Logo Tiger, Netsis ve Mikro ile Çift Yönlü Entegre Özel CRM Yazılımı Geliştirme Rehberi

Logo Tiger, Logo Netsis veya Mikro kullanan B2B şirketlerde satış süreci çoğu zaman standart bir CRM’in öngördüğünden daha karmaşıktır. Müşteriye özel fiyatlar, çok kademeli onaylar, bölgesel sorumluluklar, vadeler, risk limitleri, stok rezervasyonları ve sipariş istisnaları aynı akışta buluşabilir. Hazır CRM kalıpları bu işleyişi karşılamadığında ekipler Excel dosyalarına, e-postalara ve tekrar veri girişine yönelir. Sonuç; geciken teklifler, farklı sistemlerde çelişen kayıtlar ve kimin hangi işlemi yaptığı belirsiz süreçlerdir.

Çözüm, ERP’nin yerine yeni bir sistem kurmak değildir. Doğru yaklaşım; ERP’nin finansal ve operasyonel ana veri rolünü koruyan, satış deneyimini ise şirketin gerçek süreçlerine göre modelleyen özel CRM yazılımıdır. Logo’nun entegrasyon çözümü de müşteri, sipariş, stok ve fatura gibi verilerin merkezî biçimde toplanmasını ve ERP çözümleriyle çift yönlü paylaşılmasını öne çıkarır. Bu yaklaşımın ürün tarafındaki karşılığı Logo Veri Toplama ve Entegrasyon açıklamasında görülebilir.

Özel CRM–ERP entegrasyonu ne anlama gelir?

Çift yönlü entegrasyon, her verinin iki sistem arasında sınırsızca kopyalanması değildir. Hangi kaydın hangi sistemde oluşturulacağı, hangi alanın nerede değiştirilebileceği ve değişikliğin karşı tarafa ne zaman aktarılacağı önceden belirlenir. Örneğin CRM yeni bir satış fırsatının ve teklif taslağının çalışma alanı olabilir; onaylanan sipariş ERP’ye aktarılır. ERP’de kesinleşen stok, risk, sevkiyat ve tahsilat durumları ise CRM’e geri döner.

Böylece satış temsilcisi müşterinin güncel bakiyesini, kullanılabilir stok bilgisini ve sipariş durumunu ayrı ekranlarda aramak zorunda kalmaz. Finans veya operasyon ekibi de CRM kaynaklı siparişleri yeniden yazmaz. Ancak bu faydayı sağlayabilmek için entegrasyon, yalnızca teknik bağlantı olarak değil; veri sahipliği, süreç kontrolü ve hata yönetimi birlikte düşünülerek tasarlanmalıdır.

İlk adım: Süreç ve gereksinim analizi

Proje, ekran çizimleriyle değil mevcut işleyişin incelenmesiyle başlamalıdır. Satış temsilcisinin müşteri açma talebinden tahsilat görünürlüğüne kadar izlediği yol belgelenir. Sürece satış, finans, operasyon, depo, BT ve ERP sorumluları birlikte katılmalıdır. Her ekip yalnızca kullandığı ekranları değil, beklediği kontrolleri ve karşılaştığı istisnaları da açıklamalıdır.

Analiz sırasında aşağıdaki sorulara somut yanıtlar aranır:

• Yeni müşteri veya cari kartı kim tarafından, hangi onayla açılıyor?
• Ürün, fiyat, iskonto, vade ve stok bilgilerinin güvenilir kaynağı hangisi?
• Teklif hangi koşullarda siparişe dönüşüyor ve hangi onaylardan geçiyor?
• Risk limiti, kapalı hesap, stok yetersizliği veya geçersiz fiyat nasıl ele alınıyor?
• Tahsilat ve sevkiyat bilgisinin CRM’de hangi ayrıntı düzeyinde gösterilmesi gerekiyor?
• Hangi kullanıcı hangi şirket, şube, bölge, müşteri veya belgeye erişebiliyor?

Bu çalışma sonucunda kapsam, kullanıcı rolleri, iş kuralları, veri sözlüğü ve entegrasyon kataloğu ortaya çıkar. Kumsal Ajans’ın projeye özel web yazılım geliştirme yaklaşımı, kullanıcı ihtiyacını ve kurumsal işleyişi ortak bir ürün mimarisinde ele almak için uygun bir çerçeve sunar.

Veri sahipliği matrisi oluşturun

Entegrasyondaki en kritik karar, her veri nesnesinin ana sahibini belirlemektir. “Her iki sistem de güncelleyebilir” kararı pratik görünse de çatışma üretir. Cari unvan, vergi bilgisi, muhasebe kodu ve risk limiti çoğunlukla ERP’nin kontrolünde kalmalıdır. CRM; satış sorumlusu, ziyaret notu, fırsat aşaması, aktivite ve teklif çalışma sürümleri gibi satış odaklı verileri yönetebilir.

Ürün kodu, birim, vergi oranı ve resmî stok miktarı ERP’den gelmeli; CRM bunları yetkili kullanıcıya okunabilir biçimde sunmalıdır. Fiyat konusunda ise tek bir sayı yerine fiyat listesi, müşteri anlaşması, para birimi, miktar basamağı, geçerlilik tarihi ve iskonto sırası değerlendirilmelidir. Benzer kural çatışmalarının nasıl modellenebileceği, özel fiyat ve iskonto kuralları rehberinde ayrıntılı olarak ele alınır.

Çift yönlü veri akışları nasıl modellenir?

Müşteri ve cari kart akışı

CRM’de oluşturulan potansiyel müşteri doğrudan ERP’de cari karta dönüşmemelidir. Vergi numarası, iletişim bilgisi ve mükerrer kayıt kontrollerinden geçen talep, yetkili onayından sonra ERP’ye gönderilebilir. ERP’nin ürettiği cari kod CRM kaydına bağlanır. Daha sonraki kritik değişiklikler için alan bazlı yetki uygulanır; örneğin satış ekibi teslimat adresi talep edebilir ancak risk limiti değiştiremez.

Ürün, fiyat ve stok akışı

CRM, ERP’den yalnızca ürün listesini değil satış kararını etkileyen bağlamı da almalıdır. Aktiflik durumu, birim dönüşümü, varyant, depo, kullanılabilir miktar ve fiyatın geçerlilik tarihi buna dahildir. Stok verisinin anlık mı, belirli aralıklarla mı güncelleneceği iş ihtiyacına göre seçilir. Yüksek sipariş hacminde ekranda görülen stok ile sipariş anındaki ERP kontrolü ayrı değerlendirilmelidir.

Teklif ve sipariş akışı

Teklif CRM’de sürümlü olarak hazırlanmalı; ürün, miktar, fiyat, iskonto, ödeme koşulu ve teslimat bilgileri kaydedilmelidir. Onaylanan sürüm değiştirilemez bir anlık görüntü olarak korunur. Sipariş aktarımında CRM benzersiz bir işlem anahtarı gönderir. Aynı istek ağ kesintisi nedeniyle yeniden denendiğinde ERP’de ikinci sipariş oluşmamalıdır. ERP kabulü sonrasında belge numarası, durum ve hata mesajı CRM’e dönmelidir.

Tahsilat ve durum akışı

Tahsilat kaydının finansal sahibi ERP’dir. CRM, satış ekibine yalnızca görevini yerine getirmesi için gereken bakiye, vade, gecikme ve ödeme durumu bilgisini göstermelidir. Banka hesabı veya muhasebe fişi gibi gereksiz ayrıntıların aktarılması veri riskini büyütür. Siparişin onaylandı, hazırlanıyor, kısmen sevk edildi veya kapandı gibi durumları da ortak bir durum sözlüğüyle eşleştirilmelidir.

Logo Tiger, Netsis ve Mikro için bağlantı yaklaşımı

Tek bir entegrasyon yöntemi bütün kurulumlara uygulanamaz. ERP ürünü kadar kullanılan sürüm, lisanslar, şirket yapısı, kurulum modeli, mevcut özelleştirmeler ve iş ortağı politikaları da bağlantı seçimini etkiler. Logo Tiger veya Netsis tarafında desteklenen uyarlama ve entegrasyon araçları; Mikro tarafında ise kurulumla uyumlu API olanakları değerlendirilmelidir. Mikro’nun resmî dokümantasyonu, ERP entegrasyonuna yönelik REST uçlarını ve OpenAPI tanımını yayımlar; teknik kapsam güncel kurulum için MikroAPI dokümantasyonundan doğrulanmalıdır.

Doğrudan ERP veritabanına kontrolsüz yazma, kısa vadede hızlı görünse de iş kurallarını atlama, veri bütünlüğünü bozma ve sürüm yükseltmelerinde kırılma riski taşır. Desteklenen API, servis veya üretici uyarlama katmanı tercih edilmelidir. Zorunlu okuma senaryolarında dahi erişim salt okunur tutulmalı, sorgu yükü sınırlandırılmalı ve üretici desteği teyit edilmelidir. CRM ile ürünlere özgü bağlantılar arasına bir entegrasyon katmanı koymak, Tiger, Netsis ve Mikro farklılıklarının iş uygulamasına yayılmasını engeller.

Güvenilir senkronizasyonun teknik kuralları

Çift yönlü akışlarda bağlantının kurulması yeterli değildir; işlemin güvenli biçimde tamamlandığı kanıtlanmalıdır. Her mesaj benzersiz kimlik, kaynak sistem, zaman damgası, kayıt sürümü ve ilişkilendirme anahtarı taşımalıdır. Aktarım sonucu “bekliyor, işlendi, reddedildi, yeniden denenecek” gibi açık durumlarla izlenmelidir.

• Tekrarlanan istekler aynı sonucu üretmeli ve mükerrer belge oluşturmamalıdır.
• Geçici bağlantı hataları kontrollü aralıklarla yeniden denenmelidir.
• İş kuralı hataları otomatik tekrar yerine görev kuyruğuna alınmalıdır.
• Alan eşleştirmeleri ve kod dönüşümleri sürümlü biçimde saklanmalıdır.
• Başarılı ve başarısız işlemler ilişkilendirme kimliğiyle uçtan uca izlenmelidir.
• Toplu senkronizasyonlar sayfalama, hız sınırı ve kaldığı yerden devam mekanizması kullanmalıdır.

Örneğin ERP “cari hesap kapalı” yanıtı verdiğinde sistem bunu genel bir teknik hata gibi göstermemelidir. Satış kullanıcısına anlaşılır açıklama sunulmalı, kayıt sorumlu ekibin kuyruğuna yönlendirilmeli ve düzeltme sonrasında güvenli biçimde yeniden çalıştırılmalıdır.

Rol, yetki ve veri güvenliği

CRM’de menüyü gizlemek gerçek yetkilendirme değildir. Kontrol; API uç noktası, işlev, kayıt ve alan seviyelerinde sunucu tarafında uygulanmalıdır. Bir satış temsilcisi yalnızca kendi bölgesindeki carileri görebilirken yönetici tüm ekibi izleyebilir; finans rolü risk ve tahsilat alanlarına erişebilir. İhracat, toplu fiyat güncelleme ve sipariş iptali gibi kritik işlemler ayrıca sınırlandırılmalıdır.

OWASP, API’lerde nesne ve işlev düzeyinde eksik yetkilendirmeyi önemli riskler arasında gösterir. Bu nedenle rol matrisi yalnızca arayüz tasarımında değil, her servis çağrısında uygulanmalı; varsayılan erişim kapalı olmalı ve gerekli izin açıkça verilmelidir. Güncel risk başlıkları OWASP API Security Top 10 üzerinden incelenebilir.

Aktarım kanalları şifrelenmeli, erişim anahtarları kod içinde tutulmamalı, kişisel ve ticari veriler gereksiz yere çoğaltılmamalıdır. Denetim izi; kullanıcıyı, zamanı, eski ve yeni değeri, kaynak sistemi ve işlem sonucunu kaydetmelidir. Log kayıtlarında parola, erişim anahtarı veya gereksiz kişisel veri bulunmamalıdır. Yedekleme, saklama süresi, erişim gözden geçirmesi ve olay müdahale sorumlulukları proje kapsamında tanımlanmalıdır.

Test ve devreye alma planı

Entegrasyon testleri yalnızca başarılı örneklerle tamamlanamaz. Mükerrer cari, pasif ürün, geçersiz fiyat, yetersiz stok, kapalı dönem, zaman aşımı, kısmi aktarım ve yetkisiz erişim gibi senaryolar denenmelidir. Test ortamındaki kodlar, şirket yapısı ve özelleştirmeler üretime yeterince yakın olmalıdır. Kişisel veriler kullanılacaksa maskeleme uygulanmalıdır.

Devreye alma öncesinde başlangıç verisinin nasıl taşınacağı belirlenir. Hangi carilerin ve ürünlerin CRM’e alınacağı, eski tekliflerin aktarılıp aktarılmayacağı ve sistemler arası anahtarların nasıl eşleştirileceği karara bağlanır. Pilot ekip veya sınırlı müşteri grubu ile başlamak, hataların kontrollü biçimde görülmesini sağlar. Geçiş penceresi, geri dönüş planı, destek sorumluları ve başarı ölçütleri önceden açıklanmalıdır.

Canlı kullanım sonrasında senkronizasyon gecikmesi, hata oranı, yeniden deneme sayısı, mükerrer kayıt, manuel müdahale ve sipariş kabul süresi izlenmelidir. Bu göstergeler entegrasyonun yalnızca çalışıp çalışmadığını değil, operasyonu gerçekten iyileştirip iyileştirmediğini gösterir.

Doğru proje çıktısı nasıl görünür?

Başarılı özel CRM projesinin çıktısı yalnızca ekranlardan oluşmaz. Kurumun süreç haritası, veri sahipliği matrisi, rol ve yetki modeli, entegrasyon sözleşmeleri, hata kataloğu, test senaryoları, devreye alma planı ve işletim dokümantasyonu aynı teslimatın parçalarıdır. Modern ve sürdürülebilir mimari sayesinde ERP sürümü veya süreç değiştiğinde bütün uygulamayı yeniden yazmak yerine ilgili bağlantı ve kural katmanı güncellenebilir.

Kumsal Ajans, İstanbul merkezli bir dijital ajans olarak kurumların gerçek işleyişine göre özel web yazılımları ve kurumsal kaynak planlama çözümleri tasarlar. Logo Tiger, Logo Netsis veya Mikro altyapınızla uyumlu özel CRM kapsamını; veri sahipliği, çift yönlü senkronizasyon kuralları, yetkiler, hata senaryoları ve devreye alma adımlarıyla birlikte planlamak için Kumsal Ajans ile iletişime geçin.