İç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.