Shopify’da stok problemleri çoğu zaman yanlış bir stok rakamıyla başlamaz. Genellikle belirsiz bir mimariyle başlar.
Bir işletmenin bugün tek deposu olabilir; ardından ikinci depo, fiziksel mağazalar, 3PL, pazaryeri stoğu veya harici bir OMS eklenebilir. Bu noktada soru artık yalnızca “Ne kadar stoğumuz var?” değildir. Asıl mesele stoğun ana kaynağının hangi sistem olduğu, hangi Shopify location’ın hangi fiziksel noktayı temsil ettiği ve online satışa gerçekten hangi miktarın açılacağıdır.
Bu ayrım önemlidir çünkü Shopify stoğu location bazında yönetirken, harici sistemler rezervasyon, transfer, güvenlik stoğu, kanal tahsisi ve satılabilir stok hesaplarını farklı biçimde yönetebilir.
Shopify location’ları yalnızca adres değildir
Shopify’da bir location; depo, mağaza, fulfillment hizmeti veya stoğun tutulduğu başka bir operasyon noktası olabilir.
Bu nedenle location yapısı işletmenin gerçek operasyonunu yansıtmalıdır. ERP veya WMS depo kodları kullanıyorsa bu kodlar proje büyüdükçe rastgele oluşturulmak yerine Shopify location’larıyla bilinçli biçimde eşleştirilmelidir.
Örneğin:
ERP WH-01 ↔ Shopify Ana Depo
ERP WH-02 ↔ Shopify Mağaza Fulfillment
3PL-TR ↔ Shopify 3PL Türkiye
Amaç, her stok hareketi ve fulfillment kararının sistemler arasında anlaşılır kalmasıdır.
Önce stok gerçeğinin hangi sistemde tutulduğunu belirleyin
Stok senkronizasyonuna başlamadan önce ana kaynak belirlenmelidir.
Bazı markalarda Shopify doğrudan ana stok sistemi olabilir. Özellikle fulfillment ağı görece basitse ve stok Shopify ile uyumlu mağaza, depo veya fulfillment servislerinden güncelleniyorsa bu model yeterli olabilir.
Daha karmaşık yapılarda ise ERP, WMS veya OMS gerçek stok topolojisinin ana kaynağı olabilir. Böyle bir yapıda Shopify’ın bilmesi gereken temel bilgi, online satış kararını verecek satılabilir miktardır.
En önemli nokta, iki sistemin birbirinden bağımsız biçimde “doğru stok budur” dememesidir.
Fiziksel stok ile satılabilir stok aynı şey olmayabilir
ERP bir depoda fiziksel olarak 100 adet ürün gösteriyor olabilir ancak online mağazanın 100 adedin tamamını satmasına izin verilmeyebilir.
Pratik bir satılabilir stok hesabı şöyle olabilir:
Fiziksel stok − rezervasyonlar − güvenlik stoğu − kanal tahsisi = online satılabilir stok
Formül işletmenin operasyonuna göre değişir; ancak prensip aynıdır: Shopify’a müşterinin gerçekten satın alabileceği miktar gönderilmelidir.
Güvenlik stoğu Shopify dışında yönetiliyorsa entegrasyon katmanı doğru satılabilir miktarı hesaplayıp Shopify’a göndermelidir.
Tek bir online location mı, gerçek location’ları Shopify’a yansıtmak mı?
İki temel mimari yaklaşım vardır.
Model 1: Tek bir toplu online location
Harici OMS veya ERP gerçek depoları yönetir ve Shopify’a her SKU için tek bir satılabilir miktar gönderir.
Shopify’da örneğin Online Satılabilir Stok adlı bir location bulunabilir. Tüm storefront siparişleri bu location üzerinden ayrılır; ancak fiziksel olarak hangi deponun siparişi karşılayacağına OMS karar verir.
Shopify’ın gerçek depo topolojisini bilmesine gerek olmayan yapılarda bu model daha sade olabilir.
Model 2: Gerçek fulfillment noktalarını Shopify’a yansıtmak
Her mağaza veya depo kendi Shopify location’ı olarak tanımlanır.
Mağazadan teslim alma, mağazadan gönderim, location bazlı stok görünürlüğü veya Shopify’ın native fulfillment yönlendirmesi gibi özellikler kullanılacaksa bu yapı daha uygundur.
Karşılığında senkronizasyon ve routing tarafı daha detaylı hale gelir. Entegrasyon yalnızca toplam stoğu değil, her location’ı doğru tutmak zorundadır.
Sipariş yönlendirme ile stok senkronizasyonu aynı karar değildir
Stoğun nerede bulunduğunu bilmek, siparişin nereden gönderileceğini otomatik olarak belirlemez.
Routing şu unsurları değerlendirebilir:
- stok bulunabilirliği,
- müşteriye uzaklık,
- kargo maliyeti,
- teslimat vaadi,
- depo önceliği,
- mağaza operasyon kuralları,
- siparişi bölmekten kaçınma.
Shopify’ın native fulfillment ve routing yetenekleri bulunur; daha karmaşık operasyonlarda routing kararları harici bir OMS içinde tutulabilir.
Mimaride Shopify’ın fulfillment location’ını mı seçeceği yoksa harici sistemin fulfillment order’ı yeniden yönlendirebileceği mi net olmalıdır.
Split fulfillment artık daha önemli
Modern e-ticaret siparişleri her zaman tek gönderiye dönüşmez.
Bir sipariş location, teslimat yöntemi, teslimat vaadi veya stok durumu nedeniyle bölünebilir. Shopify’ın fulfillment modeli bir sipariş için birden fazla fulfillment order ve fulfillment oluşmasını destekler.
Bu nedenle entegrasyonlar şu varsayımı yapmamalıdır:
bir sipariş = bir depo = bir gönderi
Bu yaklaşım küçük bir mağazada çalışabilir, ancak birden fazla depo veya omnichannel fulfillment devreye girdiğinde sorun çıkarabilir.
Stok güncellemelerinde idempotency ve mutabakat gerekir
Gerçek zamanlı senkronizasyon faydalıdır ancak kalıcı veri tutarlılığını tek başına garanti etmez.
Ağ hataları, gecikmiş event’ler, eşzamanlı işlemler veya ERP kesintileri Shopify ile kaynak sistem arasında fark oluşturabilir.
Bu nedenle olgun bir mimari genellikle üç katman içerir:
İlk başlangıç stoğu → sürekli artımlı güncellemeler → periyodik mutabakat
Harici sistem yeni ana stok değerini gönderiyorsa absolute write; sadece fark gönderiyorsa quantity adjustment mantığı kullanılabilir.
Periyodik mutabakat ise Shopify’daki stokları kaynak sistemle karşılaştırıp beklenmeyen farkları düzeltmelidir.
Transfer stoğu satılabilir stokla karıştırılmamalıdır
Location’lar arasında yolda olan stok her zaman müşteriye satışa açık değildir.
İşletme inventory transfer kullanıyorsa entegrasyon yalnızca gelen miktarı toplam stoğa eklemek yerine transferin kaynak location’ını, hedef location’ını ve durumunu dikkate almalıdır.
Bu konu özellikle mağaza ve depolar arasında sık stok transferi yapan perakendeciler için kritiktir.
Pratik mimari kontrol listesi
- Stok ana kaynağını belirleyin.
- Gerekliyse ERP/WMS depolarını doğru Shopify location’larıyla eşleyin.
- Satılabilir stok hesabını netleştirin.
- Shopify’da toplu stok mu yoksa location bazlı stok mu tutulacağını belirleyin.
- Routing kararının hangi sistemde olduğunu tanımlayın.
- Operasyon birden fazla gönderi üretebiliyorsa split fulfillment destekleyin.
- Transfer stoklarını available miktardan ayırın.
- Güvenli retry ve idempotent stok güncellemeleri kullanın.
- Düzenli stok mutabakatı çalıştırın.
- Canlıya çıkmadan önce düşük stok, tükenmiş stok, kısmi fulfillment ve depo erişilememe senaryolarını test edin.
Digimaps perspektifi
Shopify projelerinde ERP veya WMS bağlantısına geçmeden önce location, stok ve fulfillment kurallarını netleştirmeyi tercih ediyoruz. Doğru stok mimarisi, mağaza büyümeye başladıktan sonra ortaya çıkan pek çok operasyon problemini en baştan önler.
Shopify operasyonunuz birden fazla depo, mağaza veya 3PL yapısına geçiyorsa uygulamadan önce stok ve fulfillment modelini birlikte değerlendirebiliriz.