Kontrak Maintenance Aplikasi: Isi SLA yang Melindungi Operasional Setelah Go-Live

Aplikasi tidak selesai saat go-live. Sesudahnya selalu ada sistem operasi yang diperbarui, layanan pihak ketiga yang mengubah API-nya, bug yang baru muncul ketika volume transaksi naik, dan pengguna yang butuh bantuan. Kontrak maintenance aplikasi mengatur siapa menangani semua itu, seberapa cepat, dan dengan ketentuan apa.

Sayangnya banyak kontrak maintenance hanya berisi satu kalimat, misalnya "vendor memberikan dukungan teknis selama 12 bulan", ditambah satu angka biaya bulanan. Kalimat seperti itu tidak membantu ketika aplikasi berhenti pada Sabtu malam dan tidak ada yang tahu siapa yang harus dihubungi. Berikut isi yang perlu ada agar kontrak itu benar-benar melindungi operasional Anda.

Garansi dan maintenance adalah dua hal berbeda

Garansi adalah kewajiban vendor memperbaiki cacat dari pekerjaan proyek, tanpa biaya tambahan, selama periode tertentu setelah serah terima. Maintenance adalah layanan berkelanjutan sesudahnya: pemantauan, pembaruan, perbaikan, dukungan pengguna, dan perubahan kecil.

Kontrak perlu menyebut kapan garansi berakhir dan kapan maintenance dimulai. Satu hal yang perlu ditegaskan: cacat yang ditemukan di masa garansi tetap diperbaiki sebagai garansi, meskipun perbaikannya baru selesai setelah masa maintenance berjalan. Daftar temuan dari UAT yang belum selesai juga sebaiknya dilampirkan, agar tidak berubah status menjadi pekerjaan maintenance berbayar.

Lingkup kontrak maintenance aplikasi

Perawatan software umumnya terbagi menjadi empat jenis. Pastikan kontrak menyebut mana yang termasuk.

1. Korektif. Memperbaiki bug yang muncul saat aplikasi dipakai.
2. Adaptif. Menyesuaikan aplikasi dengan perubahan di sekitarnya: versi sistem operasi dan browser, perubahan API layanan pihak ketiga, atau aturan bisnis yang berubah karena regulasi.
3. Preventif. Memasang pembaruan keamanan, memperbarui pustaka yang usang, memeriksa cadangan, dan membersihkan hal yang berpotensi menjadi masalah.
4. Penyempurnaan. Perubahan kecil dan fitur tambahan. Ini yang paling sering menimbulkan selisih paham, jadi biasanya dibatasi dengan kuota jam atau ditangani sebagai permintaan perubahan.

Di luar empat jenis itu, tulis juga apakah kontrak mencakup pemantauan aplikasi, cadangan data beserta uji pemulihannya, dan dukungan bagi pengguna, termasuk jam layanan dan kanal yang dipakai.

Tingkat gangguan dan waktu tanggap

Inti SLA adalah definisi tingkat gangguan beserta janji waktunya. Tulis definisinya dengan contoh dari aplikasi Anda sendiri, bukan istilah umum.

• Kritis. Aplikasi tidak bisa dipakai sama sekali, data rusak, atau ada indikasi kebocoran. Contoh: kasir di semua cabang tidak bisa menyimpan transaksi.
• Tinggi. Fungsi utama terganggu tetapi ada jalan memutar. Contoh: laporan harian gagal dibuat otomatis dan harus ditarik manual.
• Sedang. Fungsi pendukung terganggu.
• Rendah. Masalah tampilan, teks, atau pertanyaan penggunaan.

Untuk setiap tingkat, pisahkan tiga janji waktu:

• Waktu respons: kapan vendor mengonfirmasi dan mulai menangani.
• Waktu pemulihan sementara: kapan operasional bisa berjalan lagi, meski dengan jalan memutar.
• Waktu penyelesaian: kapan perbaikan permanen terpasang.

Vendor yang hanya menjanjikan waktu respons belum menjanjikan apa pun tentang kapan masalah selesai. Tulis juga jam layanan untuk tiap tingkat. Aplikasi yang dipakai di akhir pekan butuh penanganan gangguan kritis di akhir pekan, sedangkan aplikasi laporan internal mungkin cukup ditangani di hari kerja berikutnya.

Contoh alur saat gangguan kritis terjadi

Bayangkan aplikasi pemesanan Anda berhenti pada Sabtu pukul delapan malam. Kontrak yang baik membuat urutan berikut berjalan tanpa perlu dirundingkan:

1. Staf yang bertugas melapor lewat kanal darurat yang tertulis di kontrak, bukan lewat pesan pribadi ke salah satu programmer.
2. Vendor mengonfirmasi dalam waktu respons yang disepakati dan menunjuk satu orang penanggung jawab.
3. Operasional dipulihkan lebih dulu, misalnya dengan mengembalikan versi sebelumnya, meskipun penyebabnya belum ditemukan.
4. Vendor memberi kabar berkala sampai masalah teratasi.
5. Dalam beberapa hari kerja, vendor menyerahkan laporan penyebab dan langkah pencegahannya.

Jika salah satu langkah ini belum tertulis, tambahkan sebelum kontrak ditandatangani.

Uptime: tulis cara menghitungnya

Angka uptime tanpa cara hitung tidak bisa ditagih. Sebagai gambaran, 99,5 persen dalam bulan 30 hari berarti gangguan paling lama sekitar 3,6 jam, sedangkan 99,9 persen berarti sekitar 43 menit. Pertanyaan yang perlu dijawab di kontrak:

• Diukur per bulan atau per tahun, dan dengan alat pemantauan apa.
• Apa yang dihitung sebagai "tidak tersedia": aplikasi tidak bisa dibuka, gagal login, atau satu fungsi utama mati.
• Apakah jendela pemeliharaan terjadwal dikecualikan, dan berapa hari sebelumnya harus diumumkan.
• Siapa yang bertanggung jawab atas server. Jika server berada di akun cloud milik Anda, tanggung jawab uptime terbagi dan pembagiannya perlu ditulis.

Pengecualian yang wajar

Vendor wajar mengecualikan gangguan yang berasal dari luar kendalinya: layanan pihak ketiga yang sedang bermasalah, jaringan internet di lokasi Anda, perubahan yang dibuat pihak lain tanpa koordinasi, atau akun yang disalahgunakan. Yang perlu dijaga, pengecualian tidak berarti vendor diam. Kontrak tetap mewajibkan vendor membantu mendiagnosis, menjelaskan penyebabnya, dan berkoordinasi dengan pihak ketiga atas nama Anda.

Permintaan perubahan dan kuota jam

Kebutuhan bisnis berubah setelah go-live, dan permintaan kecil akan terus datang. Ada dua cara mengaturnya. Pertama, kuota jam per bulan untuk perubahan kecil, dengan aturan jelas apakah sisa jam hangus atau bisa dibawa ke bulan berikutnya. Kedua, setiap perubahan diestimasi dan disetujui terpisah. Apa pun pilihannya, wajibkan estimasi tertulis sebelum pekerjaan dimulai, agar tagihan tidak datang sebagai kejutan.

Laporan bulanan

Laporan maintenance yang berguna memuat daftar tiket beserta waktu respons dan penyelesaiannya dibandingkan target, uptime bulan itu, pembaruan keamanan yang dipasang, hasil uji pemulihan cadangan, dan rekomendasi untuk bulan berikutnya. Tanpa laporan, Anda tidak punya dasar untuk menilai apakah biaya bulanan sepadan.

Syarat keluar: bagian yang paling sering dilupakan

Kontrak maintenance aplikasi juga harus mengatur bagaimana ia berakhir.

• Masa kontrak, cara perpanjangan, dan berapa lama pemberitahuan sebelum berakhir.
• Konsekuensi bila target SLA berulang kali tidak tercapai, misalnya potongan biaya atau hak mengakhiri kontrak lebih awal.
• Kewajiban saat berakhir: dokumentasi terbaru, seluruh akses dan kredensial, serta bantuan transisi ke tim atau vendor berikutnya.

Syarat keluar ini hanya bermakna bila kode dan akunnya memang milik Anda. Bila belum, baca dulu panduan kepemilikan source code.

Pertanyaan sebelum menandatangani

• Siapa yang saya hubungi saat gangguan kritis terjadi di luar jam kerja, dan lewat kanal apa?
• Apakah waktu penyelesaian, bukan hanya waktu respons, tertulis untuk setiap tingkat?
• Apa yang terjadi pada tiket yang masih terbuka ketika kontrak berakhir?
• Bagaimana saya tahu pembaruan keamanan benar-benar dipasang?

Di lini Enterprise Software Etzal Group, proyek ditutup dengan serah terima, dokumentasi, dan garansi 30 hari, lalu berlanjut ke maintenance dengan ketentuan yang ditulis di penawaran. Jika Anda ingin draf kontrak maintenance dari vendor mana pun dibaca dari sisi teknis, gunakan sesi konsultasi gratis.