Asansör Arıza Yazılımı İçin Pilot Müşteri Seçimi

İÇERİK

Asansör Arıza Yazılımı kullanmaya geçerken yapılan en yaygın hatalardan biri, sistemi ilk günden bütün müşterilere ve teknisyenlere açmaktır. Kâğıt formlar, telefon görüşmeleri ve mesajlaşma gruplarıyla yürütülen bir süreç bir gecede değiştirildiğinde, küçük bir tanımlama hatası bile onlarca iş emrini etkileyebilir. Bunun yerine sınırlı sayıda müşteri, bina ve teknisyenden oluşan kontrollü bir pilot grup seçmek daha güvenli sonuç verir. Bu rehberde pilot müşterinin hangi ölçütlerle seçileceğini, uygulamanın nasıl sınırlandırılacağını ve başarı kararının hangi veriler üzerinden verileceğini öğreneceksiniz.

Pilot Uygulama Neden Gereklidir?

Pilot uygulama, yazılımın yalnızca teknik olarak çalışıp çalışmadığını kontrol etmek için yapılmaz. Asıl amaç, firmanın mevcut arıza yönetimi alışkanlıkları ile yeni sistemin işleyişi arasındaki uyumu gerçek servis koşullarında görmektir.

Bir arıza kaydı açıldığında şu zincirin eksiksiz işlemesi gerekir:

1. Çağrının doğru müşteri ve asansörle eşleştirilmesi
2. Arıza türü ve öncelik seviyesinin belirlenmesi
3. Uygun teknisyenin görevlendirilmesi
4. Teknisyenin bildirimi zamanında görmesi
5. Yola çıkma, varış ve müdahale bilgilerinin kaydedilmesi
6. Kullanılan parçaların ve yapılan işlemlerin belirtilmesi
7. Fotoğraf, açıklama ve imzanın eklenmesi
8. İş emrinin doğru durumla kapatılması
9. Bina yöneticisinin bilgilendirilmesi
10. Arıza geçmişinin raporlara doğru yansıması

Bu zinciri yüzlerce asansörde aynı anda denemek gereksiz risk oluşturur. Pilot çalışma sayesinde bildirim ayarları, kullanıcı yetkileri, zorunlu alanlar, teknisyen alışkanlıkları ve müşteri iletişimi küçük bir grupta gözlemlenir.

İyi bir pilot çalışmanın amacı kusursuz görünmek değil, sistem bütün portföye açılmadan önce eksikleri görünür hâle getirmektir.

Doğru Pilot Müşterinin Özellikleri

Pilot müşteri seçerken yalnızca “bizi üzmez” denilen en yakın bina yöneticisine yönelmek doğru değildir. Seçilen müşterinin gerçek iş yükünü temsil etmesi, geri bildirim vermesi ve makul ölçüde iş birliğine açık olması gerekir.

Orta yoğunlukta arıza kaydı bulunmalı

Hiç arıza vermeyen iki asansörlü bir bina, arıza yazılımını değerlendirmek için yeterli veri üretmez. Buna karşılık sürekli kritik arızaların yaşandığı, ilişkilerin gergin olduğu büyük bir tesis de ilk pilot için gereğinden fazla risklidir.

En uygun başlangıç noktası, geçmiş kayıtlarına göre ayda birkaç arıza bildirimi bulunan orta yoğunlukta bir müşteridir. Böylece kayıt açma, atama, müdahale ve kapatma adımları doğal akışında birkaç kez test edilebilir.

Müşteri ilişkisi sağlıklı olmalı

Pilot müşterinin firma ile iletişimi açık olmalıdır. Bina yöneticisi veya teknik sorumlu, yeni sistemin denendiğini bilmeli ve yaşadığı deneyimi dürüstçe paylaşabilmelidir. Ancak sadece her talebi kabul eden bir müşterinin seçilmesi de yanıltıcı olabilir. Pilot sonunda gerçek kullanıcı davranışını görebilmek için soru soran ve geri bildirim veren bir müşteri daha değerlidir.

Portföyü temsil etmeli

Firmanın portföyü ağırlıklı olarak apartmanlardan oluşuyorsa yalnızca hastane veya alışveriş merkezi üzerinde pilot yapılması doğru sonuç üretmez. Pilot grup, günlük operasyonun önemli özelliklerini taşımalıdır.

Örneğin şu unsurlar dikkate alınabilir:

• Asansör sayısı
• Binaların birbirine olan mesafesi
• Asansörlerin kullanım yoğunluğu
• Gece ve hafta sonu çağrı ihtimali
• Bina yöneticisinin iletişim yöntemi
• Bakım sözleşmesinin kapsamı
• Arızalarda kullanılan yedek parça çeşitliliği
• Kurtarma gerektiren çağrıların sıklığı

Dijital iletişime tamamen kapalı olmamalı

Pilot müşterinin ileri düzey teknoloji kullanıcısı olması gerekmez. Ancak SMS, e-posta, mobil bağlantı veya müşteri portalı üzerinden bilgi almaya tamamen kapalı olması uygulamayı zorlaştırır. İlk pilotta, dijital bildirimleri takip edebilecek bir yöneticiyle çalışmak daha sağlıklıdır.

Pilot Müşteri Adaylarını Puanlama

Müşteri seçimini yalnızca sezgiyle yapmak yerine basit bir puanlama tablosu kullanılabilir. Her aday 1 ile 5 arasında değerlendirilir. Toplam puanı yüksek olan müşteri pilot için önceliklendirilebilir.

Değerlendirme ölçütü	1 puan	3 puan	5 puan
Arıza yoğunluğu	Neredeyse hiç yok	Ayda birkaç kayıt	Düzenli ve yönetilebilir
Müşteri ilişkisi	Gergin	Standart	Güvenli ve iletişime açık
Portföyü temsil etme	Çok farklı	Kısmen benzer	Genel portföyle uyumlu
Dijital iletişim	Kullanmak istemiyor	Destekle kullanabilir	Rahatlıkla kullanabilir
Geri bildirim isteği	İlgisiz	Sorulursa yanıtlıyor	Düzenli geri bildirim veriyor
Operasyon riski	Çok yüksek	Orta	Kontrol edilebilir
Veri kalitesi	Bilgiler eksik	Kısmen güncel	İletişim ve cihaz verileri tam

Puanlama yapılırken “arıza yoğunluğu” ölçütünde en yüksek puan, en fazla arızası olan müşteriye verilmemelidir. Buradaki hedef, sistemi yeterince çalıştıracak fakat pilot ekibi kontrolsüz biçimde zorlamayacak bir yoğunluk bulmaktır.

Örneğin üç adaydan biri 29, diğeri 24, sonuncusu 18 puan aldıysa ilk aday güçlü bir başlangıç noktasıdır. Bununla birlikte müşterinin kritik tesis niteliğinde olması veya devam eden ticari bir anlaşmazlığın bulunması gibi özel riskler ayrıca değerlendirilmelidir.

Pilot Kapsamı Nasıl Belirlenir?

Pilot müşteriyi seçmek tek başına yeterli değildir. Hangi arıza türlerinin, kaç asansörün ve hangi çalışanların sürece dâhil edileceği açıkça yazılmalıdır.

İlk pilot için genel uygulamada şu kapsam yönetilebilir kabul edilir:

• 1 veya 2 müşteri
• 5–20 asansör
• 2–4 saha teknisyeni
• 1 operasyon sorumlusu
• 2–4 haftalık uygulama süresi
• Normal arızalar ve mesai içi çağrılar
• Sınırlı sayıda bildirim ve rapor türü

Firmanın iş hacmine göre bu rakamlar değişebilir. Yüzlerce teknisyeni olan bir kuruluş için 20 asansör küçük kalabilir; beş kişilik yerel bir bakım firması için ise 10 asansör yeterli veri üretebilir.

İlk aşamada ne test edilmelidir?

Pilotun ilk haftasında temel arıza akışına odaklanılmalıdır:

• Çağrı kaydının açılması
• Doğru asansörün seçilmesi
• Teknisyene görev atanması
• Bildirimin alınması
• Müdahale bilgilerinin girilmesi
• Fotoğraf ve açıklama eklenmesi
• İş emrinin kapatılması
• Müşteri bilgilendirmesinin yapılması

İkinci aşamada parça kullanımı, tekrar arıza analizi, teknisyen performansı, müşteri portalı ve gelişmiş raporlar denenebilir. Bütün özellikleri ilk gün zorunlu hâle getirmek, teknisyenlerin ana iş akışını öğrenmesini güçleştirir.

Pilot Teknisyen Ekibi Nasıl Seçilmeli?

Pilot müşteri kadar teknisyen seçimi de önemlidir. Yalnızca teknolojiye yatkın en genç çalışanları seçmek, gerçek saha koşullarını yansıtmayabilir. Sadece değişime dirençli çalışanlarla başlamak ise yazılımın gereksiz yere olumsuz değerlendirilmesine yol açabilir.

Dengeli bir pilot ekipte şu profillerin bulunması faydalıdır:

• Mobil uygulamaları rahat kullanan bir teknisyen
• Saha tecrübesi yüksek kıdemli bir teknisyen
• Günlük iş yükü ortalama seviyede olan bir çalışan
• Operasyon merkezinden iş atayan bir sorumlu
• Pilot süresince geri bildirimleri toplayacak bir ekip lideri

Teknisyenlere yalnızca uygulamanın menüleri anlatılmamalıdır. Hangi bilginin neden istendiği de açıklanmalıdır. Örneğin “arıza nedeni” alanının doğru doldurulması, yalnızca rapor oluşturmak için değil, aynı asansörde tekrarlanan sorunun fark edilmesi için gereklidir.

Eğitim sırasında gerçekçi bir deneme çağrısı açılması yararlı olur. Teknisyen bildirimi almalı, yola çıkmalı, sahaya varmalı, müdahale kaydı girmeli ve işi kapatmalıdır. Böylece canlı kullanımdan önce eksik izinler ve anlaşılmayan alanlar ortaya çıkar.

Başarı Ölçütleri Önceden Belirlenmeli

“Pilot güzel geçti” ifadesi ölçülebilir bir sonuç değildir. Uygulama başlamadan önce hangi göstergelerin takip edileceği belirlenmelidir. Aksi durumda ekip, sistemi kişisel izlenimlere göre değerlendirebilir.

Başarı göstergesi	Örnek hedef	Kontrol yöntemi
Dijital açılan arıza oranı	En az %90	Toplam çağrı ile sistem kayıtlarını karşılaştırma
Eksiksiz kapatılan iş emri	En az %85	Zorunlu alan ve kapatma raporu
Atama-bildirim başarısı	En az %95	Bildirim ve kullanıcı kayıtları
Fotoğraflı servis kaydı	Uygun işlerin en az %80’i	Ek dosya kontrolü
Tekrar arızanın eşleştirilmesi	Aynı cihaz kayıtlarının tamamı	Asansör geçmişi incelemesi
Kullanıcı geri bildirimi	Haftalık olarak toplanması	Kısa değerlendirme formu
Kâğıt veya mesajla paralel kayıt	Pilot sonunda belirgin azalma	Eski ve yeni kanal karşılaştırması

Hedefler firmanın başlangıç seviyesine göre ayarlanmalıdır. Daha önce bütün arıza kayıtlarını telefonla yöneten bir işletmede ilk hafta yüzde 100 eksiksizlik beklemek gerçekçi olmayabilir. Önemli olan, pilot süresi boyunca ölçülebilir bir iyileşme görülmesidir.

Asansorex gibi bir Asansör Arıza Yazılımı üzerinden çağrı, teknisyen ataması, müdahale kaydı ve cihaz geçmişinin aynı akışta tutulması, pilot sonuçlarının dağınık mesajlardan değil karşılaştırılabilir verilerden değerlendirilmesini sağlar.

Pilot Sırasında Yapılmaması Gereken Hatalar

Pilotun başarısını yazılım kadar uygulama yöntemi de belirler. Aşağıdaki hatalar sonuçların güvenilirliğini azaltır:

• En sorunlu müşteriyi seçmek: Yoğun şikâyet ve kritik arızalar, ekibin yeni sisteme alışmasını zorlaştırır.
• Hiç arıza vermeyen müşteriyi seçmek: Yeterli kayıt oluşmadığı için iş akışı gerçek anlamda test edilemez.
• Eski yöntemi sınırsız sürdürmek: Aynı çağrının telefon, mesaj, kâğıt ve yazılım üzerinden takip edilmesi kayıt karmaşası yaratır.
• Her alanı zorunlu yapmak: Teknisyenler sahada gereksiz veri girişiyle karşılaşır ve uygulamadan uzaklaşır.
• Geri bildirimi pilot sonuna bırakmak: İlk günlerde çözülebilecek küçük sorunlar haftalar boyunca devam eder.
• Teknisyeni denetlenen kişi gibi görmek: Pilot, çalışan aramak için değil süreci geliştirmek için yapılmalıdır.
• Müşteriye bilgi vermemek: Bildirim yöntemindeki değişiklikler bina yöneticisi tarafından hata olarak algılanabilir.
• Başarı ölçütü belirlememek: Karar kişisel beğeniye veya birkaç olumsuz olaya dayanır.

Eski yöntem tamamen kapatılmayacaksa bile geçiş kuralları net olmalıdır. Örneğin acil kurtarma çağrısı telefonla alınabilir; ancak çağrıyı alan personel aynı anda dijital arıza kaydını açmalıdır. Böylece hızdan ödün verilmeden kayıt bütünlüğü korunur.

Pilot Sonunda Geçiş Kararı Nasıl Verilir?

Pilot tamamlandığında yalnızca yazılım sağlayıcısının sunduğu raporlar incelenmemelidir. Firma sahibi, operasyon sorumlusu, teknisyenler ve mümkünse pilot müşteri birlikte değerlendirilmelidir.

Kapanış toplantısında şu sorulara yanıt aranabilir:

1. Kaç çağrı dijital olarak kaydedildi?
2. Hangi adımda veri kaybı veya gecikme oluştu?
3. Teknisyenlerin en çok zorlandığı alan hangisiydi?
4. Bina yöneticisinin bilgi alma süresi iyileşti mi?
5. Tekrar arızalar cihaz geçmişinde görülebildi mi?
6. Gereksiz veya eksik alanlar hangileriydi?
7. Kullanıcı yetkileri doğru çalıştı mı?
8. Tüm portföye geçişten önce hangi düzenlemeler gerekiyor?

Sonuçlar üç gruba ayrılmalıdır: hemen düzeltilmesi gereken kritik konular, genel yayılımdan sonra geliştirilebilecek iyileştirmeler ve eğitimle çözülebilecek kullanıcı sorunları. Kritik bir problem yoksa sistem bir sonraki müşteri grubuna kademeli biçimde açılabilir.

İkinci aşamada farklı özellik taşıyan müşteriler seçmek faydalıdır. İlk pilot apartman ağırlıklıysa sonraki gruba site, fabrika veya daha yüksek kullanım yoğunluğuna sahip bir bina eklenebilir. Böylece sistemin farklı operasyon koşullarındaki davranışı görülür.

Sıkça Sorulan Sorular

Pilot müşteri sayısı kaç olmalı?

Küçük ve orta ölçekli bir bakım firması için başlangıçta 1–2 müşteri genellikle yeterlidir. Müşteri sayısından çok, pilot kapsamındaki asansörlerin ve oluşan arıza kayıtlarının sistemi gerçek koşullarda çalıştıracak düzeyde olması önemlidir.

Pilot uygulama ne kadar sürmeli?

Genel uygulamada 2–4 haftalık süre temel iş akışını görmek için uygundur. Arıza sayısı düşükse süre uzatılabilir. Pilotun yalnızca takvim süresine değil, yeterli sayıda tamamlanmış arıza kaydına ulaşmasına göre kapatılması daha doğru olur.

Pilot müşteriden ücret alınmalı mı?

Bu karar firmanın ticari modeline bağlıdır. Mevcut bakım müşterisine süreç iyileştirmesi olarak sunulan pilot için ayrıca ücret istenmeyebilir. Ancak ek hizmet veya özel entegrasyon sağlanıyorsa kapsam ve ücret yazılı olarak açıklanmalıdır.

Bina yöneticisine pilot olduğu söylenmeli mi?

Evet. Yöneticiye hangi bildirimlerin değişeceği, geri bildiriminin neden önemli olduğu ve acil durumda hangi iletişim kanalını kullanacağı açıkça anlatılmalıdır. “Test yapıyoruz” yerine “arıza iletişimini ve servis takibini iyileştiren kontrollü bir uygulama yürütüyoruz” şeklinde net bir açıklama yapılabilir.

Pilot sırasında kâğıt formlar kullanılmaya devam edilmeli mi?

Kısa bir doğrulama dönemi dışında iki yöntemi uzun süre birlikte yürütmek önerilmez. Paralel kayıt zorunluysa hangi kaydın esas kabul edileceği belirlenmelidir. Aksi hâlde farklı saatler, açıklamalar ve kapatma durumları ortaya çıkabilir.

Pilot başarısız olursa yazılım tamamen bırakılmalı mı?

Hayır. Önce başarısızlığın kaynağı ayrıştırılmalıdır. Sorun yanlış müşteri seçimi, eksik eğitim, hatalı veri aktarımı, bildirim ayarı veya yazılımın iş ihtiyacını karşılamaması olabilir. Kritik eksikler düzeltildikten sonra sınırlı kapsamda ikinci pilot yapılabilir.

Özet

Asansör Arıza Yazılımı için doğru pilot müşteri; yeterli arıza verisi üreten, portföyü temsil eden, iletişime açık ve operasyon riski kontrol edilebilir müşteridir. Pilotun kapsamı, teknisyen ekibi, süresi ve başarı ölçütleri başlamadan önce belirlenmelidir. Böylece karar birkaç kullanıcının kişisel yorumuna değil; kayıt tamlığı, müdahale akışı, müşteri iletişimi ve tekrar arıza görünürlüğü gibi somut sonuçlara dayanır. Asansorex ile sınırlı bir müşteri grubunda başlatılacak kontrollü pilot, tüm portföye geçmeden önce iş akışındaki eksikleri görmeye ve daha düzenli bir dijital geçiş planlamaya yardımcı olabilir.