Dalam memilih penyedia managed service, perhatikan empat hal: angka uptime beserta cara pengukurannya, waktu respons untuk tiap tingkat keparahan, jalur eskalasi yang jelas, dan ketentuan serah terima ketika kerja sama berakhir. Angka uptime tanpa definisi dan tanpa konsekuensi tidak berarti apa-apa.
Hampir semua penyedia menjanjikan uptime 99,9% dan dukungan 24/7. Karena hampir semua mengatakannya, kedua angka itu justru menjadi pembeda yang paling lemah.
Yang benar-benar membedakan ada pada detail di baliknya: bagaimana uptime dihitung, apa yang terjadi bila target tidak tercapai, dan siapa yang bisa dihubungi ketika masalah tidak juga selesai.
Apa itu SLA layanan IT dan apa yang seharusnya ada di dalamnya
Pertanyaan apa itu SLA layanan IT paling mudah dijawab begini: ia dokumen yang mengubah janji menjadi angka beserta konsekuensinya. Tanpa angka, ia hanya pernyataan niat; tanpa konsekuensi, angkanya tidak berarti apa-apa.
SLA yang layak memuat setidaknya empat hal. Definisi apa yang dihitung sebagai gangguan — dan apa yang dikecualikan. Angka ketersediaan beserta cara pengukurannya. Waktu tanggap per tingkat keparahan. Dan apa yang terjadi bila target tidak terpenuhi.
Bagian pengecualian justru yang paling perlu dibaca teliti. Pemeliharaan terjadwal biasanya dikecualikan, dan itu wajar. Tetapi kalau pengecualiannya melebar sampai mencakup gangguan penyedia hulu dan masalah jaringan, angka ketersediaan di halaman depan kehilangan makna.
Standar uptime 99.9 persen dan artinya dalam menit
Standar uptime 99.9 persen terdengar hampir sempurna, tetapi diterjemahkan menjadi waktu ia berarti sekitar 43 menit gangguan per bulan. Untuk situs profil perusahaan, itu tidak terasa. Untuk sistem pemesanan pada jam sibuk, 43 menit bisa berarti kerugian yang nyata.
Naik satu tingkat ke 99,99 persen memangkasnya menjadi sekitar empat menit per bulan — tetapi biayanya berlipat, karena menuntut infrastruktur cadangan yang selalu menyala dan tim yang benar-benar siaga. Menuntut angka itu untuk sistem yang tidak membutuhkannya hanya menambah biaya.
Yang lebih menentukan daripada angkanya adalah cara pengukurannya. Ketersediaan yang dihitung dari sisi perangkat keras hampir selalu terlihat bagus. Yang relevan bagi Anda adalah apakah aplikasinya bisa dipakai pengguna — diukur dari luar jaringan, bukan dari dalam.
Waktu respons support dan bedanya dengan waktu penyelesaian
Banyak kontrak hanya menjamin waktu respons support — berapa lama sampai pesan Anda dibalas. Itu bukan hal yang sama dengan berapa lama masalahnya selesai, dan perbedaan ini sering baru disadari saat sedang menghadapi gangguan.
SLA yang baik membedakan tingkat keparahan dengan definisi yang jelas. Layanan berhenti total tidak boleh diperlakukan sama dengan permintaan menambah akun pengguna, dan masing-masing punya target waktu sendiri — untuk respons maupun untuk penyelesaian atau setidaknya solusi sementara.
Tanyakan juga jalur eskalasinya: kalau setelah dua jam belum ada kemajuan, siapa yang bisa dihubungi berikutnya. Vendor yang tidak bisa menjawab pertanyaan ini biasanya hanya punya satu orang yang mengerjakan semuanya.
Tanda vendor IT buruk yang bisa dikenali sejak awal
Beberapa tanda vendor IT buruk sudah terlihat sebelum kontrak ditandatangani, dan semuanya layak dijadikan alasan berhenti melangkah:
- Meminta kredensial administrator utama untuk dipakai bersama, bukan akun terpisah dengan jejak audit.
- Tidak bersedia menyerahkan dokumentasi, sehingga Anda bergantung sepenuhnya pada mereka.
- Membuat akun cloud atas nama mereka sendiri, bukan atas nama perusahaan Anda.
- Tidak punya contoh laporan bulanan yang bisa ditunjukkan.
- Tidak pernah menguji pemulihan cadangan, atau tidak bisa menunjukkan catatan hasilnya.
- Ketentuan penghentian kerja sama tidak mengatur proses serah terima.
- Menyanggupi semua permintaan tanpa satu pun catatan keberatan — biasanya tanda belum memahami masalahnya.
Pertanyaan yang layak diajukan sebelum tanda tangan
Jawaban atas beberapa pertanyaan berikut akan cepat memisahkan penyedia yang serius dari yang sekadar menjual nama. Semuanya wajar ditanyakan, dan penolakan menjawab salah satunya sudah merupakan jawaban tersendiri.
- Siapa yang menangani gangguan pada pukul dua dini hari, dan bagaimana cara menghubunginya?
- Bisakah kami melihat contoh laporan bulanan yang biasa Anda kirimkan?
- Bagaimana proses serah terima bila kerja sama berakhir, dan berapa lama prosesnya?
- Seberapa sering uji pemulihan cadangan dijalankan, dan apakah hasilnya dilaporkan?
- Apa yang termasuk dan apa yang di luar lingkup layanan bulanan?
- Berapa orang yang akan mengenal lingkungan kami, bukan hanya satu orang?
Menilai kecocokan tanpa berkomitmen panjang
Kontrak panjang di awal jarang menguntungkan kedua pihak. Lebih baik memulai dari satu pekerjaan berbatas jelas — audit infrastruktur, misalnya — untuk menilai cara kerja dan kualitas komunikasinya.
Dari satu pekerjaan kecil itu sudah banyak yang bisa dinilai: apakah temuan disampaikan apa adanya termasuk yang tidak menyenangkan, apakah laporannya bisa dipahami tanpa penjelasan lisan, dan apakah mereka bersedia mengatakan bahwa sesuatu tidak perlu dikerjakan meski itu berarti nilai proyeknya lebih kecil.
Yang terakhir itu penanda paling kuat. Vendor yang menyanggupi semua permintaan tanpa satu pun catatan keberatan biasanya belum benar-benar memahami masalahnya.
Cara memulai tanpa memindahkan semuanya sekaligus
Memulai managed cloud tidak harus berarti memindahkan seluruh sistem atau menyerahkan akses tanpa batas. Tahap awal yang sehat biasanya berupa inventaris aset, peninjauan akun dan hak akses, pemasangan pemantauan, lalu perbaikan satu atau dua risiko yang paling mendesak. Dari sini, kedua pihak mendapat gambaran nyata tentang lingkungan dan cara kerja yang cocok.
Setelah fondasi itu rapi, prioritas berikutnya dapat disusun berdasarkan dampak bisnis: pemulihan aplikasi transaksi, biaya lingkungan non-produksi, atau proses rilis yang masih manual. Pendekatan bertahap membuat perusahaan tetap memegang kendali atas perubahan, sementara manfaat operasional mulai terasa tanpa menunggu proyek besar selesai seluruhnya.
Buat scorecard sebelum membandingkan penawaran
Harga bulanan mudah dibandingkan, tetapi bukan itu yang paling menentukan hasil kerja sama. Buat scorecard sederhana sebelum bertemu vendor agar semua penawaran dinilai dengan ukuran yang sama. Beri bobot lebih besar pada risiko yang paling mahal bagi bisnis Anda, bukan pada daftar fitur yang paling panjang.
Nilai setiap kandidat pada kepemilikan akun dan dokumentasi, cakupan jam siaga, kejelasan prioritas insiden, bukti uji pemulihan cadangan, jalur eskalasi, serta cara laporan disampaikan. Tambahkan satu kriteria nonteknis: apakah mereka mau menjelaskan batas layanan dengan bahasa yang bisa dipahami pengambil keputusan.
Minta jawabannya tertulis dan kaitkan dengan kondisi yang nyata, misalnya satu aplikasi berhenti menerima transaksi atau tagihan cloud melonjak. Jawaban terhadap skenario seperti ini jauh lebih informatif daripada presentasi umum. Vendor yang baik akan bertanya balik tentang dampak bisnis, ketergantungan aplikasi, dan batas risiko yang dapat Anda terima.
Setelah dua atau tiga kandidat dinilai, periksa selisihnya bersama orang yang akan bekerja langsung dengan mereka. Penawaran termurah bisa tetap masuk akal bila lingkupnya memang kecil; yang berbahaya adalah menganggap dua harga setara ketika satu pihak tidak memasukkan pemantauan, dokumentasi, atau pemulihan ke dalam layanan.
Scorecard tidak menggantikan percakapan, tetapi mencegah keputusan kembali ke kesan presentasi. Simpan hasilnya sebagai lampiran keputusan pengadaan. Enam bulan kemudian, Anda dapat meninjau apakah janji yang dinilai paling penting benar-benar dipenuhi dan memakai data itu untuk memperbaiki lingkup kerja atau memilih arah lain. Tinjauan ini juga memberi dasar yang adil untuk memperpanjang, memperkecil, atau menghentikan kerja sama tanpa mengandalkan ingatan atau keluhan sesaat. Dengan catatan yang sama, diskusi evaluasi menjadi keputusan bisnis yang tenang, bukan negosiasi berdasarkan persepsi masing-masing pihak.
Jadwal evaluasi ini sebaiknya sudah ditetapkan sejak awal, lengkap dengan orang yang bertanggung jawab meninjau hasilnya.