Kebanyakan review teknologi kuartalan yang pernah saya ikuti hanyalah teater dashboard: satu slide berisi persentase uptime dan jumlah tiket, semua orang mengangguk, rapat selesai, tidak ada yang berubah. Review teknologi kuartalan yang sesungguhnya tidak butuh dashboard. Yang dibutuhkan adalah satu jam, lima pertanyaan, dan kesediaan untuk mendengar jawaban jujur dari orang-orang yang benar-benar memakai sistem itu setiap hari.
Inti dari mereview Q1 bukan untuk membuktikan sistem Anda baik-baik saja. Tujuannya adalah menemukan satu hal yang diam-diam menghabiskan paling banyak jam kerja atau uang dalam tiga bulan terakhir, lalu memperbaikinya sebelum Q2 mengulang kesalahan yang sama. Itu butuh bicara langsung dengan staf, bukan sekadar membaca panel metrik.
Berikut agenda satu jam yang saya jalankan, dan lima metrik yang benar-benar menunjukkan apakah teknologi Anda membantu atau justru membebani.
Kenapa dashboard saja melewatkan cerita yang sebenarnya
Dashboard memberi tahu Anda bahwa sebuah sistem hidup 99.2% dari waktu operasional. Dashboard tidak memberi tahu Anda bahwa staf sudah terbiasa memasukkan ulang data secara manual ke spreadsheet setiap pagi karena sinkronisasi antar dua sistem gagal secara diam-diam. Uptime dan volume tiket adalah sinyal yang lambat dan sudah "dipoles". Biaya sesungguhnya justru ada pada workaround yang tidak pernah dicatat sebagai insiden karena orang-orang cuma diam-diam menyesuaikan diri.
Inilah kenapa review harus melibatkan percakapan, bukan sekadar menarik laporan. Tanyakan langsung ke tim Anda: "Apa yang sekarang kalian kerjakan secara manual, yang sebenarnya berharap bisa dikerjakan sistem?" Satu pertanyaan itu saja bisa mengungkap lebih banyak utang teknis nyata dibanding dashboard mana pun.
Agenda satu jam
- Menit 0-10: Apa yang rusak. Tarik daftar insiden. Bukan cuma kejadian "sistem down", tapi apa pun yang butuh perbaikan darurat, telepon tengah malam, atau permintaan maaf ke pelanggan.
- Menit 10-20: Apa yang jadi lebih lambat. Bandingkan cycle time untuk proses inti (order sampai pemenuhan, pengajuan sampai persetujuan, tiket sampai selesai) dengan kuartal sebelumnya. Melambat tanpa sebab yang jelas adalah indikator awal friksi yang menumpuk.
- Menit 20-35: Apa yang dikerjakan staf secara manual. Ini bagian percakapannya. Tanyakan ke dua atau tiga orang dari tim berbeda, apa yang mereka kerjakan dengan tangan yang seharusnya ditangani sistem. Catat setiap jawaban, sekecil apa pun.
- Menit 35-50: Satu perubahan yang paling menghemat jam kerja di Q2. Bukan wishlist. Satu perubahan, diranking berdasarkan jam yang dihemat dikalikan berapa banyak orang yang terdampak.
- Menit 50-60: Putuskan dan tugaskan. Pilih satu perubahan itu, tunjuk penanggung jawabnya, tetapkan tanggalnya. Kalau tidak ada yang ditugaskan, review ini cuma teater.
Lima metrik yang benar-benar penting
| Metrik | Apa yang diungkap | Cara mendapatkannya |
|---|---|---|
| Cycle time proses inti | Apakah sistem mempercepat atau justru memperlambat pekerjaan nyata | Bandingkan waktu awal-sampai-selesai untuk 1-2 alur kerja utama Anda, kuartal ke kuartal |
| Jumlah downtime dan insiden | Tren keandalan, bukan cuma rata-rata satu kuartal | Tarik dari log insiden, timbang berdasarkan jam operasional yang terdampak |
| Jumlah workaround manual | Utang teknis tersembunyi yang tidak muncul di dashboard mana pun | Tanyakan langsung ke staf, catat setiap jawaban |
| Tingkat kekambuhan tiket support | Apakah akar masalah benar-benar diperbaiki atau cuma ditambal | Lacak berapa banyak tiket yang merupakan pengulangan dari masalah sebelumnya |
| Biaya per transaksi atau per unit yang diproses | Apakah belanja teknologi benar-benar menurunkan biaya, bukan sekadar menambah tools | Total biaya sistem + tenaga kerja, dibagi volume, dilacak kuartal ke kuartal |
Kelima metrik ini memberi gambaran yang jauh lebih lengkap dibanding uptime dan jumlah tiket saja, karena keduanya menghubungkan performa teknologi langsung dengan hasil bisnis: kecepatan, keandalan, tenaga kerja tersembunyi, kegagalan berulang, dan biaya.
Contoh kasus singkat
Sebuah jaringan apotek yang saya review punya dashboard yang menunjukkan uptime sehat di sistem inventarisnya. Percakapan satu jam mengungkap bahwa tiga manajer cabang masih secara manual mencocokkan stok dengan catatan kertas setiap minggu, karena forecasting sistem sudah cukup sering salah sehingga tidak ada yang mempercayainya lagi. Itulah workaround yang tidak akan pernah terlihat di dashboard, dan itu menghabiskan lebih banyak jam kerja staf dibanding insiden apa pun yang tercatat pada kuartal itu. Untuk cerita bagaimana celah semacam ini ditutup lewat disiplin forecasting yang lebih baik, lihat A Pharmacy Chain Let Data Decide Its Reorders.
Mengubah review menjadi rencana kuartal berikutnya
Tahan godaan untuk keluar dari rapat ini dengan sepuluh action item. Pilih satu perubahan yang paling menghemat jam kerja di paling banyak orang, tunjuk satu penanggung jawab, dan tetapkan tanggal yang nyata. Kalau Anda konsisten menemukan lebih banyak temuan dibanding yang bisa Anda tindaklanjuti, itu sendiri adalah data yang berguna, itu menunjukkan ke mana seharusnya diarahkan target teknologi kuartal berikutnya. Saya pernah menulis soal kenapa tiga target lebih baik dibanding sepuluh di Set 3 Technology Goals for the New Year (Not 10), dan disiplin yang sama berlaku di sini: lebih sedikit, terdanai, selesai, mengalahkan daftar panjang yang tidak dimiliki siapa pun.
Kalau tim Anda tidak punya kapasitas internal untuk menjalankan review semacam ini secara objektif, mitra teknis dari luar bisa menjalankannya dengan cara yang menghindari bias "semuanya baik-baik saja" yang sering jadi default tim internal. Itu percakapan yang layak dilakukan sebelum berubah jadi pemadaman kebakaran di Q2, dan itu jenis keterlibatan yang saya jalani lewat partner.
Intinya
Anti-dashboard, pro-percakapan. Satu jam yang dihabiskan untuk menanyakan apa yang rusak, apa yang melambat, dan apa yang diam-diam dikerjakan staf secara manual, akan memberi tahu Anda lebih banyak dibanding satu kuartal penuh snapshot metrik. Pilih satu perubahan, tunjuk satu penanggung jawab, tetapkan satu tanggal, dan Anda baru saja mengubah review menjadi rencana yang nyata, bukan laporan status yang tidak ditindaklanjuti siapa pun.