Asansör Arıza Çağrı Programı İçin Teknik Şartname Maddeleri

İÇERİK

Asansör arızalarının telefon görüşmeleri, WhatsApp mesajları ve kâğıt notlarla yönetilmesi; çağrının unutulmasına, yanlış teknisyenin yönlendirilmesine ve müdahale süresinin ölçülememesine yol açabilir. Bu nedenle yazılım satın alma sürecinde yalnızca ekran görüntülerine veya satış sunumuna bakmak yeterli değildir. İhtiyacın açık şekilde tanımlandığı bir teknik şartname hazırlanmalıdır. Bu rehberde, Asansör Arıza Çağrı Programı seçerken şartnameye eklenebilecek işlevsel, teknik ve operasyonel maddeleri bulabilirsiniz. Maddeler doğrudan kopyalanabilir; ancak firma büyüklüğüne, hizmet verilen asansör sayısına ve ekip yapısına göre uyarlanmalıdır.

Teknik Şartname Hazırlamadan Önce İhtiyacı Belirleyin

İyi bir teknik şartname, mümkün olduğunca fazla özellik isteyen belge değildir. Firmanın gerçek çalışma düzenini ölçülebilir gereksinimlere dönüştüren belgedir. Önce mevcut arıza süreci çıkarılmalıdır: Bildirim kimden geliyor, çağrıyı kim kaydediyor, teknisyen nasıl seçiliyor, bina yöneticisine hangi bilgiler veriliyor ve iş nasıl kapatılıyor?

Hazırlık aşamasında aşağıdaki veriler belirlenmelidir:

• Sözleşmeli asansör ve bina sayısı
• Aylık ortalama arıza çağrısı
• Aynı anda çalışan teknisyen sayısı
• Şube, bölge ve nöbet ekibi yapısı
• Mesai dışı çağrıların yönetim biçimi
• Kullanılan muhasebe, CRM veya iletişim sistemleri
• Müşteriye gönderilmesi gereken bildirimler
• Arıza formunda alınması zorunlu bilgiler
• İnternet bağlantısının zayıf olduğu çalışma bölgeleri
• Yönetimin takip etmek istediği performans göstergeleri

Örneğin 150 asansöre hizmet veren tek şubeli bir firma ile 2.000 asansörü farklı ilçelerde yöneten bir kuruluşun aynı iş akışına sahip olması beklenemez. Küçük firmada hızlı kayıt ve kolay kullanım öncelikliyken, çok şubeli yapıda yetkilendirme, otomatik atama, nöbet yönetimi ve karşılaştırmalı raporlama daha kritik olabilir.

Şartnamedeki her madde, gerçek bir iş sorununa veya ölçülebilir bir kontrol ihtiyacına karşılık gelmelidir.

Arıza Çağrısı ve İş Emri Yönetimi Maddeleri

Şartnamenin ilk bölümü, bir arıza bildiriminin alınmasından kapatılmasına kadar geçen süreci tanımlamalıdır. “Arıza kaydı yapılabilmelidir” gibi genel ifadeler yerine, kaydın hangi bilgileri içereceği ve nasıl izleneceği açıklanmalıdır.

Örnek şartname maddeleri şunlardır:

1. Sistem; telefon, müşteri portalı veya yetkili kullanıcı tarafından iletilen arıza bildirimlerinin merkezi olarak kaydedilmesini sağlamalıdır.
2. Her arıza çağrısına benzersiz bir kayıt veya iş emri numarası verilmelidir.
3. Kayıtta müşteri, bina, asansör, bildirim zamanı, bildiren kişi, iletişim bilgisi, arıza açıklaması ve öncelik seviyesi tutulabilmelidir.
4. Aynı asansör için hâlihazırda açık bir arıza kaydı bulunuyorsa kullanıcı uyarılmalıdır.
5. Arıza kayıtları en azından Yeni, Atandı, Yola Çıktı, Müdahale Ediliyor, Parça Bekliyor, Tamamlandı ve İptal gibi durumlarla izlenebilmelidir.
6. Durum adları, firmanın operasyonuna göre düzenlenebilmeli veya uygun seçenekler arasından yapılandırılabilmelidir.
7. Acil çağrılar ve mahsur kalma bildirimleri, normal arızalardan görsel olarak ayrılabilmelidir.
8. Arıza kaydına fotoğraf, belge, sesli açıklama veya ilgili diğer dosyalar eklenebilmelidir.
9. Çağrının hangi kullanıcı tarafından, hangi tarih ve saatte oluşturulduğu değiştirilemez işlem geçmişinde tutulmalıdır.
10. Kapatılan bir arıza yeniden açıldığında gerekçesi ve işlemi yapan kullanıcı kaydedilmelidir.

Mahsur kalma bildirimi için ayrı bir önem seviyesi tanımlanması özellikle önemlidir. Ancak yazılım, güvenlik prosedürlerinin yerine geçmez. Firma; kurtarma, yetkili personel ve acil durum süreçlerini yürürlükteki kurallara ve kendi yetkinliklerine göre ayrıca yönetmelidir.

Teknisyen Atama ve Mobil Kullanım Şartları

Bir arıza programının gerçek değeri, ofiste açılan kaydın sahadaki teknisyene eksiksiz ulaşmasıyla ortaya çıkar. Bu nedenle teknik şartnamede mobil kullanım birkaç genel cümleyle geçiştirilmemelidir.

Kontrol alanı	Şartnamede aranacak asgari özellik	Doğrulama yöntemi
İş emri bildirimi	Atanan çağrının teknisyene anlık iletilmesi	Test çağrısı oluşturma
Durum güncelleme	Yola çıkma, varış ve tamamlanma bilgilerinin kaydı	Mobil uygulama testi
Çevrimdışı çalışma	Bağlantı yokken veri girilip sonra eşitlenmesi	İnternet kapatılarak test
Kanıt toplama	Fotoğraf, açıklama, kullanılan parça ve imza kaydı	Örnek iş emri kapatma
Konum bilgisi	Yetki ve açık bilgilendirme çerçevesinde konum kaydı	İzin ve kayıt kontrolü
Cihaz uyumu	Firmanın kullandığı güncel telefon ve tabletlerde çalışma	Pilot cihaz testi
Geçmiş görüntüleme	Yetki dâhilinde önceki arıza ve bakım kayıtlarına erişim	Asansör geçmişi kontrolü

Teknisyen ataması yapılırken bölge, nöbet durumu, uzmanlık, mevcut iş yükü ve asansöre uzaklık gibi bilgiler değerlendirilebilmelidir. Ancak otomatik atama isteniyorsa kural açık yazılmalıdır. Örneğin “Sistem en yakın teknisyeni atamalıdır” ifadesi tek başına yetersizdir. Konum izninin kapalı olması, teknisyenin başka bir kritik çağrıda bulunması veya belirli marka sistemde yetkin olmaması gibi istisneler tanımlanmalıdır.

Mobil uygulamada teknisyen şu işlemleri yapabilmelidir:

• Kendisine atanan açık iş emirlerini görebilme
• Bina ve yetkili kişi bilgilerine ulaşabilme
• Navigasyon için adresi kullanabilme
• Arıza nedenini ve yapılan işlemi seçebilme
• Kullanılan yedek parçaları kaydedebilme
• Fotoğraf, açıklama ve müşteri imzası ekleyebilme
• Çözülmeyen işi gerekçesiyle beklemeye alabilme
• Gerekli yetki varsa termal servis fişi oluşturabilme
• İş tamamlandığında müşteriye iletilecek servis kaydını hazırlayabilme

Müşteri Bildirimleri ve Hizmet Şeffaflığı

Bina yöneticisi veya yetkili kişi, arıza bildiriminden sonra sürekli firmayı aramak zorunda kalmamalıdır. Şartnamede, müşteriye hangi aşamalarda ve hangi kanallardan bilgi verileceği belirtilmelidir.

Sistem; çağrı alındığında, teknisyen atandığında, ekip yola çıktığında ve işlem tamamlandığında SMS, e-posta, mobil bildirim veya müşteri portalı üzerinden bilgilendirme yapabilmelidir. Her kanal zorunlu tutulmak yerine firmanın kullanacağı kanallar seçilmelidir. SMS gibi ayrıca maliyet oluşturan hizmetlerin birim fiyatı, paket şartları ve gönderim kayıtları teklif aşamasında açıklanmalıdır.

Müşteri portalı talep ediliyorsa şu maddeler eklenebilir:

• Müşteri yalnızca yetkili olduğu bina ve asansörleri görebilmelidir.
• Yeni arıza bildirimi oluşturabilmelidir.
• Açık kaydın güncel durumunu izleyebilmelidir.
• Tamamlanmış servis formlarına erişebilmelidir.
• Fotoğraf ve açıklama ekleyebilmelidir.
• Kişisel veya ticari açıdan gereksiz bilgiler müşteriye gösterilmemelidir.
• Bildirimlerin hangi kullanıcı tarafından oluşturulduğu izlenebilmelidir.

Bu kayıtları telefon notları yerine Asansorex gibi bir bakım ve arıza takip yazılımında toplamak, hem firma sahibinin müdahale süresini görmesini hem de bina yöneticisinin hizmet geçmişine daha düzenli ulaşmasını sağlayabilir.

Raporlama ve Performans Ölçüm Maddeleri

“Gelişmiş raporlama bulunmalıdır” ifadesi, teklifleri sağlıklı karşılaştırmaya yetmez. Hangi göstergelerin ölçüleceği teknik şartnamede ayrı ayrı tanımlanmalıdır.

Program en azından aşağıdaki raporları sunabilmelidir:

• Tarih aralığına göre toplam arıza sayısı
• Asansör, bina, müşteri, bölge ve şube bazında arıza dağılımı
• İlk yanıt ve sahaya varış süresi
• Arızanın açılması ile tamamlanması arasındaki süre
• Tekrar eden arıza sayısı ve oranı
• Arıza nedeni ve kullanılan parça dağılımı
• Teknisyen bazında atanan, tamamlanan ve bekleyen işler
• Mesai içi ve mesai dışı çağrı karşılaştırması
• Çözülemeyen veya parça bekleyen işlerin yaşlandırma listesi
• Sözleşmeli ve sözleşme dışı işlerin ayrımı

Tekrar arıza tanımı özellikle netleştirilmelidir. Aynı asansörde 7, 15 veya 30 gün içinde oluşan her çağrının tekrar arıza sayılması yanıltıcı olabilir. Programın; tarih aralığı, arıza kodu ve ilgili ekipman gibi ölçütlerle filtreleme yapabilmesi istenmelidir.

Raporlar ekranda görüntülenebilmeli ve yaygın dosya biçimlerinden en az birine aktarılabilmelidir. Bununla birlikte dışa aktarılan raporda hangi alanların bulunacağı, kullanıcı yetkilerinin korunup korunmadığı ve kişisel verilerin gereksiz biçimde çoğaltılmaması da değerlendirilmelidir.

Güvenlik, Yetkilendirme ve Veri Yönetimi

Arıza kayıtları; müşteri iletişim bilgileri, bina adresleri, teknisyen bilgileri ve hizmet geçmişi içerebilir. Bu nedenle güvenlik bölümü, teknik şartnamenin temel parçalarından biridir.

Aşağıdaki maddeler şartnameye eklenebilir:

• Her kullanıcıya kişisel hesap tanımlanmalı; ortak kullanıcı kullanımı zorunlu olmamalıdır.
• Firma sahibi, ofis personeli, teknisyen ve müşteri için farklı erişim seviyeleri oluşturulabilmelidir.
• Kullanıcı yalnızca görev ve sorumluluğu için gerekli verilere erişebilmelidir.
• Kritik kayıt ekleme, değiştirme, kapatma ve silme işlemleri zaman damgasıyla kaydedilmelidir.
• Parolalar güvenli biçimde saklanmalı ve parola politikası uygulanabilmelidir.
• Uygun pakette çok faktörlü kimlik doğrulama seçeneği sunulması değerlendirilmelidir.
• Veri iletimi güncel güvenli bağlantı yöntemleriyle korunmalıdır.
• Yedekleme sıklığı, yedeklerin saklama süresi ve geri yükleme yöntemi açıklanmalıdır.
• Hizmet sona erdiğinde verilerin hangi biçimde teslim edileceği sözleşmede belirtilmelidir.
• Veri silme, saklama ve erişim süreçleri KVKK kapsamındaki yükümlülüklerle uyumlu planlanmalıdır.
• Güvenlik olayı yaşandığında uygulanacak bildirim ve müdahale süreci açıklanmalıdır.

Tedarikçiden yalnızca “veriler güvendedir” beyanı alınmamalıdır. Yedeklerin ne sıklıkla oluşturulduğu, bir geri yükleme denemesinin nasıl yapıldığı ve hizmet kesintisinde kiminle iletişime geçileceği sorulmalıdır.

Entegrasyon, Destek ve Kabul Kriterleri

Arıza çağrı programının başka sistemlerle çalışması gerekiyorsa entegrasyon kapsamı baştan belirlenmelidir. Muhasebe yazılımı, SMS hizmeti, çağrı merkezi, e-posta altyapısı veya mevcut müşteri sistemiyle bağlantı talep edilebilir.

Her entegrasyon için şu bilgiler yazılmalıdır:

• Aktarılacak veri alanları
• Veri aktarım yönü
• Güncelleme sıklığı
• Mükerrer kayıt kontrolü
• Hata durumunda uygulanacak süreç
• Kurulum ve kullanım maliyeti
• Entegrasyonun bakım sorumluluğu
• Kullanılacak kimlik doğrulama yöntemi

Kabul sürecinde yalnızca programın açılması yeterli sayılmamalıdır. Gerçek iş akışını temsil eden bir pilot çalışma yapılmalıdır. Örneğin bir deneme binası ve iki teknisyen seçilerek arıza açma, atama, çevrimdışı veri girişi, fotoğraf ekleme, müşteri bildirimi ve raporlama adımları birlikte test edilebilir.

Kabul kontrolü için şu sıra uygulanabilir:

1. Örnek müşteri, bina ve asansör verilerini sisteme aktarın.
2. Normal ve acil öncelikli iki ayrı arıza kaydı oluşturun.
3. Kayıtları farklı teknisyenlere atayın.
4. Bir iş emrini internet bağlantısı kapalıyken güncelleyin.
5. Kullanılan parça, fotoğraf ve açıklama ekleyerek işi kapatın.
6. Müşteri bildiriminin doğru kişiye ulaştığını kontrol edin.
7. Müdahale süresi ve tekrar arıza raporunu oluşturun.
8. Yetkisiz bir kullanıcının kısıtlı verilere erişemediğini doğrulayın.
9. Dışa aktarma ve veri yedekleme sürecini test edin.
10. Tespit edilen eksikleri yazılı kabul tutanağına kaydedin.

Destek saatleri, kritik sorunlara ilk dönüş hedefi, eğitim kapsamı, sürüm güncellemeleri ve ek ücretli hizmetler de şartnamede veya ticari sözleşmede açıkça yer almalıdır.

Sıkça Sorulan Sorular

Teknik şartname kaç maddeden oluşmalıdır?

Sabit bir sayı yoktur. Önemli olan madde sayısı değil, iş akışının ölçülebilir biçimde tanımlanmasıdır. Orta ölçekli bir firma için işlev, güvenlik, mobil kullanım, raporlama ve destek başlıklarına dağıtılmış 30–50 açık madde çoğu zaman yeterli bir başlangıç sağlar.

Her özelliği zorunlu tutmak doğru mudur?

Hayır. Maddeler zorunlu, tercih edilen ve opsiyonel olarak sınıflandırılmalıdır. Aksi hâlde kullanılmayacak özellikler maliyeti artırabilir ve tekliflerin karşılaştırılmasını zorlaştırabilir.

Mobil uygulamanın çevrimdışı çalışması gerekli midir?

Teknisyenlerin bodrum katlarında, makine dairelerinde veya bağlantının zayıf olduğu bölgelerde çalışması nedeniyle çevrimdışı kayıt önemli olabilir. Ancak hangi verilerin çevrimdışı tutulduğu ve bağlantı geldiğinde nasıl eşitlendiği pilot testte doğrulanmalıdır.

Konum takibi şartnameye eklenebilir mi?

Operasyon için gerekiyorsa eklenebilir; fakat amaç, kapsam, erişim yetkisi ve saklama süresi açıkça belirlenmelidir. Çalışanların bilgilendirilmesi ve kişisel verilerin korunmasına ilişkin yükümlülükler ayrıca değerlendirilmelidir.

Yazılımın mevzuata uygun olduğunu söylemesi yeterli midir?

Tek başına yeterli değildir. Yazılım kayıt ve raporlama süreçlerini destekler; bakım firmasının teknik, sözleşmesel ve mevzuattan doğan sorumluluklarını ortadan kaldırmaz. İstenen belge, alan ve iş akışları ayrıca kontrol edilmelidir.

Demo ile teknik kabul aynı şey midir?

Hayır. Demo, genel özellikleri gösterir. Teknik kabul ise firmanın kendi cihazları, kullanıcıları, örnek verileri ve gerçek senaryolarıyla şartname maddelerinin tek tek doğrulanmasıdır.

Özet

Başarılı bir Asansör Arıza Çağrı Programı şartnamesi; çağrı kaydından teknisyen atamasına, mobil çalışmadan müşteri bilgilendirmesine, güvenlikten raporlamaya kadar bütün süreci ölçülebilir maddelerle tanımlar. Belirsiz ifadeler yerine test edilebilir kabul kriterleri yazılmalı, zorunlu ve opsiyonel özellikler ayrılmalı, satın alma öncesinde gerçek bir pilot uygulanmalıdır. Asansorex gibi sektöre odaklanan çözümler değerlendirilirken de aynı şartname üzerinden ilerlemek, özelliklerin firma ihtiyacına ne ölçüde karşılık verdiğini daha nesnel biçimde görmeye yardımcı olur.