06 Şub 2026·5 dk
Manuel onay iş akışı yazılımı: önce süreci haritalayın
Manuel onay iş akışı yazılımı, hatırlatmalar veya kurallar eklemeden önce durumları, sahipleri, son tarihleri ve istisnaları tanımladığınızda en iyi şekilde çalışır.
Manuel onay iş akışı yazılımı, hatırlatmalar veya kurallar eklemeden önce durumları, sahipleri, son tarihleri ve istisnaları tanımladığınızda en iyi şekilde çalışı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.
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:
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.
İ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:
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.
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:
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.
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:
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.
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:
İ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ı.
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:
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.
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:
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.
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:
İ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.
Onaylar bir veya iki kişiden fazlasını içerdiğinde, son tarihlere bağlı olduğunda veya sıkça takip gerektirdiğinde e-postadan vazgeçin. İnsanlar sürekli durum soruyorsa, yanlış sürümü onaylıyorsa veya istekler gelen kutularında kayboluyorsa, e-posta zaten zaman ve risk kaybettiriyor demektir.
Bugün süreç gerçekten nasıl işliyorsa onu haritalayın. Birkaç yakın tarihli onay e-postasını inceleyin ve isteklerin nasıl başladığını, kimlerin incelediğini, hangi bilgilerin gerektiğini, nerede döndüğünü ve nasıl sona erdiğini yazın. Bu, gelen kutusu karmaşasını yeni bir araçta kopyalamak yerine temiz bir süreç oluşturmanızı sağlar.
İnsanların bir bakışta anlayacağı küçük bir setle başlayın. Birçok durumda dört veya beş durum yeterlidir; örneğin Taslak, Onay bekleniyor, Onaylandı, Reddedildi ve Değişiklik gerekli. İki etiket neredeyse aynı hissediyorsa, birini çıkarın.
Genellikle hayır. Durum, isteğin hangi aşamada olduğunu göstermeli, kimin elinde olduğunu değil. Waiting for approval gibi bir etiket, With finance'den daha açıktır çünkü ilk etiket durumun kendisini bildirir; ikincisi durumu ve sahibi karıştırır.
Her adım için bir ana sahip ve bir yedek atayın. Ana onaycı yoksa, yedek bir iş kuralıyla devralmalı; örneğin bir iş günü sonra veya yokluğun bilinmesiyle. Bu, isteklerin limbo'da kalmasını engeller.
Her aşama için bir son tarih belirleyin; tek bir genel tarih yeterli değil. Zamanlayıcı genellikle isteğin o aşamaya girdiği anda başlamalıdır. Süre kaçırılırsa bir hatırlatma gönderin ve sonra yedek veya ekip liderine yükseltin gibi bir sonraki adımı önceden tanımlayın.
Onları Needs more info veya Waiting for requester gibi net bir durumla geri gönderin. İstek sahibini tekrar aktif sahip yapın ve eksik bilgiler eklenene kadar süreyi duraklatın. Bu, yan e-postalarla çözmeye çalışmaktan daha temizdir.
Hayır, acil isteklerin ayrı ama dar bir yolu olmalı. Her şeyi acil yapma hakkı olursa bu etiket anlamsızlaşır. Müşteri etkisi, uyumluluk son tarihleri veya diğer zaman kritik durumlar gibi net vakalar için saklayın.
En yaygın hata, e-posta sürecini olduğu gibi kopyalamaktır. Diğer sorunlar arasında çok fazla durum, çok fazla onaycı, belirsiz sahiplik ve başlatıldıktan sonra tanımlanan istisna kuralları yer alır. İlk etapta basit başlayın ve zayıf adımları düzeltin.
Bir ekip ve bir istek türüyle küçük bir pilot uygulama yapın. İnsanların hâlâ e-posta veya sohbet kullanıp kullanmadığını izleyin, sonra durumları, devralmaları ve son tarihleri sıkılaştırın. Kısa bir doğrulama döngüsüyle 5–10 isteği sonra iki hafta sonra tekrar gözden geçirmek işe yarar. İçe dönük bir onay aracı prototiplemek isterseniz, Koder.ai gibi araçlar düz dille tanımlanmış süreci çalışan bir araca çevirmede yardımcı olabilir.