Berat suatu produk tercantum di modul Manajemen Material. Persentase bahan daur ulang tercantum di sistem formulasi. Sertifikat pemasok tersedia dalam format PDF di drive jaringan. Paspor produk memerlukan ketiga informasi tersebut dalam satu set data, dan di sinilah letak inti proyek integrasi, bukan pada penghubungan dua sistem.
“Integrasi ERP yang mulus” adalah janji standar yang dalam praktiknya diikuti oleh proyek berdurasi tiga bulan. Kami menerbitkan panduan ini agar tim TI Anda dapat memeriksa apa saja yang sebenarnya diminta sebelum menandatangani kontrak. Artikel ini menjelaskan data apa saja yang dibutuhkan Pas Produk dari sistem Anda, melalui tiga jalur mana data tersebut dikirimkan kepada kami, dan mengapa proses ini dapat diselesaikan dalam dua minggu.
Apa yang Sebenarnya Harus Disediakan oleh Sistem ERP Anda
Agar Pas Produk (DPP) dapat dibuat, kami membutuhkan per produk:
- Data master - nomor artikel, deskripsi, varian, berat, dimensi, gambar
- Data daftar bahan (BOM) - 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 kewajiban 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, Produksi, Kualitas, Daftar Pemasok, terkadang ada modul terpisah untuk data lingkungan, dan terkadang sistem tersendiri untuk formulasi dan daftar bagian.
Pertanyaan mengenai integrasi bukanlah: “Apakah sistem ERP Anda mengirimkan data ke DPP?” Melainkan: “Bagaimana cara Anda menggabungkan data dari 5 subsistem menjadi satu set data yang utuh?”
Tiga cara yang telah teruji
Cara 1: Mengambil data dari sistem ERP
Cara ini bekerja dengan baik pada ERP modern (SAP S/4HANA Cloud, Dynamics 365, Odoo). Penyedia DPP mengambil data melalui antarmuka ERP (secara teknis menggunakan OData atau REST). Hanya perubahan yang diambil, baik sesuai jadwal maupun dipicu oleh suatu peristiwa.
Keuntungan: pengembangan yang minim dari pihak Anda; Anda menyediakan akses baca, sedangkan penyedia yang menangani konversi data.
Kekurangan: tidak berfungsi dengan instalasi SAP ECC versi lama tanpa lapisan antarmuka tambahan. Anda memerlukan aturan yang jelas mengenai siapa yang berhak mengakses data apa.
Cara 2: Meneruskan Perubahan
ERP Anda melaporkan setiap perubahan sebagai peristiwa (melalui SAP Event Mesh, Apache Kafka, atau RabbitMQ), dan penyedia DPP menerimanya.
Keuntungan: hampir secara real-time, dapat berkembang seiring waktu, dan sistem-sistem tersebut tidak saling bergantung.
Kekurangan: Pengaturannya rumit dan membutuhkan infrastruktur yang tidak dimiliki oleh setiap departemen TI. Biasanya terlalu berlebihan untuk perusahaan kecil.
Cara 3: Memanfaatkan lapisan integrasi yang sudah ada
Anda sudah memiliki lapisan ### integrasi(Mulesoft, Boomi, Informatica, Azure Data Factory) di antara ERP dan sistem eksternal. Lapisan ini berfungsi sebagai perantara: Penyedia DPP berkomunikasi dengannya, bukan langsung dengan ERP.
Keuntungan: Investasi yang sudah ada dapat dimanfaatkan, aturan tetap stabil, tidak ada akses langsung ke ERP bagi pihak ketiga.
Kekurangan: Biaya lapisan integrasi Anda pun ikut meningkat.
Apa yang Kami Lakukan Secara Berbeda dalam Proyek-Proyek Konkret
Banyak penyedia ingin terhubung langsung dengan ERP Anda. Kami pada dasarnya menyertakan langkah perantara: Antarmuka kami menerima format data netral (skema JSON) 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
Format lengkap dan semua kueri dijelaskan secara terbuka di Dokumentasi API, sebagai deskripsi antarmuka sesuai standar OpenAPI. Tim TI Anda dapat memeriksa antarmuka ini sebelum kontrak ditandatangani - termasuk contoh permintaan, respons kesalahan, dan detail otentikasi.
Jangka waktu penerapan pendekatan ini dalam praktik:
- Hari 1 hingga 2: Lokakarya pemetaan. Bidang ERP mana yang akan dipetakan ke bidang DPP mana?
- Hari 3 hingga 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 sering salah: jebakan paling umum
Data master produk tersebar di beberapa sistem: SAP memiliki nomor artikel, PIM memiliki gambar dan teks pemasaran, PLM memiliki daftar komponen. Tidak ada yang memiliki gambaran yang konsisten. Solusi: tentukan sebelum proyek dimulai sistem mana yang menjadi sistem utama untuk setiap kolom.
Sertifikat dalam bentuk PDF: pemasok mengirimkan sertifikat GOTS, OEKO-TEX, atau REACH sebagai pindaian PDF. Ini bukanlah sumber data yang terstruktur. Solusi: Lembaga sertifikasi semakin sering menawarkan akses melalui antarmuka (OEKO-TEX sudah lebih maju, sedangkan GOTS masih tertinggal). Atau: masukkan secara manual, tetapi sertakan tanggal berlaku agar sertifikat yang sudah kadaluwarsa tidak muncul di DPP.
Kerahasiaan Resep: terutama di sektor kosmetik, makanan, dan farmasi: resep lengkap merupakan rahasia perusahaan. Apakah DPP harus mempublikasikannya? Solusi: Model Tiga Tingkat dari ESPR. Kategori produk dipublikasikan, sedangkan pihak berwenang dapat melihat formula 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 memuat 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-pertanyaan yang harus Anda ajukan sebelum memulai proyek
Sebelum Anda mengirimkan RFP kepada 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 lapisan integrasi yang sebaiknya digunakan?
- Apakah sudah ada antarmuka yang berfungsi melalui sistem ERP Anda?
Jawaban-jawaban tersebut akan menentukan mana dari tiga pendekatan yang paling sesuai untuk Anda.
Jawaban-jawaban tersebut akan menentukan apakah proyek ini akan berlangsung selama dua minggu atau enam bulan.
Pertanyaan mengenai posting ini
Apakah antarmuka REST sudah cukup, atau apakah kita memerlukan middleware?
Antarmuka tersebut sudah cukup. Ketiga pola tersebut berbeda dalam hal di mana transformasi terjadi, bukan dalam hal apa yang kami terima - antarmuka kami menerima skema JSON netral, apa pun alat yang Anda gunakan untuk membuatnya. Pull dari sistem ERP modern, aliran peristiwa, dan lapisan integrasi yang sudah ada semuanya berakhir di titik akhir yang sama. Penggunaan middleware layak dipertimbangkan jika Anda memang sudah mengoperasikannya dan ingin middleware tersebut tetap menjadi bagian dari perjanjian dengan pihak ketiga. Jika saat ini belum ada, jangan membelinya hanya untuk keperluan sertifikasi produk.
Apa saja yang akan diputuskan dalam lokakarya pemetaan?
Bidang ERP mana yang akan menjadi bidang referensi - dan sistem mana yang menjadi sumber utama jika beberapa sistem menyimpan nilai yang sama. Lokakarya ini diselenggarakan pada Hari 1 dan 2 dan merupakan titik krusial dari keseluruhan proyek, karena keputusan mengenai kualitas data diambil di sana, bukan nanti dalam kode program. Ajaklah orang-orang yang mengelola sistem tersebut, bukan hanya mereka yang bertanggung jawab atas proyek ini - bagian data master, produksi, kualitas, dan pembelian jarang berada dalam satu departemen. Semua proses selanjutnya, yaitu ekspor data, validasi, dan pemecahan masalah, hanyalah urusan teknis.
Sertifikat kami hanya tersedia dalam bentuk pindaian PDF. Apa yang harus kami lakukan dengan ini?
Pindaian bukanlah sumber data terstruktur dan karenanya tidak dapat digunakan untuk paspor. Ada dua cara yang bisa dilakukan - penyedia layanan sertifikasi semakin banyak menawarkan permintaan melalui API, dan jika tidak tersedia, masukkan nilainya secara manual, tetapi selalu sertakan tanggal kedaluwarsa agar tidak ada sertifikat yang kedaluwarsa yang tetap tercantum dalam paspor yang telah diterbitkan. Rencanakan metode manual ini sebagai pekerjaan rutin, bukan sebagai tugas satu kali.
Bisakah tim TI kami memeriksa antarmuka tersebut sebelum kami menandatanganinya?
Ya. Skema lengkap dan semua titik akhir tersedia sebagai spesifikasi OpenAPI di Dokumentasi API, lengkap dengan contoh permintaan, respons kesalahan, dan rincian otentikasi. Semua informasi tersebut dapat diakses tanpa perlu melalui proses negosiasi penjualan, sehingga tim integrasi Anda dapat memperkirakan beban kerjanya sebelum kontrak ditandatangani. Jika penyedia layanan tidak memaparkan antarmukanya pada tahap ini, hal itu juga merupakan pertimbangan tersendiri.
Apa yang terjadi dengan data kita jika kita berganti penyedia layanan?
Data Anda akan disertakan. Antarmuka ini menerima skema JSON netral, bukan format eksklusif, dan seluruh inventaris Anda akan dihasilkan kembali dalam format CSV, XLSX, JSON-LD, dan SQL, atau melalui REST-API. Hal ini memang disengaja - format yang Anda isi bersifat portabel, sehingga berpindah platform hanya memerlukan proses ekspor, bukan pembuatan ulang. Ajukan pertanyaan yang sama kepada setiap penyedia layanan sebelum lokakarya pemetaan, karena setelah itu nama-nama kolom Anda akan tercantum dalam model mereka.
Berapa lama sebenarnya waktu yang dibutuhkan untuk proses integrasi?
Dalam proyek-proyek yang kami dampingi, prosesnya memakan waktu dua minggu - dua hari untuk pemetaan, tiga hari hingga ekspor pertama melalui Validator kami, tiga hari untuk perbaikan kesalahan, dan dua hari hingga paspor pertama diterbitkan. Proses yang memakan waktu bukanlah kode itu sendiri, melainkan apa yang ditemukan oleh Validator - kolom yang hilang, pengkodean yang tidak seragam, serta nilai-nilai yang tidak ada yang bertanggung jawab atasnya. Sediakan waktu untuk hari-hari ini, jangan memotongnya. Proyek yang melewatkan tahap ini akan menerbitkan data yang masih memiliki celah tersebut.
Apakah kita harus menghubungkan semua produk sekaligus?
Tidak. Mulailah dengan produk-produk yang terlebih dahulu memerlukan data dasar, serta dengan sistem sumber - skema netral ini dapat menangani katalog parsial maupun katalog lengkap, dan proses impor dapat diulang, sehingga proses yang dijalankan kemudian akan memperbarui inventaris. Hal ini juga membuat lokakarya pemetaan tetap cukup ringkas sehingga dapat diselesaikan dalam dua hari. Perluasan setelahnya merupakan tugas pemetaan, bukan proyek baru.
