ERP ile CRM Arasında Veri Sahipliği Nasıl Belirlenir?

CRM müşterinin iletişim adresini güncellerken ERP eski adresi geri yazıyorsa entegrasyon çalışıyor görünse bile veri güvenilir değildir. İki sistemin birbirine bağlı olması, her alanın iki yönde serbestçe değiştirilebileceği anlamına gelmez. Veri sahipliği, bir bilginin hangi süreçte oluşturulduğunu, kim tarafından onaylandığını ve diğer sistemlere hangi yönde dağıtılacağını belirler. Bu karar teknik ekipten önce satış, operasyon ve ilgili kayıt sahiplerinin katılımıyla verilmelidir.

Sistem değil alan bazında karar verin

“Müşterinin sahibi ERP olsun” gibi genel bir ifade çoğu zaman fazla geniştir. Ticari unvan, teslimat adresi, satış temsilcisi ve müşteri tercihleri farklı ekipler tarafından yönetilebilir. Her alan için oluşturma yetkisini, güncelleme yetkisini ve okuma ihtiyacını ayrı yazın. Bir sistemin bilgiyi göstermesi onu değiştirme yetkisine sahip olmasını gerektirmez. Ekranda salt okunur alan kullanılması, kullanıcının yanlış yerde düzeltme yapmasını önleyebilir; sunucu tarafındaki yetki kuralı da aynı kararı uygulamalıdır.

Basit bir veri matrisi oluşturun

Örnek olarak müşteri kodu ERP tarafından üretilsin, CRM bu kodu referans olarak saklasın. Görüşme notunun sahibi CRM olsun ve ERP yalnızca gerekli özet bilgiyi alsın. Siparişin teslimat adresi ise sipariş anındaki bir kopya olarak korunsun; müşteri kartının daha sonra değişmesi geçmiş teslimat kaydını değiştirmesin. Bu ayrım ana veri ile işlem verisini ayırır. Her satıra alanın amacı, kaynak sistem, hedef sistem ve değişiklik tetikleyicisi eklenmelidir.

Çatışmayı son yazan kazanır kuralına bırakmayın

İki kullanıcının aynı kaydı kısa aralıklarla değiştirmesi gerçek bir iş çatışması olabilir. Sadece güncelleme saatine bakarak karar vermek doğru bilgiyi kaybettirebilir. Saatlerin farklı olması veya toplu aktarımın zaman damgasını yenilemesi de değerlendirmeyi bozabilir. Çatışmalı değerleri görünür bir kuyruğa alın; veri sahibi hangi değerin geçerli olduğuna karar versin. Otomatik çözüm uygulanacak alanlar için kuralı örneklerle belgeleyin ve çözümün izini saklayın.

• Müşteri kimliğini iki sistem arasında değişmeyen bir eşleme ile bağlayın.
• Kaynak bilgiyi ve değişiklik sürümünü entegrasyon kaydına ekleyin.
• Eksik zorunlu alanı sessizce varsayımla doldurmak yerine incelemeye gönderin.
• Silinen veya pasifleştirilen kaydın diğer sistemdeki karşılığını açıkça tanımlayın.

Gecikmeyi kullanıcıya açıklayın

Her aktarımın anlık olması gerekmeyebilir. Ancak kullanıcı hangi ekrandaki bilginin ne kadar güncel olduğunu anlayabilmelidir. Son başarılı eşitleme zamanı, bekleyen değişiklik ve hata durumu birbirinden ayrılmalıdır. “Bağlantı başarılı” göstergesi tek başına kayıtların güncel olduğunu kanıtlamaz. Satış temsilcisi güncel bir teslimat adresini girdiğinde değişikliğin onay beklediğini görebilirse aynı düzeltmeyi tekrar tekrar yapmaz. Bu görünürlük destek taleplerini açıklamayı da kolaylaştırır.

Kabul denemesi için dört olay

Yeni müşteri oluşturma, mevcut müşteriyi düzeltme, aynı alanı eşzamanlı değiştirme ve müşteri hesabını pasifleştirme senaryolarını çalıştırın. Her olaydan sonra iki sistemdeki alanları karşılaştırın. Beklenmeyen geri yazma varsa kaynağı bulunmadan entegrasyonu genişletmeyin. Veri matrisi onaylandığında geliştirme ekibinin elinde teknik bir aktarım listesinden fazlası olur: işletmenin doğru veri tanımı bulunur. Yeni alan eklendiğinde aynı matrisi güncellemek, entegrasyonun zamanla kontrolsüz bir senkronizasyona dönüşmesini engeller.

İlgili rehber: ERP ve Ön Muhasebe Yazılımları: Küçük İşletme Rehberi.