Ölçeklendikçe sağlam kalan onay iş akışı taslağı

Ekip büyüdükçe onay iş akışları neden bozulur

Onay iş akışları nadiren insanların umursamamasından başarısız olur. Başarısız olmalarının nedeni süreçlerin küçük bir ekip düşünülerek, herkesin yazılı olmayan kuralları bildiği varsayılarak tasarlanmasıdır. Ekip büyüdüğünde o ortak hafıza kaybolur.

Büyüdüğünde bir iş akışı sorgulandığında genellikle şöyle görünür: talepler kimsenin sonraki adımın kime ait olduğunu bilmemesi yüzünden beklemeye girer; onaylar sohbet veya e-postada verilir ve güvenilir bir denetim izi olmaz; insanlar son tarihleri yakalamak için süreci atlar ve finans veya operasyonlar sonra düzeltmek zorunda kalır; aynı istek iki kez (ya da hiç) onaylanır çünkü en son versiyon ve bağlam belirsizdir.

Sorunun kökü, kuralların insanların kafasında yaşaması, iş akışında olmamasıdır. Birisi "500$ altındaki pazarlama araçları ekip lideri tarafından onaylanabilir, yeni tedarikçi değilse" bilir ama sistem bilmez. O kişi yokken her şey yavaşlar.

Büyüme ayrıca "onay" kelimesinin anlamını değiştirir. Daha fazla talep türü, daha fazla onaycı ve daha fazla istisna olur. Bir satın alma talebi bir indirim talebi veya erişim talebiyle aynı değildir. Her birinin farklı riskleri vardır ve farklı bilgi ve kanıt gerekir.

Hacim iki katına çıktığında bile ayakta kalan bir iş akışı birkaç temel şeyi korumalıdır:

• Netlik: herkes mevcut adımı ve bir sonraki eylemin kimde olduğunu görebilmeli.
• Hız: sık karşılaşılan vakalar "bilen tek kişi"yi beklemeden hızlı ilerlemeli.
• Sorumluluk: kararlar ve yorumlar kaydedilip aranabilir olmalı.
• Öngörülebilirlik: son tarihler, SLA'lar ve eskalasyonlar elle kovalanmak yerine yerleşik olmalı.

Bu genellikle rastgele mesajlaşmadan, adımların, koşulların ve sahipliğin görünür ve tekrar edilebilir olduğu açık bir sürece geçmek anlamına gelir.

Kapsam ve tamamlanma tanımından başlayın

Birçok iş akışı, kimsenin talebin ne olduğunu veya ne zaman bitmiş sayılacağını kabul etmemesi yüzünden başarısız olur. Bir şey çizmeye başlamadan önce sınırları ve bitiş çizgisini tanımlayın.

Talebi sade terimlerle tanımlayın. Kim gönderebilir? Hangi bilgiler eklenmelidir? İnceleme için hangi bilgiler yeterli sayılır? Form her yere "Yok" yazmaya izin veriyorsa, onaycılar ya her şeyi engeller ya da gözden geçirirken rastgele onaylarlar.

Onay dışında sonuçları tanımlayın. Bir onaycı değişiklik istendiğinde, talep artık gerekli olmadığında veya reddedilmesi gerektiğinde ne olacağına karar verin. Bu seçimler sonraki her adımı şekillendirir.

Sahipliği erken atayın. Bir süreç sahibi kurallar ve güncellemeler için sorumludur. Onaycılar kararlar için sorumludur, tasarım için değil. Finans, güvenlik veya hukuk gibi gözden geçirenler tavsiye verebilir ama her zaman nihai kararı sahiplenmeyebilir.

Kapsam etrafında sert bir sınır çizin. "500$ üzeri tüm harcamalar" nettir. "Satın almalar" net değildir. Ayrıca kapsam dışı olanları (ör. seyahat iadeleri veya başka yerde ele alınan yenilemeler) listeleyin ki iş akışı her şeye açık bir ağ olmayan bir şeye dönüşmesin.

Oluşturmadan önce kısa bir gereksinim kontrolü yapmak sonradan yeniden iş yapmaktan kurtarır:

• Kim gönderebilir ve kim bir talebi görüntüleyebilir?\n- Hangi alanlar zorunlu ve hangi değerler kabul edilebilir?\n- Hangi sonuçlar var (onayla, reddet, değişiklik iste, iptal) ve her birini kim tetikleyebilir?\n- Süreç sahibi kimdir ve hangi roller onaylıyor?\n- Açıkça kapsam dışı olan nedir?

Basit bir örnek: bir dizüstü talebi sadece onaylanıp tedarike devredildiğinde, reddedildiğinde bir nedenle kapandığında veya eksik bilgilerin spesifik bir listesiyle geri gönderildiğinde "tamamlanmış" sayılır. Bu tanım yoksa aynı talep günlerce belirgin bir bitiş noktası olmadan dolanabilir.

Yeniden kullanabileceğiniz basit bir onay iskeleti

Küçük, tekrarlanabilir bir iskeletle başlayın ve dikkatle genişletin. Çoğu ölçeklendirme sorunu sorumlulukların karışmasından, "sadece bir istisna daha" eklemekten ve bir sonraki adımın ne olduğunu kaybetmekten kaynaklanır.

Birçok iş için yeniden kullanılabilir iskelet:

• Giriş (Intake): biri bir talep gönderir.
• Doğrulama (Validation): eksiksizlik ve doğruluk için temel kontroller.
• İnceleme (Review): bağlam, sorular ve destekleyici notlar toplanır.
• Karar (Decision): onayla veya reddet.
• Gerçekleştirme (Fulfillment): onaylanan işi yapın.
• Kayıt (Recordkeeping): kapatın ve olanları arşivleyin.

Kontrolleri onaylardan ayrı tutun. Kontroller "bu geçerli ve eksiksiz mi?" sorusunu yanıtlar. Onaylar "buna izin verelim mi?" sorusunu yanıtlar. Doğrulama genellikle operasyonlar veya talep sahibiyle ilişkilidir. Onaylar bütçe, risk veya politika için sorumlu rollerde olur.

Ayrıca adımları küçük tutun: adım başına bir karar hedefleyin. Tek bir adım birinden bütçeyi, uyumluluğu ve teknik fizibiliteyi değerlendirmesini istiyorsa, o adım tıkanır veya bir toplantıya dönüşür.

Son olarak, "değişiklik iste" yolunu doğru yere dönecek şekilde ekleyin, başlangıca geri değil. Finans eksik bir teklif isterse, talep sahibine (veya doğrulamaya) geri yönlendirilsin, sonra finans incelemesine yeniden dönsün; hukuk ve yönetimi yeniden yapmak zorunda kalmasın.

Okunaklı kalan koşullu yönlendirme kuralları

Koşullu yönlendirme, iş akışlarının genellikle labirente dönüştüğü yerdir. Çözüm büyük ölçüde disiplin: az sayıda girdi seçin, kuralları sade İngilizce/Türkçe cümlelerle yazın ve ardından tam olarak yazıldığı gibi uygulayın.

İnsanların zaten anlayıp tutarlı şekilde doldurabileceği yönlendirme girdilerine bağlı kalın: tutar, departman veya maliyet merkezi, risk seviyesi, tedarikçi türü (mevcut vs ilk defa) ve bölge gibi.

Her kuralı bir satırlık cümle olarak yazın. Eğer bir kural bir satıra sığmıyorsa, genellikle çok fazlasını yapmaya çalışıyordur.

Okunaklı kalan örnekler:

• "Tutar 1.000$ altındaysa ekip liderine yönlendir. 1.000$ veya üzeriyse Finans'a yönlendir."\n- "Tedarikçi ilk defa ise, Finans'tan önce Vendor Management ekle."\n- "Risk yüksekse, departmandan bağımsız olarak Güvenlik incelemesi ekle."\n Özel durumlar kaçınılmazdır; bunları adlandırın ve izole edin. "Acil" yaygın bir örnektir. Acil'in ne anlama geldiğini (24 saat içinde teslim tarihi, müşteri kesintisi vb.) tanımlayın, sonra daha az adımlı ama daha sıkı not isteyen hızlı bir yol açın.

Birden fazla kural uygulanıyorsa, çakışmaların nasıl çözüleceğine baştan karar verin. Yaygın desenler öncelik sırası (risk tutarın önüne geçer), kvorum (3'ten 2'si yeterli), herkes onaylamalı (seri veya paralel) veya bir tıraş rolü gibi olabilir.

Yönlendirmeyi iki dakikalık bir konuşmada açıklayabiliyorsanız, ekip ikiye katlandığında okunaklı kalmasını sağlayabilirsiniz.

Sürekli elle takip gerektirmeyen SLA'lar ve eskalasyonlar

SLA'lar, "genelde çalışan" bir süreçten, hacim arttığında da öngörülebilir kalan bir sürece dönüşmeyi sağlar. Amaç basit: kararlar zamanında verilsin ve kimse kuyruğu gözlemlemek zorunda kalmasın.

Çoğu ekip için birden fazla saat gerekir:

• İlk yanıta kadar geçen süre (onayla, reddet, değişiklik iste veya teyit)
• Nihai karara kadar geçen süre (onaylandı veya reddedildi)
• Gerçekleştirmeye kadar geçen süre (onaylanan takip görevi tamamlandı)

Her şey için tek bir genel zamanlayıcıdan kaçının. Düşük riskli bir talep karar için 24 saate izin verebilirken, yüksek tutarlı bir talep daha sıkı eşikler gerektirir. SLA'ları talep türüne, tutara veya riske bağlayın ki kurallar adil gelsin.

Eskalasyon bir merdiven olmalı, beklenmedik bir yeniden atama değil. Basit bir desen:

• Mevcut onaycıya hatırlatma\n- Onaycının yöneticisine (veya vekiline) eskalasyon\n- Gerekirse bir yedek onaycı grubuna yeniden atama\n- Talebe yeni durumu ve beklenen sonraki süreyi bildirme

Sonsuz tartışmaları önleyen bir detay: saatin ne zaman durduğunu tanımlayın. Bir talep bilgi için geri gönderildiyse, SLA talep sahibinin yanıtlayana kadar durmalı. Harici evrak bekleniyorsa, "beklemede" gerçek bir durum olmalı, sadece bir yorum değil.

İleride ihtiyaç duyacağınız durumlar, denetim izi ve izinler

Ölçeklenebilir bir iş akışı yalnızca adımlar ve koşullar değil; net durumlar, güvenilir bir denetim izi ve organizasyonun çalışma şekline uygun izinler gerektirir. Bunları atlarsanız süreç ilk gün iyi görünür, otuzuncu günde acı verici olur.

Herkesin anlayacağı durum etiketleriyle başlayın. İş akışları arasında tutarlı tutun: Taslak (Draft), Beklemede (Pending), Onaylandı (Approved), Reddedildi (Rejected). Detay gerekiyorsa her takım için yeni üst düzey durumlar icat etmek yerine "Beklemede: Finans" gibi alt durum ekleyin.

Denetim izinde ne kaydedeceğinizi tanımlayın. Bunu anlaşmazlıklar, uyumluluk ve hata ayıklama için geleceğe yönelik bir yatırım gibi görün:

• Kim işlem yaptı (kullanıcı, rol, ekip)\n- Hangi işlem yapıldı (gönder, onayla, reddet, değişiklik iste, üstten geçme)\n- Ne zaman oldu (zaman damgası, ilgiliyse son tarih)\n- Ne değişti (kritik alanlar için eski ve yeni değerler)\n- Neden oldu (yorum, reddetme nedeni, ek not)

Bildirimler insanların hafızasına değil durumlara bağlı olmalı. Bir talep Beklemede olduğunda sonraki onaycıyı ve talep sahibini bilgilendirin. Reddedildiğinde talep sahibine nedeniyle birlikte bildirim gönderin. Onaylandığında satın alma gibi aşağıya devralma işleri yapacak ekipleri haberdar edin.

İzinler, iş akışlarının baskı altında bozulduğu kısımdır. Erken karar verin:

• Talep sahibi: Taslak oluşturma ve düzenleme; her zaman görüntüleme\n- Onaycı: atandığında görüntüleme ve karar verme; yorum ekleme\n- Yönetici (Admin): her şeyi görüntüleme; veri sorunlarını düzeltme; acil durumlarda yönlendirme yapma\n- Finans/Hukuk/Güvenlik: dahil olduklarında görüntüleme; gerekli alanları ekleme\n- Denetçi: taleplere ve geçmişe salt okunur erişim

Pratik bir kural: bir talep Beklemede olduğunda kritik alanları (tutar, tedarikçi, kapsam) kilitleyin. Bir şey değişmesi gerekiyorsa, geçmiş temiz kalsın diye taleple ilgili açık bir "İstenen değişiklikler" notu ile Taslağa geri gönderin.

Adım adım: görsel iş süreci düzenleyicisinde oluşturun

Görsel bir düzenleyici, iş akışının tamamını bir karmaşa haline gelmeden önce görmenize yardımcı olur. Çalışır bir yol elde etmek için aşamalar halinde oluşturun, sonra kuralları ekleyin.

Akışı beş geçişte oluşturun

1. İskeleti haritalayın. Giriş, doğrulama, onaylar, gerçekleştirme ve kapatma için adımlar oluşturun. Açık bitiş durumları ekleyin: Onaylandı, Reddedildi, Geri gönderildi.

2. Giriş verilerini ve doğrulamayı ekleyin. Alanları (tutar, maliyet merkezi, tedarikçi, gerekli tarih) tanımlayın. Kötü talepler kuyruğa girmesin diye erken hızlı kontroller ekleyin.

3. Koşullu yönlendirmeyi ekleyin. Sadece onaycının değiştiği yerlerde dallanma yapın. Yaygın çakışmaları açıkça ele alın (ör. talep eden onaycıyla aynıysa yeniden yönlendir).

4. Zamanlayıcıları ve eskalasyonları ekleyin. Adım başına SLA'lar belirleyin. Bir zamanlayıcı süresi dolduğunda hatırlatmalar ve merdivene göre eskalasyonlar gönderin.

5. Gerçek vakalar ve uç durumlarla test edin. Bir dizi senaryoyu uçtan uca çalıştırın ve görevlerin, mesajların, durumların ve denetim kayıtlarının doğru olduğunu doğrulayın.

Yeniden kullanmak için küçük bir test seti

Her iş akışını değiştirdiğinizde tutarlı bir senaryo seti kullanın:

• Küçük tutar, normal rota\n- Yüksek tutar, finans gerektirir ve gecikirse eskalasyon olur\n- Eksik zorunlu alan (girişte engellenir)\n- Çakışma: talep eden ile onaycı aynı (doğru şekilde yeniden yönlendirir)\n- "Düzenleme için geri gönder" döngüsü (doğru adıma dönüp geçmişi korur)

Testten sonra belirsiz adları yeniden adlandırın ve geçici dalları kaldırın. Şimdi okumak zorsa, büyüme sırasında ayakta kalamaz.

Yaygın tuzaklar ve nasıl kaçınılır

Çoğu onay akışı öngörülebilir nedenlerle başarısız olur. İlk günden itibaren netlik ve istisnalar için tasarlayın.

Tuzak: ilerlemeyen iş için onaycı eklemek. Fazladan onaycı güvenli hissettirir ama ölü zaman ve kafa karışıklığı yaratır. Her adım için bir sorumlu onaycı tutun. Diğerleri sadece bilgi amaçlı bildirim alabilir.

Tuzak: sahibi olmayan eskalasyonlar. Bir SLA, kimsenin harekete geçme yetkisi yoksa anlamsızdır. Bir eskalasyon sahibi atayın (kişi değil rol) ve onların ne yapabileceğini tanımlayın: onayla, reddet, yeniden yönlendir veya değişiklik iste.

Tuzak: kuralların gelen kutularında ve sohbetlerde yaşaması. Yönlendirme mantığı "bir yerde" üzerinde anlaşılmış ama süreçte değilse, kararlar tutarsız olur. Koşulları doğrudan iş akışına koyun ve her kuralın neden var olduğunu kısa bir notla ekleyin.

Tuzak: değişiklik iste döngüsünün olmaması. İnceleyenler sadece onayla veya reddet seçeneğine sahipse, insanlar talepleri yeniden başlatır ve bağlam kaybolur. İhtiyaç duyulan değişiklikler için bir "Güncelleme gerekli" durumu ekleyin.

Tuzak: istisnalar insanların süreç dışına çıkmasına zorlaması. Acil öğeler ve eksik belgeler olur. Kontrollü bir istisna yolu ekleyin ve kimlerin neden istisna kullandığını kaydedin.

Yeniden kullanılabilir gereksinim toplama kontrol listesi

Her onay iş akışını oluşturmadan önce aynı girdileri toplayın. Bu akışı okunaklı tutar ve "özel durumları" sonradan acil düzeltmelere dönüştürmez.

İstek sahibi, onaycılar ve uyumluluk/raporlama sorumlusu ile kısa bir atölye (30–45 dakika) yapın. Aşağıyı yakalayın:

• Talep türleri ve gereken veriler: kategoriler, zorunlu alanlar ve gerekli kanıt (teklifler, ekran görüntüleri, belgeler).\n- Onaycı rolleri ve delege kuralları: rol bazında onay, izinli iken yedekler, delege kuralları ve çakışmaların nasıl ele alındığı.\n- Yönlendirme kuralları ve istisnalar: eşikler, koşullar, hızlı yollar ve kontrollü istisna yönetimi.\n- SLA'lar, durdurma kuralları ve eskalasyonlar: talep türü başına hedefler, saatin ne zaman durduğu ve her adımda eskalasyonun ne anlama geldiği.\n- Denetim, erişim ve çıktı: nelerin kaydedilmesi gerektiği, kimin neyi görebileceği ve onaydan sonra ne olduğu (bilet, PO talebi, erişim verildi, ödeme adımı).

Örnek taslak: koşullu yönlendirmeli satın alma onayları

Bu örnek, hacim ve ekip büyüdükçe bile açıklığı korur.

Senaryo ve yönlendirme kuralları

Bir talep sahibi miktar, maliyet merkezi, tedarikçi ve amaç ile bir satın alma gönderir. Yönlendirme birkaç basit eşik ve bir tedarikçi-risk kuralını izler:

• 1.000$ altı: departman sorumlusu\n- 1.000$–10.000$: önce departman sorumlusu, sonra Finans\n- 10.000$ üzeri: departman sorumlusu, Finans ve sonra yürütme onaycısı (CFO/COO)\n- Her tutar için: tedarikçi yeni, müşteri verisi işliyorsa veya yüksek risk listesinde ise Güvenlik incelemesi ekle

Tedarikçi-risk kuralını tutar kurallarından ayrı tutun ki tedarikçi kriterlerini akışın geri kalanına dokunmadan ayarlayabilesiniz.

SLA'lar, eskalasyon ve sonuçlar

Talep sahibini koruyan bir SLA belirleyin: ilk yanıt 1 iş günü içinde. "İlk yanıt" onay, reddetme veya değişiklik isteğini kapsar.

24 saat içinde hiçbir işlem olmazsa, onaycının yöneticisine eskalasyon yapın ve talebi bilgilendirin. İlk eskalasyonda işi hemen yeniden atamaktan kaçının—önce görünürlük ekleyin, gerekirse sonra yeniden atayın.

Sonuçları açıkça belirtin:

• Onayla: Onaylandı durumuna geçsin ve aşağıya devralma (PO talebi, bilet veya ödeme adımı) tetiklensin.\n- Reddet: bir neden gerektirsin ve Reddedildi olarak kapansın.\n- Değişiklik iste: yorumları geri gönderip "Güncelleme gerekli" durumunu açsın, sonra aynı adımı talep eden tamamlayınca devam etsin.

Sürecin işe yarayıp yaramadığını görmek için adım bazında onay sürelerini, yeniden iş oranını (ne sıklıkla değişiklik istendiğini) ve adım/ departman bazında eskalasyon sıklığını takip edin.

Sonraki adımlar: pilot, ölçüm ve uygulama

Kasıtlı olarak küçük başlayın. Bir ekip ve bir talep türü seçin (yazılım erişimi, satın alma talepleri, izin) ve 2–4 haftalık bir pilot yürütün. Akışı tasarlandığı şekilde tutun ki gerçek iş altında nerede büküldüğünü görebilesiniz.

Kuralları ve iş akışı mantığını birlikte tutun. Eğer yönlendirme bir belgede yaşayıp mantık başka bir yerde olursa, ikisi zamanla uyumsuzlaşır. Her adımın yanına düz dilde kural notları ekleyin ki "neden buraya gitti?" kolayca cevaplanabilsin.

Erken dönemde hafif izleme ekleyin. Şık panellere ihtiyaç yok: her adımda ortalama süreyi, en önemli bekleme nedenlerini (eksik bilgi, yanlış onaycı, belirsiz politika), eskalasyon sayılarını ve yeniden iş oranını takip etmek fazlasıyla öğreticidir.

Değişim için plan yapın: yeni kuralları kim önerir, kim gözden geçirir ve güncellemeler nasıl duyurulur. Haftalık veya iki haftalık gözden geçirme genellikle yeterlidir. Her değişiklik için kısa bir not şart koşun: hangi sorunu çözdüğü, kimleri etkilediği ve başarıyı nasıl ölçeceğiniz.

Eğer bu taslağı elle kodlamadan çalışan bir uygulamaya dönüştürmek isterseniz, AppMaster (appmaster.io) gibi bir no-code platformunda taleplerinizi modelleyebilir, onay mantığını görsel Business Process Editor'de kurabilir ve aranan bir geçmişi tek yerde tutarak web ve mobil ekranları hızla yayınlayabilirsiniz.