Asansör Arıza Yönetim Programı Değiştirme Sinyalleri

İÇERİK

Bir asansör arıza yönetim programı, yalnızca gelen arızaların kaydedildiği dijital bir liste değildir. Doğru kullanıldığında arıza bildiriminden teknisyen görevlendirmeye, sahadaki müdahaleden müşteri bilgilendirmesine ve geçmiş arıza analizine kadar bütün servis operasyonunu birbirine bağlar. Ancak firma büyüdükçe, teknisyen sayısı arttıkça ve servis verilen asansör portföyü genişledikçe yıllar önce yeterli görünen bir program operasyonun önünde engel hâline gelebilir.

Buradaki kritik nokta, programı yalnızca “çalışıyor veya çalışmıyor” şeklinde değerlendirmemektir. Yazılım teknik olarak çalışabilir; fakat arızalar hâlâ WhatsApp mesajlarından aranıyorsa, teknisyen atamaları telefonla yapılıyorsa, müşteri sürekli durum soruyorsa ve yöneticiler hangi arızanın neden geciktiğini göremiyorsa sistem görevini yeterince yerine getirmiyor demektir.

Peki asansör arıza yönetim programını değiştirme zamanı nasıl anlaşılır? Aşağıdaki sinyaller, mevcut sisteminizin büyüyen operasyonunuza artık ayak uyduramadığını gösterebilir.

1. Arıza Kayıtları Farklı Kanallara Dağılıyorsa

Değişim ihtiyacının en güçlü belirtilerinden biri, arıza kayıtlarının tek sistemde toplanamamasıdır.

Bir bakım firmasına aynı gün içinde arıza bildirimleri şu kanallardan gelebilir:

• Firma telefonu
• Teknisyenlerin kişisel telefonları
• WhatsApp
• Bina yöneticisinin doğrudan araması
• Ofis personeline gelen mesajlar
• E-posta
• QR kod veya dijital bildirim kanalları

İyi bir arıza yönetim sisteminde bu bildirimlerin sonunda tek bir takip kaydı oluşmalıdır. Ancak personel programı kullanmak yerine ayrıca defter, Excel veya WhatsApp grubu tutuyorsa burada önemli bir sorun vardır.

Örneğin bina yöneticisi saat 09.20'de arıza bildirir. Ofis çalışanı teknisyene WhatsApp'tan mesaj gönderir. Teknisyen başka bir işte olduğu için mesajı 40 dakika sonra görür. Bu sırada müşteri tekrar arar ve arızanın sisteme kaydedilmediği fark edilir.

Sorun teknisyenin hızından çok sürecin kişilere bağlı olmasıdır.

Bir arızanın takibi için sürekli telefon görüşmesi yapmak gerekiyorsa kullanılan sistem gerçek anlamda arıza yönetimi sağlamıyor olabilir.

2. Hangi Teknisyenin Hangi Arızaya Gittiği Net Değilse

Arıza yönetiminin merkezinde doğru teknisyeni doğru işe yönlendirmek vardır.

Küçük bir ekipte servis sorumlusu personelin günlük durumunu ezbere bilebilir. Fakat ekip büyüdüğünde bu yöntem sürdürülebilir değildir.

Örneğin 8 teknisyeniniz olduğunu düşünün. Aynı anda 11 farklı arıza geldiğinde şu soruların hızlı cevaplanması gerekir:

• Hangi teknisyen müsait?
• Hangi teknisyen hangi bölgede?
• Kim başka bir arıza üzerinde çalışıyor?
• Hangi kayıt daha acil?
• Teknisyen görevi kabul etti mi?
• Sahaya ulaştı mı?
• İşlem tamamlandı mı?

Bu soruların cevabı için sürekli telefon trafiği gerekiyorsa mevcut asansör arıza takip programı saha operasyonunu yeterince desteklemiyor olabilir.

Özellikle servis hacmi yükseldikçe manuel görev dağıtımı, arıza müdahale süresini uzatabilir ve ekipler arasında iş yükü dengesizliği oluşturabilir.

3. Arıza Müdahale Sürelerini Ölçemiyorsanız

Bir arıza kaydının sadece “açık” veya “kapalı” olması yeterli değildir. Firmanın süreç performansını anlayabilmesi için arıza yaşam döngüsündeki temel zamanları izleyebilmesi gerekir.

Örneğin:

Ölçülmesi gereken veri	Neden önemlidir?
Arıza bildirim zamanı	Sürecin başlangıcını gösterir
Teknisyen atama zamanı	Ofis operasyonunun hızını gösterir
Müdahale başlangıcı	Sahaya ulaşma performansını gösterir
Arıza kapanış zamanı	Toplam çözüm süresini ortaya çıkarır
Tekrar arıza kaydı	Kalıcı çözüm kalitesini değerlendirmeye yardımcı olur
Kullanılan parça/not	Teknik geçmişin oluşturulmasını sağlar

Mevcut sisteminiz bu verileri sağlıklı biçimde kaydetmiyorsa yöneticiler genellikle yalnızca şikâyet geldiğinde gecikmelerden haberdar olur.

Oysa ölçülemeyen servis performansını geliştirmek oldukça zordur.

Örneğin bir teknisyenin ortalama müdahale süresi 35 dakika, diğerinin 90 dakika olabilir. Bunun sebebi personel performansı, bölge dağılımı, trafik, yanlış görev planlaması veya teknik uzmanlık olabilir. Veri olmadan doğru nedeni bulmak güçleşir.

4. Tekrarlayan Arızaların Geçmişine Ulaşamıyorsanız

Asansör servis operasyonunda en değerli verilerden biri arıza geçmişidir.

Aynı asansörün son üç ayda beş kez kapı kilidi kaynaklı arıza vermesi ile beş farklı nedenle arıza vermesi aynı durum değildir.

Teknisyen sahaya gittiğinde şu bilgileri görebilmelidir:

• Daha önce hangi arızalar oluşmuş?
• Hangi parçalar değiştirilmiş?
• Son müdahaleyi kim yapmış?
• Hangi teknik açıklama bırakılmış?
• Aynı sorun daha önce tekrar etmiş mi?
• Fotoğraf veya servis kaydı bulunuyor mu?

Bu bilgiler geçmiş WhatsApp konuşmalarında veya farklı personelin notlarında kalıyorsa firma teknik hafızasını oluşturamaz.

Sonuç olarak teknisyen her arızayı sıfırdan incelemek zorunda kalabilir.

Özellikle sık tekrar eden arızaların tespiti; bakım kalitesini, parça kararlarını ve müşteri iletişimini doğrudan etkileyebilir. Bu nedenle yeni program seçerken yalnızca “arıza kaydı açıyor mu?” sorusuna değil, arıza geçmişini ne kadar anlamlı sunduğuna da bakılmalıdır.

5. Teknisyenler Programı Kullanmak İstemiyorsa

Bazı firmalarda problem yazılımın teknik olarak yetersiz olması değil, saha kullanımının zor olmasıdır.

Bir teknisyenin arıza kaydını kapatmak için uzun formlar doldurması, bilgisayara ihtiyaç duyması veya çok sayıda gereksiz ekran arasında dolaşması gerekiyorsa sistem kısa sürede kullanılmamaya başlanabilir.

Sahada ideal süreç mümkün olduğunca basit olmalıdır:

1. Teknisyen görevi görür.
2. Arıza adresine gider.
3. Yapılan işlemi kaydeder.
4. Gerekirse fotoğraf ekler.
5. Kullanılan parça veya açıklamayı girer.
6. Arızayı tamamlar.

Program ne kadar karmaşık olursa teknisyenlerin “sonra girerim” deme ihtimali o kadar artar. Kayıtlar gün sonunda topluca girildiğinde ise saat bilgileri, teknik açıklamalar ve işlem detayları gerçeği tam olarak yansıtmayabilir.

Program değişikliği düşünürken masaüstündeki özelliklerden önce sahadaki teknisyenin kullanım deneyimini test etmek bu nedenle önemlidir.

6. Müşteri Sürekli “Teknisyen Ne Zaman Gelecek?” Diye Arıyorsa

Arıza yönetimi yalnızca firma içi verimlilik konusu değildir. Aynı zamanda müşteri deneyimini doğrudan etkiler.

Bina yöneticisi arıza bildirdikten sonra çoğunlukla üç şeyi bilmek ister:

• Bildirim firmaya ulaştı mı?
• Teknisyen yönlendirildi mi?
• Arıza çözüldü mü?

Bu üç bilgi için müşterinin sürekli firmayı araması gerekiyorsa iletişim sürecinde gereksiz iş yükü oluşur.

Örneğin bir servis sorumlusu günde 25 arıza yönetiyorsa ve her arıza için müşteriyle iki ek telefon görüşmesi yapıyorsa toplamda 50 ek görüşme ortaya çıkabilir. Bu görüşmelerin bir kısmı sistem tarafından sağlanan durum bilgileri veya otomatik bilgilendirme süreçleriyle azaltılabilir.

Asansorex gibi arıza ve bakım süreçlerini tek yerde toplayan sistemler, bildirimin kayda alınması, teknisyen görevlendirmesi ve tamamlanan servis kayıtlarının takip edilmesi açısından bu dağınıklığı azaltmaya yardımcı olabilir.

7. Rapor Almak İçin Excel'e Veri Taşıyorsanız

Mevcut programınız arızaları kaydediyor olabilir. Ancak ay sonunda analiz yapabilmek için verileri Excel'e aktarıp tekrar düzenlemek zorunda kalıyorsanız sistemin raporlama tarafı yetersiz kalıyor olabilir.

Firma sahibinin veya servis sorumlusunun en azından şu sorulara cevap verebilmesi faydalıdır:

• Bu ay kaç arıza oluştu?
• En fazla arıza hangi binalarda gerçekleşti?
• Ortalama çözüm süresi nedir?
• En çok tekrar eden arıza tipi hangisi?
• Hangi teknisyen kaç arızaya müdahale etti?
• Hangi müşterilerde olağan dışı arıza yoğunluğu var?
• Kaç kayıt hâlâ açık?
• Hangi arızalar uzun süredir sonuçlandırılmadı?

Bu sorulara cevap vermek için birkaç farklı dosyanın birleştirilmesi gerekiyorsa zaman kaybı yalnızca rapor hazırlama aşamasında yaşanmaz. Yönetim kararları da gecikir.

Programı Değiştirme Kararı İçin Pratik Kontrol Listesi

Tek bir sorun nedeniyle hemen yazılım değiştirmek doğru olmayabilir. Bunun yerine mevcut sistemi belirli kriterlerle değerlendirmek daha sağlıklıdır.

Aşağıdaki işaretlerden kaç tanesinin firmanızda bulunduğunu kontrol edin:

• Arıza kayıtları WhatsApp ve telefonlarda kalıyor.
• Teknisyen atamaları manuel takip ediliyor.
• Açık arızaların güncel durumu kolay görülemiyor.
• Müdahale ve çözüm süreleri ölçülemiyor.
• Eski arıza geçmişine ulaşmak zor.
• Teknisyenler programı düzenli kullanmıyor.
• Fotoğraf ve teknik notlar farklı yerlerde tutuluyor.
• Müşteriler durum öğrenmek için sürekli arıyor.
• Tekrarlayan arızalar kolay analiz edilemiyor.
• Rapor hazırlamak için Excel kullanılıyor.
• Yeni personelin sisteme alışması uzun sürüyor.
• Firma büyüdükçe program yavaşlatıcı hâle geliyor.

Genel bir değerlendirme olarak bir veya iki problem eğitim ya da süreç düzenlemesiyle çözülebilir. Ancak bu listenin önemli bir bölümü günlük operasyonunuzda yaşanıyorsa yeni bir sistem araştırmak mantıklı hâle gelir.

Yeni Programa Geçmeden Önce Ne Yapılmalı?

Program değiştirme kararı verildiğinde doğrudan tüm verileri yeni sisteme taşımak yerine kontrollü ilerlemek daha güvenlidir.

Öncelikle mevcut sistemde şu verilerin kapsamını çıkarın:

• Müşteri ve bina kayıtları
• Asansör bilgileri
• Geçmiş arızalar
• Bakım kayıtları
• Teknisyen kayıtları
• Sözleşmeler
• Cari bilgiler
• Fotoğraf ve belgeler

Ardından yeni programı gerçek bir saha senaryosuyla test edin.

Örneğin demo sırasında yalnızca ekranları izlemek yerine şu senaryoyu uygulayın:

Arıza bildirimi → teknisyen atama → saha müdahalesi → fotoğraf/not → arıza kapanışı → geçmiş kayıt kontrolü

Bu zincirin tamamı kolay yürüyorsa program günlük operasyon konusunda daha gerçekçi biçimde değerlendirilmiş olur.

Sıkça Sorulan Sorular

Asansör arıza yönetim programı ne zaman değiştirilmelidir?

Program günlük operasyonu kolaylaştırmak yerine sürekli manuel işlem oluşturuyorsa, arıza kayıtları kayboluyorsa, saha ekipleri sistemi kullanmıyorsa veya gerekli raporlara ulaşmak zorlaşıyorsa değişiklik değerlendirilmelidir.

Eski arıza kayıtları yeni programa aktarılabilir mi?

Bu, kullanılan eski ve yeni sistemin veri aktarım özelliklerine bağlıdır. Geçiş öncesinde özellikle müşteri, bina, asansör ve mümkünse geçmiş servis kayıtlarının hangi formatta alınabildiği kontrol edilmelidir.

Program değiştirmek servis operasyonunu aksatır mı?

Plansız geçiş aksama yaratabilir. Bu nedenle veri hazırlığı, kullanıcı eğitimi ve kısa bir pilot kullanım dönemi önemlidir. Önce belirli bir ekip veya sınırlı sayıda bina üzerinde yeni sistemi denemek riski azaltabilir.

Yeni arıza programında en önemli özellik nedir?

Tek bir özellikten çok bütün sürecin kesintisiz çalışması önemlidir. Arızanın açılması, teknisyen ataması, saha kaydı, fotoğraf veya açıklama eklenmesi, kapanış ve geçmişe erişim aynı süreç içerisinde kolay yürütülebilmelidir.

WhatsApp kullanmak yerine mutlaka arıza programı gerekir mi?

WhatsApp hızlı iletişim için kullanışlıdır ancak tek başına düzenli bir servis kayıt sistemi değildir. Mesaj geçmişinden arıza süresi, teknisyen performansı, tekrar eden sorunlar veya bina bazlı servis geçmişi çıkarmak zorlaşabilir.

Asansorex arıza yönetiminde nasıl yardımcı olabilir?

Asansorex; arıza kayıtlarının merkezi biçimde takip edilmesi, saha ekiplerine iş yönlendirilmesi ve tamamlanan servis işlemlerinin kayıt altına alınması gibi süreçleri tek yapı altında toplamaya yardımcı olur. Özellikle telefon, mesaj ve ayrı dosyalar arasında yürüyen operasyonu daha izlenebilir hâle getirmek isteyen firmalar için değerlendirilebilir.

Özet

Bir asansör arıza yönetim programını değiştirme kararı, yalnızca mevcut yazılım eski göründüğü için verilmemelidir. Asıl ölçüt, sistemin günlük operasyonu ne kadar desteklediğidir.

Arıza kayıtlarının farklı kanallara dağılması, teknisyen atamalarının telefonla yapılması, müdahale sürelerinin ölçülememesi, tekrar eden arızaların fark edilememesi ve müşterilerin sürekli bilgi almak için firmayı araması önemli uyarı işaretleridir.

En sağlıklı yaklaşım, mevcut sürecinizi uçtan uca değerlendirmek ve yeni sistemi gerçek bir arıza senaryosunda test etmektir. Amaç daha fazla özellik satın almak değil; arıza bildirimi ile çözüm arasındaki süreci daha hızlı, ölçülebilir ve kontrol edilebilir hâle getirmektir. Asansorex gibi bakım ve arıza süreçlerini birlikte yöneten çözümler de bu noktada dağınık servis operasyonunu tek sistemde toplamaya yardımcı olabilir.