Manuel onay iş akışı yazılımı: önce süreci haritalayın

Neden e-posta onayları karışır

E-posta, süreç küçük ve gayri resmi olduğunda onaylar için işe yarar. Bir kişi isteği gönderir, başka bir kişi yanıtlar ve iş ilerler. Ancak daha fazla kişi işin içine girince çatlaklar hızla görünür.

İlk sorun görünürlük. Onay istekleri haber bültenleri, takvim davetleri ve günlük mesajların yanında durur. Birisi isteği daha sonra incelemeyi planlar, sonra o mesaj gelen kutusunda aşağı düşer ve kaybolur.

Bir sonraki sorun sürüm karışıklığıdır. Bir kişi orijinal sohbete yanıt verir, başka biri düzenlenmiş eki iletir ve bir başkası eski bir kopyayı onaylar. Birkaç tur sonra kim hangi dosyanın, fiyatın veya ifadenin güncel olduğundan tam emin değildir.

Sahiplik de bulanıklaşır. Bir istek finans, hukuk ve bir ekip liderinden girdi gerektiriyorsa, iş durduğunda kim sorumludur? E-postada bu cevap genellikle belirsizdir. İnsanlar başkasının hallettiğini varsayar, bu yüzden hiçbir şey yapılmaz.

Birisi ofiste değilse veya yol tutara göre, risk veya müşteri türüne göre değişiyorsa işler daha da kötüleşir. Bu istisnalar genellikle insanların kafasında yaşar, paylaşılan bir süreçte değil. Bu da onay yolunu öngörmeyi zorlaştırır ve takip etmeyi daha da zorlaştırır.

Maliyet birkaç yavaş yanıttan daha büyüktür. Gecikmeler satın almaları, sözleşmeleri, lansmanları, işe alım kararlarını ve müşteri işlerini bekletebilir. Ekipler işleri yapmak yerine güncellemeleri kovalar.

Basit bir örnek sorunu gösterir. Bir satış indirim isteği e-posta ile yöneticisine gider, sonra finansa iletilir. Finans revize bir rakam ister, ama temsilci sadece bir sohbete güncelleme ekler. Yönetici önceki sürümü onaylar, finans onayı bekler ve müşteri iki gün boyunca hiçbir haber almaz.

Bu yüzden ekipler manuel onay iş akışı yazılımlarına bakmaya başlar. Gerçek sorun yalnızca hız değil. E-posta, bir şey bozulana kadar durumları, sahipliği, son tarihleri ve istisnaları gizler.

Ayarlarla oynamadan önce gerçek süreci haritalayın

Yazılıma herhangi bir şey kurmadan önce onay sürecinin bugün gerçekten nasıl işlediğini yazın. Bu adımı atlarsanız, muhtemelen e-posta karışıklığını yeni bir araca kopyalarsınız, düzeltilmiş bir sürece değil.

Küçük başlayın. Her onay akışını birden taşımayın. Sık gerçekleşen, gecikmelere neden olan veya en çok takip gerektiren bir süreci seçin; örneğin satın alma talepleri, içerik onayı, indirim onayları veya erişim istekleri.

Sonra birkaç gerçek örneğe bakın. Üç ila beş yakın tarihli e-posta dizisi genellikle deseni göstermek için yeterlidir. Gerçek vakaları kullanın, hafızayı değil. İnsanlar küçük devralmaları, yan cevapları ve son dakika istisnalarını unuturlar.

Bu örnekleri incelerken temel noktaları sade bir dille yakalayın:

• isteğin nasıl başladığı
• ilk kim tarafından incelendiği
• sonra kimlerin onayladığı
• nerede durduğu veya geri döndüğü
• nasıl sona erdiği

Ayrıca her adımın hangi bilgilere ihtiyaç duyduğunu not edin. Bir yönetici karar vermeden önce bütçe tutarını, satıcı adını ve son teslim tarihini bilmek isteyebilir. Bu bilgiler sık sık eksikse, gecikme gerçekten bir onay sorunu değil, istek kalitesi sorunudur.

Son tarihleri de haritaya ekleyin. Her adımın kaç gün veya iş günü alması gerektiğini yazın, kim cevap vermezse ne olacağını ve acil isteklerin farklı bir yol izleyip izlemediğini belirtin. İstisna kurallarını da listeleyin. Belki belirli bir tutarın üzerindeki onaylar finans incelemesi gerektirir. Belki ana sahibi yoksa yedek bir onaycı devreye girer.

Tüm süreci insanların zaten kullandığı kelimelerle tek sayfada toplayın. "Finans tutarı kontrol eder" veya "Yönetici eksik ayrıntı ister" gibi yazın; soyut ve sistemsel görünen ifadeler kullanmayın. Amaç insanların tanıyacağı bir süreç, parlak görünen bir diyagram değil.

İşi yapanlar "Evet, bu gerçekten böyle oluyor" dediğinde haritanız hazır demektir.

İnsanların hızlıca anlayacağı durumlar seçin

İyi bir durum listesi basit bir testi geçmelidir: iki kişi aynı isteği okuduğunda bir sonraki adım hakkında aynı sonuca varmalıdır.

Bu yüzden manuel onay iş akışı yazılımı, kısa ve net bir durum listesiyle en iyi şekilde çalışır. Çoğu ekibin on etikete ihtiyacı yoktur. Şu an istek hangi durumda olduğunu söyleyen birkaç etikete ihtiyaçları vardır.

Pratik bir başlangıç şöyle görünebilir:

• Taslak
• Onay bekleniyor
• Onaylandı
• Reddedildi
• Değişiklik gerekli

Her durum tek bir anlama gelmelidir. Onay bekleniyor isteğin hazır olduğu ve birinin incelemesi gerektiği anlamına gelir. Değişiklik gerekli henüz onaylanmadığı, ancak güncellenip geri gelebileceği anlamına gelir. Reddedildi isteğin durduğu anlamına gelir, yeniden açılmasına izin veren bir kural yoksa işlem sona erer.

Karışıklık, ekiplerin Beklemede, İncelemede, İnceleme altında ve Onay bekleniyor gibi neredeyse eş anlamlı etiketler oluşturduğunda başlar. Sisteme göre bunlar farklıdır; insanlara göre çoğu zaman aynı şeyi ifade eder. Bu da dağınık raporlama, belirsiz devralmalar ve gereksiz sorulara yol açar.

Bir durum uzun açıklama gerektiriyorsa, yeniden adlandırın. İyi etiketler bir listede, panoda veya mobil ekranda kolayca taranabilir. İnsanlar kaydı açmadan anlayabilmelidir.

Durumu sahiplikten ayırmak da akıllıca olur. Onay bekleniyor genellikle Finans elinde gibi bir etiketten daha açıktır. İlk etiket isteğin durumunu bildirir; ikincisi hem durum hem de o anki kişi bilgisini karıştırır.

İşe yarayan en küçük küme ile başlayın. Gerektiğinde gerçek bir sorun çözecekse daha sonra durum ekleyebilirsiniz.

Sahipleri ve devralmaları net belirleyin

Bir adım "ekip"e ait olarak bırakıldığında iş akışı hızla bozulur. Her aşamanın net bir sahibi olmalı. O kişi başkalarından girdi isteyebilir, ama isteği ilerletmekten sorumlu tek bir ad veya atanmış rol olmalı.

Bu, e-posta onay zincirinden yazılıma geçtiğinizde daha da önem kazanır. E-postada insanlar alışkanlıklara güvenir. Birisi bir iletiyi fark eder, iletir veya bir sonraki onaycıya hatırlatır. Yazılım bu tür tahmine dayalı davranışlara güvenemez.

Her adım için dört basit soruyu yanıtlayın:

• Şu an kimin sorumluluğunda?
• O kişi yoksa kim devreye girer?
• Onay veya reddetme sonrası sıra kimde?
• Kim yeniden açabilir veya iptal edebilir?

Devralmalar da en az bunun kadar net olmalı. Bir yönetici onaylar ve sonra finans incelerse, bunu iş akışında doğrudan belirtin. Finansa gönder gibi belirsiz bırakmayın; sistemin hangi kişi veya rolün alacağını bilmesi gerekir.

Basit bir ekipman talebi örneği düşünün. Talep çalışanın yöneticisiyle başlar. Maliyet belirli bir tutarın üzerindeyse finans aşamasına geçer. Finans sahibi yoksa bir iş günü sonra yedek bir kontrolör devreye girer. İstekçi bir hata yaptıysa yalnızca istek sahibi ve ilk onaycı yeniden açabilir. İstek artık gerekli değilse yalnızca istek sahibi veya departman yöneticisi iptal edebilir.

Bu kurallar katı gibi gelebilir, ama olağan karışıklıkları önler: takılan istekler, çift incelemeler ve herkesin başkasının sorumlu olduğunu varsaydığı uzun boşluklar.

Son tarihleri ve istisna kurallarını ekleyin

Bir iş akışı, yalnızca tüm istek için tek bir son tarih olduğunda takılır. Her aşamanın kendi süresi olmalı ki ekipler zamanın nerede gerçekten kaybedildiğini görebilsin.

Örneğin bir yönetici incelemesine bir iş günü, finansa iki gün ve hukuka üç gün verilebilir. Çoğu durumda saat/süre, isteğin o duruma girdiği anda başlamalıdır; ilk e-postanın gönderildiği zaman değil. Bu, geciken işleri tespit etmeyi çok daha kolaylaştırır.

Otomasyon yapmadan önce dört temel şeyi tanımlayın:

• her aşama için bir son tarih
• bir tarih kaçırıldığında ne yapılacağı
• acil durumlar için ayrı bir yol
• eksik bilgiler, revizyon ve istisnalar için kurallar

Bir tarih kaçırıldığında bir sonraki adımı önceden belirleyin. Basit bir kural genellikle en iyi sonucu verir: bir hatırlatma gönderin, sonra hiçbir şey değişmezse yedeğe veya ekip liderine yükseltin. Gecikmiş işler aynı durumda hareketsiz bırakılmasın.

Acil isteklerin kendi yolu olmalı, ama bunu dar tutun. Her şey "acil" olarak işaretlenebilirse, etiketin değeri kalmaz. Müşteri odaklı sorunlar veya uyumluluk son tarihleri gibi birkaç net vaka için sınırlandırın.

İstisna kuralları da en az diğerleri kadar önemlidir. Bir istek bilgi eksikliği nedeniyle duruyorsa, onu Waiting for requester gibi bir duruma taşıyın ve süreyi duraklatın. Reddedildiyse ama düzeltilebiliyorsa kapatmak yerine tekrar işleme gönderin. Normal politikanın dışında kalıyorsa, kişilerin e-posta ile doğaçlama yapmasına izin vermeyin; isimlendirilmiş bir istisna onaycısına yönlendirin.

Basit bir satın alma talebi bunun neden önemli olduğunu gösterir. Finans isteği alır ama satıcı teklifi eksiktir. Kural yoksa finansın süresi dolar ve herkes kafası karışır. Kural varsa istek Eksik bilgi durumuna geçer, istek sahibi aktif sahip olur ve teklif eklenene kadar süre durur.

Pratikte basit bir akış

Yeni bir dizüstü bilgisayar için bir satın alma talebini hayal edin. Bir çalışan öğeyi, maliyeti, sebebi ve gereken tarihi içeren bir form doldurur. İş akışının karmaşık olması gerekmez.

Temel bir versiyon şu durumları kullanabilir:

• Gönderildi
• Ek bilgi gerekiyor
• Yönetici onayladı
• Finans onayladı
• Tamamlandı

İstek Gönderildi olarak başlar ve yöneticinin önüne gider. Eğer çalışan sadece yeni işe alınan için dizüstü yazıp bütçe kodunu boş bıraktıysa, yönetici onaylamamalı ve problemi yan bir e-postayla anlatmamalıdır. Daha temiz olanı durumu Ek bilgi gerekiyor olarak değiştirmek ve geri göndermektir. Çalışan tekrar aktif sahip olur, eksik bilgiyi ekler ve yeniden gönderir.

İstek tamamlandığında yönetici inceler ve durumu Yönetici onayladı olarak değiştirir. Sahiplik sonra finansa geçer. Finans bütçeyi, satıcı kurallarını ve harcama limitini kontrol eder. Her şey uygunsa durum Finans onayladı olur.

Şimdi gerçek bir istisna ekleyin. Finans onaylayıcısı üç gün hastayken yok. O kural planlanmamışsa istek olduğu yerde bekler. Daha iyi bir düzen yedek sahibin önceden adlandırılmasını sağlar. Tarih geçtiğinde veya yokluk bilindiğinde istek yedeğe geçer, limbo'da beklemez.

Finans onayladığında istek Tamamlandı olur. Ek bir satın alma adımı daha sonra istenirse ekleyebilirsiniz. İlk sürüm basit kalmalı.

Yazılıma taşırken yapılan yaygın hatalar

En büyük hata e-posta sürecini birebir kopyalamaktır. Bu güvenli hissettirir ama genellikle eski sorunları yeni bir sisteme kilitler.

E-posta zayıf noktaları gizler. İnsanlar yan sohbetlerde açıklama yapar, güncellemeleri manuel takip eder ve net kurallar olmadan onay verir. Aynı süreç yazılıma değiştirilirse, karışıklık yok olmaz; sadece görünür hale gelir.

Diğer yaygın hata çok detay eklemektir. Ekipler her küçük adımı görünür kılmak isteyince uzun durum listeleri oluşturur. Uygulamada bu süreci takip etmeyi zorlaştırır. Bir istek beklemede inceleme, inceleme altında, yorum bekliyor, geri gönderildi, yeniden gönderildi ve onay için hazır gibi etiketlenebiliyorsa, çoğu kişi hangi etiketi kullanacağını bilemez.

Aynı durum onaycılarda da olur. Beş kişi "olursa" diye eklenirse, iş yavaşlar ve kimse tam sorumluluk hissetmez.

Hızlıca ortaya çıkan birkaç uyarı işareti:

• insanlar sürekli kimin sorumlu olduğunu soruyor
• iki durum aynı şeyi ifade ediyormuş gibi duruyor
• onaylar hâlâ ne olduğunu açıklamak için yan e-postalar gerektiriyor
• birkaç kişi işlem yapabiliyor ama kimse açıkça hesap verebilir değil

Ekipler ayrıca temel kurallar yerleşmeden hatırlatmalar ve yükseltmeler eklemeye başlar. Hatırlatmalar yalnızca sistem zaten neyin bekleme sayıldığını, kimin geç kaldığını ve sonra ne olacağını bildiğinde yardımcı olur. Kurallar belirsizse hatırlatmalar sadece gürültü yaratır.

Bir diğer hata istisnaları lansmandan sonra görmezden gelmektir. Gerçek onay zincirlerinin her zaman istisnaları vardır. Birisi hasta olur. Bir istek acildir. Form eksiktir. Reddedilen bir öğe düzenlenip geri gelir. Bu durumlar erken planlanmamışsa insanlar ilk olağandışı durumda yine e-postaya döner.

Gün birinci için tam yerine basit olan iyidir. Önce zayıf adımları düzeltin, durumları az tutun, her adım için bir sahip atayın ve otomasyonu eklemeden önce istisnaların nasıl işleyeceğini belirleyin.

Otomasyona geçmeden önce hızlı kontrol

Yönlendirme kurallarını, hatırlatmaları veya yükseltmeleri açmadan önce sürecin e-posta olmadan çalışacak kadar net olup olmadığını kontrol edin.

Yararlı bir test basittir: standart bir istek çoğu zaman tek ve net bir yoldan baştan sona ilerleyebiliyor mu? Eğer hayırsa önce yolu düzeltin.

Şu sorulardan geçin:

• Normal bir isteğin standart bir rotası var mı?
• Durumlar düz dilde yazıldı mı?
• Her adımın bir ana sahibi ve bir yedeği var mı?
• Son tarihler iş akışı içinde görünür mü?
• İstisna vakaları otomasyona başlamadan önce yazıldı mı?

Bu sorulara net yanıt veremiyorsanız durun. Temiz etiketler, net sahiplik ve yazılı istisna kuralları akıllı otomasyondan daha fazla zaman kazandırır.

Bu yüzden birçok ekip süreci basit bir dokümanda veya beyaz tahtada eskiz yapar, sonra araca taşır. İç kullanım için bir onay uygulaması oluşturuyorsanız, Koder.ai düz dilde yazılmış bir iş akışını uzun bir geliştirme döngüsü olmadan çalışan bir yazılıma dönüştürmek için pratik bir yol olabilir.

Küçük, güvenli bir pilot ile devreye alın

Yeni süreci tüm şirkete birden yaymayın. Bir ekip ve bir istek türüyle başlayın; örneğin satın alma onayları veya içerik onayı. Küçük bir pilot, sorunları yayılmadan önce tespit etmeyi kolaylaştırır.

İşte manuel onay iş akışı yazılımının güven kazanıp kazanmama anı. Eğer insanlar gerçek istekleri e-postadan daha az karışıklıkla tamamlayabiliyorsa benimseme çok daha kolay olur.

Test etmek için yeterince sık gerçekleşen ama bir hafta sonra değişmesi riskli olmayan bir akış seçin. Pilot gruba amacın mükemmellik değil aksak noktaları küçükken bulmak olduğunu açıkça söyleyin.

Pilot sırasında insanların sistemden ayrıldığı ve işi elle yaptığı anları izleyin. Bu genellikle eksik bir şey olduğunun en net işaretidir.

Şunlara dikkat edin:

• sahipliği net olmadığı için takılan istekler
• insanların farklı yorumladığı durum isimleri
• gerçek işleğe uymayan tarih kuralları
• hâlâ e-posta veya sohbete kayan istisnalar

İlk birkaç gerçek vaka sonra temel kuralları sıkılaştırın. Belirsiz devralmaları düzeltin, durum adlarını sadeleştirin ve tarihleri gerçeğe göre ayarlayın. Raporlar, yükseltmeler ve ekstra otomasyon üzerine, çekirdek akış temiz çalışana dek bekleyin.

Basit bir gözden geçirme ritmi yardımcı olur. İlk 5–10 isteğin ardından süreci kontrol edin, sonra iki hafta sonra tekrar edin. Tek bir düz soru sorun: insanlar hâlâ nerede geçici çözüme ihtiyaç duydular?

Hızla bir iç onay aracı test etmek isterseniz, Koder.ai sohbetten prototip oluşturup çalışan bir uygulamaya dönüştürmede kullanışlı olabilir. Bu, daha geniş bir yayına geçmeden önce süreci doğrulamak için sıklıkla yeterlidir.

Güvenli bir dağıtım genellikle bilerek sıkıcıdır. Bu iyi bir işarettir. İnsanlar ne olacağını, kimin sorumlu olduğunu ve normal yol uymadığında ne yapmaları gerektiğini bilmelidir.