Belediye yazılımı nasıl seçilir?

Belediye yazılımı seçimi bir ürün seçimi değil, bir tedarik ve mimari kararıdır. Aynı "e-belediye yazılımı" başlığı altında; İçişleri Bakanlığı’nın merkezi e-Belediye Bilgi Sistemi, ticari bütünleşik paketler, modüler ürün aileleri ve belediyeye özel geliştirilen sistemler yan yana durur. Yanlış seçimin faturası yalnız bütçe değildir: veriye erişememek, tedarikçi değiştirememek ve her yeni entegrasyonda pazarlık masasına dönmek, ilk lisans bedelinden çok daha pahalıya mal olur. Bu sayfa; hangi markayı değil, hangi soruları önce sormanız gerektiğini anlatır ve kriter bazlı karşılaştırma sayfalarımıza açılır.

Belediye yazılımı nedir, neyi kapsar?

Belediye yazılımı; bir belediyenin mali süreçlerini (tahakkuk-tahsilat, bütçe, muhasebe), vatandaş hizmetlerini (başvuru, e-belediye portalı, mobil uygulama), mekânsal süreçlerini (imar, numarataj, kent bilgi sistemi / CBS) ve kurumsal işleyişini (EBYS, meclis kararları, personel) sayısal ortamda yürüten sistemlerin tümüdür. Türkiye’de bu resmin merkezinde artık kamu eliyle işletilen bir platform da vardır: 7099 sayılı Kanun’la (2018) İçişleri Bakanlığı’na kurulma ve işletilme yetkisi verilen e-Belediye Bilgi Sistemi, projenin resmî sitesindeki tanıma göre 45’i İçişleri, 18’i Çevre ve Şehircilik Bakanlığı tarafından hazırlanmak üzere toplam 63 modülden oluşacak şekilde kurgulanmıştır (belediye.gov.tr, modül listesi). Dolayısıyla seçim sorusu çoğu belediyede "hangi paket?" değil; "merkezi platformun üstüne ne koyacağız, neyi kendimize özel kuracağız?" sorusudur.

Seçim kriterleri çerçevesi: 8 başlık

Marka broşürlerini kapatın ve teklifleri şu sekiz başlıkta aynı tabloya koyun. Bir teklif bu başlıkların herhangi birinde cevap veremiyorsa, eksik olan sizin sorunuz değil, teklifin kendisidir.

1. Mevzuat uyumu: 5393 sayılı Belediye Kanunu süreçleri, mali mevzuat, KVKK ve — mekânsal veri tarafında — TUCBS/OGC standartları. "Uyumluyuz" cümlesi değil, hangi sürümle hangi tarihte uyum sağlandığı sorulmalı.
2. Veri sahipliği ve çıkış maliyeti: Sözleşme bittiğinde veriniz hangi formatta, kaç günde, hangi bedelle size teslim ediliyor? Bu madde şartnamede yoksa, fiilen kiracısınız demektir.
3. Entegrasyon yeteneği: MERNİS/KPS, e-Devlet Kapısı, bankalar, UAVT ve mevcut sistemlerinizle bağlantı. Ayrıntı için e-Devlet entegrasyonu çözüm sayfamıza bakabilirsiniz. Kapalı API, gelecekteki her projenizin vergisidir.
4. Toplam sahip olma maliyeti (TCO): İlk kurulum bedeli değil; 5 yıllık lisans + bakım + güncelleme + her entegrasyon/rapor talebinin ek ücreti toplamı. Ucuz görünen teklif, çoğu zaman ek talep kalemlerinde pahalıdır.
5. Ölçek uyumu: Büyükşehir için tasarlanmış bir sistemi belde belediyesine, belde için yazılmışı büyükşehre taşımak iki yönde de başarısızdır. Nüfus, personel sayısı ve işlem hacmi teklife yazılmalı.
6. Destek ve SLA: Yanıt ve çözüm süreleri saat cinsinden, cezai şartıyla birlikte. "7/24 destek" ifadesi, SLA tablosu yoksa pazarlama cümlesidir.
7. Güvenlik ve KVKK: Yetkilendirme, loglama, sızma testi geçmişi, verinin nerede barındırıldığı. Vatandaş verisi işleyen her modül için veri işleme envanteri istenmelidir.
8. Sürdürülebilirlik: Üreticinin ürün yol haritası, ekip büyüklüğü ve — özel geliştirmede — kaynak kodunun ve dokümantasyonun belediyeye teslimi. Sistemi ayakta tutacak bilginin kurumda birikmesi, tek kişiye veya tek firmaya bağlı kalmaması gerekir.

Bu sekiz başlık bir puanlama tablosuna dönüştürülebilir: her kritere belediyenizin öncelik ağırlığını verin (örneğin veri sahipliğine yüzde 20, devreye alma hızına yüzde 10), her teklifi aynı kanıt standardıyla puanlayın. Ağırlıkları ihaleden önce yazılı olarak sabitlemek, hem değerlendirmeyi tarafsızlaştırır hem de süreç sonunda "neden bu teklif?" sorusunun cevabını hazır eder.

Sık yapılan 6 hata

• Demoya göre karar vermek: Demo, ürünün en iyi gününü gösterir. Kararın girdisi demo değil; referans belediyede sahada görülen işleyiş ve şartname cevaplarıdır.
• İlk yıl maliyetiyle kıyaslamak: Yıllık lisans, bakım oranı, ek modül ve entegrasyon kalemleri 5 yıla yayılmadan iki teklif kıyaslanamaz.
• Veri devrini sözleşmeye yazmamak: En pahalı ders budur. Devir formatı, süresi ve bedeli en baştan yazılmalıdır.
• Mevcut veriyi yok saymak: Yıllarca birikmiş tahakkuk geçmişi, imar arşivi ve CBS katmanlarının yeni sisteme kayıpsız aktarımı ayrı bir iş kalemidir; teklifte yoksa sonradan pazarlık konusu olur.
• Her şeyi tek ihalede almak: Mali modüller, vatandaş portalı ve CBS farklı olgunlukta işlerdir. Tek dev ihale, en zayıf kalemin riskini tüm projeye bulaştırır.
• Personeli sürece katmamak: Sistemi kullanacak tahakkuk memuru ve zabıta ekibi seçim sürecinde yoksa, canlıya geçişte direnç ve "eski usule dönüş" kaçınılmazdır.

Şartname yaklaşımı: markadan değil, ihtiyaçtan yazın

İyi şartname bir marka tarifi değildir; doğrulanabilir yetenek listesidir. Pratik çerçeve şudur: önce mevcut durum envanteri (hangi sistemler var, hangi veriler nerede), sonra hedef süreçler (hangi işlem kaç adımda bitecek), sonra zorunlu standartlar (açık API, OGC WMS/WFS, e-Devlet servisleri, KVKK), en sonda kabul kriterleri (hangi testten geçince kabul edilecek). 4734 sayılı Kamu İhale Kanunu çerçevesinde rekabeti daraltan marka-model tarifi yerine işlevsel tanım kullanmak, hem hukuki riski azaltır hem daha çok teklif toplar. Şartnameye mutlaka girmesi gerekenler: veri sahipliği ve devir maddesi, SLA tablosu, entegrasyon protokolleri, eğitim saatleri ve — özel geliştirmede — kaynak kodu teslimi. Bu yaklaşımın CBS’ye uyarlanmış hâlini KBS/CBS çözüm sayfamızda, e-belediye geneline uyarlanmış hâlini e-belediye bilgi yönetim sistemi sayfamızda ayrıntılı anlatıyoruz.

Seçim süreci adım adım: örnek bir plan

İyi işleyen seçim süreçleri birbirine benzer. Aşağıdaki akış, orta ölçekli bir belediye için makul bir çerçevedir; ölçeğe göre daralır veya genişler, ama sıra değişmemelidir — sıranın bozulması, genellikle "önce ürün seçildi, sonra ihtiyaç ona uyduruldu" demektir:

1. Mevcut durum envanteri: Kullanılan tüm yazılımlar, sözleşme bitiş tarihleri, veri hacimleri ve entegrasyonlar tek tabloya yazılır. Merkezi e-Belediye modüllerinden hangilerinin kullanıldığı da bu tabloya girer.
2. İhtiyaç analizi: Her müdürlükle ayrı oturum; "hangi işlem bugün kaç adımda bitiyor, hedef ne" sorusuna ölçülebilir cevap alınır. Çıktı bir istek listesi değil, önceliklendirilmiş süreç listesi olmalıdır.
3. Pazar taraması ve model kararı: Merkezi platform + paket + modüler + özel geliştirme seçenekleri ihtiyaç listesiyle eşleştirilir; karşılaştırma sayfalarımızdaki kriter tabloları bu adım içindir.
4. Şartname yazımı: İşlevsel tanım + zorunlu standartlar + kabul kriterleri + veri devri maddesi. Şartnameyi ürün broşüründen değil, ihtiyaç analizinden türetin.
5. Doğrulama: Demo yerine referans belediye ziyareti ve örnek veriyle test senaryosu. Teklif sahibine kendi verinizden bir kesitle canlı senaryo çalıştırtmak, yüz sayfalık broşürden daha çok şey söyler.
6. TCO tablosu ve karar: Tüm teklifler 5 yıllık toplam maliyet tablosunda eşitlenir; karar gerekçesi yazılı hâle getirilir. Bu belge, hem meclis sunumunda hem olası itirazlarda sizi korur.

5 yıllık TCO tablosu nasıl kurulur?

Karşılaştırmanın omurgası bu tablodur. Satırlar: ilk kurulum/lisans bedeli, yıllık bakım ve güncelleme, kullanıcı/modül genişleme maliyeti, entegrasyon kalemleri, eğitim, veri taşıma ve — çoğu tabloda unutulan satır — çıkış maliyeti (sözleşme sonunda veri devri ve geçiş). Sütunlar: değerlendirilen her model/teklif. İki pratik kural: birincisi, üreticinin sözlü "o dahil" cevabı tabloya yazılı teklif eki olmadan işlenmez; ikincisi, özel geliştirmede geliştirme bedelinin öne yüklü, paketlerde ise tekrarlayan lisansın yıllara yayılı olduğu unutulmadan aynı 5 yıllık ufukta kıyas yapılır. Tablo dürüst kurulduğunda çoğu belediyede sonuç, tek bir modelin zaferi değil karma bir mimari çıkar: çekirdekte merkezi/hazır bileşenler, farklılaştıran katmanlarda özel geliştirme.

Kararı kim verir? Komisyon ve yönetişim

Belediye yazılımı seçimlerinin gözden kaçan başarısızlık nedeni teknik değil yönetişimseldir: kararı tek başına bilgi işlem birimi verir, sistemi ise tahakkuk, imar ve zabıta kullanır. Sağlıklı kurgu, en az dört sesin masada olmasıdır — süreci yürüten müdürlükler (gerçek ihtiyaç), mali hizmetler (bütçe ve 5 yıllık yük), bilgi işlem (entegrasyon ve güvenlik) ve hukuk/ihale birimi (şartname ve sözleşme maddeleri). Bu komisyon ihale ilanından önce kurulmalı, kriter ağırlıkları ve kabul kriterleri yazılı olarak sabitlenmelidir; ihale sürecinin ortasında değişen ağırlık, hem itiraz gerekçesi üretir hem de kararın gerekçesini zayıflatır. Meclis onayı gereken kalemlerde, teknik gerekçe notunun meclis sunumundan önce hazır olması süreci belirgin biçimde hızlandırır: sunumda tartışılması gereken şey ürünün özellikleri değil, belediyenin hangi ihtiyacına hangi modelle cevap verdiğidir.

Tedarik modeli kararı: karşılaştırma sayfalarımız

Kriterler netleşince sıra tedarik modeline gelir. Belediyelerin en sık karşılaştığı kararları ayrı sayfalarda, kriter bazlı ve tarafsız biçimde karşılaştırdık — "en iyi" listesi değil, hangi durumda hangisinin mantıklı olduğunu gösteren analizler: