Asansör Bakım Programı İçin İhtiyaç Analizi Şablonu

İÇERİK

Asansör bakım programı seçerken yapılan en yaygın hatalardan biri, doğrudan yazılım özelliklerini karşılaştırmaya başlamaktır. Firma sahibi onlarca özellik içeren bir sunum görür, teknisyen mobil uygulamanın kullanımına bakar, muhasebe tarafı cari takibi sorar ve sonunda herkes farklı beklentilerle karar vermeye çalışır. Oysa doğru sıralama bunun tersidir: Önce firmanın ihtiyacı belirlenmeli, daha sonra yazılım bu ihtiyaçlara göre değerlendirilmelidir.

İyi hazırlanmış bir ihtiyaç analizi, yalnızca hangi özelliklerin gerekli olduğunu göstermez. Kullanılmayacak modüllere para harcanmasını, kritik bir fonksiyonun satın alma sonrasında eksik olduğunun fark edilmesini ve teknisyenlerin kullanmak istemediği karmaşık bir sisteme geçilmesini de önler.

Aşağıdaki şablon, küçük bir bakım firmasından yüzlerce asansörlük portföy yöneten işletmelere kadar kullanılabilecek şekilde hazırlanmıştır. Amaç, satın alma görüşmesine başlamadan önce firmanın bakım, arıza, saha, finans, stok ve raporlama süreçlerini somut olarak ortaya çıkarmaktır.

İhtiyaç Analizine Mevcut Sistemi Yazarak Başlayın

İlk soru "Yeni programda hangi özellikler olsun?" değildir. Önce bugün işlerin nasıl yürütüldüğünü yazmak gerekir.

Birçok asansör firmasında bilgiler birkaç farklı yerde tutulur:

• Bakım listeleri Excel dosyasında,
• Arızalar WhatsApp grubunda,
• Tahsilatlar muhasebe programında veya defterde,
• Teklifler Word ve PDF dosyalarında,
• Teknisyenlerin yaptığı işlemler kâğıt föylerde,
• Müşteri telefonları personelin telefon rehberinde,
• Stok durumu ise depo sorumlusunun bilgisinde olabilir.

Bu yapı küçük bir portföyde yönetilebilir görünse de iş hacmi büyüdükçe bilgi dağınıklığı ciddi zaman kaybına dönüşür.

İhtiyaç analizinin ilk bölümüne şu soruları yazın:

1. Kaç asansöre düzenli bakım hizmeti veriyoruz?
2. Kaç aktif teknisyenimiz var?
3. Aylık ortalama kaç bakım gerçekleştiriyoruz?
4. Aylık ortalama kaç arıza kaydı geliyor?
5. Bakım planlarını bugün nerede tutuyoruz?
6. Arıza talepleri hangi kanallardan geliyor?
7. Teknisyenin yaptığı işlemi nasıl doğruluyoruz?
8. Tahsilat ve cari hesapları nerede takip ediyoruz?
9. Sözleşme yenileme tarihlerini nasıl kontrol ediyoruz?
10. Yönetici olarak gün sonunda hangi bilgileri göremiyoruz?

Bu soruların cevapları mevcut operasyonun fotoğrafını ortaya çıkarır.

İhtiyaç analizi yaparken yalnızca bugün yaşanan problemleri değil, firmanın önümüzdeki 1–2 yıl içinde ulaşabileceği iş hacmini de düşünmek gerekir.

Örneğin bugün 120 asansöre hizmet veren ancak kısa sürede 250 asansöre çıkmayı hedefleyen bir firma, yalnızca bugünkü iş yüküne göre sistem seçmemelidir.

Bakım Planlama İhtiyacını Belirleyin

Asansör bakım firmasının en temel operasyonu periyodik bakımdır. Bu nedenle ihtiyaç analizinin önemli bir bölümü bakım planlamasına ayrılmalıdır.

İlk olarak mevcut planlama yöntemini değerlendirin.

Örneğin şu sorunlardan hangileri yaşanıyor?

• Aylık bakım planında unutulan binalar oluyor.
• Teknisyen değiştiğinde bakım listelerini yeniden düzenlemek zorlaşıyor.
• Tamamlanan ve bekleyen bakımlar anlık görülemiyor.
• Teknisyenin gerçekten binaya gidip gitmediği kontrol edilemiyor.
• Bakım formu ofise geç ulaşıyor.
• Müşteri geçmiş bakım kayıtlarını istediğinde belge bulmak zaman alıyor.
• Aynı binaya gereksiz tekrar ziyaretleri gerçekleşiyor.

Bu sorunlardan birkaç tanesi bile düzenli yaşanıyorsa bakım planlama modülü satın alma kararında yüksek öncelikli olmalıdır.

Bakım modülü için kontrol listesi

Bir programdan aşağıdaki fonksiyonlardan hangilerini beklediğinizi işaretleyebilirsiniz:

İhtiyaç	Öncelik	Gerekli mi?
Aylık bakım planı oluşturma	Yüksek	Evet/Hayır
Teknisyene bakım atama	Yüksek	Evet/Hayır
Mobil cihazdan bakım kapatma	Yüksek	Evet/Hayır
Bakım kontrol formu	Yüksek	Evet/Hayır
Fotoğraf ekleme	Orta	Evet/Hayır
Müşteri imzası alma	Orta	Evet/Hayır
Geçmiş bakım kayıtlarını görüntüleme	Yüksek	Evet/Hayır
Bakım raporu oluşturma	Orta	Evet/Hayır
Tamamlanmayan bakımları takip etme	Yüksek	Evet/Hayır
Bakım sonrası tahsilat kaydı	Orta	Evet/Hayır

Burada önemli olan her satıra otomatik olarak "Evet" yazmak değildir. Gerçekten kullanılacak özellikleri belirlemektir.

Örneğin iki teknisyenli ve 70 asansörlük bir firma için gelişmiş ekip dağılım raporları düşük öncelikli olabilir. Buna karşılık 15 teknisyen ve 700 asansörlük bir portföyde iş yükü dağılımı kritik hale gelebilir.

Arıza Yönetimi İçin Gerçek Senaryoları Çıkarın

Arıza yönetimi, yazılım demosunda yalnızca "arıza kaydı açılabiliyor mu?" sorusuyla değerlendirilmemelidir.

Gerçek operasyon daha karmaşıktır.

Örnek bir senaryo düşünelim:

Saat 18.20'de bina yöneticisi arayıp asansörün çalışmadığını bildiriyor. Ofisteki personel kaydı oluşturuyor. Bölgedeki teknisyen bilgilendiriliyor. Teknisyen binaya gidiyor, kapı kilidi problemi tespit ediyor, işlemi gerçekleştiriyor ve arızayı kapatıyor.

İhtiyaç analizi burada şu ayrıntıları sorgulamalıdır:

• Arızayı kim kaydetti?
• Hangi binada oluştu?
• Bildirim saati nedir?
• Hangi teknisyen görevlendirildi?
• Teknisyen ne zaman müdahale etti?
• Arıza nedeni neydi?
• Hangi işlem uygulandı?
• Parça kullanıldı mı?
• Ücret tahsil edildi mi?
• Müşteri bilgilendirildi mi?
• Aynı asansörde daha önce benzer arıza yaşandı mı?

Bu soruların cevaplarını sistematik biçimde tutabiliyorsanız arıza geçmişi zamanla değerli bir teknik veri tabanına dönüşür.

Örneğin aynı asansörde üç ay içinde beş kez kapı kaynaklı arıza oluşuyorsa sorun artık tekil bir servis çağrısı değil, analiz edilmesi gereken tekrar eden bir problemdir.

Bu nedenle ihtiyaç listesinde arıza geçmişi, müdahale süresi ve tekrar eden arıza analizi gibi maddelerin bulunması yararlı olur.

Teknisyenlerin Sahadaki İhtiyaçlarını Ayrı Değerlendirin

Firma sahibinin istediği program ile teknisyenin kullanabileceği program her zaman aynı değildir.

Yönetici ayrıntılı raporlar görmek isteyebilir ancak teknisyenin sahada temel ihtiyacı hızlı işlem yapabilmektir. Bu nedenle saha ekibinin ihtiyaç analizi ayrıca yapılmalıdır.

Teknisyen açısından şu sorular önemlidir:

• Bugünkü işlerimi telefondan görebiliyor muyum?
• Bina adresine ve iletişim bilgisine kolay ulaşabiliyor muyum?
• Bakım formunu sahada doldurabiliyor muyum?
• Fotoğraf ekleyebiliyor muyum?
• Arızada yapılan işlemi birkaç adımda kaydedebiliyor muyum?
• Kullanılan parçayı sisteme işleyebiliyor muyum?
• Müşteri imzasını alabiliyor muyum?
• Tahsilat yaptıysam kaydedebiliyor muyum?
• Önceki bakım veya arıza geçmişini görebiliyor muyum?

Bir sistem teknik olarak çok güçlü olabilir ancak saha personelinin günlük işini zorlaştırıyorsa kullanım oranı düşebilir.

Bu nedenle mümkünse satın alma öncesinde en az bir teknisyenle gerçek bir senaryo test edilmelidir. Örneğin örnek bir bina açılarak bakım başlatma, form doldurma, fotoğraf ekleme ve işlemi kapatma süreci uygulanabilir.

Asansorex gibi bakım takip yazılımları bu noktada bakım, arıza ve saha kayıtlarının aynı süreç içinde tutulmasına yardımcı olabilir. Ancak hangi modüllerin kullanılacağı yine firmanın kendi iş akışına göre belirlenmelidir.

Cari, Tahsilat ve Sözleşme İhtiyaçlarını Unutmayın

Asansör firmalarında operasyon ile finans birbirinden tamamen ayrı değildir. Yapılan bakım, arıza veya parça değişiminin çoğu zaman finansal bir karşılığı vardır.

Bu nedenle ihtiyaç analizinde yalnızca teknik süreçlere odaklanmak eksik değerlendirme oluşturur.

Şu soruları cevaplayın:

Cari hesap

• Hangi müşterinin ne kadar borcu olduğunu görebiliyor muyuz?
• Tahsilat geçmişi düzenli tutuluyor mu?
• Bina bazında borç takibi gerekiyor mu?
• Yapılan işlem otomatik olarak cariye yansıtılmalı mı?

Sözleşme

• Kaç aktif bakım sözleşmemiz var?
• Sözleşme başlangıç ve bitiş tarihlerini takip ediyor muyuz?
• Yaklaşan yenilemeleri önceden görmek istiyor muyuz?
• Sözleşme fiyatlarını ve kapsamlarını sistemde saklamak gerekiyor mu?

Teklif

• Revizyon tekliflerini nasıl hazırlıyoruz?
• Eski teklifleri kolay bulabiliyor muyuz?
• Hangi tekliflerin kabul veya reddedildiğini biliyor muyuz?
• Teklif sonrasında müşteriye dönüş yapmayı unutuyor muyuz?

Buradaki temel amaç bir ön muhasebe sistemi satın almak değil, firmanın operasyonuyla finansı arasında hangi bağlantıların gerekli olduğunu belirlemektir.

Örneğin teknisyen ücretli bir arızayı tamamladığında bu işlemin ofis tarafından tekrar Excel'e yazılması gerekiyorsa çift veri girişi vardır. İhtiyaç analizinde bu durum açık biçimde yazılmalıdır.

Stok ve Malzeme Takibi Gerçekten Gerekli mi?

Stok modülü, özellik listelerinde cazip görünen ancak ihtiyaç analizinde dikkatle değerlendirilmesi gereken alanlardan biridir.

Küçük firmalarda yalnızca temel birkaç parçanın takibi yeterli olabilir. Daha büyük firmalarda ise merkez depo, araç deposu ve teknisyen zimmeti gibi süreçler önem kazanabilir.

Şu soruları sorun:

• Kaç farklı parçayı düzenli olarak stokluyoruz?
• Hangi parçanın hangi araçta olduğunu bilmemiz gerekiyor mu?
• Teknisyen kullandığı parçayı sahadan düşmeli mi?
• Kritik stok seviyesi uyarısı gerekli mi?
• Tedarikçiden yapılan alışları takip etmek istiyor muyuz?
• Bir arızada hangi parçanın kullanıldığını sonradan görmek önemli mi?

Eğer stok kayıpları, unutulan malzemeler veya gereksiz tekrar alımlar ciddi maliyet oluşturuyorsa stok yönetimine yüksek öncelik verilmelidir.

Ancak stok hareketi çok düşük olan küçük bir firma için ilk aşamada bakım, arıza ve cari yönetimi daha kritik olabilir.

İhtiyaçları "Olmazsa Olmaz" ve "Olsa İyi Olur" Diye Ayırın

İhtiyaç analizindeki en önemli adımlardan biri önceliklendirmedir.

Her özellik aynı değerde değildir.

Basit bir puanlama sistemi kullanılabilir:

• 3 puan: Olmazsa olmaz
• 2 puan: Önemli
• 1 puan: Olsa iyi olur
• 0 puan: Şu anda gerekli değil

Örnek:

Özellik	Puan
Bakım planlama	3
Mobil teknisyen kullanımı	3
Arıza atama	3
Cari takip	3
Sözleşme hatırlatma	2
Fotoğraflı bakım kaydı	2
Stok yönetimi	2
Müşteri portalı	1
Gelişmiş KPI raporları	1

Bu tablo satın alma görüşmesini ciddi biçimde kolaylaştırır.

Bir yazılım 40 özellik sunabilir fakat firmanızın 3 puan verdiği beş temel ihtiyacın ikisini karşılamıyorsa doğru seçim olmayabilir.

Buna karşılık daha sade görünen başka bir sistem kritik ihtiyaçların tamamını karşılıyorsa operasyon açısından daha değerli olabilir.

Demo Görüşmesini İhtiyaç Listesine Göre Yapın

İhtiyaç analizi tamamlandıktan sonra yazılım demosu pasif bir sunum olmaktan çıkar.

Satıcıya "Programınızı anlatır mısınız?" demek yerine gerçek senaryolar üzerinden ilerleyebilirsiniz.

Örneğin şu testleri yaptırın:

1. Yeni bir bina ve asansör oluşturun.
2. Bu asansör için bakım planlayın.
3. Bakımı bir teknisyene atayın.
4. Teknisyen tarafından mobil cihazdan bakım işlemini tamamlayın.
5. Bakım formu ve fotoğraf ekleyin.
6. Bir arıza kaydı oluşturup teknisyene atayın.
7. Kullanılan parçayı kaydedin.
8. İşlemi müşterinin cari hesabına yansıtın.
9. Geçmiş bakım ve arıza kayıtlarını açın.
10. Yönetici olarak tamamlanan ve bekleyen işleri görüntüleyin.

Bu yöntem katalogdaki özellikleri değil, gerçek iş akışını test eder.

Ayrıca eğitim, veri aktarımı ve teknik destek gibi konular da ihtiyaç analizine eklenmelidir. Çünkü iyi bir yazılımın başarısı yalnızca özellik sayısına değil, firmanın sistemi ne kadar hızlı kullanmaya başlayabildiğine de bağlıdır.

Hazır İhtiyaç Analizi Şablonu

Satın alma öncesinde aşağıdaki kısa şablonu doldurabilirsiniz:

Firma bilgileri

• Aktif asansör sayısı:
• Aktif bakım sözleşmesi sayısı:
• Teknisyen sayısı:
• Ofis kullanıcı sayısı:
• Aylık ortalama bakım:
• Aylık ortalama arıza:
• Mevcut kullanılan sistem:

En büyük üç problem

1. 2. 3.

Olmazsa olmaz özellikler

* * * * *

İkinci öncelikli özellikler

* * * *

Mobil kullanım ihtiyacı

• Bakım kapatma:
• Arıza kapatma:
• Fotoğraf:
• İmza:
• Tahsilat:
• Parça kullanımı:

Finansal takip

• Cari hesap:
• Tahsilat:
• Faturalandırma:
• Teklif:
• Sözleşme:

Yönetim raporları

• Tamamlanan bakımlar:
• Eksik bakımlar:
• Açık arızalar:
• Teknisyen performansı:
• Alacak durumu:
• Sözleşme yenilemeleri:

Bu şablon doldurulduğunda yazılım sağlayıcılarından gelen teklifleri aynı kriterlerle karşılaştırmak çok daha kolay hale gelir.

Sıkça Sorulan Sorular

Asansör bakım programı almadan önce ihtiyaç analizi yapmak şart mı?

Zorunlu değildir ancak yanlış yazılım seçme riskini ciddi biçimde azaltır. Özellikle bakım, arıza, saha ve finans süreçleri farklı araçlarda yürütülüyorsa ihtiyaçların satın alma öncesinde yazılı hale getirilmesi faydalıdır.

İhtiyaç analizini firma sahibi tek başına yapabilir mi?

Firma sahibi süreci başlatabilir fakat en sağlıklı sonuç için en az bir teknisyen ve mümkünse ofiste operasyonla ilgilenen personelin görüşü alınmalıdır. Çünkü saha ve ofis ihtiyaçları birbirinden farklı olabilir.

Küçük asansör firmalarının da bakım yazılımına ihtiyacı var mı?

Portföy küçüklüğü tek başına belirleyici değildir. Bakımlar unutuluyor, arıza kayıtları kayboluyor, tahsilatlar karışıyor veya müşteri geçmişine ulaşmak zaman alıyorsa dijital takip küçük firmalarda da fayda sağlayabilir.

Yazılım seçiminde özellik sayısı önemli mi?

Tek başına önemli değildir. Yüzlerce özellik sunan fakat firmanın temel iş akışını zorlaştıran bir sistem yerine kritik ihtiyaçları hızlı ve anlaşılır şekilde karşılayan bir çözüm daha verimli olabilir.

Demo sırasında nelere dikkat edilmelidir?

Hazır sunum yerine gerçek bir senaryo test edilmelidir. Bakım oluşturma, teknisyene atama, mobil kapatma, arıza kaydı, cari yansıtma ve geçmiş kayıtlara ulaşma gibi günlük işlemler doğrudan denenmelidir.

İhtiyaçlar zamanla değişirse ne yapılmalı?

İhtiyaç analizi yılda en az bir kez veya portföy, personel ya da iş modeli ciddi biçimde değiştiğinde yeniden gözden geçirilebilir. Firmanın büyümesiyle birlikte raporlama, stok, rota veya yetkilendirme gibi daha önce düşük öncelikli alanlar önemli hale gelebilir.

Özet

Doğru asansör bakım programını seçmenin başlangıç noktası yazılım özellikleri değil, firmanın gerçek operasyonudur. Kaç asansöre hizmet verdiğiniz, teknisyenlerin sahada nasıl çalıştığı, arızaların nasıl kaydedildiği, tahsilatların nasıl izlendiği ve hangi bilgileri zamanında göremediğiniz netleşmeden yapılan yazılım karşılaştırması yanıltıcı olabilir.

İhtiyaçları önce "olmazsa olmaz", "önemli" ve "olsa iyi olur" şeklinde sınıflandırmak; daha sonra demoda bu süreçleri gerçek senaryolarla test etmek en sağlıklı yöntemdir. Bakım, arıza, cari, sözleşme ve saha süreçlerini tek yerde takip etmek isteyen firmalar Asansorex gibi sektöre yönelik çözümleri de aynı ihtiyaç listesi üzerinden değerlendirebilir. Böylece karar, özellik sayısına veya satış sunumuna göre değil, firmanın günlük operasyonuna sağlayacağı gerçek katkıya göre verilir.