Proof of Concept IoT: Uji Coba yang Berujung Keputusan

Sensor sudah terpasang, dashboard menyala, dan minggu pertama semua orang antusias. Tiga bulan kemudian proyeknya masih berstatus "uji coba". Tidak ada yang bisa mengatakan berhasil atau gagal, karena sejak awal tidak ada yang menetapkan apa arti berhasil. Anggaran perluasan tidak pernah diajukan, dan tim lapangan pelan-pelan berhenti membuka dashboard.

Proof of concept IoT (POC) yang baik bukan demo teknologi. POC adalah eksperimen kecil yang dirancang untuk menjawab satu pertanyaan bisnis dan berakhir dengan keputusan: lanjut, ubah, atau berhenti. Artikel ini membahas cara merancangnya, dari memilih masalah sampai menulis keputusan di akhir.

Kenapa proof of concept IoT sering berhenti tanpa keputusan

• Pertanyaannya kabur, misalnya "ingin melihat apa yang bisa dilakukan IoT".
• Kriteria sukses dibuat setelah data keluar, sehingga hasil apa pun bisa ditafsirkan sesuai selera.
• Tidak ada pembanding. Tanpa angka sebelum POC, perbaikan tidak bisa dibuktikan.
• Tidak ada pemilik di sisi operasional. Hanya tim IT atau vendor yang peduli pada hasilnya.
• Tidak ada tanggal selesai dan tidak ada yang menyiapkan langkah berikutnya.
• Lokasinya terlalu istimewa. Vendor merawat titik uji setiap hari, sehingga hasilnya tidak mewakili kondisi normal.

POC, pilot, dan rollout menjawab pertanyaan berbeda

Tahap	Pertanyaan yang dijawab	Skala umum
Proof of concept	Apakah data bisa didapat dengan andal, dan apakah data itu menjawab masalahnya?	Satu mesin atau beberapa titik
Pilot	Apakah tim memakainya dalam kerja sehari-hari, dan apakah hasil bisnisnya terlihat?	Satu lini atau satu area
Rollout	Bagaimana memperluasnya dengan biaya dan dukungan yang wajar?	Banyak lini atau lokasi

Banyak pabrik menggabungkan POC dan pilot. Itu wajar, asalkan kedua pertanyaannya tertulis dan dijawab terpisah.

Mulai dari satu masalah yang biayanya sudah terlihat

Pilih masalah yang sudah memakan biaya dan tercatat di suatu tempat: jam henti satu mesin kritis, biaya kelebihan kVArh di tagihan, suhu ruang dingin yang sering melewati batas, atau kompresor yang tetap menyala di malam hari. Tuliskan sebagai satu kalimat hipotesis:

"Bila arus dan suhu motor pompa transfer di lini 2 dipantau dengan alarm, tim maintenance bisa menangani gejala sebelum pompa berhenti, sehingga jam henti tak terencana di lini itu turun."

Hindari dua jebakan. Pertama, masalah yang terlalu jarang terjadi, sehingga mungkin tidak muncul sama sekali selama POC. Kedua, masalah yang solusinya menuntut perubahan besar di luar jangkauan POC. Komponen biaya POC seperti ini, dari titik ukur dan pemasangan sampai langganan, dibahas di artikel biaya implementasi IoT pabrik.

Tetapkan kriteria sukses sebelum sensor dipasang

Kriteria yang baik mencakup tiga lapis: teknis, pemakaian, dan bisnis. Tabel berikut hanya contoh; angkanya perlu disesuaikan dengan masalah Anda.

Lapis	Contoh kriteria	Cara mengukur
Teknis	Minimal 98% data terkirim sesuai jadwal; selisih dengan alat ukur pembanding di bawah 2%	Riwayat data di platform, pengukuran pembanding
Pemakaian	Setiap alarm kritis ditanggapi dalam 30 menit	Catatan alarm dan konfirmasinya
Bisnis	Jam henti tak terencana pompa turun dibanding tiga bulan sebelumnya	Catatan maintenance

Lengkapi dengan aturan keputusan yang disepakati sponsor sebelum mulai, misalnya: lanjut ke pilot bila ketiga lapis tercapai; ulangi dengan perbaikan bila teknis tercapai tetapi pemakaian belum; hentikan bila data tidak bisa didapat dengan andal di lokasi ini. Pastikan juga ada angka pembanding. Bila catatan lama tidak ada, jadikan satu sampai dua minggu pertama sebagai masa pengamatan sebelum alarm dipakai untuk bertindak.

Berapa lama POC sebaiknya berjalan

Tetapkan tanggal selesai sejak awal. Durasinya ditentukan oleh siklus masalah, bukan oleh angka bulat. POC harus mencakup beberapa kali kejadian yang ingin dideteksi, ditambah variasi operasi normal seperti pergantian shift, hari libur, dan produk yang berbeda.

Masalah yang muncul setiap minggu bisa dibuktikan dalam beberapa minggu. Kejadian yang hanya terjadi sekali dalam beberapa bulan sulit dibuktikan lewat POC; pilih indikator yang lebih sering muncul, atau gunakan data historis sebagai pembanding. Jangan hitung hari-hari pertama saat perangkat baru dipasang dan tim masih menyesuaikan diri. Perpanjangan boleh, asalkan alasannya tertulis dan ada pertanyaan baru yang mau dijawab.

Siapa yang perlu terlibat

Peran	Tanggung jawab dalam POC
Sponsor (manajer pabrik atau operasional)	Menyetujui kriteria, mengambil keputusan di akhir, menyiapkan anggaran langkah berikutnya
Pemilik proses (kepala produksi atau maintenance)	Menentukan masalah dan memastikan alarm ditindaklanjuti
Operator dan teknisi	Memakai sistem setiap hari dan memberi masukan
Tim IT dan OT	Jaringan, keamanan, dan akses ke PLC
Mitra teknologi	Perangkat, platform, pemasangan, dan laporan hasil

Satu orang di sisi pabrik harus menjadi penanggung jawab. Libatkan operator sejak hari pertama, karena merekalah yang menentukan apakah alarm benar-benar ditindaklanjuti. Pendekatannya dibahas di artikel pelatihan operator sebagai kunci adopsi IoT.

Setelah POC: tiga kemungkinan keputusan

• Lanjut. Susun rencana pilot atau perluasan dari angka POC: jumlah titik, biaya per titik, waktu pemasangan, dan siapa yang merawat. Di tahap ini juga diputuskan arsitekturnya, termasuk apakah akan membangun sistem IoT sendiri atau memakai platform.
• Ubah dan ulangi. Bila data andal tetapi tim belum memakainya, yang perlu diubah biasanya ambang alarm, tampilan, atau pelatihan, bukan perangkatnya.
• Berhenti. Data tidak andal, atau masalahnya ternyata tidak sebesar dugaan. Hasil ini tetap bernilai karena mencegah investasi besar ke arah yang salah.

Tutup POC dengan laporan satu sampai dua halaman: pertanyaan, kriteria, hasil dibanding target, keputusan, biaya, dan langkah berikutnya. Laporan inilah yang dibawa ke rapat anggaran.

Yang perlu diperhatikan

• Pilih lokasi yang mewakili, bukan yang paling mudah atau paling bermasalah.
• Pastikan data bisa dibawa keluar lewat ekspor atau API, supaya hasil POC tidak terkunci di satu sistem.
• Libatkan tim IT sejak awal untuk persetujuan jaringan dan keamanan. Persetujuan yang terlambat sering menunda POC berminggu-minggu.
• Pisahkan biaya POC dan biaya rollout. Biaya per titik saat uji coba belum tentu sama dengan biaya pada skala besar.

Pertanyaan yang sering diajukan

Apa bedanya POC dengan demo vendor?

Demo menunjukkan fitur dengan data contoh. POC memakai mesin, data, dan masalah pabrik Anda sendiri, dengan kriteria sukses yang Anda tetapkan.

Berapa titik ukur yang ideal untuk POC?

Secukupnya untuk menjawab pertanyaan, sering hanya satu mesin atau beberapa titik. Titik yang terlalu banyak membuat POC berubah menjadi rollout kecil yang sulit dievaluasi.

Apakah POC IoT harus berbayar?

Tidak selalu. Paket Community INCLUDE gratis tanpa batas waktu untuk 3 perangkat dan 2 pengguna, cukup untuk menguji satu titik. Perhatikan masa simpan datanya: untuk membandingkan data beberapa minggu, pilih paket dengan retensi lebih panjang.

Bagaimana bila hanya sebagian kriteria tercapai?

Aturan keputusan yang disepakati di awal menjawabnya. Bila kasusnya tidak tercakup, sponsor memutuskan berdasarkan data, dengan tenggat yang jelas, bukan dengan memperpanjang POC tanpa batas.

Proof of concept IoT bersama INCLUDE

Lewat jasa konsultasi transformasi digital industri, tim INCLUDE memetakan kondisi operasional Anda, mengurutkan peluang dari yang paling cepat memberi hasil dibanding biayanya, lalu menguji peluang teratas di satu titik sebelum diperluas. Hasil akhirnya roadmap bertahap dengan target terukur di tiap fase, siap dibawa ke manajemen.

Untuk sisi teknis, data POC bisa datang dari sensor IncludeBox, perangkat Modbus RTU lewat IncludeGateways, atau perangkat Anda sendiri lewat MQTT dan HTTP. Alarm bisa diteruskan ke email atau Telegram sesuai paket. Harga semua paket, termasuk kuota perangkat dan retensi data, tercantum terbuka di halaman harga.