Asansör Bakım Programı Satın Alma Komitesi İçin Brief

İÇERİK

Asansör bakım programı satın almak, yalnızca “hangi yazılım daha fazla özellik sunuyor?” sorusuna cevap vermekten ibaret değildir. Yanlış seçim; teknisyenin kullanmadığı bir sistem, gereksiz lisans maliyetleri, dağınık müşteri kayıtları ve birkaç ay sonra tekrar Excel veya WhatsApp kullanımına dönülmesiyle sonuçlanabilir. Doğru seçim ise bakım firmasının saha operasyonundan bina yöneticisi iletişimine kadar birçok süreci daha ölçülebilir hale getirir. Bu nedenle satın alma kararı mümkünse tek kişinin görüşüne değil, firma sahibi ile sahada sistemi kullanacak teknisyenlerin ortak değerlendirmesine dayanmalıdır. Hazırlanacak kısa ve net bir satın alma briefi, farklı yazılımları aynı kriterlerle karşılaştırmayı ve demo sırasında doğru soruları sormayı kolaylaştırır.

Satın Alma Briefi Neden Gereklidir?

Bir bakım programı araştırılmaya başlandığında ilk karşılaşılan sorun, ürünlerin birbirinden çok farklı biçimlerde sunulmasıdır. Bir yazılım bakım planlamasını ön plana çıkarırken başka biri finans özelliklerini, diğeri mobil uygulamasını veya raporlamasını vurgulayabilir.

Brief olmadığı zaman karar süreci kolayca özellik yarışına dönüşür.

Örneğin bir bakım firmasının asıl problemi teknisyenlerin bakım föylerini geç teslim etmesi olabilir. Ancak demo sırasında onlarca finans ve raporlama ekranı gösterildiğinde satın alma ekibi asıl problemi unutabilir.

Satın alma briefinin temel amacı şudur:

Yazılımın neler yapabildiğini değil, firmanın hangi problemleri çözmesi gerektiğini önce tanımlamak.

İyi hazırlanmış bir brief sayesinde:

• Farklı yazılımlar aynı kriterlerle karşılaştırılır.
• Demo sırasında hangi senaryoların test edileceği önceden belirlenir.
• Firma sahibi ile teknisyen arasındaki beklenti farkı azalır.
• Sonradan ortaya çıkan ek ücretlerin riski düşer.
• Kullanılmayacak özellikler için gereksiz ödeme yapılmaz.
• Yazılımın saha operasyonuna gerçekten uygun olup olmadığı anlaşılır.

Özellikle 100, 300 veya 500'den fazla asansörün takip edildiği portföylerde küçük bir operasyon hatası bile ay içinde çok sayıda eksik kayıt veya gecikmiş bakım oluşturabilir. Bu nedenle brief, yalnızca satın alma belgesi değil aynı zamanda operasyon ihtiyaçlarının özeti olarak görülmelidir.

Komitede Kimlerin Görüşü Alınmalı?

Küçük ve orta ölçekli asansör firmalarında resmi anlamda kalabalık bir satın alma komitesi oluşturmak şart değildir. Ancak en az iki farklı bakış açısının karara dahil edilmesi faydalıdır.

Firma sahibi

Firma sahibi daha çok toplam maliyet, operasyon kontrolü ve yatırımın geri dönüşüyle ilgilenir.

Şu sorular önemlidir:

• Yazılım yıllık olarak firmaya ne kadara mal olacak?
• Kullanıcı veya asansör sayısı arttığında fiyat değişecek mi?
• Şube veya ek personel için ayrıca ücret alınacak mı?
• Mevcut veriler sisteme aktarılabilecek mi?
• Yazılım operasyon maliyetini gerçekten azaltacak mı?
• Veriler gerektiğinde dışarı aktarılabilecek mi?

Teknisyen veya saha sorumlusu

Yazılımın başarılı olup olmayacağını çoğu zaman saha belirler. Masaüstünde çok kapsamlı görünen bir sistem, teknisyenin bir bakım kaydını tamamlaması için sürekli ekran değiştirmesini gerektiriyorsa birkaç hafta içinde kullanım direnci oluşabilir.

Teknisyenin özellikle değerlendirmesi gereken noktalar:

• Günlük bakım listesine ulaşma kolaylığı
• Mobil kullanım
• Bakım formu doldurma süresi
• Fotoğraf ekleme
• Müşteri imzası alma
• Arıza kaydı kapatma
• İnternet bağlantısı zayıf olduğunda kullanım
• Önceki bakım veya arıza geçmişine erişim

Bina yöneticisinin beklentisi

Bina yöneticisinin satın alma kararında doğrudan bulunması gerekmez. Ancak müşterilerin firmadan en sık istediği bilgiler briefte dikkate alınmalıdır.

Örneğin:

• Bakım ne zaman yapıldı?
• Hangi teknisyen geldi?
• Hangi işlem gerçekleştirildi?
• Arıza ne zaman bildirildi?
• Arıza ne zaman çözüldü?
• Ödeme veya borç durumu nedir?
• Bakım belgesine ulaşılabilir mi?

Bu soruların önemli bölümü bugün telefon ve WhatsApp üzerinden cevaplanıyorsa yazılım seçiminin müşteri iletişimini de azaltması beklenebilir.

Briefte Bulunması Gereken Temel Kriterler

Satın alma komitesi mümkünse yazılım firmalarıyla görüşmeden önce ihtiyaçları önem sırasına koymalıdır.

Her özelliği “zorunlu” olarak işaretlemek doğru değildir. Çünkü sonuçta yüzlerce maddelik, gerçek operasyon önceliklerini göstermeyen bir liste ortaya çıkar.

Kriterleri üç gruba ayırmak daha kullanışlıdır:

• Zorunlu: Olmadan yazılım satın alınmayacak özellikler.
• Önemli: Operasyonu ciddi şekilde kolaylaştıracak özellikler.
• Tercih sebebi: Olması avantaj sağlayan ancak kararın tek başına belirleyicisi olmayan özellikler.

Örnek değerlendirme tablosu şöyle hazırlanabilir:

Değerlendirme alanı	Öncelik	Kontrol edilecek konu	Örnek ağırlık
Bakım planlama	Zorunlu	Aylık bakım programı ve geciken işler	%20
Mobil saha kullanımı	Zorunlu	Teknisyenin telefondan işlem kapatabilmesi	%20
Arıza yönetimi	Zorunlu	Bildirim, atama, müdahale ve kapanış	%15
Kayıt ve geçmiş	Zorunlu	Asansör bazında geçmiş işlemler	%10
Raporlama	Önemli	Tamamlanan ve geciken işlerin raporu	%10
Müşteri iletişimi	Önemli	Bina yöneticisine bilgi sunabilme	%10
Veri aktarımı	Önemli	Mevcut müşteri ve asansör verilerinin taşınması	%5
Destek hizmeti	Zorunlu	Kurulum ve kullanım desteği	%5
Toplam maliyet	Zorunlu	Lisans ve ek ücretler	%5

Ağırlıklar her firmaya göre değişebilir. Örneğin saha ekibi büyük olan bir bakım firmasında mobil kullanımın ağırlığı %25'e çıkarılabilir. Tahsilat problemi yaşayan başka bir firma ise finans ve cari takip fonksiyonlarını daha yüksek puanlayabilir.

Önemli olan bütün adayların aynı puanlama sistemiyle değerlendirilmesidir.

Demo Sırasında Özellik Değil Senaryo Test Edin

Satın alma sürecindeki en sık yapılan hatalardan biri, demo sunumunu tamamen yazılım firmasına bırakmaktır.

Bu durumda sağlayıcı doğal olarak ürünün en güçlü bölümlerini gösterir. Oysa satın alma komitesinin ihtiyacı, kendi günlük operasyonunu test etmektir.

Demo öncesinde 5–7 gerçek senaryo hazırlanması daha sağlıklı sonuç verir.

Örneğin:

1. Yeni bir bina ve asansör kaydı oluşturun.
2. Bu asansör için aylık bakım planlayın.
3. Bakımı belirli bir teknisyene yönlendirin.
4. Teknisyenin telefondan bakım kaydını tamamlamasını sağlayın.
5. Fotoğraf veya imza gibi saha kanıtlarını kaydedin.
6. Aynı asansörde yeni bir arıza kaydı oluşturun.
7. Bir ay sonra geçmiş bakım ve arıza kayıtlarını bulun.

Bu test sırasında kronometre tutulması bile yararlı olabilir.

Örneğin bir teknisyenin bakım kapatma işlemi teoride kolay görünürken sahada 15 farklı alana veri girmesi gerekiyorsa kullanıcıların sistemi düzenli kullanması zorlaşabilir.

Demo sırasında şu soru da mutlaka sorulmalıdır:

“Bunu bize anlatmadan, teknisyenimiz kendisi yapabilir mi?”

Bir programın gerçek kullanılabilirliği çoğu zaman bu soruda ortaya çıkar.

Asansorex gibi asansör bakım operasyonuna odaklanan yazılımlar değerlendirilirken de yalnızca özellik listesine bakmak yerine firmanın kendi bakım ve arıza senaryolarını uygulamalı olarak denemesi daha sağlıklı bir karşılaştırma sağlar.

Mevzuat ve Kayıt Düzeni Briefte Unutulmamalı

Asansör bakım firmalarında yazılım yalnızca iş planlama aracı değildir. Bakım geçmişinin düzenli tutulması, yapılan işlemlerin izlenebilmesi ve gerektiğinde ilgili kayıtların bulunabilmesi de önemlidir.

Türkiye'de bakım ve işletme süreçlerinin temel çerçevelerinden biri Asansör İşletme ve Bakım Yönetmeliğidir. Yönetmelik, bakım hizmeti ve ilgili sorumluluklara ilişkin düzenlemeler içerir. ([Sanayi Bakanlığı][1]) Periyodik kontrol süreçlerinde ise asansörlerin kontrol sonuçlarına göre bilgi etiketleriyle sınıflandırılması uygulaması bulunmaktadır. ([Sanayi Bakanlığı][2])

Satın alma briefinde bu nedenle şu maddeler bulunabilir:

• Asansör bazında bakım geçmişi görüntülenebiliyor mu?
• Bakımı yapan personel kaydı tutuluyor mu?
• Tarih ve işlem bilgileri geriye dönük bulunabiliyor mu?
• Bakım sırasında kullanılan formlar saklanabiliyor mu?
• Fotoğraf veya imza gibi saha kayıtları ilişkilendirilebiliyor mu?
• Periyodik kontrol sonrasında gerekli takip işleri planlanabiliyor mu?
• Geçmiş kayıtlar gerektiğinde dışarı aktarılabiliyor mu?

Burada amaç yazılımın mevzuat sorumluluğunu üstlenmesi değildir. Yazılım, firmanın gerekli operasyon ve kayıt düzenini daha sistematik yürütmesine yardımcı olan bir araçtır.

Toplam Maliyeti Sadece Lisans Fiyatıyla Hesaplamayın

İki yazılım arasında karar verirken yalnızca yıllık lisans ücretini karşılaştırmak yanıltıcı olabilir.

Gerçek maliyet hesabında aşağıdaki kalemler birlikte düşünülmelidir:

• Yıllık veya aylık lisans
• Kullanıcı başına ek ücret
• Asansör sayısı arttığında oluşan ücret
• Şube ücreti
• Kurulum bedeli
• Eğitim bedeli
• Veri aktarım bedeli
• SMS veya iletişim kontörleri
• E-fatura gibi ek servisler
• Destek veya bakım ücreti
• Ek depolama veya yedekleme ücretleri
• Sözleşme yenileme fiyatı

Ayrıca yazılımı kullanmamanın maliyeti de hesaplanmalıdır.

Örneğin firma her ay:

• 10 saat bakım planı hazırlıyorsa,
• 8 saat teknisyenlerden föy topluyorsa,
• 6 saat bina yöneticilerine geçmiş kayıt gönderiyorsa,
• 6 saat eksik bakım kayıtlarını kontrol ediyorsa,

toplam 30 saatlik operasyonel iş oluşur.

Yeni sistem bu süreyi 12 saate indirebiliyorsa aylık 18 saatlik tasarruf sağlanmış olur.

Basit ROI hesabı şu şekilde düşünülebilir:

Yıllık kazanım = zaman tasarrufu + hata azalması + tahsilat iyileşmesi - yazılım maliyeti

Her kalemi kesin TL değerine çevirmek zor olabilir. Ancak mevcut durum ile yeni sistem arasındaki farkın ölçülmesi satın alma kararını çok daha objektif hale getirir.

Satın Alma Kararından Önce Son Kontrol Listesi

Komitenin nihai karardan önce kısa bir kapanış toplantısı yapması yararlıdır.

Aşağıdaki soruların büyük bölümüne net cevap verilemiyorsa satın alma kararını yalnızca demo etkisiyle vermemek gerekir.

• Yazılımla çözmek istediğimiz ilk üç problem belli mi?
• Saha teknisyeni sistemi denedi mi?
• Gerçek bir bakım senaryosu uygulandı mı?
• Gerçek bir arıza senaryosu uygulandı mı?
• Mevcut verilerin nasıl aktarılacağı açık mı?
• Toplam yıllık maliyet belli mi?
• Ek kullanıcı ve asansör maliyetleri öğrenildi mi?
• Destek kapsamı belli mi?
• Verilerin nasıl alınabileceği soruldu mu?
• Eğitim süreci tanımlandı mı?
• İlk 30 gün için geçiş planı var mı?
• Başarıyı ölçmek için KPI belirlendi mi?

Satın alma sonrasında da ilk ay için birkaç basit KPI seçilebilir:

• Planlanan bakımların tamamlanma oranı
• Geciken bakım sayısı
• Dijital olarak kapanan bakım oranı
• Ortalama arıza kapanış süresi
• Eksik saha kaydı sayısı
• Bina yöneticilerinden gelen kayıt sorgusu sayısı

Böylece “programı aldık” yerine “program operasyonu iyileştirdi mi?” sorusuna cevap verilebilir.

Sıkça Sorulan Sorular

Asansör bakım programı satın alma komitesinde kaç kişi olmalı?

Küçük ve orta ölçekli firmalarda kalabalık bir komite gerekli değildir. Firma sahibi ve sistemi günlük kullanacak deneyimli bir teknisyenin birlikte değerlendirme yapması çoğu zaman yeterlidir. Önemli olan ticari ve saha bakış açılarının birlikte temsil edilmesidir.

Demo sırasında kaç özellik test edilmelidir?

Onlarca özelliği yüzeysel incelemek yerine 5–7 kritik iş senaryosunu baştan sona test etmek daha faydalıdır. Bakım oluşturma, teknisyene yönlendirme, sahadan kapatma, arıza kaydı ve geçmiş kayıt sorgulama iyi başlangıç senaryolarıdır.

En ucuz asansör bakım programını seçmek doğru mudur?

Tek başına fiyat üzerinden karar vermek doğru değildir. Kullanım zorluğu, eğitim ihtiyacı, ek ücretler, veri aktarımı ve destek kalitesi toplam maliyeti doğrudan etkiler. Daha düşük lisans fiyatına sahip bir sistem, operasyonu yavaşlatıyorsa uzun vadede daha pahalı hale gelebilir.

Satın almadan önce teknisyenin programı denemesi gerekli mi?

Evet. Programın günlük kullanıcılarından biri teknisyen olduğu için saha deneyimi kararın önemli parçasıdır. Özellikle mobil kullanım, bakım kapatma, fotoğraf ekleme ve arıza işlemleri gerçek cihaz üzerinden denenmelidir.

Yazılımın mevzuata uygun olması tek başına yeterli midir?

Hayır. Mevzuatla ilgili kayıtların tutulabilmesi önemlidir ancak programın firmanın operasyonuna, kullanıcı alışkanlıklarına, portföy büyüklüğüne ve müşteri iletişimine de uygun olması gerekir. Yazılım, firmanın yasal sorumluluklarının yerine geçen değil, kayıt ve operasyon süreçlerini destekleyen bir araçtır.

Satın alma briefi ne kadar uzun olmalıdır?

Çoğu bakım firması için 2–4 sayfalık net bir brief yeterlidir. Firma bilgileri, mevcut sorunlar, zorunlu özellikler, demo senaryoları, maliyet kriterleri ve karar puanlaması bulunmalıdır. Çok uzun belgeler karar sürecini kolaylaştırmak yerine zorlaştırabilir.

Özet

Asansör bakım programı satın alma sürecinde en önemli adım, yazılım firmalarıyla görüşmeden önce kendi ihtiyacınızı tanımlamaktır. Firma sahibi maliyet ve kontrol tarafını, teknisyen ise günlük kullanım ve saha gerçeklerini değerlendirmelidir. Ardından bütün adaylar aynı bakım, arıza, kayıt, destek ve maliyet senaryolarıyla test edilmelidir.

İyi hazırlanmış bir satın alma briefi sayesinde karar “hangi program daha etkileyici görünüyor?” sorusundan çıkar ve “hangi program bizim günlük operasyonumuzu daha az hata ve daha az manuel iş ile yönetmemizi sağlıyor?” sorusuna dönüşür.

Asansorex gibi asansör bakım firmalarına yönelik çözümler de bu çerçevede değerlendirilirken firmanın kendi portföyü, saha ekibi ve gerçek bakım senaryoları temel alınmalıdır. Böylece yazılım seçimi yalnızca bir lisans satın alma kararı değil, ölçülebilir bir operasyon iyileştirme yatırımı haline gelir.