İçindekiler
ERP altı saat kapalı kaldığında siparişler gelmeye devam edebilir. Asıl risk, sistem açıldıktan sonra hangi siparişin işlendiğini, hangisinin beklediğini ve hangisinin iki kez gönderildiğini bilememektir. EDI iş sürekliliği, kesinti boyunca her mesajın izini koruyan ve kontrollü dönüş sağlayan işletim modelidir.
Bu model sunucu yedeğinden daha geniştir. Sipariş, sevkiyat bildirimi ve fatura farklı iş etkileri taşır. Operasyon ekibi her belge türü için bekleme sınırını, alarm sahibini, yeniden işleme yöntemini ve mutabakat kanıtını önceden tanımlar.
İçindekiler
- EDI kesintisi neden sistem açılınca bitmez?
- RTO ve RPO mesaj akışına nasıl çevrilir?
- Dört kayıt testi hangi boşlukları gösterir?
- Retry, resend ve reprocess kararı nasıl verilir?
- Türkiye'deki bir üretici kesintiyi nasıl yönetebilir?
- EDI süreklilik planı nasıl test edilir?
EDI Kesintisi Neden Sistem Açılınca Bitmez?
Bir EDI akışı aktarım, dönüşüm, iş kuralı ve hedef uygulama katmanlarından geçer. AS2 bağlantısı çalışırken ERP siparişi reddedebilir. Mapping tamamlanırken ticaret ortağının acknowledgment mesajı gelmeyebilir. Yeşil görünen bağlantı, ticari işlemin tamamlandığını kanıtlamaz.
Uptime Institute'un 2025 araştırmasında IT ve ağ sorunları, 2024'te etkili kesintilerin yüzde 23'ünü oluşturdu. Son kesintisinin maliyetini bildiren katılımcıların yüzde 20'si 1 milyon doların üzerinde bir tutar verdi. Yüzde 37'lik grup ise 100 bin ile 1 milyon dolar aralığındaydı. Bu rakamlar yalnız EDI kesintilerini ölçmüyor; dijital işlemlerde kurtarma disiplininin mali boyutunu gösteriyor.
EDI tarafında kurtarma, teknik servisin yeniden başlamasıyla tamamlanmaz. Bekleyen kuyruğun sayılması, karşı tarafa ulaşan mesajların ayrılması ve ERP'deki kayıtlarla mutabakat gerekir. Aksi halde ekip aynı siparişi yeniden işleyebilir veya sessizce kaybolan bir sevkiyat bildirimini fark etmeyebilir.
NIST'in EDI güvenlik rehberi, işlem loglarının ve durum geri bildirimlerinin kayıp, yanlış işlenmiş ya da kopya mesajları bulmak için kullanılmasını öneriyor. Rehber ayrıca ağ arızasından dönüşte mesaj atlamadan ve çoğaltmadan kurtarmayı ayrı bir kontrol olarak ele alıyor.
RTO ve RPO Mesaj Akışına Nasıl Çevrilir?
RTO, bir sistemin kabul edilemez etki doğmadan önce ne kadar süre kapalı kalabileceğini tanımlar. RPO ise geri dönüşte ne kadarlık verinin yeniden oluşturulmasının kabul edilebileceğini gösterir. Tek bir “EDI RTO” değeri, farklı belge akışlarının etkisini gizler.
Otomotiv üretim programı, perakende siparişi ve dönem sonu faturası aynı saat sınırına sahip olmayabilir. Operasyon ekibi belge türü, ticaret ortağı ve gün içi kapanış saatine göre ayrı hedef belirlemelidir. ISO/TS 22317, iş etki analizinin ürün, hizmet, bağımlılık, RTO ve uygun RPO gereksinimlerini birlikte çıkarmasını ister.
Pratik karar sırası şöyledir:
- Kesinti hangi iş sonucunu durduruyor: üretim, hazırlama, sevkiyat, tahsilat veya raporlama?
- Etki kaç dakika ya da saat sonra kabul edilemez hale geliyor?
- Mesajlar güvenli bir kuyrukta tutuluyor mu; kuyruk kapasitesi hedef süreyi karşılıyor mu?
- Geri dönüşte hangi kontrol numarası ve acknowledgment kaydı son doğru noktayı gösteriyor?
- İşlem sırası bozulursa hangi belgeler manuel onay gerektiriyor?
NIS2 Madde 21(2)(c), iş sürekliliği, yedek yönetimi, felaket kurtarma ve kriz yönetimini aynı tedbir grubunda sayıyor. Komisyon Uygulama Tüzüğü 2024/2690 da kurtarma sırası, hedefler, kaynaklar ve geçici tedbirlerden normal işleyişe dönüş için yazılı plan istiyor. Şirket NIS2 kapsamında olmasa bile bu yapı, EDI bağımlılıklarını ölçmek için kullanılabilir.
Dört Kayıt Testi Hangi Boşlukları Gösterir?
Bir EDI mesajının akıbetini dört kayıtla doğrulayın. Bu kayıtların herhangi biri eksikse süreklilik planında görünürlük boşluğu vardır.
- Kimlik: Mesaj kimliği, kontrol numarası, gönderici, alıcı ve belge türü kayıtlı mı?
- Zaman: Alınma, dönüşüm, hedef sisteme aktarım ve acknowledgment zamanları görülebiliyor mu?
- Durum: Teknik aktarım ile ticari kabul ayrı durumlar olarak tutuluyor mu?
- Eylem: Hata sonrası kimin ne yaptığı, retry veya resend nedeni ve sonuç kayda giriyor mu?
Bu test, “dosya gönderildi” kaydını yeterli kanıt saymaz. Örneğin X12 997 ya da EDIFACT CONTRL, belirli bir teknik kabul düzeyi hakkında bilgi verir. Ticaret ortağının miktar, fiyat veya teslim tarihi gibi iş içeriğini onayladığını her zaman kanıtlamaz.
MAP'in EDI izleme ve takip çözümü MAP Monitor, gelen ve giden belgelerin mevcut durumunu ve geçmişini tek noktada gösterir. Yetki verilen tedarikçiler de aynı verilere erişebilir. Bu görünürlük, olay sırasında ekiplerin ortak mesaj kaydı üzerinden çalışmasına yardım eder. Kuyruklama, otomatik retry ve felaket kurtarma davranışı ise kullanılan entegrasyon mimarisi için ayrıca doğrulanmalıdır.
Retry, Resend ve Reprocess Kararı Nasıl Verilir?
Yanlış tekrar, kesintinin kendisinden daha pahalı bir veri sorunu yaratabilir. Bir satın alma siparişinin iki kez işlenmesi fazla üretim doğurabilir. Tekrarlanan fatura ise muhasebe ve mutabakat yükü çıkarır.
Üç işlemi ayırın:
- Retry: Aktarım tamamlanmadı ve mesajın karşı tarafa ulaşmadığı doğrulandı. Aynı teknik teslimat yeniden denenir.
- Resend: Karşı taraf mesajı reddetti. Veri düzeltilir, sürüm ve kontrol numarası kurala uygun biçimde yönetilir, belge yeniden gönderilir.
- Internal reprocess: EDI katmanı kabulü tamamladı; ERP, WMS veya başka bir hedef uygulama işlemi reddetti. Mesaj dışarı tekrar gönderilmeden içeride yeniden işlenir.
Microsoft'un EDI felaket kurtarma rehberi, X12 ve EDIFACT kontrol numaralarının bölgeler arasında eşitlenmesini öneriyor. Amaç, ikincil ortama geçişte kopya kontrol numarası üretmemek. SAP Business Network belgeleri de retry ve acknowledgment davranışının bağlantı türüne göre değişebildiğini gösteriyor. Her platform için varsayım yapmak yerine ürün belgesini ve ticaret ortağı anlaşmasını kontrol edin.
Karar kaydında özgün mesaj kimliği, hata katmanı, karşı tarafa erişim kanıtı, seçilen işlem ve yeni mesaj kimliği bulunmalıdır. Otomatik retry sayısına üst sınır koyun. Aynı hata art arda oluşuyorsa mesajı inceleme kuyruğuna alın ve sorumlu ekibe yönlendirin.
Türkiye'deki Bir Üretici Kesintiyi Nasıl Yönetebilir?
Bursa'daki varsayımsal bir otomotiv tedarikçisini ele alalım. Şirket bir vardiyada 600 ORDERS, 420 DESADV ve 180 INVOIC mesajı işliyor. ERP bağlantısı 90 dakika duruyor; EDI ağ geçidi mesajları almaya devam ediyor.
Ekip önce kesinti başlangıcındaki son başarılı kontrol numarasını sabitler. Yeni ORDERS mesajları güvenli kuyrukta tutulur. Üretim planını etkileyen siparişler ticaret ortağı ve teslim saatiyle sıralanır. Çıkışı yaklaşan sevkiyatların DESADV kayıtları ikinci çalışma listesine alınır. INVOIC mesajları, mali kapanış saatine kadar kontrollü biçimde bekleyebilir.
ERP açıldığında bütün kuyruğu tek komutla boşaltmak risklidir. Ekip önce beş ORDERS mesajını işler ve ERP kayıtlarıyla mesaj durumunu karşılaştırır. Kontrol başarılıysa küçük gruplarla devam eder. Her grup sonrasında kabul, ret ve bekleyen sayıları kayda girer.
Ardından dört mutabakat yapılır: ağ geçidinin aldığı mesaj sayısı, dönüşümden geçen sayı, ERP'nin oluşturduğu ticari kayıtlar ve gönderilen acknowledgment mesajları. Sayılar eşleşmediğinde fark mesaj kimliği düzeyinde araştırılır. Böylece 90 dakikalık kesinti, belirsiz bir veri temizleme çalışmasına dönüşmez.
Bu senaryo bir kapasite vaadi değildir. Her işletme kuyruk sınırını, vardiya hacmini ve öncelik sırasını kendi iş etki analiziyle belirlemelidir.
EDI Süreklilik Planı Nasıl Test Edilir?
Uptime Institute, son üç yılda kuruluşların yaklaşık yüzde 40'ının insan hatasına bağlı büyük bir kesinti yaşadığını bildiriyor. Bu olayların yüzde 85'i prosedürün izlenmemesi veya prosedür kusuruyla bağlantılıydı. Yazılı planın masa başında kalması bu nedenle ölçülebilir bir risk.
Üç ayda bir 60-90 dakikalık tatbikat planlayın. Test ortamında ERP erişimini durdurun veya belirli bir mapping hatası üretin. Gerçek müşteri verisi kullanmayın. Ekip alarmın oluşma süresini, olay sahibinin atanmasını, bekleyen mesaj listesinin çıkarılmasını ve kontrollü dönüşün tamamlanmasını kronometreyle ölçsün.
Tatbikat sonunda şu kanıtları saklayın:
- Beklenen ve gerçekleşen RTO
- Kuyrukta kalan en eski mesajın yaşı
- Kayıp, kopya ve sırası bozulan mesaj sayısı
- İlk alarm ile sorumlu ataması arasındaki süre
- Mutabakatın tamamlanma süresi
- Güncellenecek prosedür, mapping veya alarm kuralı
İlk uygulama adımı olarak en yüksek iş etkisine sahip üç belge akışını seçin. Her akış için son doğru kaydı nasıl bulacağınızı ve kontrollü dönüşte hangi sayıları eşleştireceğinizi yazın. EDI iş sürekliliği planını diğer entegrasyon ve tedarik zinciri içerikleriyle birlikte MAP Blog üzerinden takip edebilirsiniz.
