Kurumsal Web Sitesi Entegrasyonları: CRM, ERP ve Chatbot Bağlantısı Nasıl Kurulur?

Kurumsal bir sitede web sitesi entegrasyonu, siteyi CRM, ERP ve chatbot gibi iş sistemlerine bağlayan veri köprülerinin tamamıdır. Bu yazıda o köprülerin mimarisini anlatıyorum: API, webhook, ara katman (iPaaS), ERP stok ve fiyat senkronu, chatbot devri ve güvenlik. Kısacası, hangi sistemin neyin sahibi olduğunu ve verinin hangi yoldan aktığını birlikte kuracağız.

Kurumsal web sitesi entegrasyonu nedir?

Kurumsal web sitesi entegrasyonu, sitenin CRM, ERP, chatbot ve benzeri iş yazılımlarıyla API, webhook veya ara katman üzerinden otomatik veri alışverişi yapmasıdır. Amaç, aynı bilgiyi iki kez girmemek, stok, fiyat ve müşteri kaydını tek doğru kaynaktan beslemek ve her sistemin kendi işini yapmasını sağlamaktır.

2012'den beri kurumsal projelerde gördüğüm tablo hep benzer. Site bir yerde, muhasebe programı başka yerde, satış ekibi ise Excel dosyalarında yaşıyor. Ancak müşteri bu ayrımı görmez; sitede gördüğü fiyatın, stok bilgisinin ve temsilcinin söylediğinin tutarlı olmasını bekler. Entegrasyon bu beklentiyi karşılayan sessiz altyapıdır.

Bu yazı form verisinin CRM'e düşmesini adım adım anlatan bir rehber değil. Form tarafının kurgusunu randevu, teklif ve demo formu tasarımı yazısında ele aldım. Burada daha geniş resme bakıyoruz: sistemlerin birbirine nasıl bağlandığına.

Siteye hangi sistemleri bağlamalısınız ve neden?

Her şirketin sistem haritası farklıdır; yine de kurumsal projelerde en sık karşılaştığım bağlantılar şunlar:

• CRM: müşteri, fırsat ve görev kayıtlarının sahibi. Site buraya kişi ve talep gönderir.
• ERP: ürün, stok, fiyat, cari hesap ve sipariş kayıtlarının sahibi. Site buradan veri okur, sipariş yazar.
• Chatbot ve canlı destek: ziyaretçiyle ilk teması kurar, gerektiğinde insana devreder.
• E-posta pazarlama aracı: bülten ve otomasyon listelerini tutar.
• Ödeme ve kargo servisleri: tahsilat ve teslimat durumunu bildirir.

Neden bağlarız? Çünkü elle aktarım hem yavaş hem hatalıdır. Örneğin fiyat listesini ayda bir siteye elle giren bir sanayi firması, kur değiştiği hafta yanlış fiyatla teklif almaya başlar. Üstelik hatayı genellikle müşteri fark eder, şirket değil.

Entegrasyonda "tek doğru kaynak" ilkesi ne demek?

Her veri türünün tek bir sahibi olmalıdır. Stokun sahibi ERP ise sitede stok elle değişmez; müşteri iletişim bilgisinin sahibi CRM ise ERP'deki kopyayı oradan beslersiniz. Bu ilkeyi projenin ilk gününde bir tabloya yazmanızı öneririm.

Sahipliği belirlemeden başlayan projelerde en sık gördüğüm sorun çift yönlü çakışmadır. Müşteri telefon numarasını sitede değiştirir, ERP'de eskisi kalır, ardından gece senkronu eski numarayı geri yazar. Dolayısıyla "kim yazar, kim okur" sorusu teknik değil, yönetsel bir karardır.

API, webhook ve ara katman arasındaki fark nedir?

Üç kavram sık karışır, bu yüzden kısaca ayıralım. API, bir sistemin dışarıya açtığı kapıdır; siz sorarsınız, o cevap verir. Webhook ise tersidir: bir olay olduğunda sistem size haber verir. Ara katman (iPaaS veya kendi yazdığınız bir servis) ise bu kapıların arasında duran, veriyi çeviren ve yönlendiren trafik polisidir.

Seçimi yaparken karşı sistemin ne sunduğuna da bakın. Bazı CRM'ler güçlü webhook desteği verir, bazı yerel ERP'ler ise yalnız sorgulanabilir bir API sunar. Yani yöntemi çoğu zaman siz değil, bağlandığınız sistem belirler; sizin işiniz o kısıtın etrafında sağlam bir akış kurmaktır.

Pratikte çoğu kurumsal proje bunların karışımıdır. Örneğin kataloğu gece API ile çekersiniz, ödeme onayı webhook ile gelir, CRM akışı ise bir ara katmandan geçer.

Noktadan noktaya mı, merkezi ara katman mı?

İki sistem varsa noktadan noktaya bağlantı yeterlidir: site doğrudan CRM'in API'sine konuşur. Ancak sistem sayısı arttıkça bağlantı sayısı hızla büyür. Dört sistemi birbirine doğrudan bağlarsanız altı ayrı köprü yazarsınız ve her birinin hata yönetimi ayrıdır.

Merkezi yaklaşımda her sistemi yalnız ara katmana bağlarsınız. Böylece CRM'i değiştirdiğinizde sitenin koduna dokunmazsınız; yalnız ara katmandaki bağlayıcıyı değiştirirsiniz. Benim kuralım basit:

• İki sistem ve düşük hacim: doğrudan API, sade kod.
• Üç veya daha fazla sistem: ara katman, tek izleme ekranı.
• Özel iş kuralı yoğunsa (bayi fiyatı, iskonto matrisi): kendi servisiniz.

Mimari tarafında siteyi parçalara ayırmayı düşünen büyük ekipler için micro frontend mimarisi yazısı da iyi bir tamamlayıcıdır; entegrasyon katmanını ön yüzden ayırmak orada da temel kuraldır.

iPaaS araçları ne zaman mantıklı?

iPaaS (Integration Platform as a Service), hazır bağlayıcılarla sistemleri kod yazmadan veya az kodla bağlayan bulut servislerinin genel adıdır. Zapier, Make ve n8n KOBİ tarafında sık karşılaştığım örneklerdir; kurumsal tarafta daha kapsamlı platformlar da vardır.

Bu araçlar hız kazandırır. Üstelik iş ekibi basit bir akışı yazılımcı beklemeden kurabilir. Öte yandan üç riski baştan konuşmanız gerekir:

• Maliyet: çoğu aracın fiyatı işlem sayısına bağlıdır; hacim arttıkça fatura da büyür.
• Belgesiz akışlar: kimsenin belgelemediği otomasyonlar bir gün sessizce durur.
• Veri yeri: kişisel veri üçüncü bir hizmetten geçer, bu nedenle sözleşme ve aydınlatma metinlerinizde bunu hesaba katmalısınız.

Saha tecrübeme dayanan kaba bir sınır çizeyim, garanti değil: akış sayısı bir elin parmaklarını geçmiyorsa ve hacim düşükse iPaaS iyi başlangıçtır. Akışlar iş kuralıyla dolmaya başladığında ise kendi servisinize geçmeyi planlayın.

ERP ile stok ve fiyat senkronunu nasıl kurarsınız?

ERP entegrasyonunda ilk soru hangi alanların, ne sıklıkla ve hangi yönde akacağıdır. Ben işe ERP'deki ürün kartını satır satır okuyarak başlarım; stok kodunu, birimi, KDV oranını, liste fiyatını ve varsa bayi fiyatını ayrı ayrı eşleştiririm.

Ardından senkron sıklığına karar veririz. Katalog ve açıklamalar günde bir yeterli olabilir. Stok ise satış hızına bağlıdır: yavaş dönen sanayi ürünlerinde saatlik güncelleme çoğu zaman yeter, hızlı tükenen e-ticaret ürünlerinde anlık veya dakikalık akış gerekir.

1. Alan eşleme tablosunu çıkarın (ERP alanı, site alanı, dönüşüm kuralı).
2. İlk tam aktarımı test ortamında yapın ve rastgele 50 ürünü elle karşılaştırın.
3. Değişiklik odaklı (delta) senkrona geçin; yalnız değişen kayıtları taşıyın.
4. Her senkronun başlangıç, bitiş ve hata sayısını kaydedin.
5. Senkron durduğunda kime bildirim gideceğini yazın.

Bayi ve ihracat senaryolarını sanayi ve üretim firmaları için web tasarım yazısında ayrıca işledim; orada fiyatın kime görüneceği sorusu da var.

Siparişi ERP'ye yazarken nelere dikkat etmelisiniz?

Okumak kolaydır, yazmak risklidir. Siteden ERP'ye sipariş yazdığınızda artık muhasebe kayıtlarına dokunuyorsunuz; dolayısıyla hata payı sıfıra yakın olmalı.

İlk kural tekrar koruması (idempotency). Ağ kesildiğinde site aynı siparişi iki kez göndermeye çalışabilir. Bu yüzden her siparişe benzersiz bir anahtar verin ve ERP tarafında aynı anahtarla gelen ikinci kaydı reddedin. İkinci kural stok rezervasyonu: ödeme onayı gelmeden stoğu kesin düşmeyin, ama geçici olarak ayırın.

Üçüncüsü cari eşleştirmedir. Yeni bir müşteri geldiğinde ERP'de yeni cari mi açacaksınız, yoksa vergi numarasına göre mevcut kaydı mı bulacaksınız? Bu kararı muhasebe ekibiyle birlikte verin. Son olarak iade ve iptal akışını unutmayın; pek çok proje yalnız "mutlu yol"u kurar, iptali ise elle bırakır.

CRM entegrasyonunun mimari tarafını nasıl kurgulamalısınız?

CRM tarafında mimari soru şudur: site CRM'e doğrudan mı yazacak, yoksa arada bir kuyruk mu olacak? Doğrudan yazım basittir, ancak CRM birkaç dakika erişilemez olursa o aradaki talepler kaybolabilir.

Bu nedenle ben kurumsal projelerde siteyle CRM arasına basit bir kuyruk koyarım. Site talebi önce kendi veri tabanına kaydeder, ardından kuyruk CRM'e gönderir. CRM cevap vermezse kuyruk birkaç kez yeniden dener; yine başarısız olursa kayıt bir hata listesine düşer ve sorumluya bildirim gider. Böylece hiçbir talep sessizce kaybolmaz.

Alan eşleme, kaynak ve kampanya bilgisinin aktarımı ve lead atama kuralları bu yazının kapsamı dışında; bunlar ayrı bir yazının konusu. Kampanya etiketlerini doğru üretmek içinse UTM oluşturucu aracını kullanabilirsiniz. Mimari açıdan hatırlamanız gereken tek şey şu: CRM'e giden her kayıt, siteden bağımsız olarak da geri izlenebilmeli.

Chatbot entegrasyonunda insana devir nasıl işler?

Chatbot'un değeri, cevaplayamadığı anda ne yaptığında yatar. İyi bir devir akışında bot, konuşmayı bir temsilciye aktarırken üç şeyi birlikte taşır: konuşma özeti, ziyaretçinin kimlik bilgisi (izin verdiyse) ve hangi sayfadan geldiği.

Devrin tetikleyicilerini açıkça tanımlayın. Örneğin ziyaretçi "temsilci" veya "insan" yazdığında, bot iki kez üst üste anlamadığında ya da konu fiyat pazarlığı veya şikâyet olduğunda devir başlasın. Mesai dışında ise bot bunu dürüstçe söylemeli ve bir geri dönüş talebi oluşturmalı.

• Devir anında CRM bir görev açsın ve konuşma özetini göreve eklesin.
• Temsilci yanıt verene kadar ziyaretçi tahmini bekleme süresini görsün.
• Bot, stok veya fiyat sorusunu ERP'den gelen güncel veriyle yanıtlasın, tahminle değil.

Son madde kritik. Chatbot'un yanlış fiyat söylemesi, sitede yanlış fiyat yazmasından daha zararlıdır, çünkü müşteri bunu kişisel bir söz gibi algılar.

Web sitesi entegrasyonu güvenliğini nasıl sağlarsınız?

Entegrasyon, sitenizi iş sistemlerinizin kapısına bağlar; bu yüzden güvenlik ayrı bir başlığı hak ediyor. OWASP, API'lere özgü riskleri OWASP API Security Top 10 listesinde toplar; listenin başında nesne düzeyinde yetkilendirme hataları yer alır. Yani bir kullanıcının başkasına ait siparişi, yalnız numarasını değiştirerek görebilmesi.

Benim projelerde uyguladığım asgari kurallar şunlar:

• Her entegrasyon için ayrı ve dar yetkili bir kullanıcı veya uygulama anahtarı.
• Anahtarların kodda değil, sunucu ortam değişkenlerinde veya bir gizli anahtar kasasında durması.
• Gelen webhook'ların imzasının doğrulanması; imzasız isteği reddedin.
• Tüm trafiğin HTTPS üzerinden akması ve ERP'nin yalnız izin verilen IP'lerden erişime açık olması.
• Anahtarların belirli aralıklarla yenilenmesi ve eski anahtarın iptali.

Güçlü anahtar ve parola üretmek için şifre oluşturucu işinizi görür. Yetkilendirme tarafında pek çok modern API OAuth 2.0 standardını kullanır; ekibinizin bu akışı anladığından emin olun.

Webhook'lar neden bazen iki kez gelir?

Bu soru, entegrasyonu ilk kez kuran ekiplerin en sık şaşırdığı konudur. Webhook gönderen sistemler, karşı taraf zamanında başarılı yanıt vermezse bildirimi yeniden dener. Stripe'ın webhook dokümantasyonu da aynı olayın birden fazla kez gelebileceğini ve olay kimliğine göre tekrarları ayıklamanız gerektiğini açıkça belirtir.

Dolayısıyla alıcı tarafta üç alışkanlık edinin. Birincisi, gelen her olayın kimliğini kaydedin ve aynı kimlik ikinci kez gelirse işlemeyin. İkincisi, webhook'a hızlıca "aldım" yanıtı verin, ağır işi arka planda yapın. Üçüncüsü, olayların sırayla geleceğini varsaymayın; "iptal" bildirimi "oluşturuldu" bildiriminden önce gelebilir.

Bu küçük ayrıntıları atladığınızda tipik sonuç çift fatura, çift e-posta veya yanlış stok olur. Yani sorun kodda değil, varsayımdadır.

Entegrasyon sitenin hızını etkiler mi?

Doğru kurulursa etkilemez; yanlış kurulursa ciddi biçimde etkiler. En sık hata, sayfa her açıldığında ERP'ye canlı sorgu atmaktır. ERP yavaş cevap verdiğinde ürün sayfası da yavaşlar, üstelik ERP üzerindeki yük gereksiz yere artar.

Bunun yerine veriyi sitenin kendi veri tabanına veya önbelleğine senkronlayın ve sayfayı oradan besleyin. Canlı sorguyu yalnız gerçekten gereken anlara saklayın; örneğin sepete eklerken son stok kontrolü. Böylece hem ziyaretçi hızlı sayfa görür hem de ERP rahat nefes alır.

Chatbot ve takip betikleri de ayrı bir yük getirir. Bu betikleri sayfa yüklendikten sonra çağırın. Hızın arama görünürlüğüne etkisini site hızı SEO'yu nasıl etkiler yazısında ayrıntılı anlattım.

Hata olduğunda kim, nasıl haberdar olur?

Entegrasyonun en tehlikeli hali çalışmıyor olması değil, sessizce çalışmıyor olmasıdır. Bir senkron üç gün durur, kimse fark etmez, ardından müşteri stokta olmayan ürünü satın alır.

Bu nedenle her projede basit bir izleme düzeni kurarım:

1. Her akış için "son başarılı çalışma zamanı" kaydı.
2. Beklenen süre aşıldığında e-posta veya mesajla uyarı.
3. Başarısız kayıtların görüldüğü ve tek tuşla yeniden denenebildiği bir hata listesi.
4. Haftalık kısa bir özet: kaç kayıt aktı, kaçı hata verdi.

Uyarının kime gideceği teknik bir detay gibi durur, ama değildir. Stok senkronu durduğunda satış operasyonu, CRM akışı durduğunda satış müdürü haberdar olmalı. Kısacası sahiplik tablosunu izleme tarafına da taşıyın.

Entegrasyon projesi hangi sırayla ilerlemeli?

Her şeyi aynı anda bağlamaya çalışmak, en sık gördüğüm başarısızlık sebebidir. Ben aşağıdaki sırayı öneririm:

1. Keşif: sistem haritası, veri sahipliği tablosu, mevcut API'lerin ve lisansların kontrolü.
2. Tek yönlü okuma: önce ERP'den siteye katalog ve stok; risk düşük, fayda yüksek.
3. Siteden CRM'e yazma: talepler kayıpsız aksın.
4. Sipariş yazma: ERP'ye kontrollü yazım, tekrar koruması ve iptal akışıyla.
5. Chatbot ve otomasyonlar: altyapı oturduktan sonra.

Her aşamanın sonunda test ortamında gerçekçi verilerle deneme yapın, ardından canlıya alın. Böylece bir sorun çıktığında hangi adımdan kaynaklandığını hemen bilirsiniz. Sitenin kendisini de bu sırayla uyumlu tasarlamalısınız; web tasarım sürecinde entegrasyon noktalarını baştan konuşmamın nedeni de bu.

ERP'nin API'si yoksa ne yapılabilir?

Türkiye'de özellikle yerel muhasebe ve ERP yazılımlarında bu soruyla sık karşılaşıyorum. Her yazılımın modern bir web API'si yok; bazıları yalnız veri tabanı erişimi, dosya aktarımı veya ek ücretli bir modül sunar.

Seçenekleri güvenlikten ödün vermeyecek sırayla değerlendirin. Önce yazılım üreticisine resmi bir entegrasyon modülü olup olmadığını sorun. Ardından dosya tabanlı aktarımı düşünün: ERP belirli aralıklarla bir dosya üretir, entegrasyon servisi onu okur. En son seçenek, ERP veri tabanına yalnız okuma yetkili ve kısıtlı bir kullanıcıyla bağlanmaktır.

ERP veri tabanına doğrudan yazmaktan ise kaçının. Üreticinin iş kurallarını atlar, güncelleme sonrası bozulabilir ve destek hakkınızı riske atar. Kısacası yazma işlemleri için mutlaka resmi yolu tercih edin.

Entegrasyon maliyetini neler belirler?

Burada rakam vermeyeceğim, çünkü maliyet tamamen kapsamınıza bağlı. Ancak teklif karşılaştırırken bakmanız gereken kalemleri sayabilirim:

• Bağlayacağınız sistem sayısı ve her birinin API kalitesi.
• Akış yönü: yalnız okuma mı, yazma da var mı?
• İş kurallarının karmaşıklığı (bayi fiyatı, kampanya, çoklu depo).
• Ara katman lisansı veya iPaaS aylık ücreti.
• ERP ya da CRM tarafındaki ek modül ve kullanıcı lisansları.
• İzleme, bakım ve sürüm güncellemesi sorumluluğu.

Son kalem en çok atlanan kalemdir. CRM veya ERP sürüm yükselttiğinde entegrasyonun da güncellenmesi gerekebilir; bu nedenle bakım sözleşmesinde entegrasyonun kapsama girip girmediğini yazılı olarak netleştirin. Ölçülebilir bir hedef koymak içinse kurumsal web sitesinde dönüşüm hedefi yazısına göz atabilirsiniz.

E-ticaret tarafında web sitesi entegrasyonu nasıl farklılaşır?

E-ticarette entegrasyon sayısı ve hızı artar. Ödeme altyapısı, kargo firmaları, pazaryerleri ve e-fatura servisleri de akışa girer. Üstelik stok aynı anda hem sitede hem pazaryerinde satıldığı için senkron gecikmesi doğrudan iptal ve kötü yoruma dönüşür.

Bu yüzden e-ticarette merkezi bir stok kaynağı ve olay tabanlı (webhook) akış neredeyse zorunludur. Sipariş bir kanalda oluştuğu anda diğer kanallardaki stok düşmelidir. Ayrıca e-fatura ve kargo etiketi gibi yasal ve operasyonel adımların sırası da netleşmelidir. Bu kurguyu e-ticaret danışmanlığı kapsamında kanal kanal ele alıyorum.

Chatbot hangi verilere erişmeli, hangilerine erişmemeli?

Chatbot'u ERP ve CRM'e bağladığınızda ona bir tür çalışan yetkisi vermiş olursunuz. Bu nedenle yetkiyi en dar haliyle başlatın. Genel ürün bilgisi, stok durumu ve liste fiyatı çoğu zaman sorunsuzdur. Ancak müşteriye özel iskonto, cari bakiye veya başka bir müşterinin sipariş durumu gibi bilgiler ayrı bir kimlik doğrulaması olmadan asla bota açılmamalı.

Pratik bir yaklaşım şu: botu salt okuma yetkili, ayrı bir entegrasyon kullanıcısıyla bağlayın. Ziyaretçi sipariş durumunu sorarsa bot önce sipariş numarası ve e-posta gibi iki bilgiyi eşleştirsin, ardından yalnız o siparişin durumunu göstersin. Böylece bot yardımcı olur, ama bir veri sızıntısı kapısına dönüşmez.

Ayrıca botun ERP'ye yazma yetkisi olmamalı. Teklif veya sipariş talebi gelirse bot bunu CRM'de bir görev olarak açar, işlemi ise bir insan onaylar. Yani bot ön kapıda karşılar, kasaya ise dokunmaz.

Web sitesi entegrasyonu için dokümantasyonu nasıl tutmalısınız?

Entegrasyonu kuran kişi şirketten ayrıldığında geriye yalnız dokümantasyon kalır. Bu yüzden her projede kısa ama eksiksiz bir entegrasyon dosyası isterim. Uzun bir kitap değil; bir yeni ekip üyesinin bir öğleden sonrada okuyup anlayabileceği bir özet. Ayrıca bu dosyayı ekibin kolayca bulabileceği ortak bir klasörde saklayın, kişisel bir bilgisayarda değil.

• Sistem haritası: hangi sistem hangisine, hangi yöntemle bağlı.
• Veri sahipliği tablosu: her alanın sahibi ve akış yönü.
• Alan eşleme listesi ve dönüşüm kuralları (para birimi, birim, KDV).
• Anahtarların nerede durduğu (anahtarın kendisi değil, yeri) ve yenileme takvimi.
• Hata senaryoları ve her birinde kimin ne yapacağı.
• Sürüm geçmişi: hangi değişikliği kim, ne zaman yaptı.

Bu dosyayı canlı tutun. Her değişiklikte güncellemek beş dakika sürer; güncellemediğinizde ise bir sonraki arızada saatler kaybedersiniz. Kısacası dokümantasyon, entegrasyonun sigortasıdır.

Entegrasyonun şirket içindeki sahibi kim olmalı?

Teknik olarak entegrasyonu bir yazılımcı ya da ajans kurar. Ancak iş sahibi mutlaka şirketin içinden biri olmalı. Aksi halde bir sorun çıktığında herkes birbirini işaret eder: ajans ERP'yi, ERP firması siteyi, satış ekibi ise "sistemi" suçlar.

Ben genellikle iki rol tanımlarım. Birincisi iş sahibi: çoğu zaman operasyon veya satış müdürü; hangi verinin nereye akacağına o karar verir. İkincisi teknik sorumlu: şirket içi BT ekibinden biri ya da sözleşmeli bir destek; uyarıları o alır ve ilk müdahaleyi o yapar.

Bu iki kişiyi dokümantasyonun ilk sayfasına yazın. Üstelik yılda bir kez birlikte oturup akışları gözden geçirmelerini sağlayın; iş süreçleri değişir, entegrasyon da onlarla birlikte değişmelidir. Dijital tarafta birden fazla kanalı yöneten şirketlerde bu rol dağılımını bir danışmanla netleştirmek de zaman kazandırabilir.

Entegrasyonun işe yarayıp yaramadığını nasıl ölçersiniz?

Entegrasyon bir amaç değil, araçtır; dolayısıyla başarısını teknik değil, iş metrikleriyle ölçmelisiniz. Projeye başlamadan önce üç dört ölçüt seçin ve mevcut durumlarını not edin. Aksi halde altı ay sonra "işe yaradı mı?" sorusuna yalnız hislerle cevap verirsiniz.

• Talebin satış ekibine ulaşma süresi: formdan temsilciye kaç dakika?
• Stok kaynaklı sipariş iptali sayısı: ayda kaç sipariş "ürün yok" diye iptal oluyor?
• Elle veri girişine harcanan süre: ekip haftada kaç saati kopyala yapıştıra ayırıyor?
• Fiyat tutarsızlığı şikâyeti: sitede görünen ile faturadaki fiyat kaç kez farklı çıktı?

Bu ölçütleri entegrasyondan önce ve sonra aynı yöntemle ölçün. Örneğin iptal sayısını ERP raporundan, yanıt süresini CRM'deki kayıt ve ilk temas zamanından çekin. Böylece yatırımın karşılığını somut olarak görürsünüz; iyileşme yoksa da hangi akışa yeniden bakmanız gerektiğini bilirsiniz.

Bir not daha ekleyeyim: ölçüm verisini de tek doğru kaynaktan alın. Satış ekibinin tuttuğu Excel ile CRM raporu farklı rakam veriyorsa önce o farkı çözün, ardından karar verin.

Test ortamı olmadan entegrasyon kurulabilir mi?

Kısa cevap: kurabilirsiniz, ama önermem. Canlı ERP üzerinde deneme yapmak, gerçek cari hesaplara sahte sipariş yazmak anlamına gelir; sonra bunları muhasebe ekibi tek tek temizler. Üstelik yanlış bir toplu güncelleme, bütün fiyat listesini birkaç dakikada bozabilir.

Bu yüzden projenin başında ERP ve CRM üreticisine bir test ortamı (sandbox) olup olmadığını sorun. Birçok bulut CRM bunu sunar; yerel ERP'lerde ise çoğu zaman şirket veri tabanının bir kopyasıyla ayrı bir test şirketi açmak mümkündür. Test ortamındaki veriyi de gerçeğe yakın tutun, ancak kişisel verileri maskeleyin.

Test ortamı bir kez kurulduğunda yalnız ilk proje için değil, sonraki her değişiklik için de işe yarar. Kısacası bu maliyeti bir kerelik bir harcama değil, uzun vadeli bir sigorta olarak görün.

Entegrasyonu canlıya almadan önce neleri test etmelisiniz?

Canlı öncesi test listem kısadır ama taviz vermem:

• Mutlu yol: normal sipariş, normal talep, normal stok güncellemesi.
• Kesinti: CRM veya ERP erişilemezken gelen talep kayboluyor mu?
• Tekrar: aynı webhook iki kez geldiğinde çift kayıt oluşuyor mu?
• Uç veri: Türkçe karakter, çok uzun adres, boş alan, farklı para birimi.
• Yetki: bir kullanıcı başkasının siparişini görebiliyor mu?
• Geri alma: sorun çıkarsa entegrasyonu kapatıp elle çalışmaya dönebiliyor musunuz?

Son maddeyi özellikle vurgularım. Her entegrasyonun bir kapatma anahtarı olmalı; böylece gece yarısı bir hata çıktığında siteyi kapatmadan akışı durdurabilirsiniz. DNS ve alan adı tarafında hazırlık yapmak için DNS sorgulama aracını kullanabilirsiniz. Projenizi birlikte planlamak isterseniz iletişim sayfasından ulaşabilirsiniz.