"Kenapa saya masih harus bayar tiap bulan? Sistemnya kan sudah jalan." Pertanyaan ini saya dengar dari hampir setiap klien yang pernah saya tangani, dan sebenarnya wajar untuk ditanyakan. Biaya maintenance software membingungkan justru karena produk yang dirawat itu terlihat sudah jadi. Gedung yang sedang direnovasi jelas butuh biaya berkelanjutan. Aplikasi yang berjalan lancar tidak terlihat butuh apa-apa. Intuisi itu keliru, dan memahami alasannya layak menyita sepuluh menit waktu Anda sebelum perpanjangan kontrak berikutnya.
Software bukan gedung, lebih mirip kebun. Dibiarkan saja, ia tidak akan tetap sama, ia akan menurun kualitasnya, karena tanah di bawahnya terus bergerak: sistem operasi diperbarui, browser berubah, payment gateway merotasi API mereka, kerentanan keamanan ditemukan di library yang bahkan tidak Anda sadari sedang Anda pakai. Biaya maintenance software adalah harga untuk membayar seseorang merawat kebun itu supaya tidak diam-diam membusuk sementara dari luar tetap terlihat baik-baik saja.
Yang sebenarnya dibeli dari biaya maintenance bulanan
Pecah menjadi empat kelompok, karena "maintenance" sebagai satu baris biaya menyembunyikan apa yang sebenarnya sedang dibayar.
Patching keamanan. Setiap software dibangun di atas puluhan, kadang ratusan, library pihak ketiga. Kerentanan terus-menerus ditemukan di library-library itu, dan perbaikan yang tidak diterapkan adalah pintu yang terbuka. Ini kerja yang tidak terlihat: tidak ada yang berubah di layar, tapi sistem yang tidak di-patch selama delapan belas bulan punya risiko yang secara material berbeda dibanding yang di-patch tiap bulan.
Update dependency dan kompatibilitas. Ponsel yang dipakai pelanggan Anda mendapat update OS. Browser yang dipakai staf admin Anda mengubah cara ia menangani script tertentu. Penyedia payment men-deprecate versi API lama sesuai jadwal mereka sendiri, bukan jadwal Anda. Semua ini bukan aplikasi Anda yang "rusak", ini dunia di sekitar aplikasi Anda yang berubah, dan seseorang perlu mengimbanginya atau aplikasi tetap akan rusak, hanya saja belakangan dan lebih mendadak.
Monitoring dan respons insiden. Seseorang perlu menyadari saat halaman pembayaran mulai gagal jam 2 pagi, sebelum pelanggan Anda yang menyadarinya duluan. Uptime monitoring, error tracking, dan adanya orang yang benar-benar bisa merespons saat ada alert, itu semua biaya, dan itu salah satu hal utama yang dibayar oleh biaya maintenance software.
Kapasitas enhancement kecil. Tidak semua perubahan butuh proyek penuh. "Bisa tambahkan filter di laporan ini" atau "PDF invoice perlu logo baru kami" adalah permintaan kecil yang menumpuk. Retainer maintenance biasanya mencakup sejumlah jam untuk hal-hal semacam ini, supaya permintaan kecil tidak masing-masing butuh penawaran baru dan seminggu bolak-balik.
Berapa biaya sebenarnya kalau maintenance ditunda
Saya pernah melihat langsung tagihannya kalau ini dilewatkan. Sebuah jaringan ritel di Tangerang yang pernah saya tangani sudah dua tahun tidak punya retainer maintenance untuk integrasi point-of-sale mereka, karena "toh masih jalan." Lalu sebuah penyedia payment men-deprecate versi API lama dengan pemberitahuan tiga bulan sebelumnya yang terkubur di email developer yang tidak ada yang baca. Begitu ada yang sadar, proses checkout sudah gagal secara intermiten di beberapa toko saat akhir pekan puncak penjualan. Biaya perbaikan darurat itu, ditambah kehilangan penjualan akhir pekan itu, lebih mahal dibanding dua tahun retainer maintenance yang moderat.
Itulah pola yang diikuti hampir semua kegagalan akibat maintenance yang ditunda:
| Biaya yang ditunda | Di mana dampaknya muncul |
|---|---|
| Kerentanan keamanan yang tidak di-patch | Kebocoran data, kegagalan kepatuhan, atau ransomware, sering baru muncul bertahun-tahun kemudian, padahal celahnya sudah ada sejak awal |
| Deprecation API yang tidak ditangani | Downtime mendadak sesuai jadwal vendor, bukan jadwal Anda, biasanya di momen paling buruk |
| Tidak ada monitoring | Pelanggan menemukan bug lebih dulu daripada Anda, dan saat itu terjadi, itu sudah jadi komplain, bukan lagi tiket |
| Tidak ada kapasitas enhancement | Setiap perubahan kecil berubah jadi negosiasi darurat dengan vendor yang sudah pindah fokus ke klien lain |
Perbaikan darurat selalu lebih mahal dibanding maintenance yang seharusnya dilakukan, dan itu datang dengan biaya reputasi yang tidak pernah dibebankan oleh biaya bulanan.
Cara membuat budget tanpa membayar berlebih
Retainer maintenance yang wajar biasanya 15 sampai 20 persen dari biaya pembangunan awal per tahun, meski ini bervariasi tergantung kompleksitas sistem dan seberapa kritis uptime bagi revenue Anda. Sebelum menandatangani atau memperpanjang kontrak, tanyakan tiga hal ini ke vendor Anda:
- Apa saja yang termasuk dalam "patching", secara spesifik, dan seberapa sering dilakukan?
- Apa komitmen waktu respons kalau ada yang rusak di production?
- Berapa jam kapasitas enhancement kecil yang dibundel, dan apa yang terjadi kalau jamnya tidak terpakai?
Kalau vendor tidak bisa menjawab ini secara spesifik, Anda bukan sedang membeli maintenance, Anda sedang membeli janji yang samar, yang merupakan bentuk lain dari utang teknis yang diam-diam menumpuk di kontrak Anda, bukan di codebase Anda.
Kesimpulan
Biaya maintenance software bukan pajak untuk sesuatu yang sudah berjalan, itu adalah harga untuk menjaganya tetap berjalan sementara segala sesuatu di sekitarnya terus berubah. Minta vendor Anda merinci apa yang sebenarnya Anda bayar, patching, kompatibilitas, monitoring, dan kapasitas enhancement, lalu bandingkan secara jujur dengan berapa biaya yang harus ditanggung kalau ada patch yang terlewat atau pemberitahuan deprecation yang terabaikan, di jam 2 pagi saat akhir pekan sibuk. Kalau Anda sedang mengevaluasi apakah setup atau hubungan vendor Anda saat ini masih masuk akal, itu percakapan yang layak dilakukan dengan partner sebelum perpanjangan kontrak berikutnya, bukan sesudah insiden berikutnya.