Ünite 8 / 11

E-Devlet ve Süreç Otomasyonu: Başvurudan Sonuca

Kazanimlar:

  • Bir kamu başvuru sürecini adım adım dijitalleştirir ve insanın nerede karar noktasında tutulacağını belirler.
  • Dijital uçurumu ve erişim eşitsizliğini öngörerek her sürece bir alternatif kanal bırakır.
  • İstisna ve hata yönetimini tasarlar; model emin olamadığında reddetmek yerine insana yönlendirmeyi kural yapar.

Vatandaşın kamuyla temasının giderek büyüyen kısmı çevrimiçi gerçekleşir: e-Devlet Kapısı üzerinden belge alma, başvuru yapma, randevu, ödeme, durum sorgulama. E-devlet (kamu hizmetlerinin dijital kanallarla, tek noktadan ve çoğu zaman insan aracısı olmadan sunulması), hem vatandaşın işini kolaylaştırır hem de kurumun yükünü azaltır. Bu dijital hizmetlerin arkasında ise iş akışları ve giderek artan biçimde süreç otomasyonu (başvuru alma, yönlendirme, eksik belge kontrolü, bildirim gönderme gibi tekrarlayan adımların yazılımla otomatik yürütülmesi) vardır. İşte YZ, bu akışları tasarlamada, form ve bildirim metinlerini üretmede, gelen başvuruları ön-değerlendirmede ve süreçteki tıkanıklıkları bulmada güçlü bir araçtır. Ama bir uyarıyla: otomatik bir sürecin verdiği her hak-doğuran/kısıtlayan karar, hukuken bir insanın gözden geçirebileceği ve gerekçelendirebileceği bir noktaya bağlanmalıdır. Tam otomatik ret, itiraz ve insan denetimi olmadan meşru değildir.

Otomasyonda "insan neredetutulur?" sorusu

Süreç otomasyonunu tasarlarken en kritik karar, insanın hangi noktada devrede kalacağıdır. Üç yaygın model vardır:

  • Tam otomasyon (insan yok): Yalnızca hak doğurmayan, düşük riskli, kural-net işler için uygundur — örneğin bir belgenin sistemden otomatik üretilip verilmesi. Kurallar tamamen belliyse ve hata düşük maliyetliyse tercih edilebilir.
  • İnsan döngüde (human-in-the-loop): YZ/sistem bir öneri üretir, insan onaylar ya da düzeltir. Hak doğuran/kısıtlayan kararların standart modeli budur. Örneğin bir yardım başvurusunu sistem ön-değerlendirir, memur karar verir.
  • İnsan gözetiminde (human-on-the-loop): Sistem otomatik işler ama insan izler, örneklem denetler ve istisnaları alır. Yüksek hacimli, orta riskli işlerde kullanılır.

Anahtar ilke: karar vatandaşın hakkını ne kadar çok etkiliyorsa, insan o kadar merkezde olmalı. Bir randevu saatinin otomatik atanması ile bir işyeri kapatma kararının otomatik verilmesi aynı rejime tabi olamaz.

İpucu: Her otomatik adım için "bu adım yanlış çalışırsa vatandaş nasıl itiraz eder ve bir insan nasıl düzeltir?" sorusunun cevabını baştan tasarlayın. İtiraz yolu olmayan otomasyon, hem hukuken hem etik olarak sakattır.

Adım adım: bir dijital süreç tasarlamak

  1. Süreci haritalandır. Başvurudan sonuca tüm adımlar, kararlar ve aktörler.
  2. Riske göre sınıflandır. Her adım hak doğuruyor/kısıtlıyor mu? İnsan nerede şart?
  3. Otomatikleştirilecekleri seç. Kural-net, düşük riskli, tekrarlayan adımlar.
  4. Form ve bildirim metinlerini üret. Sade, erişilebilir, kişisel veri-minimal.
  5. İtiraz ve istisna yollarını kur. Her otomatik karara insan denetim noktası bağla.
  6. Kişisel veri akışını denetle. Hangi veri, nereye, ne kadar süre gidiyor? (KVKK)
  7. Pilot, izle, iyileştir. Hata oranı ve şikayetleri ölç; düzelt.

Üç mini vaka

Vaka 1 — Eksik belge otomasyonu. Bir kurumda başvuruların %38'i eksik belge yüzünden geri çevriliyor, vatandaş tekrar geliyordu. Başvuru anında YZ destekli bir eksik-belge kontrolü eklenince, vatandaş daha formu göndermeden eksiğini gördü; ikinci başvuru oranı %38'den %11'e düştü, gişe yükü azaldı.

Vaka 2 — Tam otomatik retten dönüş. Bir sosyal yardım pilotu, gelir eşiğini otomatik hesaplayıp eşik üstündekileri otomatik reddediyordu. Ama bazı özel durumlar (engelli bakım yükü, geçici gelir) kurala girmiyordu ve haksız retler oldu. Süreç "insan döngüde" modele çevrildi: sistem ön-değerlendirir, memur istisnaları görüp karar verir. Haksız ret şikayetleri kayboldu.

Vaka 3 — Tıkanıklık tespiti. 6 aylık süreç loglarını YZ ile analiz eden bir birim, başvuruların ortalama 9 gününün tek bir onay adımında beklediğini gördü; o adımda tek yetkili vardı. Yetki ikinci bir kişiye de verilince ortalama süre 14 günden 6 güne indi.

Dört kopyalanabilir şablon

1) Süreç haritası ve risk sınıflandırma:

Rolün: kamu süreç tasarımcısı. Aşağıdaki hizmetin başvurudansonuca tüm adımlarını çıkar. Her adım için belirt: (1) neyapılıyor, (2) hak doğuruyor/kısıtlıyor mu, (3) otomatikleşirmi yoksa insan kararı mı gerekir, (4) buradaki ana risk.Emin olmadığın hukuki noktayı "teyit edilmeli" diye işaretle.HİZMET: [tarif et]

2) Sade bildirim/form metni:

Aşağıdaki durum için vatandaşa gidecek bir bildirim metniyaz: sade, saygılı, adım adım. Ne yapması gerektiğini,süresini [teyit edilecek] ve itiraz yolunu açıkça belirt.Gereksiz kişisel veri isteme. Jargon kullanma.DURUM: [ör. eksik belge / başvuru sonucu]

3) İtiraz ve istisna yolu tasarımı:

Aşağıdaki otomatik karar adımı için bir insan denetim veitiraz mekanizması tasarla: (1) vatandaş nasıl itiraz eder,(2) hangi durumlar otomatikten çıkıp insana gitmeli(istisnalar), (3) insan karar verirken neye bakmalı,(4) süre ve kayıt. Tam otomatik retten kaçın.ADIM: [otomatik karar]

4) Süreç tıkanıklığı analizi:

Aşağıdaki süreç loglarını (adım - süre) incele. Sadeceverilen veriyle: (1) en uzun bekleyen adımı, (2) olasıdarboğaz nedenini (tek yetkili, elle işlem vb.), (3) 2-3iyileştirme önerisini ver. Dışarıdan sayı ekleme.LOG: [adım ve süre verisi]

Zayıf prompt / Güçlü prompt

Zayıf: "Bu başvuru sürecini otomatikleştir."

Güçlü: "Rolün kamu süreç tasarımcısı. Önce başvurudan sonuca tüm adımları çıkar ve her adımı 'hak doğurur/doğurmaz', 'otomatikleşir/insan gerekir', 'ana risk' diye sınıflandır. Yalnızca kural-net ve düşük riskli adımları otomatiğe öner; hak-kısıtlayan her adım için insan onayı ve itiraz yolu tasarla, tam otomatik ret önerme. Kişisel veri akışını (hangi veri nereye) işaretle. Belirsiz hukuki noktaları 'teyit edilmeli' diye ayır."

Fark: güçlü prompt otomasyonu riske göre ayırır, insan denetimini ve itirazı zorunlu kılar, veri akışını ve hukuki belirsizliği görünür yapar.

Otomasyon modeli seçimi

İş türü

Uygun model

Neden

Belge üretimi (kural-net)

Tam otomasyon

Düşük risk, hak doğurmaz

Yardım/teşvik değerlendirme

İnsan döngüde

Hak doğurur, istisna var

Yüksek hacimli sınıflandırma

İnsan gözetiminde

Örneklem denetimi yeterli

Ceza/kısıtlama kararı

İnsan merkezde

Ağır hak kısıtı, gerekçe şart

Erişim eşitliği ve istisna yönetimi

Bir kamu sürecini dijitalleştirmek ve otomatikleştirmek, verimliliği artırırken yeni bir eşitsizlik riski doğurur: dijital uçurum (bilgisayar, internet erişimi ya da dijital okuryazarlığı olmayan vatandaşların hizmete erişememesi). Yaşlı, engelli, kırsalda yaşayan ya da düşük gelirli vatandaşlar tümüyle çevrimiçi bir süreçte dışarıda kalabilir. İyi tasarlanmış bir dijital süreç, her zaman bir alternatif kanal (yüz yüze başvuru, telefonla destek, vekâletle işlem) bırakır; otomasyon vatandaşı kanala mahkûm etmez, ona seçenek sunar. Aynı biçimde, iyi bir otomasyon "her şey yolunda giderse" senaryosuna değil, istisna yönetimine (eksik belge, sistem hatası, kural dışı durum ortaya çıktığında ne olacağı) göre tasarlanır; çünkü kamuda asıl mağduriyet, tam da kuralın dışına düşen vatandaşta yaşanır.

Mini vaka — otomasyonun dışladıkları. Bir sosyal yardım başvurusu tümüyle çevrimiçine taşınınca başvuru sayısı ilk ay yüzde 30 düştü — talep azaldığı için değil, en muhtaç grup olan yaşlı ve internetsiz vatandaşlar başvuramadığı için. Kurum, muhtarlıklarda destekli başvuru noktası açınca sayı toparlandı; verimlilik, erişim eşitliğiyle dengelendi.

Mini vaka — istisnada tıkanan süreç. Otomatik bir ruhsat sürecinde belge YZ ile ön kontrolden geçiriliyordu; ama sistem, nadir bir belge türünü "geçersiz" sayıp başvuruları sessizce reddediyordu. Haftada yaklaşık 15 haklı başvuru bu kör noktaya düştü. Çözüm: model emin olamadığında reddetmek yerine memura yönlendirmek.

Süreç tasarımını denetleyen sablon:

Görev: Aşağıdaki dijital süreç için bir RİSK ve ERİŞİM kontrol listesi üret.Süreç: [adım adım akış]Sorular: 1) İnterneti/cihazı olmayan vatandaş nasıl başvurur? 2) Engelli erişimi sağlanıyor mu? 3) Sistem hata verirse başvuru ne olur? 4) Kural dışı/istisna durumda kim karar verir? 5) Otomatik ret veriliyorsa itiraz yolu ve insan denetimi var mı?Çıktı: Her soru için risk düzeyi + öneri. Uydurma çözüm ekleme.

İpucu: Bir otomasyonu "kaç işlemi hızlandırdı" ile değil, "kimi dışarıda bıraktı" sorusuyla da değerlendirin. Kamu hizmetinde başarı, hızlanan çoğunluk kadar dışarıda kalmayan azınlıkla ölçülür.

Sık yapılan hatalar

  • Hak-kısıtlayan kararı tam otomatiğe bağlamak. İtiraz ve insan denetimi olmadan meşru değildir.
  • İstisnaları kurala sığdırmaya çalışmak. Gerçek hayat kuralın dışına taşar; istisna için insan kapısı bırakın.
  • İtiraz yolunu sonradan düşünmek. Her otomatik karara baştan bir itiraz ve düzeltme yolu tasarlayın.
  • Kişisel veri akışını denetlememek. Otomasyon veriyi çoğaltır; nereye gittiğini ve saklama süresini kontrol edin.
  • Bildirimi jargonla yazmak. Vatandaş anlamazsa süreç dijital ama erişilemez olur.
  • Pilotsuz yaygınlaştırmak. Önce küçük ölçekte hata oranını ölçün, sonra genişletin.

Özetle

E-devlet ve süreç otomasyonu, kamu hizmetini hızlandırır ve yükü azaltır; YZ bu süreçleri haritalamada, metin üretmede, ön-değerlendirmede ve darboğaz bulmada güçlüdür. Ama tasarımın kalbi tek bir sorudur: insan nerede? Karar vatandaşın hakkını ne kadar etkiliyorsa insan o kadar merkezde olmalı; her otomatik karar bir itiraz ve insan denetim noktasına bağlanmalı, kişisel veri akışı KVKK'ya göre denetlenmelidir.

Uygulama görevi

Biriminizin bir çevrimiçi hizmetini seçin. "Süreç haritası ve risk sınıflandırma" şablonuyla adımları çıkarıp her birini risk ve otomatikleşebilirlik açısından işaretleyin. Hak doğuran bir adım için "İtiraz ve istisna yolu tasarımı" şablonuyla bir insan denetim mekanizması tasarlayın. Bir bildirim metnini "Sade bildirim/form metni" şablonuyla üretip erişilebilirliğini kontrol edin.

Kontrol listesi

  • [ ] Her adımı risk ve otomatikleşebilirlik açısından sınıflandırdım.
  • [ ] Hak-kısıtlayan hiçbir kararı tam otomatiğe bırakmadım.
  • [ ] Her otomatik karara insan denetimi ve itiraz yolu bağladım.
  • [ ] İstisnalar için insan kapısı tasarladım.
  • [ ] Kişisel veri akışını ve saklama süresini denetledim (KVKK).
  • [ ] Bildirimleri sade ve erişilebilir yazdım; pilotla test ettim.