«Integrasi ERP yang mulus» adalah janji standar yang, dalam praktiknya, diikuti oleh proyek berdurasi tiga bulan. Kami menerbitkan Panduan API kami agar tim TI Anda dapat memeriksa apa saja yang sebenarnya akan diakses sebelum menandatangani kontrak. Berikut ini hal-hal yang perlu Anda ketahui sebelum memulai proyek integrasi.
Apa yang Sebenarnya Harus Disediakan oleh ERP Anda
Agar DPP dapat terbentuk, kami memerlukan hal-hal berikut per produk:
- Data master - nomor artikel, deskripsi, varian, berat, dimensi, gambar
- Data daftar bahan - komponen beserta jumlah dan persentase bahan daur ulang
- Data asal - lokasi produksi, nomor batch, tanggal produksi
- Data lingkungan - CO2eq per unit, konsumsi air, konsumsi energi
- Data pemasok - siapa yang memasok komponen apa (untuk due diligence)
Secara teoritis, semua data ini tersedia di sistem ERP Anda. Namun dalam praktiknya, data tersebut tersebar di 4 hingga 7 modul: Manajemen Material (MM), Produksi (PP), Kualitas (QM), Pemasok (LFA1), terkadang modul EHS terpisah untuk data lingkungan, dan terkadang sistem PLM untuk formulasi.
Pertanyaan mengenai integrasi bukanlah: «Apakah sistem ERP Anda mengirimkan data ke DPP?» Melainkan: «Bagaimana Anda menggabungkan data dari 5 subsistem menjadi satu set data yang utuh?»
Tiga pola integrasi yang telah teruji
Pola 1: OData / REST-Pull
Berfungsi dengan baik pada ERP modern (SAP S/4HANA Cloud, Dynamics 365, Odoo). Penyedia DPP mengambil data melalui OData atau REST. Secara bertahap, terjadwal, atau berbasis peristiwa.
Keuntungan: pengembangan yang minimal dari pihak Anda; Anda menyediakan kredensial baca, sedangkan penyedia yang membangun transformasi data.
Kekurangan: tidak berfungsi dengan instalasi SAP ECC versi lama tanpa lapisan API tambahan. Anda memerlukan tata kelola atas Permintaan Akses Data.
Pola 2: Integrasi Berbasis Peristiwa
SAP Event Mesh, Apache Kafka, RabbitMQ. Sistem ERP Anda mempublikasikan peristiwa perubahan, sedangkan penyedia DPP mengonsumsinya.
Keuntungan: hampir real-time, skalabilitas yang elegan, terpisah.
Kekurangan: Pengaturannya rumit dan membutuhkan infrastruktur yang tidak dimiliki oleh setiap departemen TI. Biasanya berlebihan untuk perusahaan kecil.
Pola 3: Middleware / ETL
Anda memiliki lapisan integrasi (Mulesoft, Boomi, Informatica, Azure Data Factory) di antara ERP dan sistem eksternal. Middleware ini berfungsi sebagai perantara - penyedia DPP berkomunikasi dengan middleware, bukan langsung dengan ERP.
Keuntungan: investasi yang sudah ada dapat dimanfaatkan, tata kelola yang stabil, tidak ada akses langsung ke ERP bagi pihak ketiga.
Kekurangan: Biaya middleware Anda akan meningkat seiring pertumbuhan.
Apa yang Kami Lakukan Secara Berbeda dalam Proyek-Proyek Konkret
Banyak penyedia ingin terhubung langsung dengan ERP Anda. Kami secara prinsip memasukkan langkah perantara: API kami menerima skema JSON netral, yang dapat Anda isi menggunakan alat pilihan Anda. Artinya:
- Anda dapat melakukan persiapan data sendiri, menggunakan alat yang sudah dikenal oleh tim Anda
- Anda dapat mengganti penyedia layanan kami - format netral ini bersifat portabel
- Anda dapat mengambil kembali seluruh data Anda kapan saja - dalam format CSV, XLSX, JSON-LD, dan SQL, serta melalui REST-API
- Kami menyediakan validator impor yang memeriksa data Anda sebelum diunggah
Skema lengkap dan semua titik akhir (endpoint) didokumentasikan secara publik sebagai spesifikasi OpenAPI di /apidocs. Tim TI Anda dapat memeriksa antarmuka ini sebelum kontrak ditandatangani - termasuk contoh permintaan, respons kesalahan, dan detail otentikasi.
Jadwal pelaksanaan pendekatan ini dalam praktiknya:
- Hari 1 hingga 2: Lokakarya pemetaan. Bidang ERP mana yang akan dipetakan ke bidang DPP mana?
- Hari ke-3 hingga ke-5: Ekspor JSON pertama dari ERP, melalui validator kami.
- Hari ke-6 hingga ke-8: Pemecahan masalah (bidang yang hilang, pengkodean yang tidak konsisten).
- Hari ke-9 hingga ke-10: DPP pertama sudah aktif.
Dua minggu, bukan tiga bulan. Kunci utamanya adalah lokakarya pemetaan - di situlah kualitas data ditentukan.
Apa yang bisa salah: jebakan paling umum
Data master produk tersebar di beberapa sistem: SAP memiliki nomor artikel, PIM memiliki gambar dan teks pemasaran, PLM memiliki daftar bahan. Tidak ada yang memiliki gambaran yang konsisten. Solusi: tentukan sebelum proyek dimulai sistem mana yang menjadi “Sumber Kebenaran” untuk setiap kolom.
Sertifikat dalam format PDF: Pemasok mengirimkan sertifikat GOTS, OEKO-TEX, atau REACH dalam bentuk pindaian PDF. Ini bukanlah sumber data yang terstruktur. Solusi: Lembaga sertifikasi semakin banyak menawarkan permintaan melalui API (OEKO-TEX memimpin, GOTS tertinggal). Atau: masukkan data secara manual, tetapi sertakan tanggal berlaku agar sertifikat yang sudah kadaluwarsa tidak muncul di DPP.
Kerahasiaan Resep: terutama di bidang kosmetik, makanan, dan farmasi: resep lengkap merupakan rahasia perusahaan. Apakah DPP harus mempublikasikannya? Solusi: Model tiga tingkatan ESPR. Kategori produk dipublikasikan, sementara otoritas dapat melihat formulasi lengkapnya. Hampir tidak pernah menjadi penghambat, tetapi harus diklarifikasi sejak dini.
Data CO₂ berdasarkan pemasok: Pemasok Anda memberikan nilai rata-rata untuk seluruh portofolionya, bukan per batch. Solusi: Terima untuk sementara, sesuaikan kontrak pemasok dalam jangka panjang. ESPR mensyaratkan nilai spesifik produk mulai dari tanggal tertentu, tetapi praktik saat ini merupakan kompromi.
Versi bahasa lokal: Sistem ERP Anda hanya berisi nama produk dalam bahasa Jerman dan Inggris. Untuk 27 negara UE, Anda memerlukan lebih dari itu. Solusi: terjemahan mesin dengan basis data terminologi; kami memiliki artikel terpisah mengenai hal ini.
Pertanyaan yang harus Anda ajukan sebelum memulai proyek
Sebelum Anda mengirimkan RFP ke tiga penyedia layanan, jawablah pertanyaan-pertanyaan berikut secara internal:
- Berapa banyak produk/nomor artikel yang harus memiliki DPP? (10, 10.000, 1 juta?)
- Sistem apa saja yang saat ini menyimpan data yang relevan dengan DPP?
- Departemen mana yang mengelola masing-masing sistem tersebut?
- Apakah Anda memiliki investasi middleware yang sebaiknya dimanfaatkan?
- Apakah sudah ada lapisan API yang berfungsi di atas sistem ERP Anda?
Jawaban-jawaban tersebut akan menentukan mana dari ketiga model yang paling sesuai untuk Anda. Dan jawaban-jawaban tersebut juga akan menentukan apakah proyek ini akan memakan waktu dua minggu atau enam bulan.