Membangun MES sendiri atau membeli? Cara menghitung biaya yang sebenarnya

Kenapa membangun sendiri hampir selalu terlihat lebih masuk akal

Argumen untuk membangun MES secara internal memang terdengar meyakinkan.

Tidak ada yang lebih memahami proses produksi selain tim Anda sendiri. Anda memiliki engineer yang memahami operasional pabrik. Biaya lisensi dari vendor terlihat jauh lebih mahal dibandingkan biaya beberapa orang developer. Sementara itu, hampir setiap demonstrasi produk selalu menyisakan satu kesan yang sama: ada bagian yang terasa tidak benar-benar sesuai.

Pada tahap awal, asumsi tersebut sering kali terbukti.

Dalam beberapa bulan, production order sudah berjalan. Operator sudah memiliki antarmuka. Dashboard sudah menampilkan data. Sistem terasa lebih cocok karena memang dibangun berdasarkan kebutuhan yang sangat spesifik.

Di sinilah banyak perusahaan mulai yakin bahwa keputusan untuk membangun sendiri sudah tepat.

Masalahnya, bagian MES yang paling mudah dilihat justru merupakan bagian yang paling kecil.

Layar, formulir, dan alur kerja hanyalah lapisan terluar. Sebagian besar kompleksitas MES justru muncul setelah implementasi awal selesai, ketika sistem mulai digunakan dalam skala yang lebih besar dan kebutuhan baru mulai bermunculan.

Kompleksitas yang baru muncul setelah sistem berjalan

Kebutuhan	Kenapa lebih sulit daripada yang terlihat
Genealogy	Menelusuri hubungan material melewati split, merge, rework, dan konsumsi parsial membutuhkan model data yang kompleks
Penjadwalan kapasitas terbatas	Penjadwalan produksi melibatkan changeover, kalender, ketergantungan, dan keterbatasan resource
Audit trail	Tidak cukup hanya menyimpan log. Setiap perubahan harus dapat ditelusuri dan tidak dapat dimanipulasi
Konektivitas protokol	Integrasi dengan OPC UA, MQTT, dan Modbus membutuhkan penanganan kualitas data, reconnect, dan sinkronisasi
Konkurensi	Sistem harus mampu menangani banyak pengguna yang mengakses resource yang sama secara bersamaan
Masa simpan	Catatan produksi harus tetap dapat diakses dan diverifikasi selama bertahun-tahun
Perilaku offline	Sistem harus mampu beroperasi ketika koneksi jaringan terganggu dan melakukan sinkronisasi setelah koneksi kembali tersedia

Tidak ada satu pun kebutuhan di dalam daftar tersebut yang dapat dianggap sebagai fitur tambahan.

Semuanya merupakan kemampuan dasar yang diharapkan dari sebuah MES.

Masalahnya, hampir seluruh kebutuhan tersebut baru terlihat setelah implementasi tahap pertama selesai.

Tiga biaya yang paling sering diabaikan

Pemeliharaan tidak pernah berhenti

MES bukan aplikasi yang selesai setelah implementasi.

Perubahan proses, pembaruan infrastruktur, penambahan equipment, serta perubahan kebutuhan bisnis akan terus terjadi.

Karena itu, pemeliharaan menjadi pekerjaan yang berlangsung tanpa batas waktu.

Sebagai acuan, banyak organisasi menggunakan angka 15 sampai 25% dari biaya pengembangan sebagai biaya pemeliharaan tahunan.

Dalam tiga tahun, biaya pemeliharaan saja dapat mendekati biaya pembangunan awal.

Ada biaya kesempatan yang tidak terlihat

Setiap engineer yang membangun MES tidak sedang mengerjakan proyek lain.

Bagi sebagian besar perusahaan manufaktur, MES bukan produk yang menghasilkan keunggulan kompetitif secara langsung.

MES merupakan infrastruktur yang mendukung operasional.

Pertanyaannya bukan apakah perusahaan mampu membangunnya.

Pertanyaannya adalah apakah membangun MES merupakan penggunaan terbaik untuk sumber daya yang dimiliki.

Risiko terbesar adalah hilangnya pengetahuan

Sistem yang dibangun secara internal sering kali bergantung pada sejumlah kecil orang.

Ketika mereka berpindah pekerjaan, pengetahuan yang dimiliki ikut berpindah.

Yang hilang bukan hanya kemampuan menulis kode, tetapi juga pemahaman tentang alasan di balik setiap aturan bisnis yang diterapkan.

Inilah alasan mengapa banyak sistem internal akhirnya digantikan oleh solusi komersial, sering kali dalam situasi yang jauh lebih mendesak daripada yang direncanakan.

Kapan membangun sendiri memang menjadi pilihan yang tepat?

Membangun sendiri lebih sering menjadi keputusan yang tepat daripada yang diakui banyak vendor.

Namun, ada beberapa syarat yang harus terpenuhi.

• Proses produksi Anda benar-benar berbeda dan menjadi keunggulan bisnis.
• Ruang lingkup proyek dijaga tetap kecil dan terdefinisi dengan jelas.
• Anda memiliki tim software jangka panjang, bukan sekadar tim proyek.
• Beban regulasi relatif ringan.

Semakin tinggi kebutuhan traceability, validasi, audit trail, dan kepatuhan, semakin besar pula kompleksitas yang harus ditanggung.

Strategi yang paling sering berhasil: pendekatan hibrida

Dalam praktiknya, pendekatan yang paling konsisten menghasilkan implementasi yang berhasil adalah model hibrida.

Gunakan platform yang sudah matang untuk kemampuan yang bersifat umum, seperti:

• Eksekusi produksi.
• Traceability.
• Penjadwalan.
• Konektivitas equipment.
• Audit trail.

Kemudian, bangun lapisan yang benar-benar membedakan proses bisnis Anda di atas platform tersebut.

Pendekatan ini memungkinkan perusahaan memanfaatkan kemampuan yang sudah terbukti tanpa kehilangan fleksibilitas.

Namun, strategi ini hanya berhasil jika platform yang dipilih memang dirancang untuk dapat dikonfigurasi dan diperluas.

Cara membandingkan biaya secara lebih realistis

Jika Anda sedang mempertimbangkan untuk membangun atau membeli MES, lakukan satu latihan sederhana.

1. Tuliskan seluruh kebutuhan yang sudah diketahui.
2. Masukkan traceability, audit trail, penjadwalan, dan konektivitas secara eksplisit.
3. Tambahkan 40% untuk kebutuhan yang belum teridentifikasi.
4. Tambahkan biaya pemeliharaan selama tiga tahun.
5. Bandingkan dengan biaya lisensi, implementasi, dan dukungan dalam periode yang sama.
6. Tanyakan apa yang akan terjadi jika orang-orang yang membangun sistem tersebut tidak lagi berada di perusahaan.

Pertanyaan terakhir sering kali lebih menentukan daripada perhitungan biayanya sendiri.

Posisi VECHR MES

VECHR MES dikembangkan berdasarkan pengalaman menghadapi dua tantangan yang berlawanan: platform yang terlalu kaku untuk dikustomisasi dan sistem internal yang semakin sulit dipelihara seiring waktu.

Karena itu, platform dirancang agar konfigurasi dapat dilakukan langsung oleh pabrik.

Specification, routing, dan aturan quality dapat diubah melalui visual designer. Process Orchestrator menyediakan lebih dari 50 jenis node untuk membangun alur kerja, sementara plugin SDK berbasis TypeScript memungkinkan perusahaan menambahkan logika yang benar-benar spesifik.

Pendekatannya sederhana.

Gunakan platform untuk kemampuan yang bersifat umum.

Bangun hanya bagian yang benar-benar membedakan bisnis Anda.

Kemampuan seperti genealogy dua arah, penjadwalan kapasitas terbatas, audit trail yang tidak dapat dimanipulasi, serta konektivitas OPC UA, MQTT, dan Modbus merupakan fondasi yang sebaiknya tidak perlu dibangun ulang oleh setiap perusahaan.