Bir ziyaretçi web sitenizden teklif ister. Talep satış ekibine ulaşır, müşteri bilgileri CRM sistemine girilir, teklif onaylandığında sipariş ERP üzerinde açılır. Bu zincirde aynı adresin üç kez yazılması, ürün kodunun farklı yorumlanması veya güncellenen telefonun eski kayıtta kalması mümkündür. Entegrasyon projesinin değeri, bu geçişleri işletmenin çalışma düzenine uygun ve izlenebilir hale getirmesinden gelir.
Başarılı bir web yazılım projesinde hangi uygulamaların bağlanacağı kadar, hangi bilginin nerede yönetileceği de önemlidir. CRM müşteri ilişkilerini, ERP ise işletmenin kaynak ve operasyon süreçlerini destekler; ancak kullanılan modüller ve sorumluluklar şirkete göre değişir. Bu nedenle bağlantı geliştirmeye başlamadan önce veri akışı, karar noktaları ve hata durumları birlikte tasarlanmalıdır.
Entegrasyon Kapsamını Bir İş Akışıyla Tanımlayın
İlk toplantıda tüm sistemleri birbirine bağlamayı hedeflemek yerine, tamamlanması gereken bir iş akışını seçin. Örneğin web formundan gelen teklif talebinin CRM içinde doğru satış kuyruğuna düşmesi, yetkili kişinin onayından sonra ERP siparişine dönüşmesi ve sonucun web panelinde görünmesi. Talebin alınması ile siparişin onaylanması farklı iş olaylarıdır; aralarındaki karar otomatik varsayılmamalıdır.
Bir kurumsal web sitesi yalnızca talep topluyorsa, stok ve muhasebe verilerinin tamamına erişmesi gerekmeyebilir. Buna karşılık müşteri portalında sipariş durumu gösterilecekse hangi durumların ziyaretçiye açıklanacağı ayrıca belirlenir. İç operasyon notları ile müşterinin görmesi gereken bilgiler aynı kapsamda değerlendirilmez. Projenin sınırı, ekranda sunulan işlevle ilişkilendirilir.
Bu akışın başlangıcını, bitişini, sorumlusunu ve kapsam dışı işlemlerini kısa bir dokümana yazın. Eski kayıtların aktarımı, ek modül lisansları, tedarikçi geliştirmeleri ve kullanıcı eğitimi ayrı teslim kalemleri olabilir. İhtiyaçların düzenlenmesinde kurumsal web tasarım briefi hazırlama rehberimiz başlangıç sağlar; entegrasyonda bu belgeyi veri ve işlem senaryolarıyla derinleştirmek gerekir.
Mevcut Sistemlerin Gerçek Olanaklarını Kontrol Edin
Bir ürünün tanıtımında API desteği bulunması, ihtiyaç duyulan bütün işlemleri desteklediği anlamına gelmez. Kullanılan sürümde müşteri kaydı açılabiliyor mu, sipariş satırları güncellenebiliyor mu, özel alanlara erişilebiliyor mu? Test ortamı, erişim yöntemi, kullanım sınırları ve entegrasyon için gerekli lisanslar ilgili sağlayıcıdan doğrulanmalıdır. Değerlendirmeyi satış sunumu yerine proje ortamına uygulanabilen belgeler üzerinden yapın.
Hazır bağlantı modülü varsa desteklediği akışları örnek kayıtlarla inceleyin. Modülün bulunması alan eşleştirme, yetki ve hata takibi ihtiyacını ortadan kaldırmaz. Ürünün sınırları iş sürecinizi karşılamıyorsa uyarlama veya ek geliştirme gerekebilir. Özel web yazılım ve hazır sistem karşılaştırması, bu seçimi ilk kurulumun yanında sürdürülebilirlik açısından da değerlendirmeye yardımcı olur.
Her Veri Alanı İçin Yetkili Kaynağı Belirleyin
Entegrasyonlarda en zor sorulardan biri şudur: Aynı müşteri iki sistemde değiştirildiğinde hangi bilgi geçerli olacaktır? Tek bir uygulamayı bütün verilerin sahibi ilan etmek her zaman doğru değildir. Ürün kodu ERP üzerinde, satış temsilcisi CRM üzerinde, web sayfasına özel açıklama ise içerik panelinde yönetilebilir. Sorumluluğu kayıt bazında değil, gerektiğinde alan bazında tanımlayın.
Örnek bir ürün için ticari kod, satışa uygunluk, görsel ve açıklama farklı kaynaklardan gelebilir. ERP stok bilgisi gönderebilir; web ekibi açıklamayı düzenleyebilir. Entegrasyonun her güncellemede açıklamayı boş değerle ezmesi önlenmelidir. Alanın aktarılmaması, boş gönderilmesi ve açıkça silinmesi farklı anlamlar taşıyabilir. Bu ayrım yazılı olmadığı zaman doğru çalışan bağlantı bile yanlış iş sonucu üretir.
İki yönlü güncelleme gerçekten gerekiyorsa çakışma kuralını tanımlayın. Her durumda son gelen değeri kabul etmek, gecikmiş bir mesajın yeni bilgiyi silmesine yol açabilir. Sürüm, değişiklik kaynağı ve yetkili kullanıcı kararına göre işlem tasarlayın. Farklı sistemlerdeki tarih alanları karşılaştırılacaksa saat dilimi ve zaman kaynağı koşullarını da doğrulayın.
Alan Eşleştirmesini Veri Sözlüğüne Dönüştürün
Alan eşleştirme tablosu yalnızca kaynak ve hedef sütunlarından oluşmamalıdır. Her satırda veri tipi, zorunluluk, dönüşüm, örnek değer, boş değer davranışı ve hatada sorumlu kişi bulunmalıdır. Böylece satış, operasyon ve yazılım ekipleri aynı alan adından aynı şeyi anlar. Aşağıdaki başlıklar özellikle teklif ve sipariş akışlarında işe yarar:
- Kimlikler: Web talep numarası, CRM kayıt kimliği ve ERP sipariş numarası arasındaki ilişkiyi saklayın; değişebilir şirket adı üzerinden eşleştirme yapmayın.
- Tutarlar: Para birimini, ondalık hassasiyeti ve tutarın hangi bileşenleri içerdiğini belirtin; farklı gösterim biçimlerinin yanlış sayıya dönüşmesini engelleyin.
- Ürünler: Stok kodu, varyant, ölçü birimi ve sipariş miktarı ilişkisini tanımlayın; kutu ile adet gibi farklı birimleri aynı kabul etmeyin.
- Durumlar: Yeni, inceleniyor, onaylandı, iptal edildi gibi iş durumlarının karşılıklarını ve hangi geçişe kimin karar verdiğini yazın.
- İletişim: Telefon, e-posta ve adres alanlarında biçim kontrolünü, güncelleme yetkisini ve eksik bilgiyle devam edilip edilmeyeceğini belirleyin.
Özellikle e-ticaret sitesi geliştirme çalışmalarında aynı ürünün farklı kanallardaki kimlikleri karışabilir. Ticari işlem yaratılmadan önce eşleşmeyen ürünlerin ayrı bir inceleme kuyruğuna alınması daha yönetilebilir bir yaklaşımdır. Genel çerçeve için e-ticaret veri entegrasyonu yazımız incelenebilir; proje kararları ise mevcut sistemlerin alan ve süreç ayrıntılarına dayanmalıdır.
Veri sözlüğünü doğrulamak için yalnız kusursuz örnekler seçmeyin. Uzun şirket adı, birden fazla teslimat adresi, pasif ürün, değişmiş iletişim bilgisi ve boş isteğe bağlı alan gibi durumları da test kümesine ekleyin. Örnekler gerçek müşteri bilgisi içermek zorunda değildir; iş kurallarını temsil eden yapay test kayıtları hazırlanabilir. Alanın ekranda nasıl göründüğü ile API üzerinden hangi biçimde taşındığı birlikte kontrol edilmelidir.
Aktarım Sıklığını İşin İhtiyacına Göre Seçin
Her verinin anlık aktarılması gerekmez. Satış ekibine yeni talep bildirimi hızlı ulaşmalıdır; raporlama verileri belirli aralıklarla güncellenebilir. Stok görünürlüğünde kabul edilen gecikme ise sipariş modeline göre değerlendirilir. İhtiyacı yalnızca anlık veya günlük diye tanımlamayın; gecikme olduğunda hangi ekranın nasıl davranacağını ve bilginin güncelliğinin kullanıcıya nasıl gösterileceğini de yazın.
Sistem destekliyorsa webhook, gerçekleşen olayı karşı tarafa bildirebilir. Diğer seçenek, değişen kayıtları belirli aralıklarla sorgulamaktır. Sorgulama yönteminde sayfalama, son başarılı ilerleme noktası ve aktarım sırasında oluşan değişikliklerin kaçırılmaması planlanır. Bildirim yönteminde ise tekrar gelen veya farklı sırada ulaşan olaylar dikkate alınır. Seçim, sağlayıcının belgelenmiş davranışına ve kabul edilen gecikmeye göre yapılır.
Örneğin Stripe webhook belgeleri, olayların oluşma sırasıyla tesliminin garanti edilmediğini ve aynı olayın tekrar gelebileceğini açıklar. Bu, bütün CRM ürünlerinin aynı davranacağı anlamına gelmez. Planlama açısından çıkarılacak ders, olay sırasını ve tekrar teslimini varsaymak yerine kullanılan servisin sözleşmesini doğrulamak, işlenen olayları izlemek ve gerektiğinde güncel kaydı sorgulayabilmektir.
Tekrar Deneme Mükerrer Sipariş Üretmemeli
Bir sipariş gönderildiğinde bağlantı zaman aşımına uğrayabilir. Bu durum, siparişin hedef sistemde oluşmadığını kanıtlamaz; karşı taraf kaydetmiş fakat yanıt ulaşmamış olabilir. Aynı isteği körlemesine yeniden göndermek ikinci sipariş yaratabilir. Güvenilir akış, işlem kimliğini korur, hedefteki sonucu kontrol eder ve tekrarın yeni bir ticari işlem oluşturmasını önleyecek kuralı uygular.
Bu davranış idempotans kavramıyla ilişkilidir: Aynı işleme ait tekrarlar, amaçlanan sonucu gereksiz yere çoğaltmamalıdır. Bir talep kimliği, gönderim denemesi kimliği ve hedef kayıt kimliği birbirinden ayrılır. Hedef API destekliyorsa belgelenmiş idempotans mekanizması kullanılır. Desteklemiyorsa benzersiz iş anahtarı, eşleştirme kaydı ve eşzamanlı işlemleri kontrol eden tasarım birlikte değerlendirilir.
Microsoft Dataverse Upsert belgesi, dış sistemden gelen kaydın mevcutsa güncellenmesi, yoksa oluşturulması yaklaşımını ve alternatif anahtar kullanımını açıklar. Bu olanak ürünün kendi kurallarına bağlıdır. Upsert kullanmak, tetiklenen bildirim veya başka yan işlemlerin de kendiliğinden tek kez gerçekleşeceği anlamına gelmez; bütün iş akışının tekrar davranışı test edilmelidir.
Hataları Operasyon Ekibinin Yönetebileceği Hale Getirin
Eksik zorunlu alan, yetkisiz erişim, geçici bağlantı sorunu ve kullanım sınırına takılma aynı hata değildir. Eksik ürün kodunu tekrar tekrar göndermek sorunu çözmez. Geçici kesintide ise kontrollü yeniden deneme işe yarayabilir. Her hata türü için otomatik işlem, azami deneme politikası, bekleme yaklaşımı ve insan müdahalesine geçiş koşulu belirlenmelidir.
Ürüne özgü bir örnek olarak Microsoft Dataverse hizmet koruma limitleri, Web API sınır aşımlarında 429 yanıtını ve yeniden denemeden önce beklemeyi belirten Retry-After başlığını açıklar. İstemci bu bilgiyi dikkate almalıdır. Bütün sağlayıcılar için sabit bir bekleme süresi uydurmak yerine, kullanılan API'nin güncel sınırları ve yanıtları esas alınır.
Operasyon ekranında kaydın bekliyor, işleniyor, tamamlandı veya inceleme gerekiyor durumunda olduğu anlaşılmalıdır. Teknik günlükte izleme kimliği bulunabilir; kullanıcının ekranında ise hangi bilginin düzeltilmesi gerektiği açıkça yazılmalıdır. Bekleyen iş sayısı ve en eski bekleyen kaydın süresi izlenerek aksaklık görünür hale getirilir. Uyarının kime gideceği belirlenmemişse, hata kaydı tutulması tek başına yeterli değildir.
Erişimleri ve Veri Görünürlüğünü Sınırlandırın
Entegrasyon bağlantısının yalnızca gerekli işlemleri yapabilecek yetkilerle çalışmasını hedefleyin. Test ve canlı erişimleri ayırın; kimlik bilgilerini web sayfasının istemci koduna veya içerik alanlarına yerleştirmeyin. Günlüklere erişim anahtarı ve gereksiz müşteri verisi yazılmaması için kayıt politikasını belirleyin. Gelen bildirimin kaynağını doğrularken sağlayıcının desteklediği doğrulama yöntemini uygulayın.
Kullanıcı ekranında müşteri kaydı gösteriliyorsa, bağlantının veriyi getirebilmesi ile o kullanıcının görmeye yetkili olması ayrı kontrollerdir. Hesapların kimin adına açıldığı, erişimlerin kim tarafından yönetileceği ve destek değişikliğinde nasıl devredileceği başlangıçta belirlenmelidir. Bu konu, site sahipliği ve destek hakları rehberimizdeki erişim envanteri yaklaşımıyla birlikte ele alınabilir.
Kabul Testlerini Gerçek İş Sonucuna Bağlayın
Bağlantıdan başarılı yanıt alınması, bütün alanların doğru aktarıldığını veya siparişin kullanılabilir olduğunu tek başına göstermez. Testte web talebi, CRM kaydı ve ERP sonucu birlikte izlenmelidir. Kontrol yalnız geliştirici tarafından yapılmamalı; satış ve operasyon sorumluları da kendi ekranlarında beklenen sonucu doğrulamalıdır. Kabul planında en az şu durumlar yer almalıdır:
- Normal akış: Geçerli talep doğru müşteriyle eşleşir, onaydan sonra tek sipariş oluşur ve hedef kayıt numarası geri alınır.
- Tekrarlı gönderim: Aynı talep yeniden işlendiğinde ikinci sipariş açılmaz; işlem geçmişinde tekrarın nasıl ele alındığı görülebilir.
- Hatalı veri: Tanımsız ürün veya eksik zorunlu alan sessizce atlanmaz; sorumlu kişi kaydı düzelterek kontrollü biçimde yeniden işleyebilir.
- Kesinti ve dönüş: Hedef sistem erişilemezken kayıtlar kaybolmaz; bağlantı düzeldiğinde bekleyen işler belirlenen sırayla ve kapasiteyle ele alınır.
- Çakışma: Eski güncelleme yeni verinin üzerine yazmaz; iptal veya onay olayının gecikmesi uygun iş kuralıyla değerlendirilir.
Test verileri üretim kayıtlarından ayrılmalı, deneme siparişlerinin gerçek operasyon başlatması engellenmelidir. Her senaryonun beklenen sonucu, ekran kanıtı ve onaylayan rolü teslim dosyasına eklenebilir. Bu hazırlığı geliştirme sonuna bırakmak yerine web tasarım proje takvimine dahil etmek, sağlayıcı erişimi veya iş birimi onayı gibi bağımlılıkları erken görünür kılar.
Aktarım Sonrası Mutabakatı Atlamayın
Günlük kontrol, yalnız başarısız istekleri saymaktan ibaret olmamalıdır. Kaynakta onaylanan ve hedefte karşılığı bulunamayan işlemler ayrı raporlanmalıdır. Hedefte kayıt var fakat bazı alanlar eksikse bu da tamamlanmış kabul edilmemelidir. Karşılaştırmada ortak iş kimliği, beklenen durum ve kontrol tarihi kullanılabilir. Böylece mesajın ulaşması ile işin tamamlanması arasındaki fark görünür olur.
Mutabakatın hangi aralıkla çalışacağı işlem hacmine ve operasyonun toleransına göre kararlaştırılır. Raporu inceleyecek rol, düzeltme yetkisi ve yeniden işleme adımı belirlenir. Örneğin bir sipariş satış onayı beklediği için aktarılmadıysa teknik hata sayılmaz. Buna karşılık onaylı siparişin eşleşmesi yoksa araştırılır. Kuralların bu ayrımı yapması, ekibi gereksiz uyarılarla meşgul etmeden gerçek eksiklere yönlendirir.
Örnek Akış: Teklif Talebinden Onaylı Siparişe
Varsayımsal bir üretim işletmesini düşünelim. Web sitesinde açılan TLF-104 numaralı talep CRM üzerinde bir satış fırsatına bağlanıyor. Bu numara her denemede korunuyor; CRM'nin kendi kayıt kimliği de eşleştirme kaydına ekleniyor. Satış sorumlusu ürün ve miktarı doğrulamadan ERP siparişi oluşturulmuyor. Bu ayrım, formdaki her mesajın ticari siparişe dönüşmesini önlüyor.
Onaydan sonra ERP bağlantısı yanıt vermediğinde kayıt hemen başarısız ve yok kabul edilmiyor. Önce hedefte TLF-104 ile ilişkilendirilmiş sonuç araştırılıyor; varsa mevcut siparişe bağlanıyor. Yoksa sağlayıcının güvenli tekrar koşulları uygulanıyor. Ürün kodu tanımsızsa otomatik denemeler sürdürülmüyor, operasyon incelemesi açılıyor. Örnek bir müşteri başarısı iddiası değil, geliştirme ekibine verilebilecek kabul senaryosudur.
Canlıya Geçişi ve Sonraki Bakımı Birlikte Planlayın
Geçmiş kayıtların ilk aktarımı ile yeni işlemlerin günlük aktarımı ayrı işlerdir. İlk yüklemede hangi tarihin esas alınacağı, aktarım sürerken değişen kayıtların nasıl yakalanacağı ve eşleşmeyen kayıtların kimin tarafından düzeltileceği belirlenmelidir. Kaynak ve hedef sayımlarına ek olarak seçilmiş kayıtların alanları da karşılaştırılır. Hata halinde geri dönüş, oluşmuş ticari işlemleri düşünmeden topluca silmek veya yeniden göndermek olarak tasarlanmamalıdır.
Teslim dosyasında veri sözlüğü, akış şeması, test sonuçları, erişim sorumluları, izleme yöntemi ve müdahale adımları bulunmalıdır. Kurumsal web sitesi paketlerinde teslim ve destek değerlendirilirken entegrasyonun bakım sınırları ayrıca yazılmalıdır. Sağlayıcı API değişikliği, yeni alan talebi ve mevcut bağlantı hatasının giderilmesi aynı hizmet kalemi olmayabilir.
Bütçeyi karşılaştırırken yalnız bağlantının kurulmasına bakmayın. Test ortamı, lisans, veri temizliği, geçmiş veri aktarımı, izleme ve bakım sorumlulukları toplam kapsamı değiştirir. Web tasarım tekliflerini karşılaştırma rehberimizdeki kapsam yaklaşımı burada da geçerlidir: Aynı teslimler tanımlanmadan verilen iki bedel sağlıklı biçimde karşılaştırılamaz.
Entegrasyon Projesine Başlamadan Önce
Web Tasarım Sistemleri olarak entegrasyon ihtiyacını önce iş akışı, veri sorumluluğu ve doğrulanabilir teslim ölçütleri üzerinden ele almayı öneriyoruz. Sistemin çalıştığını gösterecek kanıtlar başlangıçta tanımlandığında geliştirme, test ve destek aynı hedef etrafında ilerleyebilir. İyi planlanmış bağlantı, işletmenin günlük işinde anlaşılabilir ve yönetilebilir bir süreç haline gelir.
CRM ve ERP bağlantısı planlıyorsanız kullandığınız ürünleri, gerekli modülleri, örnek alanları ve en kritik iş akışını bir araya getirin. Bu bilgilerle entegrasyon projenizi birlikte değerlendirmek için iletişime geçebilirsiniz. İlk hedef, her veriyi her yere taşımak yerine doğru bilginin doğru yetkiyle, doğru zamanda ve sonucu doğrulanabilir biçimde aktarılacağı kapsamı oluşturmaktır.
Bu makalenin uzunluğu 1885 kelimedir.
Bu makale 2026-10-10 tarihinde yayınlanmıştır.