İzin modu, vekil kuralları ve denetlemelere dayanabilen şeffaf onay geçmişiyle iş akışlarında yetki devrini öğrenin ve gecikmeleri azaltın.
Onayların durmasının basit bir nedeni vardır: iş akışı belirli bir kişiyi bekliyordur ve sistem o kişi çevrimdışıyken ne yapacağını bilmez. Bir istek o kişinin gelen kutusuna düşer, başka kimsenin işlem yapma yetkisi yoktur ve her şey durur.
Bu, onaylar bir rol yerine bir isme bağlandığında daha da kötüleşir. Ekipler değişir, insanlar izinli olur, yöneticiler seyahat eder. İş akışı otomatik olarak bir vekile geçemiyorsa, “acil” uyarıları, manuel geçici çözümler ve gecikmiş kararlar ortaya çıkar.
Ayrıca insanların sıklıkla karıştırdığı birkaç benzer eylemi ayırmak faydalıdır:
Gerçek amaç sadece hız değil. Öngörülebilirlik ve temiz bir kayıt tutmaktır.
“Şeffaf” olmak yöneticiler ve denetçiler için iki anlam taşır: iş akışının neden bir vekile yönlendirildiğini görebilmelisiniz ve kimin onayladığını, ne zaman ve hangi kurala dayanılarak yaptığını ispatlayabilmelisiniz. Eğer Alex izindeyse ve Priya bir satın almayı onaylıyorsa, geçmiş Priya'nın Alex'in vekili olarak hareket ettiğini göstermelidir. Kayıt Alex onayladı gibi görünmemeli ve özel bir sohbete kaybolmamalıdır.
Hedef sonuç basittir: hiçbir istek bloke olmasın ve birinin yokluğunda bile kimin ne yaptığının açıkça incelenebilir bir izi olsun.
Açık terimler ileride karışık kuralları önler. İnsanlar kimlerin neyi onaylayabileceği konusunda anlaşmazsa, iş akışınız ya takılır ya da denetim sorunları çıkarır.
Çoğu onay iş akışında birkaç ortak rol vardır:
Birincil onaylayıcı (primary approver) bir adım için beklenen varsayılan kişidir. Yedek onaylayıcı (backup approver) ise birincil kişi yokken onay verebilecek geri dönüş yoludur.
İnsanlar sıklıkla “yedek onaylayıcı” ile “ikinci onaylayıcıyı” karıştırır; oysa bunlar farklıdır. İkinci onaylayıcı ekstra bir seviye ekler. Yedek ise aynı seviye için alternatif bir yoldur.
Delegasyon, bir vekilin hareket etmesine izin veren kuraldır. Yaygın iki stil şudur:
Onay seviyeleri, bir isteğin geçmesi gereken sıralı adımlardır (yöneticiden sonra finans, sonra hukuk, sonra BT gibi). “Seviyeleri” vekillerden ayrı tutun: seviyeler neyin onaylanması gerektiğini; vekiller ise alışılmış kişi yokken kimin onaylayabileceğini tanımlar.
Her ekip aynı yedeğe ihtiyaç duymaz. Doğru model, insanların ne sıklıkla yok olduğu, kararın ne kadar riskli olduğu ve onay adımlarının ne kadar öngörülebilir olduğuna bağlıdır.
İlk önce bir birincil modeli seçin ve diğerlerini istisna olarak ele alın. Baştan her şeyi karıştırmak kullanıcıları şaşırtır ve denetimleri zorlaştırır.
Çoğu ekip bu modellerin bir kombinasyonunu kullanır:
İzin modu genellikle günlük kullanım için en kolay olanıdır. Kural tabanlı delegasyon daha büyük ekiplerde manuel kararları azaltır. Eskalasyon delegasyonun yerine geçmez; zaman aşımı için bir güvenlik ağıdır.
Birkaç cevap seçeneklerinizi hızla daraltır:
İzin modu ancak öngörülebilir olduğunda işe yarar. Hedef basittir: onaylar hareket etmeye devam eder ve herkes kimin sorumlu olduğunu görebilir.
Açık bir zaman aralığı zorunlu kılın. Her delegasyonun başlangıç ve bitiş tarihi olmalı (bölgesel çalışıyorsanız saat dilimi de). “İkinci bir emre kadar” gibi belirsiz ifadelerden kaçının. Birisi kapatmayı unutursa, onaylar haftalarca yanlış kişiye gidebilir.
Vekili kim seçebilir karar verin. Küçük ekiplerde kişinin kendisinin seçtiği delegasyon çalışabilir, ama insanların eğitimsiz kişileri seçmesi risklidir. Yönetici ataması çoğu organizasyon yapısına uyar. Admin ataması sıkı kontrol gerektiren durumlar için iyidir ama kurulum süresini uzatabilir.
Sistemin uygulayabileceği uygunluk kuralları belirleyin. Basit tutun ve “özel durumlar”a izin vermeyin. Tipik kurallar: aynı departmanda veya maliyet merkezinde olmak, doğru onay seviyesi ve gerekli eğitimi tamamlamış olmak. Bariz çıkar çatışmalarını her zaman engelleyin: vekil istek sahibi olmamalı ve döngüsel onaylar engellenmelidir.
Açıkta olan onaylara ne olacağını tanımlayın. Birçok ekip yeni istekleri vekile yönlendirir ama mevcut bekleyen öğeleri birincil onaylayıcıda bırakır; yalnızca zaman aşımına uğradıklarında yeniden atama veya eskalasyon yapılır. Zaman aşımı politikanızı net yapın.
Durumu görünür kılın. İstek sahibi şu anki onaylayıcıyı, devretilmenin aktif olup olmadığını ve sıradaki adımı görmelidir. "Onay bekleniyor (Alex adına devredildi, 30 Oca'ya kadar)" gibi bir durum takip çağrılarını azaltır ve güveni yükseltir.
Önce ortak bir istek için (satın alma, erişim, politika istisnası) tam onay yolunu yazın. Küçük tutun. İki ila dört adım, deseni tasarlamak için yeterlidir.
Her adımı bir role ve tek bir kayıt sahibine eşleyin. Vekil hareket etse bile her adım için bir birincil onaylayıcı tutun, böylece sorumluluk net kalır.
Delegasyon için birincil tetikleyiciyi seçin. Çoğu ekip yokluk bayrağı, tarih aralığı veya yönetici kontrollü bir anahtar kullanır. İlk önce birini seçin ki insanlar sessiz yönlendirmelerle şaşırmasın.
Hareket eden onaylayıcıyı seçmek için yönlendirme kuralları ekleyin. Sonraki sırayı öngörülebilir yapmak açıkladıktan sonra kolaydır: kullanıcının seçtiği vekil, sonra yönetici, sonra paylaşılan bir yedek kuyruğu. Vekilin hemen onay verip veremeyeceğine yoksa bir zaman aşımından sonra mı onaylayabileceğine karar verin.
Bildirimlerle beklentileri belirleyin. İstek sahipleri şu anda kimin sorumlu olduğunu görmelidir. Birincil onaylayıcılar delegasyonun aktif olduğu ve nasıl kapatılacağı hakkında bilgilendirilmeli. Vekiller, bağlamı ve reddetme seçeneklerini açıkça almalıdır.
Bir uçtan uca test çalıştırın ve geçmişi inceleyin. Kim atandı, neden delegasyon oldu, kim onayladı ve ne zaman görebilmelisiniz.
Gerçekçi bir senaryo kullanın: birincil onaylayıcı “izinde” ve vekil onay veriyor. Ardından vekil de müsait değilken yedek kuralınızı doğrulayın. Son olarak denetim izi hem birinciliği hem hareket eden onaylayıcıyı ve delegasyon nedenini gösteriyor mu kontrol edin; böylece bir denetçi devri elinde sormadan anlayabilir.
Bir denetim izi, ne olduğunu, kimin yaptığını ve neden izin verildiğini sorgusuz cevaplamalıdır. Bu, devredilmiş onaylarla daha da önemlidir çünkü “sorumlu onaylayıcı” ile “tıklayan kişi” farklı olabilir.
Delegasyon kurallarını birincil kayıtlar olarak loglayın; ayarlar gibi sessizce değişen şeyler yapmayın. Kim kimi kime devretti, başlangıç ve bitiş zamanı, kapsam (hangi istekler, tutarlar, ekipler veya belge türleri) ve süreç onay imzası gerektiriyorsa bunu kim onayladı gibi bilgileri yakalayın.
Onay kararları değiştirilemez olaylar olmalıdır. “Beklemede”yi “onaylandı” ile üzerine yazmayın. “Onaylandı”, “Reddedildi” veya “Değişiklik istendi” gibi olayları kaydedin ve iş akışı yeniden başlasa bile tutun.
Pratik bir denetim izi genellikle şunları içerir:
Yorumları ve ekleri karar olayına bağlı tutun. Ayrı bir sohbet veya genel “notlar” alanında kalırlarsa hangi yorumun hangi kararı desteklediğini kanıtlamak zorlaşır.
Son olarak geçmişi okunabilir kılın. Delegasyon değişikliklerini, gönderilen bildirimleri, verilen kararları ve yapılan eskalasyonları sıralayan tek bir zaman çizelgesi anlaşmazlıkları önler.
İnsanlar neler olduğunu görebildiklerinde gecikmeleri kabul eder. Göremediklerinde yanlış kişiyi rahatsız eder, istekleri tekrar gönderir veya sistemin bozuk olduğunu varsayarlar.
İstek sahibi ve gözden geçiriciler her zaman mevcut onaylayıcıyı ve neden seçildiğini görmelidir. Görev birincil onaylayıcıdan vekile geçtiyse doğrudan şu şekilde gösterin: “Atandı: Priya (Alex için vekil).” Bu tek satır karışıklığı önler ve hesap verebilirliği korur.
Ayrıca delegasyon penceresini ve bunu kimin ayarladığını gösterin. “Delegasyon aktif: 10 Oca - 20 Oca, Alex tarafından ayarlandı” ekiplerin devrin kasıtlı olduğunu görmesine yardımcı olur.
Gizli yeniden atama denetimleri zorlar. Birisi iz bırakmadan onaylayıcıyı değiştirebiliyorsa kullanıcıların güveni zedelenir ve yöneticiler kimsenin ne yaptığını söyleyemez. Yeniden atamayı ilgili kişilere görünür yapın ve bunu tetikleyen kişiyi her zaman kaydedin.
Basit bir “Geçmişi görüntüle” paneli genellikle yeterlidir. Odaklı tutun: mevcut durum, mevcut onaylayıcı ve nedeni, delegasyon dönemi, manuel yeniden atamalar ve karar yorumları.
Gizlilik de önemlidir. Her rolün ne görebileceğini tanımlayın. Bir istek sahibi isimleri ve durumu görmeli; ama İK, finans veya hukuk iş akışlarında iç notlar maskelenebilir.
Delegasyon genellikle basit nedenlerle başarısız olur: kurallar çok gevşek, kayıtlar belirsiz ya da bir B planı yoktur. Sonuç tahmin edilebilir: istekler limbo'da bekler ve sonra kim neyi onayladığını kanıtlayamaz.
Yaygın tuzak, onayı onaylayamayacak birine delegasyon vermektir. Örneğin, bir satın alma sorumlusu onay yetkisini harcama limiti olmayan bir ekip arkadaşına devreder. Vekil onaylar, finans bunu işaretler ve şimdi işlemi geri almak ve sistemin bunu nasıl izin verdiğini açıklamak gerekir.
Sık görülen hatalar:
Bildirim aşırı yüklemesi sinsi bir problemdir. Her adım e-posta, sohbet, push ve hatırlatmayla tetiklenirse, kullanıcılar her şeyi görmezden gelmeyi öğrenir.
Çoğu problemi önleyen tasarım seçimleri:
Delegasyon, “sıkıcı detaylar” tutarlı olduğunda çalışır. Tüm şirkete izin modunu açmadan önce her onay adımını tarayın ve sorun: eğer atanan onaylayıcı bugün yoksa ne olur?
Sonra en az bir “izinli senaryosu”nu uçtan uca test edin: istek izinden önce gönderildi, izin sırasında onaylandı ve kişi döndüğünde gözden geçirildi.
Bir satış ekibi 12 adet yeni kulaklık için (USD 1.200) satın alma isteği gönderir. İstek normalde Satış Müdürü Maya'ya gider. Ancak Maya iki hafta izinde ve onaylar bekleyemez.
Maya ayrılmadan önce izin modunu etkinleştirir ve Jordan'ı (Satış Operasyonları Lideri) 5.000 USD'ye kadar satın alma onayları için vekil olarak atar. Bunun üzerindeki tutarlar hala Finansa gider.
Temiz, denetim dostu bir devrede süreç şöyle işler:
İki detay güven sağlar. İstek sahibi onaylayıcının neden değiştiğini görebilir ("Vekile yönlendirildi: Maya ofis dışında"), ve Maya döndüğünde hangi işlemlerin yapıldığını bilir.
Maya döndüğünde "Yokluk sırasında yapılan onaylar" görünümünü açar ve Jordan'ın onun adına onayladıklarını inceler. Tarih aralığına, tutara veya istek sahibine göre filtreleyebilir. Hiçbir şeyi yeniden onaylamaz, ama bir şey şüpheli görünürse takip için işaretleyebilir.
Daha sonra bir denetçi "Bu satın almayı kim onayladı ve neden Maya onaylamadı?" diye sorarsa, zaman çizelgesi tek bir tutarlı hikaye anlatır: orijinal onaylayıcı, delegasyon nedeni (izin modu), vekil kimliği, vekil atıfı, zaman damgalı karar ve not.
Delegasyonu küçük bir ürün değişikliği gibi ele alın, bir onay kutusu gibi değil. Hedef aynı kalır: insanlar yokken onaylar ilerlesin ve her kararı sonradan açıklayabilin.
Tıkandığında zarar veren bir iş akışıyla başlayın (masraflar, satın almalar veya erişim istekleri gibi). Kapsamı sıkı tutun: bir ekip, bir onay yolu ve net bir başarı ölçütü belirleyin; örneğin "birisi yok olduğu için onayların 24 saatten fazla beklemediği".
İnsanların gerçekten uyacağı kısa bir delegasyon politikası yazın: kim devredebilir, neler devredilebilir (ör. sadece belirli bir tutarın altındaki işlemler), delegasyon nasıl başlar/biter ve acil bir geçersiz kılma nasıl olur ve nasıl kaydedilir.
Roller ve kurallar için bir sorumlu atayın ve süresi dolmuş vekilleri temizlemek için aylık veya üç aylık düzenli bir inceleme planlayın. Uzun vadeli sorunların çoğu kapatılmamış eski delegasyonlardan gelir.
Ağır kodlama gerektirmeden bir onay uygulaması yapmak isterseniz, AppMaster (appmaster.io) kullanıcıları, rolleri ve delegasyon pencerelerini bir veritabanında modelleyebilir; ardından yönlendirme ve zaman aşımı kurallarını görsel İş Süreci Editörü'nde uygulayabilir ve denetimler için tutarlı bir onay geçmişi sağlayabilir.
Aşamalar halinde yayına alın, karışıklıkları dinleyin ve ilk iş akışı birkaç hafta sorunsuz çalıştıktan sonra bir sonrakine geçin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
