Asansör Arıza Yönetim Programı kurulumunda ekip direnci nasıl aşılır?

İÇERİK

Asansör bakım firmalarında yeni bir dijital sistem devreye alınırken en sık karşılaşılan sorunlardan biri teknik kurulum değil, ekibin çalışma alışkanlıklarını değiştirmeye direnmesidir. Yıllardır telefon, WhatsApp, kâğıt servis formu veya kişisel notlarla arıza yöneten bir teknisyenden bir günde tamamen farklı bir sisteme geçmesini beklemek çoğu zaman gerçekçi değildir. Asansör Arıza Yönetim Programı kurulumu doğru yönetilmezse çalışanlar sistemi ek iş olarak görebilir, kayıtları eksik girebilir veya eski yöntemleri kullanmaya devam edebilir.

Bu nedenle başarılı bir geçiş yalnızca yazılımın kurulmasıyla değil; neden geçiş yapıldığının anlatılması, saha ekibinin sürece dahil edilmesi, kullanımın sade tutulması ve ilk haftaların yakından takip edilmesiyle mümkündür. Doğru uygulandığında dijital arıza yönetimi teknisyenin işini zorlaştıran değil, aksine telefon trafiğini ve tekrar eden bilgi taleplerini azaltan bir çalışma aracına dönüşür.

Ekipler neden yeni arıza yönetim sistemine direnç gösterir?

Direnci aşmanın ilk şartı, çalışanların neden karşı çıktığını doğru anlamaktır. Her itirazı "teknolojiye karşı olmak" şeklinde yorumlamak önemli bir yönetim hatasıdır.

Sahada çalışan teknisyenin temel kaygısı genellikle çok pratiktir: Yeni sistem bana daha fazla iş çıkaracak mı?

Örneğin teknisyen daha önce arızayı telefonla kapatırken yeni düzende müşteri seçmesi, işlem açıklaması girmesi, kullanılan parçayı kaydetmesi ve işi tamamlandı olarak işaretlemesi istenebilir. Süreç çalışan açısından gereksiz derecede uzunsa direnç kaçınılmaz hale gelir.

En sık görülen direnç nedenleri şunlardır:

• "Zaten WhatsApp'tan bildiriyoruz, neden ayrıca programa girelim?" düşüncesi
• Telefon kullanımına veya mobil uygulamalara alışık olmayan personel
• Sistemin çalışanları sürekli kontrol etmek için kullanılacağı endişesi
• Yeni uygulamanın fazla veri girişi gerektirmesi
• İlk kullanım sırasında yaşanan şifre, bağlantı veya kullanıcı hataları
• Yönetimin bir hafta sonra eski sisteme döneceği düşüncesi
• Teknisyenlerin sürece dahil edilmeden doğrudan yeni sisteme zorlanması
• Ofis ile saha arasında görev ve sorumlulukların net belirlenmemesi

Özellikle deneyimli teknisyenlerde "Ben yıllardır bu işi böyle yapıyorum" yaklaşımı görülebilir. Bu kişilere yazılımın mesleki bilgilerini sorgulayan bir sistem olmadığı açık şekilde anlatılmalıdır.

Amaç teknisyenin tecrübesini değiştirmek değil, arızanın firma içinde kaybolmasını engelleyecek ortak bir kayıt düzeni oluşturmaktır.

Kurulumdan önce ekibi sürece dahil edin

Birçok firma yaptığı ilk toplantıda çalışanlara "Pazartesiden itibaren artık bu programı kullanıyoruz" der. Teknik olarak hızlı görünen bu yöntem, organizasyon açısından genellikle direnç üretir.

Daha sağlıklı yöntem, geçişten önce kısa bir ekip toplantısı yaparak mevcut sorunları çalışanlarla birlikte belirlemektir.

Örneğin şu sorular sorulabilir:

1. Arıza bilgileri size şu anda nasıl ulaşıyor?
2. Müşteri adresi veya telefon bilgisi eksik geldiğinde ne yapıyorsunuz?
3. Aynı arızaya iki teknisyenin yönlendirildiği oluyor mu?
4. Daha önce yapılan müdahaleleri görebiliyor musunuz?
5. Ofisi en çok hangi bilgileri öğrenmek için arıyorsunuz?
6. Arızayı kapattıktan sonra hangi bilgileri tekrar ofise bildiriyorsunuz?

Bu sorular sayesinde program "yönetimin istediği yeni sistem" olmaktan çıkar ve çalışanların yaşadığı gerçek problemleri çözen bir araç olarak konumlanır.

Örneğin saha personeli sürekli müşteri adresi istemek için ofisi arıyorsa, arıza kaydında açık adres ve iletişim bilgisinin bulunmasının doğrudan teknisyene sağlayacağı fayda gösterilebilir.

Benzer şekilde geçmiş arıza kayıtları görülebiliyorsa şu avantaj anlatılabilir:

"Bu asansörde geçen ay hangi parçanın değiştiğini öğrenmek için artık ofisi aramak zorunda kalmayacaksınız."

Bu yaklaşım, "program kullanmak zorundasınız" demekten çok daha etkilidir.

Asansör Arıza Yönetim Programı geçişini aşamalı yapın

Tüm şirketi aynı gün yeni sisteme geçirmek teoride hızlı görünür ancak özellikle 10-20 kişiden büyük saha ekiplerinde sorunları büyütebilir.

Daha güvenli yöntem pilot uygulamadır.

1. Küçük bir pilot ekip belirleyin

İlk aşamada teknolojiye nispeten yatkın ve geri bildirim vermeye açık birkaç personelle başlanabilir.

Örneğin:

• 1 operasyon sorumlusu
• 2 saha teknisyeni
• Belirli bir servis bölgesi
• Belirli sayıdaki müşteri veya arıza

üzerinden sistem test edilebilir.

Buradaki amaç çalışanların performansını değerlendirmek değil, iş akışındaki gereksiz adımları tespit etmektir.

2. İlk hafta yalnızca temel işlemleri kullanın

Sistemde onlarca özellik bulunması, ilk günden hepsinin kullanılmasını gerektirmez.

Başlangıçta şu dört işlem yeterli olabilir:

• Arıza kaydının oluşturulması
• Teknisyene atanması
• Teknisyenin arızayı görüntülemesi
• İşlem sonucunun kaydedilerek arızanın kapatılması

Ekip bu akışa alıştıktan sonra fotoğraf, kullanılan malzeme, müşteri onayı, açıklamalar veya diğer detaylar sürece dahil edilebilir.

3. Pilot sonuçlarını ekiple paylaşın

Örneğin ilk hafta sonunda şu sorular değerlendirilebilir:

• Eksik adres nedeniyle kaç telefon görüşmesi azaldı?
• Teknisyen arıza geçmişine ulaşabildi mi?
• Açık kalan işler daha kolay görüldü mü?
• Yanlış teknisyene atanan işler azaldı mı?
• Hangi ekran veya işlem çalışanları zorladı?

Bu geri bildirimler daha geniş ekip geçişinden önce sürecin düzeltilmesini sağlar.

Asansorex gibi arıza ve bakım yönetimi çözümlerinde arıza kaydı, görev atama ve saha takibinin aynı iş akışında tutulması bu geçişin daha düzenli yürütülmesine yardımcı olabilir. Burada önemli olan bütün özellikleri aynı anda açmak yerine firmanın mevcut çalışma biçimine uygun, sade bir başlangıç yapmaktır.

Eğitim verirken uzun sunum yerine gerçek arıza senaryosu kullanın

Saha ekipleri için iki saatlik teorik yazılım sunumları çoğu zaman verimsizdir. Teknisyenin öğrenmesi gereken şey menülerin isimleri değil, gerçek bir arıza geldiğinde hangi adımları uygulayacağıdır.

Örnek eğitim senaryosu şöyle olabilir:

1. Apartman yöneticisi "asansör 3. katta kaldı" şeklinde arıza bildirimi yaptı.
2. Ofis personeli arıza kaydı oluşturdu.
3. İş uygun teknisyene yönlendirildi.
4. Teknisyen telefonundan müşteri ve arıza bilgilerini görüntüledi.
5. Sahada gerekli kontrolleri yaptı.
6. Arızanın nedenini ve yapılan müdahaleyi kaydetti.
7. Gerekliyse kullanılan malzemeyi belirtti.
8. İş tamamlandı olarak kapatıldı.

Teknisyen bu akışı birkaç kez uyguladığında sistemin mantığını çok daha hızlı kavrar.

Eğitim sırasında özellikle "hata yaparsanız sorun olur" yaklaşımından kaçınılmalıdır. İlk günlerde yanlış seçimler veya eksik açıklamalar normal kabul edilmelidir.

Ama belirli bir süre sonra minimum kayıt standardı oluşturulmalıdır.

Örneğin firma şu alanları zorunlu çalışma standardı haline getirebilir:

İşlem	Minimum kayıt standardı	Sorumlu
Arıza oluşturma	Müşteri, cihaz, adres, arıza açıklaması	Ofis
Görev atama	Uygun teknisyen ve öncelik	Operasyon
Sahaya müdahale	Yapılan işlem açıklaması	Teknisyen
Parça değişimi	Kullanılan parçanın kaydı	Teknisyen
İş kapatma	Sonuç ve gerekiyorsa not	Teknisyen
Kontrol	Eksik veya açık kayıtların takibi	Operasyon

Böylece çalışan neyin zorunlu, neyin isteğe bağlı olduğunu bilir.

Eski yöntem ile yeni sistemi aynı anda uzun süre kullanmayın

Geçiş sürecindeki en tehlikeli modellerden biri çift kayıt sistemidir.

Örneğin firma şu düzeni oluşturursa:

• Arıza WhatsApp grubuna yazılıyor.
• Aynı bilgi programa giriliyor.
• Teknisyen ayrıca telefonla aranıyor.
• İş tamamlanınca kâğıt form dolduruluyor.
• Teknisyen sonucu tekrar WhatsApp'tan gönderiyor.

çalışanın "program sadece ekstra iş çıkardı" demesi son derece doğaldır.

Yeni sistemin kabul edilmesi için eski yöntemlerden bazıları kontrollü biçimde kaldırılmalıdır.

Örneğin pilot dönem sonrasında şirket şu kuralı koyabilir:

"Teknisyene atanacak bütün normal arızalar sistem üzerinden gönderilecek. Telefon yalnızca acil durumlarda destek iletişimi için kullanılacak."

Böyle bir kuralın uygulanabilmesi için yönetimin de sisteme sadık kalması gerekir.

Firma sahibi bir gün programdan, ertesi gün WhatsApp'tan, sonraki gün telefonla iş gönderirse çalışanlar hangi yöntemin resmi olduğunu anlayamaz.

Bu nedenle dijital dönüşümde en önemli kurallardan biri şudur:

Yönetim kullanmadığı bir sistemi personele kullandıramaz.

Performansı personeli baskılamak için değil, süreci geliştirmek için ölçün

Arıza yönetim yazılımlarının önemli avantajlarından biri operasyonun daha ölçülebilir hale gelmesidir. Ancak çalışanların ilk endişelerinden biri de tam olarak budur.

"Artık her hareketimizi takip edecekler" düşüncesi ekip direncini artırabilir.

Bu nedenle ilk aşamada göstergelerin amacının açık şekilde anlatılması önemlidir.

Örneğin takip edilebilecek operasyon göstergeleri şunlardır:

• Açık arıza sayısı
• Gün içinde kapanan arızalar
• Uzun süre açık kalan işler
• Tekrar eden arızalar
• Müdahale bekleyen işler
• Eksik kapatılan servis kayıtları
• Aynı cihazda sık tekrarlanan sorunlar

Buradaki amaç "Ahmet bugün Mehmet'ten iki iş az yaptı" şeklinde yüzeysel karşılaştırmalar yapmak olmamalıdır.

Çünkü arızaların zorluk seviyesi aynı değildir. Bir teknisyen basit kapı ayarı yaparken diğer teknisyen kart veya sürücü kaynaklı karmaşık bir sorunla saatlerce uğraşabilir.

Daha doğru yaklaşım süreç göstergelerine bakmaktır.

Örneğin sürekli aynı binada benzer arızalar oluşuyorsa asıl soru "Teknisyen neden geç kaldı?" değil, "Bu cihazda kök problem nedir?" olmalıdır.

Bu yaklaşım çalışanların sistemi cezalandırıcı bir kontrol aracı yerine teknik kararları destekleyen bir kayıt altyapısı olarak görmesini kolaylaştırır.

İlk 30 günde uygulanabilecek geçiş planı

Her firmanın personel sayısı ve iş yoğunluğu farklıdır. Buna rağmen aşağıdaki gibi basit bir geçiş planı birçok bakım firmasında başlangıç çerçevesi olarak kullanılabilir.

İlk hafta: Hazırlık

• Mevcut arıza sürecini yazılı hale getirin.
• Ekibin yaşadığı temel sorunları belirleyin.
• Kullanıcıları oluşturun.
• Müşteri ve asansör kayıtlarını kontrol edin.
• Pilot teknisyenleri seçin.
• Minimum zorunlu kayıt alanlarını belirleyin.

İkinci hafta: Pilot kullanım

Gerçek arızaların bir bölümünü sistem üzerinden yönetin.

Her gün sonunda 10-15 dakikalık değerlendirme yapılarak şu soru sorulabilir:

"Bugün sistemi kullanırken sizi gereksiz yere yavaşlatan ne oldu?"

Bu tek soru bile birçok kullanım problemini erken aşamada ortaya çıkarabilir.

Üçüncü hafta: Ekip geneline yaygınlaştırma

Pilot ekipte çözülen problemlerden sonra diğer teknisyenler sisteme dahil edilir.

Deneyimli pilot kullanıcılar yeni personele destek verebilir. Böylece bütün sorular yalnızca ofis yöneticisine yönelmez.

Dördüncü hafta: Standartlaştırma

Bu aşamada artık şirketin resmi arıza yönetim yöntemi netleşmelidir.

Hangi işler sistemden açılacak, kimin görev atayacağı, teknisyenin hangi bilgileri girmesi gerektiği ve işin hangi koşulda kapanmış kabul edileceği yazılı hale getirilmelidir.

Amaç mümkün olduğunca çok alan doldurtmak değil, sonradan bakıldığında arızanın ne olduğunu ve ne yapıldığını anlayabilecek kadar kaliteli kayıt oluşturmaktır.

Sıkça Sorulan Sorular

Teknisyenler program kullanmak istemiyorsa zorunlu tutmak gerekir mi?

Belirli bir geçiş döneminden sonra şirketin resmi çalışma yönteminin net olması gerekir. Ancak ilk günden yalnızca zorunluluk üzerinden ilerlemek direnç yaratabilir. Önce kullanımın teknisyene sağlayacağı faydalar gösterilmeli, eğitim verilmeli ve teknik sorunlar giderilmelidir. Ardından minimum kullanım standartları herkes için uygulanmalıdır.

Yaşça büyük veya teknolojiye uzak teknisyenler sisteme nasıl adapte edilir?

Karmaşık eğitimler yerine gerçek arıza senaryolarıyla birebir uygulama daha verimli olur. İlk aşamada yalnızca arızayı açma, görüntüleme ve kapatma gibi temel işlemler öğretilmelidir. Menülerin tamamını öğretmeye çalışmak gereksizdir.

WhatsApp ile arıza takibine devam etmek sorun yaratır mı?

WhatsApp hızlı iletişim için faydalı olabilir ancak uzun vadeli arıza geçmişi, sorumluluk takibi ve raporlama açısından yetersiz kalabilir. Özellikle müşteri sayısı büyüdükçe hangi işin açık veya kapalı olduğunu takip etmek zorlaşır. Mesajlaşma aracı iletişim için, arıza yönetim sistemi ise resmi kayıt için kullanılabilir.

Yeni sisteme geçiş kaç gün sürer?

Tek bir standart süre yoktur. Küçük bir ekip birkaç gün içinde temel akışa alışabilirken daha büyük organizasyonlarda pilot kullanım ve eğitim süreci birkaç haftaya yayılabilir. Önemli olan bir anda bütün özelliklere geçmek değil, temel arıza sürecini doğru oturtmaktır.

Ekip direncinin azaldığını nasıl anlarız?

Çalışanların sistemi hatırlatılmadan kullanmaya başlaması, telefonla bilgi sorma ihtiyacının azalması, eksik arıza kayıtlarının düşmesi ve açık işlerin sistem üzerinden takip edilmesi önemli göstergelerdir. Ayrıca "programa girdin mi?" sorusunun günlük operasyon içinde giderek azalması iyi bir işarettir.

Asansorex ekip geçişinde nasıl kullanılabilir?

Asansorex, arıza kaydı ve saha operasyonlarının tek bir düzen içinde takip edilmesine yardımcı olabilir. Kurulum sırasında sistemi firmanın mevcut iş akışına göre sade şekilde başlatmak ve ekibi aşamalı olarak dahil etmek, kullanım alışkanlığının oluşmasını kolaylaştırır.

Özet

Asansör Arıza Yönetim Programı kurulumunda başarı yalnızca doğru yazılımı seçmekle elde edilmez. Asıl kritik konu, ofis ve saha ekibinin yeni çalışma biçimini benimsemesidir. Bunun için çalışanların neden direnç gösterdiği anlaşılmalı, geçişin faydası somut örneklerle anlatılmalı ve bütün özellikleri aynı anda kullanmaya çalışmak yerine temel süreçlerden başlanmalıdır.

Pilot ekip oluşturmak, gerçek arıza senaryolarıyla kısa eğitimler vermek, minimum kayıt standartlarını belirlemek ve eski yöntemleri kontrollü biçimde devreden çıkarmak geçiş sürecini önemli ölçüde kolaylaştırır. En önemlisi ise yönetimin de belirlenen sisteme bağlı kalmasıdır.

Doğru uygulandığında dijital arıza yönetimi teknisyen için ek bürokrasi değil; eksik adres aramalarını, tekrar eden telefon görüşmelerini ve belirsiz görev dağılımlarını azaltan bir çalışma düzenine dönüşür. Böylece firma sahibi operasyonu daha net takip ederken teknisyen de hangi işe, hangi bilgiyle ve hangi öncelikle müdahale edeceğini daha kolay görebilir.