Kozmetik Markası İçin Pazaryeri ve ERP Entegrasyonu

Sorun neydi?

Marka dört farklı pazaryerinde ve kendi sitesinde satış yapıyordu. Her kanalın stoğu ayrı ayrı elle güncelleniyordu. Sonuç, iki yönlü bir kayıptı: bir kanalda stok bittiğinde diğerlerinde satış devam ettiği için iptal edilen siparişler oluşuyor, aynı zamanda güvenlik payı bırakmak için gerçek stoğun altında satışa açılıyordu.

Fiyat tarafında da benzer bir dağınıklık vardı. Kampanya dönemlerinde fiyat güncellemeleri kanal kanal yapılıyor, bazı kanallarda güncelleme atlanıyordu. Muhasebe tarafında ise siparişler ay sonunda toplu olarak ön muhasebe programına giriliyordu.

Nasıl bir yapı kurduk?

Merkezde tek bir ürün ve stok kaynağı oluşturduk. Marka artık ürünü ve stoğunu tek yerde yönetiyor; sistem stok değişimini tüm kanallara belirlenen aralıklarla iletiyor. Kritik stok seviyelerinde iletim sıklığı otomatik olarak artıyor, böylece tükenen ürünün kanallarda açık kalma süresi kısalıyor.

Fiyat yönetimi için kanal bazlı kural tanımlandı. Her kanal için komisyon oranı, kargo maliyeti ve hedef kâr marjı girildi; sistem taban fiyattan hareketle kanal fiyatını hesaplıyor. Kampanya dönemlerinde tek bir indirim tanımı tüm kanallara aynı anda yansıyor, ancak marj eşiğinin altına inen ürünler uyarı veriyor.

Siparişler tek panelde toplanıyor. Hangi kanaldan geldiği, kargo bilgisi ve fatura durumu aynı ekranda görülüyor. Sipariş kaydı otomatik olarak ön muhasebe programına aktarılıyor; ay sonu toplu giriş ihtiyacı ortadan kalktı.

Kozmetiğe özgü kısım: parti ve tarih takibi

Kozmetik ürünlerinde parti numarası ve son kullanma tarihi takibi gerekiyor. Stok kaydını parti bazlı kurduk; aynı ürünün farklı partileri ayrı stok satırları olarak tutuluyor ve sevkiyatta önce son kullanma tarihi yakın olan parti çıkıyor. Belirlenen eşiğin altına inen partiler panelde uyarı listesine düşüyor.

Entegrasyon nasıl yürütüldü?

Her pazaryeri servisi için ayrı bir bağlayıcı yazıldı ve ortak bir arayüz üzerinden çalıştırıldı. Bu yapı, yeni bir kanal eklendiğinde sistemin geri kalanına dokunulmasını gerektirmiyor. Servislerin hız sınırlarına uyum için kuyruk yapısı kuruldu; başarısız istekler artan aralıklarla yeniden deneniyor ve her deneme kayıt altına alınıyor.

Entegrasyona başlamadan önce her servisle küçük bir deneme bağlantısı kuruldu. Belgelerde yazan alan adlarıyla gerçekte dönen yanıtların bazı noktalarda farklı olduğu bu aşamada görüldü ve takvim buna göre düzenlendi.

Devreye alma nasıl planlandı?

Çalışan bir satış operasyonunun stok yönetimini değiştirmek risklidir; hatalı bir devreye alma, tüm kanallarda yanlış stok gösterimi anlamına gelir. Bu yüzden geçiş kademeli yapıldı. Önce sistem yalnızca izleme kipinde çalıştırıldı: ne yapacağını hesapladı ama kanallara hiçbir şey göndermedi.

İki hafta boyunca sistemin hesapladığı stok ve fiyat değerleri, markanın elle yaptığı güncellemelerle karşılaştırıldı. Ortaya çıkan farklar tek tek incelendi; farkların bir bölümü sistemin hatasıydı, bir bölümü ise markanın elle yaptığı hatalı güncellemelerdi. Her iki taraf da bu aşamada düzeltildi.

Sonrasında önce tek bir kanal canlıya alındı, bir hafta izlendi, ardından diğer kanallar sırayla açıldı. Tüm kanallara aynı anda geçilmedi. Bu yaklaşım geçiş süresini uzattı ama tek bir kanalda bile stok hatası yaşanmadan tamamlanmasını sağladı.

İzleme ve uyarı düzeni

Entegrasyonların en tehlikeli tarafı sessizce durmalarıdır. Her kanal için son başarılı aktarım zamanı izleniyor; belirlenen süre içinde aktarım gerçekleşmezse yöneticiye bildirim gidiyor. Ayrıca günlük özet raporu gönderiliyor: kaç ürün güncellendi, kaç sipariş çekildi, kaç hata oluştu ve hangi kayıtlar beklemede.

Yeni kanal ekleme

Ortak arayüz yapısı sayesinde yeni bir pazaryeri eklemek, sistemin geri kalanına dokunulmasını gerektirmiyor. Proje tamamlandıktan sonra markanın eklediği beşinci kanal, bir haftadan kısa sürede devreye alındı. Bu esneklik, entegrasyon mimarisinin baştan doğru kurulmasının en somut karşılığı oldu.