Ketika sebuah masalah muncul, respons paling alami adalah ingin segera memperbaikinya.
Sistem lambat? Tambah kapasitas.
Pekerjaan terlambat? Tambah orang.
Data sering salah? Periksa kembali secara manual.
Pengguna sering mengeluh? Buat aplikasi baru.
Pendapatan turun? Tingkatkan promosi.
Tindakan seperti ini terlihat logis karena langsung merespons sesuatu yang terlihat. Bahkan dalam beberapa kondisi, tindakan tersebut memang dapat membantu.
Namun ada pertanyaan yang sering terlupakan:
Apakah kita sedang menyelesaikan masalah sebenarnya, atau hanya memperbaiki gejalanya?
Gejala adalah sesuatu yang terlihat di permukaan. Akar masalah adalah kondisi yang menyebabkan gejala tersebut terus muncul.
Jika akar masalah tidak ditemukan, perbaikan dapat memberikan hasil sementara. Beberapa minggu atau beberapa bulan kemudian, masalah yang sama muncul kembali—kadang dalam bentuk yang berbeda.
Karena itu, salah satu kemampuan terpenting dalam problem solving bukan sekadar menemukan solusi dengan cepat, tetapi memastikan kita sedang menyelesaikan masalah yang benar.
Gejala dan Akar Masalah Adalah Dua Hal yang Berbeda
Bayangkan sebuah proses administrasi selalu terlambat.
Gejalanya mudah terlihat:
pekerjaan tidak selesai tepat waktu.
Solusi pertama mungkin menambah pegawai.
Namun setelah pegawai ditambah, keterlambatan masih terjadi.
Kemudian dibuat reminder otomatis. Ada sedikit perbaikan, tetapi masalah belum hilang.
Setelah proses diperiksa lebih dalam, ternyata sebuah dokumen harus melewati terlalu banyak tahapan verifikasi. Pada salah satu tahap, dokumen sering menunggu beberapa hari sebelum dapat diteruskan.
Sekarang kita mulai melihat perbedaannya.
Gejala: pekerjaan terlambat.
Dugaan awal: kekurangan orang.
Akar masalah: bottleneck pada proses verifikasi.
Jika kita hanya memperbaiki gejala, organisasi mungkin terus menambah sumber daya tanpa pernah menghilangkan penyebab keterlambatan.
Solusi Cepat Bisa Menciptakan Masalah Baru
Ada tekanan untuk menyelesaikan masalah secepat mungkin, terutama ketika masalah sudah mengganggu pekerjaan.
Namun kecepatan tanpa pemahaman dapat menghasilkan solution jumping: langsung memilih solusi sebelum masalah benar-benar dipahami.
Misalnya sebuah proses dianggap terlalu lambat.
Kemudian muncul keputusan:
“Kita buat aplikasi saja.”
Aplikasi selesai dibuat.
Tetapi ternyata proses bisnis di belakangnya tetap memiliki tahapan yang terlalu panjang.
Hasilnya?
Proses yang sebelumnya lambat secara manual sekarang menjadi proses digital yang tetap lambat.
Teknologi memang berubah, tetapi akar masalahnya tidak.
Inilah alasan Digital Solutions tidak seharusnya dimulai dari teknologi.
Pertanyaan pertama bukan:
“Aplikasi apa yang harus kita buat?”
Tetapi:
“Masalah apa yang sebenarnya ingin kita selesaikan?”
Jangan Berhenti pada Penyebab Pertama
Ketika menemukan sebuah penyebab, kita juga tidak boleh langsung menganggapnya sebagai akar masalah.
Misalnya:
Masalah: laporan sering terlambat.
Mengapa?
Karena data terlambat dikumpulkan.
Mengapa data terlambat dikumpulkan?
Karena beberapa unit terlambat mengirimkan data.
Mengapa unit terlambat?
Karena data harus direkap secara manual.
Mengapa masih direkap manual?
Karena informasi berasal dari beberapa sumber dengan format berbeda.
Sekarang masalahnya terlihat jauh lebih jelas.
Jika kita berhenti pada jawaban pertama, solusi mungkin hanya berupa:
“Kirim reminder lebih sering.”
Tetapi setelah menggali lebih dalam, solusi yang lebih tepat mungkin berupa standardisasi data, integrasi sumber informasi, atau penyederhanaan proses pengumpulan.
Setiap pertanyaan “mengapa?” membawa kita satu lapisan lebih dalam.
Gunakan Evidence, Bukan Dugaan
Root cause analysis mudah berubah menjadi diskusi opini.
Satu orang mengatakan penyebabnya A.
Orang lain yakin penyebabnya B.
Yang lain mengatakan masalahnya C.
Tanpa evidence, diskusi dapat berakhir pada siapa yang paling senior, paling percaya diri, atau paling meyakinkan.
Data membantu mengubah diskusi tersebut.
Jika sebuah proses terlambat, kita dapat memeriksa:
Berapa rata-rata waktu setiap tahap?
Di tahap mana waktu tunggu paling panjang?
Berapa banyak pekerjaan yang tertahan?
Apakah keterlambatan terjadi pada semua kasus atau hanya kategori tertentu?
Kapan masalah mulai muncul?
Apakah ada perubahan proses sebelum masalah terjadi?
Sekarang pembahasan bergerak dari:
“Menurut saya penyebabnya ini.”
menjadi:
“Evidence menunjukkan sebagian besar keterlambatan terjadi pada tahap ini.”
Perubahan sederhana tersebut dapat meningkatkan kualitas keputusan secara signifikan.
Data Analytics Membantu Melihat Pola di Balik Gejala
Dalam dataset besar, akar masalah tidak selalu mudah terlihat.
Bayangkan total biaya operasional meningkat 25%.
Kenaikan tersebut adalah gejala.
Kita kemudian memecah data berdasarkan kategori.
Ternyata 70% kenaikan berasal dari dua kategori tertentu.
Kemudian data dipecah berdasarkan unit.
Sebagian besar kenaikan ternyata terkonsentrasi pada tiga unit.
Setelah dibandingkan berdasarkan periode, perubahan baru mulai terlihat sejak empat bulan terakhir.
Sekarang ruang masalah semakin kecil.
Proses analisis bergerak dari:
Total → Kategori → Unit → Periode → Transaksi → Evidence
Data analytics membantu kita melakukan sesuatu yang sulit dilakukan hanya dengan melihat angka agregat: mempersempit ruang pencarian penyebab.
Namun analytics tetap tidak otomatis menentukan akar masalah.
Ia membantu menunjukkan ke mana kita perlu melihat lebih dalam.
Korelasi Belum Tentu Akar Masalah
Ada jebakan penting ketika menggunakan data.
Dua hal dapat terjadi secara bersamaan tanpa salah satunya menyebabkan yang lain.
Misalnya setelah sebuah sistem baru digunakan, jumlah keluhan meningkat.
Apakah sistem baru menyebabkan lebih banyak masalah?
Mungkin.
Tetapi mungkin juga kanal pengaduan menjadi lebih mudah digunakan sehingga lebih banyak keluhan tercatat.
Atau pengguna sedang berada pada masa adaptasi.
Atau terdapat perubahan proses lain pada periode yang sama.
Karena itu ketika analytics menemukan hubungan, jangan langsung mengubahnya menjadi kesimpulan sebab-akibat.
Gunakan hubungan tersebut sebagai hipotesis yang perlu diverifikasi.
Pattern → Question → Evidence → Verification → Conclusion
Bukan:
Pattern → Assumption → Conclusion
Bedakan Root Cause dengan Contributing Factor
Masalah kompleks sering tidak memiliki satu penyebab tunggal.
Sebuah proyek terlambat mungkin dipengaruhi oleh spesifikasi yang sering berubah, proses persetujuan yang panjang, keterbatasan sumber daya, komunikasi yang buruk, dan ketergantungan pada pihak lain.
Mencari satu orang atau satu faktor untuk dijadikan penyebab utama justru dapat menyederhanakan masalah secara berlebihan.
Karena itu selain mencari root cause, kita juga perlu mengenali contributing factors.
Pertanyaannya bukan hanya:
“Apa penyebab masalah ini?”
Tetapi juga:
“Faktor apa saja yang membuat masalah ini dapat terjadi atau menjadi lebih buruk?”
Dengan memahami struktur penyebab, solusi dapat dibuat lebih komprehensif.
Gunakan 5 Whys, tetapi Jangan Secara Mekanis
Salah satu metode sederhana untuk mencari akar masalah adalah 5 Whys.
Konsepnya bukan bahwa kita harus selalu bertanya “mengapa” tepat lima kali.
Tujuannya adalah mencegah kita berhenti terlalu cepat pada penjelasan permukaan.
Contohnya:
Mengapa pekerjaan terlambat?
Karena dokumen terlambat diproses.
Mengapa dokumen terlambat diproses?
Karena sering dikembalikan untuk diperbaiki.
Mengapa sering dikembalikan?
Karena informasi yang dikirim tidak lengkap.
Mengapa informasi tidak lengkap?
Karena setiap unit menggunakan format yang berbeda.
Mengapa formatnya berbeda?
Karena belum terdapat standar input yang sama.
Sekarang solusi mulai berubah.
Awalnya kita mungkin ingin mempercepat petugas.
Setelah root cause ditemukan, solusi yang lebih relevan mungkin standardisasi format dan validasi input sejak awal.
Root Cause Analysis Bukan Mencari Siapa yang Salah
Ini sangat penting.
Ketika root cause analysis berubah menjadi proses mencari orang yang harus disalahkan, orang akan mulai defensif.
Informasi dapat ditahan.
Kesalahan disembunyikan.
Diskusi berubah dari perbaikan sistem menjadi perlindungan diri.
Pendekatan yang lebih sehat adalah melihat bagaimana sistem memungkinkan masalah terjadi.
Jika seseorang salah memasukkan data, pertanyaannya tidak berhenti pada:
“Siapa yang salah input?”
Tanyakan juga:
Mengapa sistem menerima format yang salah?
Apakah ada validasi?
Apakah instruksinya jelas?
Apakah pengguna mendapatkan feedback?
Apakah proses memungkinkan kesalahan yang sama terjadi berulang kali?
Tujuannya bukan menghilangkan tanggung jawab manusia.
Tujuannya adalah memastikan bahwa perbaikan tidak berhenti pada manusianya ketika sistemnya tetap menghasilkan risiko yang sama.
Jangan Otomatis Menggunakan Teknologi sebagai Solusi
Di era AI dan digitalisasi, teknologi sangat mudah menjadi jawaban pertama.
Masalah muncul?
Buat dashboard.
Buat aplikasi.
Gunakan AI.
Tambahkan automation.
Integrasikan sistem.
Semua itu dapat menjadi solusi yang tepat—jika masalahnya memang membutuhkan teknologi.
Tetapi terkadang solusi terbaik jauh lebih sederhana.
Menghapus satu tahapan persetujuan.
Memperjelas SOP.
Mengubah format formulir.
Menyatukan definisi data.
Menghilangkan pekerjaan duplikat.
Memperbaiki pembagian tanggung jawab.
Teknologi seharusnya memperkuat proses yang sudah dipahami, bukan menutupi proses yang belum pernah diperbaiki.
Jangan mendigitalkan masalah sebelum memahami masalahnya.
Uji Apakah Kita Benar-Benar Menemukan Akar Masalah
Setelah menemukan dugaan akar masalah, jangan langsung berhenti.
Buat hipotesis:
“Jika faktor ini benar-benar merupakan penyebab utama, maka memperbaikinya seharusnya mengurangi gejala secara signifikan.”
Kemudian lakukan perubahan dalam skala yang aman.
Ukur hasilnya.
Apakah waktu proses berkurang?
Apakah kesalahan turun?
Apakah keluhan berkurang?
Apakah masalah berpindah ke bagian lain?
Jika hasil tidak berubah seperti yang diharapkan, mungkin analisis akar masalah belum lengkap.
Kita kembali kepada evidence.
Inilah mengapa problem solving bersifat iteratif:
Understand → Hypothesis → Test → Evidence → Learn → Improve
Solusi juga perlu diuji.
Dari Firefighting Menuju Continuous Improvement
Organisasi yang terus memperbaiki gejala biasanya berada dalam mode firefighting.
Masalah muncul.
Diperbaiki.
Masalah muncul lagi.
Diperbaiki lagi.
Energi habis untuk merespons kejadian.
Root cause thinking mengubah pola tersebut.
Setiap masalah menjadi kesempatan untuk bertanya:
“Apa yang harus diperbaiki agar masalah ini lebih sulit terjadi lagi?”
Sekarang fokus bergeser dari reaction menuju prevention.
Dan ketika pola ini dilakukan terus-menerus, problem solving berkembang menjadi continuous improvement.
Kita tidak hanya menyelesaikan masalah hari ini.
Kita memperbaiki sistem agar bekerja lebih baik besok.
Understand → Evidence → Analyze → Solve → Improve
Root cause analysis sangat dekat dengan Thinking DNA ArrezaMP.
Understand — definisikan masalah dengan benar. Pisahkan gejala dari masalah sebenarnya.
Evidence — kumpulkan data, fakta, kronologi, dan informasi yang relevan.
Analyze — cari pola, bottleneck, hubungan, root cause, dan contributing factors.
Solve — pilih solusi yang menargetkan penyebab, bukan sekadar menutupi gejala.
Improve — ukur hasilnya dan perbaiki sistem agar masalah yang sama semakin sulit terulang.
Urutannya penting.
Jika kita melompat langsung dari:
Problem → Solution
kita berisiko menyelesaikan masalah yang salah.
Pendekatan yang lebih kuat adalah:
Problem → Evidence → Root Cause → Solution → Verification → Improvement
Kesimpulan
Masalah yang terlihat di permukaan belum tentu merupakan masalah yang sebenarnya perlu diselesaikan.
Keterlambatan bisa menjadi gejala.
Kesalahan data bisa menjadi gejala.
Biaya meningkat bisa menjadi gejala.
Keluhan pengguna bisa menjadi gejala.
Sistem lambat pun bisa menjadi gejala.
Karena itu jangan terburu-buru bertanya:
“Apa solusinya?”
Mulailah dengan:
“Apa yang sebenarnya menyebabkan kondisi ini terjadi?”
Cari evidence.
Uji asumsi.
Pisahkan gejala dari penyebab.
Kenali contributing factors.
Kemudian tentukan solusi yang benar-benar menargetkan masalah.
Karena solusi terbaik bukan solusi yang paling cepat terlihat.
Bukan pula yang paling canggih atau paling banyak menggunakan teknologi.
Solusi terbaik adalah solusi yang menyelesaikan penyebab yang tepat dan membuat masalah yang sama semakin sulit untuk terjadi kembali.
Jangan hanya membuat gejalanya menghilang.
Perbaiki sistem yang membuat gejala tersebut terus muncul.
ArrezaMP — Data Analytics • Problem Solving • Digital Solutions
0 Komentar