Asansör Arıza Yönetim Programı için teknik şartname maddeleri

İÇERİK

Asansör bakım firması için arıza yönetim yazılımı satın almak yalnızca "arıza kaydı açabiliyor mu?" sorusuyla değerlendirilemez. Gerçek operasyon; çağrının alınmasından teknisyenin görevlendirilmesine, müdahale süresinden kullanılan malzemeye, tekrar arızadan müşteri bilgilendirmesine kadar birçok adımdan oluşur. Bu nedenle hazırlanacak teknik şartname, yazılımın ekran sayısını değil firmanın gerçek saha sürecini ne kadar yönetebildiğini ölçmelidir. Bu rehberde, Asansör Arıza Yönetim Programı satın alırken veya teklif toplarken teknik şartnameye eklenmesi gereken temel maddeleri ve bu maddelerin neden önemli olduğunu ele alacağız.

Teknik şartname neden özellik listesinden ibaret olmamalı?

Asansör firmalarının yaptığı yaygın hatalardan biri, teknik şartnameyi "müşteri ekleme, personel ekleme, arıza oluşturma, rapor alma" şeklinde birkaç genel özellikten oluşturmasıdır.

Bu maddelerin tamamını karşılayan iki program arasında bile operasyon açısından ciddi farklar bulunabilir.

Örneğin iki sistem de arıza kaydı oluşturabilir. Ancak birinde yalnızca müşteri adı ve açıklama girilirken diğerinde;

• Hangi asansörde arıza olduğu,
• Arızanın bildirilme saati,
• Bildirimi yapan kişi,
• Atanan teknisyen,
• Teknisyenin yola çıkış zamanı,
• Varış zamanı,
• Müdahale süresi,
• Arıza nedeni,
• Yapılan işlem,
• Kullanılan malzeme,
• Fotoğraf,
• Müşteri imzası,
• Tekrar arıza durumu

ayrı ayrı kayıt altına alınabilir.

İkinci yapı işletme açısından çok daha değerlidir. Çünkü yalnızca "arıza kapatıldı" bilgisini değil, arıza operasyonunun tamamını ölçülebilir hale getirir.

Teknik şartnamenin temel amacı da tam olarak budur: satın alınacak sistemin ne yapacağını yoruma açık bırakmadan tanımlamak.

Arıza kayıt ve çağrı yönetimi için bulunması gereken maddeler

Teknik şartnamenin ilk bölümü arızanın sisteme nasıl girdiğini tanımlamalıdır.

İyi hazırlanmış bir şartnamede şu tür maddeler bulunabilir:

1. Sistem, müşteri veya bina bazında arıza kaydı oluşturulmasına imkân sağlamalıdır.
2. Bir müşteriye birden fazla asansör bağlıysa arızanın ilgili asansör ile eşleştirilmesi mümkün olmalıdır.
3. Arıza kayıt tarihi ve saati sistem tarafından otomatik olarak saklanmalıdır.
4. Bildirimi yapan kişinin adı, telefon numarası ve açıklaması gerektiğinde kayıt altına alınabilmelidir.
5. Arızalara önem veya öncelik seviyesi atanabilmelidir.
6. Açılan arızanın durumu takip edilebilmelidir.
7. Arıza kaydının hangi kullanıcı tarafından ve hangi tarihte oluşturulduğu görülebilmelidir.
8. Arızaya ilişkin açıklama, fotoğraf ve dosya eklenebilmelidir.
9. Aynı asansöre ait geçmiş arızalara ulaşılabilmelidir.

Burada özellikle asansör bazlı geçmiş önemlidir.

Bir teknisyen aynı binaya üçüncü kez gittiğinde yalnızca mevcut çağrı açıklamasını değil, daha önce aynı cihazda hangi sorunların yaşandığını da görebilmelidir.

Örneğin son üç ayda aynı asansörde dört kez kapı kilidi arızası oluşmuşsa bu bilgi artık tekil bir servis kaydı değil, teknik bir problem göstergesidir.

Teknisyen görevlendirme ve saha operasyonu şartları

Arıza yönetim sisteminin esas değeri masa başında değil, teknisyen sahaya çıktığında ortaya çıkar.

Bu nedenle teknik şartnamede mobil kullanım ayrı bir bölüm olarak değerlendirilmelidir.

Teknik şartname maddesi	Neden önemlidir?
Teknisyene arıza atama	Hangi çağrıdan kimin sorumlu olduğunu netleştirir
Mobil cihazdan arıza görüntüleme	Teknisyenin sürekli ofisi aramasını azaltır
Yol/varış durumlarının kaydı	Müdahale süresinin ölçülmesini sağlar
Fotoğraf ekleme	Yapılan işlemin belgelenmesine yardımcı olur
İşlem açıklaması	Teknik geçmiş oluşturur
Kullanılan malzeme kaydı	Maliyet ve stok analizine veri sağlar
Müşteri imzası	Servis işleminin teslim kaydını güçlendirir
Arıza kapatma nedeni	Raporlamanın standart hale gelmesini sağlar
Geçmiş arızaları görüntüleme	Tekrar eden problemlerin teşhisini kolaylaştırır

Şartnamede yalnızca "mobil uygulaması olmalıdır" yazılması yeterli değildir.

Mobil uygulamanın teknisyenin hangi işlemleri gerçekleştirmesine izin vereceği açıkça belirtilmelidir.

Örneğin:

Teknisyen, kendisine atanan arıza kaydını mobil cihaz üzerinden görüntüleyebilmeli; yapılan işlemi, kullanılan malzemeyi, servis açıklamasını, fotoğrafı ve gerektiğinde müşteri imzasını kaydedebilmelidir.

Bu şekilde yazılan madde hem teklif veren firmalar arasında karşılaştırmayı kolaylaştırır hem de teslim aşamasında "biz bunu farklı anlamıştık" sorununu azaltır.

Müdahale süresi ve arıza performansı ölçülmeli

Bir arıza programının en önemli avantajlarından biri servis performansını sayısal hale getirmesidir.

Bunun için sistemin yalnızca açılış ve kapanış tarihini değil, mümkünse operasyonun ara aşamalarını da kaydetmesi gerekir.

Örneğin:

Arıza bildirimi → Atama → Yola çıkış → Varış → Müdahale → Tamamlama

Bu zaman noktaları kayıt altına alındığında firma birçok önemli soruya cevap verebilir:

• Ortalama teknisyen atama süresi kaç dakika?
• Arıza bildirildikten sonra sahaya ortalama kaç dakikada ulaşılıyor?
• Bir arızanın çözülmesi ortalama ne kadar sürüyor?
• Hangi teknisyenlerde müdahale süreleri yükseliyor?
• Hangi bölgelerde ulaşım süresi fazla?
• Hangi müşterilerde arıza sayısı normalin üzerinde?
• Hangi asansörler sık tekrar arıza oluşturuyor?

Teknik şartnameye bu nedenle şu tarz bir madde eklenebilir:

Sistem, arızanın oluşturulma, teknisyene atanma, müdahale ve sonuçlandırılma zamanlarını kayıt altına alabilmeli ve bu veriler üzerinden süre bazlı raporlama yapılabilmelidir.

Bu kayıtların düzenli tutulması, özellikle yüzlerce asansöre hizmet veren firmalarda operasyon planlamasını ciddi biçimde kolaylaştırır.

Tekrar arızaların tespiti şartnamede ayrıca tanımlanmalı

Asansör servis işletmelerinde en pahalı problemlerden biri aynı cihaz için kısa aralıklarla tekrar servis çıkılmasıdır.

İlk müdahale sırasında sorun kalıcı olarak çözülmediyse firma ikinci kez personel zamanı, araç, yakıt ve iş gücü harcar.

Bu nedenle teknik şartnamede geçmiş arıza kayıtlarının analiz edilebilir olması istenmelidir.

Örneğin sistem;

• Aynı asansördeki arıza sayısını,
• Belirli dönem içindeki tekrar çağrıları,
• Arıza nedenlerini,
• Değiştirilen parçaları,
• Müdahale eden teknisyenleri

karşılaştırılabilir şekilde gösterebilmelidir.

Şartname maddesi şu şekilde oluşturulabilir:

Sistem, asansör bazında geçmiş arıza kayıtlarının tarih, arıza nedeni, yapılan işlem, teknisyen ve kullanılan malzeme bilgileriyle görüntülenmesine imkân sağlamalıdır.

Daha gelişmiş bir değerlendirmede tekrar arıza raporları da ayrıca istenebilir.

Örneğin 30 gün içerisinde aynı cihazdan gelen ikinci arıza, operasyon sorumlusu tarafından ayrıca incelenebilir.

Böylece yalnızca arıza sayısı değil, servis kalitesi de ölçülmeye başlanır.

Müşteri ve bina yöneticisi bilgilendirmesi unutulmamalı

Bir asansör arızasında yalnızca teknik operasyon yaşanmaz. Aynı zamanda ciddi bir iletişim süreci vardır.

Bina yöneticisi çoğu zaman şu soruların cevabını öğrenmek ister:

• Arıza kaydım oluşturuldu mu?
• Teknisyen geliyor mu?
• Kim geliyor?
• Sorun çözüldü mü?
• Hangi işlem yapıldı?
• Parça değişti mi?

Firma bu bilgileri düzenli sunamazsa teknik müdahale hızlı yapılmış olsa bile müşteri deneyimi zayıflayabilir.

Bu nedenle teknik şartnamede müşteri bilgilendirme yetenekleri de değerlendirilmelidir.

Örneğin programın yapısına göre SMS, bildirim veya müşteri portalı üzerinden durum paylaşımı yapılabilir.

Şartnameye aşağıdaki gibi bir madde eklenebilir:

Sistem, arıza sürecinin durum bilgilerinin yetkilendirme kapsamında müşteri veya bina yöneticisi ile paylaşılmasına uygun olmalıdır.

Burada önemli nokta, müşterinin firmanın bütün operasyonunu değil, yalnızca kendisini ilgilendiren kayıtları görebilmesidir.

Yetkilendirme ve veri güvenliği maddeleri

Arıza sistemlerinde müşteri bilgileri, telefon numaraları, adresler, teknik kayıtlar ve personel bilgileri tutulabilir.

Dolayısıyla kullanıcı yetkileri teknik şartnamenin önemli bölümlerinden biri olmalıdır.

Genel uygulamada aşağıdaki ayrımlar değerlendirilebilir:

• Firma yöneticisi tüm operasyonu görebilir.
• Operasyon sorumlusu arızaları oluşturabilir ve personele atayabilir.
• Teknisyen yalnızca kendisine verilen işleri görebilir.
• Müşteri yalnızca kendi binalarına ait izin verilen kayıtları görebilir.
• Finansal veya ticari verilere erişim ayrıca sınırlandırılabilir.

Ayrıca şartnamede veri yedekleme, kullanıcı işlem geçmişi ve erişim güvenliği gibi konular da sorgulanmalıdır.

Burada amaç yalnızca siber güvenlik değil, operasyonel hataların geriye dönük araştırılabilmesidir.

Örneğin bir arızanın açıklaması değiştirildiyse mümkün olduğunca bu işlemin kim tarafından gerçekleştirildiğinin izlenebilmesi işletme açısından değerlidir.

Bakım ve periyodik kontrol süreçleriyle ilişki kurulmalı

Arıza yönetiminin bakım geçmişinden tamamen bağımsız tutulması önemli bir veri kaybına neden olabilir.

Teknisyen bir arızaya gittiğinde cihazın;

• Son bakım tarihini,
• Önceki arızalarını,
• Yapılan parça değişimlerini,
• Teknik notlarını,
• Varsa periyodik kontrol sonuçlarını

aynı cihaz geçmişi içerisinde değerlendirebilmesi faydalıdır.

Türkiye'de asansörlerin periyodik kontrolleri yılda en az bir kez yetkilendirilmiş A Tipi Muayene Kuruluşları tarafından gerçekleştirilmektedir. Kontrol sonucunda asansörler yeşil, mavi, sarı veya kırmızı bilgi etiketi ile sınıflandırılmaktadır.

Bakanlık açıklamasında yeşil etiket kusursuz, mavi hafif kusurlu, sarı kusurlu ve kırmızı güvensiz durum için kullanılmaktadır.

Dolayısıyla arıza yazılımı seçilirken cihaz geçmişinin bakım ve diğer teknik kayıtlarla birlikte değerlendirilebilmesi önemli bir avantajdır.

TS EN 81-20 ve TS EN 81-50 de asansör sektöründe kullanılan temel güvenlik standartları arasında yer almaktadır. TSE'nin asansör muayene elemanı eğitim içeriğinde de bu standartlar ilgili asansör mevzuatı ve kontrol süreçleriyle birlikte yer almaktadır.

Ancak yazılımın görevi teknik uygunluk değerlendirmesi yapmak değildir. Programın görevi, firmanın gerçekleştirdiği bakım, arıza ve servis faaliyetlerinin düzenli kayıt altına alınmasını ve gerektiğinde hızlı biçimde erişilmesini sağlamaktır.

Raporlama için teknik şartname maddeleri

"Raporlama vardır" maddesi tek başına yeterli değildir. Hangi raporların alınacağı belirtilmelidir.

Asgari olarak şu raporlar değerlendirilebilir:

• Tarih aralığına göre toplam arıza sayısı,
• Müşteri bazında arıza sayısı,
• Asansör bazında arıza geçmişi,
• Teknisyen bazında tamamlanan işler,
• Ortalama müdahale süresi,
• Açık ve kapanmış arızalar,
• Arıza nedenleri,
• Tekrar arıza sayıları,
• Kullanılan malzemeler,
• Bölge veya ekip bazlı servis yoğunluğu.

Firma sahibi açısından özellikle müşteri ve cihaz bazlı analiz önemlidir.

Örneğin 300 asansörlük portföyde bir müşterinin 10 cihazı bulunuyorsa ve bu 10 cihaz toplam arızaların yüzde 20'sini oluşturuyorsa durum ayrıca incelenmelidir.

Belki ekipman ekonomik ömrünü doldurmuştur. Belki belirli bir komponent sürekli sorun çıkarıyordur. Belki bakım kalitesi düşüktür.

Doğru kayıt olmadan bu değerlendirmeler çoğu zaman kişisel gözleme dayanır.

Entegrasyon ve veri aktarımı şartları

Yazılım satın alırken yalnızca bugünkü ihtiyacı değil birkaç yıl sonraki işletme yapısını da düşünmek gerekir.

Firma büyüdükçe muhasebe, e-fatura, SMS, CRM veya farklı kurumsal sistemlerle veri alışverişi ihtiyacı ortaya çıkabilir.

Bu nedenle şartnamede gerektiğinde entegrasyon imkânlarının nasıl sağlanacağı sorulmalıdır.

Ancak her entegrasyonu ilk günden zorunlu tutmak da gereksiz maliyet oluşturabilir.

Daha sağlıklı yaklaşım:

1. Bugün kesin gerekli entegrasyonları belirlemek.
2. Yakın gelecekte ihtiyaç oluşabilecek sistemleri listelemek.
3. Veri dışa aktarım seçeneklerini kontrol etmek.
4. Entegrasyonların ek ücretli olup olmadığını teklif aşamasında öğrenmek.
5. Verilerin hangi formatlarda alınabileceğini netleştirmek.

Özellikle sistem değiştirme ihtimalinde firmanın kendi kayıtlarını dışarı aktarabilmesi önemlidir.

Teknik şartnamede şu tarz bir hüküm kullanılabilir:

Sistem, yetkili kullanıcıların operasyon kayıtlarını yaygın dosya formatlarında dışa aktarabilmesine imkân sağlamalıdır.

Örnek teknik şartname kontrol listesi

Bir satın alma dosyasında aşağıdaki yapı başlangıç noktası olarak kullanılabilir:

Konu	Şartnamede aranabilecek özellik
Arıza kaydı	Müşteri, bina ve asansör bazlı kayıt
Atama	Teknisyen veya ekip görevlendirme
Mobil kullanım	Sahadan işlem ve sonuç girişi
Zaman kaydı	Bildirim, atama, müdahale ve kapanış zamanı
Teknik geçmiş	Asansör bazlı geçmiş arızalar
Belgeleme	Fotoğraf, açıklama ve gerektiğinde imza
Malzeme	Kullanılan parça veya malzeme kaydı
Tekrar arıza	Cihaz bazında geçmiş karşılaştırması
Raporlama	Firma, müşteri, cihaz ve teknisyen raporları
Yetkilendirme	Kullanıcı rolüne göre erişim
Müşteri erişimi	Yetkili müşterinin kendi kayıtlarını görebilmesi
Veri aktarımı	Kayıtların dışarı alınabilmesi
Entegrasyon	Gerektiğinde diğer sistemlerle bağlantı imkânı
Destek	Eğitim ve teknik destek sürecinin tanımlanması

Asansorex gibi asansör sektörüne özel geliştirilmiş bakım ve arıza yönetim yazılımlarında bu süreçlerin bakım, müşteri, asansör ve saha operasyonuyla aynı sistem üzerinden yürütülmesi mümkün olduğundan, teknik şartname hazırlanırken modüllerin birbirleriyle nasıl çalıştığını da incelemek faydalıdır.

Yazılım demosunda şartname nasıl test edilmeli?

Şartname hazırlandıktan sonra yalnızca satıcıya gönderip "karşılıyor" cevabı almak yeterli değildir.

Mümkünse gerçek bir arıza senaryosu üzerinden demo yapılmalıdır.

Örneğin:

1. Örnek bir müşteri ve bina seçin.
2. Binadaki belirli bir asansör için arıza kaydı açın.
3. Teknisyen görevlendirin.
4. Teknisyenin telefonunda kaydın nasıl göründüğünü inceleyin.
5. Sahadan fotoğraf ve işlem açıklaması ekleyin.
6. Arızayı sonuçlandırın.
7. Aynı cihazın geçmiş kayıtlarına ulaşın.
8. İşlemin raporlara nasıl yansıdığını kontrol edin.

Bu test sırasında özellikle işlem sayısına dikkat edilmelidir.

Bir arızayı kapatmak için teknisyenin on farklı ekran dolaşması gerekiyorsa özellik teknik olarak mevcut olsa bile sahada kullanımı zor olabilir.

İyi sistem yalnızca çok özellikli değil, teknisyenin yoğun çalışma temposunda kolay kullanılabilecek kadar sade olmalıdır.

Sıkça Sorulan Sorular

Asansör Arıza Yönetim Programı teknik şartnamesinde en önemli madde nedir?

Tek bir madde seçmek doğru olmaz ancak asansör bazlı arıza geçmişinin tutulması, teknisyen görevlendirme, mobil saha kullanımı ve müdahale sürelerinin kayıt altına alınması temel gereksinimler arasında olmalıdır.

Teknik şartnamede mobil uygulama zorunlu olmalı mı?

Sahada çalışan ekip bulunan bir asansör bakım firması için mobil kullanım ciddi avantaj sağlar. Teknisyenin arızayı telefonundan görmesi ve sonucu sahadan girmesi, ofis ile yapılan telefon ve mesaj trafiğini azaltabilir.

Tekrar arıza raporu neden önemlidir?

Aynı asansöre kısa sürede tekrar servis gönderilmesi işçilik, araç ve zaman maliyetini artırır. Tekrar arızaların ölçülmesi, kronik cihaz problemlerini veya ilk müdahalede çözülemeyen sorunları tespit etmeye yardımcı olur.

Arıza yönetim programı periyodik kontrolün yerine geçer mi?

Hayır. Periyodik kontrol, yetkilendirilmiş A Tipi Muayene Kuruluşlarının gerçekleştirdiği ayrı bir süreçtir. Yazılım ise bakım ve servis firmasının operasyon kayıtlarını düzenli şekilde yönetmesine yardımcı olur. Türkiye'de periyodik kontrollerin yılda en az bir defa yaptırılması gerekmektedir.

Teknik şartnameye entegrasyon maddesi eklenmeli mi?

Firmanın bugün veya gelecekte muhasebe, e-fatura, SMS veya başka kurumsal sistemlerle bağlantı ihtiyacı olacaksa entegrasyon imkânları mutlaka sorgulanmalıdır. Ancak kullanılmayacak entegrasyonları zorunlu hale getirmek gereksiz maliyet yaratabilir.

Hazır şartnameyi doğrudan kullanmak doğru mudur?

Hazır bir metin başlangıç noktası olarak kullanılabilir ancak firmanın teknisyen sayısı, servis bölgesi, müşteri yapısı, cihaz sayısı ve mevcut iş akışına göre uyarlanmalıdır. En doğru şartname, firmanın gerçek operasyonunu tarif eden şartnamedir.

Özet

Asansör Arıza Yönetim Programı için teknik şartname hazırlanırken amaç mümkün olduğunca uzun bir özellik listesi oluşturmak değil, arıza operasyonunun başından sonuna kadar nasıl yönetileceğini tanımlamaktır. Arıza kaydı, asansör bazlı geçmiş, teknisyen atama, mobil saha kullanımı, müdahale süreleri, fotoğraf ve işlem kayıtları, tekrar arıza analizi, müşteri bilgilendirmesi, yetkilendirme ve raporlama temel değerlendirme alanlarıdır.

Satın alma kararından önce bu maddelerin gerçek bir servis senaryosuyla test edilmesi, kâğıt üzerinde güçlü görünen ancak sahada kullanılması zor sistemleri elemenin en etkili yollarından biridir. Asansorex gibi asansör bakım ve arıza süreçlerini aynı yapı altında yöneten sektörel çözümler değerlendirilirken de yalnızca özelliklerin varlığına değil, teknisyenin ve ofis ekibinin bu özellikleri günlük iş akışında ne kadar kolay kullanabildiğine bakılmalıdır.