ERP ve sistem entegrasyonu, kurumsal kaynak planlama (ERP) sistemi ile üretim yönetimi (MES), kalite, bakım, depo ve saha kontrol sistemleri arasında verinin doğru, güvenli ve izlenebilir biçimde akmasını sağlayan bir tasarım ve işletme disiplinidir. Bu rehber, bir entegrasyon projesini envanterden canlı sonrası desteğe kadar adım adım planlamak isteyen BT, entegrasyon ve proje ekipleri için hazırlandı.
Entegrasyon projelerinde sorun genellikle teknolojide değil, kararların eksik olmasındadır: hangi verinin sahibi kim, hangi sistem doğruyu söyler, bir mesaj kaybolursa ne olur? Bu rehber önce bu kararları, ardından teknik desenleri ele alır.
Sistem envanteri
Entegrasyon tasarımı, mevcut sistem haritasının çıkarılmasıyla başlar. Envanter yalnızca yazılım adlarının listesi değildir; her sistemin hangi veriyi tuttuğunu, hangi arayüzleri sunduğunu, kim tarafından yönetildiğini ve hangi kısıtlara sahip olduğunu gösterir.
Elle yapılan aktarımlar en değerli bulgulardır. Bir kullanıcının her sabah bir sistemden aldığı listeyi başka bir sisteme girmesi, hem otomasyon fırsatı hem de bugün var olan bir veri tutarsızlığı riskidir.
Envanteri bir kez çıkarıp bırakmayın. Her yeni sistem, sürüm yükseltmesi veya arayüz değişikliği envantere işlenmelidir. Pratikte bunu sağlamanın en kolay yolu, envanteri arayüz tanım belgeleriyle aynı yerde tutmak ve değişiklik talebi sürecine “envanter güncellendi mi?” adımını eklemektir. Böylece canlı sonrası destek ekibi, bir hatayı incelerken hangi sistemlerin ve akışların etkilendiğini tek bir yerden görebilir; yeni bir proje başladığında da sıfırdan keşif yapmak yerine güncel bir haritayla yola çıkılır.
ISA-95 seviyeleri: ERP, MES ve kontrol
ISA-95 (IEC 62264), iş sistemleri ile üretim kontrol sistemleri arasındaki entegrasyonu tanımlayan uluslararası bir standarttır. Standardın seviye modeli, hangi kararın hangi katmanda ve hangi zaman ölçeğinde verildiğini netleştirir; böylece her verinin nerede yaşaması gerektiğine karar vermek kolaylaşır.
- Seviye 4: İş planlamaERP: sipariş, stok, maliyet
- Seviye 3: Üretim yönetimiMES: iş emri, izlenebilirlik, OEE
- Seviye 2: Gözetim ve kontrolSCADA, HMI
- Seviye 1: Algılama, kumandaPLC, sensör, sürücü
- Seviye 0: Fiziksel prosesMakine ve proses ekipmanı
- Seviye 4 (iş planlama ve lojistik): ERP; gün, hafta ve ay ölçeğinde planlama, satın alma, stok ve maliyet.
- Seviye 3 (üretim operasyonları yönetimi): MES ve benzeri sistemler; vardiya, saat ve dakika ölçeğinde iş emri, izlenebilirlik, kalite ve performans.
- Seviye 2, 1 ve 0 (kontrol): SCADA, PLC, sensör ve fiziksel proses; saniye ve milisaniye ölçeğinde kontrol.
Genel kural: ERP doğrudan PLC ile konuşmamalıdır. Saha verisi seviye 3'te toplanır, anlamlandırılır ve ERP'ye özet olarak (üretim girişi, sarf, hurda) aktarılır. Bu ayrım hem performansı hem de güvenliği korur.
Ana kaynak kararları
Ana kaynak (source of truth), bir veri nesnesinin oluşturulduğu, değiştirildiği ve doğruluğundan sorumlu olunan tek sistemdir. Diğer sistemler bu verinin kopyasını kullanabilir ama değiştirmez. Her veri nesnesi için bu karar yazılı olarak verilmezse aynı kayıt iki sistemde farklı değerlerle yaşamaya başlar.
| Veri nesnesi | Tipik ana kaynak | Tüketen sistemler |
|---|---|---|
| Malzeme kartı | ERP | MES, kalite, depo |
| Cari (müşteri, tedarikçi) | ERP | CRM, kalite |
| Ürün ağacı ve rota | ERP veya PLM / MRP | MES, maliyet |
| Satış siparişi | ERP | Planlama, CRM |
| İş emri durumu | MES / MRP | ERP, raporlama |
| Üretim girişi ve sarf | MES / MRP | ERP (stok, maliyet) |
| Ekipman ve bakım geçmişi | Bakım sistemi | MES, OEE raporları |
| Kalite sonuçları ve uygunsuzluk | Kalite sistemi | MES, ERP (blokaj) |
| Kontrollü doküman | Doküman sistemi | MES, kalite |
Tablodaki atamalar tipik bir başlangıç noktasıdır; sizin yapınızda farklı olabilir. Önemli olan her satır için tek bir cevap olması ve bu cevabın iş sahipleri tarafından onaylanmasıdır. Alan bazında istisnalar (ör. malzeme kartı ERP'de, ama raf ömrü kalite sisteminde) varsa bunlar da ayrıca yazılmalıdır.
Entegrasyon desenleri
Doğru entegrasyon deseni; verinin ne kadar güncel olması gerektiğine, hacmine, kaynak sistemin sunduğu imkânlara ve hata toleransına göre seçilir. Tek bir projede birden fazla desen kullanmak normaldir.
| Desen | Güçlü yanı | Zayıf yanı |
|---|---|---|
| Dosya aktarımı (CSV, XML) | Basit, her sistemde var | Gecikmeli, hata takibi zor |
| Doğrudan veritabanı | Hızlı kurulur | Sıkı bağımlılık, sürüm riski |
| REST API | Standart, yetkilendirilebilir | Kaynak sistemin API'sine bağlı |
| Mesaj kuyruğu | Gevşek bağlı, dayanıklı | Altyapı ve işletme bilgisi ister |
| ETL / toplu yükleme | Büyük hacim, raporlama için uygun | Gerçek zamanlı değil |
| CDC (değişiklik yakalama) | Kaynağa az yük, güncel veri | Kurulum ve izleme karmaşık |
Başka bir sistemin veritabanına doğrudan yazmaktan kaçının. Bu yöntem hızlı görünür ama iş kurallarını atlar, yazılım güncellemelerinde bozulur ve çoğu zaman üretici desteğini riske atar. Okuma için bile mümkünse sistemin sunduğu görünüm veya API'yi tercih edin.
Arayüz tanım şablonu
Her entegrasyon akışı için bir arayüz tanım belgesi hazırlanmalıdır. Bu belge, geliştiricinin, test ekibinin ve canlı sonrası destek ekibinin aynı referansa bakmasını sağlar. Aşağıdaki alanlar iyi bir başlangıç şablonudur.
| Alan | İçerik |
|---|---|
| Arayüz kodu ve adı | Benzersiz kimlik, ör. INT-ERP-MES-01 |
| Kaynak ve hedef | Gönderen ve alan sistem |
| İş amacı | Bu akış hangi iş ihtiyacını karşılar |
| Tetikleyici ve sıklık | Olay, zamanlanmış görev, anlık |
| Desen ve protokol | REST, kuyruk, dosya, CDC |
| Alan eşleştirmesi | Kaynak alan, hedef alan, dönüşüm |
| Doğrulama kuralları | Zorunlu alanlar, formatlar, kod listeleri |
| Benzersiz anahtar | Mükerrer kontrolü için iş anahtarı |
| Hata davranışı | Yeniden deneme, bekletme, bildirim |
| Hacim ve performans | Beklenen kayıt sayısı, süre hedefi |
| Güvenlik | Hesap, yetki, şifreleme, kişisel veri |
| Sahipler | İş sahibi, teknik sahip, destek ekibi |
Hata yönetimi, yeniden deneme ve idempotency
Her entegrasyon er geç hata alır: ağ kesilir, hedef sistem bakımdadır, bir kod listesi eksiktir. İyi tasarım hatayı önlemeye değil, hatayı görünür, güvenli ve kurtarılabilir kılmaya odaklanır.
- 01AlMesajı benzersiz kimliğiyle kaydet
- 02DoğrulaZorunlu alan ve kod kontrolü
- 03DönüştürAlan eşleştirmesini uygula
- 04YazHedefe idempotent olarak işle
- 05OnaylaSonucu kaynağa ve loga bildir
- Geçici ve kalıcı hatayı ayırın: ağ zaman aşımı yeniden denenir; eksik malzeme kodu yeniden denenerek düzelmez, bir insana bildirilmelidir.
- Yeniden denemeyi artan aralıklarla yapın (exponential backoff) ve bir üst sınır koyun; sınır aşıldığında mesaj bekletme kuyruğuna (dead letter) alınır.
- Idempotency: aynı mesaj iki kez gelirse sonuç değişmemelidir. Bunun için her mesaj benzersiz bir iş anahtarı (ör. kaynak sistem + belge numarası + satır) taşır ve hedef bu anahtarı daha önce işleyip işlemediğini kontrol eder.
- Sıralama: aynı kayda ait mesajların sırası önemliyse (ör. iş emri aç, sonra kapat) bunu desen seçiminde ve anahtar tasarımında dikkate alın.
- Elle müdahale: bekletme kuyruğundaki mesajları görüntüleme, düzeltme ve yeniden gönderme yetkisinin kimde olduğunu tanımlayın.
Loglama ve izleme
Loglama, “bu sipariş neden ERP'ye geçmedi?” sorusuna dakikalar içinde cevap verebilmek içindir. İzleme ise bu soruyu kullanıcı sormadan önce sormanızı sağlar.
- Her mesaj için zaman damgası, arayüz kodu, iş anahtarı, sonuç ve hata mesajı loglanır.
- Loglar tek bir yerde toplanır ve iş anahtarıyla aranabilir.
- Kişisel veri içeren alanlar loglara açık metin olarak yazılmaz; gerekiyorsa maskelenir.
- İzleme göstergeleri: işlenen mesaj sayısı, hata sayısı, bekletme kuyruğundaki mesaj sayısı, gecikme.
- Eşik aşıldığında (ör. kuyrukta bekleyen mesaj veya son başarılı aktarımdan bu yana geçen süre) uyarı üretilir ve sorumluya iletilir.
- Log saklama süresi, denetim ve yasal ihtiyaçlara göre belirlenir.
OREL DM, veri hatlarının ne zaman ve neden durduğunu izlemek ve hangi verinin nereden geldiğini köken bilgisiyle göstermek için kullanılabilir. Böylece entegrasyon izleme, ayrı ayrı araçlara dağılmadan tek bir yerden yapılır.
Güvenlik ve KVKK
Entegrasyon hesapları çoğu zaman sistemlerdeki en yetkili ve en az izlenen hesaplardır. Bu nedenle güvenlik, tasarımın ilk gününden itibaren ele alınmalıdır.
KVKK açısından entegrasyonun kendisi bir veri aktarımıdır. Hangi kişisel verinin, hangi amaçla, hangi sisteme ve (bulut kullanılıyorsa) hangi ülkeye aktarıldığı belgelenmelidir. Bu değerlendirmenin nihai kararı hukuk veya uyum uzmanınızla birlikte verilmelidir.
Test stratejisi
Entegrasyon testi, her iki sistemin de ayrı ayrı doğru çalışmasının, birlikte doğru çalışacakları anlamına gelmediği varsayımıyla kurulur. Test katmanları birbirini tamamlar; hiçbiri tek başına yeterli değildir.
- Mutabakatİki sistemin sonuçları aynı mı?
- Uçtan uca testGerçek iş senaryosu, tüm sistemler
- Sözleşme testiArayüz şablonuna uyum
- Birim testiDönüşüm ve doğrulama kuralları
- 01Birim testleri
Alan dönüşümleri, birim çevrimleri, kod eşleştirmeleri ve doğrulama kuralları tek tek test edilir.
- 02Sözleşme testleri
Gönderen ve alan tarafın arayüz tanımına (alanlar, tipler, zorunluluklar) uyduğu, iki taraf birbirinden bağımsız değişse bile kontrol edilir.
- 03Uçtan uca testler
Satış siparişinden üretime, üretimden stok ve maliyete kadar gerçek iş senaryoları test ortamında tüm sistemlerle çalıştırılır; hata senaryoları (kesinti, mükerrer mesaj, eksik kod) da dahil edilir.
- 04Mutabakat testleri
Belirli bir dönem için iki sistemdeki kayıt sayıları, miktarlar ve tutarlar karşılaştırılır; farkların her biri açıklanır.
- 05Performans testi
Beklenen en yoğun hacim (ay sonu, sezon) test ortamında denenir; süre ve kaynak kullanımı ölçülür.
Testlerin yalnızca “mutlu yol” ile yapılması en sık görülen eksikliktir. Ağ kesintisi, hedef sistemin bakımda olması, aynı mesajın iki kez gelmesi ve eksik ana veri senaryoları test edilmeden canlıya geçilen entegrasyonlar, ilk gerçek hatada sessizce veri kaybedebilir.
Canlıya geçiş ve sahiplik
Entegrasyonun canlıya geçişi, ana veri ve açık bakiyelerin aktarımıyla birlikte planlanmalıdır. Hangi akışın hangi sırayla açılacağı, eski aktarımların ne zaman kapatılacağı ve paralel çalışma süresi önceden yazılır.
| Rol | Sorumluluk |
|---|---|
| İş sahibi | Verinin anlamı ve doğruluğu, değişiklik onayı |
| Teknik sahip | Arayüzün çalışması, değişiklik geliştirme |
| Destek ekibi | İzleme, ilk müdahale, yeniden gönderme |
| Güvenlik / uyum | Hesap ve yetki denetimi, KVKK değerlendirmesi |
Sahipliği belirsiz bir entegrasyon, canlıya geçişten birkaç ay sonra kimsenin dokunmaya cesaret edemediği bir kara kutuya dönüşür. Her değişiklik talebinin arayüz tanım belgesinde güncellenmesi ve sahiplerin düzenli olarak hata ve mutabakat raporlarını gözden geçirmesi bu riski azaltır.
Canlıya geçişten sonraki ilk haftalarda entegrasyon hatalarını günlük olarak gözden geçirmek önerilir. Bu dönemde ortaya çıkan hataların çoğu ana veri eksikliklerinden, kod listelerindeki farklardan veya test ortamında görülmeyen hacim etkilerinden kaynaklanır. Her hatanın kök nedenini kaydedin ve aynı türden hatanın tekrar etmemesi için kalıcı düzeltmeyi (doğrulama kuralı, ana veri süreci veya arayüz değişikliği) belirleyin. Hata oranı düşüp oturduktan sonra gözden geçirme haftalık veya aylık sıklığa çekilebilir.
Sonuç
İyi bir ERP entegrasyonu, doğru araç seçiminden önce doğru kararlarla başlar: envanter, ana kaynak, arayüz tanımı ve sahiplik. Ardından hatayı görünür ve kurtarılabilir kılan tasarım, en az yetkiyle çalışan güvenlik ve mutlu yolun ötesine geçen testler gelir. Bu rehberdeki kontrol listelerini her yeni arayüz için yeniden kullanarak entegrasyonlarınızı tek tek değil, tutarlı bir mimari olarak yönetebilirsiniz.