CMMS vs ERP: perbedaan, pembagian peran, dan cara integrasinya

Pengertian CMMS, ERP, dan EAM

Pertanyaan CMMS vs ERP biasanya muncul pada saat yang hampir sama di banyak pabrik: proyek ERP sedang berjalan atau baru saja selesai, lalu kepala pemeliharaan ditanya apakah timnya masih membutuhkan sistem sendiri. Jawaban yang jujur bergantung pada apa yang sebenarnya dikerjakan setiap sistem, dan istilah yang beredar sering tumpang tindih. Karena itu, definisinya perlu diluruskan lebih dulu.

EN 13306 mendefinisikan pemeliharaan sebagai gabungan tindakan teknis, administratif, dan manajerial selama siklus hidup suatu item, yang bertujuan mempertahankan atau memulihkannya ke keadaan yang mampu menjalankan fungsi yang dipersyaratkan^[1]. Definisi ini berguna untuk membaca perdebatan CMMS dan ERP. Sisi administratif dan keuangan pemeliharaan adalah wilayah alami ERP. Sisi teknis, yaitu apa yang dikerjakan pada mesin, oleh siapa, dan apa yang ditemukan, adalah wilayah alami CMMS. Keduanya menyentuh sisi manajerial dari arah yang berbeda.

CMMS

Computerized Maintenance Management System (CMMS) adalah sistem untuk merencanakan, menjalankan, dan mencatat pekerjaan pemeliharaan pada setiap aset. Fungsi dasarnya sudah dibahas dalam artikel apa itu CMMS. Untuk perbandingan ini, cukup diingat satu hal: unit kerjanya adalah work order yang terikat pada aset, dan pengguna utamanya adalah orang yang merencanakan dan mengerjakan pemeliharaan.

ERP

Enterprise Resource Planning (ERP) adalah sistem yang menyatukan proses bisnis inti perusahaan, seperti keuangan, pengadaan, persediaan, penjualan, dan produksi, dalam satu basis data. Kekuatannya terletak pada konsistensi transaksi. Setiap barang yang diterima, dikeluarkan, atau dibayar meninggalkan jejak akuntansi yang dapat diaudit, dan setiap biaya dibebankan ke struktur organisasi yang sudah disepakati.

EAM dan bedanya dengan CMMS

Enterprise Asset Management (EAM) memperluas cakupan dari pekerjaan pemeliharaan ke seluruh siklus hidup aset: perencanaan kebutuhan, pengadaan, operasi, pemeliharaan, sampai penggantian atau penghapusan. Cakupan ini sejalan dengan ISO 55000, yang memandang manajemen aset sebagai kegiatan terkoordinasi organisasi untuk mewujudkan nilai dari asetnya^[2]. Campbell, Jardine, dan McGlynn membahas manajemen aset sebagai rangkaian keputusan sepanjang umur peralatan, dan keputusan itu bergantung pada data riwayat pemeliharaan yang andal^[3].

Dalam praktik, batas antara CMMS dan EAM kabur karena banyak produk CMMS menambahkan fitur EAM dan sebaliknya. Perbedaan yang lebih berguna adalah rentang waktunya. CMMS menjawab pertanyaan harian: pekerjaan apa yang harus diselesaikan minggu ini dan apa hasilnya. EAM menjawab pertanyaan bertahun-tahun: kapan sebuah kompresor lebih ekonomis diganti daripada terus diperbaiki.

Modul pemeliharaan ERP, misalnya SAP PM

Sebagian besar ERP besar memiliki modul pemeliharaan. Contoh yang paling dikenal di Indonesia adalah SAP PM (Plant Maintenance), yang di SAP S/4HANA kini sering disebut Plant Maintenance atau Asset Management. Secara umum, modul ini menyusun aset dalam functional location (lokasi fungsional, yaitu tempat sebuah fungsi dijalankan) dan equipment (objek fisik yang terpasang di lokasi tersebut). Gangguan atau permintaan dicatat sebagai maintenance notification, lalu pekerjaan direncanakan dalam maintenance order yang memuat operasi, komponen, jam kerja, dan biaya. Biaya order kemudian dibebankan ke cost center atau objek biaya lain.

Dilihat dari daftar fungsinya, modul seperti ini sudah memuat hampir semua unsur CMMS. Karena itu, pertanyaan CMMS vs SAP PM jarang terjawab dengan membandingkan fitur. Perbedaannya lebih sering terletak pada siapa yang mengisi data, di mana data itu diisi, dan seberapa lengkap catatan teknisnya ketika pekerjaan selesai.

Untuk siapa setiap sistem dirancang

ERP dirancang di sekitar kebutuhan bagian keuangan, pengadaan, dan gudang. Layarnya padat kolom dan kode, umumnya dipakai di meja kerja, dan mengutamakan ketepatan transaksi di atas kecepatan input. Bagi seorang staf akuntansi biaya yang menutup buku setiap akhir bulan, rancangan ini masuk akal. Satu kode cost center yang salah dapat mengacaukan laporan seluruh departemen.

Pengguna pemeliharaan bekerja dengan ritme yang berbeda. Palmer menempatkan planner sebagai orang yang menyiapkan rencana kerja, suku cadang, alat, dan estimasi jam sebelum pekerjaan dijadwalkan, lalu memakai umpan balik teknisi setelah pekerjaan selesai untuk memperbaiki rencana berikutnya^[4]. Umpan balik itu harus ditangkap di tempat pekerjaan terjadi: oleh teknisi bersarung tangan berminyak di samping kompresor, sering kali di tengah shift malam.

Perbedaan ini terlihat jelas pada kejadian sehari-hari. Pukul dua dini hari, kompresor utilitas trip. Teknisi memperbaikinya, menulis catatan singkat di kertas, dan pulang. Keesokan paginya admin mengetik catatan itu ke ERP: nomor equipment, jam kerja, dan material yang dipakai. Transaksinya tercatat benar, tetapi gejala awal, temuan di lapangan, dan dugaan penyebabnya hilang di tengah jalan. Masalahnya bukan pada ERP, melainkan pada jarak antara orang yang tahu dan layar tempat data dimasukkan.

CMMS vs ERP: perbandingan dari sisi pemeliharaan

Tabel berikut membandingkan CMMS dengan modul pemeliharaan ERP pada dimensi yang biasanya menentukan apakah data pemeliharaan terisi dengan baik. Tabel ini tidak menilai mana yang lebih unggul. Setiap kolom menggambarkan titik berat rancangan yang umum, bukan kemampuan maksimal sebuah produk.

Cara paling berguna membaca tabel ini adalah melihat baris suku cadang dan akuntansi biaya. Kedua sistem menyentuh data yang sama dengan pertanyaan yang berbeda. ERP bertanya berapa nilai bearing di gudang dan ke cost center mana biayanya dibebankan. CMMS bertanya mengapa bearing pada pompa yang sama sudah tiga kali diganti tahun ini. Kedua pertanyaan itu sah, dan pabrik membutuhkan jawaban atas keduanya.

Kapan modul pemeliharaan ERP seperti SAP PM sudah cukup

Tidak setiap pabrik yang memakai ERP perlu menambah CMMS. Menambah sistem berarti menambah antarmuka yang harus dijaga, pengguna yang harus dilatih, dan satu tempat lagi di mana data bisa tidak sinkron. Modul pemeliharaan ERP biasanya sudah memadai dalam kondisi berikut.

• Pekerjaan pemeliharaan sebagian besar dialihdayakan. Jika kontraktor mengerjakan perbaikan dan pabrik terutama mengelola PO dan tagihannya, titik berat pekerjaannya memang ada di pengadaan.
• Jumlah aset kecil dan jenisnya sederhana. Planner dapat memasukkan hasil kerja sendiri tanpa kehilangan detail penting.
• Akses lapangan sudah tersedia. Perusahaan telah menyiapkan aplikasi seluler atau terminal di area produksi, dan teknisi benar-benar memakainya.
• Tata kelola menuntut satu sistem. Kebijakan grup atau auditor mewajibkan seluruh transaksi pemeliharaan berada di ERP, dan tim siap menyesuaikan cara kerjanya.

Kata "cukup" di sini harus dibuktikan dengan data, bukan dengan daftar fitur. Modul yang sudah dinyalakan belum tentu dipakai sebagaimana mestinya. Periksa beberapa ratus order pemeliharaan terakhir: apakah kode kegagalan terisi, apakah jam kerja aktual dicatat, dan apakah order ditutup dalam waktu yang wajar. Indikator seperti yang dibahas dalam artikel KPI maintenance hanya dapat dihitung jika data dasarnya lengkap.

Di mana CMMS terpisah layak dipakai

Jika uji di atas gagal, celahnya biasanya muncul di lima tempat yang sama. Semuanya berada di sisi teknis pemeliharaan, tempat ERP pada umumnya tidak dirancang untuk unggul.

Pelaksanaan di lapangan

CMMS umumnya dirancang agar teknisi dapat menerima tugas, melihat riwayat aset, memotret temuan, dan menutup work order dari ponsel di dekat mesin. Perbedaan beberapa menit dalam cara input menentukan apakah catatan diisi saat itu juga atau ditunda sampai akhir shift. Isi form work order yang baik dibahas tersendiri dalam artikel work order maintenance.

Checksheet dan inspeksi rutin

Ronda harian di ruang kompresor atau pemeriksaan mingguan panel listrik menghasilkan banyak pembacaan kecil: level oli, temperatur, bunyi, dan kebocoran. Di ERP, pekerjaan semacam ini sering hanya tercatat sebagai satu order yang selesai, tanpa nilai yang dibaca. CMMS menyimpan setiap butir checksheet sebagai data, sehingga temuan yang menyimpang dapat diteruskan menjadi work order korektif dan tren pembacaannya dapat dilihat.

Kode kegagalan yang dapat dianalisis

ISO 14224 menyusun data keandalan dan pemeliharaan dalam taksonomi peralatan bertingkat dan mencatat setiap kegagalan dengan mode kegagalan, mekanisme, penyebab, dan cara kegagalan itu terdeteksi^[5]. Struktur ini dapat dikonfigurasi di ERP maupun CMMS. Yang menentukan adalah apakah teknisi mengisinya. Kode kegagalan yang hanya dapat diisi oleh admin di kantor cenderung diisi dengan pilihan "lain-lain", dan riwayat seperti itu tidak dapat dipakai untuk analisis akar masalah.

Kepatuhan pemeliharaan preventif

Wireman menyusun indikator pemeliharaan secara berjenjang, dari tingkat korporasi dan keuangan sampai tingkat taktis dan fungsional di bagian pemeliharaan^[6]. Kepatuhan PM termasuk indikator di tingkat bawah ini: ia membutuhkan tanggal jatuh tempo dan tanggal selesai yang jujur untuk setiap tugas. Jika penutupan order bergantung pada admin yang menyalin kertas, tanggal yang tercatat adalah tanggal penyalinan, bukan tanggal pekerjaan. Cara menyusun jadwal dan intervalnya dibahas dalam artikel preventive maintenance.

Pemicu berbasis kondisi

EN 13306 membedakan pemeliharaan berbasis kondisi, yang dipicu oleh hasil pemantauan keadaan aset, dari pemeliharaan terjadwal berdasarkan interval^[1]. Agar pendekatan ini berjalan, nilai vibrasi atau temperatur yang melewati batas harus berubah menjadi work order yang ditujukan ke orang yang tepat. CMMS yang terhubung ke data kondisi umumnya menangani alur ini secara langsung, sedangkan di ERP alur yang sama sering memerlukan pengembangan tambahan.

Integrasi CMMS dengan ERP: siapa memegang data apa

Jika CMMS dan ERP dipakai bersama, prinsip pertamanya sederhana: setiap objek data hanya punya satu master (system of record). Sistem lain boleh membaca atau menyimpan salinannya, tetapi tidak boleh mengubahnya sendiri. Tanpa aturan ini, dua sistem akan pelan-pelan menyimpan dua versi kebenaran, dan rapat bulanan habis untuk menentukan angka mana yang benar.

Baris pertama dan kedua sering membingungkan. Satu aset tetap di pembukuan bisa terdiri dari puluhan item yang dipelihara. Sebuah lini pengisian, misalnya, dapat dicatat keuangan sebagai satu aset, padahal di lapangan ia terdiri dari motor, pompa, konveyor, dan panel yang masing-masing punya riwayat sendiri. Kedua daftar tidak perlu disamakan; yang perlu adalah kunci penghubung, sehingga setiap item teknis tahu ke aset tetap dan cost center mana ia termasuk.

Alurnya dimulai ketika operator melaporkan gangguan, misalnya pompa pendingin yang berbunyi kasar. Planner membuat work order di CMMS, menyusun langkah kerja, dan menentukan suku cadang yang dibutuhkan. Palmer menekankan bahwa ketersediaan suku cadang perlu dipastikan sebelum pekerjaan dijadwalkan^[4], sehingga pada tahap ini CMMS meminta reservasi stok ke ERP, atau membuat permintaan pembelian jika stok kosong. Persetujuan pembelian tetap berjalan di ERP. Setelah suku cadang siap, teknisi mengerjakan dan menutup work order di CMMS dengan jam kerja, material yang benar-benar dipakai, kode kegagalan, dan temuannya. Riwayat teknis itu tinggal di CMMS, sedangkan ringkasan biayanya diposting ke ERP.

Angka berikut adalah ilustrasi. Work order penggantian bearing pompa memakai 2 bearing seharga Rp 450.000 per buah, atau Rp 900.000. Pekerjaannya dilakukan 2 teknisi selama 3 jam, atau 6 jam kerja, dengan tarif internal Rp 75.000 per jam, atau Rp 450.000. Biaya aktual yang diposting ke cost center area pompa adalah Rp 1.350.000. Di ERP, angka ini tampil sebagai biaya pemeliharaan area. Di CMMS, angka yang sama melekat pada pompa tertentu, kegagalan tertentu, dan tanggal tertentu.

Tidak semua pertukaran perlu berjalan seketika. Data master aset dan material cukup disinkronkan secara berkala, sedangkan reservasi stok dan status permintaan pembelian sebaiknya diperbarui lebih cepat karena memengaruhi jadwal kerja. Posting biaya dapat dilakukan per work order atau dirangkum per periode, bergantung pada kebutuhan akuntansi biaya.

Langkah memutuskan dan mengintegrasikan

Urutan berikut membantu mengambil keputusan dengan data, lalu menjalankan integrasi dengan risiko yang terkendali.

1. 1Petakan alur yang berjalan sekarang. Telusuri satu pekerjaan dari laporan kerusakan sampai biayanya tercatat, lalu tandai setiap titik di mana data diketik ulang, ditunda, atau hilang.
2. 2Uji modul ERP yang sudah ada bersama teknisi. Pakai tiga pertanyaan pada kotak di atas, dan libatkan orang yang benar-benar memegang alat kerja, bukan hanya tim proyek ERP.
3. 3Tetapkan master untuk setiap objek data. Gunakan Tabel 2 sebagai titik awal, lalu sepakati kunci penghubungnya: ID aset, kode material, dan cost center.
4. 4Rapikan master suku cadang sebelum integrasi. Kode ganda untuk barang yang sama, satuan yang tidak konsisten, dan deskripsi yang tidak jelas akan ikut tersalin ke CMMS jika tidak dibersihkan lebih dulu.
5. 5Mulai dari integrasi minimum. Kirim data aset, material, dan cost center ke CMMS, lalu kirim biaya aktual ke ERP. Reservasi stok dan permintaan pembelian otomatis dapat menyusul.
6. 6Jalankan pilot di satu area. Pilih area dengan aset kritikal, jalankan siklus lengkap selama beberapa minggu, lalu cocokkan biaya di ERP dengan work order di CMMS.
7. 7Tetapkan pemilik data dan aturan perubahan. Tentukan siapa yang boleh membuat kode aset baru, kode material baru, dan cost center baru, serta di sistem mana perubahan itu dimulai.

Kesalahan umum saat menjalankan CMMS dan ERP bersama

Sebagian besar masalah integrasi bukan masalah teknis antarmuka, melainkan keputusan rancangan yang diambil terlalu cepat. Kesalahan berikut sering terlihat.

• Memaksa teknisi mengetik di layar keuangan. Layar yang dirancang untuk akuntansi biaya membuat teknisi menunda pencatatan, dan detail teknis hilang lebih dulu.
• Dua master aset yang berjalan sendiri-sendiri. Pompa baru didaftarkan di CMMS, tetapi tidak di ERP, atau sebaliknya. Dalam beberapa bulan, biaya tidak dapat lagi dihubungkan dengan asetnya.
• Mengintegrasikan semuanya pada hari pertama. Setiap alur tambahan menambah titik kegagalan. Proyek yang mencoba menyinkronkan seluruh objek sekaligus sering tertunda sebelum satu pun alur benar-benar dipakai.
• Suku cadang keluar tanpa work order. Jika barang dapat diambil dari gudang tanpa nomor work order, ERP mencatat stok berkurang, tetapi CMMS tidak tahu aset mana yang memakainya.
• Menganggap integrasi sebagai proyek TI semata. Tanpa pemilik dari pemeliharaan dan keuangan, aturan master data tidak pernah disepakati dan antarmuka hanya memindahkan kekacauan dari satu sistem ke sistem lain.

Ada juga batas yang perlu diakui. Integrasi tidak memperbaiki data yang buruk; ia hanya menyalinnya lebih cepat. Memiliki CMMS juga tidak otomatis membuat aset lebih andal. Nilainya baru muncul ketika riwayat yang tercatat benar-benar dibaca dan dipakai untuk mengubah rencana pemeliharaan.

Kesimpulan

Perdebatan CMMS dan ERP menjadi lebih jernih jika pertanyaannya diganti. Pertanyaannya bukan sistem mana yang lebih lengkap, melainkan di mana setiap jenis data paling baik dicatat dan siapa yang paling tahu isinya. ERP adalah tempat yang tepat untuk nilai stok, pembelian, cost center, dan biaya resmi. CMMS adalah tempat yang tepat untuk pelaksanaan pekerjaan, checksheet, kode kegagalan, dan riwayat teknis setiap aset.

Bagi pabrik yang sudah memakai ERP, langkah pertama yang masuk akal adalah menguji apakah modul pemeliharaannya benar-benar diisi oleh orang di lapangan. Jika ya, satu sistem mungkin cukup. Jika tidak, CMMS yang terhubung ke ERP dengan pembagian master data yang jelas biasanya lebih realistis daripada memaksa teknisi bekerja di layar yang tidak dirancang untuk mereka.