İş akışı tasarımı: analiz, onay kuralları ve otomasyon

İş akışı nedir, onay süreci nerede devreye girer?

İş akışı, bir işin başlangıcından bitişine kadar hangi adımlardan, hangi rollerden ve hangi kurallardan geçtiğini tanımlayan düzendir. Bir satın alma talebi, izin başvurusu, sözleşme onayı ya da müşteri şikâyeti, bir iş akışı üzerinden ilerler. Akış çoğunlukla bir tetikleyiciyle başlar, belirli kişilerin görevlerinden geçer, karar noktalarında dallanır ve bir çıktıyla kapanır.

Onay süreci, iş akışının yetki ve kontrol ile ilgili bölümüdür. Bir işin devam etmesi için kimin, hangi koşulda, hangi bilgiye bakarak "evet" demesi gerektiğini belirler. Onay, iş akışını yavaşlatan değil, riski doğru yerde yöneten bir mekanizma olmalıdır. İyi tasarlanmamış onay zinciri ise iş kuyruklarını şişirir, imza toplama telaşına dönüşür ve sorumluluğu dağıtarak hiç kimseyi sorumlu bırakmaz.

İş akışı tasarımı, bu düzeni sezgiyle değil bilinçli bir plan ile kurmaktır. Mevcut durumu anlamayı, hedef akışı çizmeyi, kuralları ve istisnaları tanımlamayı, aracı seçmeyi ve süreci canlıya almayı kapsar. Akış tasarımı yalnızca BT ekibinin işi değildir; işin sahibi, süreci kullanan çalışan ve denetim tarafı sürecin içinde yer alır.

Mevcut durumu çıkarmak: süreç analizi ve modelleme

Yeni akışı çizmeden önce bugün işin gerçekte nasıl yürüdüğü anlaşılmalıdır. Kâğıt üzerindeki süreç ile gerçek süreç çoğunlukla farklıdır: e-posta üzerinden verilen sözlü onaylar, geçici çözümler ve resmî olmayan kısa yollar işin gerçek yüzünü gösterir.

Analiz için süreci yürüten insanlarla görüşme yapılır. Her adım için kim yapıyor, hangi bilgiyi alıyor, hangi sisteme bakıyor, nerede bekliyor ve neye göre karar veriyor soruları sorulur. Süreçte en çok zaman kaybettiren noktalar, tekrar eden iş ve hata geri dönüşleri not edilir. Gerçek örnek talepler incelenip sürecin başından sonuna izlenir; böylece istisna yollar da ortaya çıkar.

Bulgular görsel bir şemaya aktarılır. Şemada genellikle rol bazlı şeritler kullanılır: her şerit bir kişi ya da birim, oklar akışın yönü, eşkenar dörtgenler karar noktalarıdır. Süreç modelleme için yaygın bir gösterim dili olan BPMN kullanılabilir; ancak amaç gösterimin kurallarına uymaktan çok, ekibin ortak anladığı bir resim üretmektir. Şema karmaşıklaştığında alt süreçlere bölünür.

Mevcut akıştaki sorunlar şu başlıklarda toplanır: gereksiz adım, gereksiz onay, belirsiz sorumluluk, bilgi eksikliği nedeniyle geri dönüş, sistemler arası elle veri girişi.

Hedef akışı tasarlamak: ilkeler

Hedef akış tasarlanırken birkaç ilke yol gösterir.

• Her adımın bir sahibi olsun. Sahibi belirsiz adım, bekleme noktasıdır.
• Başlangıçta eksiksiz bilgi iste. Talep formundaki zorunlu alanlar, sonradan geri dönüşü azaltır.
• Normal yolu hızlı, istisnayı görünür yap. Rutin işleri tek bir basit yoldan geçirip, riskli durumlar için ayrı bir yol tanımlamak daha az bekleme üretir.
• Paralel yürüyebilen adımları ardışık bırakma. Birbirine bağımlı olmayan onaylar aynı anda istenebilir.
• Her karar noktası için ölçüt yazılı olsun. Kim, hangi koşulda, neye göre karar verir; belirsiz ölçüt tartışma üretir.
• Zaman sınırı koy. Bekleyen işin kime, ne zaman hatırlatılacağı ve süre aşımında nereye yükseltileceği tanımlansın.

Başka bir önemli ilke, süreci otomatize etmeden önce sadeleştirmektir. Kötü bir süreci otomatikleştirmek, kötülüğü hızlandırmaktır. Önce kaldırılabilecek adımlar, birleştirilebilecek onaylar ve gereksiz kontroller ayıklanır; sonra geriye kalan akış araca aktarılır.

Onay sürecini tasarlamak: kim, ne zaman, hangi yetkiyle?

Onay tasarımının kalbinde yetki matrisi vardır. Hangi türde ve hangi büyüklükte işin kimin onayına gideceği açıkça belirlenir. Örneğin bir harcama talebinde tutar eşiklerine göre onay seviyesi yükselir; hukuki etkisi olan bir sözleşmede ayrıca hukuk birimi devreye girer. Eşiklerin ve rollerin kaynağı tek bir yerde tutulur ve değiştiğinde akış otomatik güncellenir.

Onay türleri de ayrı düşünülür: sıralı onay (bir sonraki kişi öncekinden sonra görür), paralel onay (hepsi aynı anda bakar), herhangi birinin onayı yeterli olan akış ve oy çokluğu gerektiren akış. Seçim, riskin niteliğine bağlıdır. Her ek onay hem gecikme hem de sorumluluk dağıtma anlamına gelir; bu nedenle onay sayısı gerçekten risk gerektirdiği kadar olmalıdır.

Vekâlet ve izin dönemleri sıkça unutulur. Onaylayıcı izindeyken iş tıkanıyorsa, vekil atama kuralı ve süre aşımında üst role yönlendirme akışa yazılmalıdır. Reddedilen işin ne olacağı da tanımlanmalıdır: gerekçe yazılır mı, talep sahibine döner mi, düzeltilip yeniden gönderilebilir mi?

Her onay kaydı sonradan izlenebilmelidir: kim, ne zaman, hangi bilgiye bakarak onayladı. Bu kayıt hem denetim hem iyileştirme için temel veridir.

Otomasyon ve araç entegrasyonu

İş akışı araçları, tasarlanan süreci çalıştıran yazılımlardır. Bir form ile başlayan talep, yetki kurallarına göre doğru kişiye gider, hatırlatma üretir, kayıt tutar ve sonuçta başka bir sisteme bilgi aktarır. Araç seçiminde sorulacak sorular şunlardır: Akışı yazmak için kod bilgisi gerekiyor mu? Mevcut sistemlerle (insan kaynakları, muhasebe, belge yönetimi, e-posta) entegrasyon nasıl? Mobil onay mümkün mü? Raporlama ve denetim kaydı sağlanıyor mu?

Entegrasyon tarafında tipik kazanım, aynı bilginin birden fazla yere elle girilmesini ortadan kaldırmaktır. Çalışan bilgisi insan kaynakları sisteminden okunur, onay sonucu muhasebe kaydına yansır, belge arşive otomatik düşer. Her entegrasyon noktası aynı zamanda bir hata noktasıdır; bu yüzden hata durumunda ne olacağı baştan tasarlanır.

Otomasyonun sınırı da bellidir. Yargı gerektiren, istisnalı ya da hassas kararlar insan onayında kalır. Kural tabanlı ve tekrarlayan adımlar ise araca bırakılır. Basit ve sık kullanılan bir süreçle pilot başlatıp çıkan dersleri ardından karmaşık süreçlere taşımak, büyük bir sistemi baştan kurmaktan daha güvenlidir.

Güvenlik, uyum, performans izleme ve yayılım

Akış, kişisel veri ya da finansal bilgi taşıyorsa güvenlik ve uyum tasarımın parçasıdır. Hangi rolün hangi veriyi görebileceği yetkilendirme ile sınırlanır, hassas alanlar maskelenir, değişiklik ve onay geçmişi silinemez biçimde kaydedilir. Görevler ayrılığı ilkesi gereği bir kişinin hem talep edip hem onaylayamaması sağlanır. Kurumun düzenleyici yükümlülükleri varsa denetçi bakışı tasarıma erken aşamada dahil edilir.

Canlıya alınan akış izlenir. Anlamlı göstergeler arasında bir işin başlangıçtan bitişe toplam süresi, adımlarda bekleme süreleri, reddedilme ve geri dönüş oranı, süre aşımına uğrayan iş sayısı ve kullanıcı geri bildirimi sayılabilir. Darboğaz hangi adımdaysa ona odaklanılır. İyileştirme bir kez değil, düzenli aralıklarla yapılan bir döngüdür.

Yayılım için değişim yönetimi gerekir. Yeni akış çalışanın alışkanlığını değiştirir; bu yüzden kısa eğitim, rehber dokümanlar, geçiş döneminde destek hattı ve eski yolun kapatılacağı tarihin açıkça duyurulması gerekir. Anahtar kişilerle erken denemeler yapmak, itirazları üretim öncesinde görmeyi sağlar.

Sık yapılan hatalar arasında süreç analizi yapmadan araca geçmek, her işi aynı ağır onay yoluna sokmak, istisnaları tasarlamamak ve canlıya aldıktan sonra akışa sahip çıkmamak yer alır.

Nereden başlanır, Mindset programlarında nerede çalışılır?

Başlangıç için gündelik bir süreç seçin: izin talebi, küçük bir satın alma talebi ya da belge onayı gibi. Sürecin bugünkü yolunu iş sahibiyle birlikte çizin, bekleme noktalarını işaretleyin, ardından hedef akışı çıkarın. Küçük bir deneme akışı kurup sonuçlarını izlemek, daha büyük süreçler için gerekçe ve öğrenme sağlar.

Mindset programlarında bu konu İş Akışı Tasarımı ve Onay Süreçleri eğitiminde işlenir. Modüller iş akışı tasarımı temelleri, mevcut süreç analizi ve modelleme, onay süreci tasarımı, otomasyon ve araç entegrasyonu, güvenlik ve uyum yönetimi, performans izleme ve iyileştirme ile değişim yönetimi ve yayılım başlıklarından oluşur.