Asansör Arıza Takip Programı için Teknik Şartname Maddeleri
Asansör Arıza Takip Programı satın alırken teknik şartname nasıl hazırlanmalı? Arıza kaydı, teknisyen atama, saha kullanımı, veri güvenliği, raporlama ve hizmet sürekliliği için kritik maddeleri inceleyin.
İÇERİK
Bir Asansör Arıza Takip Programı satın alırken yalnızca ekran görüntülerine, demo sunumuna veya fiyat teklifine bakmak yeterli değildir. Programın gerçek saha koşullarında nasıl çalışacağını belirleyen esas belge teknik şartnamedir. Doğru hazırlanmış bir şartname; arızanın kayıt altına alınmasından teknisyen atamasına, müdahale süresinin ölçülmesinden veri güvenliğine kadar firmanın ihtiyaçlarını net biçimde tanımlar. Böylece satın alma sonrasında “Bu özellik var sanıyorduk”, “Bu raporu alamıyoruz” veya “Teknisyen internetsizken işlem yapamıyor” gibi sorunların önüne geçilebilir.
Bu rehberde asansör bakım firmalarının, satın alma sorumlularının ve yöneticilerin bir arıza takip yazılımı için teknik şartname hazırlarken hangi maddeleri mutlaka değerlendirmesi gerektiğini örneklerle ele alıyoruz.
Teknik Şartname Neden Özellik Listesinden Daha Fazlasıdır?
Birçok firma şartname hazırlarken “arıza kaydı açılacak, teknisyen atanacak, rapor alınacak” şeklinde birkaç genel madde yazar. Ancak bu tanımlar yazılımın sahada nasıl çalışacağını belirlemek için yeterli değildir.
Örneğin iki farklı program da “arıza kaydı” özelliğine sahip olabilir. Birinde yalnızca bina adı ve açıklama girilirken diğerinde şu bilgiler tutulabilir:
- Arıza bildirim tarihi ve saati
- Bildirimi yapan kişi
- Bina ve asansör bilgisi
- Arıza türü
- Öncelik seviyesi
- Atanan teknisyen
- Teknisyenin yola çıkış zamanı
- Müdahale başlangıç ve bitiş zamanı
- Kullanılan malzemeler
- Yapılan işlem açıklaması
- Fotoğraf veya servis belgesi
- Arızanın tekrar edip etmediği
- İşin kapanış durumu
Bu nedenle teknik şartname, yalnızca hangi özelliklerin bulunacağını değil, özelliğin nasıl çalışacağını da tarif etmelidir.
Özellikle yüzlerce asansöre bakım veren firmalarda küçük bir şartname eksikliği, birkaç ay sonra binlerce eksik veya karşılaştırılamayan servis kaydına dönüşebilir.
Arıza Kaydı ve İş Emri İçin Temel Şartname Maddeleri
Şartnamenin ilk bölümü arızanın sisteme girdiği andan kapanışına kadar olan süreci tanımlamalıdır.
Örnek bir madde şöyle yazılabilir:
Sistem, arıza bildirimlerinin bina ve ilgili asansör ile ilişkilendirilerek tarih, saat, bildiren kişi, açıklama ve iletişim bilgileriyle kayıt altına alınmasına imkân sağlamalıdır.
Ardından iş emri süreci detaylandırılmalıdır.
Teknisyen ataması
Programda arızanın belirli bir teknisyene veya servis ekibine atanabilmesi şartnamede açıkça belirtilmelidir.
Atama kaydında en azından:
- Atama tarihi
- Atanan personel
- Arıza önceliği
- İş durumu
- Açıklama
bilgilerinin tutulması faydalıdır.
Firma operasyonuna göre teknisyenin kendisine atanan işi mobil cihazından görmesi de ayrıca şart koşulabilir.
Durum aşamaları
Sadece “açık” ve “kapalı” seçeneklerinden oluşan bir yapı çoğu firma için yetersiz kalır.
Örneğin süreç şu durumlarla takip edilebilir:
Yeni Arıza → Atandı → Yola Çıkıldı → Müdahale Ediliyor → Parça Bekleniyor → Tamamlandı
Buradaki amaç, ofisteki servis sorumlusunun teknisyeni sürekli telefonla aramak zorunda kalmadan işin hangi aşamada olduğunu görebilmesidir.
Kapanış kayıtları
Bir arızanın kapatılabilmesi için yapılan işlemin kaydedilmesi istenmelidir. Gerekiyorsa fotoğraf, açıklama, müşteri imzası veya kullanılan parça gibi bilgiler de şartnameye eklenebilir.
Mobil Kullanım ve Saha Koşulları Nasıl Tanımlanmalı?
Asansör servis yazılımının en kritik noktalarından biri mobil kullanımdır. Çünkü arıza kaydının asıl üretildiği yer çoğu zaman ofis değil sahadır.
Teknik şartnamede yalnızca “mobil uygulaması bulunmalıdır” demek yeterli olmaz.
| Kontrol Noktası | Şartnamede Aranabilecek Gereksinim |
|---|---|
| Mobil erişim | Teknisyen kendisine atanan işleri telefondan görebilmeli |
| İşlem kaydı | Yapılan müdahaleyi sahadan kaydedebilmeli |
| Fotoğraf | Arıza veya işlem fotoğrafı eklenebilmeli |
| Konum/zaman | Gerekiyorsa işlem zamanı kayıt altına alınabilmeli |
| İmza | Servis tamamlandığında müşteri onayı alınabilmeli |
| İnternet sorunu | Saha koşullarına uygun çalışma yöntemi bulunmalı |
| Bildirim | Yeni görev teknisyene hızlı şekilde iletilebilmeli |
| Geçmiş kayıt | Yetkisine göre önceki arızaları inceleyebilmeli |
Özellikle bodrum kat, makine dairesi ve mobil internetin zayıf olduğu bölgelerde çalışan ekipler için bağlantı kesildiğinde kayıt kaybının nasıl önleneceği satın alma öncesinde sorulmalıdır.
Şartnameye örneğin şu ifade eklenebilir:
Mobil uygulama, saha personelinin arıza iş emrine ilişkin açıklama, fotoğraf ve işlem bilgilerini kolay şekilde kaydetmesine uygun olmalıdır. Bağlantı problemi yaşanan saha koşullarında veri kaybını önleyecek yöntem sunulmalıdır.
Burada önemli olan teknoloji adına karar vermekten çok operasyonel ihtiyacı tarif etmektir.
Yetkilendirme, Veri Güvenliği ve Kayıt Geçmişi
Arıza takip programında müşteri adresleri, telefon numaraları, servis kayıtları, bina bilgileri ve personel faaliyetleri gibi önemli işletme verileri tutulabilir. Bu nedenle teknik şartnamenin güvenlik bölümü birkaç genel cümleyle geçilmemelidir.
Kullanıcı yetkileri
Her çalışanın tüm bilgilere erişmesi gerekmeyebilir.
Örneğin:
- Firma sahibi genel raporları görebilir.
- Servis sorumlusu arıza ataması yapabilir.
- Teknisyen yalnızca kendisine verilen işleri görebilir.
- Muhasebe personeli teknik müdahale detaylarını değiştiremeyebilir.
- Şube yapısı bulunan firmalarda erişimler şubeye göre sınırlandırılabilir.
Bu nedenle şartnameye rol ve yetkilendirme mekanizması açıkça yazılmalıdır.
İşlem geçmişi
Özellikle arızanın ne zaman açıldığı, kime atandığı ve ne zaman kapatıldığı gibi kritik bilgilerin sonradan izlenebilmesi gerekir.
İyi bir şartname şu soruya cevap vermelidir:
“Üç ay sonra bu arıza kaydında kimin ne işlem yaptığını görebilecek miyiz?”
İşlem geçmişinin korunması hem firma içi kontrolü kolaylaştırır hem de müşteriyle yaşanabilecek hizmet süresi tartışmalarında daha sağlıklı kayıt sunar.
Veri yedekleme ve dışa aktarım
Satın alma öncesinde mutlaka şu konular netleştirilmelidir:
- Veriler düzenli olarak yedekleniyor mu?
- Yedekleme yöntemi nedir?
- Kullanıcı kendi verilerini dışa aktarabiliyor mu?
- Hizmet sonlandırılırsa firma kayıtlarını hangi formatta alabiliyor?
- Veri kaybı yaşanması durumunda geri yükleme süreci nasıl işliyor?
Özellikle uzun süre kullanılacak kurumsal sistemlerde verinin kime ait olduğu ve nasıl alınabileceği sözleşme ve teknik şartnamede belirsiz bırakılmamalıdır.
Raporlama ve Performans Ölçümü Maddeleri
Arıza takip yazılımının değeri yalnızca kayıt toplamaktan gelmez. Toplanan kayıtların anlamlı raporlara dönüşebilmesi gerekir.
Teknik şartnamede ihtiyaç duyulan raporlar isimleriyle belirtilmelidir.
Örneğin:
- Tarih aralığına göre arıza raporu
- Bina bazlı arıza sayısı
- Asansör bazlı arıza geçmişi
- Teknisyen bazlı iş sayısı
- Ortalama müdahale süresi
- Ortalama çözüm süresi
- Tekrar eden arızalar
- Açık ve kapanmış iş emirleri
- Arıza türlerine göre dağılım
- Kullanılan parça veya malzeme kayıtları
Özellikle tekrar arıza analizi önemlidir. Aynı asansör bir ay içinde dört kez aynı nedenle duruyorsa yalnızca dört ayrı servis kaydı görmek yeterli değildir. Yönetici bu kayıtların aynı bina veya ekipman üzerinde tekrar ettiğini fark edebilmelidir.
Bu noktada şartnameye şu tür bir gereksinim eklenebilir:
Sistem, aynı asansöre ait geçmiş arıza kayıtlarının tarihsel olarak görüntülenmesine ve tarih, bina, asansör, personel veya arıza durumu gibi kriterlere göre raporlanmasına imkân sağlamalıdır.
Asansorex gibi asansör sektörüne yönelik bakım ve arıza takip yazılımlarında kayıtların bina ve asansör geçmişiyle birlikte tutulması, servis sorumlusunun geçmiş müdahalelere hızlı ulaşmasını kolaylaştırabilir.
Mevzuat ve Periyodik Kontrol Kayıtlarıyla Karıştırılmaması Gereken Nokta
Arıza takip programı önemli bir işletme aracıdır ancak yazılım kaydı, mevzuat kapsamında yapılması gereken bakım veya periyodik kontrolün yerine geçmez.
Asansör İşletme ve Bakım Yönetmeliği 6 Nisan 2019 tarihli ve 30737 sayılı Resmî Gazete'de yayımlanmıştır. ([Türkiye Belediyeler Birliği][1]) Ayrıca Sanayi ve Teknoloji Bakanlığının güncel bilgilendirmesine göre sürekli kullanılan asansörlerin periyodik kontrollerinin yılda en az bir kez yaptırılması zorunludur ve kontrol sonucunda A tipi muayene kuruluşları tarafından yeşil, mavi, sarı veya kırmızı bilgi etiketi uygulanır. ([Sanayi Bakanlığı][2])
Dolayısıyla teknik şartnamede arıza kayıtlarıyla periyodik kontrol süreçlerinin birbirine karıştırılmaması gerekir.
Programın periyodik kontrol raporlarını veya ilgili dokümanları saklaması isteniyorsa bu ayrıca yazılabilir. Ancak yazılım üreticisinin mevzuat kapsamında A tipi muayene kuruluşunun görevini yerine getirdiği şeklinde bir tanım kullanılmamalıdır.
TS EN 81-20/50 gibi standartlar da asansörlerin tasarım ve güvenlik gerekleri açısından önemlidir; bunlar doğrudan bir arıza takip yazılımının teknik yazılım standardı olarak değerlendirilmemelidir.
Satın Alma Öncesi Teknik Şartname Kontrol Listesi
Şartname tamamlandıktan sonra aşağıdaki başlıklar tek tek kontrol edilmelidir:
- Arıza bildiriminin nasıl oluşturulacağı tanımlandı mı?
- Arıza mutlaka bina ve asansörle ilişkilendiriliyor mu?
- Teknisyen veya ekip ataması belirtilmiş mi?
- Müdahale başlangıç ve bitiş zamanları takip edilebiliyor mu?
- Arızanın farklı durum aşamaları bulunuyor mu?
- Teknisyen mobil cihazdan işlem yapabiliyor mu?
- Fotoğraf ve açıklama eklenebiliyor mu?
- Arıza geçmişi sonradan görüntülenebiliyor mu?
- Tekrar eden arızalar analiz edilebiliyor mu?
- Kullanıcı yetkileri tanımlanabiliyor mu?
- Kritik işlemlerin geçmişi tutuluyor mu?
- Verilerin nasıl yedeklendiği açıklanmış mı?
- Veriler gerektiğinde dışa aktarılabiliyor mu?
- Firma, bina, asansör ve teknisyen bazlı rapor alınabiliyor mu?
- Destek ve hizmet sürekliliği koşulları sözleşmede tanımlanmış mı?
Bir şartname bu soruların büyük bölümüne açık cevap veriyorsa satın alma sonrası sürpriz yaşama ihtimali ciddi şekilde azalır.
Buna karşılık “sistem modern olmalıdır”, “kullanıcı dostu olmalıdır” veya “güvenli olmalıdır” gibi ölçülemeyen ifadeler tek başına yeterli değildir. Mümkün olduğunca kontrol edilebilir ve demo sırasında test edilebilir maddeler yazılmalıdır.
Sıkça Sorulan Sorular
Asansör Arıza Takip Programı teknik şartnamesinde en önemli madde nedir?
Tek bir madde seçmek doğru olmaz. Ancak arızanın açılışından kapanışına kadar tüm sürecin kayıt altına alınması, teknisyen ataması, işlem geçmişi ve veri erişimi temel gereksinimler arasında yer alır.
Şartnamede mobil uygulama zorunlu tutulmalı mı?
Saha ekibi bulunan asansör bakım firmalarında mobil erişim büyük avantaj sağlar. Teknisyenin arıza bilgilerini ofisten telefonla istemesi yerine kendisine atanan işi mobil cihazından görmesi ve yaptığı işlemi sahadan kaydetmesi operasyonu hızlandırır.
İnternetsiz çalışma şartnameye yazılmalı mı?
Firma bodrum, kırsal bölge veya bağlantının zayıf olduğu yapılarda sık çalışıyorsa bu konu mutlaka değerlendirilmelidir. Tam çevrimdışı çalışma zorunlu tutulacaksa hangi işlemlerin internetsiz yapılacağı açıkça belirtilmelidir.
Teknik şartnamede veri dışa aktarımı neden önemlidir?
Yıllar boyunca oluşan bina, asansör ve arıza geçmişi firmanın önemli operasyonel verisidir. Yazılım değişikliği veya sözleşmenin sona ermesi durumunda bu kayıtların erişilebilir olması gerekir. Bu nedenle dışa aktarım koşulları satın alma öncesinde netleştirilmelidir.
Arıza programı periyodik kontrol kayıtlarının yerine geçer mi?
Hayır. Arıza takip sistemi servis operasyonunun kayıt ve yönetim aracıdır. Mevzuat kapsamında yapılması gereken bakım, periyodik kontrol ve ilgili tarafların yükümlülükleri ayrıca devam eder.
Teknik şartname hazırlarken marka adı yazılmalı mı?
Özellikle birden fazla tedarikçinin değerlendirileceği satın almalarda şartnamenin marka yerine ihtiyaç ve performans kriterlerini tarif etmesi daha sağlıklı olur. Böylece farklı sistemler aynı gereksinimler üzerinden karşılaştırılabilir.
Özet
İyi hazırlanmış bir Asansör Arıza Takip Programı teknik şartnamesi, satın alınacak yazılımın yalnızca bugünkü ihtiyaçları değil, birkaç yıl sonra oluşacak veri ve operasyon yükünü de karşılamasını hedeflemelidir. Arıza kaydı, teknisyen ataması, mobil kullanım, müdahale zamanları, işlem geçmişi, yetkilendirme, veri yedekleme, dışa aktarım ve raporlama başlıkları şartnamenin temelini oluşturmalıdır.
En doğru yöntem, her maddeyi “Bu özelliğin var olduğu nasıl test edilecek?” sorusuyla kontrol etmektir. Asansorex gibi sektöre özel çözümler değerlendirilirken de demo sırasında firmanın gerçek bir arıza senaryosu üzerinden kayıt açması, teknisyene yönlendirmesi ve sonuç raporunu incelemesi; yalnızca sunum üzerinden karar vermekten çok daha sağlıklı bir değerlendirme sağlar.