Mengapa SLA Penting untuk Menjaga Keandalan Sistem Bisnis?

Mengapa SLA Penting untuk Menjaga Keandalan Sistem Bisnis?

• Fase ‘M’ pada Siklus PADI-M: Maintenance & SLA
• Apa Saja yang Dicakup dalam Kontrak Maintenance?
• SLA Bukan Sekadar Target Uptime
• Menghitung Efisiensi: Kontrak Maintenance vs. Programmer In-House
• Pastikan Aplikasi Tetap Siap Digunakan Setelah Go-Live
  • Siapa yang Menangani Aplikasi Anda Saat Terjadi Masalah?

Ada satu miskonsepsi yang masih sering muncul ketika perusahaan merencanakan pengadaan software: menganggap proyek aplikasi sama seperti pengadaan perangkat atau furnitur kantor. Setelah aplikasi selesai dibuat, dipasang, dan diserahkan oleh vendor, pekerjaan dianggap tuntas.

Padahal, software memiliki karakteristik yang berbeda. Aplikasi bukan produk statis yang akan terus berfungsi optimal tanpa pemeliharaan. Seiring waktu, kebutuhan bisnis berubah, jumlah data bertambah, dependensi teknologi berkembang, dan ancaman keamanan terus bermunculan.

Dalam Software Engineering, peluncuran aplikasi atau go-live bukanlah akhir dari siklus hidup software. Justru pada tahap inilah sistem mulai menghadapi kondisi operasional sesungguhnya, mulai dari beban penggunaan sehari-hari hingga perubahan kebutuhan pengguna.

Bayangkan sebuah aplikasi internal yang berjalan lancar saat pertama kali diluncurkan. Beberapa bulan kemudian, volume data meningkat dan proses laporan menjadi semakin lambat. Ruang penyimpanan server mulai menipis, sejumlah integrasi gagal berjalan, dan tim operasional mulai mengeluhkan gangguan yang menghambat pekerjaan mereka.

Risikonya tidak hanya berkaitan dengan performa. Software yang tidak mendapatkan pembaruan keamanan secara rutin dapat menjadi lebih rentan terhadap serangan. Misalnya, penggunaan versi PHP yang sudah tidak didukung, dependensi yang memiliki kerentanan, atau konfigurasi server yang tidak aman dapat membuka celah bagi pihak yang tidak berwenang.

Ketika gangguan terjadi, perusahaan tentu akan menghubungi vendor yang membangun aplikasi tersebut. Namun, bagaimana jika masa garansi yang disepakati dalam kontrak sudah berakhir? Apakah vendor masih berkewajiban memberikan dukungan? Berapa lama waktu yang dibutuhkan untuk merespons insiden? Dan apakah biaya perbaikannya sudah tercakup dalam anggaran?

Tanpa kesepakatan dukungan pascapeluncuran yang jelas, perusahaan berisiko menghadapi ketidakpastian justru ketika sistem sedang dibutuhkan. Pekerjaan perbaikan mungkin harus dinegosiasikan kembali, biaya tambahan perlu disetujui, dan waktu penanganan dapat memengaruhi kelangsungan operasional bisnis.

Inilah alasan mengapa pengadaan software tidak seharusnya berhenti pada serah terima aplikasi. Perusahaan juga perlu merencanakan bagaimana sistem tersebut akan dipelihara, diamankan, dan didukung setelah mulai digunakan.

Salah satu instrumen untuk memperjelas tanggung jawab tersebut adalah Service Level Agreement (SLA), yang menetapkan target layanan dan kewajiban para pihak berdasarkan kesepakatan.

Fase ‘M’ pada Siklus PADI-M: Maintenance & SLA

Bagi Dika Karya Tech, peluncuran aplikasi bukanlah akhir dari tanggung jawab pengembangan software. Setelah sistem mulai digunakan, perusahaan tetap perlu memastikan aplikasi berjalan dengan baik, data terlindungi, dan gangguan operasional dapat ditangani secara terencana.

Itulah sebabnya metodologi pengembangan PADI-M tidak berhenti pada fase ‘I’ (Implementasi), tetapi berlanjut ke fase ‘M’ (Maintenance atau Pemeliharaan).

Salah satu cara untuk mengatur dukungan pascapeluncuran adalah melalui kontrak pemeliharaan yang dilengkapi Service Level Agreement (SLA).

SLA menetapkan ekspektasi dan tanggung jawab penyedia layanan, termasuk target waktu respons, penanganan insiden, jam dukungan, serta target ketersediaan sistem jika disepakati. Sementara itu, kontrak maintenance menjelaskan aktivitas pemeliharaan yang dilakukan, seperti pembaruan keamanan, pemantauan infrastruktur, backup data, dan perbaikan bug sesuai ruang lingkup layanan.

Keduanya membantu perusahaan menghindari ketidakjelasan ketika aplikasi mengalami masalah setelah masa garansi berakhir.

Fase maintenance mencakup aktivitas pemeliharaan aplikasi dan infrastruktur, pemantauan sistem, serta pengelolaan backup. SLA membantu menetapkan target layanan dan tanggung jawab yang disepakati antara penyedia layanan dan klien.

Apa Saja yang Dicakup dalam Kontrak Maintenance?

Anggaran pemeliharaan software sebaiknya tidak dipandang sekadar sebagai biaya tambahan setelah proyek selesai. Pemeliharaan merupakan bagian dari pengelolaan risiko dan keberlangsungan sistem yang digunakan dalam operasional bisnis.

Berikut beberapa aktivitas yang dapat dimasukkan dalam kontrak maintenance Dika Karya Tech, sesuai kebutuhan dan ruang lingkup layanan yang disepakati.

Perlu diperhatikan bahwa aktivitas tersebut tidak otomatis mencakup seluruh kebutuhan pemeliharaan. Misalnya, peningkatan fitur besar, migrasi infrastruktur, audit keamanan menyeluruh, dan pengembangan integrasi baru dapat memerlukan anggaran atau kesepakatan terpisah.

Karena itu, perusahaan perlu mengetahui dengan jelas layanan apa yang termasuk dalam biaya bulanan dan pekerjaan apa yang akan ditagihkan secara terpisah.

SLA Bukan Sekadar Target Uptime

Salah satu metrik yang sering digunakan dalam SLA adalah uptime, yaitu persentase waktu ketika layanan tersedia sesuai definisi yang disepakati.

Sebagai ilustrasi, target ketersediaan 99,9% dalam periode 30 hari setara dengan sekitar 43,2 menit waktu tidak tersedia, jika dihitung berdasarkan seluruh menit dalam periode tersebut tanpa pengecualian.

Namun, angka itu saja tidak cukup untuk menilai kualitas layanan.

Perusahaan juga perlu mengetahui:

• Response time: target waktu sejak laporan insiden diterima hingga tim dukungan mulai merespons.
• Resolution atau recovery target: target penyelesaian atau pemulihan, jika dapat ditetapkan dan disepakati.
• Incident severity: klasifikasi tingkat keparahan berdasarkan dampak gangguan terhadap operasional.
• Support hours: jam operasional tim dukungan, termasuk apakah layanan darurat tersedia di luar jam kerja.
• Escalation procedure: jalur eskalasi ketika insiden tidak dapat ditangani pada tingkat dukungan awal.
• Service exclusions: kondisi yang tidak termasuk dalam perhitungan SLA, sesuai ketentuan kontrak. Penting untuk membedakan target waktu respons dengan target waktu penyelesaian. Respons dalam 30 menit, misalnya, tidak berarti seluruh masalah pasti selesai dalam 30 menit.

Demikian pula, target uptime hanya bermakna jika definisi ketersediaan, metode pengukuran, periode evaluasi, dan pengecualiannya jelas.

SLA yang baik bukan sekadar mencantumkan angka tinggi, melainkan menetapkan komitmen yang terukur dan sesuai dengan kemampuan operasional penyedia layanan.

Menghitung Efisiensi: Kontrak Maintenance vs. Programmer In-House

Sebagian perusahaan memilih merekrut programmer atau administrator sistem internal untuk menangani pemeliharaan aplikasi. Pendekatan ini memberikan kendali langsung atas pekerjaan teknis dan dapat menjadi pilihan tepat bagi perusahaan yang membutuhkan tim internal secara berkelanjutan.

Namun, biaya tenaga kerja bukan satu-satunya komponen yang perlu diperhitungkan.

Selain gaji, perusahaan mungkin perlu menyediakan tunjangan, THR, perangkat kerja, pelatihan, dan waktu untuk pengembangan kompetensi. Ketergantungan pada satu orang juga dapat menjadi risiko ketika karyawan tersebut cuti, mengundurkan diri, atau tidak tersedia saat insiden terjadi.

Sebagai ilustrasi, jika biaya tenaga kerja seorang profesional teknis diasumsikan sebesar Rp10 juta hingga Rp15 juta per bulan, biaya langsung selama satu tahun mencapai Rp120 juta hingga Rp180 juta. Angka tersebut belum mencakup seluruh biaya tambahan yang mungkin ditanggung perusahaan.

Sebagai alternatif, perusahaan dapat mempertimbangkan kontrak maintenance dengan vendor yang memahami aplikasi dan infrastrukturnya.

Misalnya, jika sebuah penawaran maintenance berada pada kisaran Rp2 juta hingga Rp5 juta per bulan, biaya kontrak selama setahun menjadi Rp24 juta hingga Rp60 juta.

Namun, angka tersebut merupakan ilustrasi, bukan perbandingan biaya yang setara secara otomatis. Kontrak maintenance mungkin hanya mencakup sejumlah jam dukungan, pemantauan terbatas, dan perbaikan tertentu. Sementara itu, karyawan internal dapat memiliki tanggung jawab yang jauh lebih luas.

Sebelum membandingkan keduanya, perusahaan perlu memeriksa:

1. Berapa jam dukungan yang tersedia setiap bulan?
2. Apakah penanganan insiden di luar jam kerja termasuk dalam kontrak?
3. Apakah biaya perbaikan bug dan pembaruan keamanan sudah termasuk?
4. Siapa yang bertanggung jawab atas infrastruktur, backup, dan pemulihan data?
5. Apakah pekerjaan tambahan memerlukan persetujuan anggaran terpisah?
6. Bagaimana dokumentasi dan pengetahuan teknis dipertahankan agar tidak bergantung pada satu orang? Untuk perusahaan yang tidak membutuhkan tenaga teknis penuh waktu, kontrak maintenance dapat menjadi pilihan yang lebih efisien. Sebaliknya, perusahaan dengan sistem yang sangat kritis, kebutuhan perubahan harian, atau operasi teknis berskala besar mungkin tetap memerlukan tim internal, baik secara mandiri maupun melalui model kerja bersama vendor.

Keputusan sebaiknya didasarkan pada kebutuhan operasional, tingkat risiko, cakupan dukungan, dan total biaya selama periode yang dievaluasi.

Pastikan Aplikasi Tetap Siap Digunakan Setelah Go-Live

Investasi pengembangan software tidak berhenti ketika aplikasi diserahkan. Sistem yang digunakan untuk menjalankan proses bisnis perlu dipelihara agar tetap kompatibel, aman, dan mampu mengikuti perubahan kebutuhan perusahaan.

Melalui fase Maintenance dalam metodologi PADI-M, Dika Karya Tech menempatkan pemeliharaan sebagai bagian dari siklus hidup software, bukan sekadar pekerjaan tambahan setelah proyek selesai.

Kami mendorong setiap klien untuk menetapkan ruang lingkup maintenance, tanggung jawab teknis, mekanisme penanganan insiden, serta target layanan secara tertulis sebelum sistem digunakan dalam operasional.

Dengan perencanaan yang tepat, perusahaan dapat memahami biaya pemeliharaan, mengurangi ketidakpastian ketika terjadi gangguan, dan menjaga keberlanjutan sistem dalam jangka panjang.

Jangan hanya merencanakan bagaimana aplikasi dibangun. Rencanakan juga bagaimana aplikasi tersebut akan dikelola setelah digunakan.

Diskusikan kebutuhan maintenance dan SLA untuk aplikasi bisnis Anda bersama Dika Karya Tech.