Bir ürünün ağırlığı malzeme yönetiminde yer alır. Geri dönüştürülmüş malzeme oranı ise formülasyon sisteminde bulunur. Tedarikçinin sertifikası bir ağ sürücüsünde PDF olarak bulunur. Ürün pasaportu, bu üç bilgiyi tek bir veri kaydında bir araya getirmelidir; entegrasyon projesinin özü tam da budur, iki sistemin birbirine bağlanmasında değil.
“Kesintisiz ERP entegrasyonu”, pratikte üç aylık bir projenin ardından gelen standart bir vaattir. Sözleşmeyi imzalamadan önce BT ekibinizin gerçekte hangi verilerin talep edildiğini kontrol edebilmesi için kılavuzumuzu yayınlıyoruz. Bu makale, pasaportun sistemlerinizden hangi verilere ihtiyaç duyduğunu, bu verilerin bize hangi üç yolla ulaştığını ve bunun neden iki hafta içinde gerçekleştirilebileceğini göstermektedir.
ERP sisteminizin aslında neyi sağlaması gerekiyor?
Bir DPP oluşturulabilmesi için her ürün başına şunlara ihtiyacımız var:
- Ana veriler - Ürün kodu, ad, varyantlar, ağırlıklar, boyutlar, resimler
- Parça listesi verileri - Miktarları ve geri dönüştürülmüş malzeme oranları ile birlikte bileşenler
- Menşe verileri - Üretim yeri, parti numarası, üretim tarihi
- Çevresel veriler - Birim başına CO2eq, su tüketimi, enerji tüketimi
- Tedarikçi verileri - Hangi bileşeni kim tedarik ediyor (durum tespiti yükümlülükleri için)
Teorik olarak bu verilerin tümü ERP sisteminizde mevcuttur. Pratikte ise bu veriler 4 ila 7 modüle dağılmıştır: Malzeme yönetimi, üretim, kalite, tedarikçi kütüğü; bazen çevre verileri için ayrı bir modül, bazen de formüller ve parça listeleri için ayrı bir sistem.
Entegrasyon sorusu şu değildir: «ERP sisteminiz bir DPP’ye veri sağlıyor mu?» Asıl soru şudur: «5 alt sistemdeki verileri nasıl tek bir tutarlı veri kümesine birleştirirsiniz?»
Üç kanıtlanmış yöntem
Yöntem 1: Verileri ERP sisteminden almak
Modern ERP’lerde (SAP S/4HANA Cloud, Dynamics 365, Odoo) iyi sonuç verir. DPP sağlayıcısı, verileri ERP’nin arayüzü üzerinden alır (teknik olarak OData veya REST). Yalnızca değişiklikler alınır; bunlar zamanlamaya göre veya bir olayın tetiklemesiyle gerçekleşir.
Avantajlar: Sizin tarafınızdan çok az geliştirme gerektirir; siz okuma erişimi sağlarsınız, sağlayıcı ise dönüştürmeyi gerçekleştirir.
Dezavantajlar: Ek bir arayüz katmanı olmadan eski SAP ECC kurulumlarında çalışmaz. Kimin hangi verileri okuyabileceğine dair net kurallara ihtiyacınız vardır.
Yöntem 2: Değişiklikleri iletmek
ERP sisteminiz her değişikliği bir olay olarak bildirir (SAP Event Mesh, Apache Kafka veya RabbitMQ üzerinden), DPP sağlayıcısı da bunları alır.
Avantajlar: Neredeyse gerçek zamanlıdır, sistemler birlikte büyür, sistemler birbirine bağımlı değildir.
Dezavantajları: Kurulumu zordur ve her BT departmanının sahip olmadığı bir altyapı gerektirir. Küçük şirketler için genellikle aşırıdır.
Yöntem 3: Mevcut entegrasyon katmanını kullanmak
ERP ile harici sistemler arasında halihazırda bir entegrasyon katmanınız (Mulesoft, Boomi, Informatica, Azure Data Factory) bulunmaktadır. Bu katman, bir nevi anlaşma görevi görür: DPP sağlayıcısı doğrudan ERP ile değil, bu katmanla iletişim kurar.
Avantajlar: Mevcut yatırımlardan yararlanılabilir, kurallar sabit kalır, üçüncü tarafların ERP’ye doğrudan erişimi olmaz.
Dezavantajlar: Entegrasyon katmanı maliyetleriniz de artar.
Somut projelerde farklı olarak yaptığımız şey
Birçok sağlayıcı, ERP’nize doğrudan bağlanmak ister. Biz ise prensip olarak bir ara adım ekliyoruz: Arayüzümüz, sizin seçtiğiniz bir araçla doldurabileceğiniz tarafsız bir veri formatı (bir JSON şeması) kabul eder. Bu şu anlama gelir:
- Veri hazırlığını, ekibinizin aşina olduğu araçları kullanarak kendiniz yapabilirsiniz
- Bizi başka bir sağlayıcıyla değiştirebilirsiniz - tarafsız format taşınabilirdir
- Tüm verilerinizi istediğiniz zaman geri alabilirsiniz - CSV, XLSX, JSON-LD ve SQL formatlarında ve REST-API üzerinden
- Verilerinizi yüklemeden önce kontrol eden bir içe aktarma doğrulayıcısı sunuyoruz
Biçimin tamamı ve tüm sorgular, OpenAPI uyumlu bir arayüz açıklaması olarak API Belgeleri adresinde kamuya açık olarak açıklanmıştır. BT ekibiniz, sözleşme imzalanmadan önce arayüzü inceleyebilir; buna örnek sorgular, hata yanıtları ve kimlik doğrulama ayrıntıları da dahildir.
Bu yaklaşımla pratikteki zaman çizelgesi:
- 1. ve 2. gün: Eşleme atölyesi. Hangi ERP alanı, hangi DPP alanına karşılık gelir?
- 3. ila 5. gün: ERP’den ilk JSON dışa aktarımları, doğrulayıcımız aracılığıyla.
- 6. ila 8. gün: Hata giderme (eksik alanlar, tutarsız kodlamalar).
- 9. ila 10. gün: İlk DPP’ler yayına alınır.
İki hafta, üç ay değil. Kilit nokta eşleme atölyesidir; veri kalitesi burada belirlenir.
Neler ters gidebilir: en sık karşılaşılan tuzaklar
Birden fazla sistemde bulunan ürün ana verileri: SAP’de ürün kodu, PIM’de görseller ve pazarlama metinleri, PLM’de parça listesi bulunur. Kimsenin elinde tutarlı bir tablo yok. Çözüm: Projeye başlamadan önce, hangi sistemin hangi alan için referans olacağını belirleyin.
PDF formatındaki sertifikalar: Tedarikçiler, GOTS, OEKO-TEX veya REACH sertifikalarını taranmış PDF olarak teslim ediyor. Bu, yapılandırılmış bir veri kaynağı değildir. Çözüm: Sertifikasyon kuruluşları giderek daha fazla arayüz üzerinden sorgulama imkanı sunmaktadır (OEKO-TEX bu konuda önde, GOTS ise geride kalmaktadır). Ya da: manuel olarak girin, ancak geçerlilik tarihini de ekleyin; böylece DPP’de süresi dolmuş sertifikalar görünmez.
Formül gizliliği: Özellikle kozmetik, gıda ve ilaç sektörlerinde, formülün tamamı ticari sır niteliğindedir. DPP bunları kamuya açık hale mi getirmeli? Çözüm: ESPR’nin üç aşamalı modeli. Ürün kategorisi kamuya açıktır, yetkili makamlar ise formülün tamamını görebilir. Neredeyse hiçbir zaman engel teşkil etmez, ancak erken aşamada netleştirilmesi gerekir.
Tedarikçiye dayalı CO2 verileri: Tedarikçiniz, parti bazında değil, tüm portföyü için bir ortalama değer vermektedir. Çözüm: Geçici olarak kabul edin, uzun vadede tedarikçi sözleşmelerini uyarlayın. ESPR, belirli bir tarihten itibaren ürüne özgü değerler talep etmektedir, ancak mevcut uygulama bir uzlaşmadır.
Yerel dil sürümleri: ERP sisteminizde ürün adları yalnızca Almanca ve İngilizce olarak yer almaktadır. 27 AB ülkesi için daha fazlasına ihtiyacınız vardır. Çözüm: Terminoloji veritabanı destekli makine çevirisi; bu konuda ayrı bir makalemiz bulunmaktadır.
Projeye başlamadan önce sormanız gereken sorular
Üç tedarikçiye bir RFP göndermeden önce, şirket içinde şu soruları yanıtlayın:
- DPP’lerde kaç ürün/ürün kodu bulunmalıdır? (10, 10.000, 1 milyon?)
- Günümüzde hangi sistemler DPP ile ilgili verileri barındırıyor?
- Her bir sistemi hangi departman yönetiyor?
- Kullanılması gereken bir entegrasyon katmanı var mı?
- ERP sisteminiz üzerinden halihazırda çalışan bir arayüz var mı?
Cevaplar, üç yoldan hangisinin size uygun olduğunu belirler.
Cevaplar, bir projenin iki hafta mı yoksa altı ay mı süreceğini belirler.
Bu yazıyla ilgili sorular
REST arayüzü yeterli mi, yoksa bir ara yazılım mı gerekiyor?
Arayüz yeterlidir. Bu üç örnekte fark, dönüşümün nerede gerçekleştiği ile ilgilidir; neyi kabul ettiğimizle değil - arayüzümüz, onu neyle oluşturmuş olursanız olun tarafsız bir JSON şemasını kabul eder. Modern bir ERP sisteminden yapılan bir veri çekme işlemi, bir olay akışı ve mevcut bir entegrasyon katmanı, hepsi aynı uç noktada son bulur. Zaten bir orta katman yazılımı kullanıyorsanız ve bunun üçüncü taraflarla olan sözleşmenizin bir parçası olarak kalması gerekiyorsa, bunu kullanmaya devam etmenizde fayda vardır. Şu anda elinizde yoksa, ürün sertifikası için yeni bir tane satın almayın.
Haritalama atölyesinde neler kararlaştırılacak?
Hangi ERP alanı hangi eşleme alanı olacak ve birden fazla sistem aynı değeri barındırıyorsa hangisi öncelikli kaynak olacak? Çalıştay 1. ve 2. günlerde düzenlenecek ve tüm projenin en kritik noktasıdır; çünkü veri kalitesiyle ilgili kararlar burada alınacak, kod yazım aşamasında değil. Sadece projeden sorumlu kişileri değil, sistemleri yöneten kişileri de atölyeye getirin - ana veriler, üretim, kalite ve satın alma nadiren tek bir departmanda bulunur. Bundan sonraki tüm aşamalar, yani veri aktarımları, doğrulama ve hata giderme, zanaat niteliğindedir.
Sertifikalarımız sadece PDF formatında taranmış haliyle mevcut. Bunlarla ne yapacağız?
Bir tarama, yapılandırılmış bir veri kaynağı değildir ve bu nedenle Pas için kullanılamaz. İki yöntem işe yarar: Sertifika sağlayıcıları giderek daha fazla API sorgusu sunmaktadır; bunların bulunmadığı durumlarda ise değerleri manuel olarak girin, ancak yayınlanan Pas’ta süresi dolmuş bir sertifikanın kalmaması için her zaman geçerlilik tarihini de ekleyin. Manuel yöntemi tek seferlik bir görev olarak değil, tekrarlanan bir iş olarak planlayın.
Bir şeyi imzalamadan önce BT ekibimiz bu arayüzü kontrol edebilir mi?
Evet. Tam şema ve tüm uç noktalar, örnek istekler, hata yanıtları ve kimlik doğrulama ayrıntılarıyla birlikte API Belgeleri adresinde OpenAPI spesifikasyonu olarak mevcuttur. Bunların hiçbiri satış görüşmesinin arkasında gizli değildir; dolayısıyla entegrasyon ekibiniz, bir sözleşme imzalanmadan önce gerekli çabayı tahmin edebilir. Bir sağlayıcı bu aşamada arayüzünü göstermezse, bu da bir cevaptır.
Sağlayıcıyı değiştirdiğimizde verilerimize ne olur?
Bunlar da dahil. Arayüz, özel bir format yerine tarafsız bir JSON şeması kabul eder ve tüm verileriniz CSV, XLSX, JSON-LD ve SQL formatlarında ya da REST API aracılığıyla geri verilir. Bu kasıtlı bir tasarımdır - veri girdiğiniz format taşınabilirdir; dolayısıyla bir değişiklik yapmak için yeniden oluşturmaya gerek kalmaz, sadece bir dışa aktarma işlemi yeterlidir. Eşleme atölyesi öncesinde her sağlayıcıya aynı soruyu sorun; çünkü atölye sonrasında alan adlarınız o sağlayıcının modelinde yer alacaktır.
Bir bağlantının kurulması gerçekten ne kadar sürer?
Desteklediğimiz projelerde, iki hafta sürer: iki gün haritalama, Validator’umuz aracılığıyla ilk dışa aktarımların gerçekleşmesine kadar üç gün, hata giderme için üç gün ve ilk pasaportların yayınlanmasına kadar iki gün. Asıl uzun yol hiçbir zaman kod değildir; asıl uzun yol, Validator’ın tespit ettikleri şeylerdir: eksik alanlar, tutarsız kodlamalar, kimsenin sorumluluğunu üstlenmediği değerler. Bu günleri kısaltmak yerine planlamaya dahil edin. Bu aşamaları atlayan bir proje, eksiklikleri de beraberinde yayınlamış olur.
Tüm ürünleri tek seferde sisteme eklememiz gerekiyor mu?
Hayır. Öncelikle bir geçiş gerektiren ürünlerle ve bir kaynak sistemle başlayın - tarafsız şema, kısmi bir kataloğu da tam bir kataloğu da kabul eder ve içe aktarmalar tekrarlanabilir; dolayısıyla sonraki çalıştırmalar envanteri günceller. Bu sayede eşleme atölyesi de iki günde tamamlanabilecek kadar kısa tutulur. Sonrasındaki genişletme ise bir eşleme görevidir, yeni bir proje değildir.
