“Mağaza ERP'ye bağlansın” ifadesi teklif hazırlamak için yeterli bir kapsam değildir. Hangi veri hangi yönde gidecek, hangi sistem doğru kaynağı temsil edecek ve hata olduğunda operasyon nasıl devam edecek? Bu sorular yanıtlanmadan bağlantı teknik olarak kurulsa bile stok veya sipariş çelişkileri sürebilir. Entegrasyonu ekranlar arasında veri taşımaktan önce iş kuralları projesi olarak düşünün.
Her veri için yetkili kaynağı seçin
Ürün açıklaması mağazada, stok ERP'de, belirli kampanya fiyatı başka bir araçta yönetiliyor olabilir. Bütün alanlara tek bir genel yön atamak bu farkları gizler. Ürün adı, stok miktarı, satış fiyatı ve sipariş durumu için ayrı sahiplik belirleyin.
İki sistemde aynı alan düzenlenebiliyorsa çakışma kuralı gerekir. Son yazan her zaman doğru olmayabilir; yanlışlıkla yapılan bir panel değişikliği onaylı ERP bilgisini geçersiz kılmamalıdır. Hangi durumda otomatik güncelleme, hangi durumda insan incelemesi gerektiğini açıklayın.
Kapsamı veri grubu ve yön bazında yazın
Aşağıdaki tablo örnek kapsam sorularıdır; her projede yönler farklı olabilir. Kendi sistemlerinizin gerçek veri sahipliğine göre doldurun.
| Veri grubu | Kapsam sorusu | Kabul örneği |
|---|---|---|
| Ürün | Kod ve varyasyon eşlemesi nerede yönetilir? | Doğru ürüne doğru veri uygulanır |
| Stok | Depo ve satılabilir miktar nasıl hesaplanır? | Ayrılan ve mevcut stok karışmaz |
| Fiyat | Hangi fiyat listesi hangi müşteriye gider? | İndirim ve para birimi doğru görünür |
| Sipariş | Hangi aşamada ERP kaydı oluşturulur? | Aynı sipariş tekrar oluşmaz |
| İptal ve iade | Hangi durum stok ve tahsilatı etkiler? | İade ile iptal ayrı işlenir |
| Müşteri | Kimlik ve adres ilişkisi nasıl korunur? | Yanlış müşteriye kayıt bağlanmaz |
Güncelleme hızını iş ihtiyacına göre belirleyin
Her alanın anında aktarılması gerekmeyebilir; fakat bazı stok veya sipariş durumlarında gecikme operasyonu etkiler. Kabul edilebilir gecikmeyi veri grubuna göre tanımlayın. “Gerçek zamanlı” ifadesini ölçülemeyen bir genel vaat olarak kullanmayın.
Shopify'ın webhook dokümanı, olay bildirimlerinin sırasının ve tesliminin her durumda garanti edilmediğini açıklar. Bu nedenle böyle bir mekanizma kullanıldığında tekrar kontrol ve veri uzlaştırma yaklaşımı da planlanmalıdır. Tek bir bildirimin gelmesini bütün kayıtların sonsuza kadar senkron kalacağı kanıtı saymayın.
Hata ve tekrar denemeyi operasyonun anlayacağı hale getirin
Varsayımsal bir sipariş ERP'ye iletilir fakat yanıt alınamadan bağlantı kesilir. Yeniden denemede ikinci sipariş oluşmaması gerekir. Sipariş kimliği, aktarım durumu ve tekrar işleme kuralı bu senaryoda birlikte çalışmalıdır.
Hata listesinde yalnızca teknik kod değil, etkilenen sipariş veya ürün, yapılacak işlem ve sorumlu kişi bulunsun. Yetkili kişi eksik bilgiyi düzelttiğinde kayıt nasıl tekrar gönderilecek ve sonuç nasıl doğrulanacak? Geliştiriciye her seferinde mesaj atmak zorunda kalan bir operasyon sürdürülebilir olmayabilir.
Kabulü başarılı bir örnekle sınırlamayın
Yeni ürün, varyasyon güncellemesi, stok değişikliği, kısmi iade, yanlış adres ve tekrar gönderim gibi senaryolar seçin. Test verisinin gerçek satış veya muhasebe sonucu yaratmadığından emin olun. Kaynak ve hedef kaydı birlikte karşılaştırın; yalnızca “başarılı” mesajına bakmayın.
Yayın sonrasında bağlantı yetkisi, sistem güncellemesi ve veri alanı değişikliklerinin sahibi belli olsun. Entegrasyonun bakım kapsamı da teklifin parçası olmalıdır. Sonuçta işletme hangi bilgiyi nerede yöneteceğini ve aksaklıkta ne yapacağını açıkça bilmelidir.