Asansör Yazılımı Satın Alma Komitesi Briefi

İÇERİK

Asansör yazılımı satın almak yalnızca farklı firmalardan fiyat teklifi toplamak değildir. Seçilecek sistem; bakım planlarını, arıza kayıtlarını, teknisyenlerin saha çalışmalarını, tahsilat süreçlerini ve bina yöneticilerine sunulan hizmet kalitesini doğrudan etkiler. Bu nedenle kararın tek bir kişinin beğenisine veya kısa bir ürün sunumuna bırakılması önemli riskler oluşturur.

Asansör yazılımı satın alma komitesi briefi, firma sahibinin, operasyon sorumlusunun, teknisyenlerin ve finans tarafının beklentilerini aynı belgede toplar. Böylece yazılım firmalarına aynı ihtiyaçlar iletilir, demolar aynı senaryolarla değerlendirilir ve fiyatlar gerçek kapsam üzerinden karşılaştırılır.

Bu rehberde satın alma briefinin hangi bölümlerden oluşması gerektiğini, komitede kimlerin yer alabileceğini, ihtiyaçların nasıl puanlanacağını ve demo sonrasında kararın nasıl verileceğini adım adım inceleyeceğiz.

Satın Alma Komitesi Briefi Nedir?

Satın alma komitesi briefi, asansör bakım firmasının yeni yazılımdan ne beklediğini açıklayan kısa fakat kapsamlı bir karar belgesidir. Bu belge bir teknik şartname kadar ayrıntılı olmak zorunda değildir. Ancak yazılım sağlayıcısının doğru teklif hazırlayabilmesi ve komite üyelerinin aynı ölçütlerle değerlendirme yapabilmesi için yeterince açık olmalıdır.

İyi hazırlanmış bir brief şu sorulara cevap verir:

• Firma bugün bakım, arıza ve tahsilat süreçlerini nasıl takip ediyor?
• Mevcut yöntemde hangi sorunlar yaşanıyor?
• Kaç asansör, bina, teknisyen ve ofis kullanıcısı bulunuyor?
• Yazılımda mutlaka olması gereken özellikler nelerdir?
• Hangi özellikler ikinci aşamaya bırakılabilir?
• Veri aktarımı, eğitim ve teknik destek beklentileri nelerdir?
• Ayrılan yaklaşık bütçe ve hedeflenen geçiş tarihi nedir?
• Yazılımın başarısı hangi göstergelerle ölçülecektir?

Brief hazırlanmadığında her departman farklı bir beklentiyle demo izleyebilir. Firma sahibi maliyet ve büyüme imkânına bakarken teknisyen mobil kullanım kolaylığına, finans sorumlusu ise fatura ve tahsilat süreçlerine odaklanabilir. Bu beklentiler önceden bir araya getirilmezse karar toplantısı kişisel yorumların tartışıldığı verimsiz bir sürece dönüşür.

Satın Alma Komitesinde Kimler Yer Almalı?

Komitenin çok kalabalık olması karar sürecini yavaşlatabilir. Ancak yalnızca firma sahibinden oluşması da saha ihtiyaçlarının gözden kaçmasına neden olabilir. Genel uygulamada üç ila beş kişilik bir değerlendirme ekibi yeterlidir.

Firma sahibi veya genel sorumlu

Firma sahibi yatırımın mali karşılığını, işletmeye getireceği düzeni ve büyüme kapasitesini değerlendirir. Onun açısından temel sorular şunlardır:

• Yazılım operasyonel maliyetleri azaltacak mı?
• Yeni personel almadan daha fazla portföy yönetilebilecek mi?
• Müşteri kaybı ve tahsilat gecikmesi azalacak mı?
• Yıllık toplam maliyet sürdürülebilir mi?
• Yazılım firması uzun vadede güvenilir bir çözüm ortağı olabilir mi?

Operasyon veya bakım sorumlusu

Operasyon sorumlusu bakım planlarının, arıza atamalarının ve teknisyen iş yükünün nasıl yönetileceğine odaklanır. Yazılımın yalnızca kayıt tutması değil, günlük iş dağılımını gerçekten kolaylaştırması gerekir.

Örneğin aynı bölgede bulunan binaların planlanması, geciken bakımların görülmesi, açık arızaların takip edilmesi ve tamamlanan işlerin kontrol edilmesi operasyon tarafının temel beklentileridir.

Saha teknisyeni

Teknisyenin görüşü özellikle mobil kullanım açısından önemlidir. Ofiste kolay görünen bir işlem sahada çok fazla adım gerektiriyorsa sistem düzenli kullanılmayabilir.

Teknisyenden şu konularda görüş alınmalıdır:

• Bakım formu ne kadar sürede tamamlanıyor?
• Fotoğraf ve açıklama eklemek kolay mı?
• Dijital imza alınabiliyor mu?
• Arıza kaydı hızlı şekilde kapatılabiliyor mu?
• İnternet bağlantısının zayıf olduğu yerlerde süreç nasıl ilerliyor?
• Aynı bilgi birden fazla ekrana giriliyor mu?

Finans veya ön muhasebe sorumlusu

Finans tarafı cari hesap, faturalandırma, tahsilat, gider, parça satışı ve raporlama ihtiyaçlarını değerlendirir. Özellikle 2026 Türkiye koşullarında yazılımın ilk fiyatı kadar lisans yenileme, SMS, e-fatura kontörü, eğitim ve veri aktarımı gibi ek maliyetlerin de incelenmesi gerekir.

Bina yöneticisi perspektifi

Bina yöneticisinin doğrudan komitede bulunması şart değildir. Ancak müşterilerin beklentileri briefte mutlaka temsil edilmelidir. Bakımın yapıldığını görebilmek, arıza durumu hakkında bilgi almak, borç ve ödeme kayıtlarına ulaşmak bina yöneticileri açısından önemli değer oluşturur.

Brief Hazırlanmadan Önce Mevcut Durum Analizi

Yazılım seçimine doğrudan özellik listesiyle başlamak yerine önce mevcut işleyiş analiz edilmelidir. Çünkü firma hangi sorunu çözmek istediğini bilmiyorsa çok sayıda özelliği bulunan fakat günlük ihtiyaca uymayan bir program seçebilir.

Mevcut durum analizi için son üç ila altı aylık operasyon incelenebilir. Aşağıdaki veriler briefin hazırlanmasını kolaylaştırır:

1. Toplam bakım sözleşmesi bulunan asansör sayısı
2. Aylık planlanan ve zamanında tamamlanan bakım sayısı
3. Aylık arıza çağrısı sayısı
4. Ortalama arıza kapanış süresi
5. Teknisyen başına düşen bina ve asansör sayısı
6. Geciken tahsilatların toplam tutarı
7. Yenileme tarihi yaklaşan sözleşme sayısı
8. Manuel hazırlanması gereken raporlar
9. Müşterilerden en sık gelen bilgi talepleri
10. Kâğıt, Excel veya mesajlaşma uygulamalarında tutulan kritik kayıtlar

Örneğin firma ayda 400 bakım planlıyor fakat ortalama 25 bakımın geciktiğini fark ediyorsa satın alınacak yazılımda bakım takvimi, gecikme uyarısı ve teknisyen iş dağılımı öncelikli olmalıdır.

Sorunun asıl kaynağı geciken tahsilatlar ise yalnızca bakım modülü güçlü olan bir yazılım yeterli olmayabilir. Cari hesap, otomatik borçlandırma, ödeme hatırlatma ve yaşlandırma raporu gibi finans özellikleri de değerlendirilmelidir.

Satın alma briefinin amacı en fazla özelliğe sahip yazılımı bulmak değil, firmanın en maliyetli operasyon sorunlarını çözen sistemi seçmektir.

Satın Alma Briefinde Bulunması Gereken Bölümler

Briefin uzunluğu firmanın büyüklüğüne göre değişebilir. Ancak iki ila dört sayfalık düzenli bir belge çoğu asansör bakım firması için yeterlidir.

Firma ve operasyon bilgileri

Bu bölüm yazılım sağlayıcısının kullanım kapsamını anlamasını sağlar.

Belgede şu bilgiler bulunabilir:

• Hizmet verilen il ve ilçeler
• Toplam bina ve asansör sayısı
• Aktif teknisyen sayısı
• Ofis kullanıcı sayısı
• Aylık ortalama bakım ve arıza sayısı
• Mevcut takip yöntemi
• Kullanılan muhasebe veya e-fatura sistemi
• Varsa şube veya farklı ekip yapıları

Projenin amacı

Amaç bölümü mümkün olduğunca somut yazılmalıdır. “Dijitalleşmek istiyoruz” ifadesi tek başına yeterli değildir.

Bunun yerine şu tür hedefler belirlenebilir:

• Kaçırılan periyodik bakımları azaltmak
• Arıza çağrılarının mesajlar arasında kaybolmasını önlemek
• Teknisyenlerin günlük işlerini tek ekrandan görmesini sağlamak
• Bakım föylerini dijital ortamda saklamak
• Sözleşme yenileme tarihlerini zamanında takip etmek
• Tahsilat gecikmelerini raporlamak
• Bina yöneticilerine daha şeffaf hizmet sunmak

Zorunlu ve tercih edilen özellikler

Bütün özellikleri “zorunlu” olarak işaretlemek seçim sürecini zorlaştırır. İhtiyaçlar üç gruba ayrılabilir:

• Olmazsa olmaz: Yazılımın satın alınabilmesi için mutlaka bulunması gereken özellikler
• Önemli: Operasyonu ciddi şekilde kolaylaştıracak fakat alternatif yöntemle geçici olarak yürütülebilecek özellikler
• Gelişim alanı: İlerleyen dönemde kullanılması planlanan özellikler

Örneğin bakım planlama, mobil form, arıza atama ve cari takip olmazsa olmaz kabul edilirken rota optimizasyonu veya müşteri portalı firmanın mevcut yapısına göre ikinci aşamaya bırakılabilir.

Veri aktarımı ve kurulum

Eski kayıtların sisteme nasıl alınacağı briefte açıkça belirtilmelidir. Firma Excel dosyalarında yüzlerce bina ve asansör kaydı tutuyorsa bu verilerin tek tek girilmesi ciddi iş yükü oluşturabilir.

Şu sorular yazılım firmasına yöneltilmelidir:

• Mevcut cari, bina ve asansör kayıtları toplu aktarılabiliyor mu?
• Veri şablonunu kim hazırlayacak?
• Hatalı veya eksik kayıtlar nasıl kontrol edilecek?
• Kurulum sürecinde sorumlu kişi kim olacak?
• İlk bakım planları birlikte oluşturulacak mı?
• Eğitim çevrim içi mi, yerinde mi yapılacak?
• Eğitim sonrası destek nasıl verilecek?

Asansorex gibi asansör sektörüne odaklanan bakım ve yönetim yazılımlarında veri aktarımı, bakım planı oluşturma ve saha kullanımının birlikte değerlendirilmesi, geçiş sürecinin yalnızca program kurulumu olarak görülmesini önler.

Yazılım Değerlendirme ve Puanlama Tablosu

Komite üyelerinin yazılımları aynı ölçütlerle puanlaması gerekir. Aksi durumda bir kişi fiyatı, başka biri tasarımı, diğeri ise yalnızca tek bir özelliği esas alabilir.

Aşağıdaki örnek puanlama tablosu firmanın ihtiyaçlarına göre düzenlenebilir:

Değerlendirme kriteri	Ağırlık	Kontrol edilecek konu
Bakım ve arıza yönetimi	%25	Planlama, atama, form, fotoğraf, imza ve geçmiş kayıtlar
Mobil saha kullanımı	%20	Hız, kullanım kolaylığı, teknisyen adımları
Finans ve tahsilat	%15	Cari, borçlandırma, tahsilat, fatura ve raporlar
Kurulum ve veri aktarımı	%10	Mevcut kayıtların sisteme alınması
Eğitim ve teknik destek	%10	Ulaşılabilirlik, eğitim kapsamı, sorun çözme süreci
Raporlama ve müşteri iletişimi	%10	Yönetici raporları, bildirimler ve şeffaflık
Toplam sahip olma maliyeti	%10	Lisans, kontör, eğitim, ek kullanıcı ve yenileme giderleri

Her yazılım 1 ile 5 arasında puanlanabilir. Ağırlıklı sonuç hesaplanırken verilen puan kriter ağırlığıyla çarpılır.

Örneğin mobil kullanım kriterinin ağırlığı yüzde 20 ve yazılımın puanı 4 ise bu bölümün ağırlıklı karşılığı 4 x 20 = 80 olarak hesaplanabilir. Aynı yöntem bütün kriterlere uygulanarak seçenekler daha nesnel biçimde karşılaştırılır.

Burada dikkat edilmesi gereken nokta, en düşük fiyatlı ürünün otomatik olarak en yüksek maliyet puanını almamasıdır. Fiyatın içinde eğitim, destek, veri aktarımı ve gerekli modüller bulunmuyorsa düşük başlangıç bedeli daha sonra ek maliyetlere dönüşebilir.

Demo Süreci Nasıl Yönetilmeli?

Plansız bir demo çoğunlukla yazılım firmasının özellikleri arka arkaya göstermesiyle tamamlanır. Satın alma komitesi ise kendi günlük işlerinin sistemde nasıl yürütüleceğini tam olarak göremez.

Bu nedenle demo öncesinde gerçekçi bir senaryo hazırlanmalıdır.

Örnek demo senaryosu şöyle olabilir:

1. Yeni bir bina ve asansör kaydı oluşturulsun.
2. Asansör için aylık bakım planı hazırlansın.
3. Bakım bir teknisyene atansın.
4. Teknisyen mobil cihazdan bakım formunu tamamlasın.
5. Fotoğraf, açıklama ve bina yetkilisi imzası eklensin.
6. Bakım sırasında tespit edilen parça ihtiyacı kaydedilsin.
7. Aynı bina için bir arıza çağrısı açılsın ve teknisyene yönlendirilsin.
8. Arıza kapatıldıktan sonra bina yöneticisine bilgi verilsin.
9. Aylık bakım bedeli cariye işlensin.
10. Geciken ödeme ve tamamlanmamış bakım raporu görüntülensin.

Demo sırasında yalnızca sunumu yapan kişinin ekranı kullanılmamalıdır. Mümkünse bir teknisyen deneme hesabından işlemleri kendisi gerçekleştirmelidir. Böylece menülerin anlaşılır olup olmadığı ve sahada kaç adım gerektiği daha doğru görülür.

Komite üyeleri demo sonunda ayrı ayrı puanlama yapmalı, yorumlarını birbirlerinin değerlendirmesinden etkilenmeden kaydetmelidir. Puanlar daha sonra ortak toplantıda karşılaştırılabilir.

Bütçe ve Toplam Sahip Olma Maliyeti

Asansör yazılımı bütçesi hazırlanırken yalnızca yıllık lisans bedeline bakmak eksik sonuç verir. Toplam sahip olma maliyeti, sistemi kullanılabilir durumda tutmak için ödenecek bütün kalemleri kapsar.

Briefte aşağıdaki maliyetler ayrı ayrı sorulmalıdır:

• Yıllık veya aylık lisans ücreti
• Kullanıcı veya teknisyen sınırı
• Asansör portföy sınırı
• Ek kullanıcı maliyeti
• Veri aktarım bedeli
• Kurulum ve eğitim bedeli
• SMS veya WhatsApp gönderim maliyeti
• E-fatura kontör maliyeti
• Mobil yazıcı ve sarf malzemeleri
• Özel rapor veya geliştirme bedeli
• Yenileme dönemindeki fiyatlandırma yöntemi
• Sözleşme sona erdiğinde veri dışa aktarma imkânı

Bütçe değerlendirmesinde yazılımın sağlayacağı tasarruf da hesaba katılmalıdır. Kaçırılan bakım ziyaretlerinin azalması, teknisyen planlamasının iyileşmesi, tahsilatların daha düzenli izlenmesi ve kâğıt işlemlerinin azalması yatırımın geri dönüşünü etkiler.

Örneğin yazılım sayesinde ayda yalnızca birkaç gecikmiş tahsilat daha erken alınabiliyor veya unutulan bakım ziyaretleri önlenebiliyorsa yıllık lisans bedelinin önemli bir bölümü operasyonel kazançla karşılanabilir.

Karar Toplantısı ve Son Kontroller

Demo ve tekliflerin tamamlanmasından sonra satın alma komitesi son bir değerlendirme toplantısı yapmalıdır. Bu toplantıda yalnızca toplam puan değil, kritik riskler de ele alınmalıdır.

Karar öncesinde şu kontroller yapılabilir:

• Zorunlu özelliklerin tamamı gerçekten çalışıyor mu?
• Eksik özellikler için verilen geliştirme sözleri yazılı mı?
• Veri aktarım kapsamı teklifte açıkça belirtilmiş mi?
• Eğitim alacak personel ve eğitim süresi belli mi?
• Teknik destek kanalları tanımlanmış mı?
• Lisans yenileme ve ek maliyet koşulları açıklanmış mı?
• Firma kendi verilerini dışa aktarabiliyor mu?
• Kullanıcı yetkileri görev dağılımına uygun mu?
• Yedekleme ve hizmet devamlılığı hakkında bilgi verilmiş mi?
• Deneme sürecinde gerçek saha işlemi yapılmış mı?

Yazılım seçildikten sonra da brief rafa kaldırılmamalıdır. Belgedeki hedefler, kurulumdan sonraki birinci ve üçüncü ayda yeniden kontrol edilmelidir. Böylece satın alma kararının beklenen sonucu üretip üretmediği görülebilir.

Sıkça Sorulan Sorular

Satın alma komitesi kaç kişiden oluşmalıdır?

Asansör bakım firmalarında genellikle üç ila beş kişi yeterlidir. Firma sahibi, operasyon sorumlusu, bir saha teknisyeni ve finans tarafını temsil eden kişi dengeli bir ekip oluşturur. Çok küçük firmalarda aynı kişi birden fazla rolü temsil edebilir.

Brief hazırlamak büyük firmalar için mi gereklidir?

Hayır. Küçük firmalarda yanlış yazılım seçiminin mali etkisi daha ağır olabilir. Birkaç sayfalık basit bir brief bile ihtiyaçların unutulmasını ve yalnızca fiyat üzerinden karar verilmesini önler.

Yazılım seçerken fiyat mı özellik mi daha önemlidir?

İkisi birlikte değerlendirilmelidir. Çok kapsamlı fakat kullanılmayan bir yazılım gereksiz maliyet oluşturabilir. Ucuz fakat bakım, arıza veya tahsilat ihtiyaçlarını karşılamayan bir sistem ise kısa süre içinde değiştirilmek zorunda kalabilir.

Demo sırasında hangi işlemler mutlaka denenmelidir?

Bina ve asansör ekleme, bakım planlama, teknisyene görev atama, mobil bakım formu doldurma, arıza açma, fotoğraf ve imza ekleme, cari borçlandırma ve raporlama işlemleri denenmelidir.

Deneme süresinde bütün veriler aktarılmalı mı?

İlk aşamada bütün portföyü aktarmak yerine farklı özelliklere sahip birkaç bina ve asansörle pilot çalışma yapılabilir. Yazılım uygun bulunduğunda doğrulanmış veri şablonu üzerinden toplu aktarım gerçekleştirilmesi daha güvenlidir.

Satın alma briefi sözleşmeye eklenebilir mi?

Brief doğrudan sözleşme yerine geçmez. Ancak teklif ve sözleşme kapsamı hazırlanırken referans belge olarak kullanılabilir. Özellikle veri aktarımı, eğitim, destek ve zorunlu özellikler sözleşmede açık biçimde yer almalıdır.

Özet

Asansör yazılımı satın alma komitesi briefi, karar sürecini kişisel beğenilerden çıkararak ölçülebilir ihtiyaçlara bağlar. Firma sahibi yatırımın geri dönüşünü, operasyon sorumlusu bakım ve arıza akışını, teknisyen saha kullanımını, finans tarafı ise mali süreçleri aynı belge üzerinden değerlendirebilir.

Etkili bir brief; mevcut durum analizi, proje hedefleri, zorunlu özellikler, demo senaryosu, bütçe kalemleri ve puanlama tablosundan oluşmalıdır. Asansorex gibi sektörel çözümler değerlendirilirken de yalnızca özellik listesini incelemek yerine firmanın kendi bina, bakım, arıza ve tahsilat senaryoları üzerinden test yapılması daha sağlıklı bir satın alma kararı sağlar.