API Entegrasyonunda Veri Akış Haritası Nasıl Hazırlanır?

ERP’de güncellenen bir müşteri kaydı CRM’de eski hâliyle görünüyorsa sorun her zaman API’nin çalışmaması değildir. Veri aktarılıyor olabilir; ancak yanlış alana yazılıyor, eksik bir kimlikle eşleştiriliyor veya hangi sistemin kaydının esas alınacağı bilinmiyordur. API entegrasyonunda veri akış haritası, bu belirsizlikleri geliştirme başlamadan görünür kılar. Harita; hangi verinin nerede oluştuğunu, nereye aktarıldığını ve aktarım sırasında hangi kurallardan geçtiğini ortak bir belgede toplar. Böylece iş birimleriyle teknik ekip aynı akışı değerlendirebilir.

01API entegrasyonunda veri akış haritası için kapsamı belirleyin

İlk adım, birbirine bağlanacak sistemleri listelemekten çok, desteklenecek iş sürecini tanımlamaktır. Örneğin amaç, özel sipariş uygulamasında açılan bir siparişin ERP’ye aktarılması ve ilgili müşteri bilgisinin CRM’deki kayıtla ilişkilendirilmesi olabilir. Bu cümle haritanın sınırını çizer: Siparişin oluşturulması kapsamdayken pazarlama kampanyaları bu akışın dışında kalabilir.

Keşif görüşmesinde her sistem için kullanım amacını, veri sorumlusunu, mevcut API veya aktarım imkânını ve erişim kısıtlarını yazılı olarak kaydedin. Ardından iş sürecini başlangıç olayından beklenen sonuca kadar anlatın. Teknik ekip bir bağlantıyı mümkün görse bile iş birimi o bağlantının hangi kararı desteklediğini açıklayamıyorsa kapsamı yeniden değerlendirmek gerekir.

• Başlangıç olayı: Aktarımı hangi işlem başlatıyor?
• Beklenen sonuç: Hedef sistemde hangi kayıt oluşmalı veya değişmeli?
• Kapsam dışı işlemler: Bu çalışmada hangi veri akışlarına dokunulmayacak?
• İlgili kişiler: Alanların anlamını ve iş kuralını kim onaylayacak?

Bu sınırlar, veri akış haritasının zamanla bütün sistemlerin genel şemasına dönüşmesini önler. Harita, karar verilecek entegrasyon kapsamına odaklanır.

02Her veri için kaynak sistemi ve akış yönünü gösterin

Aynı müşteri adı ERP, CRM ve özel uygulamada bulunabilir. Haritada yalnızca bu sistemler arasında ok çizmek yeterli değildir; her alan için hangi kaydın esas alınacağını belirtmek gerekir. Müşteri iletişim bilgilerinin kaynağı CRM, ürün kodunun kaynağı ERP olarak kararlaştırılabilir. Bunlar örnek kararlardır; sizin sürecinizde geçerli kaynak keşif sırasında doğrulanmalıdır.

Her akışa okunabilir bir ad verin: “CRM müşteri bilgisi → özel uygulama” gibi. Okun yanına aktarımı başlatan olayı, veri kapsamını ve hedefte yapılacak işlemi ekleyin. Yeni kayıt oluşturma ile var olan kaydı güncelleme farklı kurallar gerektirir. Hedefte kayıt bulunamazsa ne olacağı da gösterilmelidir: Yeni kayıt mı açılacak, işlem mi bekletilecek, yoksa inceleme için bir hata mı üretilecek?

Çift yönlü akışları iki ayrı ok olarak belgeleyin. “ERP ↔ CRM” ifadesi, aynı alan iki tarafta değiştirildiğinde hangi değerin geçerli olacağını açıklamaz. Akışları ayırmak; yazma yetkisini, güncelleme koşullarını ve olası çakışmaları ayrı ayrı incelemenizi sağlar. Böylece veri akış haritası yalnızca sistemlerin bağlantısını değil, değişikliklerin sorumluluğunu da gösterir.

03Alan eşleştirmesini keşif aşamasında somutlaştırın

Akış yönü belirlendikten sonra kaynak ve hedef alanları karşılaştırın. Alan adlarının benzemesi, aynı anlama geldikleri anlamına gelmez. CRM’deki müşteri kimliği ile ERP’deki cari kod farklı biçimlerde üretilebilir. Birini diğerinin alanına doğrudan kopyalamak, kaydın yanlış müşteriyle ilişkilendirilmesine yol açabilir.

Varsayımsal örnek: Özel sipariş uygulaması, sipariş kaydında CRM müşteri kimliğini tutuyor; ERP ise siparişi kabul etmek için cari kod bekliyor. Keşifte yalnızca “müşteri bilgisi ERP’ye gönderilecek” yazılırsa geliştirme sırasında bir dönüştürme kuralı tahmin edilmek zorunda kalır. Bunun yerine, CRM müşteri kimliği ile ERP cari kodu arasındaki ilişkinin nereden okunacağını ve ilişki bulunamazsa siparişin nasıl ele alınacağını yazılı hâle getirin.

Bu tabloya alanın zorunlu olup olmadığını, veri biçimini ve dönüşüm ihtiyacını da ekleyebilirsiniz. Kuralları keşif aşamasında yazmak, iş biriminin anlamı doğrulamasına ve geliştiricinin varsayım yerine onaylı tanıma göre çalışmasına imkân verir.

04Doğrulama ve hata senaryolarını akışa ekleyin

Bir API isteğinin teknik olarak kabul edilmesi, verinin iş açısından doğru olduğu anlamına gelmez. Veri akış haritasında aktarım öncesi ve sonrası kontrolleri ayrı gösterin. Örnekte CRM müşteri kimliği boşsa gönderim başlamamalı; kimlik dolu ancak cari kod eşleştirmesi yoksa kayıt yanlış bir cariye bağlanmamalıdır. Ürün kodu ERP’de bulunmuyorsa hangi ekibin inceleme yapacağı da tanımlanmalıdır.

Doğrulama kurallarını “veri kontrol edilir” gibi genel ifadelerle bırakmayın. Hangi alanın hangi koşulda kabul edileceğini ve başarısızlıkta ne yapılacağını belirtin. Tekrar gönderilen bir siparişin yinelenen kayıt üretmemesi için sipariş kimliğinin nasıl kullanılacağı da bu aşamada kararlaştırılır. Yeniden deneme gerektiren geçici bir bağlantı sorunu ile iş kuralını ihlal eden bir veri hatası aynı şekilde ele alınmamalıdır.

• Zorunlu alan eksikse işlem duracak mı, tamamlanması için bekleyecek mi?
• Eşleştirme bulunamazsa kayıt hangi inceleme sürecine aktarılacak?
• Tekrar denenen işlem mevcut kayıtla nasıl ilişkilendirilecek?
• Hata düzeltildiğinde aktarımın yeniden başlatılmasına kim karar verecek?

Bu soruların yanıtları, test senaryolarının temelini oluşturur. Keşifte yazılmayan bir istisna, çoğu zaman ancak canlı akışta karşılaşıldığında tartışılabilir hâle gelir.

05Haritayı izlenebilir ve onaylanabilir bir belgeye dönüştürün

Veri akış haritası tek başına bir çizim olmamalıdır. Her okun yanında kaynak ve hedef sistem, alan eşleştirmesi, tetikleyici olay, doğrulama kuralı ve hata durumundaki sorumluluk bulunmalıdır. API tabanlı veya kuyruklu aktarım seçimi de bu gereksinimler üzerinden değerlendirilir. Önemli olan, seçilen yöntemin iş akışında neyi değiştirdiğinin anlaşılmasıdır.

İzlenebilirlik için aktarıma ait bir referans belirleyin. Sipariş kimliği gibi bir iş referansı, kaynak kaydın hedefteki karşılığını bulmaya yardımcı olur. İşlem kayıtlarında hata türünü ve akış adımını görünür kılarken kişisel verileri gereksiz yere çoğaltmamaya dikkat edin. Özellikle müşteri verisi taşınırken hangi alanların gerçekten gerekli olduğunu keşif sırasında sorgulamak, KVKK bağlamındaki değerlendirmeyi de somutlaştırır.

Son olarak belgeyi yalnızca teknik ekibe değil, alanların anlamını bilen iş sahiplerine de inceletin. Örnek kayıtlarla akışın baştan sona izlenmesini isteyin: Kaynakta ne oluşuyor, hedefte hangi kayıt değişiyor, hata olursa kim görüyor? Onaylanan harita geliştirme ve test için ortak başvuru noktası olur; süreç değiştiğinde eşleştirme ve kuralların da yeniden gözden geçirilmesi gerekir.

06Sık sorulan sorular

Veri akış haritası ile alan eşleştirme tablosu aynı şey mi?

Hayır. Veri akış haritası sistemler arasındaki yönü, aktarımı başlatan olayı ve hata yolunu gösterir. Alan eşleştirme tablosu ise bu haritanın ayrıntısıdır: Kaynak alanın hedefte nereye yazılacağını ve hangi dönüşüm veya doğrulamadan geçeceğini açıklar.

ERP ve CRM’de aynı müşteri değişirse hangi kayıt kullanılmalı?

Bu karar alan bazında verilmelidir. Önce ilgili bilginin hangi sistemde yönetildiğini belirleyin; ardından diğer sistemdeki değişikliğin kabul edilip edilmeyeceğini ve çakışma durumunda nasıl inceleneceğini yazın. İki yönlü aktarım tek başına bir öncelik kuralı oluşturmaz.

Mevcut sistemleri değiştirmeden veri akış haritası hazırlanabilir mi?

Evet. Harita mevcut sistemlerin veri üretme ve aktarma imkânlarını belgelemek için de kullanılır. Keşif sonucunda hangi alanların erişilebilir olduğu, hangi eşleştirmelerin gerektiği ve mevcut entegrasyon imkânlarının hedef akışa uygunluğu değerlendirilir.

Sonuç: Veri akış haritasına sistem listesinden değil, iş sürecinden başlayın. Kaynakları, yönleri, alan eşleştirmelerini ve hata kurallarını yazılı hâle getirerek geliştirme öncesinde ortak bir karar zemini oluşturabilirsiniz. ERP, CRM ve özel yazılımlarınız arasındaki akışın değerlendirilmesi için OPEIS Teknoloji’nin ERP ve CRM Entegrasyonu hizmetini inceleyebilirsiniz.