Aydınlatma metni yükleniyor…
B2B sipariş onay akışı; satın alma talebini, talep sahibinin rolü, sipariş tutarı, bütçe, ürün grubu, şirket yapısı ve istisna koşullarına göre doğru onaycıya yönlendiren denetlenebilir karar sürecidir. Sağlıklı bir sistem yalnız “onayla” ve “reddet” düğmelerinden oluşmaz. Kimin hangi koşulda karar verebildiğini, onaycı bulunamadığında ne olacağını, sipariş değiştiğinde eski kararın geçerli kalıp kalmayacağını ve ERP'ye hangi sürümün aktarılacağını açıkça tanımlar.
Bu rehber satın alma, operasyon, finans ve bilgi teknolojileri ekiplerinin onay gereksinimlerini yazılım kapsamına çevirebilmesi için hazırlanmıştır. “Kumsal onay karar zarfı” ve rol–tutar–onaycı–vekalet–istisna matrisi bu makale için geliştirilen özgün planlama araçlarıdır. Örnekler hukuki imza yetkisi, şirket politikası veya muhasebe görüşü yerine geçmez; gerçek limitler ve sorumluluklar kurum tarafından onaylanmalıdır.
Talep, sepet, sipariş ve onay kaydı aynı şey değildir
Satın alma talebi, bir ürün veya hizmet ihtiyacını ifade eder. Sepet, henüz karara bağlanmamış kalemlerin çalışma alanıdır. Sipariş, tedarikçiye veya ERP'ye aktarılacak ticari belgedir. Onay kaydı ise belirli bir belge sürümü hakkında, belirli yetkiyle verilmiş karardır. Bunları tek kayıt gibi ele almak değişiklik, iptal ve denetim sırasında belirsizlik yaratır.
Örneğin bir çalışan on kalemli talep hazırlayabilir; yönetici iki kalemi değişiklik için geri gönderebilir; satın alma ekibi kalan sekiz kalemi farklı tedarikçilere bölebilir. Sistem yalnız “sipariş onaylandı” durumunu saklarsa hangi kalemin, hangi tutar ve koşulla onaylandığı anlaşılamaz. Belge başlığı, satırlar, fiyat sürümü, para birimi, vergi, teslimat adresi ve ekler kararın bağlamıyla birlikte korunmalıdır.
Önce iş sahipliğini, sonra yazılım akışını belirleyin
Portal, şirket politikasını kendiliğinden icat etmemelidir. Satın alma hangi kalemleri inceler, bütçe sahibi kimdir, finans hangi eşiğin üzerinde devreye girer, teknik ürünleri kim doğrular ve son ticari kararı kim verir soruları süreç sahibi tarafından cevaplanmalıdır. Yazılım bu politikayı tutarlı uygulayan ve kanıtlayan katmandır.
Microsoft'un satın alma ve tedarik iş akışı belgeleri, satın alma talepleri ile siparişleri ayrı inceleme/onay akışları olarak ele alır; katılımcıların rol, organizasyon hiyerarşisi, kuyruk veya belirli kullanıcı üzerinden atanabildiğini açıklar. Bu ürün davranışı genel bir tasarım dersini destekler: “onaycı” yalnız sabit bir e-posta adresi değil, belgede ve organizasyonda hesaplanan bir sorumluluktur.
Kumsal onay karar zarfı: Her karar hangi bilgiyi kilitlemeli?
Bir onay düğmesine basıldığında yalnız sonuç değil, kararın hangi bağlamda verildiği de saklanmalıdır. Kumsal onay karar zarfı sekiz bileşeni birlikte tutar:
- Belge kimliği ve sürümü: Kararın hangi talep veya sipariş sürümüne ait olduğu.
- Karar kapsamı: Belgenin tamamı mı, belirli satırlar mı, yoksa yalnız bütçe kontrolü mü?
- Kural sürümü: Onaycının hangi politika ve eşik tablosuyla seçildiği.
- Yetki bağlamı: Kullanıcının rolü, şirketi, şubesi, maliyet merkezi ve geçerli vekâleti.
- Hesap girdileri: Para birimi, çevrim kuru, toplam, ürün grubu ve bütçe etkisi.
- Karar: Onay, ret, değişiklik isteği, kısmi onay, yönlendirme veya iptal.
- Gerekçe ve kanıt: Zorunlu açıklama, ek, zaman ve güvenli işlem izi.
- Sonraki durum: Sıradaki onaycı, bekleme süresi, ERP aktarımı veya düzeltme görevi.
Bu zarf, daha sonra “kim onayladı?” sorusundan daha yararlı bir soruya cevap verir: “Kullanıcı tam olarak hangi belge sürümünü, hangi yetki ve hesap girdileriyle onayladı?”
Rol–tutar–onaycı–vekalet–istisna matrisini yazın
Onay politikası uzun bir e-posta zinciri yerine test edilebilir bir karar tablosuna dönüştürülmelidir. Aşağıdaki yapı proje başlangıcında gerçek roller ve eşiklerle doldurulabilir.
| Koşul | Karar sahibi | Vekâlet/yedek | İstisna | Gerekli kanıt |
|---|---|---|---|---|
| Rol kendi harcama sınırı içinde | Bütçe sahibi veya otomatik politika | Tanımlı vekil | Yasaklı ürün, bütçe aşımı veya sözleşme dışı tedarikçi | Limit, bütçe ve kural sürümü |
| Sınırı aşan belge | Bir üst mali yetkili | Departman onay kuyruğu | Onaycı pasif ya da çıkar çatışması | Hesaplanan toplam ve hiyerarşi yolu |
| Kontrollü ürün veya hizmet | Teknik/uyum sorumlusu | Uzman grup | Eksik belge veya süresi geçmiş sertifika | Satır kapsamı ve ekler |
| Sözleşme dışı fiyat/tedarikçi | Satın alma yöneticisi | Tedarik inceleme kuyruğu | Acil alım gerekçesi | Teklif karşılaştırması ve gerekçe |
| Çok şirketli veya şubeler arası işlem | İlgili tüzel kişilik yetkilisi | Şirket bazlı vekil | Yanlış şirket, maliyet merkezi veya para birimi | Şirket, şube ve muhasebe bağlamı |
Tutar tek başına yeterli koşul değildir. Aynı toplam; ürün sınıfı, proje, maliyet merkezi, tedarikçi riski, aciliyet, sözleşme durumu veya bütçe kullanılabilirliğine göre farklı rotaya gidebilir. Matris, “bu durum hiçbir kurala uymuyorsa ne olur?” satırını da içermeli ve varsayılan olarak yetkisiz geçişe izin vermemelidir.
Onay zinciri sıralı mı, paralel mi, ilk cevap mı olmalı?
Sıralı onayda ikinci karar sahibi, ilk adım tamamlanmadan işlem yapmaz. Bütçe sahibinden sonra finans kontrolü gibi bağımlı kararlar için uygundur. Paralel onayda teknik, finansal ve ticari incelemeler aynı anda başlayabilir; ancak tamamlanma kuralı “herkes”, “belirli çoğunluk” veya “zorunlu roller” olarak açık yazılmalıdır. İlk cevap modeli ise aynı yetkiye sahip nöbetçi ekiplerden birinin kaydı sahiplenmesi için kullanılabilir; birbirinden farklı sorumlulukları birbirinin yerine geçirmemelidir.
Microsoft Power Automate sıralı onay belgeleri, birinci onaydan sonra ikinci seviyenin devreye girdiği akışı ve aynı onaycının farklı adımlara atanamaması gibi ürün sınırını gösterir. Kendi sisteminizde de sıra, tamamlanma koşulu, aynı kişinin birden fazla rolü taşıması ve ayrıştırılması gereken görevler açıkça test edilmelidir.
Vekâlet, izin ve zaman aşımı akışın parçasıdır
Onaycı tatile çıktığında hesabını başka kullanıcıyla paylaşmamalıdır. Vekâlet; başlangıç ve bitiş zamanı, kapsam, devreden kişi, vekil, yetki tavanı ve oluşturma/onaylama kaydıyla ayrı bir nesne olmalıdır. Süre dolunca otomatik kapanmalı; geçmiş kararın kimin asli, kimin vekil yetkisiyle verildiği korunmalıdır.
Bekleme süresi dolduğunda sessizce bir üst yöneticiye geçmek her süreç için doğru değildir. Sistem hatırlatma gönderebilir, yedek kuyruğa taşıyabilir, belirli rolü yükseltebilir veya talep sahibine gecikmeyi gösterebilir. Ancak hiçbir eskalasyon, yeni onaycının gerçek yetkisini aşmamalıdır. Microsoft'un satın alma onayı örneklerinde de karar eylemleri arasında onay, ret, değişiklik isteği ve delegasyon ayrı davranışlar olarak gösterilir.
Belge değişirse önceki onayın geçerliliğini yeniden değerlendirin
Onaydan sonra miktar, fiyat, iskonto, teslimat adresi, tedarikçi, ödeme koşulu veya ürün satırı değişebilir. “Her değişiklik bütün onayları sıfırlar” kuralı gereksiz gecikme yaratabilir; “hiçbiri sıfırlanmaz” kuralı ise onaylanmayan bir siparişin ilerlemesine neden olabilir.
Değişiklik sınıfları tanımlayın. Yazım düzeltmesi gibi ticari sonucu etkilemeyen değişiklik mevcut onayı koruyabilir. Toplamı artıran, yeni ürün ekleyen, para birimini veya tüzel kişiliği değiştiren işlem ilgili onayları geçersiz kılmalıdır. Sistem eski ve yeni sürüm farkını göstermeli, hangi kararların neden yeniden istendiğini kaydetmelidir.
Kısmi onay ve satır bazlı yönlendirme bilinçli tasarlanmalıdır
Bir siparişte ofis sarfı, lisans, ekipman ve kontrollü ürünler birlikte bulunabilir. Bütün belgeyi tek kişiye göndermek gereksiz erişim ve bekleme yaratabilir. Satır bazlı yönlendirme her ürün grubunu uygun uzmana taşıyabilir; fakat siparişin bölünüp bölünmeyeceği, ortak iskonto veya nakliye hesabının nasıl değişeceği ve kalan satırların hangi sürümde tutulacağı tanımlanmalıdır.
Microsoft'un satın alma talebi iş akışı belgeleri, belgenin tamamının veya ayrı satırların incelemeye yönlendirilebildiğini; satırlar ayrı incelendiğinde tüm satır kararları tamamlanmadan genel sürecin bitmediğini açıklar. Bu örnek, satır bazlı onayın yalnız arayüz seçeneği değil belge bütünlüğü kararı olduğunu gösterir.
Yetkilendirmeyi yalnız arayüz düğmelerine bırakmayın
Kullanıcı onay düğmesini görmüyor diye yetkisiz işlem engellenmiş sayılmaz. Sunucu her istek için kullanıcının güncel rolünü, şirket/şube kapsamını, belgenin durumunu, sürümünü, tutarını ve vekâletini yeniden doğrulamalıdır. Doğrudan API çağrısı, eski tarayıcı sekmesi veya değiştirilmiş istek de aynı kurallardan geçmelidir.
OWASP Authorization Cheat Sheet, en az ayrıcalık, varsayılan ret ve her istekte yetki kontrolünü önerir. Bu yaklaşım onay akışında “rolü var” kontrolünün ötesine geçer: kullanıcının tam bu belge üzerinde, tam bu durumda ve bu tutarda karar verme yetkisi kanıtlanmalıdır.
ERP'ye yalnız tamamlanmış ve değişmez karar paketi gönderin
Portal “onaylandı” durumuna geçtiğinde ERP'ye yalnız sipariş numarası göndermek yeterli olmayabilir. Belge sürümü, satırlar, fiyat ve vergi toplamları, para birimi, şirket/maliyet merkezi, onay zinciri özeti ve benzersiz aktarım kimliği birlikte taşınmalıdır. Aynı aktarım yeniden denendiğinde ikinci sipariş oluşmamalıdır.
ERP reddi, iş onayı reddiyle aynı durum değildir. Örneğin geçersiz maliyet merkezi teknik/veri düzeltmesi gerektirirken bütçe sahibinin reddi yeni iş kararı ister. Hata kuyruğu aşamayı, güvenli hata özetini, sahibi ve yeniden deneme davranışını saklamalıdır. Entegrasyonun veri sahipliği ve tekrar işleme kapsamı için e-ticaret–ERP entegrasyonu rehberini tamamlayıcı kaynak olarak kullanabilirsiniz.
Kabul testlerini mutlu yol yerine sınır koşullarından üretin
| Senaryo | Beklenen karar | Kanıt |
|---|---|---|
| Toplam yetki sınırının bir kuruş altında ve üstünde | Doğru eşik ve onaycı seçilir | Kural sürümü, hesap girdisi, rota |
| Onaycı izinli; geçerli vekil var | Yalnız tanımlı kapsam vekile gider | Vekâlet dönemi ve kapsamı |
| Onaydan sonra fiyat artar | Etkilenen karar geçersizleşir | Sürüm farkı ve yeniden onay nedeni |
| Aynı kullanıcı talep sahibi ve onaycı | Politika gerektiriyorsa görev ayrılığı çalışır | Engel veya alternatif rota |
| İki onaycı aynı anda işlem yapar | Yalnız geçerli ilk işlem kaydolur; diğeri güncel durumu görür | Karar zamanı ve sürüm kontrolü |
| ERP yanıtı gelmeden bağlantı kesilir | Aynı aktarım kimliğiyle güvenli yeniden deneme yapılır | Tek ERP siparişi ve işlem geçmişi |
| Hiçbir kural eşleşmez | Varsayılan ret veya görünür inceleme kuyruğu | Sahipsiz kayıt oluşmaması |
Başarıyı yalnız onay süresiyle ölçmeyin
Ortalama karar süresi yararlı olabilir; fakat tek başına daha iyi yönetişim anlamına gelmez. İlk seferde doğru rotaya düşme oranı, süresi aşılmış görevler, vekâletle verilen kararlar, değişiklik nedeniyle yeniden açılan onaylar, istisna kuyruğundaki yaş, yetkisiz işlem denemeleri, ERP redleri ve siparişe dönüşen talepler birlikte izlenmelidir.
Ölçümde payda ve saat açık olmalıdır. “Onay süresi” talep gönderiminden ilk karara mı, bütün zorunlu kararlara mı, yoksa ERP kabulüne kadar mı ölçülüyor? Çalışma saatleri ve tatiller hesaba katılıyor mu? Bu tanımlar olmadan iki dönemin veya iki departmanın verisi karşılaştırılamaz.
Teklifte hangi teslimatlar bulunmalı?
- Rol, şirket, şube, maliyet merkezi ve veri kapsamı matrisi
- Tutar, bütçe, ürün, tedarikçi ve istisna karar tablosu
- Sıralı/paralel adımlar ile tamamlanma koşulları
- Vekâlet, izin, zaman aşımı, eskalasyon ve çıkar çatışması kuralları
- Belge sürümü, değişiklik ve yeniden onay politikası
- Kısmi/satır bazlı karar ve sipariş bölme davranışı
- ERP alanları, mükerrer işlem koruması ve hata kuyruğu
- Denetim izi, bildirimler, raporlar ve saklama yetkileri
- Gerçek sınır koşullarını kapsayan kabul testi matrisi
Kurumsal portalın rol, veri ve entegrasyon katmanlarını daha geniş kapsamda değerlendirmek için kurumsal portal planlama rehberini inceleyebilirsiniz.
Sonuç: Onay akışı, düğmeden önce karar politikasını gerektirir
İyi bir B2B onay sistemi, hızlı bir arayüzden önce doğru belgeyi, doğru sürümle, doğru yetkiliye ve açıklanabilir kuralla ulaştırır. Vekâleti, istisnayı, değişikliği, güvenli yeniden denemeyi ve ERP teslimini ana akış kadar ayrıntılı tanımlar. Projenize özel rol, limit, onay ve entegrasyon kapsamını birlikte çıkarmak için Kumsal Ajans web yazılım çözümlerini inceleyebilirsiniz.