Onay İş Akışı: Adımlar, Kurallar ve Yazılım Gereksinimleri

Onay iş akışı; bir talebin gönderildiği, karar vermeye yetkili kişilere yönlendirildiği, gerekçesiyle onaylandığı veya reddedildiği ve kaydedildiği tanımlı bir dizidir. Değer, onay düğmesinde değil yönlendirme kurallarında ve kayıttadır. Aynı yapı belge incelemesini, satın alma yetkilendirmesini ve diğer tüm kontrollü kararları kapsar.

İkiden fazla onay seviyesi genellikle gerçek risk kontrolünden çok belirsiz yetkiye işaret eder. Eşikleri tutar veya riske göre belirleyin ki rutin işler tek adımda geçsin ve yalnızca istisnalar yukarı taşınsın.

Önemli noktalar

• Eşikler seviyelerden iyidir: Tutara veya riske göre yönlendirin ki çoğu talep üç değil bir onay gerektirsin.
• Önce yokluğu tasarlayın: Ele alınmayan müsaitsizlik, onay sistemlerinin e-postayla atlanmasının nedenidir.
• Yönlendirmeniz sıra dışı değilse satın alın: Standart ürünler doğrusal onayı iyi, dallanmayı kötü yönetir.
• Asıl teslimat kayıttır: Kimin neye, ne zaman ve kuralın hangi sürümü altında karar verdiği.

Akışı tanımlamadan önce yetkiyi tanımlayın

Onay sorunlarının çoğu, yazılım kılığına girmiş yönetişim sorunlarıdır. Bir akış haritalamadan önce, kurumu neye kadar bağlamaya gerçekte kimin yetkili olduğunu ve hangi tutara kadar olduğunu yazın.

Kurumlar bu çalışma sırasında düzenli olarak birkaç kişinin aynı yetkiye sahip olduğunu düşündüğünü ya da bir adımın yalnızca birileri bir zamanlar görünürlük istediği için var olduğunu keşfeder. Görünürlük için var olan onay adımları bildirimle değiştirilmelidir; bildirim hiçbir maliyeti yoktur ve kimseyi bekletmez.

Sonra eşikleri belirleyin. Belirli bir tutarın altındaki bir satın almanın tek onayla geçmesi ve yalnızca istisnaların yukarı taşınması, tipik bir süreçteki gecikmenin çoğunu anlamlı bir kontrol kaybı olmadan ortadan kaldırır.

Akışın dört parçasını haritalayın

Talep, gönderenin sağladığıdır ve karar verilmesini sağlayan asgari bilgi olmalıdır. Her ek zorunlu alan, talebi sistemin etrafından dolaştırmak için bir gerekçedir.

Kurallar, tutara, kategoriye, departmana, riske veya bunların birleşimine göre kimin karar vereceğini belirler. Bunları şema olarak değil açık koşullar olarak yazın; çünkü koşullar test edilebilir, şemalar edilemez.

Karar, onay, ret veya düzeltme için iadedir — ve üçüncüsü sıklıkla atlanır, bu da insanları reddedip yeniden göndermeye zorlar ve geçmişi kaybettirir.

Denetim, kalıcı kayıttır: kim, ne zaman, hangi bilgiye dayanarak ve kuralın hangi sürümü altında karar verdi. Tüm iş akışının var olma nedeni budur.

Onaycı müsait olmadığında ne olacağını tasarlayın

Bu tek karar, bir onay sisteminin gerçek hayatla temasından sağ çıkıp çıkmayacağını belirler.

Devir ve zaman aşımı davranışını lansmandan önce tanımlayın: yokluğu kim karşılar, talep ne kadar sonra yukarı taşınır ve otomatik mi yükselir yoksa bekler mi. Devrin onaycı tarafından önceden mi ayarlandığına yoksa bir yönetici tarafından mı uygulandığına karar verin ve kaydın, nominal olarak sorumlu olanı değil fiilen karar vereni göstermesini sağlayın.

Ele alınmayan yokluk, onay sistemlerinin atlanmasının en yaygın nedenidir. İzindeki birinin arkasında sıkışan tek bir acil talep, kuruma bunun yerine e-posta kullanmayı öğretir ve bu alışkanlık geri dönmez.

Aynı modeli belgelere genişletin

Belge iş akışı, farklı sözcüklerle aynı problemdir: bir belgenin oluşturulmasından incelemesine, onayına, dağıtımına, saklanmasına ve nihayet imhasına kadar izlediği yol ve her adımdaki kayıt.

Mekanik kısımları otomatikleştirin — yönlendirme, sürüm kontrolü, hatırlatmalar, saklama süreleri ve denetim izi — ve muhakemeyi, yani belgenin ne söyleyeceğini, insanlara bırakın. En çok önemli olan sürüm kontrolüdür: gerçek zarar veren hata, iki kişinin farklı kopyaları düzenlemesidir ki bunu yazılım tamamen çözer, e-posta çözmez.

Saklama kurallarını personelin hatırlamasına bırakmak yerine sistemde belge sınıfı bazında tanımlayın. Ticari ve vergi kayıtları genellikle birkaç yıl gerektirir ve gereklilik belge türüne ve yargı alanına göre değişir.

Satın alma ile geliştirme arasında yönlendirme karmaşıklığına göre karar verin

Onay akışınız büyük ölçüde doğrusal ve eşiklere dayalıysa, süreç rekabet ettiğiniz bir şey değil idari bir işse ve bir çeyrek içinde çalışır durumda olması gerekiyorsa satın alın. Standart ürünler bunu iyi yapar ve geliştirici yerine yöneticiler tarafından yapılandırılabilir.

Yönlendirmenin çok sayıda koşullu dalı varsa, onaylar hiçbir satıcının desteklemediği çekirdek sistemlere geri yazmak zorundaysa veya iş akışı sattığınız hizmetin parçasıysa geliştirin.

En zor kuralınızı demoya götürün. Satıcılar temiz bir onay akışı gösterir ki bunu her ürün yapar. Eşik, istisna, devredilmiş onaycı ve başka bir sisteme geri yazma içeren kuralı götürün ve canlı yapılandırmalarını isteyin. Bazıları on dakikada yapar; bazıları hizmet bedeli ister ve o fiyatı önceden yazılı almalısınız.

Hacmi değil gecikmeyi ölçün

Gönderimden karara geçen süreyi, düzeltme olmadan onaylanan taleplerin oranını ve taleplerin en çok nerede beklediğini izleyin.

Onay hacmi işe yarar bir ölçüt değildir ve yanlış şeyi ödüllendirir. Bilmek istediğiniz, sürecin insanların kullanacağı kadar hızlı olup olmadığı ve nerede olmadığıdır. Gecikmenin çoğunu tek bir onaycının tutması, yazılım bulgusu değil yönetişim bulgusudur ve bir iş akışı sisteminin ilk kez görünür kıldığı türden bir şeydir.

İlgili rehberler

İlgili içerikler:

• Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona
• Otomasyon Keşif Aşaması Hangi Çıktıları Sağlamalı?
• Excel İş Akışı Sorunları: Maliyetler, Riskler ve Alternatifler

Onay İş Akışı: Adımlar, Kurallar ve Yazılım Gereksinimleri rehberinden doğan çalışma; ürün stratejisi, tasarım, geliştirme veya entegrasyon desteği gerektiren somut bir girişime dönüşürse Operasyon Platformunuzu Konuşalım.