Kemarin gw nge-audit checklist SOP internal buat Q3 di salah satu client tech agency. Hasilnya? Semua centang hijau. Tim sudah baca handbook, semua tanda tangan digital terverifikasi, bahkan ada presentasi PowerPoint ‘SOP Refresh’ yang dipakein coffee morning. Padahal dua minggu sebelumnya, project client utama macet total gara-gara nggak jelas siapa yang harus approve perubahan scope di tengah jalan.
Gw bingung. Kita habis keluarkan waktu 40 jam cuma buat memastikan tim udah baca dokumen yang sebenernya nggak mereka buka lagi sejak launch. Itu apa namanya kalau bukan vanity metric?
Yang ngeselin, kebanyakan founder dan ops leader di Indonesia masih terjebak mengukur efektivitas SOP melalui kepatuhan. Padalah, kepatuhan bukan indikator aliran kerja yang sehat. Kalau tim bener-bener nurut SOP tapi project tetap deadline miss, artinya SOP-nya cuma dekorasi kantor, bukan alat bantu kerja.
Kenapa audit mingguan malah ngebunuh fokus tim lo
Coba lo ingat ulang meeting review terakhir. Berapa menit yang habis buat ngecek ‘apakah semua milestone sudah dicatat di tracker?’ Berapa menit berikutnya buat narasi kenapa vendor delay padahal brief sudah clear sejak sprint awal?
Banyak tim mengira rutin audit itu disiplin. Padahal itu cuma ilusi kontrol. Ketika fokus kita ditarik ke paperwork alih-alih ke hambatan nyata, decision makers jadi lambat merespons. Yang terjadi? Task gantung numpuk. Review-an berputar tanpa action. Dan yang paling parah, senior staff mulai sotoy nge-blame junior karena ‘nggak baca SOP’ padahal SOP-nya sendiri ambigu soal chain of command.
Gw pribadi gak setuju kalau kita lanjutin ritual ini. Bukan karena dokumentasi nggak penting, tapi karena metrik kepatuhan itu dead lagging indicator. Ia baru ketahuan setelah proyek molor, bukan sebelum masalah lahir.
Pindah metrik: draf ‘decision friction’ daripada checklist kosong
Alih-alih ngecek apakah tim udah baca dokumen, mulai log decision friction setiap kali workflow macet. Definisi sederhananya: setiap titik di mana proses terhenti karena ambigu tanggung jawab, duplikasi approval, atau informasi yang belum masuk ke stakeholder yang butuh.
Di tiga agensi tech yang pernah gw konsultasikan, kita pakai template log sederhana. Setiap kali ada blockage, siapapun yang ngerasain friction wajib catat tiga hal:
- Titik berhenti: fitur mana / deliverable mana yang macet
- Penyebab utama: unclear ownership / menunggu approval / data tidak tersedia / scope creep
- Estimasi waktu hilang: jam berapa sampai jam berapa task frozen
Kita trace ulang 50 titik bottleneck selama empat sprint berturut-turut. Hasilnya cukup brutal: 60% langkah dalam proses kami ternyata redundan. Ada approval paralel untuk hal yang sama. Ada dua versi brief yang beredar karena komunikasi async nggak sinkron. Ada designer yang perlu menunggu sign-off product lead, padahal client sudah konfirmasi via chat grup sejak Senin sore.
Setelah poin-poin tadi diekstrak, kita hapus layer approval yang nggak value-add, satukan channel komunikasi utama, dan redefinisi RACI per kategori task. Gak perlu rewrite SOP ratusan halaman. Cukup edit tiga dokumen inti, lalu publish di workspace yang emang sering diakses tim.
Hasilnya? Decision latency rata-rata turun dari 14 jam menjadi 3,5 jam. Deliverable per sprint naik 22% tanpa menambah headcount. Bukan karena orang kerja lebih keras, tapi karena mereka nggak perlu antri buktiin bahwa mereka udah ‘patuh’.
Cara ngitung decision latency tanpa bikin PR-an baru
Sekarang soal angka yang beneran bisa dipertanggungjawabkan. Jangan pantau jumlah dokumen yang dibaca. Pantau ratio antara decision latency vs deliverables per sprint.
Cara menghitungnya gampang:
- Buka timeline sprint. Tandai semua task yang sempat stuck >2 jam.
- Catat selisih waktu dari pertama kali blockage muncul sampai approval/action keluar.
- Bagi total jam freeze dengan jumlah task yang berhasil diluncurkan di sprint tersebut.
Angka ini yang akan kasih lo gambaran jujur tentang kesehatan operasional. Kalau decision latency naik sementara deliverable stagnan, berarti ada rotasi approval yang terlalu kaku atau informasi yang bocor antar departemen. Lo langsung tau mau fokus perbaikan di mana, tanpa perlu nunggu laporan bulanan yang biasanya cuma berisi klaim ‘proses berjalan lancar’.
Gw coba pakai metrik ini di tim gw sendiri. Pertama kali diterapkan, hasilnya jelek banget. Tim mager nge-log friction karena mikir ini cuma tugas tambahan. Solusinya? Gw ubah jadi async micro-update di akhir standup. Gak perlu form panjang. Cukup satu baris: “Feature X nunggu confirm UI kit, delay estimasi 4 jam.” Selesai. Dalam dua pekan, kebiasaan ini kayak otomatis. Orang udah kepo liat dashboard internal kita, bukan karena dikontrol, tapi karena transparansi bikin mereka merasa punyaOwnership atas alur kerja sendiri.
Efisiensi operasional UKM: dari tracking workflow sampai auto-scale
Kalau lo ngelola UKM atau startup scale-up, ini dia bagian yang jarang dibicarakan secara terbuka: SOP yang sempurna di tahap 5 orang justru jadi jeritan saat tim melesat ke 30 orang. Banyak founder takut mengurangi struktur karena ngerasa bakal kacau balau. Padahal, struktur yang kaku tanpa feedback loop justru bikin birokrasi tumbuh tak terkendali.
Pengalaman gw di agensi menengah menunjukkan bahwa efisiensi operasional ukM bukan soal seberapa banyak aturan yang ditulis, tapi seberapa cepat sistem menyerap gesekan. Tracking workflow berbasis friction memberi lo early warning system. Lo nggak perlu nunggu audit kuartalan buat tau bahwa proses QA kamu nyangkut di handover karena file dikirim via email alias manual.
Di SatuTim kita pakai fitur Discussions buat async friction logging. Tim tinggal @channel, sebut titik macet, dan link ke ticket terkait. Nggak perlu pindah aplikasi. Data tersimpan terstruktur, bisa di-filter per sprint, dan langsung jadi bahan retro yang beneran actionable. Founder dan ops lead cuma perlu cek grafik decision latency mingguan, bukan nge-replace file Excel tiap Jumat sore.
Yang sering luput dari perhatian banyak pemimpin: efisiensi bukan tujuan, ia konsekuensi dari proses yang direstui oleh praktisi lapangan. Kalau tim lo yang sehari-hari eksekusi nggak diminta opininya soal friction, apapun SOP yang lo pasangin cuma akan jadi kertas pajangan.
Langkah gercep buat lo yang capek ngecek box-checking
Coba minggu ini: hentikan audit SOP mingguan. Ganti dengan 15 menit async friction review. Minta tiap lead submit satu poin friction terbesar di sprint lalu. Ekstrak pola. Hapus satu langkah redundan. Ukur decision latency di sprint berikutnya.
Lihat bedanya. Dari verifikasi kepatuhan ke pengurangan gesekan nyata. Dari daftar checklist kosong ke angka decision latency yang bisa ditelusuri asal-usulnya. Dari rapat panjang yang bikin mata melirik jam ke retro singkat yang langsung menghasilkan perubahan sistem.
Kalau lo penasaran gimana bentuk template log friction-nya, atau pengen tau gimana kita nyeting dashboard decision latency tanpa bikin tim mager nge-input data, komen saja di bawah. Gw share dokumen kosongnya atau kita bedah kasus spesifik di tim lo.
Pertanyaan gw buat lo: decision latency rata-rata di tim lo berapa jam per sprint, dan apakah lo berani menghapus satu lapisan approval minggu ini?