ERP sistemleri uzun yıllar boyunca gecelik batch pencereleri etrafında tasarlandı. Gün sonu mutabakatı, stok senkronizasyonu, finansal kapanış öncesi taşıma işleri ve dış sistem entegrasyonları belirli zaman bloklarında işlendi. Bu model hâlâ birçok kurumda çalışıyor; ancak gerçek zamanlı operasyon beklentisi yükseldikçe batch penceresi hem teknik borç hem de operasyonel darboğaz üretmeye başlıyor. Çözüm, ERP’yi bir anda yeniden yazmak değil; batch bağımlılığını mimari olarak daraltmaktır.
Batch penceresi neden sorun çıkarıyor?
Çünkü birikimli iş yükü, riskleri de aynı zamana yığar. Gecelik akış uzadığında operasyon ekipleri şu etkilerle karşılaşır:
- Hata fark edildiğinde geri dönmek için zaman kalmaz.
- Tek bir darboğaz bütün iş zincirini geciktirir.
- İş etkisi sabaha kadar görünmez kalır.
- Kapasite planı pik yüke göre gereksiz büyük kurulur.
Özellikle depo, lojistik ve finans entegrasyonu yüksek şirketlerde bu durum yalnızca teknik değil doğrudan ticari risk üretir.
Batch penceresiz mimari ne demek?
Bu ifade, bütün işleri anlık çalıştırmak anlamına gelmez. Daha doğru tanım şudur: yalnızca gerçekten toplu işlenmesi gereken yükleri batch olarak bırakmak, geri kalan akışları küçük ve gözlemlenebilir olay zincirlerine çevirmek.
Pratikte bu dönüşüm şu katmanlarla ilerler:
- Değişiklik üreten işlemler olay olarak dışa açılır.
- Senkron olmayan tüketiciler idempotent çalışır.
- Ağır mutabakat işleri daraltılmış zaman bloklarına sıkıştırılır.
- İş akışları teknik alarm yerine iş metriğiyle de izlenir.
Bu model, ERP çekirdeğini parçalamadan çevresini daha esnek kılar.
En sık yapılan hata: batch’i kuyrukla yeniden adlandırmak
Birçok ekip message broker ekleyince problemi çözdüğünü düşünür. Oysa eğer tüketiciler hâlâ saatlik toplu iş mantığıyla davranıyorsa sadece eski batch’i yeni bir teknolojiyle taşımış olursunuz. Mimari dönüşümün gerçek işareti şu sorularda ortaya çıkar:
- Olay başına işlenebilir en küçük birim nedir?
- Aynı kayıt tekrar gelirse akış güvenli kalıyor mu?
- Hata alan parça tüm zinciri durdurmadan izole edilebiliyor mu?
- İş etkisi panelde gerçek zamanlı görülebiliyor mu?
Bu sorular cevaplanmadan yapılan modernizasyonlar, yalnızca entegrasyon görünümünü günceller.
Observability tarafı neden kritik?
ERP akışlarında başarısızlık çoğu zaman altyapı metriğinde değil iş sonucunda görünür. Bir kuyruğun dolması, retry sayısının artması veya API gecikmesinin yükselmesi ancak iş bağlamıyla birleştiğinde anlam kazanır. Bu yüzden batch penceresiz mimaride telemetry şunları birlikte taşımalıdır:
- Teknik gecikme
- İşlem hacmi
- Mutabakat farkı
- Başarısız kayıt oranı
- Geri işleme kuyruğu büyüklüğü
Bu görünürlük olmadan yeni mimari, eski batch modelinden daha karmaşık ama daha az anlaşılır olabilir.
Kurumsal geçiş nasıl yapılmalı?
En sağlıklı yaklaşım bir “strangler” modeli kurmaktır. Önce yüksek iş etkili ama teknik olarak çevrelenebilir bir akış seçilir. Örneğin siparişten envantere yansıyan güncelleme, stok rezervasyonları veya dağıtım merkezi olayları. Bu akış olay temelli hâle getirilir, iş metriğiyle izlenir ve bir süre eski batch ile paralel çalıştırılır.
Böylece kurum:
- yeni davranışı güvenli ölçer,
- veri tutarlılığını doğrular,
- operasyon ekibini yeni ritme alıştırır,
- ERP çekirdeğini bir anda destabilize etmez.
Sonuç
ERP altyapılarında batch penceresiz iş akışı mimarisi, “her şeyi stream yapalım” çağrısı değildir. Amaç; gecelik yığılmaları azaltmak, hata etkisini küçültmek ve iş akışlarını gün içine yayılmış gözlemlenebilir parçalara bölmektir. Bu yaklaşım doğru uygulandığında ERP modernizasyonu sadece entegrasyon hızını değil, operasyonel güvenilirliği de ciddi biçimde yükseltir.