ERP'imiz Var, Ayrıca Satış Yazılımına Gerek Var mı? Kapsam Sınırı Nasıl Çizilir

ERP ile satış yazılımı birbirinin alternatifi değildir; aynı zincirin farklı uçlarını tutarlar. Bu nedenle doğru soru "hangisini alalım" değil, "sınır nerede ve hangi veriyi hangi sistem sahiplenir" sorusudur. Sınır çizilmediğinde iki sistem de aynı veriyi üretmeye başlar; ortaya çıkan şey iki yazılım değil, iki ayrı gerçektir.

Bu yazı kapsam sınırı ve kayıt sahipliği kararına odaklanıyor. Yazılım kategorilerinin tanımları ve hangisinin ne yönettiği inşaat CRM nedir yazısında, CRM ile muhasebe arasındaki bağlantının teknik kurulumu — API, dosya aktarımı, ara katman ve Logo, Netsis gibi sistemlerle entegrasyon — CRM muhasebe entegrasyonu yazısında ele alınmıştır.

Soru neden yanlış kurulmuş oluyor?

"ERP'imiz var, CRM'e gerek var mı" sorusunun arkasında genellikle şu varsayım yatar: iki yazılım da müşteri kaydı tutuyorsa işlevleri örtüşüyordur. Oysa örtüşme kayıt tipinde değil, aynı kaydın farklı aşamalarındadır.

Pratik ayrım şudur: ERP, satış gerçekleştikten sonra doğan yükümlülükleri yönetir — cari hesap, fatura, tahsilatın muhasebeleştirilmesi, maliyet, nakit akışı. Satış yazılımı ise satış gerçekleşmeden önceki zinciri yönetir: lead, görüşme, envanter durumu, teklif, opsiyon, fiyat ve ödeme planı kurgusu. İki sistemin kesiştiği yer tek bir andır: satışın kesinleştiği an.

Bu anın hangi sistemde kaydedildiği ve sonrasında verinin hangi yöne aktığı netleştirilmediğinde üç tipik sonuç görülür:

• Çifte veri girişi. Aynı müşteri hem satış ekibi hem muhasebe tarafından ayrı ayrı açılır; iki kayıt zamanla birbirinden uzaklaşır.
• Çelişen rakamlar. Satışın raporladığı bakiye ile finansın raporladığı bakiye tutmaz; her toplantı mutabakat toplantısına döner.
• Boşlukta kalan süreçler. Opsiyon, teklif geçerliliği ve fiyat listesi versiyonu gibi satış öncesi kayıtlar hiçbir sistemde tutulmaz; Excel'e düşer.

Kayıt sahipliği: her veri için tek bir doğruluk kaynağı

Kapsam sınırını çizmenin tek işe yarar yöntemi, veri bazında kayıt sahibi (tek doğruluk kaynağı) belirlemektir. Kayıt sahibi, o verinin oluşturulduğu ve değiştirildiği sistemdir; diğer sistem aynı veriyi görebilir ama değiştiremez.

Kural üç cümleyle özetlenir: her veri tipinin tek bir sahibi olur, değişiklik yalnızca sahibinde yapılır, diğer sistemdeki hâli salt okunur kopyadır. Bu kural yazılı değilse entegrasyon kurulsa bile veri tutarsızlığı sürer — çünkü iki tarafta da düzenleme yapılabildiğinde son yazan kazanır ve hangi tarafın doğru olduğu bilinmez.

Veri bazında sınır: hangi veri nerede yaşar?

Aşağıdaki dağılım konut satışı yapan bir geliştirici için tipik bir başlangıç noktasıdır. Firmanın yapısına göre birkaç satır değişebilir; önemli olan tablonun doldurulmuş ve üzerinde mutabık kalınmış olmasıdır.

Tablonun mantığı tek bir cümleye iner: satış öncesine ait her şey satış yazılımında, satış sonrası mali yükümlülüklere ait her şey ERP'de. Kesişim noktası satış anıdır ve orada veri satıştan ERP'ye akar.

Senet ve çek hangi tarafta durmalı?

Pratikte en çok tartışılan satır budur ve tek doğru cevabı yoktur. İki meşru kurgu vardır.

• ERP'de master. Senet ve çek mali kıymetli evraktır; portföy takibi, ciro, tahsil ve karşılıksız işlemleri muhasebenin alanıdır. Satış tarafında yalnızca "bu daireye karşılık şu evrak alındı" bilgisi görünür.
• Satış yazılımında master. Evrak doğrudan ödeme planının parçasıysa ve satış ekibi vade takibini kendisi yürütüyorsa, kayıt satış tarafında tutulup ERP'ye aktarılır.

Seçimi belirleyen soru şudur: vadesi yaklaşan evrak için müşteriyi kim arıyor? Arayan taraf satışsa kaydın satış tarafında olması operasyonu hızlandırır. Tahsilat takibinin satış tarafındaki kurgusu tahsilat takibi yazısında ele alınmıştır.

ERP'nin satış modülü varsa ne olur?

Birçok ERP paketinde satış veya CRM modülü bulunur ve "zaten var" cevabı genellikle buradan gelir. Modülün varlığı değil, konut satışının beş özel yapısını karşılayıp karşılamadığı belirleyicidir.

Beş sorunun cevabına göre üç senaryo çıkar. Tamamı karşılanıyorsa ayrı bir satış yazılımına gerek olmayabilir; bu durumda yapılacak iş ERP'nin satış modülünü doğru kurgulamaktır. Kısmen karşılanıyorsa — çoğu durumda böyledir — eksik parçanın geliştirmeyle mi kapatılacağı yoksa ayrı bir sistemle mi çözüleceği bir maliyet ve süre karşılaştırmasıdır. Karşılanmıyorsa satış tarafı ayrı yönetilir ve ERP ile entegre edilir.

İkinci senaryoda sorulması gereken soru genellikle atlanır: geliştirme kimde kalacak? ERP üzerine yapılan özel geliştirmeler sürüm yükseltmelerinde bakım gerektirir ve bunu yapacak kaynak genellikle dışarıdadır. Bu bakım yükü, ilk teklif karşılaştırmasında görünmez. Genel amaçlı bir sistemi konut satışına uyarlamanın ne gerektirdiği ücretsiz ve açık kaynak CRM yazısında benzer bir çerçeveyle ele alınmıştır.

Satış ekibinin ERP'de çalışmasının pratik sınırı

Teknik yeterlilik tek ölçüt değildir. ERP arayüzleri muhasebe ve idari kullanıcı için tasarlanır; satış danışmanının günlük kullanımına uygun olmayabilir. Üç nokta önceden değerlendirilmelidir.

• Kullanım hızı. Danışman müşteri karşısındayken daire müsaitliğine ve fiyata saniyeler içinde ulaşabiliyor mu?
• Mobil ve saha kullanımı. Şantiye ve saha ziyaretinde erişim var mı? Konu mobil CRM yazısında ele alınmıştır.
• Yetki ayrımı. Satış ekibinin tüm mali veriye erişmesi istenmez; rol bazlı ayrım kurulabiliyor mu?

Üçüncü madde çoğu ERP'de çözülebilir ama kurgulanması gerekir. Kurgulanmadığında iki sonuçtan biri olur: ya satış ekibi görmemesi gereken veriyi görür, ya da yetki o kadar daraltılır ki sistemi kullanamaz ve işini Excel'e taşır.

Çakışma noktaları: iki sistem de aynı veriyi üretmeye kalktığında

Sınır çizilmediğinde çakışma hep aynı dört yerde çıkar.

Dördüncü satır doğrudan onay mekanizmasına bağlanır: sapmanın hangi yetkiyle ve hangi kayıtla yapılacağı tanımlı değilse, fark ERP'de ortaya çıkar ve geriye dönük düzeltilir. Yapı satış onay süreçleri yazısında, fiyat tarafı fiyat listesi versiyonlama yazısında ele alınmıştır.

Mutabakat: sınır doğru çizilmiş mi?

Kapsam sınırının çalışıp çalışmadığı aylık mutabakatla anlaşılır. Dört karşılaştırma yeterlidir ve tutmadığında nerede bakılacağını da gösterir.

1. Satılan bağımsız bölüm sayısı. Satış tarafındaki "satıldı" adedi ile ERP'de sözleşmesi işlenmiş adet. Fark varsa satış kesinleşme anının tanımı belirsizdir.
2. Toplam satış bedeli. İki sistemdeki sözleşme bedeli toplamı. Fark varsa indirim veya plan değişikliği tek tarafta kalmıştır.
3. Tahsil edilen tutar. ERP'deki tahsilat toplamı ile satış tarafında görünen ödenmiş tutar. Fark varsa yansıtma akışı gecikiyordur.
4. Açık bakiye ve vade dağılımı. İki sistemin kalan alacak tablosu. Fark varsa ödeme planı değişiklikleri ERP'ye aktarılmıyordur.

Mutabakatın aylık ritme bağlanması, farkların birikmesini önler. Hangi raporun hangi periyotta kim tarafından okunacağı satış raporlama ritmi yazısında ele alınmıştır.

Sınırın yanlış çizildiğini gösteren altı belirti

• Satış ekibi aynı bilgiyi iki sisteme giriyor.
• Ay sonu toplantısında zamanın önemli kısmı hangi rakamın doğru olduğunu belirlemeye gidiyor.
• Müşteri bakiyesini öğrenmek için danışman muhasebeyi aramak zorunda.
• Opsiyon, teklif ve fiyat listesi Excel'de tutuluyor; hiçbir sistemde karşılığı yok.
• Faturası kesilmiş bir satış, satış tarafında hâlâ açık görünüyor.
• Aynı daire için iki farklı sözleşme bedeli bulunabiliyor.

Dördüncü madde en sık görülenidir ve ERP'si olan firmalarda satış tarafının gerçekte neyi eksik bıraktığını gösterir: mali kayıt tamdır, satış öncesi zincir kayıtsızdır.

Karar çerçevesi: dört soru

1. Satış öncesi zincir nerede tutuluyor? Lead, görüşme, teklif ve opsiyon bugün hangi sistemde? Cevap "Excel" ise eksik olan ERP değil satış yazılımıdır.
2. ERP'nin satış modülü beş yapısal ihtiyacı karşılıyor mu? Yukarıdaki kontrol sorularıyla test edilir.
3. Eksik parça geliştirmeyle kapanır mı, kapanırsa bakımı kimde? Geliştirme bedeli kadar sürüm yükseltmelerindeki bakım yükü de hesaplanır.
4. Satış ekibi o arayüzü günlük olarak kullanır mı? Kullanmayacağı bir sistem teknik olarak yeterli olsa bile çözüm üretmez.

Dört sorunun cevabı genellikle şu sonucu verir: ERP mali tarafta kalır, satış tarafı ayrı yönetilir ve ikisi satış anında birbirine bağlanır. Bu, iki ayrı sistem kullanmak anlamına gelir ama iki ayrı gerçek üretmek anlamına gelmez — yeter ki kayıt sahipliği tablosu doldurulmuş olsun.

Firma profiline göre üç senaryo

Üçüncü satırdaki ayrım terminolojik olarak sık karışır: taşeron hakedişi imalat karşılığıdır ve proje yönetimi tarafına aittir; satış komisyonu ise satış karşılığıdır ve satış tarafında hesaplanıp ERP'ye ödeme için geçer. Çok projeli yapılarda satış tarafının nasıl ayrıştırılacağı çok projeli satış ekibi rehberinde ele alınmıştır.

Entegrasyon sırası: önce hangi akış kurulur?

Tüm akışları aynı anda kurmaya çalışmak projeyi uzatır. Değer sırasına göre dört adım yeterlidir.

1. Müşteri ve cari hesap. Satışta açılan müşterinin ERP'de cari olarak oluşması. En çok çifte veri girişini bu adım ortadan kaldırır.
2. Satış ve ödeme planı. Kesinleşen satışın bedeli ve taksit takvimiyle ERP'ye geçmesi.
3. Tahsilat yansıması. ERP'de işlenen ödemenin satış tarafındaki daire ve müşteri kaydına dönmesi. Bu adım satış ekibinin muhasebeyi aramasını bitirir.
4. Komisyon ve fatura durumu. Komisyonun ödemeye, fatura bilgisinin satışa akması.

Üçüncü adım en çok fark yaratanıdır ve sıklıkla en sona bırakılır. Bağlantı yöntemlerinin teknik karşılaştırması ve kurulum süreci CRM muhasebe entegrasyonu yazısındadır.

Kararı kim verir?

Kapsam sınırı tek bir birimin kararı değildir ve tek birime bırakıldığında öngörülebilir biçimde eğilir. Finans tek başına karar verdiğinde satış öncesi zincir yok sayılır; satış tek başına karar verdiğinde mali tutarlılık gözden kaçar; bilgi işlem tek başına karar verdiğinde entegrasyonun teknik maliyeti öne çıkar, operasyonel gerçek geri planda kalır.

Pratik kurulum: kayıt sahipliği tablosunu satış yönetimi ile finans birlikte doldurur, bilgi işlem her satırın teknik olarak uygulanabilirliğini işaretler, yönetim onaylar. Tablo onaylandıktan sonra tek bir kural kalır: bir veri tipinin sahibi değiştirilecekse bu karar yeniden aynı masada alınır.

Evon bu sınırın neresinde duruyor?

Evon'un modül listesinde satış tarafında Envanter Motoru, Bağımsız Bölüm Yönetimi, Durum Yönetimi, Fiyat Listesi Yönetimi, Ödeme Planları, Teklif ve Rezervasyon Yönetimi ile Komisyon Hesaplama ve Hakediş Yönetimi; bağlantı tarafında ERP Entegrasyonları, Muhasebe Programı Entegrasyonları, Banka Entegrasyonları, API Entegrasyonları ve Otomatik Veri Senkronizasyonu bulunmaktadır. Finans tarafında ayrıca Cari Hesap Yönetimi, Borç ve Alacak Takibi, Nakit Akışı Yönetimi ile Finansal Dashboard modülleri yer alır.

Son cümledeki modüllerin varlığı, bunların sizin ERP'nizin yerine geçtiği anlamına gelmez; hangi işlevin hangi sistemde kalacağı yine bu yazıdaki kayıt sahipliği kararıdır. Mevcut ERP'niz veya muhasebe yazılımınızla hangi akışların hazır entegrasyonla, hangilerinin geliştirmeyle kurulabildiği ve senkronizasyonun hangi yönde çalıştığı demo aşamasında kendi sistem adınızla doğrulanmalıdır.

Veri sözlüğü: aynı kelime, iki farklı anlam

Mutabakat farklarının önemli bir kısmı entegrasyon hatasından değil tanım farkından doğar. Aynı kelime iki sistemde farklı şeyi işaret ettiğinde, veri doğru aksa bile rakamlar tutmaz.

Üçüncü satır en çok tartışma üretenidir: satış "müşterinin bakiyesi şu kadar" derken toplam kalan borcu, finans ise vadesi gelmiş alacağı kastediyor olabilir. İki rakam da doğrudur ve aynı tabloda yan yana konulduğunda sistem hatalı görünür.

Çözüm basittir: kayıt sahipliği tablosuyla birlikte kısa bir veri sözlüğü yazmak. Her terimin tek bir tanımı olur, raporlarda hangi tanımın kullanıldığı başlıkta belirtilir. Ödeme planı kaynaklı tanımların netleşmesi için ödeme planı rehberi, envanter terimleri için envanter yönetimi yazısı referans alınabilir.

Sıfırdan kuruyorsanız: önce hangisi?

Henüz ikisi de yoksa sıra sorusu ortaya çıkar. Pratik cevap, firmanın hangi aşamada olduğuna göre değişir.

• Satış başlamak üzereyse önce satış yazılımı. Lansman öncesinde ön talep toplanıyor, fiyat listesi kuruluyor ve envanter tanımlanıyorsa, bu verinin ilk günden yapılandırılmış biçimde birikmesi gerekir. Muhasebe tarafı bir süre mevcut yazılımla yürütülebilir. Lansman adımları konut projesi lansman süreci yazısındadır.
• Mali hacim büyüdüyse önce ERP. Çok şirketli yapı, yoğun satın alma ve maliyet muhasebesi varsa mali tarafın oturması önceliklidir; satış tarafı geçici olarak daha hafif bir yapıyla yürütülebilir — ancak bu dönemin süresi baştan belirlenmelidir.
• İkisi birden kurulacaksa sıra yine satıştan başlar. Çünkü ERP'ye akacak verinin kaynağı satıştır; kaynak yapılandırılmadan kurulan entegrasyon, eksik veriyi taşır.

Hangi sırayla kurulursa kurulsun, ilk sistemden ikincisine geçerken verinin taşınabilir biçimde tutulması gerekir; bu disiplin kurulmadığında ikinci sistem devreye alınırken veri yeniden üretilmek zorunda kalır. Göç tarafının nasıl planlandığı CRM değiştirme ve veri göçü yazısında, Excel'den sistemli yapıya geçiş bu yazıda ele alınmıştır.

Maliyet tarafında karşılaştırma yapılacaksa iki sistemin toplam sahip olma maliyeti ayrı ayrı hesaplanmalı ve entegrasyon kalemi unutulmamalıdır; hesabın kurulumu gayrimenkul CRM fiyatları ve CRM ROI yazılarında ele alınmıştır. Satış yazılımı tarafında değerlendirme kriterlerinin tamamı ise CRM programı seçerken yazısındadır.

Sık yapılan sekiz hata

1. Soruyu "hangisi" diye sormak. İki sistem aynı işi yapmaz; soru sınırın nerede olduğudur.
2. Kayıt sahipliğini yazıya dökmemek. Entegrasyon kurulsa bile iki tarafta düzenleme yapılabildiğinde tutarsızlık sürer.
3. ERP'de satış modülü var diye yeterli saymak. Modülün varlığı değil, beş yapısal ihtiyacı karşılaması belirleyicidir.
4. Geliştirmenin bakım yükünü hesaplamamak. Özel geliştirme sürüm yükseltmelerinde maliyet üretir.
5. Satış ekibinin arayüz gerçeğini atlamak. Kullanılmayan sistem teknik olarak yeterli olsa bile çözüm değildir.
6. Tahsilat yansımasını en sona bırakmak. Danışman bakiyeyi göremediği sürece muhasebeyi aramaya devam eder.
7. Taşeron hakedişi ile satış komisyonunu aynı başlıkta tutmak. Farklı süreçler, farklı sistemler.
8. Mutabakatı ritme bağlamamak. Farklar birikir ve kaynağı aylar sonra bulunamaz.

Sık Sorulan Sorular

ERP ile CRM arasındaki fark nedir?

En pratik ayrım zaman eksenindedir: satış yazılımı satış gerçekleşmeden önceki zinciri (lead, görüşme, envanter durumu, teklif, opsiyon, fiyat ve ödeme planı kurgusu) yönetir; ERP satış sonrasında doğan mali yükümlülükleri (cari hesap, fatura, tahsilatın muhasebeleştirilmesi, maliyet, nakit akışı) yönetir. İkisi satışın kesinleştiği anda kesişir. Kategorilerin ayrıntılı tanımı için inşaat CRM nedir yazısına bakılabilir.

ERP'si olan bir firma CRM almak zorunda mı?

Zorunlu değil. Belirleyici olan ERP'nin satış modülünün beş yapısal ihtiyacı karşılayıp karşılamadığıdır: bağımsız bölümün tekil varlık olarak tutulması, opsiyon ve rezervasyon durumu, çift satış kontrolü, fiyat listesi versiyonu ve satış öncesi zincirin kaydı. Hepsi karşılanıyorsa ayrı bir sistem gerekmez; eksikler varsa bunların geliştirmeyle mi ayrı sistemle mi kapatılacağı maliyet ve bakım yükü karşılaştırmasıdır.

Müşteri kaydı hangi sistemde açılmalı?

Tipik kurgu müşterinin satış tarafında açılıp ERP'ye cari hesap olarak aktarılmasıdır; çünkü kayıt satış sürecinde, çoğu zaman satış kesinleşmeden önce oluşur. Bu kurgu seçildiğinde ERP'de elle müşteri açma yetkisi kapatılmalıdır — aksi halde iki kayıt zamanla birbirinden uzaklaşır.

Tahsilat bilgisi satış ekibine açılmalı mı?

Açılmalı ama salt okunur olarak. Danışmanın müşterinin bakiyesini ve geciken taksitini görmesi, müşteriyle konuşan tarafın bilgili olmasını sağlar. Kaydın kendisi ERP'de tutulur; satış tarafında yalnızca yansır. Bu yansıtma akışı kurulmadığında danışman her sorusu için muhasebeyi aramak zorunda kalır.

Senet ve çek kayıtları hangi tarafta tutulmalı?

Tek doğru cevabı yoktur ve firmanın operasyonuna göre değişir. Belirleyici soru şudur: vadesi yaklaşan evrak için müşteriyi kim arıyor? Arayan taraf satış ekibiyse kaydın satış tarafında tutulup ERP'ye aktarılması takibi hızlandırır; mali portföy yönetimi öne çıkıyorsa master ERP tarafında kalır. Hangisi seçilirse seçilsin yazılı olması ve tek olması gerekir.

İki sistem arasındaki farkı nasıl kontrol ederim?

Aylık dört karşılaştırma yeterlidir: satılan bağımsız bölüm adedi, toplam satış bedeli, tahsil edilen tutar ve açık bakiye. Her farkın işaret ettiği kaynak bellidir — adet farkı satış kesinleşme tanımını, bedel farkı tek tarafta kalmış indirimi, tahsilat farkı yansıtma gecikmesini, bakiye farkı ödeme planı değişikliklerinin aktarılmadığını gösterir.

Entegrasyonu kurmazsak ne olur?

Sistemler çalışmaya devam eder ama aradaki iş insana kalır: müşteri iki kez açılır, bakiye telefonla sorulur, ay sonunda rakamlar elle karşılaştırılır. Bu maliyet faturada görünmediği için genellikle hesaplanmaz; oysa danışman ve muhasebe tarafında haftalık saat olarak ölçülebilir ve çoğu firmada entegrasyon bedelinin üzerine çıkar.

Sonuç

ERP ile satış yazılımı arasındaki tercih bir "ya o ya bu" sorusu değildir. İki sistem aynı zincirin farklı uçlarını tutar ve yalnızca satışın kesinleştiği anda kesişir. Bu nedenle verilmesi gereken karar hangi yazılımın alınacağı değil, her veri tipinin kayıt sahibinin kim olacağıdır.

Pratikte iki adım yeterlidir. Birincisi kayıt sahipliği tablosunu doldurup satış yönetimi, finans ve bilgi işlemin birlikte onaylaması; sahibi belirlenmemiş her satır gelecekteki bir tutarsızlıktır. İkincisi entegrasyonu değer sırasına göre kurmak: müşteri–cari eşleşmesi, satış ve ödeme planının aktarımı, tahsilatın satışa yansıması, son olarak komisyon ve fatura durumu. Bu iki adım yapıldığında iki ayrı sistem kullanmak iki ayrı gerçek üretmez.

İlgili Yazılar

Konut Projesinde Müşteri Memnuniyeti Nasıl Ölçülür? Konutta Sözleşme Devri: Müşteri Daireyi Teslimden Önce Satmak İsterse Ne Olur? Satış Kampanyası Nasıl Kurgulanır? Kapsam, Süre, Bitiş ve Ölçüm