Asansör Arıza Programı Satın Alma Brief Şablonu

İÇERİK

Asansör arıza yönetimini dijitalleştirmek isteyen bir bakım firması için en kritik aşamalardan biri, yazılım demosundan önce neye ihtiyaç duyulduğunu net biçimde tanımlamaktır. Aksi halde demo sırasında etkileyici görünen onlarca özellik arasında asıl operasyon ihtiyacı kaybolabilir. Sonuçta firma, arıza kayıtlarını hızlandırmak için aldığı bir programın sahadaki teknisyene ek iş çıkardığını veya raporlama açısından yetersiz kaldığını aylar sonra fark edebilir.

Bu nedenle bir asansör arıza programı satın alma briefi, yalnızca satın alma departmanının kullanacağı bir doküman değildir. Firma sahibi, operasyon sorumlusu, teknisyenler ve gerektiğinde muhasebe ekibinin beklentilerini aynı çerçevede toplar. Böylece farklı yazılımlar fiyatına göre değil, gerçek operasyon ihtiyacına göre karşılaştırılabilir.

Aşağıdaki şablon, özellikle arıza yönetimi güçlü bir yazılım arayan asansör firmalarının demo ve teklif süreçlerinde kullanabileceği pratik bir değerlendirme yapısı sunar.

Satın Alma Briefi Neden Hazırlanmalı?

Bir yazılım arayışına doğrudan "Hangi program daha iyi?" sorusuyla başlamak çoğu zaman doğru sonuç vermez. Çünkü iyi yazılım kavramı firmadan firmaya değişir.

Örneğin 80 asansöre bakım veren üç kişilik bir işletmenin ihtiyacı ile 1.500 asansöre hizmet veren, farklı ilçelerde ekipleri bulunan bir firmanın ihtiyacı aynı değildir.

Bir firma için temel beklenti:

• Gelen arızanın kaybolmaması,
• Teknisyene hızlı atanması,
• Müşteriye bilgi verilmesi,
• Arıza sonucunun kaydedilmesi

olabilir.

Daha büyük bir işletmede ise bunlara ek olarak:

• Bölge bazlı teknisyen atama,
• Arıza önceliklendirme,
• Müdahale süresinin ölçülmesi,
• Tekrarlayan arıza analizi,
• Personel performansının karşılaştırılması,
• Parça kullanımının kaydedilmesi,
• Arıza sonrası tahsilat takibi

gibi beklentiler ortaya çıkar.

Brief hazırlamanın temel faydası, bu ihtiyaçların satın alma görüşmesinden önce yazılı hale getirilmesidir.

İyi hazırlanmış bir brief, "Programda hangi özellikler var?" sorusunu "Bizim şu sürecimizi nasıl çözüyor?" sorusuna dönüştürür.

Bu küçük yaklaşım değişikliği, yanlış yazılım seçme riskini ciddi biçimde azaltır.

Mevcut Arıza Sürecini Önce Haritalandırın

Program satın almadan önce ilk yapılması gereken iş, mevcut arıza sürecinin nasıl ilerlediğini çıkarmaktır.

Örneğin tipik bir bakım firmasında süreç şu şekilde olabilir:

1. Bina yöneticisi firmayı telefonla veya WhatsApp üzerinden arar.
2. Ofisteki çalışan arıza bilgisini not alır.
3. Uygun teknisyen aranır.
4. Arıza adresi ve açıklaması teknisyene gönderilir.
5. Teknisyen binaya gider.
6. Müdahale gerçekleştirilir.
7. Sonuç telefon veya mesaj yoluyla ofise bildirilir.
8. Gerekirse parça veya servis ücreti müşterinin hesabına işlenir.

Bu süreç basit görünse de günlük arıza sayısı arttığında birçok problem oluşabilir.

Örneğin:

• Arıza WhatsApp mesajları arasında unutulabilir.
• Aynı arıza iki farklı teknisyene gönderilebilir.
• Teknisyen arızayı çözdüğünü bildirmeyi unutabilir.
• Arızanın ne zaman açıldığı bilinmeyebilir.
• Müdahale süresi ölçülemez.
• Kullanılan parçalar kayıt altına alınmayabilir.
• Aynı asansörde tekrar eden arızalar fark edilmeyebilir.

Satın alma briefinde bu problemlerin açıkça belirtilmesi gerekir.

Brief İçin Mevcut Durum Soruları

Firmanız için şu soruları yanıtlayın:

• Aylık ortalama kaç arıza kaydı geliyor?
• Arızalar hangi kanallardan alınıyor?
• Kaç teknisyen aktif olarak arızalara müdahale ediyor?
• Teknisyen atamasını kim yapıyor?
• Arıza öncelikleri nasıl belirleniyor?
• Arıza kapanışı nasıl kayıt altına alınıyor?
• Fotoğraf veya imza gerekiyor mu?
• Kullanılan parçalar kaydediliyor mu?
• Müşteriye arıza durumu bildiriliyor mu?
• Müdahale süresi ölçülüyor mu?

Bu cevaplar, satın alınacak yazılımın kapsamını belirler.

Asansör Arıza Programı İçin Temel Gereksinimler

Briefin en önemli bölümü, "olmazsa olmaz" özelliklerin açık şekilde listelenmesidir.

Her yazılımda yüzlerce özellik bulunabilir. Ancak satın alma kararında kritik olan, günlük operasyonu doğrudan etkileyen fonksiyonlardır.

Aşağıdaki tablo temel bir başlangıç noktası olarak kullanılabilir.

Gereksinim	Öncelik	Kontrol Edilecek Nokta
Arıza kaydı oluşturma	Çok yüksek	Telefon ve ofis üzerinden hızlı kayıt
Teknisyen atama	Çok yüksek	Arızanın personele anında iletilmesi
Mobil kullanım	Çok yüksek	Teknisyenin telefondan işlem yapabilmesi
Arıza durum takibi	Çok yüksek	Açık, atanmış, müdahalede, kapalı durumları
Fotoğraf ekleme	Yüksek	Müdahale öncesi/sonrası kayıt
Dijital imza	Orta/Yüksek	Yönetici veya görevli onayı
Tekrarlayan arıza raporu	Yüksek	Aynı asansörde sık yaşanan sorunların tespiti
Konum bilgisi	Orta/Yüksek	Saha operasyonunun doğrulanması
Parça kaydı	Yüksek	Arızada kullanılan malzemenin kaydı
Tahsilat bağlantısı	Orta	Ücretli müdahalelerin cari hesaba aktarılması
SMS/mesaj bildirimi	Orta	Bina yöneticisinin bilgilendirilmesi
Arıza geçmişi	Çok yüksek	Asansör bazında geçmiş kayıtların görüntülenmesi

Firma kendi yapısına göre bu listeyi genişletebilir.

Burada önemli olan her özelliğin "var/yok" şeklinde değerlendirilmemesidir. Özelliğin sahada nasıl çalıştığı mutlaka görülmelidir.

Örneğin bir programda fotoğraf özelliği bulunabilir ancak teknisyen fotoğraf yüklemek için beş ayrı ekrana girmek zorunda kalıyorsa saha kullanımında ciddi zaman kaybı oluşabilir.

Satın Alma Briefinde Operasyon Senaryolarını Yazın

Yazılım firmalarından yalnızca özellik listesi istemek yerine gerçek saha senaryolarını göstermelerini istemek daha sağlıklı sonuç verir.

Örneğin briefte şu senaryo bulunabilir:

Senaryo 1: Acil Arıza Kaydı

Saat 18.30'da bir bina yöneticisi arıyor ve asansörün çalışmadığını bildiriyor.

Yazılımın şu süreci göstermesi istenir:

1. Arıza kaydı nasıl açılıyor?
2. Bina ve asansör nasıl seçiliyor?
3. Uygun teknisyen nasıl atanıyor?
4. Teknisyene bildirim nasıl gidiyor?
5. Teknisyen adres ve iletişim bilgisine nasıl ulaşıyor?
6. Arıza sonucu nasıl kaydediliyor?
7. Fotoğraf eklenebiliyor mu?
8. Arıza kapandığında ofis bilgi alıyor mu?

Bu senaryo sırasında programın gerçek kullanım kolaylığı çok daha net ortaya çıkar.

Senaryo 2: Tekrarlayan Arıza

Aynı asansörde son iki ay içinde beş kez kapı arızası yaşandığını düşünelim.

Program şu sorulara cevap verebilmelidir:

• Önceki arızalar görülebiliyor mu?
• Hangi teknisyenlerin müdahale ettiği görülebiliyor mu?
• Kullanılan parçalar kayıtlı mı?
• Arıza kategorileri karşılaştırılabiliyor mu?
• Tekrarlayan arızalar raporlanabiliyor mu?

Bu özellik, firma sahipleri açısından özellikle önemlidir. Çünkü tekrar eden arızalar yalnızca teknik problem değil, aynı zamanda işçilik, yakıt, müşteri memnuniyeti ve kârlılık problemi oluşturur.

Arıza geçmişini Asansorex gibi bir bakım ve arıza takip yazılımında asansör bazında tutmak, teknisyenin sahaya gitmeden önce önceki müdahaleleri görmesini ve benzer sorunları daha hızlı değerlendirmesini sağlayabilir.

Teknik ve Ticari Kriterleri Ayrı Değerlendirin

Satın alma sırasında sık yapılan hatalardan biri yalnızca lisans fiyatına bakmaktır.

Düşük maliyetli görünen bir yazılım; veri aktarımı, eğitim, ek kullanıcı, SMS, destek veya sonraki yıl yenileme ücretleri nedeniyle toplamda daha pahalı hale gelebilir.

Bu nedenle briefte ticari koşullar için ayrı bir bölüm bulunmalıdır.

Sorulması Gereken Ticari Sorular

• Lisans aylık mı, yıllık mı?
• Kullanıcı sayısı fiyatı değiştiriyor mu?
• Asansör sayısına göre ek ücret bulunuyor mu?
• Mobil uygulama ayrıca ücretli mi?
• Kurulum ücreti var mı?
• Mevcut verilerin aktarımı ücretli mi?
• Eğitim pakete dahil mi?
• Teknik destek ek ücretli mi?
• SMS veya benzeri bildirimler kontörlü mü?
• Gelecek yıl yenileme fiyatı nasıl belirleniyor?
• Yazılım bırakıldığında veriler dışarı aktarılabiliyor mu?
• Yedekleme politikası nedir?

Bu sorular sayesinde teklifleri yalnızca ilk yıl fiyatına göre değil, toplam sahip olma maliyetine göre değerlendirmek mümkün olur.

Demo Görüşmesinde Kullanılabilecek Hazır Brief Şablonu

Aşağıdaki metin doğrudan firmanızın satın alma dokümanına uyarlanabilir.

Firma Bilgileri

Firma adı: Bakımı yapılan yaklaşık asansör sayısı: Aktif teknisyen sayısı: Şube sayısı: Aylık ortalama arıza sayısı: Mevcut kullanılan sistem:

Projenin Amacı

Arıza kayıtlarının telefon, WhatsApp ve kişisel notlardan çıkarılarak merkezi bir sistem üzerinden yönetilmesi; teknisyen atama, saha müdahalesi, arıza geçmişi ve raporlama süreçlerinin ölçülebilir hale getirilmesi.

Öncelikli Problemler

• Arıza kayıtlarının farklı kanallarda dağılması
• Teknisyen atamalarının manuel yapılması
• Arıza kapanış bilgilerinin eksik kalması
• Müdahale sürelerinin ölçülememesi
• Tekrar eden arızaların takip edilememesi
• Fotoğraf ve müdahale kanıtlarının düzenli saklanamaması

Olmazsa Olmaz Özellikler

• Mobil arıza yönetimi
• Teknisyen atama
• Arıza durum takibi
• Asansör bazında arıza geçmişi
• Fotoğraf ekleme
• Müdahale açıklaması
• Personel bazlı kayıt
• Arıza raporlama
• Müşteri ve bina bilgilerine mobil erişim

Tercih Edilen Özellikler

• SMS veya mesaj bildirimi
• Dijital imza
• Konum kaydı
• Parça/stok bağlantısı
• Tahsilat kaydı
• Tekrarlayan arıza analizi
• Müşteri portalı

Teknik Beklentiler

• Web ve mobil kullanım
• Kolay arayüz
• Düzenli yedekleme
• Veri dışa aktarma
• Yetkilendirme
• Düzenli güncelleme
• Teknik destek

Demo Sırasında Gösterilmesi İstenen Süreç

Arıza oluştur → Teknisyen ata → Teknisyen mobil bildirim alsın → Müdahale kaydı girsin → Fotoğraf eklesin → Arızayı kapatsın → Ofis sonucu görsün

Bu akışın mümkünse örnek ekranlarla değil, gerçek çalışan sistem üzerinde gösterilmesi istenmelidir.

Yazılımları Puanlama Sistemiyle Karşılaştırın

Birden fazla program inceleniyorsa değerlendirmeyi hafızaya bırakmak doğru değildir.

Basit bir 5 puanlı sistem kullanılabilir:

• 1: Yetersiz
• 2: Zayıf
• 3: Kabul edilebilir
• 4: İyi
• 5: Çok iyi

Örneğin üç farklı yazılım için şu kriterler puanlanabilir:

• Kullanım kolaylığı
• Mobil uygulama
• Arıza kayıt hızı
• Teknisyen atama
• Arıza geçmişi
• Raporlama
• Destek kalitesi
• Eğitim
• Veri güvenliği
• Toplam maliyet

Özellikle saha ekibinden en az bir teknisyenin değerlendirme sürecine katılması faydalıdır. Ofiste kolay görünen bir işlem mobil cihazda gereğinden fazla adım gerektirebilir.

Mümkünse karar vermeden önce küçük bir pilot kullanım yapılmalıdır. Örneğin bir ekip veya sınırlı sayıda bina üzerinde birkaç gün gerçek arıza kaydı oluşturularak programın günlük operasyonla uyumu test edilebilir.

Sıkça Sorulan Sorular

Asansör arıza programı satın alma briefi kim tarafından hazırlanmalı?

Briefi yalnızca firma sahibi hazırlamamalıdır. Operasyon sorumlusu ve en az bir saha teknisyeninin görüşü alınmalıdır. Muhasebe veya tahsilat entegrasyonu kullanılacaksa ilgili personelin beklentileri de eklenebilir.

Demo sırasında en önemli kontrol noktası nedir?

Programın gerçek bir arıza senaryosunda kaç adımda çalıştığı görülmelidir. Arıza oluşturma, teknisyen atama, mobil müdahale ve kapanış süreci baştan sona gösterilmelidir.

En fazla özelliği olan program mı tercih edilmeli?

Hayır. Kullanılmayan onlarca özellik yerine firmanın günlük iş akışını hızlı ve sorunsuz yöneten bir sistem daha değerlidir. Özellikle saha kullanım kolaylığı öncelikli değerlendirilmelidir.

Arıza geçmişi neden önemli?

Geçmiş kayıtlar aynı asansörde tekrar eden teknik sorunların görülmesini sağlar. Ayrıca yeni görevlendirilen teknisyen, önceki müdahaleleri inceleyerek sahaya daha hazırlıklı gidebilir.

Fiyat karşılaştırması nasıl yapılmalı?

Yalnızca lisans fiyatı karşılaştırılmamalıdır. Kurulum, eğitim, destek, kullanıcı, SMS, veri aktarımı ve yenileme gibi ek maliyetlerle birlikte yıllık toplam maliyet değerlendirilmelidir.

Asansorex bu süreçte nasıl kullanılabilir?

Asansorex, bakım ve arıza süreçlerini aynı yapı içinde takip etmek isteyen firmalarda arıza kaydı, teknisyen atama, saha kapanışı ve geçmiş kayıtların merkezi tutulmasına yardımcı olabilir. Satın alma öncesinde firmanın kendi senaryolarıyla sistemi test etmesi en sağlıklı yaklaşımdır.

Özet

Asansör arıza programı satın almak, yalnızca yazılım özelliklerini karşılaştırmak değildir. Asıl amaç firmanın mevcut operasyon sorunlarını belirlemek ve bu sorunları en az ek iş yüküyle çözen sistemi seçmektir.

İyi hazırlanmış bir satın alma briefi; arıza kayıt yöntemi, teknisyen atama süreci, mobil kullanım, arıza geçmişi, raporlama, teknik destek ve toplam maliyet gibi kritik başlıkları önceden netleştirir. Böylece demo görüşmeleri daha verimli olur ve farklı yazılımlar aynı kriterlerle değerlendirilebilir.

En iyi yöntem, satın alma kararından önce gerçek bir arıza senaryosunu baştan sona test etmektir. Teknisyenin arızayı alması, sahaya gitmesi, müdahaleyi kaydetmesi ve ofisin sonucu takip etmesi kolay değilse yazılım uzun vadede beklenen verimi sağlamayacaktır.

Doğru brief, satın alma sürecini "hangi program daha ucuz?" sorusundan çıkarıp "hangi program bizim operasyonumuzu gerçekten daha iyi yönetiyor?" sorusuna taşır.