İçeriğe geç
Dijital Dönüşüm

Süreç ve Otomasyon Dönüşümü

Süreçleri önce ölçülebilir hale getirip sonra gereksiz adımları kaldırarak otomatikleştiren dönüşüm — otomasyonun kaosu hızlandırmaması buradaki sıraya bağlıdır.

Tanım
Süreç ve Otomasyon Dönüşümü
Süreçleri önce ölçülebilir hale getirip sonra gereksiz adımları kaldırarak otomatikleştiren dönüşüm — otomasyonun kaosu hızlandırmaması buradaki sıraya bağlıdır.

Türün künyesi

Ne değişir
Adım sayısı, el değiştirme noktaları, onay eşikleri
Kimin problemi
COO / Operasyon direktörü
Ön koşul
Sürecin yazılı olması ve çevrim süresinin ölçülebilmesi
İlk sonuca süre
3–8 hafta (süreç başına)

Bu türün ön koşulu olan dönüşümler

Sıra: ölç → ele → otomatikleştir

Otomasyon projelerinin en yaygın hatası bu üç adımın sırasını bozmaktır. Ölçmeden otomatikleştirmek, iyileşmeyi kanıtlanamaz kılar; elemeden otomatikleştirmek ise kötü bir süreci kalıcı hale getirir — çünkü otomatikleştirilen adım artık kodun içine gömülmüştür ve kaldırılması bir geliştirme projesi gerektirir.
Eleme turunun tek soruluk testi şudur: bu adım kaldırılırsa hangi somut zarar oluşur? Cevap "bilmiyorum, hep böyleydi" ise adım elenebilir. Cevap "onay kaydı tutmamız gerekiyor" ise adım kaldırılmaz ama otomatikleştirilebilir. Pratikte bir sürecin adımlarının %20–40'ı birinci gruba girer ve bu, otomasyondan önce elde edilen bedava hızdır.
Üçüncü adımda seçilecek teknoloji (RPA, iş akışı motoru, LLM-destekli pipeline) süreç tipine göre değişir: kural net ve girdi yapılandırılmışsa klasik otomasyon yeterlidir; girdi serbest metin veya karar yargı gerektiriyorsa LLM katmanı devreye girer — ve o noktada süreç artık yapay zeka dönüşümünün kapsamına geçer.

İstisna tasarımı: projenin gerçekten bittiği yer

Otomasyon projeleri genelde mutlu yol (happy path) için tasarlanır ve orada da başarılı olur. Sorun kalan yüzdede çıkar: akışa uymayan işlemler bir kuyruğa düşer, o kuyruğun sahibi tanımlı değildir ve birkaç ay içinde kuyruk operasyonun yeni darboğazına dönüşür. Otomasyon oranı %80'e çıkmıştır ama toplam çevrim süresi düzelmemiştir.
İstisna tasarımının üç asgari maddesi:
  1. Kuyruğun sahibi — istisnaya düşen işlemi kim, hangi hedef sürede kapatır?
  2. Geri besleme döngüsü — istisna nedenleri sınıflandırılıyor mu? En sık üç neden bir sonraki çeyreğin backlog'una girmelidir, aksi halde istisna oranı hiç düşmez.
  3. Eşik alarmı — istisna oranı belirlenen eşiği geçtiğinde kim uyarılır?
Bu üçü yazılmadan canlıya alınan otomasyon, ölçüm panosunda başarılı görünürken operasyonda görünmez bir borç biriktirir.

Ölçülecek KPI'lar

  • İşlem başına manuel dokunuş sayısı
  • Uçtan uca çevrim süresi (bekleme dahil)
  • İnsan müdahalesi gerektirmeyen işlem oranı

Somut çıktılar

  • Süreç haritası + darboğaz analizi
  • Otomasyon akışları
  • İstisna yönetimi tasarımı

Tipik başarısızlık modları

  • Ölçülmeyen süreci otomatikleştirmek — sonuç hızlandırılmış kaostur
  • Gereksiz adımı kaldırmak yerine otomatikleştirmek: kötü süreç, hızlı kötü sürece dönüşür
  • İstisnaların tasarlanmaması — akışın %80'i otomatik, %20'si kimsenin sahiplenmediği kuyruk olur

İlk 90 Gün

  1. Tek bir uçtan uca sürecin haritalanması ve çevrim süresi tabanının ölçülmesi
  2. Adım eleme turu: hangi adım kaldırılabilir, hangisi birleştirilebilir
  3. Kalan adımların otomasyonu ve istisna kuyruğunun sahibiyle birlikte tanımlanması

Sıkça Sorulan Sorular

RPA ile LLM-destekli otomasyon arasında nasıl seçim yapılır?▾

Girdi yapılandırılmış ve kural net ise klasik otomasyon (RPA / iş akışı motoru) daha ucuz, daha hızlı ve daha denetlenebilirdir. Girdi serbest metin, kararda yargı gerekiyor veya varyasyon çok yüksekse LLM katmanı gerekir — ama o noktada kabul kriteri bir eşiğe döner ve eval disiplini şart olur.

Süreç dönüşümüne hangi süreçten başlanmalı?▾

En çok şikâyet edilenden değil, **en çok ölçülebilenden**. Çevrim süresi ve hacim verisi olan bir süreç, iyileşmeyi kanıtlayabileceğiniz tek süreçtir; kanıtlanan ilk sonuç ikinci dalganın bütçesini üretir. Şikâyet yoğun ama ölçümsüz süreçler ikinci turda ele alınır.

Otomasyon iş gücü azaltımı olarak mı sunulmalı?▾

Kapasite kazancı olarak sunulması hem daha doğru hem daha savunulabilirdir: aynı ekiple işlenen ek hacim, kısalan çevrim süresi ve insanların istisna/yargı gerektiren işe kaydırılması. Tasarruf olarak sunulan projeler 'o kişiler işten çıkmadı ki' itirazına takılır ve ROI iddiası çürütülür.

Süreç madenciliği (process mining) gerekli mi?▾

Zorunlu değil ama ölçüm adımını çok hızlandırır: sistem loglarından gerçek akışı çıkarır ve 'süreç şöyle işliyor' varsayımıyla gerçeğin farkını gösterir. Log kalitesi düşük kurumlarda daha ucuz alternatif, 20–30 işlemin elle uçtan uca izlenmesidir; çoğu darboğaz bu örneklemde de görünür.

Diğer dönüşüm türleri

Doğru türü birlikte belirleyelim

Teşhis, en zayıf boyutun darboğazı ve önümüzdeki çeyrek için üç somut aksiyon — bir görüşmeyle başlayabiliriz.