Asansör Arıza Yazılımı İçin Teknik Şartname Maddeleri

İÇERİK

Asansör arızalarını telefon görüşmeleri, mesajlaşma grupları ve kâğıt formlarla yönetmek; kayıt kaybı, geç müdahale, yanlış teknisyen ataması ve eksik raporlama gibi sorunlara yol açabilir. Bu nedenle yazılım satın alırken yalnızca özellik listesini incelemek yeterli değildir. Firma, kendi çalışma düzenini ve ölçmek istediği hizmet seviyesini açık teknik şartname maddelerine dönüştürmelidir.

İyi hazırlanmış bir Asansör Arıza Yazılımı teknik şartnamesi, farklı ürünlerin aynı ölçütlerle değerlendirilmesini sağlar. Ayrıca satın alma sonrasında “Bu özellik pakete dâhil değildi” veya “Mobil uygulama internetsiz çalışmıyor” gibi anlaşmazlıkları azaltır. Bu rehberde asansör bakım firmalarının iş emri yönetiminden veri güvenliğine, bina yöneticilerinin bilgilendirilmesinden teknik destek koşullarına kadar şartnamede bulunması gereken temel maddeleri bulabilirsiniz.

Teknik Şartname Hazırlanmadan Önce İhtiyaçlar Belirlenmeli

Şartname hazırlama süreci doğrudan özellik yazmakla başlamamalıdır. Önce firmanın mevcut arıza yönetim akışı çıkarılmalıdır. Bir arıza ihbarının hangi kanaldan geldiği, kimin tarafından kaydedildiği, teknisyenin nasıl seçildiği ve işin nasıl kapatıldığı belirlenmelidir.

İhtiyaç analizi sırasında şu sorulara cevap verilmelidir:

1. Firma kaç asansöre ve kaç farklı bölgede hizmet veriyor?
2. Günlük ve aylık ortalama kaç arıza kaydı açılıyor?
3. Gece ve hafta sonu nöbet sistemi bulunuyor mu?
4. Arızalar telefon, QR kod, müşteri portalı veya çağrı merkezi üzerinden mi alınıyor?
5. Teknisyenlerin sürekli internet erişimi var mı?
6. Bina yöneticisine hangi aşamalarda bilgi verilmesi gerekiyor?
7. Kullanılan muhasebe, SMS, e-posta veya çağrı merkezi sistemleriyle entegrasyon isteniyor mu?
8. Tekrar arızalar ve müdahale süreleri hangi ölçütlerle takip edilecek?
9. Şube, ekip ve yetki ayrımı gerekiyor mu?
10. Mevcut müşteri, asansör ve geçmiş arıza kayıtları yeni sisteme aktarılacak mı?

Bu çalışma yapılmadan hazırlanan şartnameler genellikle çok sayıda özellik içerir ancak firmanın günlük sorunlarını çözmez. Örneğin yüzlerce asansörü olan bir firma için otomatik teknisyen atama önemliyken daha küçük bir işletme için kolay mobil kullanım ve hızlı arıza kaydı öncelikli olabilir.

Arıza Kaydı ve İş Emri Yönetimi Maddeleri

Yazılımın temel görevi, arıza ihbarını izlenebilir bir iş emrine dönüştürmektir. Şartname bu süreci yoruma açık bırakmayacak şekilde tanımlamalıdır.

Arıza kaydı oluşturma

Şartnameye aşağıdaki maddeler eklenebilir:

• Sistem; telefonla alınan ihbarın ofis personeli tarafından manuel olarak kaydedilmesine izin vermelidir.
• Yetkilendirilmiş bina yöneticisi veya müşteri, kendisine tanımlanan portal üzerinden arıza bildirimi oluşturabilmelidir.
• Her arıza kaydına sistem tarafından benzersiz bir kayıt numarası verilmelidir.
• Arıza kaydında müşteri, bina, asansör, iletişim kişisi, ihbar zamanı, açıklama, öncelik ve arıza türü alanları bulunmalıdır.
• Fotoğraf, video veya belge eklenebilmelidir.
• Aynı asansörde açık bir arıza bulunuyorsa kullanıcı uyarılmalıdır.
• Kurtarma gerektiren veya yolcu mahsur kalması bildirilen kayıtlar öncelikli olarak işaretlenebilmelidir.
• Yanlış ya da mükerrer kayıtların silinmesi yerine iptal edilmesi ve işlem geçmişinin korunması sağlanmalıdır.

Durum ve zaman takibi

Arıza kaydının yalnızca “açık” ve “kapalı” olarak izlenmesi yeterli değildir. En azından Yeni, Atandı, Yola Çıkıldı, Müdahale Başladı, Parça Bekliyor, Tamamlandı ve İptal gibi durumlar tanımlanabilmelidir.

Her durum değişikliğinin zamanı ve işlemi yapan kullanıcı kayıt altına alınmalıdır. Böylece ihbarın ne kadar beklediği, teknisyenin ne zaman yönlendirildiği ve müdahalenin ne kadar sürdüğü hesaplanabilir.

Teknisyen atama

Sistem, yetkili ofis kullanıcısının arızayı uygun teknisyene veya ekibe atamasına imkân vermelidir. Atama yapılırken teknisyenin bölgesi, mevcut işleri, nöbet durumu ve yetkinliği dikkate alınabilmelidir. Atama değişiklikleri geçmiş kayıtlar silinmeden saklanmalıdır.

Mobil Saha Kullanımı ve Teknik Servis Formu

Bir arıza yazılımının başarısı, teknisyenin sahada sistemi ne kadar kolay kullanabildiğine bağlıdır. Masaüstü ekranında ayrıntılı görünen fakat mobil cihazda karmaşık çalışan bir ürün, kısa sürede personel direnciyle karşılaşabilir.

Teknik şartnamede mobil uygulama için şu koşullar yer almalıdır:

• Uygulama Android ve iOS cihazlarda kullanılabilmelidir.
• Teknisyen yalnızca kendisine veya ekibine atanan işleri görebilmelidir.
• Yeni atama ve önemli durum değişikliklerinde bildirim gönderilmelidir.
• Teknisyen tek dokunuşla “yola çıktı”, “müdahale başladı” ve “tamamlandı” bilgisi verebilmelidir.
• İnternet bağlantısının zayıf olduğu alanlarda gerekli bilgiler görüntülenebilmeli ve girilen kayıtlar bağlantı sağlandığında eşitlenebilmelidir.
• Sahada fotoğraf, açıklama, kullanılan parça, arıza nedeni ve yapılan işlem kaydedilebilmelidir.
• Müşteri veya bina yetkilisinin adı ve imzası alınabilmelidir.
• Tamamlanan iş için dijital servis formu oluşturulabilmelidir.
• Yetki verilmesi hâlinde mobil veya termal yazıcıdan servis fişi alınabilmelidir.
• Teknisyen, geçmiş arızaları görüntüleyerek aynı cihazda daha önce yapılan işlemleri inceleyebilmelidir.

Formlarda serbest metin alanı kadar standart seçeneklere de yer verilmelidir. “Kapı kilidi ayarı”, “Fotosel temizliği” veya “Kumanda panosu kontrolü” gibi tanımlı seçenekler raporlamayı kolaylaştırır. Ancak her arızayı hazır seçeneklerle açıklamak mümkün olmayacağından teknisyene ayrıntılı not ekleme imkânı da sunulmalıdır.

Müşteri Bilgilendirme ve QR Kod Özellikleri

Bina yöneticisinin en sık sorduğu soru, “Teknisyen ne zaman gelecek?” sorusudur. Doğru tasarlanmış bir sistem, ofise yapılan durum sorgulama aramalarını azaltabilir.

Şartnamede müşteri iletişimiyle ilgili şu maddeler bulunabilir:

• Arıza kaydı oluşturulduğunda ilgili kişiye SMS, e-posta veya uygulama bildirimi gönderilebilmelidir.
• Teknisyen yola çıktığında veya iş tamamlandığında otomatik bilgilendirme yapılabilmelidir.
• Bildirim metinleri firma tarafından düzenlenebilmelidir.
• Müşteri yalnızca yetkili olduğu bina ve asansörlerin kayıtlarını görebilmelidir.
• Tamamlanan servis formu müşteriyle dijital olarak paylaşılabilmelidir.
• Binaya veya asansöre özel QR kod oluşturulabilmelidir.
• QR kodla bildirim yapılırken bina ve asansör bilgileri otomatik eşleştirilebilmelidir.
• Kötüye kullanımı önlemek amacıyla iletişim doğrulaması, yetki kontrolü veya benzeri güvenlik adımları uygulanabilmelidir.

QR kod okutulduğunda kullanıcıdan yeniden uzun adres ve cihaz bilgisi istenmemelidir. Kodun temel yararı, arızalı asansörün doğru şekilde tanınmasıdır. Bununla birlikte yolcu mahsur kalması gibi acil durumlarda kullanıcıya yalnızca dijital form sunmak yerine, firmanın acil iletişim kanalına ulaşabileceği açık bir yönlendirme de gösterilmelidir.

Raporlama ve Performans Ölçümü

Şartnamede yalnızca “raporlama modülü bulunmalıdır” demek yeterli değildir. Hangi verilerin hangi kırılımlarda alınacağı açıkça belirtilmelidir.

Rapor veya gösterge	Hesaplama amacı	Önerilen kırılım
İlk müdahale süresi	İhbar ile müdahale başlangıcı arasındaki süreyi ölçmek	Şube, bölge, teknisyen
Arıza çözüm süresi	İhbar ile tamamlanma arasındaki toplam süreyi görmek	Arıza türü, asansör, müşteri
Tekrar arıza oranı	Aynı cihazdaki benzer arızaları belirlemek	7, 15 veya 30 günlük dönem
Açık iş emri sayısı	Bekleyen iş yükünü izlemek	Durum, öncelik, ekip
Teknisyen iş yükü	Atama dağılımını dengelemek	Gün, hafta, ay
Parça bekleyen işler	Tedarik nedeniyle geciken işleri görmek	Parça, tedarik süresi
Asansör bazlı arıza sıklığı	Sorunlu cihazları ve yenileme ihtiyacını belirlemek	Bina, marka, model
Müşteri bildirim durumu	Bilgilendirmelerin ulaşıp ulaşmadığını görmek	SMS, e-posta, portal

Raporların ekranda görüntülenmesinin yanında Excel veya PDF gibi yaygın biçimlerde dışarı alınabilmesi istenebilir. Yetkili kullanıcılar tarih aralığı seçebilmeli; şube, teknisyen, müşteri, bina, asansör ve arıza türüne göre filtreleme yapabilmelidir.

Tekrar arıza raporunda benzer arızanın hangi süre içinde “tekrar” sayılacağı firma tarafından belirlenebilmelidir. Her yeni kayıt otomatik olarak önceki arızanın tekrarı kabul edilmemelidir. Teknik sorumlu gerektiğinde kayıtları ilişkilendirebilmelidir.

Veri Güvenliği, Yetkilendirme ve İşlem Geçmişi

Asansör arıza kayıtları; müşteri iletişim bilgileri, bina bilgileri, teknisyen notları ve servis geçmişi gibi ticari açıdan önemli veriler içerir. Bu nedenle güvenlik maddeleri genel ifadelerle geçiştirilmemelidir.

Şartnamede aşağıdaki güvenlik ve kayıt koşulları bulunmalıdır:

• Kullanıcılar görevlerine göre yetkilendirilebilmelidir.
• Teknisyen, ofis personeli, teknik sorumlu ve firma yöneticisi için farklı erişim seviyeleri tanımlanabilmelidir.
• Şubeler yalnızca yetkileri kapsamındaki müşteri ve iş emirlerini görebilmelidir.
• Kullanıcı girişleri ve kritik işlemler tarih, saat ve kullanıcı bilgisiyle kaydedilmelidir.
• Arıza kaydı üzerinde yapılan önemli değişikliklerin geçmişi izlenebilmelidir.
• Veriler aktarım sırasında güncel ve güvenli şifreleme yöntemleriyle korunmalıdır.
• Düzenli yedekleme yapılmalı; yedekleme sıklığı, saklama süresi ve geri yükleme yöntemi sözleşmede açıklanmalıdır.
• İşten ayrılan personelin erişimi kolayca kapatılabilmelidir.
• Kişisel verilerin işlenmesi, saklanması ve silinmesi süreçlerinde yürürlükteki KVKK yükümlülükleri dikkate alınmalıdır.
• Hizmet sona erdiğinde verilerin hangi formatta teslim edileceği ve sistemden ne zaman silineceği belirlenmelidir.

Kullanıcıların kendi arıza kayıtlarını kontrolsüz biçimde silmesine izin verilmesi denetim izini bozar. Doğru yaklaşım, hatalı kaydı iptal etmek ve kayıt geçmişini korumaktır.

Entegrasyon, Destek ve Kabul Kriterleri

Yazılımın mevcut çalışma düzeniyle nasıl bağlantı kuracağı şartnamede belirtilmelidir. SMS gönderimi, e-posta, muhasebe yazılımı veya çağrı merkezi entegrasyonu isteniyorsa bağlantının kapsamı ayrıca açıklanmalıdır.

Entegrasyon maddelerinde yalnızca “API vardır” ifadesine güvenilmemelidir. Hangi verilerin okunabileceği veya gönderilebileceği, ek ücret bulunup bulunmadığı, bağlantının kim tarafından kurulacağı ve sürüm değişikliklerinde desteğin nasıl verileceği sorulmalıdır.

Destek ve hizmet seviyesi için şu konular netleştirilmelidir:

• Destek verilecek gün ve saatler
• Acil arızalarda kullanılacak iletişim kanalı
• Kritik, yüksek, orta ve düşük öncelikli yazılım sorunlarının tanımı
• İlk dönüş ve hedef çözüm süreleri
• Eğitim kapsamı ve eğitim verilecek kullanıcı sayısı
• Veri aktarımından sorumlu taraf
• Güncellemelerin pakete dâhil olup olmadığı
• İlave kullanıcı, SMS, depolama veya entegrasyon ücretleri
• Abonelik bitiminde veri dışa aktarma yöntemi
• Planlı bakım çalışmalarının bildirim süresi

Kabul sürecinde “sistem çalışıyor” değerlendirmesi yerine örnek senaryolar kullanılmalıdır. Örneğin müşteri portalından arıza açılması, teknisyene atanması, teknisyenin mobil cihazdan form doldurması, müşteri imzasının alınması ve sonuç raporunun oluşturulması baştan sona test edilmelidir.

Asansorex gibi asansör bakım ve arıza yönetimine odaklanan bir yazılım değerlendirilirken de bu senaryolar gerçek firma verilerini içermeyen deneme kayıtlarıyla uygulanabilir. Böylece karar yalnızca sunuma değil, günlük iş akışının sahadaki karşılığına dayanır.

Teknik Şartname İçin Örnek Kabul Kontrol Listesi

Satın alma veya abonelik başlamadan önce aşağıdaki kontroller yapılmalıdır:

• En az üç farklı arıza senaryosu oluşturuldu mu?
• Müşteri, bina ve asansör eşleşmesi doğru çalışıyor mu?
• Aynı asansördeki açık kayıt için uyarı veriliyor mu?
• Atama bildirimi teknisyenin mobil cihazına ulaşıyor mu?
• İnternet kesintisinde saha kaydı korunuyor mu?
• Fotoğraf, parça, açıklama ve imza forma eklenebiliyor mu?
• Durum değişikliklerinin zamanı rapora yansıyor mu?
• Yetkisiz kullanıcı başka şubenin kayıtlarını görebiliyor mu?
• Tekrar arıza raporu beklenen sonucu veriyor mu?
• Servis formu müşteriye gönderilebiliyor mu?
• Yedekten geri yükleme yöntemi yazılı olarak açıklandı mı?
• Veriler kullanılabilir bir formatta dışarı alınabiliyor mu?
• Eğitim ve destek sorumluları belirlendi mi?
• İlave ücret doğurabilecek hizmetler sözleşmede listelendi mi?

Kabul testleri mümkünse ofis çalışanı, teknisyen ve firma yöneticisinin birlikte katıldığı bir pilot çalışmayla yapılmalıdır. Bu yöntem, yalnızca teknik olarak çalışan fakat sahada kullanılması zor özelliklerin erken fark edilmesini sağlar.

Sıkça Sorulan Sorular

Teknik şartnamede marka adı yazılmalı mı?

Rekabetçi değerlendirme yapılacaksa marka yerine ihtiyaç ve kabul ölçütleri yazılması daha sağlıklıdır. Örneğin “mobil uygulama bulunmalıdır” demek yerine uygulamanın hangi işlemleri yapacağı ve hangi koşullarda kabul edileceği belirtilmelidir.

İnternetsiz çalışma mutlaka istenmeli mi?

Teknisyenlerin bodrum, kuyu çevresi veya kapsama sorunu bulunan bölgelerde çalıştığı düşünülüyorsa çevrim dışı kullanım önemli bir kriterdir. Ancak hangi verilerin internetsiz görüntüleneceği ve eşitlemenin nasıl yapılacağı açıkça tanımlanmalıdır.

Arıza yazılımında QR kod zorunlu mudur?

Her firma için zorunlu değildir fakat arızanın doğru bina ve asansörle eşleştirilmesini hızlandırır. QR kod özelliğinin müşteri doğrulaması ve acil durum yönlendirmesiyle birlikte değerlendirilmesi gerekir.

Yazılım mevzuata uyum garantisi verebilir mi?

Yazılım kayıt, takip ve raporlama süreçlerini destekler; firmanın teknik ve hukuki sorumluluğunu ortadan kaldırmaz. Şartname hazırlanırken yürürlükteki Asansör İşletme ve Bakım Yönetmeliği, kişisel veri yükümlülükleri ve firmanın hizmet kapsamı ayrıca değerlendirilmelidir.

Teknik destek süresi nasıl belirlenmeli?

Süreler sorunun etkisine göre ayrılmalıdır. Sisteme hiç erişilememesi ile rapordaki küçük bir görüntüleme hatası aynı öncelikte değerlendirilmemelidir. İlk dönüş ve hedef çözüm süreleri sözleşmede ayrı ayrı yazılmalıdır.

En doğru yazılım nasıl seçilir?

Özellik sayısından önce gerçek iş senaryolarındaki başarıya bakılmalıdır. Arıza açma, atama, saha müdahalesi, müşteri onayı ve raporlama süreci pilot olarak denenmeli; toplam maliyet, destek kalitesi ve veri taşınabilirliği birlikte değerlendirilmelidir.

Özet

İyi bir Asansör Arıza Yazılımı teknik şartnamesi; arıza kaydı, teknisyen atama, mobil kullanım, müşteri bilgilendirme, raporlama, güvenlik, entegrasyon ve destek koşullarını ölçülebilir maddelerle tanımlar. Genel ifadeler yerine gerçek kullanım senaryoları ve kabul kriterleri yazılması, satın alma sonrasında yaşanabilecek anlaşmazlıkları önemli ölçüde azaltır.

Asansorex, arıza kayıtlarının iş emrine dönüştürülmesi, saha ekiplerinin yönlendirilmesi ve servis geçmişinin merkezi olarak izlenmesi gibi süreçlerde değerlendirilebilecek çözümlerden biridir. Ancak nihai seçim yapılırken firmanın kendi saha düzenine göre hazırlanmış şartname üzerinden pilot test gerçekleştirilmesi en güvenilir yaklaşımdır.