Asansör Arıza Takip Programı için pilot müşteri seçimi

İÇERİK

Bir Asansör Arıza Takip Programı satın almak veya mevcut sistemi değiştirmek önemli bir karardır; ancak asıl başarı yazılımın satın alındığı gün değil, sahada kullanılmaya başladığı gün ortaya çıkar. Özellikle yüzlerce asansöre hizmet veren firmalarda yeni sistemi tüm portföye aynı anda açmak gereksiz operasyon riski oluşturabilir. Bunun yerine belirli bir müşteri, bina grubu veya site üzerinde pilot uygulama yapmak; süreçteki eksikleri görmeyi, teknisyenlerin alışkanlıklarını test etmeyi ve gerçek sonuçları ölçmeyi kolaylaştırır.

Buradaki kritik konu, pilot için herhangi bir müşteriyi seçmek değildir. Çok sakin bir bina seçerseniz sistem gerçek arıza yükünde sınanmaz; aşırı problemli bir bina seçerseniz de pilot gereksiz yere kriz yönetimine dönüşebilir. Bu nedenle doğru pilot müşteri, günlük operasyonu temsil edecek kadar hareketli fakat ekibin kontrol edebileceği kadar yönetilebilir olmalıdır.

Pilot müşteri neden önemlidir?

Asansör arıza yönetiminde kullanılan bir program; yalnızca arıza kaydı açılan dijital bir defter değildir. Çağrının alınmasından teknisyenin yönlendirilmesine, müdahale süresinden yapılan işlemin kaydedilmesine kadar birçok alışkanlığı değiştirir.

Örneğin eski düzende süreç şöyle ilerliyor olabilir:

1. Bina yöneticisi firmayı telefonla arar.
2. Ofisteki personel teknisyeni WhatsApp üzerinden bilgilendirir.
3. Teknisyen binaya gider.
4. Arızayı giderir.
5. Sonuç sözlü olarak ofise bildirilir.
6. Arıza geçmişi düzenli şekilde kayıt altına alınmayabilir.

Dijital arıza takibinde ise çağrının kayıt altına alınması, ilgili personele atanması, durumunun değiştirilmesi, sahadaki işlemin kaydedilmesi ve kapanış bilgilerinin saklanması gerekir.

Bu geçişin tüm müşterilerde aynı anda yapılması durumunda küçük bir eğitim eksikliği bile onlarca açık kayda dönüşebilir. Pilot müşteri uygulamasının amacı, yeni çalışma yöntemini kontrollü ölçekte doğrulamaktır.

İyi bir pilot çalışma, yazılımın sadece çalışıp çalışmadığını değil; firmanın günlük işleyişine gerçekten uyup uymadığını gösterir.

Doğru pilot müşterinin özellikleri nelerdir?

Pilot için en büyük müşteriyi veya firmanın en yakın olduğu bina yöneticisini seçmek her zaman doğru değildir. Seçim yapılırken operasyonu temsil eden bazı kriterler birlikte değerlendirilmelidir.

Seçim kriteri	Pilot için ideal durum	Neden önemli?
Asansör sayısı	Orta ölçekli portföy	Yeterli işlem üretir, yönetimi zorlaştırmaz
Arıza sıklığı	Düzenli fakat aşırı olmayan	Sistemin gerçek çağrılarla test edilmesini sağlar
Bina yöneticisi	İletişime açık	Yeni süreç hakkında geri bildirim alınabilir
Teknisyen sayısı	1–3 aktif teknisyen	Kullanım alışkanlıklarını karşılaştırmayı kolaylaştırır
Bölge	Firmanın aktif servis bölgesi	Gereksiz ulaşım ve operasyon karmaşasını azaltır
Geçmiş kayıtlar	Kısmen mevcut	Eski ve yeni sistem kıyaslanabilir
Acil durum yoğunluğu	Yönetilebilir	Pilotun sürekli kriz ortamında yürütülmesini önler

Örneğin bakım firmanızın 400 asansörlük portföyü varsa ilk pilot için bütün müşterileri sisteme almak yerine aynı bölgede bulunan 10–30 asansörlük bir site veya bina grubu daha sağlıklı olabilir.

Buradaki sayı kesin bir kural değildir. Önemli olan, seçilen grubun gerçek operasyonu gösterecek kadar hareket üretmesidir.

Pilot müşteri seçerken kaçınılması gereken hatalar

Pilot çalışmaların başarısız olmasının nedeni her zaman kullanılan yazılım değildir. Yanlış müşteri seçimi de sonuçları ciddi biçimde etkileyebilir.

Hiç arıza üretmeyen müşteriyi seçmek

Ayda neredeyse hiç çağrı gelmeyen birkaç asansörde yapılan test, arıza takip sürecinin gerçek performansını ortaya çıkarmaz. Program kullanılmadığı için teknik ekip de yeni sisteme alışamaz.

Pilot döneminde şu işlemlerin gerçekten oluşması gerekir:

• Arıza kaydı açılması
• Arızanın teknisyene atanması
• Teknisyenin işi görüntülemesi
• Müdahale bilgilerinin girilmesi
• Kullanılan parçaların veya yapılan işlemlerin kaydedilmesi
• Arızanın kapatılması
• Gerekirse yöneticiye bilgilendirme yapılması

Bu akışlardan yalnızca biri test ediliyorsa pilot kapsamı yetersiz kalabilir.

En problemli müşteriyi pilot yapmak

Diğer uçtaki hata ise sürekli arıza veren, yöneticiyle iletişim problemi yaşanan veya teknik açıdan ciddi sorunları bulunan bir binayı pilot seçmektir.

Böyle bir müşteride yaşanan her aksaklık yazılıma bağlanabilir. Oysa sorun asansörün teknik durumundan, ekip yoğunluğundan veya müşteri ilişkisinden kaynaklanıyor olabilir.

İlk pilot için operasyonu temsil eden ancak sürekli kriz üretmeyen bir müşteri daha sağlıklıdır.

Sadece teknolojiye yatkın teknisyeni kullanmak

Pilot uygulamada yalnızca telefon ve uygulama kullanımına çok alışkın bir teknisyeni görevlendirmek yanıltıcı sonuç verebilir.

Gerçek yaygınlaştırmada sistemi farklı yaş ve deneyim seviyelerindeki personel kullanacaktır. Bu nedenle mümkünse pilot ekibinde farklı kullanım alışkanlıklarına sahip teknisyenler bulunmalıdır.

Amaç en hızlı kullanıcıyı bulmak değil, ortalama saha personelinin sistemi rahat kullanıp kullanamadığını görmek olmalıdır.

Pilot başlamadan önce hangi ölçütler belirlenmeli?

Pilot çalışma yalnızca “birkaç hafta kullanalım, bakalım nasıl olacak” şeklinde yürütülmemelidir. Başlangıçta ölçülecek göstergeler belirlenmezse pilot sonunda yazılımın faydası konusunda herkes farklı yorum yapabilir.

En azından aşağıdaki değerlerin pilot öncesinde ve pilot sırasında takip edilmesi faydalıdır:

• Arıza kaydının alınma zamanı
• Teknisyene atanma süresi
• İlk müdahale süresi
• Açık kalan arıza sayısı
• Tekrar eden arıza sayısı
• Eksik kapanan servis kaydı sayısı
• Yönetici tarafından tekrar bilgi istemek için yapılan arama sayısı
• Teknisyenin gün içinde tamamladığı arıza sayısı

Örneğin eski sistemde 20 arızanın beşinde kapanış bilgisine ulaşmak için teknisyenin tekrar aranması gerekiyorsa, pilot sistem sonrasında bu sayının bire düşmesi önemli bir operasyon kazanımıdır.

Benzer şekilde ofis personeli her gün “Hangi teknisyen hangi arızaya gitti?” sorusunu telefonla takip etmek zorunda kalıyorsa, pilot sonrasında bu bilginin sistem üzerinden görülebilmesi doğrudan zaman tasarrufu sağlar.

Pilot uygulama nasıl yürütülmeli?

Pilot müşteri belirlendikten sonra süreci gereğinden fazla karmaşık hale getirmemek gerekir. İlk amaç bütün özellikleri kullanmak değil, temel arıza operasyonunun eksiksiz işlemesini sağlamaktır.

1. Müşteri ve asansör bilgilerini hazırlayın

Pilot müşterinin kayıtları mümkün olduğunca temiz şekilde sisteme aktarılmalıdır.

Kontrol edilmesi gereken temel bilgiler şunlardır:

• Bina veya site adı
• Açık adres
• Yetkili kişi
• Telefon bilgisi
• Asansörlerin tanımları
• İlgili teknisyen veya servis bölgesi
• Varsa geçmiş arıza bilgileri

Yanlış telefon numarası veya aynı asansörün iki kez kayıtlı olması gibi veri problemleri, pilot sırasında sistemi olduğundan daha karmaşık gösterebilir.

2. Arıza açma yöntemini standartlaştırın

Ofiste üç kişinin üç farklı yöntem kullanması doğru değildir. Pilot süresince arızanın sisteme nasıl girileceği açıkça belirlenmelidir.

Örneğin:

Çağrı al → müşteri/asansör seç → arıza açıklaması gir → teknisyene ata → durum takibi yap

Bu basit standart bile unutulan arıza kayıtlarını ciddi ölçüde azaltabilir.

3. Teknisyen kapanış standardını belirleyin

Arızanın yalnızca “tamamlandı” olarak işaretlenmesi yeterli değildir. Firma, hangi bilgilerin mutlaka girileceğini önceden belirlemelidir.

Örneğin:

• Tespit edilen sorun
• Yapılan işlem
• Değiştirilen veya önerilen parça
• Müdahale sonucu
• Gerekirse fotoğraf
• Tekrar ziyaret gerekip gerekmediği

Bu alanlar düzenli tutulduğunda aynı asansörde birkaç ay sonra meydana gelen arızanın geçmişi çok daha kolay analiz edilir.

Asansorex gibi arıza ve bakım süreçlerini aynı müşteri/asansör geçmişi altında takip etmeye yardımcı olan sistemlerde bu kayıtların sahadan düzenli girilmesi, pilot sonrasında gerçek operasyon verisi oluşmasını sağlar.

Pilot süresi ne kadar olmalı?

Pilotun birkaç günlük olması genellikle yeterli değildir. Çünkü arıza yoğunluğu günlere göre değişebilir. Özellikle sakin geçen bir haftada sistem yeterince test edilmeyebilir.

Genel uygulamada birkaç haftalık kontrollü kullanım dönemi, temel arıza akışını değerlendirmek için daha anlamlıdır. Ancak süreyi takvimden çok işlem sayısına göre değerlendirmek daha sağlıklıdır.

Örneğin pilot boyunca yalnızca üç arıza oluştuysa dört haftalık kullanım bile sınırlı veri üretmiş olabilir. Buna karşılık yoğun bir bölgede 40–50 gerçek arıza işlemi gerçekleşmişse kullanıcı deneyimi hakkında daha güçlü sonuçlara ulaşılabilir.

Pilotun sonunda şu üç soruya cevap verilebilmelidir:

1. Ofis personeli arızaları daha düzenli takip edebiliyor mu?
2. Teknisyenler işleri sahada eksiksiz kapatabiliyor mu?
3. Firma sahibi açık işler ve servis geçmişi konusunda daha net bilgi görebiliyor mu?

Bu üç sorudan biri sürekli “hayır” cevabı alıyorsa yaygınlaştırmadan önce neden araştırılmalıdır.

Pilot sonrasında karar nasıl verilmelidir?

Pilot uygulamanın sonunda yalnızca kullanıcıların “program güzel” veya “kullanımı biraz zor” yorumlarına bakmak yetersizdir. Hem sayısal sonuçlar hem de kullanıcı geri bildirimleri birlikte değerlendirilmelidir.

Kısa bir pilot değerlendirme toplantısında şu başlıklar ele alınabilir:

• Kaç gerçek arıza sisteme girdi?
• Kaç kayıt eksiksiz kapatıldı?
• Atama sırasında problem yaşandı mı?
• Teknisyen hangi adımlarda zorlandı?
• Ofisin telefon ve WhatsApp trafiği azaldı mı?
• Bina yöneticisine daha hızlı bilgi verilebildi mi?
• Tekrar arızalarda geçmiş kayıtlara ulaşmak kolaylaştı mı?
• Sistemi bütün portföye açmadan önce değiştirilmesi gereken bir iş alışkanlığı var mı?

Burada önemli bir nokta vardır: Pilot sırasında ortaya çıkan her sorun yazılımdan kaynaklanmayabilir.

Örneğin teknisyen arıza sonucunu sisteme girmeyi sürekli unutuyorsa konu teknik özellikten çok kullanım disiplinidir. Buna karşılık saha personeli gerekli bilgiyi girmek için gereğinden fazla adım atıyorsa kullanım akışının yeniden değerlendirilmesi gerekir.

Bu ayrım doğru yapılmalıdır.

Pilot müşteriden tüm portföye geçiş

Pilot başarılı olduğunda ertesi gün bütün müşterileri sisteme aktarmak zorunlu değildir. Özellikle büyük servis firmalarında geçişi kademeli yapmak daha güvenlidir.

Örneğin geçiş şu şekilde planlanabilir:

1. İlk pilot müşteri grubu
2. Aynı servis bölgesindeki diğer binalar
3. Pilot teknisyenlerin baktığı tüm portföy
4. Diğer teknisyen ve bölgeler
5. Şirket genelinde standart kullanım

Bu yöntem sayesinde ilk grupta öğrenilen uygulamalar sonraki ekiplere aktarılabilir.

Örneğin pilotta “arıza kapanışında yapılan işlem mutlaka yazılacak” standardı oluşturulduysa, ikinci gruba geçerken eğitim materyaline bu madde doğrudan eklenebilir.

Böylece yazılım geçişi yalnızca teknik bir kurulum değil, aynı zamanda firmanın servis süreçlerini standartlaştırma fırsatına dönüşür.

Sıkça Sorulan Sorular

Asansör Arıza Takip Programı pilotu için kaç müşteri seçilmeli?

Tek bir sabit sayı yoktur. Önemli olan pilot grubunun gerçek arıza trafiği üretmesi ve ekip tarafından kolay yönetilebilmesidir. Orta ölçekli bir bina grubu veya aynı bölgede bulunan sınırlı sayıdaki müşterilerle başlamak genellikle daha kontrollü sonuç verir.

En büyük müşteriyi pilot olarak seçmek doğru mu?

Her zaman değil. Büyük müşteriler çok sayıda asansör ve yüksek işlem hacmi nedeniyle ilk denemeyi gereksiz yere zorlaştırabilir. Operasyonu temsil eden fakat yönetilebilir yoğunluğa sahip bir müşteri daha uygun olabilir.

Pilot dönemde eski sistem de kullanılmalı mı?

Kısa bir geçiş döneminde karşılaştırma amacıyla eski kayıt yöntemine ihtiyaç duyulabilir. Ancak çalışanların sürekli hem eski hem yeni sisteme veri girmesi çift iş yaratır. Pilotun hangi tarihten itibaren ana kayıt sistemi üzerinden yürütüleceği netleştirilmelidir.

Pilot başarısı nasıl ölçülür?

Arıza kayıtlarının eksiksizliği, atama süresi, müdahale takibi, açık işlerin görünürlüğü, kapanış kalitesi, tekrar arızalar ve ofis-teknisyen arasındaki telefon trafiği gibi göstergeler karşılaştırılabilir.

Teknisyen pilot sisteme uyum sağlayamazsa ne yapılmalı?

Önce problemin kaynağı belirlenmelidir. Eğitim eksikliği, telefon kullanımı, gereksiz işlem adımları veya firma içi çalışma alışkanlıkları birbirinden ayrılmalıdır. Kısa saha eğitimi ve standart arıza kapanış akışı çoğu uyum probleminin daha net değerlendirilmesini sağlar.

Pilot başarılı olursa tüm müşterilere hemen geçilmeli mi?

Zorunlu değildir. Özellikle geniş portföylerde bölge, teknisyen veya müşteri grubu bazında kademeli geçiş daha kontrollüdür. Pilot sırasında öğrenilen kurallar her yeni gruba aktarılabilir.

Özet

Bir Asansör Arıza Takip Programı için pilot müşteri seçerken amaç en kolay müşteriyi bulmak değil, firmanın gerçek servis operasyonunu kontrollü ölçekte temsil edecek bir çalışma alanı oluşturmaktır. Yeterli arıza hareketi bulunan, iletişimi düzgün ve yönetilebilir büyüklükte bir müşteri grubu bu nedenle daha değerlidir.

Pilot başlamadan önce başarı kriterlerini belirlemek, teknisyenlerin arıza kapanış standardını netleştirmek ve sonuçları yalnızca kullanıcı yorumlarıyla değil gerçek operasyon verileriyle değerlendirmek gerekir. Başarılı bir pilot sonrasında sistem bölge veya ekip bazında kademeli olarak genişletilebilir.

Asansorex gibi arıza kayıtlarını, teknisyen süreçlerini ve müşteri/asansör geçmişini merkezi olarak takip etmeye yardımcı olan bir yazılım kullanılıyorsa pilot dönem, firmanın kendi çalışma standardını da test etmesi için iyi bir fırsattır. Hedef sadece yeni bir programa geçmek değil; kaybolmayan, ölçülebilen ve geriye dönük izlenebilen bir arıza yönetimi düzeni kurmak olmalıdır.