Eşik tabanlı yönlendirme ile esnek onay kuralları

Sabit (kodlanmış) onay kuralları neden yetersiz kalır

Kod içine gömülü onay kuralları başlangıçta sorun yaratmıyor gibi görünür. Bir geliştirici birkaç koşul ekler, iş akışı çalışır ve ekip yoluna devam eder.

Sorun, iş değiştiğinde ortaya çıkar. Finans harcama limitini artırır, bir bölge farklı bir politika uygular veya bir departman belirli talepler için ekstra bir onaylayıcı ister. Küçük görünen bir güncelleme artık uygulama mantığını değiştirmek, test etmek ve bir yayın beklemek anlamına gelir.

Bu gecikme maliyetlidir. Dakikalar içinde yapılması gereken bir politika değişikliği, teknik çalışmaya bağlıysa günler alabilir. Bu boşlukta çalışanlar eski kurallara göre hareket eder, onaylar tıkanır ve yöneticiler istisnaları e-posta veya sohbetle yönetmeye başlar.

Gizli istisnalar durumu daha da kötüleştirir. Zamanla ekipler "miktar 5.000'in üstündeyse ve departman Satış ise Direktör A'ya gönder" veya "istek Avrupa'dan geliyorsa bu adımı atla" gibi tek seferlik kurallar ekler. Bu kurallar iş akışının derinlerinde yaşadığında sadece birkaç kişi görebilir.

O zaman basit sorular bile zorlaşır:

• Belirli bir meblağın üzerindeki satın alma işlemlerini kim onaylar?
• Pazarlama, Operasyon ile aynı politikayı mı takip ediyor?
• Başka bir bölgede ne oluyor?
• Hangi istisna geçen çeyrekte eklendi?

Hiç kimse tam kural setini göremediğinde hatalar ortaya çıkar. Birisi politikanın doğru olduğunu sanırken uygulama hâlâ eski bir kural kullanıyor olabilir. Yeni bir yönetici asla görmemesi gereken isteklerle karşılaşırken gerçek onaylayıcı dışarıda kalır.

İşte bu yüzden politikalar sık değişiyorsa eşik tabanlı yönlendirme daha iyi çalışır. Kuralları uygulamanın sabit parçaları olarak görmek yerine, onları gözden geçirilebilen ve güncellenebilen iş verisi olarak saklarsınız.

Basit bir gider politikası hayal edin. 1.000'in altındaki talepler takım liderine gider, 1.000–10.000 arası bölüm başkanına, üzerindekiler ise finanse gider. Bu limitler ay içinde değişirse, onayların akması için işin geliştiriciye ihtiyacı olmamalı.

Kodlamanın sıradan politika güncellemelerini yazılım projelerine dönüştürmesi asıl maliyettir.

Eşik tabanlı yönlendirme ne demektir

Eşik tabanlı yönlendirme, onay yolunun önceden tanımladığınız değerlere göre değiştiği anlamına gelir. Bir eşik, örneğin 1.000 $ üzeri bir miktar, Finans departmanından gelen bir istek veya Avrupa'da yapılan bir satın alma gibi bir sınırdır.

Bu kuralları uygulamaya direkt yazmak yerine tablolar halinde saklarsınız. İş akışı tabloyu okur, eşleşen kuralı bulur ve isteği doğru kişiye yollar.

Temel bir kurulum şu şekilde olabilir:

• 500 $ altındaki talepler takım liderine gider.
• 500 $–5.000 $ arası talepler bölüm yöneticisine gider.
• 5.000 $ üzerindeki talepler direktöre gider.
• İK talepleri bir yol izlerken, BT talepleri başka bir yol izleyebilir.
• Kuzey Amerika ve EMEA farklı onaylayıcılar belirleyebilir.

Süreç aynı kalır, ancak onu kontrol eden değerler değişebilir.

Mantığı politikadan ayırın

Bunun ana fikri budur. Mantık, "kuralları kontrol et ve ilk eşleşeni seç" diyen kısımdır. Politika verisi ise kuralların kendisidir: miktar aralıkları, departmanlar, bölgeler, onaylayıcılar ve öncelik.

Mantık ve politika karıştığında, küçük bir değişiklik bile iş akışını düzenlemek için geliştirici gerektirir. Ayrıldığında, iş akışı sabit kalır ve sadece kural satırları değişir.

Örneğin, APAC'teki Satış artık 5.000 yerine 3.000 üzeri için direktör onayı gerektiriyorsa, bir tablo girişini güncellersiniz. Tüm onay sürecini yeniden inşa etmezsiniz.

Bu, politikaların süreç yapısından daha sık değişmesi nedeniyle yönetimi kolaylaştırır. Ekipler yeniden organize olur, bütçeler kayar ve bölgelerin sahipleri değişir. Bir tablo bu tür değişiklikleri sabit koşullardan daha iyi yönetir.

AppMaster gibi no-code bir platformda bu genellikle bir kural tablosu oluşturmak ve iş sürecinin çalışma zamanında onu kontrol etmesi demektir. Model, işin gerçekte yazıldığı biçime benzer olduğu için teknik olmayan ekiplerin de anlaması kolaydır: eğer bu koşul eşleşirse, buraya gönder.

Kural tablonuza ne koymalısınız

İyi bir kural tablosu basit bir soruyu yanıtlamalıdır: bu koşullar eşleştiğinde kimin onayı gerekir?

Yönlendirme kod içinde saklanıyorsa, her politika güncellemesi yeniden derleme anlamına gelir. Bir tablo bu değişiklikleri görünür ve yönetmesi kolay tutar.

Pratik bir kural tablosu genellikle isteği tanımlayan alanlarla başlar:

• miktar
• para birimi
• departman
• bölge
• istek tipi
• onaylayıcı rolü

Miktar ve para birimi önemlidir çünkü aynı sayı bütçelere veya ülkelere göre farklı anlamlar taşıyabilir. 5.000 USD için bir yol, 5.000 EUR veya 500.000 JPY için başka bir yol gerekebilir.

Departman ve bölge şirketlerin gerçek çalışma şeklini yansıtır. Finans, İK ve Operasyon genellikle aynı harcama için farklı onay yollarına sahiptir. Bölge yerel kurallar veya yöneticiler farklı olduğunda sonucu değiştirir.

İstek tipi de faydalı bir filtredir. Seyahat, yazılım satın alımı, tedarikçi ödemeleri veya indirim onayları farklı gözden geçiriciler gerektirebilir. Bu alan yoksa alakasız talepler aynı kuralı kullanabilir.

Onaylayıcı için bir kişinin adını değil bir rol saklayın. "Bölüm Müdürü", "Bölgesel Direktör" veya "Finans Kontrolörü" gibi değerler kullanın. Birisi iş değiştirirse, her kuralı düzenlemek yerine rol atamasını bir kez güncellersiniz.

Ayrıca başlangıç ve bitiş tarihleri eklemek faydalıdır. Bu, belirli bir tarihte başlayan politikaları, bütçe sezonundaki geçici kuralları veya gelecek çeyrek için planlanan değişiklikleri kapsar. Geçmişi tutarken süresi dolmuş kuralların aktif kalmasını engellersiniz.

Bir öncelik alanı da eklemeye değerdir. "AB + Finans + 10.000 üzeri" gibi bir kural genellikle "tüm departmanlar + 10.000 üzeri" gibi daha geniş bir kuraldan önce gelmelidir. Net öncelik yönlendirmeyi tahmin edilebilir kılar.

Tabloyu nasıl yapılandırmalı

Yapıyı basit tutun: bir satır bir onay kuralına eşit olmalıdır.

Eğer Avrupa'da pazarlama harcamaları 2.000 $ üzeri bölgesel yöneticiyi gerektiriyorsa, bu tek bir kayıtta yer almalı. Her satırın tek ve net bir anlamı olduğunda kurulum daha kolay güncellenir, test edilir ve denetlenir.

Ana tablo iki şeye odaklanmalıdır: bir kuralı tetikleyen koşullar ve iş akışına bir sonraki adımda ne yapması gerektiğini söyleyen sonuç.

Pratik bir düzen

Temiz bir tablo genellikle şu alanları içerir:

• kural ID'si veya kural adı
• aktif durum, ayrıca isteğe bağlı başlangıç ve bitiş tarihleri
• minimum miktar, maksimum miktar, departman, bölge ve istek tipi gibi koşul alanları
• onaylayıcı rolü, onaylayıcı kullanıcı veya bir sonraki adım gibi sonuç alanları
• öncelik ve varsayılan-kural bayrağı

Koşul sütunları için mümkün olduğunca serbest metin yerine kesin alanlar kullanın. Her seferinde "Finans" yazmaktansa bir departman ID'si daha güvenlidir. Bölge kodları, istek tipleri ve maliyet merkezleri için küçük arama tabloları yazım hatalarını azaltır ve filtrelemeyi kolaylaştırır.

Sonuç sütunları için iş akışının ne döndürmesi gerektiğine karar verin. Bazı ekiplerde kural belirli bir kişiyi işaret etmeli; bazılarında bir rol (Bölgesel Yönetici veya Finans Direktörü) hedeflenmelidir. Bir yaklaşımı seçin ve tutarlı kalın.

Öncelik önemlidir çünkü birden fazla kural aynı istekle eşleşebilir. Satır sırasına veya oluşturulma tarihine güvenmeyin. Sayısal bir öncelik alanı ekleyin ve nasıl çalıştığını tanımlayın; örneğin 1 önce, 100 sonra kontrol edilir.

Ayrıca bir yedek kural gerekir. Bu, belirli bir satır tarafından kapsanmayan her şey için emniyet ağıdır. Varsayılan kural eşleşmeyen talepleri operasyon yöneticisine veya yönetici inceleme kuyruğuna gönderebilir. Aksi halde talepler hiçbir yola gönderilmeden takılabilir.

AppMaster ile bunu oluşturursanız, bu tablolar görsel olarak düzenlenebilir ve böylece politika değişiklikleri veri üzerinden yapılır, sert kodlanmış iş akışı dalları yerine.

Nasıl kurulur

Tabloyu değil kararı önce başlatın. İş akışınızın hangi soruları yanıtlaması gerektiğini açıkça yazın. 5.000 $ üzeri bir satın alma yönetici gerektirir mi? Finans, Satış'tan gelen her şeyi inceliyor mu? Bir bölgeden gelen istek farklı bir yol izliyor mu?

Bu seçimler netleştiğinde, eşik tabanlı yönlendirme politika sakladığınız için çok daha kolay olur; sonradan mantığı tahmin etmeye çalışma zorunluluğu ortadan kalkar.

Basit bir kurulum genellikle beş adımdan oluşur.

Birincisi, yönlendirmeyi etkileyen alanlarla bir onay kuralları tablosu oluşturun. Yaygın sütunlar: amount_min, amount_max, department, region, approver_role, priority ve active_status.

İkincisi, hangi alanların boş bırakılabileceğine karar verin. Boş bir departman veya bölge "bu kural tümü için geçerlidir" anlamına gelebilir; daha spesifik eşleşme yoksa uygulanır.

Üçüncüsü, kuralları en özgünden en genel olana doğru ekleyin. "Satış + Avrupa + 10.000 üzeri" gibi bir kural, "herhangi departman + 10.000 üzeri" gibi geniş bir kuraldan önce kontrol edilmelidir.

Dördüncüsü, yayına almadan önce gerçek örneklerle test edin. Tam olarak 5.000 $, eksik departman verisi veya özel kural olmayan bir bölge gibi uç vakaları deneyin.

Beşinci, tablonun kimler tarafından düzenlenebileceğini sınırlayın. Politika değişiklikleri kolay olmalı, ancak herkese açık olmamalıdır.

Basit bir örnek: Kuzey Amerika'daki HR'den gelen 12.000 $ tutarındaki istek ilk olarak "HR 10.000 üzeri" kuralına eşleşir ve HR direktörüne gider. HR'ye özel kural yoksa sistem daha geniş bir "herhangi departman 10.000 üzeri" kuralına yedekleyebilir ve isteği finansa yollar.

Sıralama birçok ekibin beklediğinden daha fazla önem taşır. Geniş kuralların spesifiklerin üzerinde durması yanlış kişiye giden istekler anlamına gelir ve insanlar sistemin güvenilirliğini yitirir.

Canlıya almadan önce bir kural değişikliğinden sorumlu bir sahip atayın, kısa bir politika dokümanı tutun ve her güncellemeden sonra tekrar test edin. Küçük yönlendirme değişiklikleri büyük etkiler yaratabilir.

Pratik bir örnek

Bir şirketin her ekip için tek bir satın alma talep formu olduğunu düşünün. Her istek miktar, departman ve bölge içerir. Sistem bu değerleri bir kural tablosuyla karşılaştırır ve doğru onaylayıcıyı seçer.

Şirketin iki departmanı olduğunu varsayalım: Pazarlama ve BT. Her ikisi de 4.000 $ istekte bulunabilir, ama onay yolu aynı olmak zorunda değildir.

Aynı miktarla gelen iki isteği karşılaştırın. ABD'de 4.000 $ tutarındaki bir Pazarlama isteği Marketing Manager'a gider. ABD'de 4.000 $ tutarındaki bir BT isteği ise BT Manager'ı atlayıp CTO'ya gider; çünkü BT'nin eşiği daha düşüktür.

Bölge sonucu da değiştirebilir. ABD'de 2.500 $ tutarındaki bir Pazarlama isteği Marketing Manager'a giderken aynı tutardaki bir AB isteği Regional Marketing Lead'e gider. Form aynı kalır; sadece eşleşen kural değişir.

İşte kural tablosunun gerçek değeri: politika veride yaşar, iş akışı mantığının içinde değil.

Şirket politika güncellemesi yaparsa, tüm süreci yeniden inşa etmenize gerek yoktur. Örneğin BT, 2.000 $ üzeri talepleri artık CTO'ya göndermek isterse tek satırı düzenlersiniz:

• Eski kural: IT, US, $3,001+, CTO
• Yeni kural: IT, US, $2,001+, CTO

Diğer her şey çalışmaya devam eder. Yeni talepler hemen yeni politikayı takip ederken uygulama yapısı değişmez.

Kaçınılması gereken yaygın hatalar

Eşik tabanlı yönlendirmenin en zor kısmı genellikle temel fikir değildir. Zorlayıcı olan, politika değiştikçe ortaya çıkan ve kimse neden bir isteğin yanlış kişiye gittiğini hatırlamadığında görülen kenar vakalardır.

Yaygın bir hata, net bir öncelik olmadan örtüşen kurallara sahip olmaktır. Bir kural 3.000 $ üzeri tüm Pazarlama taleplerini bölüm yöneticisine gönderirken başka bir kural 5.000 $ üzeri her isteği finansa gönderebilir. 6.000 $ tutarındaki bir Pazarlama isteği her iki kuralla da eşleşir; bu yüzden sistemin açık bir kazananı olmalıdır. Bu önceliği kural tablosuna koyun, gizli iş akışı mantığına değil.

Diğer bir hata, kişilere göre (sabitleme) yönlendirme yapmaktır. İsimler değişir, ekipler değişir. Birisi izne çıkarsa veya başka bir departmana geçerse "Maria Lopez'e gönder" gibi kurallar her personel değişiminde düzenlenmelidir. Bunun yerine rol veya grup kullanmak daha güvenlidir; rolü güncellemek yeterlidir.

Bir yedek yol atlamanın sessiz hatalara yol açmasına izin vermeyin. Er ya da geç bir istek hiçbir kuralla eşleşmeyecek — miktar alışılmadık olabilir, departman yeni olabilir veya bir alan boş kalmış olabilir. Bu durumda iş akışı yine de güvenli bir şey yapmalı: varsayılan kuyruğa veya admin ekibine gönderme gibi.

Bölgesel istisnalar da zayıf noktalardır. Bir ülkede işe yarayan politika başka bir ülkede yerel harcama limitleri, vergi kuralları veya raporlama ihtiyaçları nedeniyle çalışmayabilir. Sadece tek bir bölgeyi test etmek, AB, ABD veya APAC isteklerinin farklı yollar izlemesi gereken durumları gözden kaçırabilir.

Zaman bazlı kurallar da unutulma eğilimindedir. Geçici bir kural çeyrek sonu, bütçe dondurması veya özel bir proje için oluşturulduysa, başlangıç ve bitiş tarihleri olduğundan emin olun. Aksi halde eski istisnalar aktif kalır ve talepleri yanlış yollara gönderir.

Yayına almadan önce son kontroller

Eşik tabanlı yönlendirmeyi açmadan önce gerçek bir kullanıcının bakış açısından gözden geçirin. Her istek kim tarafından onaylanacağı konusunda kimsenin tahmin yürütmesine gerek kalmadan doğru kişiye gitmelidir.

Son incelemeyi basit tutun.

Her normal isteğin bir net eşleşmesi olduğundan emin olun. Aynı anda iki kural uygulanabiliyorsa sonuçlar tutarsız olur.

Bir yedek yol olduğundan emin olun. Eksik departmanlar, yeni bölgeler veya sıra dışı miktarlar yine de güvenli bir yere gitmelidir.

Finans veya Operasyon limitleri, tarihler veya onaylayıcıları değiştirmek istediğinde geliştiriciye ihtiyaç olmadan değişiklik yapılabildiğini doğrulayın. Politika değişiklikleri tablodaki kayıtlarla yönetilebilmelidir.

Sadece değerleri değil tarihleri de test edin. Dün geçerli olan politika ve gelecek ay yürürlüğe girecek politika, etkili tarihleri doğru şekilde uygulandığında beklenen şekilde davranmalıdır.

Yönlendirme mantığını bir sayfada sade bir dille yazın. Bir yönetici bunu açıkça açıklayamıyorsa muhtemelen çok karmaşıktır.

Yararlı bir son test, normal vakaları, uç vakaları ve süresi dolmuş politika vakalarını kapsayan beş örnek istek oluşturmaktır. Ekip bunların sonucunu çalıştırmadan önce tahmin edebiliyorsa, kurulum muhtemelen hazırdır. Edemiyorlarsa, basitleştirin.

Sonraki adımlar

Küçük başlayın. Bugün en çok gecikmeye veya karışıklığa neden olan tek bir onay akışını seçin: belirli bir tutarın üzerindeki satın alma talepleri veya departmana göre masraf talepleri gibi. Önce bunu oluşturun, gerçek vakalarla test edin ve sonra daha fazla kural türü ekleyin.

Bu yaklaşım yönlendirme modelinin güvenilirliğini artırır. İnsanlar kuralların nasıl çalıştığını, nerede istisnalar olduğunu ve kurulum büyümeden önce neyin değişmesi gerektiğini görebilir.

İlk yayına alma dört temel soruya cevap vermeli:

• Hangi istek tipi önce otomatikleştirilmeli?
• Miktar, departman veya bölge gibi hangi alanlar yönlendirmeyi kontrol ediyor?
• Her vaka bugün kim tarafından onaylanıyor?
• Politika değiştiğinde kuralları kim güncelleyecek?

Son madde çok önemlidir. Eğer politika güncellemelerinden kimse açıkça sorumlu değilse, iş akışı zamanla gerçek işleyişten uzaklaşır. Bir kişi veya küçük bir ekip atayın; kural değişikliklerini gözden geçirsin, düzenlemeleri onaylasın ve neden değişiklik yapıldığını kısa bir kayıtla tutsun.

Ayrıca bir inceleme takvimi belirlemek yardımcı olur. Politikalar sık değişiyorsa aylık; süreç stabilse çeyreklik inceleme yeterli olabilir. Kısa bir gözden geçirme, güncel olmayan eşikler, eksik departmanlar veya bölgesel istisnaları gecikme yaratmadan önce yakalayabilir.

İncelemeyi pratik tutun. Basit sorular sorun: onaylar doğru kişilere gidiyor mu, ekip yapılarında değişiklik var mı, mevcut limitler hâlâ finansal politika ile uyumlu mu ve çok fazla manuel istisna var mı?

Bunu görsel olarak oluşturmak isterseniz, AppMaster kural tablosu, yönlendirme süreci ve teknik olmayan personelin politikaları güncelleyeceği admin ekranları oluşturmak için uygun bir seçenek olabilir. Tam no-code uygulamalar için tasarlandığı için, iş ekiplerinin onay değişikliklerini doğrudan yönetmesini istediğinizde geliştiricilere her güncelleme için geri dönmeyi önler.

Bir akış iyi çalışmaya başladığında aynı deseni sonraki süreçlerde yeniden kullanın. Küçük, net adımlar genellikle büyük yeniden yapılanmalardan daha iyi sonuç verir.