Çoğu şirkette tablo aynı: satış ekibi CRM’de çalışır, muhasebe ERP’de, depo üçüncü bir yerde. Aradaki köprü ise her ay birinin elle hazırladığı bir tablo dosyasıdır. O dosya bir süre işe yarar, sonra kırılganlaşır ve bir gün kimse hangi rakamın doğru olduğunu bilemez hale gelir.
Entegrasyon projeleri tam da bu noktada gündeme gelir. Ve tam da bu noktada en sık hata yapılır.
Yanlış soru: “hangi sistemleri bağlayalım?”
Projeye bu soruyla başlayan ekiplerin neredeyse hepsi birkaç ay sonra aynı yere geliyor: iki sistem birbirine bağlandı, ama artık aynı müşterinin iki farklı kaydı var ve hangisinin güncel olduğu belli değil.
Doğru soru şu: hangi veri, hangi sistemde doğru kabul edilecek? Müşteri adresi ERP’de mi CRM’de mi güncellenir? Fiyat hangisinden okunur? Bu netleşmeden kurulan her entegrasyon, çakışan kayıtlar üretmeye mahkûm.
Biz bu adımı “veri sahipliği tablosu” diye adlandırıyoruz ve teknik hiçbir iş yapmadan önce müşteriyle birlikte dolduruyoruz. Genelde bir toplantı sürüyor ve projenin en değerli saati oluyor.
Küçük başlayın, tek yönlü başlayın
“Her şeyi baştan bağlayalım” yaklaşımı kulağa verimli gelir ama riski tek noktada toplar. İlk canlıya alma gününde yanlış giden bir şey olduğunda, neyin bozduğunu bulmak günler alır.
Bunun yerine tek bir veri akışıyla ve tek yönde başlamak çok daha güvenli: örneğin yalnızca “CRM’de kapanan fırsat, ERP’de sipariş olarak açılsın”. Bu akış iki hafta sorunsuz çalıştıktan sonra ikincisi eklenir.
Her adımın geri alınabilir olması da önemli. Entegrasyonun kapatılabilir bir anahtarı olmalı ve kapatıldığında iş akışı elle de yürüyebilmeli.
Kimlik eşleme: en sık atlanan detay
İki sistemdeki aynı müşteriyi hangi alana bakarak eşleştireceksiniz? İsim ve unvanla eşleme yapan entegrasyonların hepsi eninde sonunda bozuluyor — çünkü “Motiweb Dijital” ile “MOTİWEB DİJİTAL LTD. ŞTİ.” aynı şirkettir ama aynı metin değildir.
Sağlam çözüm, kalıcı bir eşleme kimliği tutmak: vergi numarası gibi değişmeyen bir alan ya da her iki sistemde de saklanan ortak bir referans kodu. Kurulumu bir gün sürer, ilerideki aylarca süren temizlik işini ortadan kaldırır.
Hataları görünür kılın
Devraldığımız entegrasyonlarda en sık gördüğümüz eksik, sessiz hatalar. Bir kayıt aktarılamaz, sistem devam eder, kimse fark etmez. Üç ay sonra “bu siparişler neden ERP’de yok?” diye sorulur.
En azından şunlar olmalı: başarısız aktarımların kaydı, tekrar deneme mekanizması ve eşik aşıldığında birine giden bir uyarı. Şık bir panele gerek yok; ulaşan bir e-posta bile yeterli.
Gerçekçi bir takvim
Orta ölçekli bir ERP-CRM entegrasyonunda süre genelde şöyle dağılıyor: veri sahipliği ve alan eşlemesi bir ila iki hafta, ilk akışın geliştirilmesi iki ila üç hafta, test ve düzeltme iki hafta, ardından akış başına bir haftalık artışlarla genişleme.
Bu takvimi kısaltmanın yolu daha hızlı kod yazmak değil, kapsamı küçültmek. Tek akışla canlıya çıkmış ve çalışan bir entegrasyon; altı akışla yarım kalmış bir projeden her zaman daha değerli.
