B2B satışta sipariş toplamak tek başına zor değildir; asıl zorluk, siparişin doğru fiyatla, doğru müşteri koşullarıyla ve doğru stok bilgisiyle sisteme işlenmesidir. E-posta, Excel, telefon ve WhatsApp üzerinden ilerleyen süreçler ilk bakışta pratik görünebilir. Ancak iş hacmi büyüdükçe denge tersine döner. Aynı sipariş birden fazla kez girilir, iskonto kuralları birbirine karışır, onay bekleyen teklifler görünmez olur. b2b sipariş otomasyonu tam da bu noktada devreye girer: bayi portalı, kurallı onay akışları ve ERP entegrasyonu sayesinde sipariş yaşam döngüsünü uçtan uca dijitalleştirir.
Buradaki hedef yalnızca manuel işi azaltmak değildir. Asıl amaç, siparişin açıldığı an ile ERP'de kesinleştiği an arasındaki gecikmeyi azaltmak, veri kalitesini yükseltmek ve satış operasyonunu ölçülebilir kılmaktır. Örneğin bir bayi siparişi bugün 12 farklı alan içeriyorsa — teslimat adresi, ödeme vadesi, kampanya kodu, para birimi, stok lokasyonu gibi — bu alanların her birini e-posta zinciri içinde kontrol etmek yerine sistematik doğrulamalardan geçirmek çok daha güvenlidir.
İyi kurgulanmış bir yapı, sipariş giriş süresini dakikalar seviyesine indirebilir. Bunun yanında satış ekibine net bir görünürlük de sunar: hangi sipariş beklemede, hangisi finans onayında, hangisi ERP'ye aktarıldı, hangisi sevk için hazır. Bu yazıda bayi portalı tasarımından onay matrisine, ERP entegrasyonundan ölçümleme metriklerine kadar pratik bir çerçeve sunuyoruz.
B2B sipariş süreçlerinde darboğaz nerede oluşur?
Tipik bir distribütör ya da üretici yapısında sipariş akışı 5 ila 8 adım arasında ilerler. Bayi talebi açar, satış temsilcisi kontrol eder, fiyat veya iskonto teyit edilir, gerekiyorsa finans limiti incelenir, ERP kaydı oluşur, sevkiyat planlanır. Kağıt üzerinde bu akış düzenli görünür. Asıl sorun, verinin sistemler arasında kopuk biçimde hareket etmesidir.
En sık karşılaşılan darboğazlar şunlardır:
- Tekrarlı veri girişi: Sipariş önce e-postada, sonra Excel'de, ardından ERP'de yeniden oluşturulur.
- Onay belirsizliği: %10 üzeri iskonto kimin onayında, hangi müşteri için kredi limiti ne kadar, çoğu durumda kişiye bağlı bilgi olarak kalır.
- Anlık stok eksikliği: Portalda görünen ürün ile ERP'deki gerçek stok senkron değilse sipariş revizesi kaçınılmaz hale gelir.
- Fiyat karmaşası: Bölge, bayi seviyesi, kampanya tarihi ve para birimi birlikte hesaplanmadığında hatalı sipariş açılır.
Somut bir senaryo düşünelim. 250 aktif bayisi olan bir firmada her bayi ayda ortalama 6 sipariş açıyorsa, ayda yaklaşık 1.500 sipariş hareketi oluşur. Her siparişte yalnızca 4 dakikalık manuel doğrulama kaybı bile ayda 100 saati aşar. Üstelik bu süre yalnızca görünür kısımdır; düzeltme, iade, revizyon ve müşteri iletişimi buna dahil değildir.
Bayi portalı: Siparişi doğru yerden başlatmak
B2B otomasyonunun en kritik bileşeni bayi portalıdır. Portal, bir e-ticaret vitrini gibi çalışmamalı; ticari kuralları taşıyan bir işlem ekranı olmalıdır. Bayi yalnızca ürün görmemelidir. Kendi sözleşmeli fiyatını, açık hesap riskini, teslimat seçeneklerini ve sipariş durumlarını da görebilmelidir.
İyi bir bayi portalında en az şu modüller bulunur:
- Müşteri bazlı ürün ve fiyat görünürlüğü
- Gerçek zamanlı veya yakın gerçek zamanlı stok bilgisi
- İskonto ve kampanya kuralları
- Tekrarlayan sipariş şablonları
- Sipariş durumu takibi ve belge geçmişi
- İade veya eksik teslim talebi ekranı
Burada yapılan tasarım tercihleri operasyonu doğrudan etkiler. Örneğin 2.000 SKU içeren bir katalogda arama, filtre ve hızlı sipariş satırı yoksa bayi portalı kısa sürede kullanışsız hale gelir. Benzer şekilde minimum sipariş miktarı 12 adet olan bir ürün için adet alanı serbest bırakılırsa kullanıcı deneyimi iyileşmiş olmaz; tersine, hatalı sipariş sayısı artar. Portalın görevi, esneklik sunarken kontrolü de korumaktır.
Rol bazlı yapı neden önemlidir?
Her bayi kullanıcısı aynı yetkiye sahip olmamalıdır. Satın almacı sipariş açabilir, bölge müdürü taslakları görebilir, finans sorumlusu bakiye ve vade bilgisine erişebilir. Bu ayrım, hem güvenlik hem de süreç netliği açısından gereklidir. Özellikle çok şubeli bayi yapılarında siparişin hangi depo ya da şube adına açıldığı açık biçimde tanımlanmalıdır.
Pratikte sık kullanılan model, dealer_admin, buyer, approver gibi rol setleridir. Örnek bir kural şöyle olabilir: if order.total > 250000 then require regional_approval. Kurallar kod seviyesinde açık olduğunda süreç, kişilere değil sisteme bağlı olarak ilerler.
Onay akışları: Kuralı kişiden ayırmak
B2B siparişlerde gecikmenin büyük bölümü belirsiz onay adımlarından kaynaklanır. Kimin neyi onaylayacağı baştan tanımlanmadığında siparişler e-posta kutularında bekler. Oysa onay akışı matrisi net kurulduğunda süreç izlenebilir hale gelir.
Örnek bir onay matrisi şu şekilde tasarlanabilir:
- Tutar eşiği: 100.000 TL üzeri siparişlerde bölge yöneticisi onayı
- İskonto eşiği: Liste fiyatına göre %12 üzeri indirimde satış müdürü onayı
- Risk eşiği: Açık bakiye limiti aşılırsa finans onayı
- Ürün kısıtı: Regülasyona tabi ürünlerde ek belge kontrolü
Bu yapının faydası yalnızca hız değildir. Aynı zamanda denetlenebilirlik sağlar. Kim, hangi tarihte, hangi gerekçeyle onay verdi sorusunun yanıtı sistem loglarında bulunur. Özellikle ISO süreçleri, iç denetim veya bayi anlaşmazlıkları açısından bu kayıtlar kritik değer taşır.
Paralel ve sıralı onay ne zaman kullanılır?
Her onayı sıraya koymak doğru değildir. Finans ve satış onayı birbirini beklemek zorunda olmayabilir. Paralel akış, aynı sipariş üzerinde iki birimin eş zamanlı çalışmasına imkan tanır. Buna karşılık teknik ürünlerde uygunluk kontrolü sipariş kesinleşmeden önce zorunlu olabilir; burada sıralı akış gerekir.
İyi bir kural motoru, SLA mantığıyla da çalışır. Örneğin 2 saat içinde yanıt verilmeyen onay talebi otomatik eskalasyona düşebilir. 24 saat sonunda ise sipariş taslağı yeniden fiyat kontrolüne alınabilir. Bu tür süre tanımları, operasyon disiplinini ciddi biçimde güçlendirir.
ERP entegrasyonu: Otomasyonun omurgası
Portal ne kadar iyi olursa olsun, ERP ile güçlü şekilde entegre değilse sipariş otomasyonu eksik kalır. Çünkü ticari gerçeklik ERP'de yaşar: cari hesap, stok, fiyat listeleri, irsaliye, fatura, sevkiyat ve muhasebe kayıtları burada tutulur. Bu nedenle entegrasyon mimarisi en baştan planlanmalıdır.
Entegrasyonda tipik veri akışları şöyledir:
- ERP'den portala: ürün kartları, stok, fiyat listeleri, müşteri limitleri, açık hesap bilgisi
- Portalden ERP'ye: sipariş başlığı, satır detayları, teslimat notları, kampanya referansı
- Çift yönlü senkron: sipariş durumu, sevkiyat bilgisi, fatura numarası
Burada iki yaklaşım öne çıkar. İlki, gerçek zamanlı API entegrasyonu. Bayi siparişi verdiği anda ERP'ye anlık kayıt açılır. İkincisi ise kuyruk tabanlı veya zamanlanmış aktarım yaklaşımıdır. Özellikle eski ERP sistemlerinde 5 dakikalık ya da 15 dakikalık batch senkronizasyon daha güvenli olabilir. Tercih, ERP'nin teknik kapasitesine ve işlem hacmine göre yapılmalıdır.
Hataları nasıl yönetmek gerekir?
Entegrasyon projelerinde asıl kalite kriteri, veri giderken değil veri takılırken ortaya çıkar. Örneğin ERP, geçersiz cari kod nedeniyle siparişi reddederse kullanıcıya yalnızca “hata oluştu” mesajı gösterilmemelidir. Hata tipi sınıflandırılmalı, yeniden deneme politikası tanımlanmalı, gerekiyorsa operasyon paneline düşmelidir.
Sağlam bir yapı için şu kontroller gerekir:
- Idempotency: Aynı siparişin iki kez oluşmasını engelleyen benzersiz işlem anahtarı
- Mapping doğrulama: Birim, para birimi, vergi kodu ve depo kodlarının tutarlılığı
- Audit trail: Her aktarım için zaman damgası ve sonuç kaydı
Özellikle sipariş numarası üretiminde tek kaynak net biçimde belirlenmelidir. Portal geçici numara üretip ERP kesin numara verebilir. Bu model, izlenebilirlik açısından sık tercih edilir.
Uygulama planı: 90 günlük gerçekçi bir yol haritası
B2B sipariş otomasyonu, tek seferde devreye alınacak bir “büyük geçiş” projesi olmak zorunda değildir. Daha güvenli yaklaşım, aşamalı yayına geçmektir. Orta ölçekli bir organizasyonda 90 günlük bir plan gerçekçi kabul edilebilir.
1. faz: Analiz ve süreç haritalama — 2 ila 3 hafta
Bu aşamada siparişin mevcut yaşam döngüsü çıkarılır. Kim, hangi veriyi, hangi araçta oluşturuyor? Hangi onaylar gerçekten gerekli, hangileri alışkanlıkla sürüyor? En az 20-30 örnek siparişin incelenmesi iyi sonuç verir. İstisnalar bu aşamada görünür hale gelir.
2. faz: Portal ve kural motoru — 4 ila 6 hafta
MVP kapsamı belirlenir. Ürün listeleme, sipariş oluşturma, müşteri bazlı fiyat, temel onay akışı ve durum takibi ilk sürüm için yeterlidir. Tüm özellikleri ilk yayına sıkıştırmak çoğu zaman riski artırır.
3. faz: ERP entegrasyonu ve pilot — 2 ila 4 hafta
Önce sınırlı bir bayi grubuyla pilot yapılır. Örneğin 10 bayi, 3 ürün kategorisi, tek depo. Pilotta ölçülmesi gereken metrikler nettir: sipariş açma süresi, manuel müdahale oranı, entegrasyon hata sayısı, onay bekleme süresi. Bu veriler olmadan ikinci faz genişletmesini sağlıklı biçimde planlamak zordur.
Hangi KPI'lar izlenmeli?
Otomasyonun başarılı olup olmadığını anlamak için ölçüm gerekir. Sadece “ekip rahatladı” geri bildirimi yeterli değildir. Aşağıdaki KPI seti sahada işe yarar:
- Sipariş çevrim süresi: Sipariş oluşturma ile ERP kesinleşmesi arasındaki dakika/saat
- İlk seferde doğru sipariş oranı: Revizyon gerektirmeyen sipariş yüzdesi
- Manuel müdahale oranı: Otomatik akış dışına çıkan siparişlerin oranı
- Onay SLA uyumu: Tanımlı sürede sonuçlanan onay yüzdesi
- Entegrasyon hata yoğunluğu: 100 siparişte kaç teknik hata oluştuğu
Örneğin ilk 30 günde sipariş çevrim süresi 9 saatten 2 saate düştüyse bu ciddi bir kazanımdır. Aynı dönemde manuel müdahale oranı %40 seviyesinde kalıyorsa kural seti veya veri kalitesi hâlâ iyileştirme gerektiriyor demektir. Yani tek bir metriğe bakmak yeterli olmaz.
Sık yapılan hatalar ve kaçınma yolları
Projelerde benzer hatalar sık sık tekrar eder. İlki, portalı sadece “online sipariş formu” gibi ele almaktır. Bu yaklaşım, ERP gerçekliğini dışarıda bırakır ve kullanıcı güvenini kısa sürede zedeler. İkincisi, tüm bayi tiplerini tek bir senaryoda çözmeye çalışmaktır. Oysa zincir mağaza ile saha bayisinin işleyişi farklı olabilir.
Bir diğer hata da istisna süreçlerini göz ardı etmektir. Kısmi sevkiyat, muadil ürün önerisi, kampanya çakışması, bloke müşteri açma talebi gibi başlıklar mutlaka düşünülmelidir. Siparişlerin %80'i standart akıştan geçse bile kalan %20, operasyonun gerçek yükünü oluşturur.
Teknik tarafta ise loglama ve izleme eksikliği pahalıya mal olur. Entegrasyon çalışıyor sanılır; oysa bazı sipariş satırları sessizce düşüyor olabilir. Bu nedenle uygulama katmanında, entegrasyon servislerinde ve ERP geri dönüşlerinde merkezi izleme şarttır.
Kapanış
b2b sipariş otomasyonu, yalnızca bir sipariş giriş ekranı kurmak anlamına gelmez. Bayi portalı, onay akışları ve ERP entegrasyonu birlikte ele alındığında gerçek değer ortaya çıkar. Doğru kurgulanan yapı, satış operasyonunu hızlandırır, hataları azaltır ve yönetime anlık görünürlük kazandırır. En önemlisi de süreçleri kişilere bağımlı olmaktan çıkarır. Büyüyen şirketlerde sürdürülebilirlik tam burada başlar.
