Asansör Bakım Yazılımı Bütçe Onayı İçin 5 Slayt

İÇERİK

Bir asansör bakım yazılımı satın almak teknik ekip açısından açık bir ihtiyaç gibi görünse de firma sahibi, ortaklar veya finans sorumlusu açısından konu çoğu zaman farklı değerlendirilir. Karar verici kişinin temel sorusu "Bu program hangi özelliklere sahip?" değil, "Bu yatırım bize ne kazandıracak ve verdiğimiz paranın karşılığını nasıl alacağız?" sorusudur.

Bu nedenle bütçe onayı almak için 30 sayfalık özellik sunumları hazırlamak yerine sorunu, maliyeti, beklenen faydayı ve uygulama planını açıklayan kısa bir yönetim sunumu daha etkili olabilir. Özellikle bakım portföyü büyüyen, teknisyen sayısı artan veya Excel, WhatsApp ve kâğıt formlarla operasyon yürütmekte zorlanan asansör firmalarında doğru hazırlanmış 5 slaytlık bir bütçe sunumu, karar sürecini ciddi biçimde kolaylaştırabilir.

Aşağıdaki yapı; firma sahibi, operasyon yöneticisi veya satın alma sürecini yürüten kişinin bir asansör bakım programı yatırımını yönetime anlatırken kullanabileceği pratik bir şablondur.

Slayt 1: Bugünkü Operasyon Sorununu Rakamlarla Gösterin

İlk slaytta yazılımdan bahsetmeyin. Önce mevcut çalışma düzeninin oluşturduğu problemi gösterin.

Yönetim açısından "Excel kullanıyoruz" veya "teknisyenlerden bilgi geç geliyor" gibi ifadeler tek başına yeterince güçlü değildir. Bunun yerine sorunun işletmeye olan etkisini somutlaştırmak gerekir.

Örneğin slaytın başlığı şöyle olabilir:

Mevcut Bakım Operasyonunda Zaman ve Kontrol Kaybı

Altına firma içindeki gerçek durumlara göre şu maddeler eklenebilir:

• Aylık bakım planlarının manuel hazırlanması
• Teknisyenlere işlerin WhatsApp üzerinden gönderilmesi
• Tamamlanan bakımların merkezden anlık görülememesi
• İmzalı bakım formlarının sonradan ofise ulaşması
• Tahsilat bilgisinin saha ile muhasebe arasında geç aktarılması
• Arıza ve bakım geçmişinin farklı dosyalarda tutulması
• Bina yöneticisinin bilgi almak için sürekli firmayı araması
• Personel değiştiğinde geçmiş operasyon bilgisinin dağılması

Buradaki amaç operasyonu olduğundan kötü göstermek değildir. Yazılıma neden ihtiyaç olduğunu yönetimin anlayacağı bir iş problemine çevirmektir.

Örneğin 6 teknisyen bulunan ve ayda 500 bakım gerçekleştiren bir firma düşünelim. Her teknisyen günlük ortalama 15 dakika sadece bakım listesini kontrol etmek, merkezle yazışmak veya tamamlanan işleri bildirmek için harcıyorsa:

6 teknisyen x 15 dakika x 22 iş günü = 1.980 dakika

Bu da ayda yaklaşık 33 saatlik operasyon zamanı anlamına gelir.

Bu hesap örnektir. Sunum hazırlanırken mutlaka firmanın kendi gerçek verileri kullanılmalıdır.

Bütçe onayında en etkili başlangıç, yazılım özelliklerini anlatmak değil mevcut çalışma biçiminin şirkete neye mal olduğunu göstermektir.

Slayt 2: Yazılımın Hangi Süreçleri Birleştireceğini Anlatın

İkinci slaytta artık çözümü gösterebilirsiniz. Ancak burada da onlarca özellik sıralamak yerine mevcut sorunun hangi süreçlerle çözüleceğini anlatmak gerekir.

Slaytın başlığı:

Tek Sistemle Yönetilecek Operasyonlar

Örneğin aşağıdaki yapı kullanılabilir:

Mevcut süreç	Bugünkü yöntem	Yazılım sonrası hedef
Bakım planlama	Excel / manuel liste	Merkezi bakım takvimi
Teknisyen görevlendirme	Telefon / WhatsApp	Dijital görev ataması
Bakım formu	Kâğıt	Dijital bakım kaydı
Fotoğraf ve imza	Telefon galerisi / dosya	İlgili bakım kaydında saklama
Arıza takibi	Telefon / mesaj	Merkezi arıza kaydı
Tahsilat bilgisi	Manuel bildirim	İşlemle bağlantılı kayıt
Geçmiş işlemler	Dosya arama	Bina ve asansör bazlı geçmiş
Yönetim raporu	Manuel hazırlama	Güncel operasyon raporu

Bu tablo yönetim açısından son derece değerlidir çünkü yatırımın yalnızca "bir bakım programı" olmadığını gösterir.

Asıl değer; farklı araçlarla yürütülen süreçlerin tek bir operasyon akışında birleşmesidir.

Örneğin Asansorex gibi bakım ve saha yönetimini aynı sistemde bir araya getiren yazılımlarda bakım planı, teknisyen işlemleri, arıza kayıtları ve saha belgelerinin bağlantılı tutulması mümkün olur. Böylece değerlendirme yapılırken sadece lisans fiyatına değil, kaç farklı manuel sürecin ortadan kalkacağına bakmak daha sağlıklı olur.

Slayt 3: Yatırımın Finansal Karşılığını Gösterin

Bütçe sunumunun en önemli slaydı genellikle üçüncü slayttır.

Burada amaç kesin olmayan büyük tasarruf vaatleri oluşturmak değil, yatırımın finansal mantığını anlaşılır şekilde ortaya koymaktır.

Başlık şöyle olabilir:

Yazılım Yatırımının Beklenen Finansal Etkisi

Hesaplama için önce bugün görünmeyen maliyetleri belirleyin.

Personel zamanı

Manuel bakım planlama, teknisyenlerden bilgi toplama, evrak düzenleme ve raporlama için ofiste ayda 30 saat harcandığını düşünelim.

Saatlik toplam personel maliyetinin örnek olarak 300 TL olduğu varsayılsın:

30 saat x 300 TL = 9.000 TL / ay

Yılda:

9.000 TL x 12 = 108.000 TL

Bu, doğrudan "yazılım 108.000 TL kazandırır" anlamına gelmez. Çünkü bu sürenin tamamı ortadan kalkmayacaktır. Ancak iş gücü kullanımındaki verimsizliği görünür hale getirir.

Kaçırılan bakım ve tahsilatlar

500 asansörlük bir portföyde yalnızca birkaç bakım kaydının veya tahsilat takibinin gecikmesi bile finansal sonuç yaratabilir.

Bu nedenle hesaplamaya şu alanlar ayrıca eklenebilir:

• Zamanında yapılmayan bakım takibi
• Geciken tahsilatlar
• Unutulan sözleşme yenilemeleri
• Eksik saha belgeleri
• Gereksiz tekrar ziyaretleri
• Yanlış teknisyen yönlendirmeleri
• Manuel raporlama süresi

Sunumdaki amaç hayali bir yatırım getirisi üretmek değil, bugün ölçülmeyen operasyon maliyetlerini görünür hale getirmektir.

Basit ROI yaklaşımı

Yönetim sunumunda karmaşık finans modelleri yerine basit bir hesap kullanılabilir:

Yıllık tahmini operasyon kazancı - yıllık yazılım maliyeti = net fayda

Ardından:

Net fayda / yazılım maliyeti x 100 = yaklaşık ROI

Ancak bu hesap mutlaka gerçek şirket verilerine dayanmalıdır. Yazılım firmasının verdiği genel sektör tahminlerini doğrudan kendi firmanızın tasarrufu gibi göstermek doğru değildir.

Slayt 4: Riskleri ve Uygulama Planını Açıklayın

Yönetimin yazılım yatırımlarındaki en önemli çekincelerinden biri yalnızca fiyat değildir.

Şu sorular genellikle daha kritiktir:

"Personel bunu kullanabilecek mi?"

"Eski verileri nasıl aktaracağız?"

"Geçiş sırasında işler aksar mı?"

"Teknisyenler sisteme alışmazsa ne olacak?"

"Bir ay sonra yine Excel'e döner miyiz?"

Bu nedenle dördüncü slaytın başlığı şu olabilir:

Geçiş Planı ve Risk Kontrolü

Örnek bir geçiş planı:

1. Mevcut bina ve asansör kayıtları temizlenir.
2. Aktarılacak müşteri ve portföy bilgileri belirlenir.
3. Kullanıcı yetkileri oluşturulur.
4. Küçük bir teknisyen grubuyla pilot kullanım başlatılır.
5. İlk bakım planları sisteme aktarılır.
6. Saha ekibine kısa uygulamalı eğitim verilir.
7. İlk haftalarda kullanım hataları takip edilir.
8. Başarılı pilot sonrası tüm portföye geçilir.

Bu slayt bütçe onayında önemli bir mesaj verir: Firma yazılımı satın alıp çalışanların önüne bırakmayacaktır; kontrollü bir geçiş yapacaktır.

Özellikle yüzlerce bina ve asansör kaydı bulunan firmalarda veri aktarımı ayrı bir proje olarak ele alınmalıdır. Eski Excel dosyalarındaki mükerrer müşteri kayıtları, yanlış telefon numaraları veya güncel olmayan bakım bilgileri yeni sisteme olduğu gibi taşınmamalıdır.

Dijitalleşmenin başarısını çoğu zaman yazılımın teknik kapasitesinden çok veri kalitesi ve kullanıcı adaptasyonu belirler.

Slayt 5: Yönetimden İstenen Kararı Netleştirin

Son slaytta tekrar uzun özellik listelerine dönmek büyük bir hata olur.

Bu slaytın amacı karar istemektir.

Başlık:

Önerilen Yatırım ve Beklenen Sonuç

Slaytta maksimum birkaç ana bilgi bulunmalıdır:

• Seçilecek yazılım veya çözüm
• Yıllık toplam bütçe
• Varsa kurulum ve eğitim maliyeti
• Planlanan başlangıç tarihi
• Pilot kullanım süresi
• Başarı kriterleri
• Karar verilmesi gereken tarih

Örneğin başarı kriterleri şöyle tanımlanabilir:

• Bakım planlarının tamamının sistem üzerinden takip edilmesi
• Teknisyenlerin saha işlemlerini dijital olarak kapatması
• Eksik bakım kayıtlarının görünür hale gelmesi
• Arıza geçmişinin bina bazında izlenebilmesi
• Yönetimin aylık operasyon raporuna kolay ulaşması
• Manuel veri girişinin azalması

Bütçe talebi mümkün olduğunca açık yazılmalıdır.

"Yeni bir sistem almayı düşünüyoruz" yerine:

"Bakım operasyonunun dijitalleştirilmesi için yıllık yazılım bütçesinin onaylanması talep edilmektedir."

gibi karar verilebilir bir ifade kullanılabilir.

Yönetim toplantılarında belirsiz talepler çoğu zaman bir sonraki toplantıya ertelenir. Net kapsam, net maliyet ve ölçülebilir hedef ise karar vermeyi kolaylaştırır.

Bütçe Onay Sunumunda Hangi Rakamlar Kullanılmalı?

İyi bir sunumda mümkün olduğunca şirketin kendi verileri bulunmalıdır.

Hazırlık aşamasında aşağıdaki bilgileri çıkarmak faydalıdır:

Veri	Neden gerekli?
Toplam bakım portföyü	Operasyon büyüklüğünü gösterir
Aktif teknisyen sayısı	Kullanıcı ve saha yükünü gösterir
Aylık bakım adedi	İş hacmini ölçer
Aylık arıza sayısı	Servis yükünü gösterir
Planlama için harcanan süre	Manuel operasyon maliyetini gösterir
Evrak hazırlama süresi	Ofis iş yükünü gösterir
Geciken bakım sayısı	Planlama riskini gösterir
Geciken tahsilat toplamı	Finansal takip ihtiyacını gösterir
Yıllık yazılım maliyeti	Yatırım büyüklüğünü gösterir
Eğitim/geçiş maliyeti	Toplam sahip olma maliyetini gösterir

Özellikle yazılım fiyatı tek başına değerlendirilmemelidir.

Daha doğru soru şudur:

"Bu yazılım, bugün personelin manuel yaptığı hangi işleri azaltıyor?"

Örneğin yılda belirli bir lisans maliyeti ödeyen bir firma; bakım planlama, arıza yönetimi, saha kayıtları, raporlama ve tahsilat takibi için ayrı ayrı zaman harcıyorsa gerçek karşılaştırma yazılım fiyatıyla Excel'in ücretsiz olması arasında değildir.

Karşılaştırılması gereken şey toplam operasyon maliyetidir.

Sunumda Yapılmaması Gereken 5 Hata

Bütçe toplantısına hazırlanırken aşağıdaki hatalardan kaçınmak gerekir:

1. 40–50 özellik sıralamak: Yönetim özellik değil iş sonucu görmek ister.
2. Gerçekçi olmayan tasarruf hesapları yapmak: Kanıtlanamayan ROI rakamları güven kaybettirir.
3. Sadece yazılım fiyatını konuşmak: Geçiş, eğitim ve operasyon etkisi de değerlendirilmelidir.
4. Kullanıcı adaptasyonunu yok saymak: Teknisyen kullanmazsa en iyi yazılım bile beklenen sonucu üretmez.
5. Başarı kriteri belirlememek: Yazılımın işe yarayıp yaramadığı ölçülebilir olmalıdır.

Özellikle demo sırasında görülen her fonksiyonu bütçe sunumuna koymak gerekmez. Firma açısından kritik olan 4–5 süreç seçilmelidir.

Örneğin bir firma için rota yönetimi çok önemliyken başka bir firmada tahsilat ve sözleşme yenileme takibi daha kritik olabilir.

Bu nedenle sunum ürün odaklı değil şirket problemi odaklı hazırlanmalıdır.

Satın Alma Kararında Fiyat Dışında Neler Kontrol Edilmeli?

Yönetim bütçeyi onaylamadan önce yazılımın operasyon açısından sürdürülebilir olup olmadığını da değerlendirmelidir.

Kontrol edilmesi gereken temel başlıklar şunlardır:

• Mobil kullanım kolaylığı
• Teknisyenlerin sahadan işlem yapabilmesi
• Bakım ve arıza geçmişinin tutulması
• Kullanıcı yetkilendirmeleri
• Veri aktarım desteği
• Eğitim süreci
• Teknik destek modeli
• Yedekleme yaklaşımı
• Yeni personel ekleme kolaylığı
• Portföy büyüdüğünde sistemin kullanılabilirliği
• Raporlama seçenekleri
• Toplam yıllık maliyet

Örneğin Asansorex değerlendiriliyorsa yalnızca bakım kaydı oluşturma özelliğine değil; bakım, arıza, teknisyen operasyonu, saha kayıtları ve finansal işlemlerin firmanın mevcut iş akışına ne kadar uyduğu birlikte değerlendirilmelidir.

Bütçe kararında doğru yaklaşım, "En fazla özelliği hangi program sunuyor?" sorusundan çok "Bizim operasyonumuzdaki en pahalı ve en riskli sorunları hangi sistem çözüyor?" sorusunu sormaktır.

Sıkça Sorulan Sorular

Asansör bakım yazılımı için bütçe sunumu kaç slayt olmalı?

Yönetim seviyesindeki ilk değerlendirme için çoğu durumda 5 slayt yeterlidir. Problem, çözüm, finansal etki, uygulama planı ve bütçe talebi net şekilde anlatılabiliyorsa daha uzun bir sunum gerekmeyebilir. Teknik detaylar ihtiyaç halinde ek doküman olarak hazırlanabilir.

Yazılım bütçesi onayında en önemli slayt hangisidir?

Genellikle finansal etkiyi gösteren üçüncü slayt en fazla dikkat çeken bölümdür. Ancak ROI hesabının şirketin gerçek verilerine dayanması gerekir. Tahmini ve doğrulanmamış tasarruf rakamları kullanmak yerine mevcut iş gücü ve operasyon maliyetleri hesaplanmalıdır.

Excel ücretsizken neden bakım yazılımına bütçe ayırmak gerekir?

Excel'in lisans maliyeti düşük veya mevcut olabilir ancak gerçek maliyet yalnızca kullanılan aracın fiyatından oluşmaz. Manuel veri girişi, hatırlatmalar, teknisyen koordinasyonu, belge arama, raporlama ve bilgi kayıpları da operasyon maliyetidir.

Yazılım yatırımı kaç ayda kendini amorti etmelidir?

Her firma için aynı süreyi söylemek doğru değildir. Portföy büyüklüğü, teknisyen sayısı, mevcut iş süreçleri, lisans maliyeti ve yazılım sayesinde azaltılabilecek operasyon yükü birlikte hesaplanmalıdır.

Bütçe talebine eğitim maliyeti dahil edilmeli mi?

Varsa mutlaka dahil edilmelidir. Lisans, kurulum, veri aktarımı, eğitim ve ihtiyaç duyulan ek hizmetler toplam sahip olma maliyetinin parçasıdır. Yönetimin sonradan beklenmeyen maliyetlerle karşılaşmaması için baştan görünür hale getirilmesi daha sağlıklıdır.

Yazılım seçmeden önce demo yapılmalı mı?

Evet. Özellikle bakım planlama, arıza kaydı, teknisyen kullanımı ve saha işlemleri gerçek senaryolarla test edilmelidir. Demo yalnızca ekranların gösterildiği bir ürün tanıtımı değil, firmanın günlük operasyonunun sistem üzerinde denenmesi olarak görülmelidir.

Özet

Asansör bakım yazılımı için bütçe onayı almak, onlarca yazılım özelliğini sıralamaktan çok yatırımın işletmeye olan etkisini doğru anlatmayı gerektirir.

Etkili bir 5 slaytlık sunumda sırasıyla mevcut operasyon problemi, yazılımla değişecek süreçler, finansal etki, uygulama planı ve yönetimden istenen bütçe kararı yer almalıdır.

En güçlü sunumlar sektördeki genel vaatlere değil firmanın kendi bakım portföyüne, teknisyen sayısına, harcanan iş gücüne ve operasyon kayıplarına dayanır. Böylece asansör bakım yazılımı bir "ek yazılım gideri" olarak değil, operasyonun daha kontrollü ve ölçülebilir yönetilmesini sağlayacak bir iş yatırımı olarak değerlendirilebilir.