Asansör Arıza Yönetim Yazılımı İhale Kriterleri

İÇERİK

Asansör bakım firmaları büyüdükçe arıza operasyonunu telefon, WhatsApp grupları ve Excel dosyalarıyla yönetmek giderek zorlaşır. Bu noktada asansör arıza yönetim yazılımı satın almak yalnızca yeni bir program edinmek değil, firmanın günlük servis operasyonunun önemli bir bölümünü dijital sisteme taşımak anlamına gelir. Özellikle birden fazla yazılım firmasından teklif alınacaksa seçim sürecinin kişisel beğeniye veya yalnızca yıllık lisans ücretine göre yapılması ciddi risk oluşturabilir.

Doğru yaklaşım, ihtiyaçları önceden belirlemek ve aday yazılımları aynı kriterlerle değerlendirmektir. Böylece firma sahibi hangi çözümün gerçekten operasyonuna uyduğunu görebilir, teknisyenler sahada kullanamayacakları bir sistemle karşılaşmaz ve satın alma sonrasında beklenmedik ek maliyetlerin önüne geçilebilir.

Asansör Yazılımı İhalesinde Önce İhtiyaç Tanımlanmalı

İhale veya teklif toplama sürecinde yapılan en yaygın hatalardan biri, yazılım firmalarına yalnızca “Arıza takip programınızın fiyatı nedir?” diye sormaktır. Çünkü aynı isim altında sunulan iki yazılımın kapsamı tamamen farklı olabilir.

Bir sistem sadece arıza kaydı açıp kapatabilirken başka bir sistem;

• Arıza kaydı oluşturabilir,
• Teknisyene otomatik veya manuel görev atayabilir,
• Teknisyenin arızayı sahiplenmesini sağlayabilir,
• Müdahale süresini ölçebilir,
• Fotoğraf ve servis formu ekletebilir,
• Kullanılan parçaları kaydedebilir,
• Tahsilat işlemi oluşturabilir,
• Bina yöneticisini SMS veya başka kanallardan bilgilendirebilir,
• Arıza geçmişini bina ve asansör bazında raporlayabilir.

Bu nedenle ihale dokümanının ilk bölümü firmanın gerçek operasyon ihtiyacını tanımlamalıdır.

Örneğin 80 asansöre hizmet veren üç kişilik bir firmanın ihtiyacı ile 2.000 asansörlük portföyü 30 teknisyenle yöneten bir firmanın ihtiyacı aynı değildir.

İhtiyaç analizi yapılırken en az şu sorular cevaplanmalıdır:

1. Kaç aktif asansör yönetilecek?
2. Aynı anda kaç teknisyen sistemi kullanacak?
3. Aylık ortalama kaç arıza kaydı oluşuyor?
4. Arızalar telefonla mı, QR kodla mı, müşteri portalından mı alınacak?
5. Teknisyen konumu veya müdahale süresi takip edilecek mi?
6. Servis formu ve müşteri imzası alınacak mı?
7. Arıza sonrası kullanılan parça veya tahsilat kaydedilecek mi?
8. Mevcut bakım, cari veya faturalandırma sistemiyle bağlantı gerekiyor mu?

Bu bilgiler netleşmeden yapılan fiyat karşılaştırması sağlıklı olmaz.

Teknik Şartnamede Olması Gereken Arıza Yönetimi Özellikleri

Asansör arıza yönetim yazılımının merkezinde arıza kaydının açılmasından kapanmasına kadar geçen süreç bulunur. Bu nedenle ihale kriterlerinde öncelikle operasyon akışı değerlendirilmelidir.

Arıza kaydı açma yöntemleri

Yazılımın yalnızca ofis personelinin manuel kayıt açmasına bağlı olması operasyonu yavaşlatabilir. İhtiyaca göre aşağıdaki kanalların desteklenmesi avantaj sağlar:

• Ofisten manuel arıza kaydı,
• Mobil cihazdan kayıt,
• QR kod üzerinden arıza bildirimi,
• Müşteri veya bina yöneticisi üzerinden bildirim,
• Telefonla gelen çağrının hızlı kayda dönüştürülmesi.

Burada amaç mümkün olduğunca fazla kanal istemek değil, firmanın kullandığı kanalların kesintisiz şekilde sisteme aktarılmasını sağlamaktır.

Teknisyen atama ve sahiplenme

Arıza kaydı oluşturulduktan sonra “Kim ilgileniyor?” sorusunun ortadan kalkması gerekir.

İhale kriterine örneğin şu işlevler yazılabilir:

• Teknisyen veya ekip atama,
• Görev bildirimi,
• Arızayı sahiplenme,
• Müdahale başlangıç zamanı,
• Arızanın durumunu güncelleme,
• Başka personele aktarım,
• Çözüm ve kapanış kaydı.

Özellikle yoğun servis firmalarında açık, bekleyen, müdahale edilen ve kapatılmış arızaların ayrılabilmesi operasyon sorumlusunun iş yükünü ciddi ölçüde azaltır.

Arıza geçmişi

Bir asansörde son altı ay içinde aynı kapı problemi beş kez yaşanmışsa bu bilgi yalnızca eski servis fişlerinin arasında kalmamalıdır.

İyi bir sistemde bina ve asansör bazında;

• Arıza tarihi,
• Arıza türü,
• Müdahale eden personel,
• Çözüm açıklaması,
• Kullanılan malzeme,
• Fotoğraf,
• Servis formu

gibi geçmiş kayıtların erişilebilir olması beklenmelidir.

Bu geçmiş, tekrar eden sorunların tespitinde ve bina yöneticisiyle yapılacak görüşmelerde önemli bir veri kaynağıdır.

Mobil Kullanım ve Saha Performansı Ayrı Bir İhale Kriteri Olmalı

Bir arıza yönetim sisteminin masaüstünde iyi görünmesi yeterli değildir. Asıl kullanıcıların önemli bölümü sahadaki teknisyenlerdir.

Bu nedenle satın alma değerlendirmesinde demo yalnızca ofis bilgisayarından yapılmamalıdır. Teknisyenin gerçek kullanım senaryosu da denenmelidir.

Örneğin teklif veren firmadan şu senaryoyu canlı olarak göstermesi istenebilir:

Yeni arıza kaydı oluşturulsun, teknisyene atansın, teknisyen telefondan görevi görsün, konuma gitsin, fotoğraf eklesin, servis formunu tamamlasın ve arızayı kapatsın.

Bu tek senaryo bile yazılımın saha kullanım kalitesi hakkında önemli fikir verir.

Dikkat edilmesi gereken başlıca noktalar şunlardır:

• Mobil ekranların hızlı açılması,
• Teknisyenin birkaç adımda görevi tamamlayabilmesi,
• Fotoğraf ekleyebilmesi,
• Açıklama yazabilmesi,
• Gerekliyse dijital imza alabilmesi,
• Düşük internet bağlantısında çalışabilmesi,
• İşlem sonrasında bilgilerin merkezi kayda aktarılması.

Özellikle makine dairesi, bodrum kat veya çekim gücü düşük bölgelerde çalışan ekipler için bağlantı kalitesi önemli bir kriterdir. Bu nedenle demo sırasında yalnızca güçlü ofis internetinde yapılan testlere güvenmek yerine saha senaryosu değerlendirilmelidir.

Veri Güvenliği, Yedekleme ve Veri Sahipliği Sorgulanmalı

Asansör yazılımında saklanan bilgiler zaman içinde firmanın operasyon hafızasına dönüşür. Bina kayıtları, arıza geçmişi, servis formları, müşteri bilgileri ve personel işlemleri yıllar boyunca birikebilir.

Bu nedenle ihale dokümanında “Veriler güvenlidir” gibi genel bir ifade yerine somut sorular sorulmalıdır.

Kontrol noktası	Tedarikçiye sorulacak soru
Veri yedekleme	Veriler hangi sıklıkta yedekleniyor?
Yetkilendirme	Kullanıcıların erişim yetkileri ayrılabiliyor mu?
Veri aktarımı	Sözleşme bittiğinde veriler hangi formatta teslim ediliyor?
Kayıt geçmişi	İşlemleri yapan kullanıcı ve tarih bilgisi izlenebiliyor mu?
Erişim güvenliği	Kullanıcı hesapları ve bağlantılar nasıl korunuyor?
İş sürekliliği	Sunucu veya bağlantı problemi durumunda nasıl aksiyon alınıyor?

Özellikle veri sahipliği ihale öncesinde netleştirilmesi gereken konulardan biridir. Firma yıllarca kullandığı yazılımı değiştirmek istediğinde bina ve arıza kayıtlarına erişememesi büyük operasyon riski oluşturur.

Bu nedenle sözleşmede verilerin gerektiğinde müşteriye aktarılabilmesi açık şekilde tanımlanmalıdır.

Asansorex gibi bakım ve arıza süreçlerini tek sistemde takip etmeyi amaçlayan çözümler değerlendirilirken de yalnızca ekran özelliklerine değil; veri geçmişinin tutulması, saha kayıtlarının merkezi sisteme aktarılması ve firmanın kendi operasyon verisine erişebilmesi gibi kriterlere bakmak daha sağlıklıdır.

Destek, SLA ve Entegrasyon Kriterleri Fiyat Kadar Önemlidir

Yazılımın satın alınması sürecin başlangıcıdır. Sistemin kurulması, personelin eğitilmesi ve günlük operasyon sırasında oluşabilecek problemlerin çözülmesi gerekir.

Bu nedenle teklif isteyen firma destek hizmetini ayrıca puanlamalıdır.

Örneğin ihale şartnamesinde şu bilgiler talep edilebilir:

• Destek verilen gün ve saatler,
• Destek kanalları,
• Kritik sorunlarda hedef ilk yanıt süresi,
• Eğitim kapsamı,
• İlk veri aktarım desteği,
• Yeni personel eğitim yöntemi,
• Güncellemelerin lisansa dahil olup olmadığı.

SLA hedefleri firmanın operasyonuna göre belirlenebilir. Örneğin kritik bir sistem erişim probleminde 1-2 saat içinde ilk dönüş hedeflenmesi bir satın alma kriteri olarak konulabilir; ancak bu değer yasal bir zorunluluk değil, tarafların hizmet beklentisini tanımlayan örnek bir ticari kriterdir.

Entegrasyon konusu da ayrıca incelenmelidir. Firma bugün sadece arıza takibi istese bile ileride bakım, teklif, cari, e-Fatura, SMS veya müşteri portalı süreçlerini sisteme bağlamak isteyebilir.

Bu nedenle ihale sırasında “Bugünkü ihtiyacı karşılıyor mu?” sorusunun yanında “Firma büyüdüğünde sistemi değiştirmek zorunda kalacak mıyız?” sorusu da sorulmalıdır.

Yazılım İhalesi İçin Örnek Puanlama Tablosu

Teklifleri değerlendirmenin en sağlıklı yöntemlerinden biri ağırlıklı puanlama sistemidir. Böylece en ucuz ürünün otomatik olarak en iyi seçenek kabul edilmesinin önüne geçilir.

Aşağıdaki tablo örnek bir değerlendirme modelidir:

Kriter	Örnek ağırlık
Arıza yönetimi fonksiyonları	%25
Mobil ve saha kullanım kolaylığı	%20
Raporlama ve geçmiş kayıtları	%10
Veri güvenliği ve yedekleme	%15
Destek ve eğitim	%15
Entegrasyon ve ölçeklenebilirlik	%5
Toplam sahip olma maliyeti	%10
Toplam	%100

Bu oranlar sabit değildir. Firmanın ihtiyacına göre değiştirilebilir.

Örneğin 40 teknisyeni bulunan bir işletme mobil kullanıma daha fazla ağırlık verebilir. Küçük ancak hızla büyüyen bir firma ise ölçeklenebilirlik ve entegrasyon kriterini yükseltebilir.

Kamu alımlarında teknik şartnamelerin verimlilik ve fonksiyonelliği sağlamaya yönelik olması, rekabeti engelleyici düzenlemelerden kaçınması ve istekliler açısından fırsat eşitliğini gözetmesi gerekir. Kamu İhale Kurumu kararlarında da Hizmet Alımı İhaleleri Uygulama Yönetmeliği'nin teknik şartnamelere ilişkin bu yaklaşımı açık biçimde aktarılmaktadır. ([EKAP][1])

Bu nedenle özellikle kamu ihalesi hazırlanırken şartnameyi tek bir yazılımın ekran isimlerini veya gereksiz biçimde belirli bir ürünü tarif edecek şekilde oluşturmak yerine ihtiyaç duyulan fonksiyonel sonucu tanımlamak daha doğru bir yaklaşımdır.

Demo ve Pilot Test İhale Değerlendirmesine Dahil Edilmeli

Kağıt üzerinde neredeyse bütün yazılımlar benzer özellikler sunabilir. Asıl fark kullanım sırasında ortaya çıkar.

Bu nedenle mümkünse teklif değerlendirmesinde uygulamalı demo kriteri kullanılmalıdır.

Demo sırasında örnek bir operasyon oluşturulabilir:

1. Örnek bina ve asansör oluşturun.
2. Yeni arıza kaydı açın.
3. Arızayı bir teknisyene atayın.
4. Teknisyenin telefondan bildirimi görmesini sağlayın.
5. Teknisyenin fotoğraf ve açıklama eklemesini isteyin.
6. Arıza kapanış formunu tamamlayın.
7. Yönetici tarafından kapanan kaydı kontrol edin.
8. Aynı asansörün arıza geçmişini görüntüleyin.
9. Arıza müdahale süresini rapordan kontrol edin.

Tedarikçinin bu akışı önceden hazırlanmış sunum görüntüleri yerine gerçek sistem üzerinde göstermesi daha anlamlıdır.

Mümkün olduğunda birkaç günlük veya sınırlı kullanıcıyla yapılan pilot kullanım da teknisyenlerin sisteme nasıl adapte olacağını anlamayı kolaylaştırır.

Sadece Lisans Fiyatına Değil Toplam Maliyete Bakılmalı

Bir yazılımın yıllık fiyatının düşük olması toplam maliyetinin de düşük olduğu anlamına gelmez.

Satın alma değerlendirmesinde şu kalemler birlikte hesaplanmalıdır:

• Yıllık veya aylık lisans bedeli,
• Kullanıcı başına ek ücret,
• Asansör sayısına bağlı ücretler,
• Kurulum bedeli,
• Eğitim ücreti,
• Veri aktarım maliyeti,
• SMS veya benzeri kullanım kontörleri,
• Entegrasyon ücretleri,
• Ek modül ücretleri,
• Güncelleme bedelleri,
• Destek paketi maliyeti.

Örneğin ilk yıl 12.000 TL görünen bir yazılımın ek kullanıcı, eğitim, veri aktarımı ve modüllerle toplam maliyeti daha yüksek olabilir. Buna karşılık başlangıç fiyatı daha yüksek görünen fakat ihtiyaç duyulan fonksiyonların tamamını kapsayan başka bir sistem uzun vadede daha ekonomik hale gelebilir.

Bu nedenle teklif formunda yalnızca “yıllık lisans fiyatı” değil, mümkünse 1 yıllık ve 3 yıllık tahmini toplam sahip olma maliyeti istenmelidir.

Sıkça Sorulan Sorular

Asansör arıza yönetim yazılımı ihalesinde en önemli kriter nedir?

Tek bir kriter yoktur. Arıza yönetimi fonksiyonları, mobil kullanım, veri güvenliği, destek ve toplam maliyet birlikte değerlendirilmelidir. Özellikle teknisyenlerin sahada sistemi kolay kullanabilmesi kritik öneme sahiptir.

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

Her zaman değil. Düşük lisans fiyatı; ek kullanıcı, eğitim, entegrasyon veya destek maliyetleri nedeniyle sonradan yükselebilir. Toplam sahip olma maliyetine bakmak daha doğru sonuç verir.

İhale öncesinde demo yapılmalı mı?

Evet. Demo sırasında gerçek bir arıza senaryosunun baştan sona uygulanması önerilir. Böylece yalnızca özellik listesini değil, yazılımın günlük kullanımını da değerlendirebilirsiniz.

Yazılımın verileri teslim edebilmesi şartnameye yazılmalı mı?

Evet. Sözleşmenin sona ermesi veya yazılım değişikliği durumunda firmanın kendi bina, asansör ve operasyon kayıtlarını hangi formatlarda alabileceği önceden netleştirilmelidir.

Arıza yazılımında offline kullanım önemli mi?

Teknisyenler bodrum, makine dairesi veya mobil bağlantının zayıf olduğu alanlarda çalışıyorsa önemlidir. Bu nedenle bağlantı zayıfken veri kaydetme ve sonradan senkronizasyon kabiliyeti demo sırasında test edilmelidir.

Asansör arıza yönetimi bakım sistemiyle birlikte çalışmalı mı?

Mümkünse evet. Bakım ve arıza kayıtlarının aynı asansör geçmişinde görülebilmesi, tekrar eden sorunların analizini kolaylaştırır. Asansorex gibi bakım ve arıza süreçlerini birlikte yöneten sistemlerin avantajlarından biri, farklı operasyon kayıtlarının tek noktada ilişkilendirilebilmesidir.

Özet

Asansör arıza yönetim yazılımı ihalesinde doğru seçim yalnızca fiyat karşılaştırmasıyla yapılamaz. Satın alma öncesinde firmanın operasyon ihtiyaçları belirlenmeli; arıza kaydı, teknisyen atama, mobil kullanım, servis formu, geçmiş kayıtları, veri güvenliği, yedekleme, destek, entegrasyon ve toplam maliyet gibi başlıklar ayrı ayrı değerlendirilmelidir.

En sağlıklı yöntem, aday yazılımlar için ortak bir teknik şartname ve puanlama tablosu hazırlamak, ardından gerçek saha senaryosu üzerinden demo yapmaktır. Böylece firma sahibi satın alma kararını sunumlara veya satış vaatlerine göre değil, ölçülebilir kriterlere göre verebilir; teknisyenlerin gerçekten kullanabileceği ve işletmenin büyümesine uyum sağlayabilecek bir sistem seçebilir.