E-ticaret mağazası ile ERP veya muhasebe sistemi arasında bağlantı kurmak çoğu zaman siparişlerin otomatik aktarılması olarak anlatılır. Gerçekte bu bağlantı, farklı sistemlerdeki iş kurallarının birlikte çalışmasını gerektirir. Ürün kodları, fiyatlar, stok hareketleri, müşteri bilgileri ve sipariş durumları aynı şeyi ifade etmiyorsa hızlı veri aktarımı hatayı da hızlı yayabilir. Bu nedenle entegrasyon projesinin ilk teslimatı çalışan bir bağlantıdan önce açık bir veri ve sorumluluk haritası olmalıdır. Bu yazıda özellikle satış hacmi arttıkça elle aktarımları yönetmekte zorlanan işletmeler için planlama, hata kontrolü ve devreye alma adımlarını ele alıyorum.
Hangi verinin sahibi hangi sistem olacak?
Her veri türü için esas kaynak belirlemek gerekir. Ürün stokları depo sisteminden, açıklamalar mağazadan, müşteri hesap bilgileri başka bir uygulamadan yönetiliyor olabilir. Aynı alanın iki tarafta da serbestçe değiştirilmesi çakışma yaratır. Örneğin mağazada düzenlenen ürün adı bir sonraki toplu aktarımda eski değerle değiştiriliyorsa editörün emeği kaybolur. Entegrasyon tasarımında yalnızca hangi verinin taşınacağını değil, hangi sistemin o veriyi değiştirmeye yetkili olduğunu da yazın.
Bu kararları iş birimleri birlikte vermelidir. Teknik ekip veriyi taşıyabilir; fakat hangi stok değerinin satışa uygun olduğunu depo sorumlusu açıklamalıdır. Muhasebe ekibi de sipariş ile finansal belgenin aynı kayıt olmadığını ve hangi aşamada hangi işlemin yapılacağını belirtmelidir. Projede tek bir veri sorumlusu bulunması kararları hızlandırır. Belirsiz bir alan için varsayım yapmak yerine örnek kayıt üzerinde uzlaşmak daha güvenilir sonuç verir.
Ürün ve müşteri eşleştirmesini temizleyin
Sistemler arasında ortak ve kararlı kimlikler bulunması önemlidir. Ürün adına göre eşleştirme yapmak kırılgandır; isim değişebilir veya benzer isimler kullanılabilir. Stok kodu da ancak gerçekten benzersiz ve tutarlıysa işe yarar. Varyantlar, paketler ve set ürünler için ayrı kurallar gerekebilir. Entegrasyon öncesinde eşleşmeyen, yinelenen ve eksik kodları raporlayın. Veri temizliği tamamlanmadan otomasyon açmak, sonradan daha geniş bir düzeltme operasyonuna neden olabilir.
Müşteri tarafında da benzer dikkat gerekir. Aynı şirketin farklı şubeleri veya farklı teslimat adresleri bulunabilir. Yalnızca şirket adı üzerinden tek bir kayda bağlamak yanlış sipariş ilişkileri yaratabilir. Hangi müşteri kimliğinin hangi sistemde tutulduğunu ve yeni kayıt açma koşullarını belirleyin. Eşleştirilemeyen kayıtları sessizce atlamak yerine müdahale gerektiren ayrı bir iş listesine alın. Bu listenin düzenli kontrolünden kimin sorumlu olduğu belli olsun.
Stok kavramını ortak tanımlayın
Fiziksel stok, satışa açık stok ve rezerve stok birbirinden farklı olabilir. Depoda görünen miktarın tamamını mağazada satışa açmak her işletme için uygun değildir. Hazırlanmakta olan siparişler, hasarlı ürünler veya başka kanallara ayrılmış miktarlar satışa sunulabilecek adedi etkileyebilir. Bu nedenle hangi değerin aktarılacağını açık bir formülle tarif edin. Formüldeki her bileşenin kaynağı ve güncellenme sıklığı anlaşılır olmalıdır.
Senkronizasyon gecikmesi tamamen yokmuş gibi davranmayın. Aynı ürün farklı kanallarda aynı anda satılabilir. Güncelleme aralığı, güvenlik stoğu veya sipariş onayı gibi yöntemler işletmenin toleransına göre değerlendirilmelidir. Her ürün için aynı yaklaşım gerekmeyebilir; az bulunan ürünlerle bol stoklu ürünlerin riski farklıdır. Müşteriye gösterilen bulunabilirlik bilgisiyle operasyonun fiili kapasitesi arasındaki farkı azaltmak temel hedeftir.
Sipariş durumlarını bire bir kopyalamayın
Bir sistemdeki onaylandı durumu diğer sistemde aynı anlama gelmeyebilir. Ödeme alınmış, stok ayrılmış, hazırlanıyor ve sevk edildi gibi aşamaları iş anlamlarıyla tanımlayın. Her durum değişiminin hangi işlemi başlatacağını ve geri alınabilir olup olmadığını belirtin. Özellikle iptal ve kısmi iade senaryolarında tek bir genel durum yeterli olmayabilir. Siparişin tamamıyla satır bazındaki durumlarını ayırmak gerekip gerekmediğini gerçek örneklerle inceleyin.
Varsayımsal bir siparişte üç üründen biri iptal edildiğinde neler değişeceğini adım adım yazın. Stok serbest bırakılacak mı, tutar güncellenecek mi, müşteriye hangi bilgi gösterilecek? Bu soruların yanıtı sistemler arasında uyumlu olmalıdır. Sadece başarılı sipariş aktarımını test etmek entegrasyonun tamamlandığını göstermez. Operasyonda karşılaşılabilecek istisnalar kabul senaryolarının önemli bir bölümünü oluşturmalıdır.
Tekrarlı işlem riskini yönetin
Bağlantı kesintisinde bir istek karşı sistemde işlenmiş olabilir; ancak yanıt size ulaşmamış olabilir. Aynı isteği kontrolsüz yeniden göndermek ikinci bir sipariş veya stok hareketi oluşturabilir. Her işleme özgü kimlikler ve tekrar kontrolü bu nedenle önemlidir. Kullanılan hizmetin desteklediği yöntem mutlaka kendi belgeleri üzerinden doğrulanmalıdır. Örneğin Stripe idempotent istek belgesi, desteklenen isteklerde aynı anahtarın tekrar kullanımına ilişkin davranışı açıklar; bu davranış diğer sağlayıcılar için varsayılmamalıdır.
Tekrar deneme mekanizması sınırsız olmamalıdır. Geçici bağlantı hatası ile hatalı ürün kodu aynı biçimde ele alınamaz. Birincisi kontrollü beklemeyle tekrar denenebilirken ikincisi veri düzeltmesi gerektirebilir. Hata türlerini ayırmak, sistemin aynı başarısız işlemi sürekli çalıştırarak yük oluşturmasını önler. Son deneme zamanı, hata açıklaması ve ilgili kayıt kimliği operasyon ekranında görülebilmelidir.
Mutabakat ekranı kurun
Aktarım günlüklerinin bulunması yararlıdır, fakat işletme açısından asıl soru iki taraftaki kayıtların uyumlu olup olmadığıdır. Belirli bir dönemdeki sipariş sayıları, tutarlar ve kritik durumlar karşılaştırılabilmelidir. Fark çıktığında ilgili siparişe inmek mümkün olmalıdır. Bir işlemin teknik olarak başarılı yanıt vermesi, bütün iş bilgilerinin doğru aktarıldığını tek başına kanıtlamaz. Düzenli mutabakat, sessiz kalan hataları yakalamak için ayrı bir kontrol katmanı sağlar.
Raporlar işlem hacmine göre düzenlenmelidir. Küçük bir işletmede günlük kontrol yeterli olabilirken yoğun bir operasyonda daha sık görünürlük gerekebilir. Alarm sayısını artırmak her zaman çözüm değildir; herkesin görmezden geldiği bildirimler değerini kaybeder. Bildirimlerin hangi durumda, kime ve hangi müdahale beklentisiyle gönderileceğini netleştirin. Çözülen hatanın tekrar ortaya çıkıp çıkmadığı da izlenmelidir.
Fiyat ve birim dönüşümlerini ayrı test edin
Entegrasyonda ürün miktarı kadar fiyatın hangi anlamı taşıdığı da net olmalıdır. Liste fiyatı, müşteriye özel fiyat, kampanyalı tutar ve sipariş sırasında kabul edilen tutar birbirinden ayrılabilir. Geçmiş siparişin fiyatını güncel katalog fiyatıyla değiştirmek iş kaydını bozabilir. Yuvarlama kuralları, para birimi ve paket içindeki adet gibi ayrıntıları örneklerle doğrulayın. Bir kutunun on iki ürün içerdiği varsayımsal senaryoda mağazadaki bir adet ile depodaki bir birimin aynı şey olup olmadığını açıkça yazın.
Kontrol dosyasında normal ürün, çoklu paket, indirimli sipariş ve kısmi iade için beklenen değerler bulunsun. Sonuçları yalnızca toplam tutarla karşılaştırmayın; satır bazındaki miktarlar da incelensin. İki yanlış değer bazen toplamda birbirini dengeleyebilir. Muhasebe ve operasyon sorumlularının örnek çıktıları birlikte onaylaması bu nedenle önemlidir. Entegrasyonun teknik olarak verdiği başarılı yanıtı iş doğruluğunun yerine koymayın. İşletmenize özgü belge ve hesaplama kuralları ayrıca ilgili uzmanlarla netleştirilmeli, yazılıma aktarılan kararların sahibi belli olmalıdır. Bu hazırlık, canlı kullanımda fark edilen uyuşmazlıkların araştırılmasını da hızlandırır.
Kademeli geçiş ve geri dönüş planlayın
Entegrasyonu bütün ürünler ve bütün siparişlerle bir anda açmak yerine temsil edici bir grupla başlatabilirsiniz. Pilot sırasında eski ve yeni sonuçları karşılaştırın; fakat iki sistemin aynı işlemi bağımsız üretmesine izin vermeyin. Hangi akışın aktif olduğu açık olmalıdır. Geçiş anında bekleyen siparişlerin ve henüz aktarılmamış kayıtların nasıl ele alınacağını ayrıca belirleyin. Tarih aralığına göre körlemesine yeniden aktarım yapmak yinelenen kayıtlar oluşturabilir.
Geri dönüş planı sadece yazılımı kapatmak değildir. Yeni akışın ürettiği kayıtların hangi durumda kalacağını ve elle devam edilecekse çalışanların nasıl bilgilendirileceğini de kapsar. İlk günlerde teknik ekip ile operasyon sorumlularının aynı hata listesi üzerinden çalışması yararlıdır. Özel yazılım geliştirme veya iş otomasyonu değerlendirmesinde mevcut sistemlerinizin veri örnekleriyle başlamak, bağlantının kapsamını ve gerçek risklerini erken görmemizi sağlar.
