Harga software CMMS: komponen biaya, model lisensi, dan cara menghitung TCO

Harga software CMMS: mengapa lebih dari sekadar lisensi

Ketika manajemen bertanya tentang harga software CMMS, yang biasanya terbayang adalah satu angka di halaman penawaran: biaya lisensi atau langganan. Angka itu nyata, tetapi hanya sebagian dari pengeluaran. Sebuah CMMS baru bekerja setelah register aset disusun, rencana pemeliharaan preventif dimasukkan, teknisi dilatih, dan sistemnya dirawat selama bertahun-tahun. Semua itu juga biaya, dan sebagian besar tidak tercantum di baris lisensi.

Karena itu, ukuran yang lebih jujur adalah total biaya kepemilikan atau total cost of ownership (TCO): jumlah seluruh biaya untuk memperoleh, menerapkan, dan menjalankan sistem selama periode yang ditetapkan, misalnya tiga atau lima tahun. TCO mencakup biaya yang dibayar ke vendor, biaya yang dibayar ke pihak lain (perangkat keras, jaringan, hosting), dan biaya berupa waktu orang di pabrik sendiri.

Gagasan ini bukan hal baru dalam pemeliharaan. Literatur manajemen aset mengenalnya sebagai life-cycle costing: keputusan atas sebuah aset dinilai dari seluruh biaya sepanjang umurnya, mulai dari pengadaan, operasi, dan pemeliharaan hingga penghapusan, bukan dari harga belinya saja^[1]. Perangkat lunak pemeliharaan dapat diperlakukan dengan cara yang sama. ISO 55000 juga menempatkan manajemen aset sebagai upaya mewujudkan nilai dari aset dengan menyeimbangkan biaya, risiko, dan kinerja^[2]. Jadi, pertanyaan yang tepat bukan "CMMS mana yang paling murah", melainkan "berapa biaya total untuk memperoleh manfaat yang dibutuhkan pabrik, dan seberapa besar risikonya".

Model lisensi dan cara vendor menyusun harga

Vendor CMMS menyusun harga dengan dasar yang berbeda-beda, dan dasar itu menentukan bagaimana biaya bertambah ketika pemakaian sistem meluas. Memahami dasarnya lebih berguna daripada menghafal angkanya, karena angka berubah dari tahun ke tahun sementara strukturnya relatif tetap. Beberapa model berikut sering dijumpai, dan satu penawaran dapat menggabungkan lebih dari satu model.

Per pengguna: named user dan concurrent user

Model yang paling umum menetapkan biaya untuk setiap pengguna. Lisensi named user terikat pada satu orang tertentu: akun seorang supervisor hanya dipakai olehnya, walaupun ia hanya masuk dua kali seminggu. Lisensi concurrent user membatasi jumlah orang yang masuk pada saat yang sama, sehingga beberapa teknisi dari shift berbeda dapat berbagi satu kuota. Sebagian vendor juga membedakan jenis pengguna, misalnya pengguna penuh untuk planner dan supervisor serta pengguna terbatas untuk teknisi yang hanya menerima dan menutup work order.

Kelemahan model ini terasa pada pabrik yang ingin setiap teknisi mencatat sendiri pekerjaannya di lapangan. Semakin banyak orang yang diberi akun, semakin besar biayanya, sehingga muncul godaan untuk membatasi akun pada admin saja. Akibatnya, teknisi kembali menulis di kertas dan admin mengetik ulang di akhir shift. Biaya lisensi memang turun, tetapi kualitas data ikut turun, padahal data itulah alasan utama membeli CMMS.

Per aset

Sebagian vendor menghitung harga berdasarkan jumlah aset yang dikelola. Model ini adil bagi pabrik dengan sedikit mesin besar dan banyak pengguna. Sebaliknya, model ini memberatkan pabrik dengan banyak aset kecil: ratusan motor, pompa, kipas, dan katup yang masing-masing perlu riwayat sendiri. Dalam situasi seperti itu, tim cenderung menggabungkan beberapa aset menjadi satu entri agar tagihan tidak naik, dan riwayat per komponen pun hilang. Sebelum menerima model ini, pastikan definisi "aset" dalam penawaran tertulis jelas, termasuk apakah komponen di bawah sebuah mesin ikut dihitung.

Per lokasi dan paket tetap

Model per lokasi (per site) menetapkan satu harga untuk satu pabrik atau gedung tanpa menghitung pengguna dan aset secara rinci. Ada juga paket dengan harga tetap, biasanya dengan batas tertentu pada jumlah pengguna, aset, atau modul. Model ini mudah dianggarkan, tetapi perlu diperiksa apa yang terjadi ketika batas paket terlampaui dan apakah pabrik kedua dihitung sebagai lokasi baru dengan harga penuh.

Langganan SaaS atau lisensi perpetual

Di luar dasar perhitungannya, ada dua cara membayar. Pada model langganan (software as a service, SaaS), pabrik membayar per bulan atau per tahun selama sistem dipakai, dan umumnya hosting, pembaruan, serta dukungan teknis sudah termasuk. Pada lisensi perpetual, pabrik membayar hak pakai di awal, lalu membayar biaya pemeliharaan dan dukungan tahunan agar tetap mendapat pembaruan dan bantuan teknis. Langganan memperkecil biaya awal tetapi berjalan terus, sedangkan lisensi perpetual memperbesar biaya awal tetapi biaya tahunannya bisa lebih kecil. Mana yang lebih murah bergantung pada periode perhitungan, dan itulah sebabnya TCO selalu disebut bersama jumlah tahunnya.

Cloud atau on-premise

Lokasi sistem juga mengubah struktur biaya. Pada sistem cloud, server, cadangan data, dan keamanan dikelola penyedia, dan biayanya sudah masuk ke langganan. Pada sistem on-premise, pabrik menyediakan server sendiri, ruang dan daya listrik untuk server itu, lisensi sistem operasi dan basis data jika diperlukan, prosedur backup, serta staf TI yang memasang pembaruan dan memulihkan sistem ketika terjadi gangguan. Biaya-biaya ini jarang muncul di penawaran vendor CMMS karena dibayar ke pihak lain atau berupa waktu staf sendiri. Di sisi lain, on-premise kadang dipilih karena kebijakan data perusahaan atau koneksi internet di lokasi yang tidak andal, dan alasan seperti itu sah selama biayanya ikut dihitung.

Biaya satu kali: dari implementasi sampai pelatihan

Biaya satu kali dibayar di awal proyek dan tidak jarang lebih besar dari biaya lisensi tahun pertama. Rinciannya berbeda antarvendor, tetapi pekerjaan yang harus dilakukan relatif sama di mana pun.

• Implementasi dan konfigurasi. Menyusun struktur lokasi, area, dan lini; mengatur peran pengguna dan alur persetujuan work order; menyiapkan kode kerusakan.
• Register aset dan pembersihan data. Mendaftar setiap aset dengan kode, lokasi, data pelat nama, dan tingkat kritikalitas, lalu membuang duplikasi dan entri yang sudah tidak ada di lapangan.
• Migrasi dari Excel atau sistem lama. Memindahkan daftar aset, jadwal preventif, dan, jika memang layak, riwayat perbaikan yang konsisten.
• Rencana PM dan checksheet. Menerjemahkan rekomendasi pabrikan dan pengalaman tim menjadi tugas, interval, dan butir pemeriksaan yang terukur.
• Pelatihan. Untuk admin, planner, supervisor, dan teknisi, dengan materi yang berbeda untuk setiap peran.
• Integrasi. Menghubungkan CMMS dengan ERP untuk suku cadang, pembelian, dan biaya, atau dengan sistem lain yang sudah berjalan.

Butir keempat paling sering diremehkan. Perangkat lunak dapat menyimpan rencana PM dan checksheet, tetapi isinya harus disusun oleh orang yang memahami mesinnya. Palmer mengingatkan bahwa sistem komputer membantu planner menyimpan rencana kerja dan riwayat peralatan, tetapi tidak menggantikan pekerjaan perencanaan itu sendiri^[3]. Jika vendor menawarkan "konfigurasi PM", tanyakan apakah yang dimaksud adalah memasukkan rencana yang sudah Anda siapkan, atau ikut menyusun isinya bersama tim Anda. Selisih antara keduanya dapat mencapai beberapa minggu kerja.

Integrasi dengan ERP perlu dibahas tersendiri karena biayanya sangat bergantung pada sistem yang sudah ada: apakah ERP menyediakan antarmuka standar, data apa yang perlu mengalir (kode suku cadang, permintaan pembelian, biaya per work order), dan siapa yang memelihara penghubungnya ketika salah satu sistem diperbarui. Pembagian peran antara kedua sistem dibahas lebih rinci di artikel CMMS dan ERP. Untuk keperluan penawaran, minta vendor memisahkan biaya integrasi dari biaya implementasi, karena integrasi sering dapat ditunda ke tahap kedua setelah alur kerja dasarnya berjalan.

Perangkat keras dan tambahan opsional

CMMS yang dipakai di lapangan membutuhkan perangkat untuk mengaksesnya. Sebagian pabrik memberikan tablet atau ponsel kepada teknisi, sebagian lagi memasang komputer bersama di bengkel. Pilihan pertama membuat pencatatan lebih dekat dengan pekerjaan, tetapi menambah biaya perangkat, pelindungnya, dan penggantian perangkat yang rusak atau hilang. Pilihan kedua lebih murah, tetapi teknisi harus berjalan ke bengkel untuk menutup work order, dan kebiasaan menunda pencatatan pun kembali.

Jaringan di lantai produksi juga perlu diperiksa. Ruang kompresor, ruang panel, atau gudang di ujung gedung sering tidak terjangkau Wi-Fi. Jika sistem harus dipakai di sana, ada biaya titik akses tambahan, atau perlu dipastikan aplikasinya dapat bekerja tanpa koneksi lalu menyinkronkan data ketika jaringan tersedia kembali.

Sensor untuk condition monitoring, seperti sensor vibrasi atau temperatur, sebaiknya diperlakukan sebagai tambahan opsional yang dapat menyusul kemudian, bukan bagian dari keputusan awal. Pabrik yang belum memiliki register aset dan disiplin work order akan kesulitan memanfaatkan data sensor, karena belum ada tempat yang rapi untuk menindaklanjuti temuannya. Jika sensor sudah direncanakan, cukup pastikan CMMS yang dipilih dapat menerima data kondisi atau pemicu work order dari sistem lain di kemudian hari.

Biaya yang sering terlewat

Sebagian biaya tidak muncul di penawaran vendor mana pun karena dibayar dalam bentuk waktu, bukan uang. Justru biaya inilah yang paling sering membuat proyek CMMS terlambat atau berhenti di tengah jalan.

Waktu staf untuk menyiapkan data. Seseorang harus mendatangi setiap mesin, mencocokkan kode aset dengan pelat nama, memotret, dan mencatat komponen pentingnya. Di pabrik dengan ratusan aset, pekerjaan ini dapat memakan waktu berminggu-minggu bagi satu atau dua orang yang masih memegang tugas rutin. Jika waktu ini tidak dianggarkan, pekerjaan pemeliharaan harian yang dikorbankan, atau data disusun terburu-buru dan harus diperbaiki kemudian.

Manajemen perubahan. Teknisi yang terbiasa melapor lewat grup pesan tidak otomatis beralih ke aplikasi. Supervisor perlu meluangkan waktu untuk mendampingi, memeriksa work order yang ditutup tanpa data lengkap, dan membahas hasilnya di rapat. Biaya ini kecil per hari, tetapi berlangsung berbulan-bulan.

Kustomisasi yang menghambat pembaruan. Permintaan untuk mengubah layar atau alur kerja agar persis seperti formulir lama terdengar wajar. Namun, kustomisasi yang dibuat di luar konfigurasi standar dapat membuat setiap pembaruan versi memerlukan pengujian ulang, bahkan pekerjaan tambahan yang berbayar. Tanyakan kepada vendor mana yang termasuk konfigurasi biasa dan mana yang merupakan perubahan kode, serta apa akibatnya pada pembaruan.

Harga per modul. Beberapa vendor menjual fungsi seperti inventori suku cadang, aplikasi seluler, laporan lanjutan, atau integrasi sebagai modul terpisah. Penawaran awal yang tampak murah bisa saja belum mencakup modul yang ternyata dibutuhkan sejak hari pertama. Sebaliknya, paket lengkap bisa berisi modul yang tidak akan dipakai dalam dua tahun pertama.

Biaya keluar. Hal ini jarang dipikirkan di awal: jika suatu saat pabrik berganti sistem, dalam format apa data dapat diekspor, dan apakah ekspor itu dikenai biaya? Riwayat aset adalah milik pabrik, dan hak untuk mengambilnya sebaiknya tertulis di kontrak.

Rumus TCO, payback, dan ROI CMMS

Setelah semua komponen terdaftar, TCO dapat dihitung dengan rumus sederhana. Yang penting adalah konsistensi: periode yang sama, asumsi yang sama, dan setiap komponen ditulis terpisah agar dapat diperiksa orang lain.

Biaya hanyalah separuh dari pertanyaan manajemen. Separuh lainnya adalah manfaat, dan di sinilah kehati-hatian dibutuhkan. Dua ukuran berikut paling mudah dipahami oleh bagian keuangan.

Rumusnya sederhana; yang sulit adalah angka manfaat. Manfaat yang dapat dipertanggungjawabkan harus dihitung dari baseline pabrik sendiri: jam downtime per bulan pada aset kritikal, jam lembur teknisi untuk perbaikan darurat, nilai pembelian suku cadang mendadak, atau biaya jasa luar yang dipanggil karena kerusakan tidak terdeteksi lebih awal. Wireman menekankan bahwa indikator pemeliharaan baru berguna jika diukur secara konsisten dan dipantau trennya dari waktu ke waktu^[4]. Angka dari brosur atau dari pabrik lain tidak dapat menggantikan baseline tersebut, karena definisi dan kondisinya berbeda.

EN 15341 menyusun indikator kinerja pemeliharaan dengan mempertimbangkan aspek ekonomi, teknis, dan organisasi^[5]. Bagi perhitungan ROI, artinya manfaat sebaiknya dinyatakan dalam indikator yang memang sudah atau akan diukur pabrik, misalnya biaya pemeliharaan, jam downtime, atau persentase pekerjaan terencana, bukan dalam istilah umum seperti "efisiensi meningkat". Indikator yang lazim dipakai dibahas di artikel KPI maintenance. Untuk memperkirakan manfaat dari data pabrik Anda sendiri, simulator ROI di situs ini dapat dipakai sebagai titik awal sebelum angkanya dibawa ke rapat anggaran.

Contoh perhitungan: dua model harga selama tiga tahun

Angka berikut adalah ilustrasi untuk menunjukkan cara menghitung, bukan harga pasar. Sebuah pabrik memiliki 400 aset yang akan didaftarkan dan 12 pengguna: satu planner, dua supervisor, satu admin, dan delapan teknisi. Pabrik menerima dua penawaran rekaan. Model A adalah langganan cloud per pengguna sebesar Rp0,4 juta per pengguna per bulan. Model B adalah lisensi perpetual per aset sebesar Rp0,25 juta per aset, dipasang on-premise, dengan dukungan tahunan 20% dari nilai lisensi. Model B juga membutuhkan server dan instalasi senilai Rp40 juta serta pengelolaan TI dan backup senilai Rp18 juta per tahun. Biaya implementasi, pembersihan data, dan pelatihan dianggap sama untuk keduanya, yaitu Rp60 juta, begitu pula waktu admin internal senilai Rp12 juta per tahun.

Dalam ilustrasi ini, Model A lebih murah selama tiga tahun walaupun biaya tahunannya lebih tinggi, karena Model B membawa biaya awal yang besar. Kesimpulan itu bergantung pada asumsinya. Jika periodenya diperpanjang, selisihnya menyempit: setiap tahun Model A menambah 69,6 sedangkan Model B menambah 50,0, sehingga selisih biaya awal sebesar 140,0 (200,0 − 60,0) berkurang 19,6 per tahun dan baru habis setelah sekitar 7,1 tahun (140,0 ÷ 19,6).

Jumlah pengguna dan aset juga mengubah gambaran. Jika pabrik memutuskan memberi akun kepada 24 orang, termasuk operator yang melaporkan kerusakan, langganan Model A menjadi 24 × 0,4 × 12 = 115,2 per tahun. TCO tiga tahunnya naik menjadi 60,0 + 3 × (115,2 + 12,0) = 441,6, lebih tinggi dari Model B yang tidak berubah karena jumlah asetnya tetap. Sebaliknya, jika pabrik menambahkan 300 aset kecil ke register, lisensi Model B naik menjadi 700 × 0,25 = 175,0 dan dukungan tahunannya menjadi 35,0, sehingga TCO tiga tahunnya menjadi 275,0 + 3 × 65,0 = 470,0, sementara Model A tetap 268,8.

Untuk payback, misalkan dari catatan lembur, pembelian darurat, dan jam downtime tahun lalu, tim memperkirakan manfaat sebesar Rp120 juta per tahun, dan untuk penyederhanaan manfaat itu dianggap berlaku penuh sejak tahun pertama. Angka ini juga ilustrasi. Pada Model A, manfaat bersihnya 120,0 − 69,6 = 50,4 per tahun, sehingga payback = 60,0 ÷ 50,4 ≈ 1,2 tahun (sekitar 14 bulan). Pada Model B, manfaat bersihnya 120,0 − 50,0 = 70,0 per tahun, sehingga payback = 200,0 ÷ 70,0 ≈ 2,9 tahun. Dengan total manfaat tiga tahun 360,0, ROI Model A adalah (360,0 − 268,8) ÷ 268,8 × 100% ≈ 33,9%, sedangkan ROI Model B adalah (360,0 − 350,0) ÷ 350,0 × 100% ≈ 2,9%.

Perhitungan ini tidak mengatakan bahwa manfaat sebesar itu pasti tercapai. Ia hanya menunjukkan bagaimana asumsi manfaat dan struktur harga bersama-sama menentukan hasil, dan mengapa setiap angka di dalamnya harus dapat ditelusuri ke sumbernya.

Langkah meminta dan membandingkan penawaran vendor CMMS

Penawaran dari vendor yang berbeda hampir selalu disusun dengan asumsi yang berbeda pula. Langkah-langkah berikut membantu menyamakan dasar perbandingan sebelum angkanya dibawa ke manajemen.

1. 1Tulis kebutuhan dalam satu dokumen singkat. Cantumkan jumlah aset yang akan didaftarkan, jumlah pengguna menurut peran, lokasi, modul yang dibutuhkan sejak awal, dan integrasi yang diharapkan. Kirim dokumen yang sama ke setiap vendor.
2. 2Minta harga untuk periode yang sama. Tetapkan tiga atau lima tahun, lalu minta setiap vendor merinci biaya per tahun, termasuk kenaikan harga yang sudah direncanakan.
3. 3Pisahkan biaya satu kali dan biaya berjalan. Minta implementasi, migrasi data, pelatihan, dan integrasi ditulis sebagai baris terpisah, bukan digabung dalam satu paket.
4. 4Daftarkan apa yang termasuk dan tidak termasuk. Periksa hosting, backup, pembaruan versi, jam dukungan, aplikasi seluler, jumlah sesi pelatihan, dan batas penyimpanan berkas.
5. 5Tanyakan definisi satuan harga. Pastikan apa yang dihitung sebagai pengguna, sebagai aset, dan sebagai lokasi, serta berapa biayanya jika jumlah itu bertambah di tengah kontrak.
6. 6Hitung TCO dengan format Anda sendiri. Masukkan setiap penawaran ke tabel yang sama, tambahkan biaya yang dibayar ke pihak lain dan waktu tim internal, lalu bandingkan totalnya.
7. 7Minta pilot di satu area. Gunakan data aset dan work order nyata dari satu area selama beberapa minggu. Pilot menunjukkan apakah teknisi benar-benar mau memakai sistemnya, dan hal itu tidak dapat dilihat dari demo.
8. 8Periksa ketentuan data dan kontrak. Perhatikan format ekspor data, kepemilikan data, masa kontrak minimum, dan cara mengakhiri kontrak.

Kesalahan umum saat menilai harga CMMS

Kesalahan berikut sering muncul bukan karena tim kurang teliti, melainkan karena tekanan untuk segera memberikan satu angka kepada manajemen.

• Memilih berdasarkan harga lisensi saja. Lisensi termurah dapat menjadi pilihan termahal jika implementasinya panjang, modul pentingnya dijual terpisah, atau sistemnya tidak dipakai teknisi.
• Membeli modul yang tidak dipakai. Paket lengkap terasa aman, tetapi modul yang belum siap dijalankan hanya menambah biaya tahunan. Mulailah dari fungsi inti: register aset, work order, PM, dan checksheet.
• Melewatkan pembersihan data. Memindahkan daftar aset lama apa adanya ke sistem baru hanya memindahkan masalahnya. Duplikasi dan kode yang tidak konsisten akan muncul lagi di setiap laporan.
• Membatasi akun demi menghemat lisensi. Jika hanya admin yang dapat masuk, sistem kembali bergantung pada rekap di akhir shift, dan data yang menjadi alasan membeli CMMS tidak pernah lengkap.
• Menjanjikan manfaat tanpa baseline. ROI yang tidak dihitung dari data pabrik sendiri sulit dipertahankan ketika manajemen menanyakan hasilnya setahun kemudian.

Kesimpulan

Harga sebuah CMMS tidak dapat dijawab dengan satu angka tanpa menyebut periode, jumlah pengguna, jumlah aset, dan cakupannya. Jawaban yang dapat dipertanggungjawabkan kepada manajemen adalah TCO selama tiga atau lima tahun, yang memisahkan biaya satu kali dari biaya berjalan dan ikut menghitung waktu tim internal. Model lisensi menentukan bagaimana biaya itu bertambah ketika pemakaian meluas, sehingga model yang tepat bergantung pada bentuk pabriknya: banyak pengguna atau banyak aset, satu lokasi atau beberapa.

Sebelum menghubungi vendor, siapkan dua hal: daftar kebutuhan yang sama untuk semua penawaran dan baseline dari data pabrik sendiri. Daftar kebutuhan membuat penawaran dapat dibandingkan, sedangkan baseline membuat angka manfaat dapat diuji. Dengan keduanya, pertanyaan "berapa biaya CMMS?" dapat dijawab dengan tabel yang dapat diperiksa siapa pun, bukan dengan satu angka yang sulit dijelaskan.