ERP entegre bayi portalı mimarisi: portal ERP’nin yerine geçmemeli
Bayi portalı projelerinde en sık yapılan hata, portalın ERP’nin işini yapmaya çalışmasıdır. Fiyat hesaplama, stok düşme, cari hareket üretme gibi işler ERP’de kalmalıdır. Portal, bu verileri bayiye doğru ve zamanında gösteren, sipariş niyetini toplayıp ERP’ye aktaran bir işlem katmanıdır. Bu ayrımı baştan koymazsanız iki ayrı doğruluk kaynağı oluşur ve altı ay sonra hangisinin doğru olduğunu kimse bilemez.
Katmanlar
Sağlıklı bir kurguda dört katman vardır:
- Kayıt sistemi (ERP): Ürün, fiyat listesi, cari hesap, stok, sipariş, irsaliye, fatura. Nihai doğruluk buradadır.
- Entegrasyon katmanı: ERP ile portal arasındaki çeviri, kuyruk ve yeniden deneme mantığı. ERP’ye doğrudan bağlanan bir portal, ERP her yavaşladığında çöker.
- Portal veritabanı: Okuma için optimize edilmiş kopya. Katalog, bayi fiyatı, stok görünümü, sipariş taslakları.
- Arayüz: Bayi, satış temsilcisi ve yönetim için ayrı yetki ve görünümler.
Senkron mu, asenkron mu?
Her veri aynı hızda tazelenmek zorunda değil. Pratikte işe yarayan ayrım şudur:
| Veri | Yöntem | Tazelik |
|---|---|---|
| Ürün kataloğu | Zamanlanmış aktarım | Günlük |
| Bayi fiyat listesi | Zamanlanmış + değişiklik tetikleyici | Saatlik |
| Stok | Önbellekli, kısa ömürlü | 5–15 dakika |
| Cari bakiye / risk limiti | Sipariş anında canlı sorgu | Anlık |
| Sipariş gönderimi | Kuyruk + yeniden deneme | Asenkron |
Stoğu “anlık” göstermek cazip gelir ama ERP’yi her sayfa açılışında sorgulamak hem ERP’yi yorar hem de portalı ERP’nin performansına mahkûm eder. Bunun yerine kısa ömürlü önbellek kullanıp, siparişin onaylandığı anda canlı doğrulama yapmak daha sağlıklıdır.
Sipariş aktarımında iki kritik mekanizma
Idempotency (tekrarsızlık): Portal ERP’ye sipariş gönderir, ERP cevabı gecikir, portal yeniden dener — ve aynı sipariş iki kez düşer. Bunu önlemenin tek yolu, her siparişe portal tarafında üretilen benzersiz bir anahtar vermek ve ERP tarafında bu anahtarın daha önce işlenip işlenmediğini kontrol etmektir.
Mutabakat (reconciliation): Gecelik bir iş, portaldaki siparişlerle ERP’dekileri karşılaştırmalı; eşleşmeyenleri operasyon ekibine raporlamalıdır. Entegrasyonun sessizce bozulduğu durumları ancak böyle yakalarsınız.
Ticari kurallar nerede çalışmalı?
Fiyat, iskonto ve vade hesabı ERP’de kalmalı; portal sonucu göstermelidir. Ancak sipariş verilebilirlik kuralları portalda çalışabilir: minimum palet, araç doluluk oranı, bayinin ürün grubu yetkisi, risk limiti aşımında onaya düşürme. Bu kurallar sık değişir ve ERP’de değiştirmek pahalıdır.
Denetim izi
“Kim ne zaman ne yaptı?” sorusu, kurumsal projelerde teknik bir tercih değil, zorunluluktur. Fiyat değişikliği, sipariş onayı, limit aşımı onayı, kullanıcı yetkilendirme — hepsi kim, ne zaman, hangi değerden hangi değere bilgisiyle kaydedilmelidir. Bu kayıtlar silinemez olmalıdır.
Neyi ölçmeli?
Projenin başarısı ekran sayısıyla değil şu göstergelerle ölçülür: telefon/WhatsApp ile gelen sipariş oranındaki düşüş, sipariş giriş süresi, hatalı fiyat/ürün/miktar kaynaklı düzeltme sayısı, portal üzerinden sipariş veren aktif bayi oranı. Bu göstergeler için başlangıç değerini projeye başlamadan önce ölçün; yoksa sonunda iyileşmeyi kanıtlayamazsınız.