EDI Entegrasyon Süreci: Canlıya Geçişte 7 Adım

EDI entegrasyon süreci, iki sistem arasında bir bağlantı açmaktan daha geniştir. Siparişin hangi koşulda oluşacağı, ürün kodlarının nasıl eşleşeceği ve reddedilen mesajı kimin yöneteceği birlikte tasarlanır. Bu kararlar başta verilmezse teknik bağlantı çalışsa bile sipariş, sevkiyat veya fatura akışı işletmede karşılık bulmayabilir.

İyi planlanan bir proje analizden canlı izlemeye kadar yedi adımda ilerler. Her adımın çıktısı, sahibi ve kabul ölçütü bellidir. Böylece ekipler sorunları canlı sistemde değil, kontrollü test ortamında görür.

İçindekiler

İş hedefini ve proje kapsamını belirleyin
Ticaret ortağı gereksinimlerini toplayın
Entegrasyon mimarisini ve bağlantıyı kurun
Kaynak veriyi canlıdan önce hazırlayın
EDI mapping ve iş kurallarını geliştirin
Belgeyi değil uçtan uca süreci test edin
Canlıya kontrollü geçin ve mesajları izleyin
Sıkça sorulan sorular

1. İş Hedefini ve Proje Kapsamını Belirleyin

Projenin ilk çıktısı teknik doküman değil, kapsam kararıdır. Hangi ticaret ortaklarının bağlanacağı, hangi belgelerin gönderilip alınacağı ve hangi iş sonucunun beklendiği yazılmalıdır. Sipariş, sipariş onayı, sevkiyat bildirimi ve fatura aynı anda kapsama alınmak zorunda değildir.

IBM, EDI uygulamasının ilk adımını iş hedefinin tanımlanması olarak veriyor. Kurumun uygulama rehberi ayrıca kapsamın iş ortakları, işlem türleri ve veri kaynakları üzerinden sınırlandırılmasını öneriyor. Bu ayrım, proje sırasında yeni belge ve partner taleplerinin kontrolsüz biçimde eklenmesini önler. IBM'in EDI uygulama rehberi, kurum içi altyapıyı da dört katmanda ele alıyor: çalışma ortamı, bağlantı, entegrasyon ve veri yönetimi.

Başlangıç toplantısında şu kararlar kayda girmelidir:

Birinci fazdaki iş ortakları ve öncelik sırası
Gönderilecek ve alınacak belge türleri
Kaynak ERP, WMS veya muhasebe sistemi
Kabul edilebilir hata, gecikme ve tekrar işleme kuralları
İş, IT ve iş ortağı tarafındaki karar sahipleri

Türkiye'de otomotiv tedarikçisi için ilk faz, sipariş ve sevkiyat bildirimiyle başlayabilir. Perakende tedarikçisinde sipariş, irsaliye ve fatura daha uygun bir başlangıç paketi olabilir. Kapsam, sektör adından değil gerçek belge akışından çıkarılmalıdır.

2. Ticaret Ortağı Gereksinimlerini Toplayın

Her iş ortağı aynı standardı kullansa bile farklı alan, kod ve zamanlama kuralları isteyebilir. Bu nedenle ekip, karşı tarafın implementation guide dosyasını ve test senaryolarını mapping başlamadan edinmelidir. Belge sürümü, zorunlu alanlar, partner kimlikleri, bağlantı protokolü ve onay mesajları burada netleşir.

IBM'in EDI onboarding açıklaması, yaygın belge örnekleri olarak üç X12 işlem setini sayıyor: 850 sipariş, 810 fatura ve 997 fonksiyonel onay. Avrupa ve Türkiye bağlantılarında EDIFACT veya sektörel VDA mesajları öne çıkabilir. MAP'ın OtoEDI sayfası da EDIFACT ve VDA desteğinin yanında IDOC, XML, CSV ve TXT dönüşümünü listeliyor.

Gereksinim listesi yalnız dosya formatından oluşmamalıdır. Sipariş numarasının tekilliği, para birimi kodu, ölçü birimi, tarih biçimi ve bilinmeyen ürün kodunda izlenecek yol da yazılmalıdır. Karşı tarafın test ortamı, iletişim kişisi ve geri dönüş süresi proje takvimine eklenmelidir.

3. Entegrasyon Mimarisini ve Bağlantıyı Kurun

Mimari karar, EDI platformunun ERP ile nasıl konuşacağını ve mesajın iş ortağına hangi yoldan gideceğini belirler. İç bağlantıda API, dosya aktarımı veya veritabanı entegrasyonu kullanılabilir. Dış iletişimde AS2, SFTP, OFTP2 ya da iş ortağının kabul ettiği başka bir protokol seçilebilir.

IBM'in onboarding rehberi AS2, SFTP, MFT ve SOAP olmak üzere dört yaygın iletişim seçeneğini açıklıyor. Seçim; güvenlik, teslim bildirimi, sertifika yönetimi, mevcut altyapı ve partner şartlarına göre yapılmalıdır. Protokol kararı tek başına yeterli değildir. Endpoint, sertifika, IP izinleri, dosya adı, çalışma sıklığı ve yeniden deneme politikası da bağlantı dokümanına girmelidir.

Kuruluş bu katmanları kendi ekibiyle yönetebilir veya hizmet sağlayıcı kullanabilir. MAP'ın B2B/EDI entegrasyon sayfası, ERP sistemleri arasında sipariş ve fatura gibi iş mesajlarının otomatik değişimini hedefleyen ticari çözümün sahibi olmalıdır.

4. Kaynak Veriyi Canlıdan Önce Hazırlayın

Mapping tablosu temiz olmayan kaynak veriyi düzeltemez. Aynı ürünün iki kodla tutulması, eksik vergi bilgisi veya tutarsız adres alanı testte red üretir. Ekip, EDI dönüşümünden önce ERP'deki ana veriyi ve belge oluşturma kurallarını incelemelidir.

IBM, zayıf veri kalitesini EDI onboarding sürecinin yaygın sorunlarından biri olarak gösteriyor. Yinelenen kayıtlar, eksik alanlar ve tutarsız etiketler doğrulama adımını geciktirebiliyor. Kurumun rehberindeki basit tarih örneği bile farkı gösteriyor: standart YYYYMMDD beklerken serbest metin tarih göndermek dosyanın reddine yol açabilir.

Veri hazırlığında en az şu kontroller yapılmalıdır:

Müşteri ve tedarikçi kodları tekil mi?
İç ürün kodu ile partner SKU'su eşleşiyor mu?
Birim, ülke ve para birimi kodları kabul edilen listelere uyuyor mu?
Zorunlu vergi, adres ve sevkiyat alanları dolu mu?
İptal, kısmi sevkiyat ve fiyat farkı gibi istisnalar tanımlı mı?

Bu çalışma yalnız IT ekibine bırakılamaz. Satış, lojistik, finans ve ana veri sahipleri kendi alanlarının doğruluğunu onaylamalıdır.

5. EDI Mapping ve İş Kurallarını Geliştirin

EDI mapping, iç sistemdeki alanları hedef mesaj yapısına dönüştürür. Bir ERP'deki malzeme_kodu, karşı tarafta SKU olarak beklenebilir. Bir alan bazı partnerlerde zorunlu, bazılarında isteğe bağlı olabilir. Bu yüzden her iş ortağı için sürümlenen bir mapping tanımı gerekir.

IBM, mapping çalışmasını EDI uygulamasının dört altyapı katmanını da kesen ve çoğu zaman en fazla süre alan bölüm olarak tanımlıyor. Her alanın implementation guide içindeki karşılığı bulunur; sabit değerler, kod dönüşümleri ve koşullu kurallar ayrıca yazılır. Değişiklik geçmişi tutulmazsa yeni bir partner kuralı çalışan eski akışı bozabilir.

Mapping dokümanında kaynak alan, hedef alan, dönüşüm kuralı, zorunluluk durumu, örnek değer ve hata davranışı bulunmalıdır. Aynı iş kuralını kod, e-posta ve Excel dosyalarında ayrı ayrı tutmak yerine tek bir kontrollü kaynak kullanılmalıdır. Mapping onayı, teknik geliştiriciyle birlikte belgeyi kullanan iş biriminden de alınmalıdır.

6. Belgeyi Değil Uçtan Uca Süreci Test Edin

Bir test dosyasının karşı tarafa ulaşması, entegrasyonun hazır olduğunu kanıtlamaz. Dosya doğru ayrıştırılmalı, ERP'de doğru kaydı oluşturmalı ve gerekli onay mesajını geri üretmelidir. Ardından iptal, eksik alan, yanlış kod, tekrar gönderim ve bağlantı kesintisi gibi istisnalar denenmelidir.

IBM'in onboarding modeli testi dört başlıkta ayırıyor: bağlantı, doğrulama, tek işlem ve tam akış. Tek işlem testi mesajın gidip geldiğini gösterir. Tam akış testi ise siparişin ERP'ye düşmesinden sevkiyat ve fatura adımlarına kadar zinciri doğrular. X12 kullanan senaryolarda 997 mesajı, belgenin kabul veya red durumunu bildiren teknik kanıtlardan biridir.

Test planında her senaryo için beklenen sonuç, gerçek sonuç, sorumlu kişi ve kanıt kaydı bulunmalıdır. İş ortağıyla ortak kabul yapılmadan üretim bağlantısı açılmamalıdır. Türkiye'deki bir tedarikçi, e-fatura sürecini de aynı akışta kullanıyorsa EDI belgesiyle mali belgenin sorumlulukları birbirine karıştırılmamalıdır.

7. Canlıya Kontrollü Geçin ve Mesajları İzleyin

Canlıya geçiş tek bir tarih değil, kontrollü bir çalışma dönemidir. İlk mesajlar manuel olarak karşılaştırılabilir; hacim ve iş ortağı sayısı aşamalı artırılabilir. Eski kanalın ne zaman kapanacağı ve geri dönüş planı başlamadan belirlenmelidir.

MAP, kendi sitesinde yılda 150 milyondan fazla EDI mesajını topladığını, işlediğini ve dağıttığını belirtiyor. Bu ölçekte operasyon, yalnız mesaj gönderimine değil görünür hata ve yeniden işleme düzenine dayanır. MAP'ın kurumsal EDI verileri ayrıca 1.500'den fazla müşteri ve 25 yıllık EDI/B2B entegrasyon deneyimi bilgisini yayımlıyor.

İzleme ekranı en az gönderilen, alınan, bekleyen, reddedilen ve yeniden işlenen mesajları göstermelidir. Alarmın kime gideceği, hangi hatada iş biriminin devreye gireceği ve partner kuralı değiştiğinde mapping'in nasıl güncelleneceği tanımlanmalıdır. İlk ayın ölçümleri proje kabulünün parçası olmalıdır.

Sıkça Sorulan Sorular

EDI entegrasyon süreci nedir?

EDI entegrasyon süreci, ticaret ortakları arasında değişecek belgelerin ve kuralların belirlenmesiyle başlar. Bağlantı, veri mapping, test, canlıya geçiş ve izleme adımlarıyla tamamlanır.

EDI entegrasyonu ne kadar sürer?

Süre; iş ortağı sayısına, belge türlerine, ERP hazırlığına, mapping karmaşıklığına ve test takvimine göre değişir. Bu değişkenler görülmeden sabit bir süre vermek doğru değildir.

EDI mapping nedir?

EDI mapping, ERP veya başka bir iç sistemdeki veri alanlarını iş ortağının kullandığı EDI standardındaki alanlarla eşleştirme işlemidir. Ürün kodu, birim, tarih ve adres gibi alanlar bu aşamada dönüştürülür.

EDI entegrasyonunda hangi testler yapılır?

Bağlantı, sözdizimi, zorunlu alan, kod listesi, tek belge ve uçtan uca iş akışı testleri yapılır. Test yalnız dosyanın ulaşmasını değil ERP'de doğru işlenmesini de doğrulamalıdır.

Canlıya geçişten sonra EDI projesi biter mi?

Hayır. Mesaj redleri, gecikmeler, değişen partner kuralları ve mapping sürümleri izlenmelidir. İlk canlı işlemler ayrıca kontrol edilmeli ve hata sahipliği önceden belirlenmelidir.

Sonuç

EDI entegrasyonunun başarısı, bağlantının açıldığı gün değil gerçek iş belgelerinin doğru işlenmesiyle ölçülür. Kapsam, partner gereksinimleri, kaynak veri, mapping ve test kanıtları canlıya geçmeden tamamlanmalıdır. Üretimde ise mesaj durumu, hata sahipliği ve değişiklik yönetimi görünür kalmalıdır.

Kuruluşunuzdaki iş ortağı, belge ve ERP yapısına uygun yaklaşımı değerlendirmek için MAP B2B/EDI Entegrasyon sayfasını inceleyebilirsiniz. EDI ve tedarik zinciri dijitalleşmesiyle ilgili diğer içeriklere MAP Blog üzerinden ulaşabilirsiniz.