Asansör Saha Programı Teknik Şartname Nasıl Hazırlanır?

İÇERİK

Bir asansör saha programı teknik şartname dokümanı hazırlarken amaç, mümkün olduğunca uzun bir özellik listesi oluşturmak değildir. Asıl amaç; bakım firmasının günlük operasyonunda gerçekten ihtiyaç duyduğu fonksiyonları ölçülebilir, test edilebilir ve yoruma kapalı maddeler halinde tanımlamaktır. Çünkü yalnızca "mobil uygulama olmalı", "konum takibi yapmalı" veya "raporlama bulunmalı" şeklinde hazırlanmış genel ifadeler, satın alma aşamasında farklı yazılımların sağlıklı karşılaştırılmasını zorlaştırır.

Doğru hazırlanmış bir teknik şartname; firma sahibinin yatırım kararını kolaylaştırır, teknisyenin sahada yaşayacağı sorunları önceden ortaya çıkarır ve satın alınan programın birkaç ay sonra yetersiz kalması riskini azaltır. Bu rehberde, asansör bakım ve servis firmalarının saha yazılımı seçerken teknik şartnamelerine ekleyebilecekleri temel kriterleri pratik örneklerle ele alacağız.

Asansör Saha Programı Teknik Şartnamesinin Amacı Nedir?

Teknik şartname, yazılım sağlayıcısına "bize bir saha programı verin" demekten çok daha fazlasıdır. Hangi operasyonların dijitalleştirileceğini ve yazılımın hangi koşullarda yeterli kabul edileceğini tanımlar.

Örneğin firma ayda 800 asansörün bakımını gerçekleştiriyorsa yalnızca bakım kaydı oluşturabilmek yeterli olmayabilir. Sistem aynı zamanda bakım planlarını ekipler arasında dağıtabilmeli, sahadaki teknisyen işi tamamlayabilmeli, gerekli formu doldurabilmeli ve merkez ofis yapılan işlemi görebilmelidir.

Benzer şekilde arıza tarafında da yalnızca "arıza kaydı oluşturma" özelliği yeterli değildir. Teknik şartnamede şu sürecin tamamı düşünülmelidir:

1. Arıza kaydı açılması
2. İlgili bina ve asansörle eşleştirilmesi
3. Teknisyen veya ekibe atanması
4. Teknisyenin arızayı mobil cihazından görmesi
5. Sahada yapılan işlemlerin kaydedilmesi
6. Kullanılan parça veya masrafın işlenmesi
7. Fotoğraf ve açıklama eklenmesi
8. Arızanın tamamlanması
9. Gerekirse müşterinin bilgilendirilmesi
10. Geçmiş kaydın daha sonra tekrar görüntülenebilmesi

Bu nedenle teknik şartnameyi özellik isimleri üzerinden değil, gerçek saha senaryoları üzerinden hazırlamak daha sağlıklı sonuç verir.

Teknik Şartnamede Bulunması Gereken Temel Modüller

Asansör bakım firmasının çalışma modeline göre ihtiyaçlar değişebilir. Ancak saha operasyonunun merkezinde genellikle bakım, arıza, teknisyen, müşteri ve asansör kayıtları bulunur.

Aşağıdaki tablo örnek bir teknik şartname iskeleti olarak kullanılabilir:

Kriter	Teknik şartnamede istenebilecek özellik	Kabul kontrolü
Mobil kullanım	Teknisyen işlemleri telefondan tamamlayabilmeli	Gerçek cihazda bakım kapatma testi
Bakım yönetimi	Planlı ve gerektiğinde anlık bakım oluşturulabilmeli	Örnek bakım kaydı açılır
Arıza yönetimi	Arıza personele veya ekibe atanabilmeli	Atama bildirimi test edilir
Fotoğraf	İşlem sırasında fotoğraf yüklenebilmeli	Mobil cihazdan fotoğraf eklenir
Dijital imza	Bakım veya servis formuna imza alınabilmeli	Örnek form imzalanır
Konum	Yetkilendirilen saha işlemlerinde konum kaydı alınabilmeli	Test kullanıcısıyla kontrol edilir
Formlar	Kontrol listeleri dijital doldurulabilmeli	Örnek checklist tamamlanır
Raporlama	Tamamlanan ve bekleyen işler görülebilmeli	Tarih aralığı raporu alınır
Geçmiş kayıt	Asansörün eski bakım ve arıza kayıtları bulunabilmeli	Bir asansörün geçmişi açılır
Yetkilendirme	Kullanıcılar görevlerine göre sınırlandırılabilmeli	Farklı kullanıcı hesapları denenir
Veri aktarımı	Mevcut müşteri ve asansör verileri aktarılabilmeli	Örnek Excel veri aktarımı yapılır
Dışa aktarma	Gerektiğinde belirli veriler dışarı alınabilmeli	Örnek rapor dışa aktarılır

Şartnamenin güçlü tarafı, sağ sütunda görülen kabul kontrolüdür. Çünkü satıcının "özellik mevcut" demesi yerine özelliğin canlı olarak çalıştığı gösterilebilir.

Mobil Uygulama İçin Teknik Gereksinimler

Bir saha programının en kritik bileşeni teknisyenin kullandığı mobil taraftır. Masaüstü ekranının güçlü olması, teknisyen uygulamayı sahada rahat kullanamıyorsa tek başına yeterli değildir.

Kullanım Kolaylığı

Teknisyenin bir bakım kaydını kapatmak için gereksiz sayıda ekran dolaşması operasyon hızını düşürür. Teknik şartnamede doğrudan ekran sayısı belirlemek yerine şu tarz işlevsel maddeler kullanılabilir:

• Teknisyen kendisine atanmış işleri görebilmelidir.
• Günlük bakım ve arıza listesine mobil cihazdan ulaşabilmelidir.
• İş detayından bina ve asansör bilgisine erişebilmelidir.
• Bakım formunu mobil cihaz üzerinden doldurabilmelidir.
• Fotoğraf ekleyebilmelidir.
• Açıklama yazabilmelidir.
• Müşteri veya bina yetkilisinden dijital imza alınabilmelidir.
• İş tamamlandığında tarih ve kullanıcı bilgisi kayıt altına alınmalıdır.

Burada amaç teknisyenin sahadan merkeze WhatsApp mesajı, telefon veya kâğıt form göndermek zorunda kalmamasıdır.

İnternet Bağlantısının Zayıf Olduğu Alanlar

Makine daireleri, bodrum katları ve bazı bina bölgelerinde mobil bağlantı zayıf olabilir. Bu nedenle programın internet bağlantısı kesildiğinde nasıl davrandığı özellikle sorulmalıdır.

Teknik şartnameye örneğin şu madde eklenebilir:

Mobil uygulama, geçici internet kesintilerinde veri kaybı oluşturmayacak bir çalışma mekanizmasına sahip olmalı; bağlantı geri geldiğinde bekleyen kayıtların durumu kullanıcıya açık biçimde gösterilmelidir.

Burada "tam çevrimdışı çalışma zorunludur" gibi gereğinden katı bir koşul yazmadan önce firmanın gerçek saha ihtiyacı değerlendirilmelidir.

Bakım ve Arıza Süreci Nasıl Tanımlanmalı?

Asansör saha programı yalnızca teknisyen konumu gösteren bir uygulama olarak düşünülmemelidir. Programın asıl değeri, bakım ve servis süreçlerini kayıt altına almasıdır.

Bakım Yönetimi

Teknik şartnamede bakım tarafında aşağıdaki işlevler aranabilir:

• Aylık bakım planlarının oluşturulması
• Bakımın belirli teknisyen veya ekibe atanması
• Planlanan ve tamamlanan bakımların ayrılması
• Bakım tarihinin kaydedilmesi
• Dijital bakım formunun doldurulması
• Fotoğraf eklenmesi
• Açıklama girilmesi
• Müşteri imzasının alınması
• Gerekirse bakım sonucunun müşteriye gönderilebilmesi
• Geçmiş bakım kayıtlarının asansör bazında görüntülenmesi

Türkiye'de asansörlerin periyodik kontrolü ile bakım faaliyetleri birbirinden farklı süreçlerdir. TSE'nin güncel bilgilendirmesinde periyodik kontrollerin yılda en az bir kez A tipi akredite muayene kuruluşları tarafından gerçekleştirildiği belirtilmektedir. Kontrol sonucunda yeşil, mavi, sarı veya kırmızı bilgi etiketi uygulanabilmektedir. ([Türkiye Sıhhiye Raporu][1])

Dolayısıyla saha yazılımında "bakım tamamlandı" kaydı bulunması, yıllık periyodik kontrolün yapılmış olduğu anlamına gelmemelidir. Yazılım veri düzenini kurmalı; teknik ve mevzuatsal görevlerin yerine geçtiği izlenimini oluşturmamalıdır.

Arıza Yönetimi

Arıza yönetiminde ise kayıt açılışından çözüm aşamasına kadar takip önemlidir.

Teknik şartname örneği şöyle hazırlanabilir:

• Arızanın geliş tarihi ve saati kaydedilmelidir.
• Hangi bina ve asansöre ait olduğu seçilebilmelidir.
• Arıza teknisyen veya ekibe atanabilmelidir.
• Atanan personel mobil cihazından kaydı görebilmelidir.
• Müdahale açıklaması girilebilmelidir.
• Kullanılan malzeme veya değişen parça kaydedilebilmelidir.
• İşlem öncesi veya sonrası fotoğraf eklenebilmelidir.
• Arızanın durumu takip edilebilmelidir.
• Kapatılan kayıtlar silinmeden geçmişte görüntülenebilmelidir.

Özellikle tekrar eden arızaların analiz edilebilmesi için geçmiş kayıtların korunması değerlidir. Aynı asansörde kısa süre içinde benzer kapı, kontaktör, fotosel veya kumanda kaynaklı problemler tekrarlanıyorsa firma sahibi yalnızca son arızayı değil geçmiş müdahaleleri de görebilmelidir.

Konum, Fotoğraf ve Dijital Form Şartları

Saha programlarında en fazla yanlış anlaşılan özelliklerden biri konum takibidir. Teknik şartnamede yalnızca "GPS olacak" yazmak yeterli değildir.

Öncelikle hangi konum bilgisinin gerekli olduğu belirlenmelidir:

• Teknisyenin bakım kapattığı konum
• İşe başlama konumu
• İş tamamlanma konumu
• Günlük rota planlamasında kullanılacak konum
• Firma politikasına göre aktif saha personeli konumu

Konum özelliğinin personel yönetimi ve kişisel veri boyutu da bulunduğundan hangi verinin, hangi amaçla ve hangi süreyle kullanılacağı ayrıca değerlendirilmelidir.

Fotoğraf tarafında ise teknik şartname daha somut hazırlanabilir:

• Bir işe birden fazla fotoğraf eklenebilmeli.
• Fotoğraflar ilgili bakım veya arıza kaydıyla ilişkilendirilmeli.
• Daha sonra hangi işlemde çekildiği bulunabilmeli.
• Yetkisiz kullanıcıların kayıtları silmesi veya değiştirmesi sınırlandırılabilmeli.

Dijital formlarda da "form oluşturma var" ifadesi yeterli değildir. Firmanın mevcut bakım föyü veya kontrol listesinin yazılıma uyarlanıp uyarlanamadığı demo sırasında görülmelidir.

Bu noktada Asansorex gibi asansör bakım ve saha yönetimine odaklanan sistemlerde bakım/arıza kayıtlarının mobil ortamda kapatılması, fotoğraf, dijital imza ve saha bilgilerinin tek işlem altında toplanması; kâğıt ile dijital kayıt arasında oluşan boşlukları azaltabilir.

Raporlama ve Yönetim Tarafında Hangi Kriterler Aranmalı?

Saha programının yalnızca veri toplaması değil, toplanan veriyi anlaşılır hâle getirmesi gerekir.

Firma sahibi açısından şu soruların cevaplanabilmesi önemlidir:

• Bu ay kaç bakım planlandı?
• Kaçı tamamlandı?
• Kaç bakım gecikti?
• Hangi teknisyenlerde bekleyen işler bulunuyor?
• Hangi bölgelerde iş yoğunluğu artıyor?
• En fazla arıza veren asansörler hangileri?
• Belirli bir müşteride kaç servis kaydı oluşmuş?
• Belirli tarih aralığında hangi işlemler yapılmış?

Teknik şartnameye "gelişmiş raporlama olmalıdır" yazmak yerine ihtiyaç duyulan raporları isimlendirmek daha doğru olur.

Örneğin:

Sistem, tarih aralığı seçilerek tamamlanan bakım, bekleyen bakım ve arıza kayıtlarının raporlanmasına imkân sağlamalıdır.

Bu ifade test edilebilir.

Buna karşılık:

Sistem güçlü raporlama altyapısına sahip olmalıdır.

ifadesinin ölçülmesi zordur.

Veri Güvenliği, Yetkilendirme ve Yedekleme

Teknik şartnamenin yalnızca operasyon özelliklerinden oluşması önemli bir eksikliktir. Müşteri, bina, asansör, finans ve personel verileri bulunan bir sistemde erişim yönetimi mutlaka değerlendirilmelidir.

Şartnamede şu sorulara cevap aranmalıdır:

• Her kullanıcı bütün müşterileri görebiliyor mu?
• Teknisyen yalnızca kendisine atanmış işleri görebiliyor mu?
• Kayıt silme yetkisi sınırlandırılabiliyor mu?
• İşlem geçmişi izlenebiliyor mu?
• Eski personelin erişimi kapatılabiliyor mu?
• Kullanıcı hesapları kişiye özel açılabiliyor mu?
• Veriler düzenli olarak yedekleniyor mu?
• Hizmet sona ererse verilerin dışa aktarılması mümkün mü?

Özellikle "tek kullanıcı hesabını bütün teknisyenler kullanır" yaklaşımından kaçınılmalıdır. Kimin hangi işlemi yaptığı ancak kullanıcıların ayrı hesaplarla çalışması hâlinde sağlıklı biçimde takip edilebilir.

Şartnamede veri sahipliği de açık olmalıdır. Firmanın oluşturduğu müşteri, bina, bakım ve servis kayıtlarının hizmet sağlayıcıyla çalışma sona erdiğinde hangi formatlarda alınabileceği önceden konuşulmalıdır.

Teknik Şartnameyi Satın Alma Öncesinde Nasıl Test Etmelisiniz?

Bir yazılımı yalnızca sunum ekranından değerlendirmek yerine gerçek bir saha senaryosu üzerinden test etmek daha sağlıklıdır.

Örnek kabul testi şu şekilde uygulanabilir:

1. Test müşterisi oluşturun.
2. Müşteriye bir bina ekleyin.
3. Binaya bir asansör tanımlayın.
4. Asansöre bakım planlayın.
5. Bakımı bir teknisyene atayın.
6. Teknisyen hesabıyla mobil uygulamaya girin.
7. Bakım formunu doldurun.
8. Fotoğraf ekleyin.
9. Dijital imza alın.
10. Bakımı tamamlayın.
11. Merkezden tamamlanan kaydı kontrol edin.
12. Aynı asansöre bir arıza kaydı açın.
13. Arızayı farklı teknisyene atayın.
14. Arıza sonucunu kaydedin.
15. Asansörün bakım ve arıza geçmişini birlikte inceleyin.

Bu test 30 farklı özelliği slayttan dinlemekten daha değerlidir. Çünkü sistemin modüllerinin birbirleriyle gerçekten bağlantılı çalışıp çalışmadığını gösterir.

Ayrıca teknik şartname sabit bir mevzuat metni gibi hazırlanmamalıdır. Asansör alanındaki düzenlemeler zaman içinde güncellenebilir; örneğin Asansör Periyodik Kontrol Yönetmeliğinde 5 Ağustos 2025 tarihinde değişiklik yayımlanmıştır. ([Resmi Gazete][2]) Bu nedenle şartnamede mevzuat adı kullanılacaksa yazılım sağlayıcısından gelecekteki değişikliklerin ürüne nasıl yansıtıldığı da sorulmalıdır.

Sıkça Sorulan Sorular

Asansör saha programı teknik şartnamesi kaç maddeden oluşmalıdır?

Sabit bir sayı yoktur. Küçük bir bakım firmasında 20–30 net gereksinim yeterli olabilirken çok ekipli ve yüksek asansör portföyüne sahip firmalarda kapsam büyüyebilir. Önemli olan madde sayısı değil, her maddenin gerçek bir operasyon ihtiyacını karşılamasıdır.

Teknik şartnamede her özellik zorunlu yapılmalı mı?

Hayır. Özellikler "zorunlu", "tercih sebebi" ve "gelecekte gerekli olabilir" şeklinde sınıflandırılabilir. Aksi hâlde firma hiç kullanmayacağı özellikler nedeniyle daha karmaşık veya maliyetli bir sistem seçebilir.

Mobil uygulama teknik şartnamede zorunlu olmalı mı?

Saha personelinin bakım ve arıza işlemlerini bina başında tamamlaması hedefleniyorsa mobil kullanım temel gereksinimlerden biridir. Yalnızca masaüstü çalışan bir sistem, saha ile ofis arasında tekrar veri girişine neden olabilir.

Konum takibi mutlaka gerekli midir?

Her firma için sürekli konum takibi gerekli değildir. Bazı firmalar yalnızca bakım veya servis işleminin hangi konumda tamamlandığını görmek isteyebilir. Teknik şartname hazırlanırken hangi konum verisine gerçekten ihtiyaç duyulduğu belirlenmelidir.

Yazılımın periyodik muayene etiketlerini takip etmesi faydalı mıdır?

Evet. Yeşil, mavi, sarı ve kırmızı bilgi etiketi durumlarının asansör kartında takip edilebilmesi operasyon planlamasını kolaylaştırabilir. Ancak yazılım kaydı, A tipi muayene kuruluşunun gerçekleştirdiği resmi periyodik kontrolün yerine geçmez. TSE de periyodik kontroller ile bilgi etiketi uygulamasını ayrı bir kontrol süreci olarak açıklamaktadır. ([Türkiye Sıhhiye Raporu][1])

Teknik şartname hazırladıktan sonra doğrudan satın alma yapılmalı mı?

Mümkünse önce gerçek veriye benzeyen küçük bir senaryoyla demo veya pilot test yapılmalıdır. Özellikle bakım atama, teknisyen kullanımı, fotoğraf, imza, raporlama ve veri aktarımı canlı olarak denenmelidir.

Özet

İyi hazırlanmış bir asansör saha programı teknik şartname, yazılım satın alma sürecini "hangi programda daha fazla özellik var?" karşılaştırmasından çıkarıp "hangi sistem bizim operasyonumuzu gerçekten yönetebiliyor?" sorusuna taşır.

Şartnamede özellikle mobil kullanım, bakım ve arıza yönetimi, teknisyen atama, fotoğraf, dijital imza, konum, geçmiş kayıtlar, raporlama, kullanıcı yetkilendirme, veri aktarımı ve yedekleme konuları açık biçimde tanımlanmalıdır. Her mümkün özellik için şart koymak yerine, firmanın gerçek iş akışını destekleyen kriterlere öncelik verilmelidir.

Satın alma öncesinde şartnamedeki maddeleri tek tek işaretlemek de yeterli değildir. Müşteri oluşturma, asansör ekleme, bakım planlama, teknisyene atama, sahada form doldurma ve işi kapatma gibi gerçek bir operasyon senaryosu baştan sona test edilmelidir.

Asansorex gibi asansör sektörüne özel geliştirilen saha ve bakım yönetim çözümleri değerlendirilirken de aynı yöntem uygulanabilir: özellik listesinden çok, firmanızın günlük bakım ve arıza akışının sistem üzerinde ne kadar eksiksiz yürütülebildiğine bakmak daha doğru bir satın alma kararı verir.