Rol Bazlı Yetkilendirme İş Akışı Onay Yönetimi Rehberi

Rol Bazlı Yetkilendirme ve Onay Akışlarının Temel Mantığı

Çok departmanlı yapılarda en sık karşılaşılan sorun, kimin neye karar verebileceğinin yazılı bir kurala değil kişisel alışkanlığa dayanmasıdır. Bir satın alma talebi bazen departman müdüründe bekler, bazen doğrudan genel müdüre ulaşır; finans ekibi ise işlemi ancak ödeme aşamasında görür. Bu belirsizlik hem karar gecikmelerine hem de denetim boşluklarına yol açar.

Rol bazlı yetkilendirme (RBAC) modelinde yetkiler bireylere değil, tanımlanan rollere atanır. En az yetki prensibi gereği her rol yalnızca kendi işini tamamlamak için gereken erişime sahip olur; bu yaklaşım hata yüzeyini ve yetkisiz işlem riskini küçültür. Onay akışları ise bu rol tanımlarının üzerine inşa edilir: hangi rolün hangi koşulda onay vereceği, hangi tutarın üzerinde bir üst kademenin devreye gireceği ve onay zincirinin nasıl sıralanacağı önceden yazılı kurallara bağlanır.

Bu iki bileşen birbirinden bağımsız çalışmaz. Rol tanımı olmadan onay akışı kimin onaylayacağını bilemez; onay akışı olmadan rol tanımı kâğıt üzerinde kalır.

Çok Departmanlı Yapılarda Departmanlar Arası Çakışma Senaryoları

Büyüyen organizasyonlarda yetki çakışması genellikle üç noktada ortaya çıkar:

• Ortak bütçe kalemleri: Hem İK hem operasyon müdürünün onay yetkisi olduğunu düşündüğü bir eğitim harcaması, iki ayrı onay sürecine girer ya da hiçbirine girmez.
• Departmanlar arası projeler: Finans, proje ve satın alma ekiplerinin aynı talep üzerinde farklı sırayla onay beklediği durumlar, zinciri kilitler.
• Vekâlet boşlukları: Onay yetkisine sahip yönetici izinde ya da seyahatteyken süreç durur; çalışanlar gayri resmi yollarla onay almaya çalışır.

Bu senaryoların ortak özelliği, sorunun teknik değil yapısal olmasıdır. Yazılım bu yapıyı otomatik olarak icat edemez; süreç sahibinin önce politikayı tanımlaması, ardından sistemin bu politikayı tutarlı biçimde uygulaması gerekir. Korgün ERP’nin yetki devri rehberinde de vurgulandığı gibi, çözüm bütün yetkileri sınırsız devretmek değil; hangi kararın kim tarafından, hangi limite kadar ve hangi kayıtla alınacağını belirlemektir.

Adım Adım Yetki Matrisi ve Onay Zinciri Kurgusu

Yetki matrisini oluşturmadan önce mevcut karar envanterini çıkarmak gerekir. Aşağıdaki adımlar bir değerlendirme çerçevesi sunar; gerçek limitler ve sorumluluklar kurumun kendi politikasına göre belirlenmelidir.

1. Karar envanteri: Satın alma, masraf, izin, işe alım, fiyat istisnası gibi onay gerektiren tüm karar türlerini listeleyin.
2. Risk sınıflandırması: Her karar türü için tutar, bütçe etkisi, müşteri/tedarikçi riski ve operasyonel kritiklik değerlendirin.
3. Rol ve limit tanımı: Kimin hangi koşulda tek başına karar verebileceğini yazılı hale getirin.
4. Onay sırası: Limit aşıldığında hangi rolün devreye gireceğini ve sıralı mı paralel mi onay gerekeceğini belirleyin.
5. İstisna kuralı: Bütçe aşımı, sözleşme dışı tedarikçi veya acil durum gibi istisnaların nasıl yönlendirileceğini tanımlayın.
6. Kayıt ve raporlama: Her onay adımının gerekçesiyle birlikte kayıt altına alınacağını ve hangi raporların yönetime sunulacağını netleştirin.

Bu adımlar tamamlandıktan sonra aşağıdaki gibi bir onay matrisi oluşturulabilir. Bu tablo örnek bir iş senaryosunu yansıtmaktadır; gerçek limitler kurumunuzun politikasına göre belirlenmelidir.

Eşik Değerler, Dinamik Yönlendirme ve Sıralı / Paralel Onay Seçimi

Onay zincirleri yalnızca tutara göre değil; bütçe kullanım oranı, ürün kategorisi, proje kodu veya tedarikçi risk sınıfına göre de dinamik biçimde yönlendirilebilir. Kumsal Ajans’ın B2B onay akışı rehberinde belirtildiği gibi, aynı toplam tutar; ürün sınıfı, maliyet merkezi veya tedarikçi durumuna göre farklı onay rotasına gidebilir. Bu nedenle eşik değerleri tek boyutlu tutmak yerine çok değişkenli bir karar tablosuna dönüştürmek daha sağlıklı sonuç verir.

Sıralı onay, bir adım tamamlanmadan sonrakinin başlamadığı zincirdir. Bütçe sahibinin onayından sonra finansın devreye girmesi gibi bağımlı kararlar için uygundur. Paralel onay ise teknik, finansal ve ticari incelemelerin aynı anda başladığı modeldir; tamamlanma koşulunun “tümü”, “belirli çoğunluk” veya “zorunlu roller” olarak açıkça tanımlanması gerekir. İkisini karıştırmak, zincirin nerede durduğunu belirsizleştirir.

Onay akışı tasarımında göz ardı edilen bir nokta da belge değişikliğidir: onaydan sonra tutar, miktar veya tedarikçi değişirse önceki onayın geçerliliği yeniden değerlendirilmelidir. Sistem bu kontrolü otomatik yapmazsa eski onay yeni bir işlemi meşrulaştırmak için kullanılabilir.

Geçici Vekâlet (Delegasyon) Yönetimi

Vekâlet, onay akışlarının en çok ihmal edilen bileşenidir. Onay yetkisine sahip yönetici izne çıktığında hesabını başkasıyla paylaşmak hem güvenlik açığı yaratır hem de denetim izini bozar. Sağlıklı bir vekâlet mekanizması şu unsurları içermelidir:

• Başlangıç ve bitiş zamanı: Vekâlet belirli bir tarih aralığıyla sınırlı olmalı, süre dolunca otomatik kapanmalıdır.
• Kapsam sınırı: Vekil, asıl yetkilinin tüm yetkilerini değil yalnızca tanımlanan kapsam dahilindeki kararları alabilmelidir.
• Kayıt bütünlüğü: Geçmiş kararların kimin asli, kimin vekil yetkisiyle verildiği korunmalıdır.
• Eskalasyon kuralı: Bekleme süresi dolduğunda sessizce bir üst yöneticiye geçmek her süreç için doğru değildir; hatırlatma, yedek kuyruğa taşıma veya talep sahibine gecikmeyi gösterme gibi seçenekler değerlendirilmelidir.

Vekâlet mekanizması olmayan bir onay sistemi, yöneticinin fiziksel erişilebilirliğine bağımlı kalmaya devam eder. Bu durum özellikle çok departmanlı yapılarda zincirleme gecikmelere neden olur.

Merkezi Platform Üzerinde İş İzi ve Güvenli Süreç Denetimi

Onay akışlarının değeri yalnızca kararı hızlandırmakla ölçülmez; asıl değer, her kararın kim tarafından, hangi yetkiyle, hangi belge sürümüne dayanarak verildiğinin sonradan kanıtlanabilmesinde yatar. Telefon veya mesajla alınan sözlü onaylar bu kanıtı sağlayamaz.

Merkezi bir platformda iş izi şu bileşenleri kapsamalıdır: talep açan kullanıcı ve rolü, onay veren kullanıcı ve aktif yetkisi, kararın verildiği belge sürümü, gerekçe ve varsa ek belgeler, zaman damgası ve sonraki durum. Bu kayıt hem iç denetim hem de olası uyuşmazlık durumlarında referans noktası oluşturur.

Yönetimin her işlemi tek tek takip etmesi beklenmez; bunun yerine limit aşımları, reddedilen veya geciken onaylar ve bütçe sapmaları özetlenerek sunulmalıdır. Cockpit’in gösterge paneli modülü, bu tür özet görünümleri merkezi bir ekranda bir araya getirmeye olanak tanır.

Masraf ve avans süreçleri gibi finansal onay akışları söz konusu olduğunda, onay kaydının muhasebe süreciyle bütünleşik çalışması önemlidir. Logitera’nın geliştirdiği Cockpit platformunda masraf ve avans yönetimi modülü, bu tür süreçlerin kayıt altında tutulmasını destekleyen bileşenler içermektedir; ancak kurumunuza özgü onay akışı tasarımı ihtiyaç görüşmesinde netleştirilmelidir.

Uygulama Kontrol Listesi: Rol Bazlı Onay Akışı Kurulumu

Aşağıdaki liste, onay akışı kurgusu için bir değerlendirme çerçevesi sunar. Her madde bir karar noktasıdır; kurumunuzun koşullarına göre öncelik sırası değişebilir.

1. Onay gerektiren tüm karar türleri listelenmiş mi? (satın alma, masraf, izin, işe alım, sözleşme vb.)
2. Her karar türü için risk sınıflandırması yapılmış mı? (tutar, bütçe etkisi, operasyonel kritiklik)
3. Rol tanımları yazılı hale getirilmiş ve sisteme işlenmiş mi?
4. Tutar ve kategori bazlı eşik değerleri belirlenmiş mi?
5. Sıralı ve paralel onay zincirleri hangi süreçler için kullanılacağı netleştirilmiş mi?
6. Vekâlet mekanizması zaman ve kapsam sınırıyla tanımlanmış mı?
7. Bekleme süresi aşıldığında eskalasyon kuralı belirlenmiş mi?
8. Belge değişikliği durumunda önceki onayın geçerliliği nasıl değerlendirileceği tanımlanmış mı?
9. Her onay adımı gerekçesiyle birlikte kayıt altına alınıyor mu?
10. Yönetim için limit aşımı ve gecikme özeti raporlanıyor mu?

Rol bazlı yetkilendirme ve iş akışı onay yönetimi, tek seferlik bir kurulum değil sürekli gözden geçirilen bir yapıdır. Organizasyon büyüdükçe yeni roller, yeni eşik değerleri ve yeni istisna senaryoları ortaya çıkar. Bu nedenle sistemi kurarken değişikliğe açık bir mimari tasarlamak, uzun vadede en kritik yatırım olarak değerlendirilebilir.