İK Onay Akışlarını Rol Bazlı Kurmak: Doğru Onaylayana Yönlendirme

Rol bazlı onay akışı ne demektir?

Rol bazlı onay akışı, bir talebin türüne ve şirketteki role göre otomatik olarak doğru kişiye gitmesi demektir: izin talebi doğrudan yöneticiye, yüksek tutarlı bir avans talebi hem yöneticiye hem muhasebeye, bir zimmet talebi de depo ya da IT sorumlusuna düşer. Kağıt üzerinde basit görünen bu ayrım, çoğu şirkette hiç yazılı değildir; talep kime gideceği belirsiz olduğu için önce "bunu kime sorsam" sorusuyla kaybolur, sonra da yanlış kişide bekler.

Sorun genelde onay hızında değil, onay rotasında başlar. Sistemin ne kadar hızlı çalıştığı önemsizleşir çünkü talep zaten yanlış masaya düşmüştür. Bu yazıda hızlanmayı değil, rotanın baştan doğru kurulmasını ele alıyoruz — onay sürecini hızlandırmayı anlattığımız yazıda zincirin kendisinin nasıl kısaltılacağına bakmıştık; burada zincirin doğru kişilere göre nasıl tasarlanacağına bakıyoruz.

Neden tek bir onaylayıcı yetmez

Küçük ekiplerde tüm talepler tek bir yöneticiye gider ve bu bir süre işe yarar. Ekip büyüdükçe aynı yönetici hem izin taleplerine hem harcama fişlerine hem zimmet iadelerine bakmaya çalışır; hiçbiri onun asıl uzmanlık alanı değildir ve hepsi aynı önceliği alır. Sonuç üç şekilde ortaya çıkar:

• Yanlış onay. Muhasebe konusu olmayan bir yönetici, bütçe etkisini görmeden yüksek tutarlı bir harcamayı onaylar; ay sonunda fark muhasebede fark edilir ama iş işten geçmiştir.
• Darboğaz. Tek kişi izinliyken ya da yoğunken tüm talep türleri aynı anda birikir; sadece izin değil, zimmet iadesi ve eğitim kaydı da bekler.
• Sorumluluk belirsizliği. Bir talebe itiraz geldiğinde "bunu kim onayladı, neden onayladı" sorusuna net cevap yoktur çünkü onaylayan kişi kendi uzmanlık alanı dışında karar vermiştir.

Rol bazlı yönlendirme bu üçünü de aynı anda çözer: her talep, o konuda karar verme yetkisi ve bilgisi olan role gider.

Yönlendirmenin bel kemiği: organizasyon hiyerarşisi

Rol bazlı onay akışı, önce doğru kurulmuş bir şube-departman-personel hiyerarşisi ister. Bu hiyerarşi sadece bir organizasyon şeması değildir; kimin kimin talebini göreceğini ve onay zincirinin hangi noktadan başlayacağını da belirler. Hiyerarşi kağıt üzerindeki resmi organizasyon şemasına göre değil, gerçekte kimin kime rapor verdiğine göre kurulmalıdır — aksi halde sistem "doğru" çalışır ama gerçek karar vericiyi atlar.

Pratikte bu, her personelin bir doğrudan yöneticisi, her departmanın bir sorumlusu ve talep türüne göre ikincil bir onaylayıcısının (örneğin muhasebe ya da depo sorumlusu) tanımlı olması demektir. Bu yapı bir kere doğru kurulduğunda, yeni işe başlayan her personel otomatik olarak doğru onay rotasına dahil olur; ayrıca kurulmasına gerek kalmaz.

Talep türüne göre rota nasıl tanımlanır

Her talep türü aynı rotayı izlemek zorunda değildir; aslında izlememelidir. Yaygın ve işe yarayan bir ayrım şöyledir:

• İzin talepleri doğrudan yöneticiye gider; ikinci bir onay genellikle gerekmez çünkü karar büyük ölçüde bakiyeye ve vardiya planına bağlıdır.
• Avans ve harcama talepleri tutar eşiğine göre kademelenir: küçük tutarlar tek adımda yöneticide kalır, belirli bir eşiği aşan tutarlar otomatik olarak muhasebeye de düşer.
• Zimmet talepleri (ekipman, araç, kart) doğrudan o kaynağı yöneten role gider — bir saha yöneticisine değil, depo ya da IT sorumlusuna.
• Fazla mesai talepleri genelde vardiyayı planlayan role gider, çünkü bütçe etkisini en doğru o rol görür.

Bu ayrımın faydası somuttur: her onaylayıcı yalnızca kendi uzmanlık alanındaki talepleri görür, karar hızı artar çünkü konuyu bilen kişi karar verir, ve yanlış onay riski düşer.

Tutar ve öncelik eşikleriyle kademeli onay

Her harcama ya da avans talebini aynı ciddiyette ele almak, sistemi gereksiz yere yavaşlatır. Küçük tutarlı, düşük riskli talepler için tek adımlı onay yeterlidir; yalnızca belirlenen eşiği aşan talepler ikinci bir onaya (örneğin bölge müdürü ya da muhasebe) yükselmelidir. Eşik nerede çizilecek sorusunun tek doğru cevabı yoktur — şirketin ölçeğine ve nakit akışına göre belirlenir — ama eşiğin yazılı ve sistemde tanımlı olması, "bu neden büyütüldü?" tartışmasını baştan bitirir.

Yetki devri: onaylayan role sahip kişi yoksa ne olur

Rol bazlı yönlendirmenin en kırılgan noktası, o role atanmış tek kişinin izinli ya da ulaşılamaz olduğu andır. İyi kurulmuş bir sistemde bu durum önceden tanımlanır: doğrudan yöneticisi izinliyken talep otomatik olarak bir üst role yükselir, vekalet eden kişi o süre boyunca astların taleplerini devralır. Bu mekanizma olmadan rol bazlı yapı, aslında tek kişilik bir darboğazın üzerine kurulmuş olur — rolün adı değişir ama sorun aynı kalır.

Kurulumda sık yapılan üç hata

Herkesi aynı role bağlamak. Şirket büyürken "her şey genel müdüre gitsin, o karar versin" yaklaşımı basit görünür ama ölçeklenmez; genel müdür darboğaza dönüşür ve talepler onun takvimine hapsolur.

Rolü kişiyle eşitlemek. Sistem "Ahmet onaylar" diye kurulursa, Ahmet ayrıldığında ya da rol değiştirdiğinde tüm rota bozulur. Doğru yaklaşım rolü tanımlamak ("Bölge Muhasebe Sorumlusu") ve o role kişi atamaktır; kişi değiştiğinde rota bozulmadan kalır.

Vekalet tanımlamamak. Yukarıda değindiğimiz gibi, tek kişilik roller izin döneminde çöker. Her kritik rolün en az bir vekili olmalıdır.

Kurulum kontrol listesi

Rol bazlı onay akışına geçerken şu sırayı izlemek işe yarar: önce gerçek raporlama hiyerarşisini çıkarın (kağıt şemayı değil), sonra talep türlerini listeleyip her biri için doğru rolü belirleyin, ardından tutar/öncelik eşiklerini yazılı hale getirin, son olarak her kritik role bir vekil atayın. İlk ay sonunda hangi taleplerin hâlâ "kime gitsin" belirsizliğiyle beklediğine bakın — bu liste, rotanızda hâlâ eksik olan role işaret eder.

Kurulumu bir kerede bitirmeye çalışmayın. Önce en sık talep edilen bir veya iki tür için rota tanımlayın, bir hafta gözlemleyin, sonra kalan türlere geçin. Bu kademeli yaklaşım, kağıt üzerinde mantıklı görünen ama pratikte gerçek raporlama hattıyla uyuşmayan bir rota tanımını erken fark etmenizi sağlar; hatayı tüm talep türlerine yaymadan tek bir türde düzeltmiş olursunuz.

HR-Tech'in saha takipli İK platformunda onay akışları tam bu mantıkla kurulur: şube-departman-personel hiyerarşisi ilk günden tanımlanır, talep türüne göre doğru role yönlendirme yapılır, doğrudan yönetici izinliyken talep otomatik olarak bir üst role yükselir ve her adımın kim tarafından ne zaman atıldığı denetim kaydına işlenir. Onay akışlarınız hâlâ "kime gitsin" belirsizliğinde bekliyorsa, iletişim sayfamızdan yazın — mevcut rotanızı birlikte çıkaralım.