ONAY SÜREÇLERİ TASARIMI: YETKİ, KAYIT VE İZLENEBİLİRLİK

Onay süreçleri, sadece “kim onaylıyor?” sorusuna yanıt veren bir akış değildir; aynı zamanda kurumun risk iştahını, uyum gereksinimlerini ve operasyonel hızını aynı anda yönetme biçimidir. İyi tasarlanmış bir onay mekanizması, kararın doğru kişiye gitmesini sağlarken, kararın nasıl alındığını kanıtlayacak izleri de düzenli biçimde üretir.

Birçok ekip onay akışını hızlandırmak adına tek adım ve tek onaylayıcıyla başlar; süreç büyüdükçe delegasyon, alternatif onay, istisna yönetimi ve denetim talepleri birikerek kaosa dönüşebilir. Bu noktada “onay süreçleri tasarımı” yaklaşımını; yetki (kimin hangi koşulda karar verdiği), kayıt (hangi veriyle kanıtlandığı) ve izlenebilirlik (uçtan uca takip edilebilirlik) eksenlerinde ele almak gerekir.

Bu makalede; rol tabanlı erişimden denetim izine, SLA’lardan versiyonlamaya kadar, kurumsal yazılım ekiplerinin sahada ihtiyaç duyduğu pratikleri ve Power Automate gibi araçlarla uyumlu tasarım kalıplarını derli toplu bir çerçevede bulacaksınız. Uygulamada hız kazanmak için Power Automate eğitimi içeriğini de inceleyebilirsiniz.

Primary yaklaşım: Onay süreçleri tasarımı neden stratejik bir konudur?

Onay süreçleri, finansal risk, bilgi güvenliği, veri gizliliği, satın alma politikaları ve operasyon sürekliliği gibi kritik alanlara doğrudan temas eder. Bu yüzden “workflow yazdık bitti” yaklaşımı, özellikle regülasyon ve iç denetim baskısı olan kurumlarda kısa sürede yetersiz kalır.

Stratejik bakış, onayı bir UI ekranı veya tek bir otomasyon adımı değil; kurumun karar alma kontrol noktası olarak ele alır. Bu kontrol noktasının tasarımı; yetki matrisi, denetim izi ve kayıt yönetimi ilkeleriyle birlikte düşünülmelidir.

Onay akışının hedefleri: hız, kontrol, kanıt

• Hız: Gereksiz adımları azaltmak, doğru kişiye doğru anda gitmek
• Kontrol: Yetki devri, limitler, istisnalar ve görev ayrılığı (SoD) ilkeleri
• Kanıt: Denetimde “kim, ne zaman, neye dayanarak” sorularına yanıt üretebilmek

En yaygın tasarım hataları

Çok sık görülen hatalar; onaycıyı kullanıcıya seçtirmek, kararın gerekçesini zorunlu tutmamak, değişiklik taleplerini aynı akışa yığmak ve kayıtları dağınık sistemlerde tutmaktır. Sonuçta süreç ya yavaşlar ya da hızlı görünür ama denetlenemez hale gelir.

Yetki matrisi ve rol tabanlı erişim: Kime, hangi koşulda onay hakkı?

Yetki matrisi, onay akışının omurgasıdır. Rol tabanlı erişim (RBAC) ile birlikte ele alındığında; “onaylayıcılar listesi” bir Excel tablosu olmaktan çıkar, kurumsal yönetişimin bir parçasına dönüşür. Özellikle satın alma, harcama, izin, erişim talebi gibi süreçlerde limit ve koşul bazlı onay kurgusu kaçınılmazdır.

Yetki matrisi tasarlarken temel alanlar

Tipik bir matriste; talep türü, tutar/limit, birim, lokasyon, risk seviyesi, veri sınıflandırması ve talep sahibinin seviyesi gibi alanlar bulunur. Onaylayıcı seçimi bu parametrelerle deterministik olmalıdır; böylece kişiye bağlılık azalır ve standartlaşma artar.

Görev ayrılığı ve çıkar çatışması kontrolleri

Görev ayrılığı (Segregation of Duties) için “talebi açan ile onaylayan aynı kişi olamaz” gibi kontroller, sistematik kural olarak tanımlanmalıdır. Ayrıca yönetici onayı istenen durumlarda, talep sahibinin yönetici hiyerarşisinin güvenilir kaynaktan çekildiği doğrulanmalıdır.

Kayıt yönetimi: Hangi veriler saklanmalı, nasıl kanıtlanmalı?

Kayıt yönetimi, denetim izinin veri katmanıdır. Onay mesajlarının ekran görüntüsü veya e-posta arşivi tek başına yeterli değildir; çünkü ilişkilendirilebilir, sorgulanabilir ve bütünlüğü korunmuş kayıtlara ihtiyaç vardır. En iyi pratik; onay sürecinin her adımının bir “olay” (event) olarak kayda geçmesidir.

Denetim izi için minimum kayıt seti

1. Talep kimliği, talep tipi, talep sahibi ve talep zamanı
2. Karar noktaları: adım adı, atanan onaylayıcı, delegasyon bilgisi
3. Karar: onay/ret/geri gönder, gerekçe, ekler, zaman damgası
4. SLA bilgileri: hedef süre, geçen süre, gecikme nedeni
5. Teknik iz: akış çalıştırma kimliği, hata kodu, yeniden deneme sayısı

Kayıt bütünlüğü ve değişmezlik (immutability) yaklaşımı

Denetim loglarının sonradan değiştirilebilmesi, kanıt değerini zayıflatır. Bu nedenle log kayıtları için ayrı bir veri deposu, erişim kısıtları ve mümkünse ek bir bütünlük kontrolü (hash, imzalama veya WORM yaklaşımı) düşünülmelidir. Tam WORM gerekmese bile; yazma yetkisi sınırlı, silme yetkisi yok denecek kadar dar bir model hedeflenmelidir.

İzlenebilirlik: Uçtan uca takip, görünürlük ve raporlama

İzlenebilirlik, hem operasyon ekibinin hem de karar vericilerin “süreç nerede tıkandı?” sorusuna hızlı yanıt almasını sağlar. Bu sadece log tutmak değildir; doğru korelasyon anahtarları, raporlanabilir metrikler ve olay akışının bütün bir hikâye olarak izlenebilmesidir.

Korelasyon anahtarı ve süreç kimliği

Talep ID’si her sistemde aynı kalmalı veya bir “global request id” ile tüm alt sistemlere taşınmalıdır. En iyi senaryo; talep ID + süreç versiyonu + akış çalıştırma ID kombinasyonunun tüm kayıtlarda bulunmasıdır. Böylece hata ayıklama, denetim sorgusu ve metrik analizi kolaylaşır.

Raporlanabilir metrikler: SLA, bekleme, tekrar işleme

Onay süreçlerinde en değerli metrikler; ortalama onay süresi, adım bazında bekleme süresi, gecikme oranı, yeniden işleme sayısı (rework) ve ret gerekçelerinin sınıflandırılmasıdır. Bu metrikler; süreç iyileştirme toplantılarının “hissi” değil, veriye dayalı yapılmasını sağlar.

SLA ve istisna yönetimi: Süreci bozmadan esneklik sağlamak

SLA kurgusu, onay akışının süre hedeflerini ve eskalasyon davranışını tanımlar. İstisna yönetimi ise bu davranışın kurallı biçimde esnetilmesidir. Buradaki amaç; süreçlerin sahada yürüyebilmesini sağlarken kontrolü kaybetmemektir.

Eskalasyon ve alternatif onaylayıcı senaryoları

Yaygın bir desen; belirli süre içinde yanıt gelmezse bir üst role eskale etmek, izin/seyahat durumunda delegasyon uygulamak ve kritik taleplerde paralel onay (iki ayrı rolün onayı) istemektir. Bu kurgular; “acil” etiketiyle her şeyi bypass eden yaklaşımlara göre çok daha denetlenebilirdir.

İstisna kayıtları ve gerekçe zorunluluğu

İstisna; bir kuralın bilinçli olarak esnetilmesidir ve mutlaka gerekçeyle kayıt altına alınmalıdır. Örneğin limit aşılıyorsa, “neden” alanı zorunlu olmalı ve istisna tipi standartlaştırılmış bir listeden seçilmelidir. Böylece istisnalar yönetilebilir bir risk havuzuna dönüşür.

Versiyonlama ve değişiklik yönetimi: Akış değiştiğinde kanıt zinciri kopmasın

Onay akışları yaşayan varlıklardır; organizasyon şeması değişir, limitler güncellenir, yeni kontrol adımları eklenir. Sorun; değişiklik yapıldığında geçmişteki kararların “hangi kuralla alındığı” bilgisinin kaybolmasıdır. Bu yüzden süreç versiyonlama yaklaşımı şarttır.

Süreç versiyonu ve kural seti sürümü

Her talep kaydına; süreç versiyonu ve kural seti sürümü yazmak güçlü bir pratiktir. Böylece bir denetçi “bu talep neden bu onaycıya gitti?” diye sorduğunda, o tarihte geçerli olan kuralları gösterebilirsiniz. Değişiklik yönetiminde de; yeni sürümü kademeli devreye almak, eski sürümü belirli bir süre daha çalıştırmak mümkün olur.

Değişiklik onayı ve yayın kontrolü

Onay süreçlerini değiştiren değişikliklerin kendisi de onay sürecine tabi olabilir. Örneğin limit artışı veya kontrol adımı kaldırma gibi riskli değişikliklerde, yayın öncesi güvenlik/uyum onayı istenebilir. Bu, süreçleri “kimseye sormadan” değiştirme riskini azaltır.

Power Automate ile gerçekçi uygulama deseni: Olay kaydı ve karar izi

Power Automate gibi platformlarda onay adımlarını hızlı kurmak mümkündür; ancak kurumsal olgunluk için olay kaydı, idempotency ve hata yönetimi gibi desenler eklenmelidir. Aşağıdaki örnekler; akışın içine gömülü, tutarlı bir kayıt modelini göstermeyi amaçlar.

Örnek 1: Onay olayını JSON olarak kaydetme

Bu örnek; bir onay adımının çıktısını standart bir şemaya dönüştürüp “ApprovalEvents” benzeri bir depoya yazmayı hedefler. Alanları kurumunuza göre genişletebilirsiniz.

{
  "requestId": "REQ-2026-000184",
  "processVersion": "3.2.0",
  "ruleSetVersion": "2026.02",
  "step": {
    "name": "ManagerApproval",
    "sequence": 2,
    "assignedTo": "user:ahmet.yilmaz",
    "delegatedTo": null
  },
  "decision": {
    "result": "Approved",
    "reason": "Budget within limit, vendor verified",
    "decidedAt": "2026-02-06T14:22:18Z"
  },
  "sla": {
    "targetMinutes": 240,
    "elapsedMinutes": 63,
    "breached": false
  },
  "trace": {
    "flowRunId": "08585f7c-2e2b-4c1a-9b63-1c8dbb0a91d1",
    "retryCount": 0
  }
}

Örnek 2: Denetim izi için basit bir SQL tablo şeması

Log verisini ilişkisel depoda tutuyorsanız, sorgu performansı ve raporlama açısından adım/karar ayrımı faydalı olur. Aşağıdaki şema örnektir; üretimde indeksleme ve erişim modeli ayrıca ele alınmalıdır.

CREATE TABLE ApprovalEvent (
  Id BIGINT IDENTITY(1,1) PRIMARY KEY,
  RequestId NVARCHAR(64) NOT NULL,
  ProcessVersion NVARCHAR(32) NOT NULL,
  RuleSetVersion NVARCHAR(32) NOT NULL,
  StepName NVARCHAR(64) NOT NULL,
  StepSequence INT NOT NULL,
  AssignedTo NVARCHAR(128) NOT NULL,
  DelegatedTo NVARCHAR(128) NULL,
  DecisionResult NVARCHAR(16) NOT NULL,
  DecisionReason NVARCHAR(512) NULL,
  DecidedAt DATETIME2 NOT NULL,
  TargetMinutes INT NULL,
  ElapsedMinutes INT NULL,
  FlowRunId NVARCHAR(64) NULL
);

CREATE INDEX IX_ApprovalEvent_RequestId ON ApprovalEvent(RequestId);
CREATE INDEX IX_ApprovalEvent_DecidedAt ON ApprovalEvent(DecidedAt);

Güvenlik ve veri yönetişimi: DLP, erişim ve gizlilik sınırları

Onay süreçleri; kişisel veri, finansal bilgi ve sözleşme ekleri gibi hassas içerikler taşıyabilir. Bu nedenle veri yönetişimi; tasarımın “sonradan eklenen” değil, ilk günden itibaren kurgulanan bileşeni olmalıdır. Özellikle erişim talepleri ve harcama süreçlerinde en az ayrıcalık ilkesi kritik hale gelir.

Erişim modeli: kimler okuyabilir, kimler değiştirebilir?

Talep verisinin okunması, onay verilmesi ve kayıtların yönetilmesi birbirinden ayrılmalıdır. Onaylayıcı, karar verir; ancak geçmiş kayıtları değiştiremez. Operasyon ekibi akışı izler; ancak karar gerekçesini düzenleyemez. Uyum ekibi rapor alır; ancak süreç kural setini tek başına yayınlayamaz.

Hassas veri minimizasyonu ve maskeleme

Denetim izi için her şeyi saklamak cazip görünse de, gereksiz hassas veriyi biriktirmek risk yaratır. Eklerdeki kişisel verileri maskelemek, karar için gerekli olmayan alanları loga yazmamak ve raporlarda alan bazlı yetkilendirme uygulamak olgun bir yaklaşımdır. Kayıt tutmak ile gereksiz veri biriktirmek aynı şey değildir.

Operasyonel dayanıklılık: Hata yönetimi, yeniden deneme ve idempotency

Kurumsal onay süreçleri, hatayı tamamen sıfırlayamaz; hedef, hatayı öngörmek ve etkisini sınırlamaktır. Ağ kesintisi, servis limitleri, entegrasyon değişiklikleri veya kullanıcı hesabı problemleri gibi durumlar onay akışını durdurabilir. Tasarım, bu durumlarda kontrollü davranmalıdır.

Yeniden deneme stratejisi ve geri dönüş planı

Her adım için “yeniden deneme” yaklaşımı aynı değildir. API çağrılarında exponential backoff, kullanıcı onaylarında ise hatırlatma ve eskalasyon daha uygundur. Ayrıca bir adım başarısız olduğunda; süreci tamamen iptal etmek yerine, durumu “beklemede” veya “manuel inceleme” gibi bir kuyruğa almak işletmeyi rahatlatır.

Idempotency: Aynı talebin iki kez işlenmesini engellemek

Özellikle webhook/trigger senaryolarında aynı olayın iki kez tetiklenmesi görülebilir. Talep ID’ye dayalı bir idempotency anahtarı ile, aynı talebin aynı adımının tekrar çalışması engellenebilir. Bu yaklaşım; iki kez e-posta gitmesi, iki kez kayıt açılması veya iki kez onaya düşmesi gibi can sıkıcı sorunları azaltır.

Uygulama kontrol listesi: Tasarımın olgunluğunu hızlı değerlendirin

Aşağıdaki kontrol listesi; bir onay sürecinin kurumsal standartlara ne kadar yakın olduğunu hızlıca ölçmenize yardımcı olur. Her madde, süreç sahipleri ve teknik ekip için ortak dil oluşturur.

• Yetki matrisi parametreleri net ve deterministik
• Görev ayrılığı ve delegasyon kuralları yazılı ve testli
• Denetim izi minimum kayıt seti eksiksiz
• Korelasyon anahtarları her sistemde taşınıyor
• SLA hedefleri, eskalasyon ve istisna kayıtları tanımlı
• Süreç/kural seti versiyonlama uygulanıyor
• Erişim modeli ve veri minimizasyonu prensipleri belirgin
• Hata yönetimi, yeniden deneme ve idempotency stratejisi var

Sonuç: Hızlı ama denetlenebilir onay süreçleri mümkün

Kurumsal hayatta “hız” ve “kontrol” çoğu zaman birbirine zıt gibi görünür. Oysa doğru tasarım; hız için gereksiz adımları azaltırken, kontrol için kanıt üretir ve riskli alanlarda kurallı sıkılık sağlar. Yetki matrisiyle doğru kişiyi hedeflemek, kayıt yönetimiyle kanıt zincirini korumak ve izlenebilirlikle operasyonu görünür kılmak, sürdürülebilir bir onay mimarisi kurmanın temelidir.

Başlangıçta küçük görünen bir onay akışı, büyüdükçe kurumsal süreçlerin kalbine yerleşir. Bu nedenle tasarımı; tek seferlik bir otomasyon değil, uzun vadeli bir ürün gibi ele almak; bakım, raporlama ve uyum maliyetlerini ciddi biçimde düşürür.