Ketika sebuah masalah berhasil diidentifikasi, kita biasanya segera mencari solusi.
Proses diperbaiki.
SOP diubah.
Aplikasi baru dibuat.
Pekerjaan mulai diotomatisasi.
Dashboard diluncurkan.
Pelatihan diberikan.
Setelah semuanya selesai diterapkan, muncul perasaan bahwa masalah telah diselesaikan.
Namun ada satu pertanyaan penting yang sering terlupakan:
“Apakah kondisi setelah perubahan benar-benar menjadi lebih baik?”
Sebuah perubahan belum tentu merupakan perbaikan.
Kita dapat mengubah banyak hal tanpa menghasilkan dampak yang berarti. Bahkan dalam beberapa kasus, sebuah solusi berhasil memperbaiki satu indikator tetapi justru menciptakan masalah baru di bagian lain.
Karena itu keberhasilan seharusnya tidak hanya diukur dari apakah solusi sudah diterapkan.
Kita perlu membuktikan bahwa solusi tersebut benar-benar menghasilkan perubahan yang lebih baik.
Alurnya bukan:
Masalah → Solusi → Implementasi → Selesai
Tetapi:
Baseline → Action → Measure → Compare → Evidence → Improve
Di sinilah data analytics kembali memainkan peran penting.
Bukan hanya untuk menemukan masalah, tetapi juga untuk membuktikan apakah solusi benar-benar bekerja.
Implementasi Bukan Ukuran Keberhasilan
Bayangkan sebuah organisasi memiliki proses pelayanan yang lambat.
Kemudian dibuat aplikasi baru.
Aplikasinya selesai.
Server berjalan.
Pengguna sudah memiliki akun.
Pelatihan sudah dilakukan.
Apakah proyek tersebut berhasil?
Jika ukurannya hanya:
“Aplikasi berhasil dibuat dan digunakan.”
maka mungkin jawabannya ya.
Tetapi tujuan awalnya bukan sekadar membuat aplikasi.
Tujuannya adalah memperbaiki proses pelayanan.
Karena itu pertanyaan yang lebih penting adalah:
Apakah waktu pelayanan menjadi lebih cepat?
Apakah pekerjaan manual berkurang?
Apakah kesalahan input menurun?
Apakah pengguna lebih mudah menyelesaikan proses?
Apakah biaya operasional berkurang?
Apakah masalah yang sebelumnya terjadi sudah berkurang?
Di sinilah kita perlu membedakan antara output dan outcome.
Aplikasi adalah output.
Pelatihan adalah output.
Dashboard adalah output.
SOP baru adalah output.
Sedangkan peningkatan kecepatan, pengurangan kesalahan, efisiensi biaya, atau peningkatan kualitas layanan adalah outcome.
Solusi seharusnya dinilai dari outcome yang ingin dicapai, bukan hanya dari output yang berhasil dibuat.
Mulai dari Baseline
Jika kita ingin mengetahui apakah sesuatu menjadi lebih baik, kita perlu mengetahui kondisi sebelumnya.
Inilah fungsi baseline.
Misalnya sebelum sebuah perubahan dilakukan:
Rata-rata waktu proses: 5 hari.
Tingkat kesalahan: 8%.
Pekerjaan manual: 12 tahapan.
Keluhan pengguna: 150 per bulan.
Biaya operasional: Rp100 juta per periode.
Angka-angka tersebut menjadi titik pembanding.
Setelah solusi diterapkan, kita melakukan pengukuran kembali.
Misalnya:
Waktu proses turun menjadi 3 hari.
Tingkat kesalahan turun menjadi 4%.
Tahapan manual turun menjadi 7.
Keluhan turun menjadi 90 per bulan.
Sekarang kita memiliki evidence bahwa memang terjadi perubahan.
Tanpa baseline, kita hanya mengetahui kondisi setelah solusi diterapkan.
Kita tidak memiliki dasar yang kuat untuk mengatakan bahwa kondisi tersebut lebih baik daripada sebelumnya.
Tentukan Ukuran Keberhasilan Sebelum Bertindak
Kesalahan lain yang sering terjadi adalah menentukan ukuran keberhasilan setelah solusi selesai diterapkan.
Ini berbahaya.
Mengapa?
Karena kita dapat tergoda memilih indikator yang kebetulan menunjukkan hasil bagus.
Pendekatan yang lebih baik adalah menentukan sejak awal:
“Jika solusi ini berhasil, perubahan apa yang seharusnya terlihat?”
Misalnya sebuah perubahan ditujukan untuk mempercepat pelayanan.
Maka sebelum implementasi kita dapat menentukan:
Baseline: rata-rata 5 hari.
Target: maksimal 3 hari.
Measurement Period: tiga bulan setelah implementasi.
Guardrail: tingkat kesalahan tidak boleh meningkat.
Sekarang definisi keberhasilan menjadi lebih jelas.
Kita tidak hanya mengatakan:
“Semoga proses menjadi lebih baik.”
Kita sudah menentukan evidence apa yang nantinya akan digunakan untuk menilai keberhasilan.
Jangan Hanya Mengukur yang Mudah Diukur
Tidak semua indikator yang mudah dikumpulkan merupakan indikator yang paling penting.
Misalnya setelah sebuah sistem baru diluncurkan, laporan menunjukkan:
10.000 login.
50.000 klik.
20.000 transaksi sistem.
500 pengguna aktif.
Angka tersebut berguna.
Tetapi apakah sistem berhasil menyelesaikan masalah?
Belum tentu.
Banyaknya login menunjukkan penggunaan.
Banyaknya klik menunjukkan aktivitas.
Namun jika tujuan sistem adalah mengurangi waktu proses, kita tetap harus mengukur waktu proses.
Jika tujuannya mengurangi kesalahan, ukur error rate.
Jika tujuannya meningkatkan kepuasan pengguna, ukur pengalaman pengguna.
Jangan sampai kita memiliki banyak angka tetapi tidak memiliki angka yang benar-benar menjawab:
“Apakah masalah awal menjadi lebih baik?”
Aktivitas, Output, Outcome, dan Impact
Untuk memahami keberhasilan dengan lebih baik, kita dapat membedakan empat hal.
Activity
Apa yang kita lakukan?
Contoh:
pelatihan,
rapat,
pengembangan,
monitoring,
sosialisasi.
Output
Apa yang dihasilkan?
Contoh:
aplikasi,
dashboard,
SOP,
laporan,
fitur baru.
Outcome
Apa yang berubah setelah output digunakan?
Contoh:
waktu proses menurun,
kesalahan berkurang,
pekerjaan manual berkurang,
pengguna lebih mudah mendapatkan layanan.
Impact
Apa manfaat yang lebih luas atau jangka panjang?
Contoh:
efisiensi meningkat,
kualitas pelayanan membaik,
risiko berkurang,
kepercayaan pengguna meningkat,
sumber daya dapat digunakan lebih efektif.
Semakin jauh kita bergerak dari activity menuju impact, semakin dekat kita dengan pertanyaan:
“Apakah solusi ini benar-benar memberikan nilai?”
Before dan After Belum Selalu Cukup
Misalnya sebelum solusi diterapkan, waktu proses rata-rata adalah lima hari.
Setelah solusi diterapkan, turun menjadi tiga hari.
Apakah solusi tersebut pasti menyebabkan penurunan?
Belum tentu.
Mungkin pada periode setelah implementasi jumlah permintaan memang sedang turun.
Mungkin jumlah pegawai bertambah.
Mungkin ada perubahan kebijakan.
Mungkin jenis kasus yang diproses menjadi lebih sederhana.
Artinya perbandingan:
Before → After
adalah evidence penting, tetapi belum selalu cukup untuk membuktikan sebab-akibat.
Kita tetap perlu melihat konteks.
Semakin besar keputusan dan konsekuensinya, semakin kuat desain evaluasi yang dibutuhkan.
Dalam beberapa kasus kita dapat menggunakan:
periode pembanding,
kelompok pembanding,
pilot,
segmentasi,
analisis tren,
atau pendekatan statistik yang lebih kuat.
Tujuannya adalah memisahkan:
“Perubahan terjadi setelah solusi.”
dari:
“Perubahan terjadi karena solusi.”
Keduanya tidak selalu sama.
Perhatikan Faktor Lain yang Berubah
Dunia nyata tidak berhenti ketika kita melakukan eksperimen.
Banyak hal dapat berubah secara bersamaan.
Misalnya setelah sebuah aplikasi diluncurkan, produktivitas meningkat 20%.
Tetapi pada saat yang sama:
jumlah pegawai bertambah,
beban pekerjaan berkurang,
peraturan berubah,
atau dilakukan pelatihan intensif.
Sekarang kita tidak dapat langsung mengatakan bahwa seluruh peningkatan berasal dari aplikasi.
Inilah mengapa dokumentasi konteks sangat penting.
Ketika melakukan evaluasi, catat:
Apa yang kita ubah?
Apa lagi yang berubah pada periode yang sama?
Siapa yang terdampak?
Berapa lama pengukuran dilakukan?
Apakah terdapat kondisi khusus?
Semakin baik konteks dicatat, semakin kuat interpretasi hasilnya.
Jangan Hanya Melihat Rata-Rata
Sebuah solusi dapat membuat angka rata-rata terlihat lebih baik tetapi meninggalkan kelompok tertentu dalam kondisi buruk.
Misalnya rata-rata waktu pelayanan turun dari lima hari menjadi tiga hari.
Bagus.
Namun setelah data disegmentasi, ternyata:
80% kasus selesai dalam satu hari,
tetapi 20% kasus membutuhkan lebih dari sepuluh hari.
Rata-rata saja dapat menyembunyikan masalah tersebut.
Karena itu evaluasi dapat melihat:
median,
distribusi,
persentil,
nilai ekstrem,
segmentasi pengguna,
jenis layanan,
wilayah,
periode,
atau kategori lain yang relevan.
Pertanyaannya bukan hanya:
“Apakah rata-ratanya membaik?”
Tetapi juga:
“Siapa yang mendapatkan manfaat dan siapa yang belum?”
Jangan Memperbaiki Satu Angka dengan Merusak Angka Lain
Bayangkan target kita adalah mempercepat waktu pelayanan.
Setelah perubahan dilakukan:
Waktu pelayanan turun 40%.
Kelihatannya berhasil.
Tetapi tingkat kesalahan naik dua kali lipat.
Apakah itu perbaikan?
Belum tentu.
Kita mungkin hanya menukar satu masalah dengan masalah lain.
Karena itu setiap ukuran utama sebaiknya memiliki guardrail metrics.
Misalnya:
Primary Metric: waktu penyelesaian.
Guardrail: tingkat kesalahan tidak boleh meningkat.
Atau:
Primary Metric: biaya operasional turun.
Guardrail: kualitas layanan tidak boleh menurun.
Guardrail membantu memastikan bahwa optimasi terhadap satu indikator tidak merusak bagian lain.
Waspadai Goodhart's Law
Ada prinsip terkenal yang secara sederhana dapat dipahami sebagai:
Ketika sebuah ukuran berubah menjadi target, ukuran tersebut dapat kehilangan kemampuannya sebagai ukuran yang baik.
Misalnya target sebuah tim adalah menyelesaikan sebanyak mungkin tiket.
Apa yang mungkin terjadi?
Tim dapat memprioritaskan tiket yang mudah agar jumlah penyelesaian terlihat tinggi.
Angka meningkat.
Dashboard terlihat bagus.
Tetapi masalah kompleks justru menumpuk.
Secara angka, performa meningkat.
Secara realitas, belum tentu.
Karena itu jangan hanya bertanya:
“Apakah KPI tercapai?”
Tanyakan:
“Apakah kondisi yang sebenarnya ingin kita perbaiki memang menjadi lebih baik?”
Solusi Harus Memiliki Hipotesis
Sebelum melakukan perubahan, kita sebaiknya mengetahui mengapa kita percaya perubahan tersebut akan membantu.
Misalnya:
“Jika proses verifikasi otomatis diterapkan, maka waktu pemrosesan akan berkurang karena pekerjaan manual pada tahap tertentu dapat dikurangi.”
Ini adalah hipotesis.
Sekarang kita dapat mengujinya.
Apakah pekerjaan manual benar-benar berkurang?
Apakah waktu proses turun?
Apakah error meningkat?
Apakah ada jenis kasus yang tidak cocok dengan otomatisasi?
Hipotesis membuat solusi menjadi sesuatu yang dapat diuji, bukan sekadar sesuatu yang diyakini.
Gunakan Pilot Jika Risiko Masih Tinggi
Tidak semua solusi harus langsung diterapkan secara penuh.
Jika ketidakpastian masih tinggi, lakukan pilot.
Misalnya perubahan diterapkan terlebih dahulu pada:
satu unit,
satu kategori layanan,
sebagian pengguna,
atau periode tertentu.
Kemudian ukur hasilnya.
Pendekatannya:
Hypothesis → Pilot → Measure → Evidence → Decide
Jika hasilnya baik, solusi dapat diperluas.
Jika hasilnya buruk, kita dapat memperbaikinya dengan dampak yang lebih kecil.
Pilot memberikan ruang untuk belajar sebelum keputusan diperbesar.
Ukur dalam Periode yang Tepat
Mengukur terlalu cepat juga dapat menghasilkan kesimpulan yang salah.
Misalnya sistem baru diluncurkan hari Senin.
Hari Jumat kita mengukur produktivitas.
Ternyata turun.
Apakah sistem gagal?
Belum tentu.
Pengguna mungkin masih beradaptasi.
Ada learning curve.
Data mungkin belum stabil.
Sebaliknya, menunggu terlalu lama juga dapat membuat masalah terus berjalan.
Karena itu tentukan measurement window yang masuk akal.
Beberapa indikator dapat terlihat dalam hitungan hari.
Yang lain membutuhkan minggu atau bulan.
Tidak ada satu periode yang cocok untuk semua perubahan.
Bedakan Signal dari Noise
Setelah perubahan dilakukan, angka hampir selalu bergerak.
Hari ini naik.
Besok turun.
Minggu berikutnya naik lagi.
Tidak setiap perubahan kecil memiliki makna.
Kita perlu membedakan antara:
signal
dan
noise.
Jika sebuah indikator biasanya berfluktuasi antara 70–75, kemudian setelah perubahan menjadi 74, belum tentu ada dampak nyata.
Tetapi jika selama beberapa periode stabil di 85–90, kita memiliki evidence yang lebih kuat.
Dalam analisis yang lebih matang, kita dapat menggunakan confidence interval, hypothesis testing, effect size, control chart, atau metode statistik lain untuk membantu menilai apakah perubahan cukup berarti.
Tujuannya bukan membuat analisis menjadi rumit.
Tujuannya adalah mencegah kita merayakan fluktuasi biasa sebagai keberhasilan.
Statistical Significance Belum Tentu Practical Significance
Dengan data yang sangat besar, perubahan kecil dapat terlihat signifikan secara statistik.
Misalnya sebuah metode menunjukkan bahwa waktu proses turun rata-rata 0,3%.
Secara statistik mungkin signifikan.
Tetapi apakah 0,3% memiliki dampak nyata terhadap pengguna atau organisasi?
Belum tentu.
Karena itu kita perlu membedakan:
Statistical Significance
dan
Practical Significance.
Pertanyaannya bukan hanya:
“Apakah perubahan ini nyata secara statistik?”
Tetapi juga:
“Apakah perubahan ini cukup besar untuk berarti?”
Effect size dan konteks bisnis atau operasional menjadi penting.
Dengarkan Data dan Pengguna
Tidak semua dampak mudah ditangkap melalui angka.
Misalnya sistem baru membuat proses secara teknis lebih cepat.
Tetapi pengguna merasa alurnya jauh lebih membingungkan.
Atau sistem mengurangi pekerjaan manual pada satu bagian tetapi memindahkan beban ke bagian lain.
Data kuantitatif dapat mengatakan:
“Waktu turun 20%.”
Wawancara pengguna mungkin mengatakan:
“Proses sekarang lebih sulit dipahami.”
Keduanya adalah evidence.
Karena itu evaluasi yang baik dapat menggabungkan:
Quantitative Evidence
dan
Qualitative Evidence.
Angka membantu mengukur apa yang berubah.
Manusia membantu menjelaskan bagaimana perubahan tersebut dirasakan dan mengapa hal itu terjadi.
Jangan Takut Mengakui Solusi Tidak Berhasil
Ini bagian yang sulit.
Kita sudah menghabiskan waktu.
Tenaga.
Anggaran.
Mungkin reputasi.
Kemudian evidence menunjukkan bahwa solusi tidak menghasilkan dampak seperti yang diharapkan.
Ada kecenderungan untuk mempertahankannya.
Mencari indikator lain.
Memperpanjang waktu.
Mengatakan pengguna belum siap.
Namun problem solving yang matang membutuhkan keberanian untuk mengatakan:
“Hipotesis kita tidak terbukti.”
Itu bukan selalu kegagalan.
Jika proses evaluasinya baik, kita mendapatkan evidence baru.
Kita sekarang mengetahui bahwa pendekatan tersebut tidak memberikan dampak yang diharapkan.
Evidence tersebut dapat digunakan untuk menentukan solusi berikutnya.
Keputusan Setelah Evaluasi Tidak Selalu “Lanjut”
Setelah dampak diukur, terdapat beberapa kemungkinan keputusan.
Keep
Solusi bekerja. Pertahankan.
Expand
Solusi bekerja dan layak diperluas.
Adjust
Ada manfaat, tetapi perlu perbaikan.
Investigate
Hasil belum cukup jelas. Kumpulkan evidence tambahan.
Stop
Solusi tidak memberikan manfaat yang sebanding dengan biaya atau risikonya.
Kemampuan menghentikan solusi yang tidak efektif sama pentingnya dengan kemampuan membuat solusi baru.
Karena sumber daya yang terus digunakan pada solusi yang tidak bekerja adalah sumber daya yang tidak dapat digunakan untuk perbaikan lain.
Evidence Baru Boleh Mengubah Keputusan Lama
Keputusan dibuat berdasarkan evidence yang tersedia pada saat itu.
Setelah solusi berjalan, kita memperoleh evidence baru.
Mungkin asumsi awal ternyata benar.
Mungkin sebagian benar.
Mungkin sepenuhnya salah.
Tidak masalah.
Yang penting adalah kita bersedia memperbarui keputusan.
Evidence → Decision → Action → New Evidence → Better Decision
Inilah feedback loop yang membuat sistem terus belajar.
Perbaikan bukan satu kejadian.
Perbaikan adalah proses.
Baseline → Action → Measure → Compare → Evidence → Improve
Kita dapat menggunakan kerangka sederhana untuk mengevaluasi solusi.
Baseline
Pahami kondisi sebelum perubahan.
Action
Terapkan solusi dengan tujuan dan hipotesis yang jelas.
Measure
Kumpulkan indikator setelah perubahan.
Compare
Bandingkan dengan baseline, target, kelompok, atau periode yang relevan.
Evidence
Evaluasi apakah perubahan cukup kuat untuk dikaitkan dengan solusi dan apakah terdapat efek samping.
Improve
Pertahankan, perluas, sesuaikan, atau hentikan berdasarkan evidence.
Dengan cara ini kita tidak hanya mengatakan:
“Sudah dilakukan.”
Kita dapat mengatakan:
“Sudah dilakukan, diukur, dan evidence menunjukkan dampaknya.”
Understand → Evidence → Analyze → Solve → Improve
Prinsip yang sama sesuai dengan Thinking DNA ArrezaMP.
Understand — pahami masalah dan outcome yang sebenarnya ingin dicapai.
Evidence — bangun baseline dan tentukan indikator yang relevan.
Analyze — pahami penyebab, konteks, risiko, dan alternatif.
Solve — terapkan solusi yang memiliki hipotesis dan ukuran keberhasilan yang jelas.
Improve — ukur hasil, bandingkan dengan baseline, pelajari evidence baru, lalu perbaiki kembali.
Dengan pola tersebut, problem solving tidak berhenti ketika solusi diterapkan.
Justru setelah implementasi kita mulai menjawab pertanyaan yang paling penting:
“Apakah solusi ini benar-benar bekerja?”
Kesimpulan
Perubahan mudah dilakukan.
Perbaikan harus dibuktikan.
Aplikasi baru belum tentu memperbaiki layanan.
SOP baru belum tentu memperbaiki proses.
Otomatisasi belum tentu meningkatkan efisiensi.
Pelatihan belum tentu meningkatkan kompetensi.
Dashboard baru belum tentu menghasilkan keputusan yang lebih baik.
Semua itu adalah intervensi.
Apakah intervensi tersebut berhasil harus dibuktikan melalui evidence.
Mulailah dari baseline.
Tentukan outcome yang ingin dicapai.
Tetapkan ukuran keberhasilan sebelum bertindak.
Lakukan perubahan.
Ukur hasilnya.
Bandingkan.
Periksa efek samping.
Dengarkan pengguna.
Kemudian tentukan apakah solusi harus dipertahankan, diperluas, diperbaiki, atau dihentikan.
Karena tujuan problem solving bukan sekadar membuat sesuatu berubah.
Tujuannya adalah memastikan perubahan tersebut menghasilkan kondisi yang lebih baik daripada sebelumnya.
Baseline → Action → Measure → Compare → Evidence → Improve
Jangan hanya bertanya:
“Apakah solusinya sudah diterapkan?”
Tanyakan pertanyaan yang lebih penting:
“Evidence apa yang membuktikan bahwa setelah solusi diterapkan, keadaan benar-benar menjadi lebih baik?”
Karena pada akhirnya:
Perubahan adalah aktivitas.
Perbaikan adalah perubahan yang dapat dibuktikan dampaknya.
ArrezaMP — Data Analytics • Problem Solving • Digital Solutions
0 Komentar