Menyatukan Data IoT dengan ERP: Pola Integrasi yang Berhasil

Setelah platform IoT berjalan beberapa bulan, keluhan yang muncul hampir selalu sama: "datanya bagus, tapi kami masih mengetik ulang ke sistem produksi." Operator membaca dashboard IoT di satu layar, lalu memasukkan angka yang sama ke ERP di layar lain. Dua sumber kebenaran, dua kesempatan salah ketik, dan laporan bulanan yang tidak pernah benar-benar cocok.

Integrasi menghapus pekerjaan itu. Tetapi integrasi yang dirancang asal juga menjadi beban pemeliharaan yang tidak pernah selesai. Perbedaannya terletak pada beberapa keputusan di awal.

Tentukan dulu arah datanya

Sebelum bicara teknis, jawab satu hal: siapa memberi tahu siapa? Tiga arah yang berbeda sepenuhnya:

• IoT → ERP. Paling umum. Konsumsi energi, jam operasi mesin, dan hasil produksi mengalir ke modul biaya atau pemeliharaan.
• ERP → IoT. Jadwal produksi, nomor batch, dan target shift masuk ke platform agar data sensor punya konteks. Tanpa ini, grafik hanya menunjukkan "konsumsi naik" tanpa bisa menjelaskan bahwa yang berjalan memang produk berbeda.
• Dua arah. Paling bermanfaat, dan paling perlu kehati-hatian — terutama soal sistem mana yang menang bila terjadi perbedaan.

Sebagian besar kekacauan integrasi bermula dari melewatkan pertanyaan terakhir itu.

Jangan kirim data mentah ke ERP

Godaan pertama adalah mengalirkan semua pembacaan sensor ke ERP. Ini keliru karena dua alasan. ERP tidak dirancang untuk deret waktu beresolusi detik, dan tidak ada proses bisnis yang membutuhkannya.

Yang dibutuhkan ERP adalah angka yang sudah bermakna: total kWh per perintah kerja, jam operasi mesin per shift, jumlah unit selesai, atau suhu rata-rata selama satu batch. Agregasi dilakukan di platform IoT, dan hanya hasilnya yang dikirim. Volume datanya turun drastis, dan angka yang masuk sudah bisa langsung dipakai.

Dua pola pengiriman

Tarik berkala lewat OpenAPI. ERP atau lapisan integrasi memanggil API platform pada jadwal tertentu — misalnya tiap akhir shift — meminta rekap periode tersebut. Ini pola paling sederhana dan paling mudah didiagnosis: bila ada yang salah, panggilan bisa diulang. Cocok untuk hampir semua kebutuhan pelaporan.

Dorong berbasis kejadian lewat MQTT. Platform mengirim pesan begitu sesuatu terjadi — batch selesai, alarm menyala, ambang terlampaui. Latensinya rendah dan tidak ada penarikan sia-sia. Konsekuensinya, sistem penerima harus tahan menerima pesan yang sama dua kali; jaringan yang terputus dan tersambung kembali akan mengirim ulang.

Aturan praktisnya: gunakan tarik berkala untuk rekap dan pelaporan, gunakan dorong berbasis kejadian untuk hal yang menuntut reaksi cepat.

Empat hal yang menentukan integrasi bertahan atau tidak

• Identitas yang konsisten. Mesin yang sama harus punya pengenal yang sama di kedua sistem. Kalau di ERP bernama "MC-014" dan di platform "Mesin Injeksi 3", buat tabel pemetaan sejak awal — bukan setelah tiga bulan.
• Zona waktu yang eksplisit. Simpan waktu dalam UTC dan tampilkan dalam WIB. Selisih tujuh jam pada laporan akhir bulan adalah kesalahan yang mahal untuk ditelusuri.
• Tahan pengulangan. Setiap pesan perlu pengenal unik agar penerima dapat mengabaikan duplikat. Ini yang membedakan integrasi yang bisa dibiarkan berjalan dengan yang harus diawasi terus.
• Perilaku saat gagal. Bila ERP mati dua jam, apa yang terjadi pada data yang seharusnya terkirim? Jawaban yang benar adalah antre lalu dikirim ulang, bukan hilang diam-diam.

Keamanan jalur integrasi

Setiap jalur integrasi adalah pintu baru ke sistem inti perusahaan, dan pintu itu sering dibuat sekali lalu dilupakan. Empat hal yang perlu dipastikan sejak awal:

• Kredensial terpisah per integrasi. Jangan memakai akun administrator yang sama dengan yang dipakai manusia. Bila satu kunci bocor, cakupan dampaknya harus bisa dibatasi tanpa mengganggu yang lain.
• Hak akses seminimal mungkin. Integrasi pelaporan hanya perlu izin baca. Memberi izin tulis "supaya nanti tidak repot" adalah risiko yang tidak perlu.
• Kunci yang bisa diganti. Pastikan kredensial dapat dirotasi tanpa mematikan integrasi. Sistem yang mengharuskan pemasangan ulang saat kunci diganti pada praktiknya tidak akan pernah diganti.
• Pencatatan panggilan. Siapa memanggil apa dan kapan. Tanpa catatan ini, menelusuri sumber angka yang salah di ERP bisa memakan waktu berhari-hari.

Mulai dari satu angka, bukan seluruh sistem

Integrasi yang dimulai dengan pemetaan seluruh modul hampir selalu tertunda berbulan-bulan. Cara yang lebih berhasil adalah memilih satu angka yang jelas nilainya — misalnya kWh per perintah kerja — lalu mengalirkannya sampai benar-benar dipakai dalam keputusan. Setelah satu jalur itu terbukti stabil selama sebulan, jalur berikutnya jauh lebih cepat karena pola, otentikasi, dan penanganan galatnya sudah ada.

Cara INCLUDE menanganinya

IncludeApps menyediakan HTTP OpenAPI dan MQTT sebagai jalur keluar-masuk data, sehingga sistem lain dapat menarik rekap maupun menerima kejadian tanpa perlu akses langsung ke basis data. Data mentah tetap tinggal di platform; yang menyeberang ke ERP hanya angka yang sudah teragregasi.

Bila ERP Anda berupa sistem lama tanpa API yang layak — kondisi yang sangat umum — lapisan penghubungnya perlu dibangun. Praktik Software Development dan System Integrator di layanan INCLUDE menangani pekerjaan ini, termasuk pemetaan identitas aset dan penanganan galat yang sering tidak masuk lingkup proyek awal. Untuk memahami posisi lapisan aplikasi dalam arsitektur keseluruhan, lihat panduan platform IoT & AIoT di Indonesia.