Ada satu percakapan yang hampir selalu berulang ketika saya berbicara dengan manajer pabrik yang sudah memasang sensor IoT tapi belum mendapatkan nilai yang dijanjikan.
"Datanya ada. Banyak malah. Tapi kami tidak tahu harus diapakan."
Ini bukan keluhan tentang kekurangan data. Ini keluhan tentang kekurangan fondasi — cara data dikumpulkan, diorganisir, dibersihkan, dan disambungkan ke pertanyaan bisnis yang nyata.
Di artikel sebelumnya, saya sudah menulis tentang mengapa data adalah pondasi dari semua sistem AI — bahwa AI hanya secerdas data yang diterimanya — dan tentang hasil akhirnya: bagaimana AI bekerja dalam operasional industri nyata untuk mengubah data menjadi keputusan. Tapi ada lapisan penting di antaranya yang belum pernah saya bahas secara langsung: bagaimana membangun fondasi data itu sendiri, dari nol, dengan benar.
Artikel ini adalah tentang lapisan tengah itu.
Mengapa Fondasi Data Hampir Selalu "Hampir Siap"
Jika Anda pernah terlibat dalam proyek AI atau IoT di lingkungan industri, Anda mungkin familiar dengan satu fenomena: data yang selalu tampak hampir siap, tapi tidak pernah benar-benar siap ketika dibutuhkan.
Sensor sudah terpasang. Data sudah mengalir. Dashboard sudah ada. Tapi ketika tim data science atau vendor AI mulai bekerja, yang mereka temukan adalah:
- Sensor yang merekam data tapi tidak ada label konteks — tidak jelas apakah mesin sedang berjalan normal, dalam maintenance, atau dalam kondisi fault
- Timestamp yang tidak konsisten antar perangkat karena sinkronisasi waktu tidak dikonfigurasi dengan benar
- Data yang missing di periode tertentu tanpa penjelasan — mesin mati? Koneksi putus? Tidak ada yang tahu
- Format yang berbeda-beda dari perangkat berbeda yang tidak pernah distandarisasi
- Data yang tersimpan di silo departemen yang berbeda dan tidak pernah bisa disilangkan
Ini bukan kegagalan teknologi. Ini kegagalan arsitektur — cara data dirancang untuk mengalir dari titik pengumpulan ke titik penggunaan.
Gartner melaporkan bahwa data scientists menghabiskan 60–80% waktunya untuk cleaning dan preparing data, bukan untuk membangun model. Di lingkungan industri yang lebih kompleks, angka ini bisa lebih tinggi. Artinya: investasi terbesar dalam proyek AI bukan pada algoritma yang canggih, tapi pada fondasi data yang disiplin.
Lima Lapisan Arsitektur Data yang Perlu Dipahami
Membangun fondasi data untuk industri bukan tentang memilih software yang tepat. Ini tentang memahami bahwa ada lima lapisan berbeda dengan tanggung jawab yang berbeda — dan kegagalan di satu lapisan akan merusak semua lapisan di atasnya.
Lapisan 1 — Akuisisi: Sensor dan Sumber Data
Ini adalah titik paling awal — di mana data lahir.
Sensor tekanan, sensor suhu, arus listrik, getaran, kamera visual, barcode scanner, PLC, SCADA — semuanya adalah sumber data. Dan di lapisan ini, ada tiga keputusan yang akan berdampak pada seluruh arsitektur:
Sampling rate: Seberapa sering data direkam? Ini bukan pertanyaan teknis semata — ini pertanyaan tentang use case. Untuk predictive maintenance pada mesin berputar cepat, Anda mungkin butuh data getaran pada 1.000 Hz atau lebih tinggi. Untuk monitoring konsumsi energi harian, data per 15 menit sudah lebih dari cukup. Sampling rate yang terlalu rendah melewatkan sinyal kritis. Sampling rate yang terlalu tinggi menciptakan volume data yang tidak perlu dan mahal untuk disimpan.
Protokol komunikasi: OPC-UA, MQTT, Modbus, PROFIBUS — masing-masing punya karakteristik yang berbeda. Standar terbuka seperti OPC-UA dan MQTT memberikan fleksibilitas integrasi jangka panjang. Protokol proprietary yang dikunci oleh vendor tertentu menciptakan dependensi yang mahal ketika Anda perlu bermigrasi atau menambahkan sistem baru.
Konteks dan metadata: Ini yang paling sering terlewat. Data mentah dari sensor tidak ada artinya tanpa konteks — nama mesin, lokasi, shift produksi, produk yang sedang dibuat, status operasional. Metadata ini harus direncanakan dan dikonfigurasi sejak sensor dipasang, bukan ditambahkan belakangan.
Lapisan 2 — Edge: Pemrosesan Lokal
Lapisan ini adalah yang paling sering dilewati, tapi justru salah satu yang paling kritis.
Edge processing adalah pemrosesan data yang terjadi di dekat sumber data — di gateway, di server mini di lantai produksi — sebelum data dikirim ke cloud atau data center pusat.
Mengapa ini penting? Ada tiga alasan yang sangat praktis:
Ketahanan operasional: Jika koneksi internet terputus, mesin harus tetap bisa beroperasi dan data tetap tersimpan. Edge computing memastikan operasional tidak bergantung pada ketersediaan cloud.
Efisiensi biaya dan bandwidth: Tidak semua data mentah perlu dikirim ke cloud. Filter di lapisan edge bisa mengidentifikasi mana yang anomali (perlu dikirim segera) dan mana yang normal (bisa diagregasi dulu sebelum dikirim). Ini bisa mengurangi volume data yang dikirim — dan biaya bandwidth — secara dramatis.
Latensi respons: Beberapa keputusan perlu dibuat dalam milidetik — misalnya menghentikan mesin ketika sensor mendeteksi kondisi berbahaya. Keputusan seperti ini tidak bisa menunggu round-trip ke cloud dan kembali.
Lapisan 3 — Pipeline dan Penyimpanan
Di sini data mulai "hidup" dalam sistem yang lebih terstruktur.
Ada dua pilihan arsitektur penyimpanan yang perlu dipahami:
Time-series database (InfluxDB, TimescaleDB, AWS Timestream) dirancang khusus untuk data yang punya dimensi waktu — seperti hampir semua data sensor industri. Query seperti "tunjukkan tren suhu bearing di mesin A selama 30 hari terakhir" jauh lebih efisien di time-series database dibanding database relasional biasa.
Data lake atau data warehouse diperlukan ketika Anda perlu menggabungkan data sensor dengan data bisnis lain — data produksi dari ERP, data kualitas dari sistem QC, data maintenance dari CMMS. Integrasi lintas sistem ini adalah yang membuka nilai analitik yang sesungguhnya.
Yang tidak boleh dilupakan di lapisan ini: retention policy — seberapa lama data disimpan, dalam granularitas apa, dan di tier storage yang mana. Data sensor raw dengan frekuensi tinggi mungkin hanya perlu disimpan 30–90 hari. Data yang sudah diagregasi per jam bisa disimpan lebih lama. Data agregasi harian bisa disimpan bertahun-tahun. Tanpa kebijakan ini, biaya storage akan membengkak tanpa nilai yang sepadan.
Lapisan 4 — Kualitas dan Tata Kelola Data
Ini lapisan yang paling tidak terlihat, tapi yang paling menentukan apakah AI yang dibangun di atasnya bisa dipercaya.
Data labeling: Model machine learning yang supervised butuh data berlabel — contoh kondisi normal, contoh anomali, contoh berbagai jenis fault. Ini pekerjaan yang membutuhkan expertise domain: siapa di organisasi Anda yang bisa memberi label "ini adalah tanda awal bearing yang akan gagal" pada data getaran? Rencana untuk ini harus ada sejak awal.
Anomaly handling: Bagaimana sistem menangani data yang hilang (missing values)? Bagaimana menangani bacaan yang jelas tidak masuk akal — sensor yang melaporkan suhu 500°C padahal batas operasionalnya 150°C? Keputusan ini harus didokumentasikan dan konsisten, karena pilihan yang berbeda akan menghasilkan model yang berbeda.
Data lineage: Bisa menjawab pertanyaan "dari mana data ini berasal dan sudah diproses apa saja?" adalah fondasi dari kepercayaan terhadap output AI. Ketika model AI menghasilkan prediksi yang mengejutkan, Anda perlu bisa menelusuri kembali ke sumber data untuk memvalidasi apakah prediksinya masuk akal atau ada masalah di datanya.
Lapisan 5 — Analitik dan Model
Lapisan inilah yang paling sering dibicarakan — dashboard, model prediktif, AI. Tapi ini adalah lapisan yang hasilnya sepenuhnya ditentukan oleh kualitas empat lapisan di bawahnya.
Model predictive maintenance yang akurat, deteksi anomali yang bisa dipercaya, optimasi proses yang memberikan rekomendasi nyata — semua ini bisa dibangun jika dan hanya jika lapisan 1 sampai 4 sudah solid.
Yang perlu dipahami: lapisan ini juga yang paling cepat berubah dan berkembang. Model yang Anda bangun hari ini mungkin akan digantikan oleh pendekatan yang lebih baik dalam satu atau dua tahun. Investasi yang tidak terdepresiasi adalah pada lapisan data di bawahnya — fondasi yang solid akan bisa melayani banyak generasi model.
Lima Kesalahan yang Membuat Fondasi Data Jadi Beban
Setelah memahami arsitekturnya, ini adalah pola kegagalan yang paling konsisten saya lihat di lapangan.
Kesalahan 1: Mengumpulkan Segalanya, Tidak Menandai Apapun
"Kita rekam semua data dulu, nanti kita analisa" adalah kalimat yang terdengar prudent tapi sebenarnya berbahaya.
Data tanpa konteks adalah noise, bukan aset. Sensor yang merekam getaran tanpa informasi apakah mesin sedang dalam kondisi warm-up, full load, atau idle menghasilkan data yang sulit diinterpretasi. Semakin banyak data tanpa konteks, semakin besar pekerjaan yang dibutuhkan untuk memberikan makna padanya — dan semakin tinggi biaya storage yang tidak memberikan value.
Prinsipnya: definisikan pertanyaan bisnis yang ingin dijawab sebelum memutuskan data apa yang dikumpulkan.
Kesalahan 2: Sampling Rate yang Tidak Sesuai Use Case
Ini adalah keputusan teknis yang sering diambil secara default, padahal seharusnya didrive oleh kebutuhan.
Terlalu lambat: sensor getaran yang merekam data setiap 10 menit tidak akan pernah bisa mendeteksi bearing failure yang gejalanya muncul dalam hitungan detik. Terlalu cepat: sensor level tangki yang merekam setiap 100ms menghasilkan data yang 99% redundan dan membuang bandwidth serta storage.
Aturan praktis: buat mapping antara setiap use case yang ingin diselesaikan dengan sampling rate minimum yang dibutuhkan untuk mendeteksi sinyal yang relevan. Jadikan ini dokumen yang bisa direvisi ketika use case berkembang.
Kesalahan 3: Data Silo Antar Departemen
Data maintenance tersimpan di sistem CMMS yang tidak berbicara dengan data produksi di MES yang tidak berbicara dengan data kualitas di sistem QC. Masing-masing departemen punya "kebenaran" datanya sendiri — dan tidak ada yang bisa melihat gambaran lengkapnya.
Ini adalah situasi yang sangat umum di industri Indonesia — dan yang paling menghambat nilai analitik. Karena pertanyaan paling berharga hampir selalu lintas departemen: apakah ada korelasi antara jadwal maintenance dan cacat produksi? Apakah konsumsi energi yang tinggi berkorelasi dengan kualitas produk yang rendah?
Solusinya bukan satu sistem besar yang menggantikan semua sistem. Solusinya adalah lapisan integrasi — data mesh atau data lake — yang memungkinkan data dari berbagai sumber digabungkan untuk analisis, tanpa harus mengganti sistem operasional yang sudah berjalan.
Kesalahan 4: Tidak Ada Kepemilikan Data yang Jelas
Siapa yang bertanggung jawab jika data sensor tertentu berhenti mengalir? Siapa yang berwenang menambahkan sensor baru ke pipeline? Siapa yang memutuskan berapa lama data disimpan?
Tanpa jawaban yang jelas untuk pertanyaan-pertanyaan ini, fondasi data akan membusuk secara perlahan. Sensor yang mati tidak diganti karena tidak ada yang merasa bertanggung jawab. Definisi yang ambigu — apakah "downtime" termasuk scheduled maintenance? — menghasilkan laporan yang berbeda-beda tergantung siapa yang ditanya.
Data governance tidak harus rumit. Yang dibutuhkan adalah: satu orang atau tim yang accountable untuk setiap data domain yang kritis, definisi yang didokumentasikan untuk metrik bisnis kunci, dan proses yang jelas untuk menangani perubahan.
Kesalahan 5: Melewati Edge Layer karena Terlihat Rumit
Banyak implementasi yang langsung mengirim semua data mentah ke cloud untuk diproses di sana — karena terlihat lebih sederhana dan lebih murah di awal. Hasilnya adalah sistem yang sepenuhnya bergantung pada konektivitas internet yang stabil (tidak realistis di banyak lokasi industri Indonesia), biaya cloud yang membengkak seiring volume data bertambah, dan latensi yang membuat use case real-time tidak mungkin.
Edge layer memang menambah kompleksitas, tapi ia memberikan ketahanan dan efisiensi yang tidak bisa didapat dari arsitektur cloud-only. Ini juga salah satu kriteria terpenting dalam memilih platform IoT industrial yang tepat untuk konteks Indonesia.
Urutan yang Benar untuk Memulai dari Nol
Jika Anda membangun fondasi data dari nol — atau mengevaluasi ulang yang sudah ada — ini adalah urutan yang paling konsisten berhasil:
Langkah 1: Mulai dari use case, bukan dari sensor.
Pilih satu atau dua pertanyaan bisnis yang paling berharga dan paling bisa diukur: "Kapan mesin A kemungkinan akan breakdown?" atau "Di titik mana dalam shift energi paling boros?" Use case ini yang menentukan data apa yang dibutuhkan, bukan sebaliknya.
Langkah 2: Definisikan "data yang berguna" sebelum "data yang bisa dikumpulkan."
Untuk setiap use case, definisikan: sinyal apa yang relevan? Pada frekuensi berapa? Dengan konteks apa? Ini akan menghasilkan daftar sensor dan konfigurasi yang jauh lebih fokus dan lebih mudah dieksekusi.
Langkah 3: Bangun satu pipeline lengkap dari ujung ke ujung sebelum expand.
Dari sensor spesifik → edge processing → storage → satu dashboard atau model yang menjawab satu pertanyaan dengan baik. Pipeline yang sederhana tapi end-to-end jauh lebih berharga dari infrastruktur besar yang tidak pernah sampai ke insight.
Langkah 4: Dokumentasikan semua keputusan arsitektur.
Mengapa sampling rate 100ms dipilih untuk sensor ini? Mengapa data ini disimpan di time-series database dan bukan di relational? Dokumentasi ini bukan birokrasi — ini yang memungkinkan sistem dirawat dan dikembangkan ketika orang-orang yang membangunnya tidak ada lagi.
Langkah 5: Rencanakan skalabilitas dari awal, tapi jangan build untuk skala yang belum ada.
Pilih arsitektur yang bisa tumbuh — standar terbuka, format data yang portabel, protokol yang tidak mengunci ke vendor tertentu. Tapi jangan over-engineer untuk volume data yang belum ada. Bangun untuk kebutuhan 6–12 bulan ke depan, bukan untuk kebutuhan hipotetis 5 tahun ke depan.
Tanda-Tanda Fondasi Data yang Sudah "Cukup Baik"
Ini adalah pertanyaan yang jarang ditanyakan — kapan fondasi data sudah siap untuk AI yang sesungguhnya?
Fondasi data yang sehat menunjukkan tanda-tanda ini:
- Tim operasional mempercayai datanya. Mereka menggunakan dashboard untuk mengambil keputusan, bukan hanya sebagai laporan untuk diarsipkan. Ketika data menunjukkan anomali, mereka investigasi — bukan langsung dismiss karena merasa datanya sering salah.
- Pertanyaan bisnis baru bisa dijawab dalam hari, bukan minggu. Ketika manajemen ingin melihat korelasi antara dua variabel yang sebelumnya belum pernah dianalisis, datanya sudah ada dan bisa diakses — tidak perlu proyek baru untuk mengumpulkannya.
- Model yang dibangun di atasnya bisa dijelaskan. Ketika AI menghasilkan prediksi atau anomali alert, tim bisa menelusuri kembali ke data mentah untuk memvalidasi apakah masuk akal. Tidak ada kotak hitam yang tidak bisa diaudit.
- Ada proses yang jelas ketika data bermasalah. Sensor mati tidak menyebabkan kepanikan — ada prosedur untuk mendeteksi, melaporkan, dan memperbaikinya. Missing data ditangani dengan cara yang konsisten dan terdokumentasi.
Penutup: Data adalah Aset, Bukan Exhaust
Ada pergeseran cara pandang yang perlu terjadi di organisasi industri Indonesia: data bukan exhaust — produk sampingan yang dihasilkan mesin ketika mereka beroperasi. Data adalah aset strategis yang harus dirancang, dirawat, dan diinvestasikan dengan serius.
Di artikel sebelumnya saya menulis bahwa AI hanya secerdas data yang diterimanya. Tapi ada satu lapisan lebih dalam dari itu: data hanya seberharga arsitektur yang merancangnya.
Perusahaan yang membangun fondasi data dengan benar hari ini — meskipun AI-nya masih sederhana — sedang membangun moat yang sangat nyata. Karena ketika model AI yang lebih canggih tersedia, ketika talent data science lebih mudah didapat, ketika biaya komputasi terus turun — mereka akan bisa menggunakannya segera. Sementara kompetitor yang memulai tanpa fondasi harus membangunnya dari nol, dengan biaya dan waktu yang jauh lebih besar.
Data yang dikumpulkan dengan benar hari ini adalah keputusan strategis dengan dampak dua hingga tiga tahun ke depan.
Jika Anda sedang mengevaluasi atau membangun fondasi data untuk fasilitas industri Anda dan ingin diskusi tentang arsitektur yang tepat untuk kondisi spesifik Anda — tim Synapsis siap untuk percakapan itu.
FAQ
Apakah kami harus membangun fondasi data sendiri atau bisa minta vendor yang handle semuanya?
Sebagian besar aspek teknis bisa dan memang wajar untuk didelegasikan ke vendor yang tepat. Tapi ada satu hal yang tidak bisa didelegasikan: pemahaman tentang pertanyaan bisnis yang ingin dijawab dan keputusan data governance yang menyertainya. Fondasi data yang sepenuhnya dirancang oleh vendor tanpa keterlibatan mendalam dari tim internal hampir selalu menghasilkan sistem yang tidak sepenuhnya sesuai dengan kebutuhan operasional.
Berapa lama membangun fondasi data yang solid?
Pipeline pertama yang end-to-end — dari sensor ke insight untuk satu use case — bisa diselesaikan dalam 6–12 minggu jika ada komitmen dan sumber daya yang tepat. Fondasi yang lengkap yang mencakup multiple use case, integrasi lintas sistem, dan data governance yang matang adalah perjalanan 12–24 bulan. Yang penting adalah ada value yang nyata di setiap tahap, bukan menunggu "sempurna" sebelum mulai memberikan hasil.
Apakah kami perlu data scientist internal untuk membangun ini?
Tidak harus, terutama di awal. Yang lebih penting adalah domain expert — orang-orang yang memahami proses operasional dan bisa mendefinisikan pertanyaan bisnis yang relevan. Data engineering dan data science bisa diakses melalui vendor atau konsultan yang tepat. Yang tidak bisa dioutsource adalah pengetahuan tentang apa yang penting di operasional Anda.
Apakah cloud wajib, atau bisa on-premise?
Keduanya valid dan tergantung pada kebutuhan spesifik. Edge-first dengan cloud untuk agregasi dan analitik jangka panjang adalah arsitektur yang paling banyak direkomendasikan untuk industri di Indonesia — memberikan ketahanan operasional dari edge sambil tetap mengakses kapasitas analitik cloud untuk use case yang tidak membutuhkan latensi rendah.