CRM ile ERP arasındaki sınırın doğru cevabı tek bir cümleyle özetlenebilir: her kayıt tipinin tek bir sahibi olur, diğer sistem o kaydın kopyasını taşır ve kopya üzerinde yazma yetkisi yoktur. Sahiplik dağılımı da genel olarak şu şekilde kurulur. Müşteri adayı, fırsat, teklif, aktivite ve iletişim geçmişi CRM'de yaşar. Cari kart, fatura, tahsilat, stok ve muhasebe kaydı ERP'de yaşar. Ürün ve fiyat listesi gibi ortak veriler tek yönlü olarak ERP'den CRM'e akar. Bu üç satır projelerin büyük kısmını çözer, ama şeytan detayda: aynı müşteri iki sistemde farklı yazıldığında hangisinin doğru kabul edileceği, hangi alanın hangi yönde güncellenebileceği ve stok bilgisinin CRM'e ne sıklıkla akacağı ayrı ayrı karar gerektirir.
Bu yazıda kayıt bazlı bir sahiplik tablosu, akış yönü kararı, çakışma çözüm kuralları ve senkron sıklığı üzerine somut bir çerçeve bulacaksınız. Türkiye'de sık karşılaşılan senaryoyu esas aldık: şirkette zaten bir ERP var, CRM ikinci sistem olarak geliyor.
Sınır Sorusu Neden "Hangi Sistem Daha İyi" Sorusundan Farklıdır?
CRM ve ERP karşılaştırması genelde fonksiyon karşılaştırmasıyla yapılır. Biri müşteri ilişkisine, diğeri kaynak planlamasına bakar. Bu doğru ama bir projeye başlarken işe yaramaz, çünkü proje masasındaki soru fonksiyon sorusu değildir. Soru şudur: bu kaydın doğrusu nerede tutulacak?
Aradaki fark önemli. "Teklif CRM'de de hazırlanabilir, ERP'de de hazırlanabilir" cümlesi teknik olarak doğrudur ve tam bu yüzden tehlikelidir. İki sistemde de yapılabilen bir işi iki sistemde de yapmaya başlarsanız, altı ay sonra iki farklı teklif havuzunuz olur. Satış ekibi CRM'deki sayıyı, finans ERP'deki sayıyı söyler ve toplantı hangi rakamın doğru olduğu tartışmasına döner. Bu noktada sistemlerin ikisi de düzgün çalışıyordur; bozuk olan şey sınırdır.
Tek Doğru Kaynak Ne Demek, Ne Demek Değil?
Tek doğru kaynak (single source of truth) ifadesi "veri tek yerde tutulur" diye anlaşılıyor ama kastedilen bu değil. Veri iki sistemde de bulunabilir. Tek olan şey, o veriyi değiştirme yetkisidir.
Bunu üç kavramla ayırmak işleri kolaylaştırır:
✓ Sahip sistem: Kaydı oluşturan ve değiştirebilen sistem. O kayıt tipinin doğrusu buradadır.
✓ Kopya taşıyan sistem: Kaydı görebilen ama değiştiremeyen sistem. Kopya sadece okunur.
✓ Paylaşılan alan: İstisnai olarak iki tarafın da yazabildiği alan. Her paylaşılan alan bir çakışma riski demektir, o yüzden sayısı mümkün olduğunca az tutulur.
Pratik kural şu: bir alanı iki tarafın da yazmasına izin veriyorsanız, o alan için hangi tarafın kazandığını yazılı olarak belirlemek zorundasınız. Belirlemediyseniz, kazanan taraf en son çalışan senkron olur ve bu rastgele bir sonuçtur.
Hangi Kayıt Nerede Yaşar?
Aşağıdaki tablo, Türkiye'deki tipik bir Zoho CRM ve ERP kurulumunda çalışan varsayılan dağılımı gösteriyor. Sektöre göre istisnalar olur, ama tartışma buradan başlarsa çok daha hızlı ilerler.
| Kayıt tipi | Sahip sistem | Akış yönü | Not |
| Müşteri adayı (lead) | CRM | Akmaz | ERP'nin müşteri adayına ihtiyacı yoktur |
| Fırsat ve satış hunisi | CRM | Akmaz | Kapanmamış iş ERP'yi ilgilendirmez |
| Kontak ve ilgili kişiler | CRM | CRM'den ERP'ye, sadece gerekli olanlar | ERP'ye fatura ve sevkiyat kişisi yeter |
| Aktivite, görüşme, e-posta | CRM | Akmaz | ERP'de karşılığı yoktur |
| Cari kart (müşteri hesabı) | ERP | ERP'den CRM'e | Vergi numarası, unvan, adres, risk limiti |
| Ürün ve hizmet kataloğu | ERP | ERP'den CRM'e | CRM'de ürün elle açılmamalı |
| Fiyat listesi ve iskonto matrisi | ERP | ERP'den CRM'e | Fiyatın doğrusu tek yerde durmalı |
| Teklif | CRM | CRM'den ERP'ye, onaylandığında | Onaysız teklif ERP'ye gitmez |
| Sipariş | ERP | ERP'den CRM'e, durum bilgisi | Sipariş numarası ERP'de üretilir |
| Fatura ve tahsilat | ERP | ERP'den CRM'e, sadece durum | e-fatura düzeni gereği ERP tarafında kalır |
| Stok ve teslim tarihi | ERP | ERP'den CRM'e, okunur | Satış görür, değiştiremez |
| Servis ve destek kaydı | Servis masası veya CRM | Akmaz | ERP'nin ilgi alanı değildir |
Cari Kart: En Sık Tartışılan Kayıt
Cari kartın sahibi ERP'dir, çünkü cari kart bir muhasebe nesnesidir. Vergi numarası, unvan, vergi dairesi ve fatura adresi mali kayıtla birebir tutmak zorundadır ve bu bilginin doğruluğundan finans sorumludur. CRM tarafındaki hesap kaydı bu cari kartın kopyasıdır.
Buradaki asıl karar şudur: cari kartı kim açar? İki seçenek var ve ikisi de çalışır, ama karışık kullanılırsa mükerrer kayıt üretir.
• ERP'de açılır: Satış CRM'de fırsatı kazandığında finansa talep gider, cari kart ERP'de açılır ve kopyası CRM'e döner. Daha temizdir, mükerrer kayıt riski düşüktür, ama satışın hızını finansın yanıt süresine bağlar.
• CRM'de talep başlatılır: Satış CRM üzerinden bir cari kart açılış talebi oluşturur, onay adımından geçer, ERP'de açılır ve kopya geri döner. Hız kaybı azdır ama iş akışı kurmak gerekir.
Hangisini seçtiğinizden çok, tek bir yolun açık kalması önemlidir. Hem satışın hem finansın ayrı ayrı cari kart açabildiği kurulumlar, mükerrer kayıtla ilgili sorunların büyük kısmının kaynağıdır.
Ürün ve Fiyat Listesi: Kopyalamayın, Akıtın
Sahada en sık gördüğümüz hatalardan biri, ürün kataloğunun CRM'e bir kez elle girilip orada bırakılmasıdır. İlk ay sorun çıkmaz. Üçüncü ayda ERP'de fiyat güncellenir, CRM'deki liste eski kalır ve satış eski fiyattan teklif verir. Bu, teknik bir hata değil sınır hatasıdır: fiyatın sahibi belirlenmemiştir.
Fiyat listesi ERP'de yaşamalı ve CRM'e tek yönlü akmalıdır. CRM tarafında satış temsilcisinin değiştirebileceği şey fiyat değil, iskonto talebidir. İskonto da onay akışından geçmelidir.
Teklif: CRM'de Hazırlanır, Onaylanınca ERP'ye Geçer
Teklifin sahibi CRM'dir çünkü teklif bir satış nesnesidir. Kaç revizyon yapıldığı, hangi itirazla değiştiği, kimin onayladığı satış sürecine ait bilgidir ve ERP bu bilgiyi taşımaz.
Ancak teklif onaylandığı anda muhasebe nesnesine dönüşme yolundadır. O yüzden akış şudur: teklif CRM'de hazırlanır ve revize edilir, onay alındığında ERP'ye sipariş olarak geçer, sipariş numarası ERP'de üretilir ve CRM'e geri döner. Böylece iki sistemde de aynı işin aynı numarayla izi kalır.
Akış Yönünü Nasıl Belirlersiniz?
Her alan için üç soruya cevap verilirse akış yönü kendiliğinden çıkar:
• Bu alanın doğruluğundan hangi departman sorumlu? Sahip sistem o departmanın çalıştığı sistemdir.
• Bu alan değiştiğinde diğer sistemde bir karar değişiyor mu? Değişmiyorsa akıtmaya gerek yoktur. Gereksiz senkron, bakım maliyeti ve hata kaynağıdır.
• Bu alanı diğer tarafın değiştirmesi gerekiyor mu, yoksa görmesi yeterli mi? Görmesi yeterliyse alan okunur olarak açılır.
Üçüncü soru en çok atlanan sorudur. Satış ekibinin stok miktarını görmesi gerekir, değiştirmesi gerekmez. Buna rağmen birçok kurulumda stok alanı CRM tarafında yazılabilir bırakılır ve bir süre sonra kimsenin güvenmediği bir sayıya dönüşür.
İki Sistem Aynı Müşteriyi Farklı Yazdıysa Hangisi Kazanır?
Çakışma kaçınılmazdır, çünkü aynı şirket iki sisteme iki farklı zamanda ve iki farklı kişi tarafından girilir. Çözüm, çakışmayı engellemeye çalışmak değil, çakışma çıktığında ne olacağını önceden yazmaktır.
Eşleştirme Anahtarını Unvan Değil Vergi Numarası Yapın
Türkiye'de kurumsal müşteri eşleştirmesinde tek güvenilir anahtar vergi kimlik numarasıdır. Unvan üzerinden eşleştirme yapan kurulumlar mutlaka mükerrer kayıt üretir, çünkü aynı şirket şu varyasyonlarla girilir:
• "ABC Yapı Sanayi ve Ticaret Anonim Şirketi"
• "ABC Yapı San. ve Tic. A.Ş."
• "ABC Yapı A.Ş."
• "Abc Yapı A.Ş."
Bu dördü aynı şirkettir ve hiçbir metin karşılaştırması bunu güvenle çözmez. Vergi numarası ise tektir. Bu yüzden vergi numarası alanı hem CRM hem ERP tarafında zorunlu alan olmalı, mükerrer kontrolü bu alan üzerinden kurulmalı ve unvan yalnızca görüntüleme amaçlı kullanılmalıdır.
Şahıs firmaları ve bireysel müşteriler için aynı işlevi TCKN görür. İhracat yapan şirketlerde yurt dışı müşteride vergi numarası olmayabilir; bu durumda ülke kodu ile birlikte ikinci bir kurumsal kimlik alanı tanımlanır.
Unvan Yazımını Tek Formata Bağlayın
Vergi numarası eşleştirmeyi çözer ama raporlamayı çözmez. Aynı müşteri farklı yazılmışsa rapor gruplaması bozulur. Bunun çözümü unvan yazımı için tek bir kural belirlemektir: kısaltmalar standart mı yoksa açık mı yazılacak, büyük harf kullanımı nasıl olacak, unvan sonundaki şirket tipi eklenecek mi. Kural neyse ERP'de kurulur, CRM kopyayı olduğu gibi alır.
Kazanan Kaynağı ve Hakem Adımını Yazın
Paylaşılan her alan için tek satırlık bir kural yeter:
| Alan | Kazanan | Çakışma durumunda |
| Unvan, vergi bilgisi, fatura adresi | ERP | CRM kopyası üzerine yazılır |
| Telefon ve e-posta | CRM | ERP'ye aktarılır, CRM'deki kalır |
| Sevkiyat adresi | ERP | Satışın önerisi talep olarak açılır |
| Risk limiti ve vade | ERP | CRM sadece görür |
| Sektör, segment, kaynak | CRM | ERP'nin ilgi alanı dışında |
Bu tabloyla çözülemeyen durumlar için bir hakem adımı gerekir: çakışma bir kişiye görev olarak düşer ve manuel kapatılır. Otomatik olarak birleştirilen kayıtların sessizce yanlış birleşmesi, elle kapatılan bir görevden çok daha pahalıdır.
Senkron Sıklığı: Hangi Veri Gecikmeye Tahammül Eder?
Her veriyi gerçek zamanlı akıtmak gerekmez ve genelde iyi bir fikir de değildir. Gerçek zamanlı entegrasyon hem daha kırılgan hem daha pahalıdır. Doğru soru şu: bu veri on beş dakika eski olsa bir karar yanlış çıkar mı?
| Veri | Önerilen sıklık | Gerekçe |
| Stok miktarı | Gerçek zamanlı veya çok sık | Satış müşteriye söz veriyor |
| Risk limiti ve bakiye | Gerçek zamanlı | Teklif verme kararını etkiler |
| Fiyat listesi | Günlük veya değişiklikte | Gün içinde nadiren değişir |
| Cari kart bilgileri | Değişiklikte | Sık değişmez |
| Fatura ve tahsilat durumu | Günlük | Satışın anlık bilmesi gerekmez |
| Ürün kataloğu | Günlük veya değişiklikte | Yeni ürün her gün eklenmez |
Bu tabloyu doldurmanın yan faydası şu: gerçek zamanlı akması gereken alan sayısı beklediğinizden azdır ve entegrasyon kapsamı küçüldüğünde proje süresi de maliyeti de düşer.
Sınırı Yanlış Çizmenin Dört Tipik Sonucu
Sınır kararının atlandığı projelerde hep aynı dört belirti çıkar. Bu belirtiler entegrasyonun çalışmadığını değil, sahiplik dağılımının yazılmadığını gösterir.
✓ İki sistemde iki farklı ciro: Aynı ayın satışı CRM'de bir, ERP'de başka görünür. Genelde sebep, kapanış tarihinin iki tarafta farklı tanımlanması ve teklifin iki yerde de tutulmasıdır.
✓ Satışın ERP ekranına girmek zorunda kalması: Satış temsilcisi stok veya bakiye görmek için ERP'ye giriyorsa, CRM benimseme oranı düşer. Okunur alan eksikliğinin en görünür sonucu budur.
✓ Tekliflerin Excel'e kaçması: Fiyat listesi eski, iskonto akışı yok veya teklif ekranı ağırsa, satış kendi Excel dosyasına döner ve teklif verisi sistemin dışında birikir.
✓ Raporların birbirini tutmaması: Mükerrer kayıt ve farklı unvan yazımı, müşteri bazlı raporları gruplayamaz hale getirir. Rapor bir kez güven kaybettiğinde geri kazanması uzun sürer.
Zoho CRM Tarafında Bu Sınır Nasıl Kurulur?
Sahiplik kararı verildikten sonra Zoho CRM tarafında bunu uygulamak için ihtiyacınız olan yapılar hazırdır. Kararı verilmemiş bir sınırı hiçbir araç çözmez, ama karar verildiyse uygulaması teknik bir işe dönüşür.
✓ Alan seviyesinde yetki: ERP'den akan alanlar kullanıcı profillerinde salt okunur yapılabilir. Böylece "kopya üzerinde yazma yetkisi yok" kuralı arayüzde de geçerli olur.
✓ Zorunlu alan ve doğrulama kuralları: Vergi numarası zorunlu alan yapılabilir, format doğrulaması eklenebilir ve mükerrer kontrolü bu alan üzerine kurulabilir.
✓ Onay ve süreç akışları: Cari kart açılış talebi, iskonto onayı ve teklif onayı Blueprint veya onay akışlarıyla kurulur. Teklif onaylanmadan ERP'ye geçmez.
✓ Zoho Flow ile alan eşleme: Hangi alanın hangi yöne aktığı Zoho Flow üzerinde tanımlanabilir; kod yazmadan tek yönlü veya çift yönlü akış kurulabilir.
✓ Hazır ERP entegrasyonları:Türkiye'de sık karşılaşılan Logo ile hazır entegrasyonumuz bulunuyor, SAP ve diğer kurumsal ERP sistemleri için de entegrasyon senaryoları kurguluyoruz.
Faturalama tarafına ayrı bir not düşmek gerekir. Türkiye'de e-fatura ve e-arşiv düzeni sebebiyle fatura süreci ERP ve entegratör tarafında kalır. CRM'in bu akıştaki rolü fatura kesmek değil, fatura ve tahsilat durumunu satışın görebileceği şekilde taşımaktır. Bu ayrımı baştan netleştirmek, ilerleyen aşamada gereksiz bir kapsam tartışmasını önler.
Projeye Başlamadan Önce Doldurulacak Sınır Tablosu
Entegrasyon konuşmasına başlamadan önce şu dört kolonlu tabloyu doldurmanızı öneririz. Tabloyu satış, finans ve operasyon birlikte doldurmalı, çünkü sahiplik kararı teknik değil organizasyonel bir karardır.
Kayıt veya alan | Sahibi kim | Diğer taraf ne yapabilir | Ne sıklıkla akar |
... | ... | Görür / Talep açar / Yazar | ... |
Tablo bittiğinde elinizde entegrasyon kapsamının kendisi olur. Deneyimimiz şu: bu tabloyu dolduran şirketlerde entegrasyon kapsamı beklenenden küçük çıkıyor, çünkü "akması gerekir" sanılan alanların birçoğunun aslında akmasına gerek olmadığı görülüyor.
Kısa bir uyarı: bu tabloyu tek başına CRM danışmanı dolduramaz. Cari kartın kim tarafından açılacağı ya da iskonto yetkisinin kimde olacağı bir yetki kararıdır ve şirket içinde verilmesi gerekir. Danışmanın işi, kararın sonuçlarını göstermek ve kararı sisteme doğru şekilde yansıtmaktır.
Öne Çıkanlar
• Her kayıt tipinin tek bir sahibi olur; diğer sistem kopya taşır ve kopya üzerinde yazma yetkisi olmaz.
• Müşteri adayı, fırsat ve teklif CRM'de; cari kart, fatura, tahsilat ve stok ERP'de yaşar. Ürün ve fiyat listesi tek yönlü olarak ERP'den CRM'e akar.
• Kurumsal müşteri eşleştirmesinde tek güvenilir anahtar vergi kimlik numarasıdır; unvan üzerinden eşleştirme mükerrer kayıt üretir.
• Paylaşılan her alan için kazanan taraf yazılı olarak belirlenmeli, belirlenemeyen durumlar için manuel bir hakem adımı tanımlanmalıdır.
• Her veri gerçek zamanlı akmak zorunda değildir; stok ve risk limiti dışındaki çoğu veri günlük senkronla yeterli olur.
• Sahiplik dağılımı yazılmadığında entegrasyon teknik olarak çalışır ama kimse sisteme güvenmez.
Sıkça Sorulan Sorular
CRM ve ERP entegrasyonu tek yönlü mü çift yönlü mü olmalı?
Varsayılan tercih tek yönlü olmalıdır. Çift yönlü akış yalnızca iki tarafın da aynı alanı gerçekten değiştirmesi gerektiğinde kurulur ve o durumda kazanan taraf mutlaka yazılı olarak belirlenir. Tek yönlü akış hem daha az bakım gerektirir hem de çakışma riski taşımaz.
Cari kartı satış mı finans mı açmalı?
İkisi de çalışır, ama tek bir yol açık kalmalıdır. Finansın açtığı model daha temizdir ve mükerrer kayıt riski düşüktür. Satışın hızını korumak istiyorsanız, CRM üzerinden onaya giden bir cari kart açılış talebi akışı kurup kartı yine ERP'de açtırmak daha iyi bir denge sağlar.
Fatura CRM üzerinden kesilebilir mi?
Türkiye'de e-fatura ve e-arşiv düzeni sebebiyle fatura süreci ERP ve entegratör tarafında yürür. CRM'in rolü fatura kesmek değil, fatura ve tahsilat durumunu satış ekibinin görebileceği şekilde taşımaktır. Bu ayrımı proje başında netleştirmek gerekir.
Aynı müşteri iki sistemde farklı yazılmışsa ne yapmalıyız?
Önce eşleştirme anahtarını vergi kimlik numarasına çevirin ve bu alanı iki tarafta da zorunlu yapın. Mevcut mükerrer kayıtlar için vergi numarası üzerinden bir birleştirme çalışması yapılır, otomatik birleştirilemeyen kayıtlar bir kişiye görev olarak atanır ve elle kapatılır.
Stok bilgisini CRM'e aktarmak zorunda mıyız?
Satış ekibi müşteriye teslim sözü veriyorsa evet, ve bu veri sık güncellenmelidir. Ancak stok alanı CRM tarafında salt okunur olmalıdır. Satışın değiştirebildiği bir stok alanı kısa sürede güvenilirliğini kaybeder.
Entegrasyon kapsamını nasıl küçültebiliriz?
Her alan için "bu alan değiştiğinde diğer sistemde bir karar değişiyor mu" sorusunu sorun. Cevap hayırsa o alanı akıtmayın. Bu tek soru, çoğu projede kapsamı belirgin şekilde küçültüyor ve hem süreyi hem maliyeti düşürüyor.
Sınırı Doğru Çizmek İçin Yanınızdayız
CRM ile ERP arasındaki sahiplik dağılımı, teknik bir entegrasyon sorusu gibi görünse de aslında bir yetki ve süreç kararıdır. Yanlış çizilmiş bir sınır, en iyi kurulmuş entegrasyonu bile kimsenin güvenmediği bir yapıya çevirir. Şirketinizin mevcut ERP kurulumuna göre bu sınırı birlikte çizmek ve Zoho CRM tarafında doğru şekilde uygulamak için ekibimize danışın.