Chapter 7: Pecah

"The source of the problem is almost never where you first think it is." — Gause & Weinberg, Are Your Lights On?

Memecahkan Masalah

Kebanyakan orang saat diberi sebuah masalah langsung lompat ke solusi. Padahal yang lebih penting dari solusi yang cepat adalah penentuan masalah yang tepat. Pada Chapter kali ini, kita akan belajar untuk gak langsung lompat ke solusi dan coba memecahkannya perlahan. Skill yang kita akan pelajari kali ini adalah fondasi dasar good consulting, good policy-making, good engineering, and honestly just good thinking.

Kita akan mencoba memecahkan masalah yang nyata dan (semoga) dekat dengan kita: Transjakarta. Meski secara tidak langsung pemecahan masalah sudah dibahas beberapa kali sepanjang materi-materi yang sudah kita baca, harapannya pada kesempatan kali ini kita bisa coba memecahkan masalahnya dari dekat.

---

Kenapa ini Penting?

Ini yang sering terjadi saat orang melihat masalah yang kompleks:

1. Ngelihat gejala-gejala yang tampak
2. Brainstorm beberapa solusi cepat
3. Pilih jawaban yang paling obvious
4. Langsung implementasi
5. Berharap masalahnya pergi, yang terkadang malah kembali dan menjadi lebih buruk

Familiar gak? Ini yang disebut oleh Eliyahu Goldratt dalam novelnya The Goal (1984) sebagai “local optimization”, yaitu memperbaiki satu bagian dari sistem dan ngelupain bagian-bagian lain yang berinterkasi dengannya.

Alternatif lainnya adalah analisis masalah yang terstruktur, mengubah pola pikir dari sekadar “ada yang rusak” menjadi “ini pusat masalahnya, dan inilah cara-cara terbaik untuk mengatasinya.”

Ambil contohnya gini: misal di kampus lo parkirannya selalu penuh, solusinya kan bukan buka kampusnya 24 jam dan ngadain kelas di jam 2 pagi supaya mahasiswanya tersebar secara merata. Atau malah naikin harga parkirnya jadi 10x lipat supaya parkiran jadi kosong? Gak, dong? Terus gimana dong caranya? Coba kita pelajarin prinsip dasar memecahkan masalah pakai contoh kasus Transjakarta.

---

Masalah Dengan Solusi

Sebelum kita masuk ke framework, gua mau menekankan satu hal dulu: solusi pertama yang kepikiran di otak lo hampir pasti bukan yang terbaik. Kenapa? Karena solusi pertama itu pasti dibentuk dari cara kita mendefinisikan masalah, dan kebanyakan orang mendefinisikan masalah terlalu sempit di fase awal.

Kasus Transjakarta

Gejalanya: Orang numpuk di depan pintu bus pas mau berangkat.

Yang kebanyakan orang bilang: "Scannernya lambat. Ganti scanner yang lebih cepat."

Masuk akal sih, DAN mungkin benar. Tapi coba perhatiin apa yang baru aja terjadi. Begitu lo bilang "scannernya lambat," lo udah secara otomatis mendefinisikan ini sebagai masalah teknologi. Sekarang otak lo cuma bakal generate solusi teknologi: scanner lebih canggih, scanner model lain, hapus scanner sekalian.

Tapi gimana kalau masalah sebenarnya bukan di situ?

Gimana kalau bottleneck-nya bukan kecepatan scanner, tapi karena semua orang dateng di waktu yang sama karena busnya jumlahnya terbatas dan orang-orang pada numpuk? Ganti scanner secepat apapun, masalahnya gak bakal ilang.

Atau gimana kalau bottleneck-nya adalah cuma ada satu pintu, jadi bahkan kalau scannernya instan, 200 orang tetap gak bisa masuk lewat celah 90 cm di waktu yang sama? Kayak nyuruh seluruh penonton konser NCT keluar lewat satu pintu darurat.

Cara lo merumuskan sebuah masalah mengandung asumsi tersembunyi yang membatasi ruang solusi lo. Kalau lo merumuskan ulang masalahnya, lo buka pintu ke solusi-solusi baru.

Jadi gimana caranya ngebuka pintu ke solusi-solusi baru itu?

---

Problem Reframing

Problem reframing artinya lo sengaja merumuskan ulang masalah dengan cara yang berbeda-beda untuk ngeliat solusi baru apa yang muncul. Mungkin beberapa dari lo familiar dengan How Might We, nah ini konsepnya sama persis tapi konteksnya masih dalam domain problem statement. Ambil kasus Transjakarta tadi, terus coba lengkapin kalimat ini dengan lima cara berbeda:

"Masalah sebenernya adalah ______."

Setiap reframe secara teknis valid. Setiap reframe membuka ruang solusi yang berbeda. Kekuatan utama reframing adalah lo gak mengubah situasinya, lo mengubah apa yang lo lihat.

Coba sendiri. Sebelum lanjut, pilih satu masalah sehari-hari:

1. Antrian panjang di warung
2. Parkiran mall yang selalu penuh
3. Kegerahan saat pidato di hari buruh

Coba tulis lima versi "masalah sebenernya adalah..." yang berbeda. Rasain sendiri betapa beda rasanya tiap versi.

Terus gimana kalau lo kebingungan cara reframenya? Solusinya: Tambah referensi lo.

Semakin banyak data yang lo punya, maka semakin besar kemungkinan lo bisa melihat sebuah masalah dari angle yang lebih luas dan lebih tinggi. Baca beberapa jurnal atau artikel yang kredibel sebagai fondasi awal untuk menjadi sudut pandang lo analasis masalahnya. Diskusi bareng teman. Wawancara beberapa orang. Dan berjuta-juta cara lainnya yang lo bisa lakukan untuk memperluas sudut pandang lo.

---

Bedah Masalahnya

Setelah lo punya rumusan masalah yang bagus, langkah selanjutnya adalah decompose, yaitu mecah masalah besar itu jadi pertanyaan-pertanyaan kecil yang lebih bisa dijawab. Dan ini adalah skill inti yang diajarkan di Bulletproof Problem Solving karya Conn & McLean (2019), dua mantan partner McKinsey yang capek lihat orang salah diagnosis masalah.

Tool utama mereka namanya issue tree (atau logic tree).

Apa Itu Issue Tree?

Issue tree adalah cara memecah masalah secara terstruktur ke bagian-bagian komponennya. Aturan utamanya disebut MECE: Mutually Exclusive, Collectively Exhaustive (yang sudah kita pernah bahas di chapter sebelumnya)

• Mutually exclusive = cabang-cabangnya gak tumpang tindih (lo gak ngitung hal yang sama dua kali)
• Collectively exhaustive = cabang-cabangnya mencakup segalanya (gak ada yang ketinggalan)

Bayangin kayak motong kue. Kalau lo motongnya bener, tiap potongan terpisah (ME) dan kalau digabung lagi jadi kue yang utuh (CE).

Aplikasinya ke Kasus Transjakarta

Ini salah satu cara bikin issue tree untuk masalah bottleneck tadi:

Perhatiin apa yang dilakukan struktur ini: lo dipaksa melihat masalah dari tiga sudut berbeda sebelum milih solusi. Kalau hipotesisnya masalah kapasitas, solusinya bakal beda dari kalau hipotesisnya masalah flow.

Hipotesis Dulu, Baru Test

Issue tree gak otomatis kasih jawaban, dia kasih tahu lo pertanyaan apa yang harus diselidiki. Setelah pohonnya jadi, lo bentuk hipotesis tentang cabang mana yang jadi penyebab utama, terus lo cari cara buat mengujinya.

Untuk kasus Transjakarta, misalnya, lo bisa pergi langsung ke halte dan observasi. Hitung berapa lama waktu yang dibutuhkan tiap kegiatan tap. Hitung berapa orang dateng per menit. Ukur lebar pintunya. Lihat apakah masalahnya lebih parah di jam sibuk (masalah flow) atau konsisten sepanjang hari (masalah throughput).

Inilah hypothesis-driven approach: lo ngumpulin data yang ditargetkan untuk mengkonfirmasi atau menyangkal tebakan spesifik yang sudah lo tentuin. Jauh lebih efisien daripada ngumpulin semua data yang ada di muka bumi terus bingung sendiri.

Tapi berarti analisis tiap orang bakal berbeda-beda, dong? Betul. Karena proses pembuatan issue tree sangat bergantung dengan cara seorang problem solver menganalisis masalahnya, di situlah letak skillnya diuji dan terlihat.

---

Lihat Sistemnya, Bukan Kejadiannya

Issue tree bagus untuk masalah-masalah yang bisa diukur dan diuji. Tapi banyak masalah di dunia nyata adalah masalah sistem: sebab dan akibatnya saling berhubungan, dan memperbaiki satu hal mengubah hal lain juga. Soal menganalisis masalah dari sistem ini bisa lo baca lebih lengkap di buku Thinking in Systems (2008) karya Donella Meadows.

Kayak waktu lo benerin masalah makan siang tapi malah buka masalah baru korupsi.

Ide Intinya: Feedback Loops

Dalam sebuah sistem, sebab dan akibat itu gak linear tapi seringnya saling memengaruhi. Ada dua jenis loop:

Reinforcing loops (R): hal-hal yang berdampak pada diri sendiri, entah baik maupun buruk.

• Contoh: Lebih banyak penumpang → lebih banyak revenue → lebih banyak bus → lebih banyak penumpang
• Contoh: Bus terlalu penuh → reputasi buruk → penumpang berkurang → pendanaan berkurang → bus makin sedikit → makin penuh

Balancing loops (B): hal-hal yang mendorong ke arah keseimbangan.

• Contoh: Antrian panjang → sebagian penumpang beralih ke ojek → antrian berkurang
• Contoh: Pengalaman buruk → penumpang ganti rute → tekanan di rute ini berkurang

Bottleneck Transjakarta kemungkinan besar terjebak dalam reinforcing loop:

• kemacetan → pengalaman makin buruk → orang menghindari bus di jam sibuk → ketika mereka tetap datang, busnya udah penuh dari halte sebelumnya → makin macet lagi. Muter terus aja tuh kaya drama ijazah palsu.

Leverage Points

Ide paling terkenal dari Donella Meadows adalah leverage points: titik-titik dalam sistem di mana intervensi kecil menghasilkan perubahan besar. Ibarat masuk gorong-gorong sekali, dampaknya sampe hari ini.

Begini cara Meadows menentukan ranking leverage dari yang paling lemah ke paling kuat, dan rasanya emang counter intuitive:

Kebanyakan solusi yang orang usulkan ada di bagian atas daftar (leverage rendah). Perubahan paling berdampak biasanya ada di bagian bawah, tapi juga lebih susah diimplementasi karena butuh mengubah keyakinan atau struktur, bukan sekadar nambah resource.

Makanya "tinggal tambah busnya aja" hampir gak pernah beneran menyelesaikan masalah intinya.

Contoh simplenya coba liat KRL dan MRT. Gua cukup yakin nambah lebar peron sisi di stasiun KRL gak bakal buat penumpangnya ngantri setertib MRT yang sudah dihimbau dari awal MRT ada di Jakarta buat ngantri di garis yang ada. Orang-orangnya sama loh, jenis transportasinya 11:12, tapi beda banget kan behaviornya?

---

Temuin Constraint-nya

Theory of Constraints (The Goal karya Goldratt, 1984) bilang: dalam sistem apapun, selalu ada satu bottleneck yang membatasi total output. Memperbaiki hal lain selain bottleneck itu sia-sia sampai lo benerin yang ganjel itu dulu. Ibarat buru-buru nyiapin 19 juta lapangan kerja tapi manusia-manusianya belum siap buat kerja kan percuma, makanya keputusan untuk gak buru-buru mewujudkan itu ya masuk akal (loh kok jadi dukung).

Lima langkah fokusnya:

1. Identifikasi constraint-nya, apa sebenernya faktor pembatasnya?
2. Eksploitasi, peras output maksimal dari constraint itu tanpa investasi besar
3. Fokus Alokasi Resource ke constraint itu (jangan biarkan hal-hal lain mengganggu si constraint)
4. Elevasi, invest untuk menghilangkan constraint-nya)
5. Ulangi, begitu lo benerin, constraint-nya pindah ke tempat lain, cari yang baru dan selesaikan

Banyak banget, ya? Pasti susah buat kebayang, ya? Coba kita bedah pelan-pelan.

Aplikasinya ke Kasus Transjakarta

Langkah 1

Apa constraint-nya? Scanner? Lebar pintu? Frekuensi bus? Lo harus ngukur dulu. Katakanlah lo nemuin scanner memproses satu tap setiap 2 detik. Dengan kecepatan 2 detik per orang, kerumunan 200 orang butuh 400 detik = hampir 7 menit di depan pintu. Sementara busnya cuma berhenti 3 menit.

Scanner adalah constraint-nya.

Langkah 2

Eksploitasi. Bisa gak lo pre-clear komuter yang sama tiap hari? Bisa gak, ada petugas yang bantu orang yang tap-nya error biar gak nunggu auto-retry? Bisa gak dibuka satu lajur lagi?

Langkah 3

Jangan dulu invest ke bus yang lebih besar (nambah kapasitas) sebelum lo benerin kecepatan proses di pintu. Gak ada gunanya punya bus raksasa kalau boarding rate-nya masih kena bottleneck yang sama. Itu kayak beli panci masak 50 liter padahal kompor lo cuma satu dan apinya kecil.

Langkah 4

Baru sekarang invest. Tambah scanner kedua. Atau ganti ke sistem tap-on-board. Atau pindah ke transit tanpa gate sama sekali.

Langkah 5

Begitu boarding-nya lancar, constraint-nya pindah. Mungkin sekarang jadi masalah pintu yang sempit, atau penumpukan bus di level rute. Nah itu yang diselesaikan selanjutnya. Tapi secara prinsip, selesaikan yang paling membatasi terlebih dahulu.

Coba baca ulang sekali lagi dan coba praktekin versi lo sendiri buat versi solusi buatan lo.

---

Milih di Antara Solusi-Solusi

Sampai sini, lo harusnya udah punya banyak pilihan solusi. Pertanyaan selanjutnya: gimana cara milihnya?

Di sinilah banyak orang pusing, mereka ngerasa solusi terbaik itu udah obvious, tapi begitu ditanya kenapa, mereka gak bisa jelasin kenapa itu yang terbaik. Kayak milih satu kandidat capres karena kandidat yang lain jelek.

Jawabannya: lo butuh kriteria evaluasi. Sebuah standar eksplisit yang lo pake buat membandingkan pilihan-pilihan lo.

Bikin Evaluation Matrix

List kriterianya, kasih bobot sesuai kepentingannya, dan kasih skor tiap pilihan. Contoh untuk Transjakarta:

Inti dari evaluation matrix adalah membuat asumsi lo eksplisit supaya bisa diperdebatkan. Stakeholder yang berbeda akan memberikan bobot yang berbeda ke kriteria yang berbeda pula, subjektif, dan ini wajar. Budget officer bakal kasih bobot tinggi ke biaya, komuter akan kasih bobot tinggi ke pengalaman, dan justru di situlah percakapan yang menarik dimulai. Kalau semuanya harus punya satu pendapat dan gak boleh diskusi, pindah aja ke Indonesia Korea Utara

Bukan berarti siapa yang paling keras suaranya yang menang, tapi siapa yang paling jelas menjelaskan kenapa bobotnya harus begitu.

---

Kesimpulan: The Full Loop

Ini adalah proses yang udah kita laluin dari awal sampai akhir:

1. OBSERVASI gejalanya
            ↓
    2. REFRAME masalahnya
       (Tulis "masalah sebenernya adalah..." dengan lima cara berbeda)
            ↓
    3. BANGUN issue tree
       (Pecah jadi cabang MECE dan kasih pertanyaan-pertanyaan krusialnya.)
            ↓
    4. HIPOTESIS
       (Pilih root cause yang paling mungkin. Bentuk tebakan yang bisa diuji.)
            ↓
    5. INVESTIGASI
       (Kumpulin data yang ditargetkan. Konfirmasi atau sangkal hipotesisnya.)
            ↓
    6. IDENTIFIKASI constraint-nya
       (Faktor tunggal apa yang paling membatasi sistem?)
            ↓
    7. GENERATE solusi di berbagai level
       (Pakai hierarki leverage points-nya Meadows — jangan cuma mikirin parameter)
            ↓
    8. EVALUASI dengan kriteria yang eksplisit
       (Bikin matrix. Bikin asumsi lo kelihatan.)
            ↓
    9. REKOMENDASIKAN
       (Pilih opsi yang paling cocok dengan kriteria. Jelasin trade-off-nya.)

Loop ini dalam prakteknya gak linear, lo bakal sering balik ke langkah sebelumnya. Lo investigasi dan nemu hipotesis lo salah, jadi lo reframe dan bangun ulang pohonnya. Itu normal dan justru lebih sering bakal terjadi. Tujuannya bukan untuk ngikutin langkah-langkahnya dengan sempurna. Tujuan utamanya adalah menyelesaikan masalahnya dengan sistematis supaya kemungkinan lo salah jadi serendah mungkin.

Bedanya orang yang asal jawab sama orang yang beneran mikir bukan di seberapa cepat mereka sampai ke solusi. Tapi di seberapa sadar mereka tentang langkah mana yang lagi mereka jalanin, dan kapan mereka harus balik ke langkah sebelumnya.

---

Key Concepts Summary

---

Recommended Reading

• Goldratt, E. (1984). The Goal. North River Press.
• Gause, D. & Weinberg, G. (1990). Are Your Lights On? Dorset House.
• Meadows, D. (2008). Thinking in Systems. Chelsea Green Publishing.
• Conn, C. & McLean, R. (2019). Bulletproof Problem Solving. Wiley.
• Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
• Stroh, D.P. (2015). Systems Thinking for Social Change. Chelsea Green Publishing.

---

Latihan: Esai Posisi

Apakah pelajar seharusnya diperbolehkan mengakses internet saat mengerjakan ujian?

Tugas lo adalah nulis esai yang menjawab pertanyaan ini. Gak ada batasan minimal atau maksimal. Gak ada batasan format juga. Lo boleh nulis esai biasa, bikin infografis, HTML dengan grafik interaktif, atau apapun yang lo rasa paling efektif buat nyampein argumen lo. Gua gak peduli kemasannya. Gua peduli cara lo mikir.

Satu-satunya aturan yang gak bisa diganggu gugat: lo harus milih satu posisi yang jelas. Setuju, atau tidak setuju. Gak ada "tergantung konteksnya", gak ada "kedua sisi punya argumen yang valid". Lo harus berdiri di satu sisi dan jelasin kenapa sisi lo yang bener.

3 hasil esai terbaik dari masing-masing posisi bakal masuk ke sesi debat 3vs3, sebuah format baru yang gua lagi mau coba ke kalian. Gua butuh orang dari kedua kubu, dan kalau distribusinya gak seimbang, gua bakal turun sendiri ke tim yang kurang orang, bahkan kalau itu artinya 1 lawan 3.

Jadi kalau lo genuinely percaya di satu posisi, bela itu. Kalau lo belum yakin, pilih yang paling bisa lo pertahanin. Yang penting, begitu lo udah milih, pertahanin sampai akhir.

Yang Gua Nilai

Bukan seberapa panjang esai lo. Bukan seberapa rapi formatnya. Tapi:

• Seberapa jelas stand lo dari awal sampai akhir
• Seberapa solid argumen lo ngebuktiin posisi lo
• Seberapa jujur lo mengakui kelemahan posisi lo tanpa lari ke gray area
• Seberapa lo bisa bikin siapapun yang baca ngerasa "bener juga ya"

Pakai Senjata Terbaik Lo

Lo udah pelajari banyak hal dari materi-materi yang udah gua tulis sebelumnya. Praktekin semuanya secara maksimal, termasuk yang lo baru pelajari di chapter kali ini. Kasih tunjuk cari lo bedah dan memecahkan pertanyaan yang ada secara menyeluruh.

Post Test