Asansör Arıza Ticket Programı Raporunu Yönetim Toplantısına Taşımak

İÇERİK

Bir asansör bakım firmasında arıza çağrıları gün boyunca gelir, ekiplere dağıtılır ve çoğu zaman yoğunluk içinde kapanır. Ay sonunda yönetim toplantısında “Bu ay kaç arıza vardı?” sorusuna cevap vermek kolaydır. Asıl değerli sorular ise başkadır: Hangi binalarda arıza tekrarlandı? Ekipler nerede bekledi? Hangi işler parça ihtiyacı yüzünden uzadı? Müşteriye hangi aşamada bilgi verilemedi? Asansör arıza ticket programı raporu, tek tek çağrı kayıtlarını bu sorulara cevap veren bir yönetim gündemine dönüştürmelidir. Bu rehberde, toplantıya hangi verileri götüreceğinizi, rakamları nasıl yorumlayacağınızı ve toplantıdan uygulanabilir kararlarla nasıl çıkacağınızı bulacaksınız.

Yönetim toplantısının amacı rakam okumak değil, karar vermek

Yönetim toplantısına bütün arıza kayıtlarını sırayla taşımak, katılımcıları ayrıntıya boğar. Firma sahibi maliyet ve müşteri memnuniyetini; operasyon sorumlusu ekip dağılımını; teknisyen ise sahada karşılaştığı tekrar eden teknik sorunları görmek ister. İyi bir rapor bu üç bakışı aynı olaylar üzerinden buluşturur.

Toplantı öncesinde rapor dönemini netleştirin. Örneğin içinde bulunulan ayı bir önceki ayla karşılaştırın; ancak iş yükü değiştiyse yalnızca toplam çağrı sayısına bakmayın. Portföye yeni binalar eklendiğinde arıza sayısının yükselmesi tek başına performansın kötüleştiği anlamına gelmez. Arıza sayısını hizmet verilen asansör sayısı, bina grubu ve arıza türüyle birlikte okuyun.

Raporun ilk sayfası şu dört soruya kısa cevap vermelidir:

• Kaç arıza kaydı açıldı ve kaçı kapandı?
• Hangi arızalar tekrar etti veya açık kaldı?
• Müdahale ve çözüm süresini en çok ne etkiledi?
• Önümüzdeki ay hangi üç konuda karar alınmalı?

Bu soruların cevabı bir sayfaya sığmıyorsa yönetim özeti henüz yeterince sadeleşmemiş demektir. Ayrıntılı ticket listesi gerektiğinde incelenmek üzere raporun arkasında durabilir.

Toplantıya götürülecek metrikleri doğru tanımlayın

Aynı kelimeyi farklı kişiler farklı anlamda kullanıyorsa toplantı hızla yanlış sonuca gider. Örneğin “çözüm süresi” arızanın bildirildiği andan asansörün tekrar kullanıma açıldığı ana kadar mı ölçülüyor, yoksa teknisyenin iş emrini kapattığı ana kadar mı? Bu iki zaman farklı olabilir. Her metriğin başlangıç ve bitiş noktası önceden yazılmalıdır.

Aşağıdaki tablo, yönetim toplantısı için yeterli bir başlangıç seti sunar. Bunlar yasal eşik veya sektör standardı değil, firmanın kendi performansını izlemek için kullanabileceği ölçülerdir.

Tekrar arıza ölçümünde firmanızın seçtiği zaman aralığını ve “aynı neden” tanımını sabit tutun. Bir ay yedi gün, sonraki ay otuz gün kullanılırsa oranlar karşılaştırılamaz. Ayrıca her yeni çağrıyı otomatik olarak önceki arızanın tekrarı saymayın. Aynı asansörde kapı kontağı sorunu ile enerji kesintisi farklı olaylardır.

Ortalama süreyi tek başına sunmak da yanıltabilir. Çok uzun süren birkaç iş, ortalamayı yükseltir; buna karşılık ortalama makul görünürken bazı müşteriler sürekli gecikme yaşayabilir. Bu nedenle en uzun süren işleri ve gecikmelerin hangi bina veya bölgede toplandığını ayrıca inceleyin.

Arıza kayıtlarını toplantı gündemine nasıl dönüştürürsünüz?

Ticket programından alınan ham veri bir başlangıçtır. Yönetim toplantısı için kayıtları nedenlerine göre ayırmak gerekir. Önce eksik veya hatalı girişleri temizleyin: kapanış zamanı olmayan iş, yanlış binaya bağlanan çağrı ya da aynı olay için açılmış iki kayıt sonucu değiştirebilir.

Ardından arızaları karar vermeyi kolaylaştıracak gruplara ayırın. Örneğin kapı kaynaklı sorunlar, elektrik beslemesiyle ilişkili olaylar, kullanıcı kaynaklı bildirimler ve sahada nedeni henüz kesinleştirilemeyen işler ayrı değerlendirilebilir. Teknik teşhis yapılmadan çağrı sırasında söylenen nedeni kesin arıza nedeni olarak raporlamayın.

Toplantı dosyasını şu sırayla hazırlamak pratiktir:

• Bir sayfalık özet: Toplam iş yükü, önceki dönemle değişim ve dikkat isteyen üç bulgu.
• Tekrar eden sorunlar: Aynı asansör veya bina grubunda kümelenen kayıtlar.
• Uzayan işler: Gecikme nedeni, mevcut durum ve sorumlu kişi.
• Ekip kapasitesi: Çağrı yoğunluğu ile ekiplerin bölge ve vardiya dağılımı.
• Karar listesi: Onay, bütçe veya görev ataması bekleyen maddeler.

Örneğin bir binada ay içinde dört kapı arızası kaydı açıldıysa toplantıda yalnızca “dört çağrı” demek yeterli değildir. Teknisyenin notlarından aynı kapıdaki tekrar eden belirtiyi, uygulanan işlemleri ve sonraki kontrol ihtiyacını çıkarın. Kayıtlar farklı belirtiler gösteriyorsa bunu da açıkça belirtin. Böylece yönetim, ek ziyaret planlanmasına mı, parça değerlendirmesine mi yoksa bina kullanım koşullarının görüşülmesine mi ihtiyaç olduğunu tartışabilir.

Asansorex gibi bir arıza takip yazılımında çağrı, saha işlemi ve kapanış bilgilerini aynı iş kaydında tutmak, bu hazırlığı kolaylaştırır. Raporun güvenilirliği yine de teknisyenin sahadaki bulguyu açık yazmasına ve kayıtların düzenli kapatılmasına bağlıdır.

Sürelerin arkasındaki operasyon sorununu bulun

Bir rapor “müdahale süresi uzadı” diyebilir; fakat tek başına nedenini söylemez. Gecikmeyi aşamalara ayırdığınızda çözüm daha görünür olur: Çağrı geç mi kaydedildi? Ekip ataması mı beklendi? Ulaşım mı uzadı? Bina erişimi mi sağlanamadı? Sahaya varıldıktan sonra parça mı beklendi?

Bu ayrım firma sahibi için gereksiz harcamayı önler. Sorun ekip atamasında yoğunlaşıyorsa yeni araç almak çözüm olmayabilir. Belirli bölgelerde yol süresi artıyorsa ekiplerin günlük güzergâhı yeniden düzenlenebilir. Sık kullanılan bir parçanın yokluğu işleri uzatıyorsa stok kararı verilebilir. Her durumda karar, birkaç dikkat çekici olaya değil, kayıtların gösterdiği örüntüye dayanmalıdır.

Açık ticket listesini ayrıca gözden geçirin. “Teknisyen gitti” bilgisi, işin çözüldüğü anlamına gelmez. Asansör kullanım dışıysa, parça bekleniyorsa veya ek ziyaret gerekiyorsa kayıt durumu bunu açıkça göstermelidir. Bina yöneticisine verilen bilgi de aynı durumla uyumlu olmalıdır. İçeride açık görünen bir işin müşteriye “tamamlandı” diye aktarılması, teknik sorunun yanında güven sorunu yaratır.

Teknisyen notlarında yalnızca “arıza giderildi” yazıyorsa bir sonraki çağrıda geçmiş kaydın yararı sınırlı kalır. Belirti, tespit, yapılan işlem ve gerekiyorsa izleme önerisi kısa fakat anlaşılır biçimde yazılmalıdır. Yönetim raporunun kalitesi, günlük kayıt alışkanlığıyla başlar.

Toplantıyı görev ve takip tarihiyle bitirin

Yönetim toplantılarının sık görülen zayıf noktası, doğru sorunun bulunup sonraki adımın belirsiz bırakılmasıdır. “Tekrar arızaları azaltalım” bir hedef cümlesidir; uygulanabilir karar değildir. Hangi asansörlerin inceleneceği, kimin inceleyeceği ve sonucun ne zaman değerlendirileceği yazılmalıdır.

Her karar için dört alan yeterlidir: sorun, yapılacak iş, sorumlu kişi ve kontrol tarihi. Örneğin “Aynı binadaki kapı arızalarının servis kayıtları teknik sorumlu tarafından incelenecek; gerekli kontrol ve malzeme ihtiyacı gelecek hafta bildirilecek” ifadesi takip edilebilir. Bir sonraki toplantıda da kararın sonucu aynı arıza kayıtları üzerinden görülebilir.

Bina yöneticisini ilgilendiren kararları iç toplantıdan sonra anlaşılır bir dille paylaşın. Teknik ekibin kesinleştirmediği bir nedeni kesin teşhis gibi sunmayın. İş uzuyorsa mevcut durum, beklenen sonraki adım ve yeniden bilgilendirme zamanı açıklanmalıdır. Bu yaklaşım, müşterinin tekrar tekrar arayarak bilgi aramasını da azaltır.

Son olarak raporu yalnızca kötü sonuçları aramak için kullanmayın. Belirli bir bölgede ilk müdahale hızlandıysa hangi ekip düzeninin işe yaradığını öğrenin. Tekrar arızası azalan binalarda yapılan işlemleri inceleyin. İşe yarayan uygulamayı tarif edebildiğinizde diğer ekiplere aktarmak mümkün olur.

Sıkça Sorulan Sorular

Yönetim toplantısında bütün arıza ticketları tek tek gösterilmeli mi?

Genellikle hayır. Yönetim önce toplam görünümü, tekrar eden sorunları, uzayan işleri ve karar gerektiren kayıtları görmelidir. Tekil ticket ayrıntıları, bir bulgunun nedenini incelemek gerektiğinde açılmalıdır.

Arıza sayısının artması bakım kalitesinin düştüğünü gösterir mi?

Tek başına göstermez. Portföy büyüklüğü, yeni devralınan binalar, çağrı kayıt disiplinindeki değişiklik ve arıza türleri birlikte değerlendirilmelidir. Aynı koşullardaki bina gruplarını karşılaştırmak daha anlamlıdır.

Tekrar arıza raporunda hangi bilgi olmalı?

Asansör ve bina bilgisi, önceki çağrının tarihi, bildirilen belirtiler, teknisyenin tespiti, yapılan işlem ve yeni çağrıyla ilişkisi yer almalıdır. İki çağrının aynı kök nedene bağlı olup olmadığı teknik incelemeyle değerlendirilmelidir.

Müdahale süresi ile çözüm süresi arasındaki fark nedir?

Müdahale süresi, bildirimin alınmasından ekibin sahaya ulaşmasına kadar geçen süreyi anlatır. Çözüm süresi ise arızanın bildirilmesinden asansörün yeniden kullanılabilir duruma gelmesine kadar geçen süredir. Firma, raporunda kullandığı kesin başlangıç ve bitiş noktalarını belirtmelidir.

Küçük bir bakım firması için bu rapor gerekli mi?

Evet. Az sayıda kayıt olduğunda rapor daha kısa hazırlanabilir. Bir sayfalık özet bile hangi binaya tekrar gidildiğini, hangi işin açık kaldığını ve gelecek hafta kimin ne yapacağını görünür kılar.

Özet

Asansör arıza ticket programı raporu, yönetim toplantısında sayı sunmak için değil, arızaların neden tekrar ettiğini ve işlerin nerede uzadığını anlamak için kullanılmalıdır. Tutarlı metrikler seçin, kayıtları teknik bağlamıyla okuyun ve her önemli bulguyu sorumlusu ile kontrol tarihi belli bir karara bağlayın. Asansorex gibi bir sistemde düzenli tutulan arıza geçmişi bu değerlendirmeye dayanak sağlar; toplantının gerçek çıktısı ise sahada uygulanıp sonraki dönemde sonucu ölçülen kararlardır.