Belediyelerde onay ve takip neden zorlaşır
Belediyelerde bir talep çoğu zaman tek bir müdürlüğün sınırları içinde kalmaz. Vatandaştan gelen bir başvuru, sahadan gelen bir tespit ya da kurum içi bir yazı; fen işlerinden mali hizmetlere, imardan zabıtaya kadar birden fazla birimin görüşünü, onayını ve aksiyonunu gerektirebilir. Bu trafik e-posta, telefon, kâğıt üst yazı ve birbirinden kopuk tablolar üzerinden yürüdüğünde, "bu iş şu an kimde, hangi aşamada ve ne zamana kadar tamamlanmalı" sorusunun yanıtı çoğu zaman belirsiz kalır.
Asıl sorun çalışanların gayreti değil, sürecin görünür olmamasıdır. Sahibi belli olmayan, son tarihi takip edilmeyen ve cevaplanıp cevaplanmadığı kayıt altına alınmayan işler birikir. Yönetim ise gecikmeyi çoğunlukla iş tıkandıktan ya da bir şikâyet geldikten sonra fark eder.
Talepten onaya: tek bir akış
Belediye onay ve takip sistemi, bir işin doğuşundan kapanışına kadar olan yolu tek bir akışta tanımlamayı amaçlar. Bir talep oluşturulduğunda hangi müdürlüğe düştüğü, kimin sorumlu olduğu, hangi onay basamaklarından geçeceği ve beklenen tamamlanma süresi baştan bellidir. Onay sıraya bağlanabilir: önce ilgili birim, ardından müdür, gerekiyorsa başkan yardımcısı. Her adımda kararı veren kişi, tarih ve gerekçe kayda geçer.
Bu yapı, sorumluluğun kişiden kişiye sözlü olarak devredildiği belirsiz alanı daraltır. Bir iş bir masada beklerken kimin aksiyon alması gerektiği nettir; devredildiğinde de iz kaybolmaz.
Gecikme, SLA ve eskalasyon
Her iş türü için hedef süreler tanımlanabilir. Örneğin bir bilgi talebine yanıt için belirlenen gün sayısı, bir saha müdahalesi için öngörülen tamamlanma süresi sisteme girilebilir. Süresi yaklaşan işler için sorumluya hatırlatma, süresi aşan işler için bir üst kademeye eskalasyon planlanabilir. Böylece gecikmeler, sorun büyümeden önce görünür hâle gelir.
Bu mekanizma kesin sonuç vaadi değildir; daha çok riskli işleri erkenden öne çıkaran bir karar destek katmanı olarak değerlendirilebilir. Nihai kararı ve önceliklendirmeyi yine ilgili yönetici verir.
Cevap takibi ve raporlama
Sistem, bir yazının yalnızca iletilip iletilmediğini değil; okunduğunu, onaylandığını ve cevaplandığını ayrı durumlar olarak izlemeye yardımcı olur. Bu sayede "ilgili birime gönderildi ama yanıt gelmedi" durumları belirginleşir. Birim bazında açık iş sayısı, ortalama kapanma süresi, SLA içinde tamamlanan iş oranı gibi göstergeler raporlanabilir. Bu raporlar performans göstermekten çok, darboğazların nerede oluştuğunu anlamaya ve kaynak planlamasına yardımcı olmak üzere kullanılabilir.
Notivex ile nasıl ele alınır
VexCore bu ihtiyacı, amiral ürünü Notivex çerçevesinde ele alır. Notivex; operasyonel kontrol ve kurumsal bildirim yetenekleriyle, talep ve onay akışlarını, sorumluluk dağılımını, SLA takibini ve okundu, onaylandı, cevaplandı izlemesini bir arada toplamayı amaçlar. Yapay zekâ tarafı; özetleme, önceliklendirme önerisi ve dikkat gerektiren işleri öne çıkarma gibi alanlarda insan onayı ve denetim izi ile çalışan bir destek katmanı olarak konumlanır.
Kurulum belediyenin altyapısına göre on-prem, bulut ya da hibrit olabilir. Kamu ve kurumsal tarafta önce sınırlı kapsamlı bir pilot veya PoC ile başlanması, sürecin sahada doğrulanması ve sonra kademeli yaygınlaştırma değerlendirilebilir.
Örnek senaryo
Bir mahalleden gelen "kaldırım çökmesi" bildirimi sisteme düşer ve fen işleri müdürlüğüne yönlendirilir. Saha ekibinin değerlendirmesi gerektiği için iş hem fen işlerine hem de gerekiyorsa zabıtaya bağlanır; bütçe etkisi olduğundan mali hizmetlerin görüşü onay basamağına eklenir. Her birim kendi adımını gördükçe işi sahiplenir, tamamlandığında bir sonraki onaya devreder. Belirlenen süre aşılmaya başladığında sorumlu müdür hatırlatma alır; gerekirse iş bir üst kademeye taşınır. Bildirim kapandığında okundu, onaylandı ve cevaplandı kayıtları, ileride gelebilecek bir bilgi talebine veya denetime karşı izlenebilir bir geçmiş oluşturur.