İhtiyaç analizi yapılmadan yazılım seçmenin sonuçları
Belediye yazılım seçimi sürecinde en sık görülen hata, kurumun gerçek ihtiyacı netleştirilmeden ürün bakmaya başlanmasıdır. Çoğu zaman süreç şöyle ilerler: Bir müdürlük mevcut işleyişten memnun değildir, başka bir belediyede kullanılan bir sistem duyulur, kısa bir sunum yapılır ve “bizde de olsun” denir. Ancak belediyede sorun çoğu zaman yazılım eksikliği değil, dağınık süreçler, belirsiz görev paylaşımı ve standartlaşmamış veri yapısıdır.
Örneğin bir belediyede beyaz masa başvuruları telefon, e-posta, WhatsApp, CİMER, sosyal medya ve yüz yüze kanallardan geliyor olabilir. Eğer bu başvuruların hangi müdürlüğe nasıl yönlendirileceği, hangi sürede cevaplanacağı ve kapanış bilgisinin nasıl girileceği tanımlı değilse, alınacak en pahalı sistem bile karışıklığı tek başına çözmez. Sonuçta ekranlar değişir ama işleyiş değişmez. Personel yine Excel listesi tutar, müdürlükler yine birbirini telefonla arar, vatandaş ise “başvurum ne durumda” diye tekrar tekrar belediyeyi aramak zorunda kalır.
İhtiyaç analizi yapılmadan alınan yazılımlarda şu sonuçlar sık görülür:
- Birimlerin sisteme farklı amaçlarla bakması nedeniyle düşük kullanım oranı oluşur.
- Eski alışkanlıklar devam eder; evrak kayıt ayrı, talep takibi ayrı, raporlama ayrı yerde tutulur.
- Veri kalitesi bozulur; aynı vatandaş için birden fazla kayıt açılır, adres bilgileri standart olmaz.
- Bütçe harcanır ama yöneticinin görmek istediği net raporlar yine üretilemez.
- Yeni yazılım, eski dağınıklığın dijital versiyonuna dönüşür.
Bu durum sadece belediyelerde değil, okullarda ve sağlık kurumlarında da görülür. Bir devlet okulunda veli talepleri için sistem alınır ama öğretmen, idare ve rehberlik servisi hangi talebin kimde kapanacağını netleştirmezse sistem kısa sürede terk edilir. Bir kamu hastanesinde randevu dışı başvuru, cihaz bakım takibi veya hasta yakını geri bildirimleri için ayrı ayrı uygulamalar alınır ama süreç sahipliği belirlenmezse personel yine telefon ve kâğıt notlarla ilerler.
Doğru yaklaşım, yazılım demosundan önce mevcut işleyişin masaya yatırılmasıdır. Hangi müdürlük hangi veriyi üretiyor, hangi işlem kaç adımda tamamlanıyor, en çok gecikme nerede yaşanıyor, vatandaş en çok ne için arıyor, hangi rapor gerçekten gerekiyor? Belediye yazılım seçimi, ürün kataloğu üzerinden değil, süreç haritası üzerinden yapılmalıdır.
“Her şeyi yapan sistem” vaadi neden riskli olabilir?
Belediye yöneticilerinin düştüğü ikinci yaygın hata, tüm ihtiyaçları tek başına çözeceği söylenen sistemlere fazla güvenmektir. “Beyaz masa var, CRM var, saha ekipleri var, gelir yönetimi var, insan kaynakları var, mobil uygulama var, çağrı merkezi var” şeklinde uzayan listeler ilk bakışta cazip görünür. Ancak kamu kurumlarında geniş kapsam her zaman verimli kullanım anlamına gelmez.
Çünkü belediyenin ihtiyacı “çok modül” değil, çalışan ve sürdürülebilir bir yapıdır. Bir sistemin her şeyi yapabildiği söyleniyorsa şu riskler ortaya çıkar:
- Belediyenin hiç kullanmayacağı modüller için lisans ve bakım maliyeti oluşur.
- Arayüz karmaşık hale gelir, personelin öğrenme süresi uzar.
- Her müdürlüğün özel ihtiyacına tam uymayan genel çözümler ortaya çıkar.
- Tek tedarikçiye aşırı bağımlılık oluşur.
- Entegrasyon vaat edilir ama sahada manuel iş yükü devam eder.
Gerçek hayatta bunun karşılığı şudur: Fen işleri müdürlüğü saha arıza takibi için hızlı bir ekran isterken, sistemde onlarca menü ve gereksiz alan vardır. Zabıta ekipleri mobil cihazdan kolay işlem yapmak ister ama uygulama yavaş çalışır. Kültür müdürlüğü etkinlik kayıtlarını basitçe takip etmek isterken, personel karmaşık formlar nedeniyle Excel’e geri döner. Sonra kurum içinde şu cümle duyulur: “Sistem var ama kullanışlı değil.”
Bir diğer risk de entegrasyon tarafındadır. Belediyeler çoğu zaman e-Devlet kapısı, MERNİS, TAKBİS, KEP, SMS servisleri, çağrı merkezi altyapısı, elektronik belge yönetimi ve ödeme sistemleriyle uyum bekler. Sunumlarda “entegre olur” demek kolaydır; önemli olan bunun hangi yöntemle, hangi süre içinde ve hangi ek maliyetle yapılacağıdır. Özellikle vatandaş verisi işleniyorsa KVKK açısından veri minimizasyonu, erişim yetkileri, log kayıtları ve saklama politikaları net olmalıdır. İnternet erişimi, kullanıcı hareketleri ve kayıtların tutulması tarafında 5651 sayılı Kanun kapsamındaki yükümlülüklerin de göz ardı edilmemesi gerekir.
Bu nedenle belediye yazılım seçimi yapılırken “tek sistem her şeyi çözer” yaklaşımı yerine, “en kritik süreçleri sorunsuz yürüten, gerektiğinde diğer sistemlerle konuşabilen yapı” tercih edilmelidir. Az ama çalışan modül, çok ama kullanılmayan modülden daha değerlidir.
Kullanım kolaylığı, destek ve devreye alma süresi neden kritik?
Kamu kurumlarında bir yazılımın başarısını belirleyen şey çoğu zaman teknik özellik listesi değil, günlük kullanım gerçekliğidir. Belediyede personelin zamanı sınırlıdır. Vatandaş veznede bekler, telefonlar çalar, müdürlüklerden acil dönüş beklenir, sahadaki ekip anlık bilgi ister. Böyle bir ortamda zor öğrenilen, yavaş çalışan veya her işlem için teknik destek gerektiren bir sistemin yaşama şansı düşüktür.
Özellikle beyaz masa, evrak kayıt, ruhsat, tahsilat veya saha ekip yönetimi gibi alanlarda kullanım kolaylığı kritik önemdedir. Çünkü bu birimlerde personel devir hızı olabilir, geçici görevlendirmeler yaşanabilir ve herkesin ileri düzey teknik bilgiye sahip olması beklenemez. Eğer yeni gelen bir personel temel işlemleri kısa bir eğitimle yapamıyorsa, kurum yine eski yöntemlere döner.
Destek konusu da çoğu zaman satın alma aşamasında yeterince sorgulanmaz. Oysa belediyede sorunlar mesai saatine göre çıkmaz. Meclis öncesi rapor alınamaz, hafta sonu etkinliğinde kayıt ekranı açılmaz, saha ekibi mobil uygulamaya giremez. Bu durumda tedarikçinin sadece satış ekibinin değil, gerçek destek yapısının ne kadar güçlü olduğu önemlidir. Destek taleplerine dönüş süresi, uzaktan bağlantı imkânı, yerinde müdahale kapasitesi ve eğitim materyalleri mutlaka sorulmalıdır.
Devreye alma süresi de göz ardı edilen bir başlıktır. Bazı projeler kağıt üzerinde çok iyi görünür ama 8-10 ay süren kurulum, veri taşıma ve uyarlama süreçleri nedeniyle kurumun enerjisini tüketir. Bu sırada eski sistem de yeni sistem de birlikte yürür; personel iki kez veri girmek zorunda kalır. Sonuçta hem yorgunluk hem direnç oluşur.
Gerçekçi bir örnek verelim: Bir ilçe belediyesi, vatandaş taleplerini tek noktadan yönetmek için yeni sistem alıyor. Ancak eski başvuru kayıtları farklı Excel dosyalarında, bazıları e-postalarda, bazıları da sadece personelin kişisel notlarında. Veri temizliği yapılmadan geçişe başlanıyor. Eğitim sadece bir kez veriliyor. İlk hafta sonunda personel eski listeye geri dönüyor çünkü yeni sistemde arama yapmak zor, ekranlar karışık ve müdürlük bazlı raporlar hazır değil. Kağıt üzerinde proje tamamlanmış görünse de fiiliyatta kullanım düşüyor.
Bu nedenle belediye yazılım seçimi yapılırken şu üç konu birlikte değerlendirilmelidir: Kullanıcı ekranı ne kadar sade, destek ne kadar erişilebilir, sistem ne kadar sürede gerçek kullanıma geçebilir? Kamu tarafında “bir gün lazım olur” diye alınan özelliklerden çok, “yarın sabah kullanılabilir mi” sorusu daha belirleyicidir.
Satın alma öncesi sorulması gereken temel sorular
Yanlış seçim riskini azaltmanın en pratik yolu, satın alma öncesinde doğru soruları sormaktır. Sunumlarda anlatılan genel ifadeler yerine, belediyenin kendi işleyişine dokunan net sorular sorulmalıdır. Aşağıdaki başlıklar belediye yöneticileri için iyi bir kontrol listesi olabilir:
- Bu yazılım hangi somut sorunumuzu çözüyor? Telefon trafiğini mi azaltacak, raporlamayı mı hızlandıracak, evrak kaybını mı önleyecek?
- Hangi müdürlükler aktif kullanacak? Her birimin rolü ve yetkisi tanımlanabiliyor mu?
- Bugün kullandığımız Excel dosyaları, e-posta akışları ve eski kayıtlar nasıl taşınacak?
- e-Devlet, EBYS, KEP, SMS, ödeme altyapısı veya diğer kurumsal sistemlerle entegrasyon hazır mı, ayrıca mı geliştirilecek?
- Mobil kullanım gerçekten sahaya uygun mu? Zabıta, fen işleri, park bahçeler ekipleri bunu rahat kullanabilir mi?
- Yetkilendirme, loglama ve veri erişimi KVKK’ya uygun şekilde yönetilebiliyor mu?
- Sistem üzerinde yapılan işlemler denetlenebilir mi? Gerekli kayıtlar 5651 sayılı Kanun çerçevesinde tutulabiliyor mu?
- Destek taleplerine dönüş süresi nedir? Arıza durumunda tek muhatap kim olacak?
- Eğitim bir defalık mı, tekrar eden eğitim ve kullanıcı dokümantasyonu var mı?
- Devreye alma için gerçekçi takvim nedir? Pilot uygulama yapılacak mı?
- Lisans, bakım, entegrasyon, eğitim ve ek geliştirme maliyetleri ayrı ayrı net mi?
- Benzer ölçekte hangi belediyelerde kullanılıyor? Mümkünse o kurumlarla doğrudan görüşülebilir mi?
Burada özellikle referans kontrolü önemlidir. Sadece “birçok belediyede kullanılıyor” ifadesi yeterli değildir. Nüfus ölçeği, hizmet çeşitliliği ve organizasyon yapısı benzer belediyelerden örnek istenmelidir. Mümkünse bilgi işlem müdürlüğü, ilgili müdürlük ve son kullanıcı ile ayrı ayrı görüşülmelidir. Çünkü yazılımı satın alan ile her gün kullanan kişinin değerlendirmesi farklı olabilir.
Ayrıca ihale ve satın alma sürecinde teknik şartnamenin gerçek ihtiyaca göre hazırlanması gerekir. Şartname, katalogdan kopyalanmış genel maddelerden oluşursa, seçim süreci sağlıklı ilerlemez. Teknik kriterler kadar kullanım senaryoları da tarif edilmelidir. Örneğin “vatandaş başvurusu alındığında ilgili müdürlüğe otomatik yönlensin, süre aşımında uyarı versin, kapanışta SMS gitsin, yönetici ekranında günlük bekleyen işler görülsün” gibi somut beklentiler yazılmalıdır.
Sonuç olarak belediye yazılım seçimi, sadece bir ürün satın alma işi değildir; kurumun çalışma biçimini etkileyen yönetsel bir karardır. İhtiyaç analizi yapılmadan, “her şeyi yapan sistem” vaatlerine kapılarak, kullanım kolaylığı ve destek sorgulanmadan verilen kararlar çoğu zaman bütçe kaybına, düşük kullanım oranına ve yeni bir dağınıklığa yol açar. Doğru yöntem ise sade ilerlemektir: Önce sorunu netleştirmek, sonra süreci tanımlamak, ardından kurumun gerçekten kullanabileceği çözümü seçmek. Belediyelerde iyi yazılım, en çok özellik sunan değil, vatandaş hizmetini ve kurum içi işleyişi gerçekten kolaylaştıran yazılımdır.