Membuat SLA untuk Tim Data Satu Orang

SLA tim data satu orang adalah kesepakatan tertulis soal berapa lama tiap jenis permintaan data bakal dijawab dan diselesaikan. Isinya angka, bukan janji.

Kalau kamu satu-satunya orang yang ngerti SQL di kantor, kamu udah tau masalahnya. Permintaan datang dari lima arah. Semuanya ditandain urgent. Yang paling berisik yang dikerjain duluan.

SLA ngubah urutan itu dari siapa-paling-keras jadi apa-paling-berdampak. Dan yang lebih penting: kamu punya dokumen buat nunjukin kenapa permintaan seseorang belum kesentuh.

Di bawah ini aku pakai contoh dari log permintaan sebuah distributor FMCG di Bekasi. 214 permintaan masuk selama 6 bulan, dikerjain satu analis.

Apa itu SLA untuk tim data?

SLA (service level agreement) adalah dokumen yang nyebutin layanan apa yang kamu kasih, berapa lama waktu responsnya, dan apa yang di luar cakupan. Buat tim data, isinya biasanya tiga bagian: cara ngirim permintaan, tingkat prioritas dengan waktu tunggu masing-masing, dan daftar hal yang nggak kamu kerjain.

Konsepnya dipinjam dari tim IT support. Atlassian punya penjelasan resmi soal SLA di Jira Service Management yang bagus buat lihat strukturnya.

Bedanya buat tim data satu orang: kamu nggak punya backup. Jadi SLA kamu harus jujur soal kapasitas, bukan nyalin angka dari tim yang isinya delapan orang.

Kenapa tim data satu orang butuh SLA?

Aku ngitung ulang log 214 permintaan tadi. Hasilnya bikin kaget dua kali.

Pertama, 88 permintaan (41%) sebenernya minta angka yang sama dengan permintaan sebelumnya, cuma beda periode atau beda orang yang minta. Itu 88 kali ngerjain ulang hal yang udah pernah dikerjain.

Kedua, median waktu pengerjaan cuma 3,5 jam per permintaan. Tapi median waktu dari permintaan masuk sampai selesai: 6 hari kerja. Selisihnya bukan kerja. Itu antre, klarifikasi bolak-balik, dan permintaan yang kepotong permintaan lain.

Angka kedua itu yang bikin stakeholder ngerasa tim data lambat. Padahal kerjaannya cuma 3,5 jam.

SLA nutup selisih itu dengan dua cara. Klarifikasi dipindah ke depan lewat form. Dan antrean jadi transparan, jadi orang tau posisinya di nomor berapa.

Langkah 1: Bikin form intake yang wajib

Ini bagian yang paling nggak enak buat dijalanin, dan paling besar dampaknya.

Satu pintu masuk. Google Form, Notion form, atau channel khusus. Terserah, asal satu.

Enam pertanyaan yang aku pakai:

1. Pertanyaan bisnisnya apa? Bukan "minta data penjualan", tapi "produk mana yang stoknya nggak gerak lebih dari 60 hari".
2. Keputusan apa yang bakal diambil dari angka ini? Pertanyaan ini nyaring 20% permintaan yang cuma penasaran.
3. Kapan dibutuhin, dan kenapa tanggal itu? Alasannya wajib. "Rapat direksi Kamis" beda level sama "biar cepet aja".
4. Bentuk hasilnya apa? Angka di chat, file CSV, atau dashboard yang bisa dibuka sendiri.
5. Kalau telat sehari, apa yang rugi? Ini yang nentuin prioritas, bukan kata "urgent".
6. Udah pernah ada laporan mirip? Kasih link kalau ada.

Pertanyaan nomor 5 yang paling banyak nyaring. Dari 214 permintaan tadi, cuma 19 yang punya kerugian nyata kalau telat sehari.

Simpan semua submission-nya di satu spreadsheet. Ini yang nanti jadi bukti waktu kamu ngobrolin kapasitas sama atasan.

Langkah 2: Tentuin tiga tingkat prioritas

Tiga cukup. Lima terlalu ribet buat dijalanin sendirian.

Tingkat	Kriteria	Dijawab dalam	Selesai dalam
P1	Angka salah lagi dipakai buat keputusan, atau pipeline mati	2 jam kerja	Hari yang sama
P2	Ada deadline eksternal yang nyata (rapat, laporan ke klien, audit)	1 hari kerja	3 hari kerja
P3	Berguna, tapi nggak ada yang rugi kalau minggu depan	1 hari kerja	Masuk backlog, direview tiap Senin

Perhatiin kolom "dijawab" kepisah dari "selesai". Ini yang sering kelewat.

Balasan dalam 2 jam yang isinya "udah aku terima, masuk P3, target Rabu depan" nurunin tensi jauh lebih efektif daripada diem tiga hari lalu ngirim hasil sempurna. Orang nggak marah karena nunggu. Orang marah karena nggak tau lagi nunggu apa.

Satu aturan tambahan: yang nentuin tingkat prioritas kamu, bukan yang minta. Kalau semua orang boleh nandain P1, dalam dua minggu semuanya P1.

Langkah 3: Hitung kapasitas kamu beneran

SLA yang nggak dihitung dari kapasitas cuma daftar keinginan.

Mulai dari 40 jam seminggu, lalu potong:

Pos	Jam	Catatan
Rapat dan koordinasi	6	Standup, rapat divisi, 1-on-1
Laporan rutin	8	Refresh dashboard, laporan mingguan
Perbaikan dan cek kualitas data	5	Pipeline gagal, angka nggak cocok
Proyek roadmap	8	Dikunci, nggak boleh dipotong permintaan dadakan
Sisa buat permintaan ad-hoc	13	Ini angka SLA kamu

13 jam. Dengan median pengerjaan 3,5 jam per permintaan, kapasitas realistis kamu sekitar 3-4 permintaan baru per minggu.

Distributor tadi rata-rata nerima 8,9 permintaan per minggu. Selisihnya bukan masalah kemalasan. Itu masalah aritmatika.

Angka ini yang kamu bawa ke rapat. Bukan "aku kewalahan", tapi "kapasitas 4, masuk 9, jadi 5 permintaan tiap minggu numpuk".

Buat ngitung median waktu pengerjaan dari log kamu sendiri, pakai MEDIAN, bukan rata-rata. Satu proyek yang makan 40 jam bisa narik rata-ratanya jadi nggak masuk akal.

Hitung volume per kategori pakai COUNTIFS:

=COUNTIFS(log!$D$2:$D;"P2";log!$A$2:$A;">="&DATE(2025;11;1))

Langkah 4: Tulis apa yang nggak kamu kerjain

Bagian ini yang bikin SLA kamu punya gigi.

Daftar yang aku pakai:

• Permintaan yang masuk lewat chat pribadi tanpa form. Dijawab dengan link form, bukan dengan hasil.
• Permintaan buat besok yang masuk sore ini, kecuali P1.
• Ekspor data mentah tanpa tujuan yang jelas.
• Ngerapiin file Excel orang lain.
• Angka buat presentasi yang materinya belum jadi. Tunggu materinya jadi dulu, biar nggak ngitung tiga kali.

Poin terakhir itu nyelametin 11 jam kerja di bulan pertama distributor tadi nerapin SLA-nya.

Tulis juga apa yang jadi tanggung jawab peminta. Definisi metrik disepakati sebelum query jalan. Perubahan permintaan di tengah jalan berarti masuk antrean lagi dari belakang. Ini yang bikin scope creep berhenti tanpa kamu harus berdebat tiap kali.

Langkah 5: Bikin antreannya kelihatan

Satu halaman, bisa diakses semua orang, isinya tiga kolom: lagi dikerjain, antre minggu ini, backlog.

Update tiap Senin pagi. Lima menit.

Efeknya lebih besar dari yang aku kira. Waktu orang lihat permintaan mereka nomor 6 dari 11, mereka berhenti nanya "udah sampai mana?". Sebagian malah narik permintaannya sendiri setelah lihat antreannya.

Kalau kamu udah punya dashboard yang jalan, tempel ringkasan antreannya di situ. Nggak perlu tool baru.

Tambahin satu kolom kecil: berapa permintaan yang selesai minggu lalu. Ini bikin kerja kamu keliatan, dan bikin orang paham kenapa antreannya panjang.

Contoh kasus: distributor FMCG Bekasi, 3 bulan setelah SLA

Analis di sana nerapin lima langkah di atas mulai Agustus 2025. Perbandingan 3 bulan sebelum dan sesudah:

Ukuran	Sebelum	Sesudah
Permintaan masuk per minggu	8,9	5,2
Median waktu tunggu sampai selesai	6 hari	2,5 hari
Permintaan duplikat	41%	12%
Jam roadmap yang kepakai per minggu	1,5	7

Yang bikin volume turun dari 8,9 ke 5,2 bukan orang jadi males minta. Pertanyaan nomor 5 di form ("kalau telat sehari apa yang rugi?") bikin sebagian orang sadar sendiri permintaannya nggak penting.

Duplikat turun soalnya form-nya nampilin daftar laporan yang udah ada. Setengah dari duplikat selesai sebelum masuk antrean.

Dan 7 jam roadmap per minggu itu yang paling berharga. Di situ dashboard stok akhirnya kelar, yang lalu motong permintaan soal stok jadi hampir nol.

Kesalahan umum waktu bikin SLA sendirian

Janji terlalu cepat di awal. Semangat bikin orang nulis "semua permintaan selesai 24 jam". Tiga minggu kemudian meleset terus, dan SLA-nya nggak dipercaya lagi. Mulai dari angka yang kamu yakin bisa penuhi 90% waktu.

Nggak ngelog apa-apa. Tanpa catatan permintaan, kamu nggak punya bukti apa pun waktu diminta kerja lebih banyak. Log itu satu-satunya argumen yang kebal opini.

Ngerjain permintaan chat "cuma sebentar". Sekali dilanggar, formnya mati. Konsistensi lebih penting daripada aturannya sendiri.

SLA ditulis sendiri lalu diumumkan. Ajak minimal dua kepala divisi yang paling sering minta buat review draftnya. Orang lebih patuh ke aturan yang mereka ikut bikin.

Nggak pernah direview. Cek ulang tiap kuartal pakai data log. Kalau P2 meleset 30% dari waktu, angkanya yang salah, bukan kamu.

FAQ

Perlu izin atasan buat bikin SLA sendiri?

Bikin draftnya duluan tanpa izin, itu cuma dokumen. Yang butuh persetujuan adalah waktu tunggu di dalamnya, soalnya itu yang ngikat departemen lain. Bawa ke atasan sebagai usulan berbasis data antrean kamu, bukan sebagai keluhan. Biasanya lebih gampang disetujui kalau kamu tunjukin berapa jam kapasitas yang ada dan berapa jam permintaan yang masuk.

Gimana kalau ada yang nekat minta lewat WhatsApp terus?

Jawab ramah, lalu minta dia isi form. Jangan kerjain permintaannya sebelum formnya masuk, walaupun cuma lima menit. Kalau kamu kerjain sekali, form itu jadi opsional selamanya. Aku biasanya siapin satu balasan template dua kalimat plus link form biar nggak capek ngetik ulang.

Berapa lama waktu respons yang masuk akal buat satu orang?

Yang aku pakai: P1 dijawab dalam 2 jam kerja dan selesai hari itu juga, P2 dijawab 1 hari kerja dan selesai 3 hari, P3 masuk backlog dan direview tiap Senin. Sesuaikan sama jam kerja kamu. Jangan janjiin angka yang cuma bisa kamu penuhi kalau lembur, soalnya SLA yang sering meleset lebih buruk daripada nggak ada SLA.

Apa bedanya SLA sama roadmap data?

SLA ngatur permintaan yang masuk dan berapa lama dijawab. Roadmap ngatur proyek yang kamu rencanakan sendiri, misalnya bikin dashboard baru atau rapiin tabel. Keduanya rebutan jam yang sama. Makanya di SLA kamu perlu nyebut berapa persen waktu mingguan yang dikunci buat roadmap, biar nggak habis kemakan permintaan dadakan.

SLA-nya sering meleset. Harus gimana?

Cek dulu penyebabnya dari log permintaan. Kalau yang meleset cuma satu jenis permintaan, biasanya estimasi waktunya yang salah, jadi ubah kategorinya. Kalau melesetnya merata, berarti volume permintaan udah lewat kapasitas kamu. Itu bukan masalah disiplin, itu data buat minta tambahan orang atau ngurangin cakupan.

Mulai dari mana

Tiga hal yang paling ngaruh. Satu pintu masuk lewat form, tiga tingkat prioritas dengan waktu respons yang kepisah dari waktu selesai, dan angka kapasitas jam yang dihitung jujur.

Jangan tulis dokumen 10 halaman. Satu halaman yang dipatuhi kalahin sepuluh halaman yang nganggur di Drive.

Minggu ini, catat semua permintaan yang masuk beserta jam pengerjaannya. Dua minggu data aja udah cukup buat nyusun SLA versi pertama yang angkanya beneran, bukan tebakan.

Habis SLA-nya jalan, langkah berikutnya biasanya lebih berat: membangun budaya data di perusahaan yang belum siap.