Talep onayda bekliyor ama kimde? Onay akışını koda gömmek mi, iş akışı motoru mu?

Onay akışı üç seviyede kurulabilir. Birincisi koşulları doğrudan koda gömmek, ikincisi akışı açık bir durum makinesi olarak modelleyip onay kurallarını veritabanında tutmak, üçüncüsü bir iş akışı motoru (BPMN motoru ya da dayanıklı yürütme platformu) kullanmak. Kurumsal uygulamaların çoğu için doğru yer ortadaki seviyedir. Motor, akışı iş biriminin kendisi değiştirecekse, süreç günler boyunca açık kalıyorsa ve paralel dallar, zamanlayıcılar, telafi adımları işin merkezindeyse kazanır. Ama projeleri çıkmaza sokan şey genelde seviye seçimi değil: kaydın hangi adımda olduğu veriye yazılmamıştır, talebin kimde beklediğini gösteren bir ekran yoktur ve onayın hangi kurala göre verildiği altı ay sonra açıklanamaz.

Önce üç soruyu ölçün

Teknoloji tartışmasına girmeden önce kendi sürecinizi sayıya dökün.

Akış ne sıklıkla ve kimin eliyle değişiyor? Mali işler onay eşiğini 50 bin TL'den 100 bin TL'ye çektiğinde bu sizde bir sürüm çıkışı mı demek? Son on iki ayda akış kaç kez değişti, bu değişiklikleri kim istedi? Yılda bir iki kez ve her seferinde yazılım ekibiyle konuşularak oluyorsa koda gömülü akış yeterlidir. Ayda bir değişiyorsa ve değiştiren kişi yazılımcı değilse, kuralı koddan çıkarmanız gerekir.

Bir talep ne kadar yaşıyor? Saatler içinde kapanan bir onay ile imza, bütçe ve tedarikçi yanıtı bekleyip üç hafta açık duran bir onay aynı mimariyi istemez.

Akış sıralı mı, dallanıyor mu? Tek bir zincir (amir, sonra mali işler) ile "üç müdürden ikisi onaylarsa geçer" arasında ciddi fark var. Bu üç cevabı şartnamede netleştirmeden kod yazmaya başlamak, sonradan sökülmesi en pahalı kısmı en erken sabitlemek demektir.

Durumu bir kolona yazın, koşullardan türetmeyin

En sık gördüğümüz hata, onay durumunu birkaç boole alanından hesaplamak: amir_onayladi, maliisler_onayladi, iptal_edildi, revizyonda. Dört alan on altı kombinasyon üretir ve bunların çoğu gerçekte var olamayacak durumlardır. "İptal edilmiş ama mali işler onaylamış" satırını üretimde bir kez gördüğünüzde, hangi kodun o satırı yazdığını bulmak günler alır.

Doğrusu tek bir durum alanı ve izin verilen geçişlerin listesidir: taslak, onay_bekliyor, revizyon_istendi, onaylandi, reddedildi, geri_cekildi. Yanına üç alan daha koyun: şu an kimde beklediği (rol ya da kişi), beklemenin başladığı an ve son tarih. Bu üç alan olmadan "kimde kaldı" sorusunu ancak kayıtları tarayarak cevaplayabilirsiniz. Geçişleri de veri modelinin parçası yapın; kaydın hangi durumdan hangisine geçebileceği tek bir yerde tanımlı olsun (veri modeli tasarımında sık yapılan hatalar).

Onay matrisini koddan çıkarın

İkinci seviyenin özü şu: kim onaylayacak sorusunun cevabı kod değil, veridir. Tablonun satırları koşul ve sonuçtan oluşur. Koşul tarafında tutar aralığı, masraf merkezi, kategori, talep eden birim bulunur. Sonuç tarafında gereken onaycılar (kişi değil rol olarak), sıralı mı paralel mi ilerleyeceği ve paralelse kaç onayın yeterli olduğu yazar.

Bu yapının adı karar tablosudur ve standardı da vardır: OMG'nin DMN spesifikasyonu, en son Eylül 2026'da 1.6 sürümüyle resmileşti. DMN motoru kurmak zorunda değilsiniz, ama spesifikasyonun bir fikrini ödünç alın: eşleşme politikası. Birden fazla satır aynı talebe uyduğunda ne olacağını baştan yazın. İlk eşleşen mi geçerli, yoksa eşleşen bütün satırların onaycıları birleştirilecek mi? Bu kuralı yazmayan ekipler, 120 bin TL'lik bir talebin neden dört ayrı kişiye düştüğünü sonradan açıklayamıyor.

Bir de sürüm meselesi var. Çalışan bir talep, başladığı andaki kural setine bağlı kalmalı. Matris değiştiğinde yolda olan talepler yeni kurala geçerse, "bu talep neden iki onayla kapandı" sorusunun cevabı kaybolur. Pratik çözüm basit: matrisin sürüm numarasını talebin üzerine yazın ve değerlendirmeyi o sürümle yapın.

Akışı tıkayan beş gerçek durum

Onay sistemleri demoda değil, ikinci ayda tıkanır. Tıkayan şeyler hep aynıdır.

• Onaycı izinde. Vekalet mekanizması gerekir: başlangıç ve bitiş tarihi olan, kimin kime vekalet verdiğini kaydeden bir tanım. Kayıt "X onayladı" değil, "Y adına X onayladı" biçiminde tutulmalı.
• Onaycı işten ayrıldı. Yönlendirme kişiye değil role yapılırsa bu sorun kendiliğinden çözülür (yetkilendirme modeli). Yine de sahipsiz kalan görevleri toplu biçimde devretmeye yarayan bir yönetici ekranı tutun.
• Kendi talebini onaylama. Rolü taşıyor olmak yetmez; talebi açan kişi o talebi onaylayamamalı. Görevler ayrılığı ilkesinin yazılımdaki karşılığı tam olarak budur ve kuralı uygulamanın içine koymazsanız, yetki matrisi doğru olsa bile ihlal edilir.
• Tutar sonradan değişti. Talep eden, iki onay aldıktan sonra kalemi 90 binden 140 bine çıkarırsa alınan onaylar artık o talebi kapsamaz. Kuralı baştan koyun: tutarı ya da kapsamı değiştiren revizyon, yeni eşiğin gerektirdiği onayları sıfırlar.
• Kimse bakmıyor. Her adımın bir süre bütçesi olsun. Hatırlatma ve yükseltme işleri zamanlayıcıyla çalışan arka plan işleridir (kuyruk ve arka plan işleri), bildirimler de insanların gerçekten baktığı kanala düşmelidir (bildirim sistemi tasarımı). Onay ekranına ayda bir giren bir müdür, e-posta gelmiyorsa süreci haftalarca bekletir.

"Reddet" tek bir şey değildir

Üç ayrı eylemi tek düğmeye bindirmek, kullanıcıların sistemi terk etmesinin en hızlı yoludur. Reddetme talebi kapatır. Revizyon isteme talebi sahibine geri gönderir ve düzeltilip tekrar akışa girmesini bekler. Geri çekme ise talep sahibinin kendi işlemidir.

Her birinin dönüş noktasını yazılı olarak tanımlayın: revizyondan sonra talep en başa mı döner, yoksa revizyonu isteyen adıma mı? Pratikte en sağlıklısı, değişen alanlara bakıp kararı buna göre vermektir. Açıklama alanı serbest metin değil zorunlu olsun, çünkü "reddedildi" yazan ama nedenini söylemeyen bir kayıt, bir hafta sonra aynı talebin tekrar açılmasına yol açar.

Denetim izi, "kimde kaldı" ekranı ve istisnalar

Her geçiş için ayrı bir satır yazın: kim, ne zaman, hangi eylem, hangi açıklama, hangi kural sürümü, varsa kimin adına. Bu kayıt eklemeli olmalı, yani güncellenmemeli (denetim izi tasarımı). Karar anındaki tutarı da kaydedin; talep sonradan değiştiğinde onayın neyi kapsadığı ancak böyle görülür.

Burada dikkat edilecek bir incelik var. Denetim izi, akışın işlediğini kanıtlar, kontrolün çalıştığını değil. Herkes sırayla tıklamış olabilir ve kimse bakmamış olabilir. Bunu kapatmanın yolu, istisnai onaylarda gerekçeyi zorunlu tutmak ve eşik üstü onayların ayrı bir raporda listelenmesidir.

Bir de tek bir ekran var ki yatırımını en hızlı geri ödüyor: bekleyen talepleri onaycıya göre gruplayan ve her birinin kaç gündür beklediğini gösteren liste. Satın alma müdürü "bizden kaynaklı gecikme yok" dediğinde tartışmayı bitiren ekran budur.

İş akışı motoru ne zaman gerçekten kazanır?

Motor tartışmasına şu beş ölçütle girin. Süreç günler ya da haftalar boyunca açık kalıyor ve sunucu yeniden başlatmalarını, sürüm çıkışlarını aşmak zorunda. Paralel dallar ve birleşme noktaları var. Zamanlayıcı, hatırlatma ve yükseltme akışın merkezinde. Yarıda kalan süreçte önceki adımları geri alan telafi işlemleri gerekiyor. Ve iş birimi akışı diyagram üzerinde kendisi değiştirmek istiyor. Üçü birden doğruysa motor mantıklıdır, biri doğruysa kendi durum makineniz daha ucuzdur.

İki ayrı dünya var. BPMN motorları (Camunda, Flowable gibi) süreci diyagram olarak modellemenizi sağlar. Notasyonun standardı OMG'nin BPMN spesifikasyonu ve resmî sürüm hâlâ Ocak 2014'te yayımlanan 2.0.2; yani notasyon on yılı aşkın süredir yerinde duruyor. Dayanıklı yürütme platformları (Temporal, AWS Step Functions gibi) ise süreci diyagramla değil kodla yazdırır, buna karşılık her adımın durumunu kalıcılaştırır ve süreç kaldığı yerden devam eder. İş birimi diyagramı kendisi yönetecekse birincisi, akış geliştiricinin elinde kalacaksa ikincisi daha az sürtünme yaratır.

Motor da bir bağımlılıktır

"BPMN uyumlu" ifadesi taşınabilirlik garantisi vermez. Camunda'nın kendi dokümanı, Camunda 7 için modellenen bir diyagramın Camunda 8'de çalışmadığını ve tersinin de geçerli olduğunu açıkça yazıyor. Camunda 7 Community Edition'ın son özellik sürümü 14 Ekim 2025'te çıkan 7.24 oldu; sonrasında güvenlik yamaları dahil yeni sürüm gelmeyeceği duyuruldu ve depo arşivlendi. Kurumsal sürümün destek sonu ise Nisan 2027'den 9 Nisan 2030'a uzatıldı, ücretli ek destek 2032'ye kadar sürüyor. Yani motor seçimi, beş yıl sonra geri dönüp sizi bulacak bir karar (desteği biten yazılım riski).

Platform sınırları da somut. AWS Step Functions'ın standart iş akışlarında bir yürütme en fazla bir yıl sürebilir, geçmişi 25.000 olayla sınırlıdır, kapandıktan 90 gün sonra geçmiş kaybolur ve adımlar arasında taşınan veri 256 KiB'ı aşamaz. Temporal'da bir iş akışının olay geçmişi 51.200 olay ya da 50 MB sınırına dayanır, 10.240 olay ve 10 MB eşiklerinde uyarı verir. Yüz kalemlik bir siparişin her kalemi için döngü kuran bir onay akışı bu sayılara sandığınızdan çabuk yaklaşır.

İki pratik sonuç çıkıyor. Birincisi, iş verisi sizin veritabanınızda kalsın; motor süreci yürütsün ama kaydın gerçeği motorun içinde durmasın. İkincisi, motoru kendi arayüzünüzün arkasına alın, uygulama kodunuz motorun sınıflarını doğrudan çağırmasın. Bu iki kural, beş yıl sonraki geçişi yeniden yazım olmaktan çıkarıp taşıma işine dönüştürür.

ERP'de zaten onay varsa ikinci bir onay kurmayın

Satın alma onayı ERP'nizde çalışıyorsa, yeni uygulamada paralel bir onay zinciri kurmak iki kaydın birbirini tutmadığı klasik tabloyu üretir. Önce hangi sistemin kaydın sahibi olduğuna karar verin, sonra diğer tarafa yalnızca durumu yansıtın. Durum güncellemelerini tekrar gönderime dayanıklı yazın, aynı mesajın iki kez gelmesi onayı iki kez işlememeli (ERP ve veri senkronizasyonu).

ERP'nin ya da bir low-code aracının hazır iş akışı modülü de bir seçenek, hele süreç tek ve standartsa. Sınırı, akış kendi ürününüzün farklılaştırıcı parçası haline geldiğinde görürsünüz (low-code ne zaman yetmez). Her müşteriye ayrı bir onay akışı sözü veriyorsanız, bunu kod çatallayarak değil kural verisiyle yapmanız gerektiğini de baştan bilin (müşteriye özel geliştirme mi, konfigürasyon mu).

Bu hafta yapılabilecek üç şey

Son 50 onay talebini dışa aktarın ve her adımda kaç saat beklediğini ölçün. Kaç tanesi sistem dışına taştı, yani telefonla ya da mesajla halledilip sisteme sonradan işlendi? Bu oran, mimari tartışmasından daha çok şey söyler.

Durum alanını ve izin verilen geçişleri tek sayfaya çizin. Üretimdeki kayıtlarda bu listede olmayan bir durum kombinasyonu var mı, sorgulayın.

Onay matrisini koddan çıkarıp tabloya taşıyın, sürüm numarası ekleyin ve eşleşme politikasını yazın. Bu üç adım motor kararını ertelemenizi sağlar, çünkü motora geçmeye karar verseniz de ilk isteyeceği şey tam olarak budur.

Onay süreçleriniz kullanıcıları sistem dışına itiyorsa ya da mevcut akışı değiştirmek her seferinde yeni bir geliştirme talebine dönüşüyorsa, mevcut yapıyı birlikte gözden geçirip hangi seviyede durmanız gerektiğini çıkaralım.