İş akışı istisnaları: işi ilerleten yollar

Günlük iş akışı sorunları neden net yollara ihtiyaç duyar?

Çoğu iş akışı diyagramda basit görünür: biri başvuru gönderir, yönetici onaylar ve ekip işi tamamlar. Gerçek işler nadiren bu düz çizgiyi izler. Bir form maliyet merkezi olmadan gelir, müşteri istisna talep eder veya onay sorumlusu son tarihi kaçırır.

Belirlenmiş bir yol yoksa süreç durur. İnsanlar ayrıntıları sohbete kopyalar, hatırlatma e-postaları gönderir veya sorunu takip etmek için bir tablo açar. İlk başvuru belirsizlik içinde kalırken birkaç kişi aynı bilginin farklı sürümlerini kullanır.

Net iş akışı istisnaları başvuruyu sürecin içinde tutar. İş akışı, başvuru sahibinden eksik bilgileri isteyebilir, reddedilen başvuruyu gerekçesiyle geri gönderebilir veya geciken görevi yedek bir sorumluya atayabilir. Herkes güncel durumu ve sırada kimin işlem yapması gerektiğini görür.

Bu yaklaşım raporlamayı da daha yararlı hale getirir. On satın alma başvurusu bütçe kodu bekliyorsa, başvuru formunda tekrarlanan bir sorun vardır. Başvurular sık sık manuel incelemeye gidiyorsa onay kurallarının ayarlanması gerekebilir. Sohbet mesajları bu kalıpları çoğu zaman gizler.

Bir süreç hatasıyla iş kararı farklı şekilde ele alınmalıdır. Gerekli veri eksik veya geçersiz olduğu için iş akışı duruyorsa bu bir süreç hatasıdır. Örneğin bir çalışan makbuz olmadan masraf bildirimi gönderir. İş akışı bildirimi geri göndermeli ve çalışanın ne eklemesi gerektiğini belirtmelidir.

İş kararı ise değerlendirme gerektirir. Bir sipariş normal harcama limitini aşabilir, ancak tedarikçinin acil bir yedek parçaya ihtiyacı olduğu için yönetici siparişi onaylayabilir. Veriler eksiksizdir, fakat kurallar tek başına sonucu belirleyemez.

Bu iki durumu genel «hata» olarak ele almak karışıklık yaratır. Başvuru sahipleri bir alanı mı düzeltmeleri, kanıt mı sunmaları yoksa karar mı beklemeleri gerektiğini bilemeyebilir. Her istisnaya anlaşılır bir ad, belirli bir sorumlu ve tanımlı bir sonuç verin.

Örneğin AppMaster ile oluşturulan bir iş akışı eksik başvuruları gönderene geri gönderirken politika istisnalarını yöneticiye iletebilir. Başvuru, gelen kutuları arasında dolaşmak yerine tek bir yerde kalır. Bu basit tercih, çok sayıda takip işini önleyebilir.

İş akışını oluşturmadan önce her istisnayı tanımlayın

Bir iş akışının normal ilerlemenin durduğu anlar için net yollara ihtiyacı vardır. Dört yaygın iş akışı istisnasıyla başlayın: eksik bilgi, reddedilen başvurular, geciken işler ve manuel inceleme gerektiren durumlar. Her biri «bir şeyler ters gitti» gibi belirsiz bir durum yerine kendi kuralına sahip olmalıdır.

Her istisna için tetikleyiciyi, sorumluyu, son tarihi ve sonraki işlemi belgeleyin. Böylece kimin yanıt vermesi gerektiği bilinmediği için başvuruların kuyrukta beklemesi önlenir.

Her yolun işi başvuru sahibine geri gönderip göndermeyeceğine veya başvuruyu sonlandırıp sonlandırmayacağına erkenden karar verin. Eksik bilgiler genellikle başvuruyu yapan kişiye geri döner. Reddedilen bir başvuru değişiklik için geri gönderilebilir, ancak sabit bir politikayı ihlal eden başvuru açık bir gerekçeyle kapatılmalıdır. Çalışanlar yeniden başvuru yapıp yapamayacaklarını tahmin etmek zorunda kalmamalıdır.

Mevcut durumu açıklayan adlar kullanın. «Başvuru sahibinden bilgi bekleniyor», «Reddedildi», «Gecikti» ve «Manuel inceleme gerekiyor» gibi ifadeler, «İstisna 2» veya «İşlem bekliyor» gibi etiketlerden daha kullanışlıdır. Bir listeye bakan kişi ne olduğunu ve sırada kimin işlem yapacağını anlamalıdır.

Yalnızca ilk başvuru için değil, istisnanın kendisi için de son tarih belirleyin. Örneğin başvuru sahibine eksik faturayı yüklemesi için iki iş günü verin. Yanıt gelmezse iş akışı bir hatırlatma gönderebilir ve belirlenen sürenin sonunda başvuruyu kapatabilir. Böylece eski işler sessizce birikmez.

Kodsuz bir uygulamada istisnaları görünür durum değişiklikleri ve iş sürecindeki ayrı yollar olarak oluşturun. AppMaster'ın görsel Business Process Editor aracı kararları eşlemenize, sorumlular atamanıza ve başvuruları sonraki adıma yönlendirmenize yardımcı olabilir. Durum listelerinde, bildirimlerde ve çalışan ekranlarında aynı ifadeleri kullanın.

Eksik bilgisi olan başvuruları yönlendirin

Boş bir alan içeren başvuru, birinin onaylayabileceği işlerle aynı kuyrukta beklememelidir. «Bilgi bekleniyor» gibi net bir durum verin ve başvuruyu aktif onay yolundan çıkarın. Böylece insanlar ilerlemenin neden durduğunu görebilir ve bir inceleyicinin başvuruyu gözden kaçırdığını düşünmez.

Durum, başvuru sahibine doğrudan bir mesaj göndermelidir. «Daha fazla ayrıntı gerekli» gibi belirsiz notlardan kaçının. Eksik öğeyi adlandırın ve kabul edilebilir bir yanıtın nasıl görüneceğini açıklayın: «Bu satın alma başvurusunu inceleyebilmemiz için lütfen tedarikçi teklifini ekleyin ve aylık maliyeti girin.»

İlk başvuruyu açık ve düzenlenebilir tutun. Başvuru sahibi departmanı, bütçe kodunu ve açıklamayı yeniden yazmadan teklifi ekleyebilmeli veya tarihi düzeltebilmelidir. İyi bir iş akışı istisna yönetimi yolu, daha önce kontrol edilen ayrıntıları, yorumları ve başvurunun durum değiştirdiği zamanı korur.

Geri dönüş yolunu açıkça tanımlayın

Başvuru sahibi eksik bilgiyi eklediğinde başvuruyu belirlenmiş bir sonraki adıma gönderin. Çoğu zaman başvuru sahibinden ayrıntıyı isteyen kişiye geri döner. Yeni bilgi kararı değiştiriyorsa ilk onay aşamasına dönmesi gerekebilir.

Eksik alanları veya belgeleri, yanıt vermekten sorumlu kişiyi, güncellemeyi kontrol edecek inceleyiciyi, yanıt son tarihini ve başvuru sona ererse kapanma nedenini kaydedin. Bu kayıt, daha sonra ortaya çıkabilecek soruları yanıtlar. Bir yönetici, fatura başvurusunun finans ekibinin yavaş onayı yüzünden değil, vergi belgesi beklediği için durduğunu görebilir.

Hatırlatmalar ve kapanış kuralı kullanın

Yanıt son tarihinden önce bir hatırlatma ayarlayın. İki iş gününün ardından ve son tarihte birer hatırlatma göndermek pratik bir yaklaşımdır. Hatırlatmayı önce başvuru sahibine gönderin, sürecin eskalasyon gerektirdiği durumlarda yöneticisini ekleyin.

İş akışı istisnalarının bir bitiş noktası da olmalıdır. Belirlenen süre içinde yanıt gelmezse başvuruyu «Eksik» olarak kapatın ve nedeni kaydedin. Başvuruyu silmeyin. Başvuru sahibi yeni bir başvuru gönderdiğinde geçmişe ihtiyaç duyabilir.

AppMaster gibi kodsuz bir iş akışı aracı başvuru durumunu saklayabilir, bildirim gönderebilir ve güncellenen formu görsel iş süreçleri aracılığıyla inceleyiciye geri yönlendirebilir. Bir iş arkadaşınız eksik olanı, kimin işlem yapması gerektiğini ve hiçbir şey yapılmazsa ne olacağını anlayabilmelidir.

Bağlamı kaybetmeden reddedilen başvuruları yönetin

Reddedilen bir başvuru gelen kutusunda veya belirsiz bir durum etiketinin içinde kaybolmamalıdır. Başvuruyu yapan kişi neyin başarısız olduğunu, kararı kimin verdiğini ve sorunu düzeltip düzeltemeyeceğini bilmelidir. Daha sonra soru çıktığında yöneticilerin de aynı kayda ihtiyacı vardır.

Nedeni yalnızca serbest metin yorumunda değil, yapılandırılmış bir alanda saklayın. Bir satın alma formunda «Bütçe yok», «Yinelenen başvuru», «Eksik onay» veya «Politika ihlali» gibi nedenler sunulabilir. Seçilen nedene sığmayan ayrıntılar için kısa bir yorum alanı ekleyin.

Bu, raporların kullanımını kolaylaştırır. Yönetici, başvuruların çoğunun çalışanların maliyet merkezini atlaması nedeniyle mi yoksa bir politikanın insanları şaşırtması nedeniyle mi başarısız olduğunu görebilir. Ayrıca inceleyicilerin «bütçeyi aşıyor» ve «bütçe çok yüksek» gibi aynı nedenin farklı sürümlerini yazmasını önler.

Reddedilen bir başvurunun üç olası sonucu vardır. Eksik teklif, belirsiz iş gerekçesi veya yanlış tutar gibi başvuru sahibinin düzeltebileceği bir sorun varsa değişiklik için geri gönderin. Onaylanmamış bir tedarikçi kullanmak veya izin verilen limiti aşmak gibi açık bir kural ihlali varsa kapatın. Yönetici ya da uyum sorumlusu karar vermeliyse belirsiz durumları manuel incelemeye gönderin.

Geri gönderilen bir başvuru ilk ayrıntılarını, eklerini ve onay geçmişini korumalıdır. Başvuru sahibinden yeni bir başvuru oluşturmak yerine mevcut başvuruyu düzenlemesini isteyin. İş akışı durumu «Değişiklik istendi» olarak ayarlayabilir, başvuruyu sahibine atayabilir ve seçilen ret nedenini inceleyici notuyla birlikte gönderebilir.

Başvuru sahibi yeniden gönderdiğinde yeni sürümü kaydedin ve uygun inceleyiciye iletin. Önceki reddi geçmişte tutun. Bu kayıt başvurunun neden durduğunu ve başvuru sahibinin sorunu giderip gidermediğini açıklar.

Kapatılan başvurular da aynı özeni gerektirir. Başvuru sahibini, inceleyicileri, karar tarihini, ret kodunu, notları ve ekli kanıtları tek bir kayıtta tutun. Başvuru sahipleri kendi kapatılmış başvurularını görebilmeli, yöneticiler ise ekiplerinin tam geçmişini görüntüleyebilmelidir.

AppMaster'da veri modeli başvuru durumunu, ret nedenini, inceleyici notlarını, karar tarihini ve bir geçmiş tablosunu içerebilir. Görsel bir iş süreci düzeltilebilecek başvuruları başvuru sahibine geri gönderebilir ve politika ihlallerini otomatik olarak kapatabilir. Rutin düzeltmeler ilerlemeye devam ederken nihai kararlar belgelenmiş olur.

Geciken görevler için kurallar belirleyin

Son tarih her görev için aynı varsayılan zamanlayıcıya dayanmak yerine işin niteliğine uygun olmalıdır. Bir yöneticinin rutin bir masrafı onaylamak için bir iş gününe, hukuki inceleme için ise beş güne ihtiyacı olabilir. Ekip kapasitesi de önemlidir. Atanan kişi günün çoğunu müşterilerle geçiriyorsa iki saatlik bir son tarih pek anlamlı değildir.

Son tarih kuralını iş akışına yazın. Sayacın ne zaman başladığını, hafta sonlarının hesaba katılıp katılmadığını ve görevin tamamlandığını hangi olayın gösterdiğini belirtin. Açık kurallar, bir başvurunun cuma günü geç gelmesi veya başka bir ekipten bilgi beklemesi gibi durumlarda tartışmaları önler.

Son tarihten önce hatırlatma gönderin. Kullanılabilir sürenin yüzde 75'ine gelindiğinde gönderilen bir hatırlatma, sorumluya harekete geçmesi için çoğu zaman yeterli zaman bırakır. Beş günlük bir görevde hatırlatmayı dördüncü gün gönderin. Mesajda görev adını, son tarihi, mevcut sorumluyu ve gerekli işlemi belirtin. «Bekleyen bir göreviniz var» ifadesi insanların işine çok az yarar.

Son tarih geçtiğinde sonraki işlemi karar verme yetkisi olan belirli bir kişiye veya role atayın. Geciken işi genel bir gelen kutusuna göndermeyin. Bu, sorumluluğu gizler ve çoğu zaman yeni bir gecikmiş görev oluşturur.

Sonuç, gecikmenin türüne uygun olmalıdır. Eksik uyum kontrolü gibi güvenli bir kararı engelleyen gecikmiş bir görev varsa başvuruyu duraklatın. İlk sorumlu yoksa veya kapasitesi yetersizse görevi yeniden atayın. İç notun geç kalması gibi gecikme sonraki adımı engellemiyorsa görünür bir uyarıyla devam edin. Gecikme müşteriye verilen sözü, ödemeyi veya dış bir son tarihi etkiliyorsa yöneticiye eskale edin.

Tekrarlanan eskalasyonlara sınır koyun. Bir satın alma başvurusu, bir gecikmiş hatırlatmadan sonra alıcıdan satın alma liderine, başka bir iş gününün ardından finans yöneticisine geçebilir. Yeni sorumlu önceki yorumları ve ekleri görebilsin diye başvuru geçmişi korunmalıdır.

İş akışı istisnaları yalnızca bir uyarıya ihtiyaç duymaz. Bir sorumluya, karar kuralına ve kaydedilmiş bir sonuca ihtiyaç duyar. AppMaster'da görsel bir iş süreci geciken görevleri doğru kişiye yönlendirebilir ve ayrı son tarih tabloları olmadan başvuruların ilerlemesini sağlayabilir.

İnsanların kullanabileceği bir manuel inceleme adımı ekleyin

Bazı başvurular bir kurala uymaz. Tedarikçi adı tanıdık görünmeyebilir, masraf normal limiti aşabilir veya iki alan birbiriyle çelişebilir. Bu durumlarda otomatik yönlendirme yerine bir kişinin karar vermesi gerekir.

Manuel inceleme sürecini odaklı tutun. Yalnızca değerlendirme gerektiren başvuruları gönderin ve yönlendirmenin nedenini görünür yapın. «İnceleme gerekiyor» gibi belirsiz bir durum, inceleyicinin iş akışının neden durduğunu kendisinin araştırmasını gerektirdiği için ek iş yaratır.

İnceleyicilere yeterli bağlam sağlayın

İnceleme ekranında ilk başvuru, istisnayı tetikleyen alan veya kural, önceki yorumlar ve destekleyici dosyalar gösterilmelidir. Satın alma talebini onaylayan yönetici tutarı, tedarikçiyi, bütçe kodunu, başvuru sahibini ve teklifi tek yerde görmelidir.

İnceleyicilere sonraki iş akışı yoluna uygun seçenekler verin: başvuruyu onaylayıp ilerletmek, reddedip kapatmak, değişiklik için başvuru sahibine geri göndermek veya belirli bir kişiye ya da ekibe eskale etmek. Her istisna kararı için kısa bir gerekçe isteyin. «Bütçe aşıldı» veya «İmzalı teklif eksik» gibi ifadeler başvuru sahibinin harekete geçmesine yardımcı olur ve sonraki inceleyici için kayıt bırakır. Rutin onaylar uzun açıklamalar gerektirmez.

Karar için bir süre belirleyin

Kararın sahibi yoksa manuel iş gecikmiş işe dönüşebilir. İş akışı bir inceleyici atadığında son tarih belirleyin. Örneğin standart bir satın alma başvurusu için iki iş günü verin. Son tarihten önce hatırlatma gönderin, atanan kişi yoksa başvuruyu yedek inceleyiciye veya yöneticiye yönlendirin.

Karar verme yetkisi herkeste olmadığı sürece aynı başvuruyu aynı anda herkese göndermekten kaçının. Bu, çelişkili yanıtlar doğurabilir. Önce tek bir sorumlu atayın, her işlemi kaydedin ve nihai karardan sonra başvuruyu kilitleyin.

AppMaster'da bir Business Process istisnayı inceleme görevine yönlendirebilir, kararı ve yorumu saklayabilir ve onay, ret veya değişiklik istendi yollarından biriyle devam edebilir. Görev ilk başvuruya bağlı kalır, böylece insanların geçmişi e-postalardan yeniden oluşturması gerekmez.

Örnek: yoldan çıkan bir satın alma başvurusu

Bir çalışan 2.400 dolar değerinde yeni monitörler için satın alma başvurusu gönderir. Başvuruda ürün listesi ve departman vardır, ancak tedarikçi teklifi eksiktir. İş akışı başvuruyu yöneticiye göndermek yerine durumu «Bilgi bekleniyor» olarak ayarlar ve sonraki görevi başvuru sahibine atar.

Başvuru sahibi eksik belgenin adını ve bir son tarihi içeren bir mesaj alır. Yönetici eksik bir başvuru almaz, bu nedenle onay kuyruğu işlevini korur. Başvuru sahibi teklifi yüklediğinde iş akışı yükleme zamanını kaydeder, durumu «Bütçe incelemesine hazır» olarak değiştirir ve başvuruyu finans sorumlusuna gönderir.

Finans ekibi kalan departman bütçesini kontrol eder ve tutar aylık limiti aştığı için başvuruyu reddeder. Reddedilen başvuru iş akışı ilk formu, teklifi, yorumları ve onay geçmişini birlikte tutar. Durum «Bütçe nedeniyle reddedildi» olur ve başvuru sahibi şu açık güncellemeyi alır: «Siparişi 1.800 dolara düşürün veya gelecek ayı bekleyin.»

Başvuru sahibi iki monitörü çıkarır ve başvuruyu yeniden gönderir. İş akışı başvuru sahibinden yeniden başlamasını istemek yerine yeni bir finans inceleme görevi oluşturur. Finans ekibi düzeltilmiş tutarı onaylar. Durum «Yönetici onayı bekleniyor» olur ve yönetici önceki reddin tam geçmişiyle birlikte görevi alır.

Bir onay gecikirse

Yöneticinin yanıt vermek için iki iş günü vardır. İkinci gün iş akışı bir hatırlatma gönderir. Son tarih geçerse geciken görev yönetimi durumu «Yönetici onayı gecikti» olarak değiştirir ve eskalasyon görevini yöneticinin ekip liderine atar.

Başvuru sahibi de bir güncelleme alır. Başvurunun eskale edilmiş bir karar beklediğini, ilk son tarihi ve eskalasyon zamanını başvuru kaydında görebilir.

Ekip lideri bütçe notunu ve tedarikçi teklifini kontrol ettikten sonra siparişi onaylar. İş akışı başvuruyu «Satın alma için onaylandı» durumuna getirir, siparişi vermesi için satın alma ekibine atar ve başvuru sahibine işlemin devam edebileceğini bildirir.

Bu örnek, iş akışı istisnalarının neden kendi durumlarına ve sorumlularına ihtiyaç duyduğunu gösterir. Her dal bir kişiye sonraki işlemi bildirirken başvuru sahibi sohbetlerde insanları takip etmek zorunda kalmadan güncellemeleri alır. Satın alma ekibi siparişi kapattığında kayıtta eksik teklif talebi, finans reddi, düzeltilmiş başvuru, geciken onay ve nihai karar bulunur.

İstisna yolları oluştururken sık yapılan hatalar

Ekipler genellikle önce normal yolu oluşturur, ardından diğer her şey için tek bir genel yol ekler. Bu yol çoğu zaman yoğun bir yöneticide sonlanır. Eksik ayrıntılar, reddedilen başvurular ve geciken onaylar farklı kişilere ve farklı işlemlere ihtiyaç duyar. Hepsini tek gelen kutusuna göndermek gecikme yaratır ve ekibin düzeltebileceği kalıpları gizler.

İnsanlara ne olduğunu ve ne yapmaları gerektiğini anlatan adlar kullanın. «Sorun» ve «İlgilenilmesi gerekiyor» gibi ifadeler inceleyiciyi her öğeyi açıp değerlendirmeye zorlar. «Tedarikçi teklifi eksik», «Finans tarafından reddedildi» veya «Onay iki gün gecikti» gibi etiketler sonraki kişiye işe yarar bir başlangıç noktası verir.

Birkaç tasarım kuralı, istisnaların e-posta takibine dönüşmesini önler:

• Her istisnayı işlem yapabilecek bir sorumluya ve yokluklar için bir yedek sorumluya yönlendirin.
• Son tarih geçmeden önce sorumluyu uyarın, yanıt gelmezse eskale edin.
• İnceleyicilerin bir öğeyi reddetmeden, geri göndermeden veya onaylamadan önce neden seçmesini ve kısa bir not eklemesini zorunlu kılın.
• Birisi düzeltme istediğinde ilk başvuruyu, ekleri ve önceki yorumları koruyun.
• İstisnanın ne zaman başladığını, kimin yönettiğini ve ne zaman sona erdiğini kaydedin.

Sessiz son tarihler özel bir sorun yaratır. Herkes görevin başkasının sorumluluğunda olduğunu düşünürken görev günlerce dokunulmadan kalabilir. Geciken görev yönetimi kuralı önce atanan kişiyi, belirlenen sürenin ardından da belirli bir yöneticiyi bilgilendirmelidir. 24 saat sonra bir hatırlatma, 48 saat sonra eskalasyon gibi ölçülebilir bir kural kullanın.

İnceleme adımlarının da sınırları olmalıdır. İnceleyiciler nedenini kaydetmeden herhangi bir karar verebiliyorsa manuel inceleme sürecini geliştirmek zorlaşır. Zamanla ekipler aynı başvurunun maliyet, politika, eksik kanıt veya yanlış form alanı nedeniyle tekrar tekrar geri gönderildiğini anlayamayabilir.

Düzeltme için geri döndüğünde başvuruyu koruyun. Başvuru sahibi ret nedenini gönderilen bilgilerin yanında görmeli, yalnızca etkilenen alanları güncellemeli ve aynı kaydı yeniden göndermelidir. Yeni bir başvuru başlatmak bağlamı kaldırır, işi çoğaltır ve reddedilen başvuru iş akışına ilişkin raporlamayı zayıflatır.

İyi iş akışı istisna yönetimi, birinin hızlıca anlayabileceği bir kayıt bırakır. Neyin başarısız olduğunu, sonraki işlemin sorumlusunu ve başvurunun neden yön değiştirdiğini gösterir.

Hızlı kontroller ve sonraki adımlar

Bir iş akışı istisnası başvuruyu adı olmayan bir kuyrukta bırakmamalıdır. Her istisna yolu için onu başlatan olayı, sorumlu kişiyi ve onu sona erdiren işlemi belirleyin. Böylece iş akışı istisnaları son dakika araştırması olmaktan çıkar ve rutin işe dönüşür.

Bir iş akışını yayımlamadan önce her istisnanın boş bir gerekli alan, ret veya kaçırılan son tarih gibi net bir tetikleyicisi olduğunu kontrol edin. Sonraki işlem için tek bir sorumlu atayın, başvuruyu birkaç kişi görebilse bile bu sorumlu belirli olsun. Mesajlar ne olduğunu, alıcının ne yapması gerektiğini ve bunu ne zaman yapacağını söylemelidir. Güncel durumu ve karar geçmişini işlem yapması gereken çalışanlara görünür tutun, geciken işleri genel bir gelen kutusu yerine belirli bir kişiye veya role eskale edin.

Yolları gerçekçi durumlarla test edin. Eksik ek içeren bir başvuru gönderin. Bir başvuruyu gerekçesiyle reddedin. Bir onayı son tarihini geçene kadar bekletin. Ardından doğru kişinin işe yarar bir mesaj alıp almadığını ve arka plan bilgisi istemeden görevi tamamlayıp tamamlayamadığını kontrol edin.

Reddedilen bir başvuru iş akışının başvuru sahibine geri dönüş yolu da olmalıdır. İlk başvuruyu, ret nedenini ve inceleyici notlarını birlikte tutun. Başvuru sahibi sorunu düzeltip yeniden gönderebilmeli, önceki kararı kaybettiren yinelenen bir kayıt oluşturmamalıdır.

Geciken görev yönetimi için her son tarih kaçırıldığında ne olacağını belirleyin. İlk hatırlatma görev sahibine gidebilir. Daha sonraki eskalasyon yöneticisine veya yedek inceleyiciye gönderilebilir. Hatırlatmaları sonsuza kadar göndermeyin. Birinin görevi tamamlaması, yeniden ataması, süresini uzatması veya kapatması gereken bir nokta belirleyin.

AppMaster, ekiplerin bu yolları görsel iş süreçleriyle oluşturmasına yardımcı olur. Ekipler durum değişikliklerini, son tarihleri, bildirimleri, onayları ve manuel incelemeyi iş akışı mantığını elle yazmadan modelleyebilir. Yüksek hacimli bir süreçle başlayın, istisna durumlarını onu kullanan kişilerle test edin ve gerçek işler bir boşluk ortaya çıkardığında yolları ayarlayın.

İlk birkaç haftadan sonra iş akışını gözden geçirin. En sık gerçekleşen istisnaları sayın ve manuel incelemelerdeki notları okuyun. Aynı eksik ayrıntı tekrar tekrar gecikmeye neden oluyorsa başvuru formunu değiştirin veya daha erken bir kontrol ekleyin. Başlangıçta yapılan küçük düzeltmeler istisnaların daha sonra birikmesini önler.