1. İki uygulamayı değil, bir işi birbirine bağlayın
CRM ile ERP arasında veri aktarımı yapmak, satıştan operasyona iş devrinin doğru tasarlandığı anlamına gelmez. İlk olarak tek bir akışı seçin: onaylanan teklifin siparişe dönüşmesi veya müşteri bilgilerinin güncellenmesi gibi. Kaydın nerede başladığını, hangi kararın ardından aktarılacağını ve diğer ekip için ne zaman kullanılabilir olacağını yazın. Hakan’ın proje deneyimi, canias ERP ile entegre bir CRM’in sıfırdan geliştirilmesini de kapsıyor. Böyle bir çalışma planlarken her alanı iki yönlü eşitlemek yerine, seçilen akışın gerçekten ihtiyaç duyduğu bilgiyle başlamak daha açık bir kapsam sağlar.
- Akışın başlangıcını, bitişini ve karar veren kişiyi yazın.
- İlk kapsama alınmayacak süreçleri de listeleyin.
2. Sahipliği kayıt değil alan düzeyinde belirleyin
Müşteri iki sistemde de bulunabilir; bu, bütün bilgilerinin iki yerde de değiştirilebilmesi gerektiği anlamına gelmez. Satış sorumlusu CRM’de, ödeme koşulu ERP’de yönetiliyor olabilir. Bu bir örnek tasarım kararıdır; doğru dağılımı sizin süreçleriniz belirler. Her alan için asıl kaynak, düzenleme yetkisi, aktarım yönü ve çakışma kararı içeren bir sözlük hazırlayın. Microsoft’un alan sınırları yaklaşımı da sistemlerin aynı kavramı farklı amaçlarla ele alabileceğini vurgular. Bu ilkeyi kullanmak için uygulamaları yeniden yazmak veya mikroservis mimarisine geçmek gerekmez.
- Bir alan iki yerde değişirse hangi kararın geçerli olacağını tanımlayın.
- Boş değer, silme ve pasife alma işlemlerinin anlamını ayrı yazın.
3. Eşleştirme ve dönüşüm kurallarını görünür yapın
Aktarımın hangi müşteriyi veya ürünü güncelleyeceği, taşınan alanlar kadar önemlidir. İsim benzerliğine dayanarak kayıtları otomatik birleştirmeyin. Sistemler arasındaki kimlik bağlantısını, ilk eşleştirme yöntemini ve şüpheli kaydı kimin inceleyeceğini belirleyin. Para birimi, ölçü birimi, adres yapısı ve durum kodu dönüşümlerini örnekler üzerinden kontrol edin. Eşleşmeyen değer için sessiz bir varsayılan kullanmak yerine, akışın durması mı yoksa inceleme kuyruğuna alınması mı gerektiğine karar verin. Bu kararları yalnızca geliştiricinin kodunda bırakmayın; süreç sahibinin okuyabileceği biçimde saklayın.
- İlk veri aktarımı ile günlük güncellemenin kurallarını ayrı kontrol edin.
- Mükerrer ve eşleşmeyen kayıtlar için inceleme sorumlusu atayın.
4. Güncellik ihtiyacını işin ritmine göre seçin
Her bilginin anında aktarılması gerekmeyebilir. Stok uygunluğu ile haftalık müşteri sınıflandırması aynı gecikmeye duyarlı değildir. Her akış için kabul edilebilir gecikmeyi ve ekranda gösterilecek son güncelleme bilgisini belirleyin. İşlemin gönderilmesi, alınması ve hedefte tamamlanması aynı durum olarak gösterilmemeli. Bağlantı kesildiğinde kullanıcıya ne söyleyeceğinizi önceden tasarlayın. Aktarım yöntemi; mevcut uygulamaların izin verdiği arayüzler, veri hacmi ve operasyonun ihtiyacına göre seçilmelidir. Yalnızca sunumda daha iyi göründüğü için her işlemi anlık hale getirmeye çalışmayın.
5. Başarısız işlemin nasıl toparlanacağını tasarlayın
Bağlantı yeniden kurulduğunda aynı talebin tekrar gönderilmesi gerekebilir. Tasarım, bu tekrarın yanlışlıkla ikinci bir sipariş veya müşteri oluşturmasını önlemeli. Başarılı adımları, hata nedenini ve tekrar deneme durumunu izleyebileceğiniz bir işlem kaydı tutun. Sürecin bir kısmı tamamlandıysa, her şeyi eski haline döndürmek her zaman doğru iş kararı değildir. Microsoft’un telafi işlemleri rehberi de toparlanmanın iş kurallarına bağlı olduğunu ve bazı durumlarda insan müdahalesi gerektiğini açıklar. Satış veya operasyon ekibinin karar vermesi gereken belirsiz kayıtları görünür bir inceleme listesine yönlendirin.
- Tekrar deneme, iptal ve elle düzeltme yetkilerini belirleyin.
- Kullanıcıya teknik hata kodunun yanında yapılacak işi de gösterin.
6. Teslimi bağlantı testiyle sınırlamayın
Kabul sırasında normal akışı, tekrar gönderimi, eksik alanı, bağlantı kesintisini ve çakışan güncellemeyi birlikte deneyin. Kaynağın ve hedefin aynı iş sonucunu gösterdiğini süreç sahipleriyle doğrulayın. Günlük takip ekranı, açık hata listesi, erişim sorumluları ve değişiklik kayıtları teslimin parçası olsun. İlk kullanımdan sonra hangi ölçülerin izleneceğini belirleyin: bekleyen aktarım, en eski hata, eşleşmeyen kayıt ve çözüm süresi gibi. Bu göstergeler için önce mevcut durumu ölçün. Başarıyı varsayılan bir tasarruf oranıyla değil, üzerinde anlaştığınız işin güvenilir biçimde tamamlanmasıyla değerlendirin.
