Laptop lemot.

Hapus beberapa file.

Normal lagi.

Seminggu kemudian lemot.

Hapus file lagi.

Normal.

Kemudian lemot lagi.

Atau dalam pekerjaan:

deadline selalu terlambat.

Tim diminta bekerja lebih cepat.

Bulan berikutnya terlambat lagi.

Rapat ditambah.

Tetap terlambat.

Situasinya terlihat berbeda, tetapi polanya sama.

Kita memperbaiki sesuatu.

Masalah terlihat selesai.

Beberapa waktu kemudian masalah yang sama kembali.

Kalau terus terjadi, ada kemungkinan yang selama ini diperbaiki hanyalah gejalanya, bukan penyebab utamanya.

Inilah salah satu bagian penting dalam memahami cara menyelesaikan masalah dengan efektif.

Sebelum mencari solusi, kita perlu memastikan satu hal:

Apakah kita sudah menyelesaikan masalah yang benar?

Karena solusi yang sangat bagus sekalipun tidak banyak berguna kalau diarahkan kepada masalah yang salah.

Gejala dan Akar Masalah Itu Berbeda

Bayangkan ada ember di bawah atap yang bocor.

Setiap hujan:

ember penuh.

Solusi pertama:

buang air dari ember.

Air hilang.

Masalah terlihat selesai.

Hujan berikutnya?

Ember penuh lagi.

Membuang air memang menyelesaikan kondisi sementara.

Tetapi akar masalahnya tetap:

atap bocor.

Contoh ini sederhana, tetapi pola yang sama terjadi dalam kehidupan sehari-hari.

Kita sering sibuk mengosongkan ember tanpa pernah melihat ke atas.

Apa Itu Akar Masalah?

Akar masalah atau root cause adalah faktor mendasar yang menyebabkan sebuah masalah terjadi atau terus berulang.

Menghilangkan gejala dapat memberikan perbaikan sementara.

Mengatasi root cause bertujuan mengurangi kemungkinan masalah yang sama kembali karena penyebab utamanya sudah ditangani.

Namun tidak semua masalah mempunyai satu akar tunggal.

Masalah kompleks bisa mempunyai beberapa penyebab yang saling berhubungan.

Karena itu root cause analysis bukan sekadar mencari satu pihak untuk disalahkan.

Tujuannya memahami sistem.

Contoh Sederhana: Selalu Terlambat ke Kantor

Masalah:

“Saya selalu terlambat.”

Solusi cepat:

“Besok gue harus berangkat lebih cepat.”

Besok berhasil.

Beberapa hari kemudian terlambat lagi.

Kenapa?

Mungkin akar persoalannya bukan waktu berangkat.

Bisa jadi:

tidur terlalu malam,

alarm terlalu mudah dimatikan,

persiapan dilakukan pagi hari,

rute perjalanan tidak mempunyai buffer,

atau estimasi waktu selalu terlalu optimistis.

Kalau penyebab sebenarnya belum ditemukan, kalimat “harus lebih disiplin” mungkin tidak cukup.

Jangan Langsung Melompat ke Solusi

Begitu mendengar masalah, otak suka mencari jawaban.

“Website lambat.”

Ganti hosting.

“Penjualan turun.”

Pasang iklan.

“Tim nggak produktif.”

Tambah meeting.

“Konten sepi.”

Posting lebih banyak.

Mungkin benar.

Tetapi mungkin juga tidak.

Solusi yang muncul terlalu cepat sering berasal dari asumsi.

Langkah pertama seharusnya:

definisikan masalahnya.

1. Tulis Masalah dalam Satu Kalimat

Kalau sebuah masalah tidak bisa dijelaskan secara sederhana, kemungkinan kita belum benar-benar memahaminya.

Hindari:

“Pokoknya sistem ini kacau.”

Terlalu luas.

Coba:

“Pesanan pelanggan rata-rata terlambat dikirim dua hari selama tiga minggu terakhir.”

Sekarang jauh lebih jelas.

Ada:

objek,

kondisi,

ukuran,

dan periode.

Semakin jelas problem statement, semakin mudah mencari penyebabnya.

Hindari Kata yang Langsung Menuduh Penyebab

Misalnya:

“Penjualan turun karena tim marketing malas.”

Kalimat itu bukan hanya mendeskripsikan masalah.

Ia sudah memasukkan kesimpulan.

Padahal belum tentu benar.

Problem statement yang lebih netral:

“Jumlah transaksi bulan ini turun 20% dibandingkan rata-rata tiga bulan sebelumnya.”

Sekarang penyebabnya masih terbuka untuk diperiksa.

Bisa marketing.

Bisa harga.

Bisa produk.

Bisa kompetitor.

Bisa traffic.

Bisa proses checkout.

Jangan mengunci jawaban sebelum investigasi dimulai.

2. Pisahkan Fakta dari Interpretasi

Contoh:

“Customer tidak suka produk baru.”

Apakah itu fakta?

Belum tentu.

Faktanya mungkin:

“Conversion rate produk baru lebih rendah daripada produk sebelumnya.”

Interpretasinya:

“Customer tidak suka.”

Ada banyak kemungkinan lain.

Harga lebih mahal.

Halaman produk membingungkan.

Traffic berbeda.

Stok ukuran tertentu habis.

Iklan menjangkau audiens yang salah.

Memisahkan fakta dari interpretasi mencegah kita membangun solusi berdasarkan dugaan.

Gunakan Pertanyaan: “Apa yang Benar-Benar Kita Tahu?”

Ketika diskusi mulai penuh asumsi, tanyakan:

Apa yang benar-benar diketahui?

Apa datanya?

Apa yang hanya dugaan?

Apa yang belum diketahui?

Empat pertanyaan ini sederhana tetapi sangat berguna.

Masalah sering terlihat rumit karena fakta, opini, dan asumsi tercampur menjadi satu.

3. Cari Kapan Masalah Mulai Terjadi

Waktu dapat memberikan petunjuk.

Misalnya:

Website mulai lambat sejak kapan?

Penjualan turun sejak kapan?

Mesin mulai sering bermasalah sejak kapan?

Karyawan mulai sering terlambat sejak kapan?

Kemudian tanyakan:

Apa yang berubah tepat sebelum itu?

Mungkin ada:

software update,

pegawai baru,

supplier baru,

proses baru,

harga baru,

campaign baru,

atau perubahan lingkungan.

Korelasi tidak otomatis berarti penyebab.

Tetapi timeline membantu mempersempit investigasi.

Bandingkan Sebelum dan Sesudah

Kalau sebelumnya sistem berjalan normal dan sekarang tidak, cari perbedaannya.

Sebelum:

proses A.

Sesudah:

proses B.

Sebelum:

traffic 10.000.

Sesudah:

traffic tetap 10.000 tetapi conversion turun.

Sekarang kita tahu masalah mungkin bukan traffic.

Perbandingan membantu menghilangkan beberapa hipotesis.

4. Tanyakan “Kenapa?” Lebih dari Sekali

Salah satu metode paling terkenal dalam root cause analysis adalah 5 Whys.

Konsepnya sederhana.

Tanyakan:

Kenapa?

Kemudian terhadap jawabannya:

Kenapa?

Ulangi beberapa kali sampai mencapai penyebab yang lebih mendasar.

Angka lima bukan aturan wajib.

Kadang cukup tiga.

Kadang perlu tujuh.

Tujuannya bukan mencapai angka tertentu.

Tujuannya melewati jawaban permukaan.

Contoh 5 Whys

Masalah:

Pesanan terlambat dikirim.

Kenapa?

Karena barang baru dipacking sore hari.

Kenapa baru dipacking sore?

Karena daftar pesanan selesai disiapkan terlalu lambat.

Kenapa daftar pesanan terlambat?

Karena data dari dua channel penjualan harus digabung manual.

Kenapa harus manual?

Karena sistem belum terintegrasi.

Sekarang solusi:

“Packing harus lebih cepat”

terlihat kurang lengkap.

Masalah sebenarnya mungkin berada pada aliran data sebelum proses packing dimulai.

Jangan Memaksa 5 Whys Menjadi Satu Jalur

Realitas sering bercabang.

Kenapa pesanan terlambat?

Bisa karena:

data terlambat,

stok sulit ditemukan,

jumlah staf kurang,

atau pickup kurir terlalu awal.

Artinya kita mungkin mempunyai beberapa cabang penyebab.

Jangan memaksa semua masalah menjadi satu rantai sederhana hanya karena metode disebut “5 Whys”.

5. Gunakan Fishbone Diagram untuk Masalah yang Kompleks

Fishbone diagram atau Ishikawa diagram membantu mengelompokkan kemungkinan penyebab.

Biasanya masalah ditulis di satu sisi.

Kemudian penyebab dibagi ke beberapa kategori.

Dalam konteks bisnis atau operasional, kategorinya bisa berupa:

People,

Process,

Technology,

Materials,

Environment,

Measurement.

Tidak harus selalu memakai kategori yang sama.

Sesuaikan dengan masalah.

Contoh: Website Sering Down

Daripada langsung menyalahkan server, buat beberapa kategori.

Infrastructure

CPU.

RAM.

Storage.

Network.

Software

Plugin.

Database.

PHP.

Update.

Traffic

Bot.

Traffic spike.

Attack.

Configuration

Caching.

Timeout.

Cron job.

Human

Perubahan konfigurasi.

Deployment.

Maintenance.

Sekarang investigasi lebih sistematis.

6. Cari Pola, Bukan Hanya Insiden

Satu kejadian bisa kebetulan.

Sepuluh kejadian mulai menunjukkan pola.

Misalnya customer complaint selalu meningkat:

hari Senin,

jam tertentu,

produk tertentu,

atau setelah campaign tertentu.

Pola membantu mempersempit penyebab.

Tanyakan:

Apakah selalu terjadi?

Kapan paling sering?

Kapan tidak terjadi?

Apa yang berbeda ketika masalah tidak terjadi?

Pertanyaan terakhir sering sangat berguna.

“Kapan Masalah Tidak Terjadi?” Bisa Memberikan Jawaban

Misalnya mesin sering overheat.

Tetapi hanya pada shift siang.

Apa yang berbeda?

Suhu ruangan?

Operator?

Beban produksi?

Prosedur?

Atau mesin lain yang berjalan bersamaan?

Kondisi ketika masalah tidak terjadi bisa sama informatifnya dengan kondisi ketika masalah terjadi.

7. Jangan Mengabaikan Data karena Tidak Sesuai Dugaan

Kita semua mempunyai kecenderungan mencari bukti yang mendukung keyakinan awal.

“Pasti gara-gara X.”

Kemudian hanya memperhatikan data yang menguatkan X.

Ini dikenal sebagai confirmation bias.

Problem solving yang baik membutuhkan kemampuan mengatakan:

“Ternyata dugaan awal gue salah.”

Itu bukan kegagalan.

Justru berarti investigasi bekerja.

Hipotesis Boleh Salah

Buat hipotesis.

Misalnya:

“Website lambat karena plugin baru.”

Kemudian test.

Plugin dinonaktifkan di environment yang aman.

Tidak ada perubahan.

Berarti hipotesis melemah.

Lanjut ke hipotesis berikutnya.

Jangan mempertahankan sebuah jawaban hanya karena kita yang pertama mengusulkannya.

8. Bedakan Korelasi dan Sebab-Akibat

Dua hal terjadi bersamaan tidak otomatis berarti salah satunya menyebabkan yang lain.

Contoh:

Traffic turun setelah website mengganti warna tombol.

Apakah warna tombol penyebabnya?

Belum tentu.

Pada periode yang sama mungkin:

ranking turun,

campaign berhenti,

tracking rusak,

atau seasonality berubah.

Timeline penting.

Tetapi tetap perlu bukti tambahan sebelum menyimpulkan causal relationship.

9. Cari Bukti yang Bisa Membantah Teori Kita

Biasanya kita bertanya:

“Apa bukti bahwa teori ini benar?”

Coba tambahkan:

“Apa yang harus terjadi kalau teori ini salah?”

Misalnya teori:

“Pengiriman terlambat karena kurir.”

Kalau benar, keterlambatan seharusnya terjadi setelah paket diserahkan ke kurir.

Tetapi data menunjukkan paket justru sudah terlambat sebelum pickup.

Berarti penyebab utama mungkin berada di internal warehouse.

Mencari bukti yang bisa membantah hipotesis membuat analisis lebih kuat.

10. Pergi ke Tempat Masalah Terjadi

Spreadsheet berguna.

Dashboard berguna.

Report berguna.

Tetapi terkadang kita perlu melihat proses secara langsung.

Bagaimana barang dipacking?

Bagaimana customer melakukan checkout?

Bagaimana staf memasukkan data?

Bagaimana pengguna memakai aplikasi?

Realitas sering berbeda dengan SOP tertulis.

Sebuah proses yang terlihat sederhana dalam flowchart mungkin mempunyai sepuluh workaround di lapangan.

Jangan Hanya Bertanya kepada Manajer

Orang yang menjalankan proses setiap hari sering mempunyai informasi berbeda.

Tanyakan kepada:

operator,

customer service,

teknisi,

admin,

atau pengguna.

Bukan untuk mencari siapa yang salah.

Tetapi untuk memahami bagaimana sistem benar-benar bekerja.

“Kenapa Kamu Melakukan Ini?” Bisa Terdengar Menuduh

Ganti dengan:

“Bisa ceritain prosesnya dari awal?”

atau:

“Apa yang biasanya bikin bagian ini paling sulit?”

Pertanyaan terbuka menghasilkan informasi lebih baik.

Orang cenderung defensif kalau merasa sedang diinterogasi.

Root Cause Analysis Bukan Mencari Kambing Hitam

Ini penting.

Misalnya ditemukan:

“Operator salah memasukkan data.”

Apakah root cause-nya:

operator ceroboh?

Mungkin.

Tetapi jangan berhenti terlalu cepat.

Tanyakan:

Kenapa kesalahan mudah terjadi?

Form membingungkan?

Tidak ada validation?

Training kurang?

Instruksi tidak jelas?

Beban kerja terlalu tinggi?

Sistem memungkinkan satu typo menyebabkan kerusakan besar?

Human error sering menjadi titik awal investigasi, bukan titik akhir.

Kalau Satu Kesalahan Manusia Bisa Menghancurkan Sistem, Sistemnya Juga Perlu Dievaluasi

Manusia akan membuat kesalahan.

Selalu.

Sistem yang baik mencoba mengurangi dampaknya.

Contohnya:

confirmation dialog,

input validation,

backup,

permission,

checklist,

dan review.

Daripada berharap:

“Semua orang jangan pernah salah,”

lebih realistis membuat sistem yang tahan terhadap kesalahan.

Cari Single Point of Failure

Single point of failure adalah satu komponen yang ketika gagal dapat membuat seluruh sistem berhenti.

Misalnya seluruh tim bergantung pada:

satu orang,

satu spreadsheet,

satu server,

atau satu supplier.

Selama semuanya berjalan, tidak terlihat masalah.

Begitu titik tersebut gagal, seluruh proses ikut terganggu.

Root cause analysis dapat mengungkap ketergantungan semacam ini.

11. Gunakan Pareto Principle untuk Menentukan Prioritas

Tidak semua penyebab mempunyai dampak sama.

Dalam banyak situasi, sebagian kecil penyebab dapat berkontribusi terhadap sebagian besar masalah.

Prinsip ini sering dikaitkan dengan aturan 80/20.

Tidak harus tepat 80 dan 20.

Intinya:

cari penyebab yang memberikan dampak terbesar.

Kalau ada 20 jenis complaint, mungkin tiga kategori menghasilkan mayoritas complaint.

Mulai dari sana.

Jangan Menyelesaikan Masalah Kecil Hanya karena Mudah

Ada kecenderungan memilih pekerjaan yang cepat selesai.

Lima masalah kecil dibereskan.

Terasa produktif.

Tetapi masalah besar yang menghasilkan 70% kerugian tidak disentuh.

Prioritas harus mempertimbangkan:

impact,

frequency,

risk,

dan effort.

Bukan hanya kemudahan.

Buat Matriks Impact vs Effort

Bagi solusi menjadi empat kelompok.

High Impact + Low Effort

Kerjakan lebih dulu.

High Impact + High Effort

Rencanakan dengan serius.

Low Impact + Low Effort

Kerjakan jika ada kapasitas.

Low Impact + High Effort

Pertanyakan apakah layak.

Matriks sederhana ini membantu ketika ada terlalu banyak pilihan solusi.

12. Jangan Mencari Solusi Sebelum Menentukan Kriteria Sukses

Bagaimana kita tahu masalah sudah selesai?

“Website lebih cepat.”

Berapa cepat?

“Complaint berkurang.”

Berapa banyak?

“Tim lebih produktif.”

Diukur dengan apa?

Definisikan kondisi sukses.

Misalnya:

waktu loading halaman utama di bawah target tertentu,

jumlah error turun,

pengiriman selesai sebelum cut-off,

atau repeat complaint berkurang.

Tanpa ukuran, solusi sulit dievaluasi.

Solusi yang Terlihat Berhasil Bisa Saja Hanya Memindahkan Masalah

Misalnya untuk mempercepat produksi, quality control dikurangi.

Produksi naik.

Sukses?

Sebulan kemudian return produk meningkat.

Masalah tidak hilang.

Hanya berpindah dari produksi ke customer service.

Karena itu evaluasi solusi harus melihat efek samping.

13. Cari Second-Order Effects

Setiap perubahan dapat menghasilkan konsekuensi berikutnya.

Contoh:

Meeting dikurangi untuk meningkatkan produktivitas.

Efek pertama:

waktu kerja bertambah.

Bagus.

Efek kedua:

informasi antar-tim mulai tidak sinkron.

Sekarang muncul masalah baru.

Problem solving yang matang tidak hanya bertanya:

“Apa yang terjadi setelah solusi diterapkan?”

Tetapi juga:

“Lalu setelah itu apa?”

Jangan Mengoptimalkan Satu Bagian dengan Merusak Keseluruhan Sistem

Tim A ingin menyelesaikan pekerjaannya secepat mungkin.

Mereka mengirim semua pekerjaan ke Tim B sekaligus.

KPI Tim A terlihat bagus.

Tim B kewalahan.

Secara lokal:

A sukses.

Secara sistem:

gagal.

Ini disebut local optimization.

Solusi harus dinilai berdasarkan tujuan keseluruhan, bukan hanya satu bagian.

14. Buat Beberapa Solusi, Jangan Cuma Satu

Begitu menemukan satu ide yang terasa bagus, kita sering berhenti mencari.

Coba paksa menghasilkan minimal tiga alternatif.

Misalnya masalah:

customer menunggu terlalu lama.

Solusi A:

tambah staf.

Solusi B:

kurangi langkah proses.

Solusi C:

otomatisasi bagian tertentu.

Solusi D:

ubah sistem antrean.

Sekarang kita bisa membandingkan.

Satu masalah tidak selalu mempunyai satu solusi.

Solusi Terbaik Tidak Selalu Solusi Paling Canggih

Software baru terdengar menarik.

AI terdengar modern.

Automation terdengar efisien.

Tetapi mungkin masalahnya cukup diselesaikan dengan:

checklist,

label yang lebih jelas,

atau perubahan urutan kerja.

Teknologi adalah alat.

Bukan tujuan.

Kalau solusi Rp200 ribu menyelesaikan masalah sama baiknya dengan software Rp200 juta, kompleksitas tambahan perlu dipertanyakan.

15. Uji Solusi dalam Skala Kecil

Sebelum mengubah seluruh sistem, coba pilot.

Misalnya proses baru diuji:

satu minggu,

satu cabang,

satu tim,

atau satu jenis produk.

Lihat hasilnya.

Apa yang membaik?

Apa yang justru rusak?

Apa yang tidak diperkirakan?

Eksperimen kecil membuat kesalahan lebih murah.

Jangan Menganggap Pilot Berhasil Hanya karena Tidak Ada Keluhan

Tidak ada complaint belum tentu berarti sukses.

Mungkin pengguna belum mencoba.

Mungkin staf diam.

Mungkin masalah baru belum terlihat.

Gunakan metrik yang sudah ditentukan.

Bandingkan sebelum dan sesudah.

16. Dokumentasikan Apa yang Dicoba

Problem solving sering kehilangan banyak waktu karena tim lupa:

apa yang sudah diuji,

kapan,

dan hasilnya apa.

Buat catatan sederhana:

Masalah

Apa yang terjadi?

Hipotesis

Apa dugaan penyebab?

Test

Apa yang dilakukan?

Hasil

Apa yang berubah?

Kesimpulan

Hipotesis diterima, ditolak, atau perlu data tambahan?

Dokumentasi mencegah eksperimen yang sama diulang tanpa alasan.

Jangan Takut Menulis “Belum Tahu”

Tidak semua masalah bisa dijawab dalam satu meeting.

“Belum tahu” jauh lebih berguna daripada jawaban palsu yang terdengar percaya diri.

Kalau belum tahu:

tentukan data apa yang dibutuhkan.

Kemudian cari.

Ketidakpastian adalah bagian normal dari investigasi.

17. Gunakan Data, tetapi Jangan Mengabaikan Konteks

Data membantu.

Tetapi angka tanpa konteks bisa menyesatkan.

Misalnya conversion rate turun.

Buruk?

Belum tentu.

Mungkin traffic naik drastis karena campaign awareness dengan audiens lebih luas.

Conversion percentage turun, tetapi total transaksi naik.

Karena itu jangan melihat satu metric sendirian.

Tanyakan apa cerita di belakang angka tersebut.

Average Bisa Menyembunyikan Masalah

Rata-rata waktu pengiriman:

2 hari.

Terlihat bagus.

Tetapi mungkin:

80% dikirim dalam 1 hari,

20% membutuhkan 6 hari.

Average menyembunyikan kelompok customer yang mengalami masalah besar.

Coba lihat distribusi.

Segmentasi berdasarkan:

produk,

wilayah,

channel,

atau periode.

18. Jangan Mengubah Lima Hal Sekaligus

Website lambat.

Tim:

ganti hosting,

ganti plugin,

ubah database,

aktifkan CDN,

dan update PHP

pada hari yang sama.

Website jadi cepat.

Bagus.

Pertanyaannya:

apa penyebab sebenarnya?

Tidak tahu.

Kalau memungkinkan, ubah variabel secara terkontrol.

Dengan begitu kita belajar dari perubahan.

Tetapi Jangan Terlalu Kaku Kalau Situasinya Darurat

Ada perbedaan antara investigasi normal dan incident response.

Kalau server produksi sedang down dan bisnis berhenti, prioritas pertama:

restore service.

Gunakan workaround kalau perlu.

Setelah kondisi stabil, baru lakukan root cause analysis secara lebih sistematis.

Urutannya:

contain → recover → investigate → prevent.

Jangan membiarkan sistem tetap rusak hanya demi eksperimen yang sempurna.

Fix Sementara Bukan Hal Buruk

Mengosongkan ember tetap berguna kalau rumah sedang kebanjiran.

Yang salah adalah menganggap ember sebagai perbaikan permanen.

Dalam problem solving ada:

temporary fix

dan

permanent corrective action.

Keduanya bisa diperlukan.

Yang penting kita tahu mana yang sedang dilakukan.

19. Buat Preventive Action setelah Masalah Selesai

Setelah root cause diperbaiki, tanyakan:

Bagaimana mencegah kejadian serupa?

Misalnya:

tambahkan monitoring,

buat alert,

ubah SOP,

tambahkan validation,

buat backup,

atau training.

Tujuan akhirnya bukan hanya menyelesaikan incident.

Tetapi membuat sistem sedikit lebih kuat daripada sebelumnya.

Monitoring Adalah Bagian dari Solusi

Anda memperbaiki sesuatu.

Kemudian tidak pernah memeriksanya lagi.

Bagaimana tahu masalah tidak kembali?

Tentukan indikator.

Misalnya:

error rate,

downtime,

complaint,

return,

atau processing time.

Monitoring membuat solusi dapat diverifikasi dalam jangka panjang.

20. Lakukan Post-Mortem Tanpa Menyalahkan

Setelah insiden besar, lakukan review.

Apa yang terjadi?

Kapan mulai?

Bagaimana terdeteksi?

Apa dampaknya?

Apa yang dilakukan?

Apa root cause-nya?

Apa yang bisa diperbaiki?

Post-mortem yang baik berfokus pada pembelajaran.

Kalau setiap review berubah menjadi sesi mencari orang untuk dihukum, orang akan mulai menyembunyikan kesalahan.

Akibatnya organisasi justru kehilangan informasi penting.

Psychological Safety Membantu Problem Solving

Kalau anggota tim takut mengatakan:

“Saya salah.”

masalah lebih sulit ditemukan.

Mereka akan mencoba menutupi.

Tim yang sehat memungkinkan seseorang mengatakan:

“Gue melakukan ini dan ternyata salah.”

Kemudian fokus bergeser ke:

bagaimana memperbaikinya?

Kejujuran mempercepat diagnosis.

Dua Kepala Bisa Menghasilkan Perspektif Ketiga

Di sinilah konsep One Plus One Is Three menjadi relevan.

Orang pertama melihat masalah dari sisi teknis.

Orang kedua melihat dari sisi pengguna.

Ketika keduanya berdiskusi, muncul perspektif ketiga yang sebelumnya tidak dimiliki keduanya.

Kolaborasi yang baik bukan sekadar:

A punya ide.

B punya ide.

Lalu pilih salah satu.

Kadang:

A + B menghasilkan C.

Ide baru.

Itulah nilai kombinasi perspektif.

Tetapi Brainstorming Tidak Selalu Berarti Semua Orang Bicara Bersamaan

Dalam meeting, orang paling vokal bisa mendominasi.

Akibatnya ide orang lain tidak muncul.

Coba metode:

semua orang menulis hipotesis sendiri terlebih dahulu.

Baru kemudian dibagikan.

Dengan begitu ide pertama yang diucapkan tidak terlalu memengaruhi seluruh kelompok.

Hindari Groupthink

Kalau bos mengatakan:

“Menurut saya masalahnya marketing.”

Semua orang:

“Iya, benar.”

Padahal mungkin tidak.

Untuk masalah penting, minta seseorang secara sengaja mencari kelemahan dari hipotesis utama.

Bukan untuk berdebat.

Tetapi untuk memastikan keputusan tidak dibuat hanya karena hierarki.

Orang yang Berbeda Melihat Masalah yang Berbeda

Developer melihat bug.

Designer melihat interface.

Customer service melihat complaint.

Finance melihat biaya.

Customer melihat pengalaman.

Semua bisa benar pada saat bersamaan.

Masalah kompleks sering membutuhkan beberapa perspektif untuk membangun gambaran lengkap.

Jangan Undang Terlalu Banyak Orang Tanpa Alasan

Kolaborasi bagus.

Tetapi meeting 20 orang tidak otomatis menghasilkan solusi 20 kali lebih baik.

Pilih orang berdasarkan informasi yang dibutuhkan.

Siapa memahami proses?

Siapa terkena dampak?

Siapa mempunyai keahlian relevan?

Siapa yang akan menjalankan solusi?

Kolaborasi harus menambah perspektif, bukan hanya menambah kursi.

Masalah Personal Juga Bisa Menggunakan Prinsip yang Sama

Root cause analysis tidak hanya untuk bisnis.

Misalnya:

“Saya nggak pernah punya waktu olahraga.”

Kenapa?

Karena pulang selalu terlalu malam.

Kenapa?

Karena pekerjaan sering selesai terlambat.

Kenapa?

Karena sore hari banyak pekerjaan yang belum selesai.

Kenapa?

Karena pagi sering habis untuk aktivitas kecil dan notifikasi.

Sekarang solusi mungkin bukan:

“Cari motivasi olahraga.”

Tetapi:

“Perbaiki struktur waktu kerja.”

Tetapi Jangan Mengubah Semua Masalah Hidup Menjadi Spreadsheet

Tidak semua hal membutuhkan diagram.

Hubungan.

Kesedihan.

Konflik personal.

Keputusan hidup.

Manusia bukan mesin.

Framework membantu berpikir.

Tetapi empati, emosi, nilai, dan konteks tetap penting.

Gunakan alat problem solving ketika memang membantu.

Bukan untuk menghilangkan sisi manusia dari masalah.

Kadang Masalah Tidak Bisa “Diselesaikan”

Ada masalah yang sebenarnya constraint.

Misalnya:

hari hanya 24 jam.

Budget terbatas.

Ruangan kecil.

Cuaca buruk.

Kita tidak bisa menghapus constraint.

Yang bisa dilakukan adalah bekerja di dalam batas tersebut.

Bedakan:

problem yang bisa diperbaiki

dengan

constraint yang harus dikelola.

Kadang Solusinya Adalah Berhenti Melakukan Sesuatu

Kita sering berpikir solusi berarti menambah.

Tambah staf.

Tambah aplikasi.

Tambah proses.

Tambah meeting.

Tetapi solusi bisa berupa:

hapus langkah,

hapus approval,

hapus laporan,

hapus fitur,

atau berhenti melakukan aktivitas yang tidak lagi memberikan nilai.

Subtraction adalah bentuk problem solving yang sering terlupakan.

Tanya: “Kalau Kita Tidak Boleh Menambah Apa Pun, Apa yang Bisa Dihapus?”

Pertanyaan ini memaksa perspektif berbeda.

Proses mempunyai 12 langkah.

Tidak boleh tambah software.

Tidak boleh tambah staf.

Apa yang bisa dihilangkan?

Mungkin empat langkah ternyata hanya warisan proses lama dan sudah tidak dibutuhkan.

Kadang sistem menjadi buruk bukan karena kekurangan sesuatu.

Tetapi karena terlalu banyak sesuatu.

Solusi Sederhana Sering Datang setelah Pemahaman yang Dalam

Orang melihat solusi akhir:

“Oh, cuma begitu?”

Tetapi menemukan solusi sederhana bisa membutuhkan investigasi panjang.

Kesederhanaan bukan berarti analisisnya dangkal.

Sering justru sebaliknya.

Setelah memahami masalah dengan benar, kita tahu bagian mana yang benar-benar perlu disentuh.

Jangan Bangga dengan Solusi Rumit

Kompleksitas bukan tanda kecerdasan.

Kalau sebuah masalah bisa diselesaikan dengan satu perubahan sederhana, itu bagus.

Tujuan problem solving bukan menunjukkan seberapa pintar kita.

Tujuannya membuat masalah benar-benar berkurang.

Checklist Singkat Menemukan Akar Masalah

Ketika menghadapi masalah yang terus berulang, gunakan urutan ini:

1. Apa yang sebenarnya terjadi?

Tuliskan fakta.

2. Sejak kapan terjadi?

Cari timeline.

3. Di mana dan kapan paling sering terjadi?

Cari pola.

4. Kapan masalah tidak terjadi?

Cari perbedaan.

5. Kenapa ini terjadi?

Gunakan beberapa lapis “kenapa”.

6. Apa bukti bahwa dugaan kita benar?

Cari data.

7. Apa yang bisa membuktikan dugaan kita salah?

Lawan confirmation bias.

8. Apa akar penyebab yang bisa kita pengaruhi?

Prioritaskan.

9. Solusi apa saja yang mungkin?

Jangan berhenti pada ide pertama.

10. Bagaimana kita tahu solusi berhasil?

Tentukan metrik.

Setelah Menemukan Root Cause, Jangan Langsung Merayakan

Root cause adalah hipotesis sampai diuji.

Misalnya kita yakin penyebabnya:

proses manual.

Automasi diterapkan.

Kalau masalah tetap terjadi, berarti analisis belum selesai.

Kembali.

Periksa asumsi.

Problem solving adalah siklus.

Bukan garis lurus.

Siklus Problem Solving yang Sederhana

Gunakan pola:

Observe

Apa yang terjadi?

Define

Apa masalah sebenarnya?

Investigate

Kenapa terjadi?

Generate

Solusi apa yang mungkin?

Test

Apa yang terjadi kalau solusi diterapkan?

Measure

Apakah hasil membaik?

Learn

Apa yang kita pelajari?

Kemudian ulangi kalau diperlukan.

Jangan Takut Mengubah Definisi Masalah

Awalnya:

“Customer service terlalu lambat.”

Setelah investigasi:

“Ternyata 60% tiket berasal dari satu bagian checkout yang membingungkan.”

Sekarang problem statement berubah.

Ini kemajuan.

Bukan inkonsistensi.

Semakin banyak informasi, pemahaman masalah seharusnya menjadi lebih akurat.

Problem Solving yang Baik Mengurangi Masalah di Masa Depan

Ada dua jenis kemenangan.

Pertama:

masalah hari ini selesai.

Kedua:

sistem belajar sehingga masalah serupa lebih kecil kemungkinan terjadi.

Kemenangan kedua lebih berharga.

Karena organisasi atau individu tidak hanya kembali ke kondisi sebelum masalah.

Mereka menjadi lebih baik setelah melewatinya.

Kesimpulan

Kalau masalah yang sama terus muncul meskipun sudah berkali-kali “diperbaiki”, kemungkinan kita perlu berhenti mencari solusi baru untuk sementara.

Kembali ke masalahnya.

Tanyakan:

Apa yang sebenarnya sedang terjadi?

Dalam memahami cara menyelesaikan masalah dengan efektif, kemampuan mendefinisikan masalah sering lebih penting daripada seberapa cepat kita menghasilkan solusi.

Pisahkan fakta dari asumsi.

Cari kapan masalah mulai.

Perhatikan pola.

Tanyakan kenapa beberapa kali.

Uji hipotesis.

Dengarkan orang yang menjalankan proses.

Cari kemungkinan penyebab dari beberapa perspektif.

Kemudian baru pilih tindakan.

Itulah inti cara menemukan akar masalah.

Jangan hanya mengosongkan ember setiap kali hujan.

Cari dari mana air masuk.

Dan ketika masalah cukup kompleks, jangan merasa harus menemukan semuanya sendirian.

Satu orang mungkin melihat sesuatu yang tidak dilihat orang lain.

Dua perspektif yang berbeda bisa menghasilkan pemahaman ketiga yang jauh lebih baik.

Kadang memang:

one plus one is three.

Bukan dalam matematika.

Tetapi dalam cara ide berkembang ketika orang melihat masalah yang sama dari sudut yang berbeda.