E-belediye çözüm türleri: bütünleşik paket, modüler mimari, özel geliştirme

Bir belediye e-belediye yatırımı planlarken üç tedarik yaklaşımıyla karşılaşır: bütünleşik ticari paket (tüm modüller tek üreticiden), modüler mimari (her ihtiyaç için ayrı ürün, entegrasyonla birleştirme) ve özel geliştirme (belediyenin süreçlerine göre yazılan sistem). Türkiye’de bu karar artık boşlukta verilmiyor: 7099 sayılı Kanun’la (2018) İçişleri Bakanlığı’na kurma ve işletme yetkisi verilen e-Belediye Bilgi Sistemi, projenin resmî modül listesine göre 45’i İçişleri Bakanlığı, 18’i Çevre ve Şehircilik Bakanlığı tarafından hazırlanmak üzere toplam 63 modülden oluşacak şekilde kurgulandı (belediye.gov.tr, modül listesi); 1 Ocak 2026’da Program Bütçe Modülü uygulamaya alındı ve 2026 boyunca yeni belediyeler mali modülleriyle sisteme katılmaya devam ediyor (belediye.gov.tr duyuruları, 2026). Bu, karşılaştırmanın zeminini değiştirir: standart mali süreçler merkezileşirken, belediyelerin kendi tedarik kararları giderek vatandaş deneyimi, mekânsal veri ve yapay zeka katmanlarına kayıyor.

Karşılaştırma kriterleri

Üç yaklaşımı aynı terazide tartmak için altı kriter kullanıyoruz: devreye alma süresi (imzadan canlıya), maliyet yapısı (ilk bedel + 5 yıllık toplam sahip olma maliyeti davranışı), esneklik (belediyeye özgü sürece uyarlanabilme), entegrasyon (MERNİS/KPS, e-Devlet, bankalar, mevcut sistemler), veri sahipliği ve tedarikçi bağımlılığı (lock-in) ve ihale/şartname pratiği. Aşağıdaki tablo yaklaşım türlerinin yapısal özelliklerini karşılaştırır; belirli bir markanın taahhüdü değildir.

Bütünleşik paket: hız ve tek muhatap, karşılığında şablona uyum

Güçlü yanları: Modüller arası uyum üreticinin sorumluluğundadır; tek sözleşme, tek destek hattı vardır; kurulum ve eğitim süreçleri denenmiş şablonlarla ilerler. Standart işleyen, bilgi işlem kadrosu dar belediyeler için öngörülebilir bir yoldur. Zayıf yanları: Belediyenin süreci ürünün şablonundan saparsa uyarlama ya pahalıdır ya mümkün değildir; yıllar içinde birikmiş veri tek üreticinin veri modelinde yaşar ve devir maddesi yazılmamışsa tedarikçi değiştirmek fiilen yeni bir projeye dönüşür. Kritik denetim noktası, sözleşmedeki veri devri ve format maddesidir.

Modüler mimari: her işe en uygun araç, karşılığında entegrasyon yükü

Güçlü yanları: Tahakkuk için ayrı, EBYS için ayrı, CBS için ayrı ürün seçilebildiğinden her kalemde rekabet korunur; bir modülün başarısızlığı tüm sistemi rehin almaz; merkezi e-Belediye modülleriyle yan yana yaşamaya en uygun modeldir. Zayıf yanları: Entegrasyonun sahibi belediyedir; iki üreticinin birbirini işaret ettiği arıza günleri bu modelin bilinen riskidir. Modüler yaklaşım, ancak açık API ve standart veri formatları şartnameye yazılırsa çalışır — aksi hâlde "modüler" kâğıt üstünde kalır, pratikte birden çok küçük lock-in doğar.

Özel geliştirme: süreç kimin, yazılım onun

Güçlü yanları: Yazılım, belediyenin gerçek iş akışına göre kurulur; kaynak kodu ve veri tabanı sözleşmeyle belediyeye teslim edilebilir, bu da tedarikçi bağımlılığını yapısal olarak kırar; her entegrasyon ve rapor talebi "ek ücret kalemi" değil, geliştirme planının parçasıdır. Vatandaş portalı, saha denetimi, kent bilgi sistemi üstü analiz gibi belediyeyi farklılaştıran katmanlarda en güçlü modeldir. Zayıf yanları: İlk kurulum süresi pakete göre uzundur; ihtiyaç analizi zayıf yapılırsa kapsam büyür; belediyede sistemi sahiplenecek asgari bir teknik kapasite (veya danışmanlık desteği) gerektirir. Bizim de içinde bulunduğumuz model budur: belediyeye özel e-belediye geliştirme yaklaşımımızda kaynak kodu ve veri belediyede kalır — ancak dürüst olalım: standart mali süreçler için merkezi platform dururken bu modeli "her şeyi sıfırdan yazmak" için değil, belediyeye özgü katmanlar için öneriyoruz.

İçişleri e-Belediye platformu bu tabloyu nasıl değiştiriyor?

Merkezi sistemin resmî hedefleri arasında süreç sadeleştirme ve kamu kurumları arası gerçek zamanlı veri paylaşımı sayılır; Bakanlık, sistem devreye girdiğinde yılda en az 1 milyar 831 milyon TL tasarruf sağlanacağını duyurmuştur (İçişleri Bakanlığı). Bu rakam Bakanlığın kendi hedef beyanıdır; gerçekleşmeye ilişkin bağımsız bir ölçüm bu sayfada kaynak gösterilmemektedir. Pratikte bunun anlamı şudur: mali ve idari çekirdek modüllerde belediyelerin ticari paketlere bağımlılığı azalırken, ticari ve özel çözümlerin rekabet alanı merkezi sistemin kapsamadığı yerlere taşınıyor — vatandaş deneyimi, mobil uygulama, kent bilgi sistemi, saha/zabıta denetimi ve yapay zeka destekli analiz. 2026 itibarıyla teklif değerlendiren bir belediyenin ilk sorusu bu olmalı: "Bu modül merkezi sistemde zaten var mı?"

Pratikte kazanan çoğu zaman karma mimari

Üç modeli saf hâlleriyle karşılaştırmak analiz için gereklidir, ama sahada nadiren saf bir model uygulanır. 2026 koşullarında yaygınlaşan kurgu şudur: mali ve idari çekirdek merkezi e-Belediye Bilgi Sistemi modüllerinde, olgunlaşmış yan süreçler (ör. EBYS) hazır üründe, belediyeyi farklılaştıran katmanlar (vatandaş portalı, saha denetimi, CBS üstü analiz) ise özel geliştirmede yürür. Bu kurgunun avantajı, her kalemde riski o kaleme uygun modelle karşılamasıdır: standart süreçte tekerleği yeniden icat etmezsiniz, özgün süreçte ise ürünün şablonuna sıkışmazsınız. Bedeli ise entegrasyon disiplinidir — karma mimari, ancak sistemler arasında kimin hangi veriyi ürettiği ve hangi servisin sahibi olduğu net yazıldığında ayakta kalır. Bu yüzden karma modele geçen belediyelerde ilk yatırım çoğu zaman yeni bir modül değil, entegrasyon ve veri sözlüğü çalışmasıdır: hangi kaydın asıl kaynağı hangi sistemdir sorusuna tek cümlelik cevap veremiyorsanız, mimari henüz kurulmamış demektir.

İhale ve şartname açısından farklar

• Bütünleşik pakette şartname genellikle modül listesi ve referans şartı üzerinden yazılır; kritik madde veri devri, SLA cezai şartı ve sürüm güncelleme taahhüdüdür.
• Modüler alımda her ihale kaleminde açık API, standart veri formatı (ör. web servisleri, OGC standartları) ve entegrasyon sorumluluk matrisi tanımlanmalıdır; aksi hâlde uyuşmazlıkta hakem kalmaz.
• Özel geliştirmede şartname iş analizi çıktılarına, kabul testlerine, kaynak kodu ve dokümantasyon teslimine, fikri hak devrine ve bakım dönemine odaklanır; "analiz onayı olmadan geliştirme başlamaz" maddesi kapsam kaymasının sigortasıdır.
• Her üç modelde de 4734 sayılı Kanun pratiği, marka-model tarifi yerine işlevsel ve doğrulanabilir yetenek tanımını gerektirir; rekabeti daraltan tarif hem itiraz hem iptal riskidir.

Hangi durumda hangisi?

• Bilgi işlem kadrosu dar, süreçleri standart belde/ilçe belediyesi: Merkezi e-Belediye modülleri + gerekiyorsa dar kapsamlı hazır paket. Özel geliştirme yalnız vatandaş kanalı gibi tek noktaya.
• Orta ölçekli, entegrasyon ihtiyacı yüksek ilçe/il belediyesi: Modüler yaklaşım; merkezi sistem + seçilmiş ürünler + entegrasyon katmanı. Şartnamede açık API şartı pazarlık edilemez olmalı.
• Kendine özgü süreçleri olan, farklılaşmak isteyen belediye: Çekirdekte merkezi/hazır bileşenler, farklılaştıran katmanlarda (portal, saha, CBS üstü analiz, derin e-Devlet entegrasyonu) özel geliştirme.
• Mevcut paketinden çıkmak isteyen belediye: Önce veri devri müzakeresi, sonra model kararı. Devir güvence altına alınmadan yeni ihaleye çıkmak, eski bağımlılığı yenisiyle değiştirmektir.