sim-manajement-book/chapters/outlines/outline-bab-04.md

OUTLINE DETAIL — BAB 4

Analisis Permasalahan Organisasi

Bagian: II — Fondasi Berpikir Manajerial Level: Lanjutan
Estimasi Halaman: 15–18
Reader Outcome: Pembaca mampu melakukan diagnosis masalah organisasi berbasis informasi, membedakan gejala dari akar masalah, dan menyusun rumusan masalah yang siap ditindaklanjuti.

---

SEK 8.1 — PEMBUKA

Hook: Sebuah rumah sakit tipe B di Jawa Tengah mengeluhkan "pasien menumpuk di rawat jalan." Solusi yang diusulkan: tambah dokter. Tetapi analisis alur informasi menunjukkan bahwa penyebab sebenarnya adalah bottleneck di sistem rekam medis yang memakan 40% waktu kunjungan. Menambah dokter tidak menyelesaikan masalah — memperbaiki alur informasi yang menyelesaikannya.

Opening Bridge (dari Bab 7):

Bab 7 membekali manajer dengan BI dan analitik yang memberi insight tentang "apa yang terjadi" dan "mengapa terjadi." Tetapi insight tanpa framing masalah yang benar hanya melahirkan jawaban untuk pertanyaan yang salah. Bab ini mundur selangkah: sebelum mencari solusi SI, manajer harus terlebih dulu mendefinisikan masalah yang benar.

Central Question:

Mengapa mendefinisikan masalah organisasi secara tepat lebih kritis daripada langsung mencari solusi — dan bagaimana teknik problem framing membantu manajer membedakan gejala dari akar masalah?

---

SEK 8.2 — MODEL UTAMA (Gambar 8.1)

Nama Model: Kerangka Problem Framing Manajerial

graph TD
    SYM[Gejala Terlihat] --> PAT[Identifikasi Pola]
    PAT --> ROOT[Akar Masalah]
    GAP[Gap Analysis] --> ROOT
    IDEAL[Kondisi Ideal] --> GAP
    ROOT --> PS[Rumusan Masalah yang Dapat Ditindaklanjuti]
    PS --> HYP[Hipotesis Solusi Awal]
    HYP -.->|validasi data| ROOT

Penjelasan Node:

• Gejala Terlihat — apa yang tampak oleh manajer: keterlambatan, keluhan, penurunan kinerja. Gejala bukan masalah — ia sinyal bahwa ada masalah di bawah permukaan.
• Identifikasi Pola — manajer mencari pola di balik gejala: apakah terjadi berulang? Di unit mana? Sejak kapan? Teknik: fishbone diagram, 5-Why.
• Gap Analysis — membandingkan kondisi saat ini dengan kondisi ideal. Gap inilah yang menjadi masalah sesungguhnya.
• Akar Masalah — penyebab fundamental yang jika diatasi, gejala akan hilang. Bukan gejala itu sendiri.
• Rumusan Masalah — pernyataan masalah yang spesifik, measurable, dan actionable. "Waktu proses X terlalu lama" bukan rumusan yang baik; "Proses verifikasi data memakan 3 hari padahal standar 1 hari karena input manual" lebih baik.
• Hipotesis Solusi — baru di sini SI muncul sebagai kandidat solusi. Solusi SI hanya valid jika akar masalahnya memang terkait informasi/data/proses.

---

SEK 8.3 — DEFINISI KUNCI

📌 Problem Framing Proses mendefinisikan dan membatasi suatu masalah organisasi secara tepat sebelum mencari solusi — memastikan bahwa energi dan sumber daya dialokasikan untuk menyelesaikan masalah yang benar, bukan gejala yang terlihat. Relevansi manajerial: Manajer yang terburu-buru mencari solusi tanpa framing yang tepat berisiko membangun sistem informasi yang canggih tetapi menjawab pertanyaan yang salah.

📌 Root Cause Analysis (Analisis Akar Masalah) Metode sistematis untuk mengidentifikasi penyebab fundamental suatu masalah — berbeda dari gejala atau penyebab antara — menggunakan teknik seperti fishbone diagram, 5-Why, atau fault tree analysis. Relevansi manajerial: Investasi SI yang mengatasi gejala (bukan akar masalah) hanya menghasilkan pengulangan masalah dengan teknologi yang lebih mahal.

📌 Gap Analysis Perbandingan sistematis antara kondisi aktual dan kondisi yang diinginkan (desired state), mengidentifikasi celah (gap) yang harus dijembatani melalui intervensi — termasuk potensi SI. Relevansi manajerial: Gap analysis memaksa manajer untuk mengartikulasikan "seperti apa seharusnya" sebelum mengkritisi "seperti apa saat ini" — tanpa target, kritik menjadi keluhan tanpa arah.

📌 Stakeholder Analysis Identifikasi dan pemetaan semua pihak yang berkepentingan dengan suatu masalah organisasi — kepentingan, pengaruh, dan perspektif mereka terhadap masalah. Relevansi manajerial: Masalah yang sama bisa terlihat berbeda dari perspektif berbeda. Kegagalan SI sering terjadi karena masalah didefinisikan hanya dari perspektif satu stakeholder.

---

SEK 8.4 — KONSEP INTI (6 sub-seksi)

8.4.1 Problem Framing: Mengapa Mendefinisikan Masalah Lebih Kritis dari Solusi

• Argumen: Einstein: "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." Dalam konteks SI, 60%+ proyek gagal bukan karena teknologi, tetapi karena masalah yang dirancang untuk diselesaikan tidak pernah didefinisikan dengan benar.
• Data pendukung: Standish Group (2023) melaporkan bahwa hanya 31% proyek SI yang "berhasil" — dan 45% faktor kegagalan berakar pada requirements yang salah, yang berakar pada problem definition yang salah.
• Contoh: Perusahaan retail menginvestasikan CRM karena "pelanggan tidak loyal." Setelah CRM dipasang, pelanggan tetap pergi — karena masalah sebenarnya adalah kualitas produk, bukan relationship management.

8.4.2 Symptom vs Root Cause: Kesalahan Paling Umum Manajer

• Argumen: Otak manusia secara natural cenderung langsung ke solusi (Kahneman: System 1 thinking). Membedakan gejala dari akar masalah membutuhkan disiplin berpikir sistematis yang jarang dilatih.
• Data pendukung: 72% manajer mengakui pernah mengimplementasikan solusi yang hanya mengatasi gejala, bukan akar masalah (McKinsey Problem Solving Survey, 2022).
• Contoh: Gejala: "Laporan keuangan selalu terlambat." Akar masalah (level 1): "Input data dari cabang terlambat." Akar masalah (level 2): "Cabang tidak memiliki internet stabil." Solusi SI: memperbaiki sistem pelaporan pusat tidak menyelesaikan masalah di tingkat cabang.

8.4.3 Teknik Analisis: Fishbone Diagram, 5-Why, Gap Analysis

• Argumen: Tiga teknik ini membentuk toolkit dasar manajer untuk analisis masalah — tidak membutuhkan keahlian teknis, tetapi membutuhkan disiplin bertanya "mengapa" berulang kali.
• Fishbone (Ishikawa): Mengorganisir kemungkinan penyebab ke dalam kategori (People, Process, Technology, Data, Policy, Environment).
• 5-Why: Bertanya "mengapa?" secara berulang hingga mencapai akar masalah yang tidak bisa di-"mengapa"-kan lagi.
• Gap Analysis: Tabel: Kondisi Saat Ini × Kondisi Ideal × Gap × Implikasi SI.

8.4.4 Stakeholder Analysis dalam Konteks Masalah Organisasi

• Argumen: Masalah organisasi tidak pernah netral — setiap stakeholder memiliki perspektif, kepentingan, dan definisi "masalah" yang berbeda. SI yang dirancang tanpa memahami multi-stakeholder perspective berisiko hanya melayani satu pihak.
• Data pendukung: 48% proyek SI gagal karena "scope tidak mencakup kebutuhan semua stakeholder" (PMI Pulse of the Profession, 2023).
• Contoh: Sistem absensi digital: HR menginginkan data akurat, karyawan menginginkan kemudahan, manajer menginginkan real-time monitoring, serikat pekerja khawatir tentang surveillance. Masalah yang sama, empat perspektif berbeda.

8.4.5 Peran Informasi dalam Konfirmasi/Sanggahan Hipotesis Masalah

• Argumen: Setiap rumusan masalah adalah hipotesis yang harus divalidasi dengan data sebelum solusi SI dirancang. Tanpa validasi, organisasi membangun SI berdasarkan asumsi — bukan fakta.
• Data pendukung: Hanya 35% proposal proyek SI di Indonesia menyertakan data validasi masalah (Kominfo, 2023).
• Contoh: Hipotesis: "Keluhan pelanggan meningkat karena sistem customer service lambat." Data menunjukkan: respons sistem rata-rata 2 detik (baik). Masalah sebenarnya: script customer service tidak dilatihkan — masalah SDM, bukan SI.

8.4.6 Dari Masalah ke Kebutuhan SI: Membangun Jembatan yang Tepat

• Argumen: Tidak semua masalah organisasi membutuhkan SI baru. Jembatan dari "masalah → kebutuhan SI" harus dibangun hanya jika akar masalah terkait: informasi yang tidak tersedia, informasi yang tidak akurat, informasi yang terlambat, atau proses informasi yang tidak efisien.
• Data pendukung: 40% implementasi SI baru sebenarnya bisa diselesaikan dengan optimasi SI yang sudah ada (Gartner, 2023).
• Decision tree: Apakah masalahnya terkait informasi/data/proses? → Ya → Apakah SI yang ada bisa dioptimasi? → Tidak → Baru pertimbangkan SI baru.

---

SEK 8.5 — KOMPARASI (Tabel 8.1)

Judul: "Gejala vs Akar Masalah: 6 Kasus Organisasi Nyata"

No	Gejala Terlihat	Akar Masalah (Root Cause)	Solusi yang Salah (symptom-based)	Solusi yang Benar (root cause-based)
1	Laporan terlambat	Input data dari cabang via Excel manual	Beli software reporting canggih	Digitalisasi input data di cabang
2	Pelanggan mengeluh	Script CS tidak di-update 2 tahun	Ganti platform customer service	Redesign SOP + training CS
3	Stok sering kosong	Data inventory tidak real-time	Tambah safety stock 200%	Implementasi barcode/RFID tracking
4	Karyawan resign tinggi	Beban kerja manual repetitif 60%	Program retensi + bonus	Otomasi proses repetitif
5	Budget overrun proyek	Scope creep tanpa governance	Tambah budget	Change request governance
6	Data tidak akurat	Tidak ada validasi di titik input	Audit data bulanan	Validasi otomatis di form entry

💡 Insight: Setiap kasus di tabel ini menunjukkan pola yang sama: solusi yang populer dan "logis" (column 4) sering salah karena ia merespons gejala, bukan akar masalah. Manajer yang disiplin melakukan root cause analysis sebelum mengusulkan solusi SI menghemat rata-rata 40% biaya proyek.

---

SEK 8.6 — REALITAS LAPANGAN (3 fenomena)

Fenomena 1: "Solutionism" di Proyek SI Indonesia

Pola umum di organisasi Indonesia: rapat membahas masalah, 10 menit kemudian sudah bicara solusi. Studi internal Kemenpan RB (2023) menemukan bahwa 67% proposal proyek SI pemerintah tidak menyertakan analisis masalah terstruktur — langsung ke deskripsi solusi dan spesifikasi teknis. Hasilnya: sistem yang dibangun tidak dipakai karena tidak menyelesaikan masalah yang benar.

💡 Insight: "Solutionism" — kecanduan langsung ke solusi — adalah musuh utama problem framing yang baik. Organisasi perlu membudayakan: "jangan bicara solusi sampai masalah benar-benar dipahami."

Fenomena 2: Fishbone yang Bagus di Theory, Sulit di Praktik

Fishbone diagram diajarkan di hampir semua pelatihan manajemen, tetapi jarang digunakan secara efektif dalam konteks proyek SI. Survei di 120 perusahaan manufaktur Jawa Tengah (Universitas Diponegoro, 2022) menunjukkan bahwa 78% peserta pelatihan mengakui tahu fishbone diagram, tetapi hanya 12% yang pernah menggunakannya di proyek nyata. Alasan: "terlalu sederhana terlihat," "hasil diskusinya subjektif," "tidak ada yang memimpin proses."

💡 Insight: Tools analisis masalah tidak gagal karena terlalu sederhana — ia gagal karena tidak ada pemimpin yang memfasilitasi proses dengan disiplin dan memastikan output-nya di-follow-up. Fishbone tanpa fasilitator dan follow-up hanya menjadi pajangan flipchart.

Fenomena 3: Ketika Target Corporation Gagal Membaca Early Warning

Kasus kebocoran data Target Corporation (2013, 40 juta kartu kredit): SI security Target sebenarnya sudah mendeteksi anomali 12 hari sebelum breach dieksfiltrasi. Alert system bekerja. Tetapi organisasi gagal di problem framing: alert diperlakukan sebagai "noise biasa" bukan "sinyal masalah serius." Root cause bukan kegagalan SI — melainkan kegagalan culture: tidak ada eskalasi clear, tidak ada decision owner untuk alert.

💡 Insight: SI yang sempurna sekalipun tidak berguna jika organisasi tidak memiliki budaya eskalasi dan problem framing yang menghubungkan alert sistem ke tindakan manusia yang tepat.

---

SEK 8.7 — SALAH KAPRAH (⚠️)

⚠️ Jebakan 1: "Masalahnya jelas: kita butuh sistem baru"

Mengapa salah: Ini adalah solutionism klasik. "Butuh sistem baru" bukan definisi masalah — ia premature solution. Masalah harus didefinisikan dalam terms: apa yang terjadi, seharusnya bagaimana, mengapa gap ada, dan siapa yang terdampak. Baru kemudian ditentukan apakah SI baru diperlukan. Koreksi: Sebelum membahas solusi SI, tanyakan: "Apakah kita sudah memahami akar masalahnya? Apakah masalah ini terkait informasi? Apakah SI yang ada sudah dioptimasi?"

⚠️ Jebakan 2: "Kalau semua setuju ini masalahnya, pasti benar"

Mengapa salah: Konsensus bukan bukti. Groupthink bisa membuat seluruh tim sepakat atas definisi masalah yang salah. Kesamaan perspektif dalam kelompok homogen justru mengurangi kemungkinan menemukan masalah yang benar. Koreksi: Validasi definisi masalah dengan data, bukan dengan voting. Undang perspektif berbeda: end-user, front-liner, IT, pelanggan — bukan hanya manajer di ruang rapat.

⚠️ Jebakan 3: "Cukup tanya pimpinan untuk tahu apa masalahnya"

Mengapa salah: Masalah yang terlihat dari lantai C-suite sangat berbeda dari masalah yang dialami front-liner. Pimpinan sering melihat gejala aggregated (KPI turun), bukan akar masalah operational (proses X bottleneck). Koreksi: Gunakan multi-method: wawancara top-down + observasi bottom-up + data analysis. Triangulasi sumber memastikan definisi masalah yang lebih akurat.

---

SEK 8.8 — STUDI KASUS (📊)

📊 Studi Kasus Dasar — SIMRS: Bottleneck Informasi di Rawat Jalan

❌ Kondisi Awal: Rumah sakit tipe B di Jawa Tengah: antrian rawat jalan rata-rata 3 jam. Keluhan pasien meningkat 45% dalam 6 bulan. Manajemen mengajukan proposal: "tambah 5 dokter spesialis."

✅ Setelah Problem Framing: Analisis fishbone + observasi waktu menunjukkan: dari 3 jam antrian, hanya 25 menit di-spend di konsultasi dokter. Sisanya: registrasi manual (45 menit), pencarian rekam medis fisik (40 menit), input data ganda di 3 sistem berbeda (30 menit). Akar masalah: bottleneck informasi di proses administratif, bukan kekurangan dokter.

Fase Kunjungan	Waktu Sebelum	Setelah SI Terintegrasi
Registrasi	45 menit	5 menit (self-service kiosk)
Pencarian rekam medis	40 menit	0 (electronic medical record)
Waktu konsultasi	25 menit	25 menit (tidak berubah)
Input data ganda	30 menit	0 (single entry)
Total	180 menit	55 menit

💡 Pelajaran: Menambah dokter adalah solusi yang mahal dan hanya mengurangi 25 menit dari 180 menit. Problem framing yang benar menemukan bahwa 85% waktu bukan di konsultasi — dan SI yang tepat bisa menghilangkan bottleneck informasi tanpa menambah tenaga medis.

📊 Studi Kasus Lanjutan — Target Corporation: Kegagalan Membaca Sinyal Masalah

❌ Kondisi Awal (2013): Sistem keamanan FireEye di Target mendeteksi malware pada 30 November 2013 dan mengirimkan alert. Tim di Bangalore menerima alert dan meneruskan ke tim Minneapolis. Alert diklasifikasikan sebagai "routine" karena volume alert harian sudah sangat tinggi (ratusan per hari).

✅ Apa yang Seharusnya Terjadi: Organisasi dengan problem framing yang baik akan memiliki: (1) framework klasifikasi alert dengan severity level, (2) escalation path yang jelas, (3) decision owner untuk setiap severity level, (4) budaya "better safe than sorry" untuk security alerts.

Dimensi	Aktual	Seharusnya
Alert response	Diabaikan selama 12 hari	Eskalasi dalam 4 jam
Escalation path	Tidak jelas	Severity Level → Response Team → CTO
Decision owner	Tidak ditentukan	CISO dengan otoritas shutdown
Budaya	"Noise filtering"	"Zero tolerance for security anomaly"
Dampak	40 juta kartu kredit breach	Breach bisa dicegah atau diminimalkan

💡 Pelajaran: Target memiliki SI keamanan yang excellent — ia mendeteksi serangan. Masalahnya bukan SI; masalahnya adalah organisasi tidak memiliki problem framing culture yang menghubungkan deteksi masalah ke eskalasi dan tindakan. SI tanpa governance respons adalah alarm yang berbunyi di ruangan kosong.

---

SEK 8.9 — TEMPLATE PRAKTIS (🔧)

Nama: Problem Statement Canvas

TEMPLATE A.8 — PROBLEM STATEMENT CANVAS

Tanggal             : ________________________________________
Tim Analisis        : ________________________________________
Organisasi/Unit     : ________________________________________

═══════════════════════════════════════════════════════════════

1. GEJALA YANG TERLIHAT (apa yang dikeluhkan/dirasakan?)
   ________________________________________
   ________________________________________
   ________________________________________

2. DATA PENDUKUNG GEJALA (bukti kuantitatif)
   Metrik          : ________________________________________
   Angka saat ini  : ________________________________________
   Benchmark/target: ________________________________________

3. ANALISIS 5-WHY
   Mengapa 1: ________________________________________
   Mengapa 2: ________________________________________
   Mengapa 3: ________________________________________
   Mengapa 4: ________________________________________
   Mengapa 5: ________________________________________)
   
   → AKAR MASALAH: ________________________________________

4. STAKEHOLDER YANG TERDAMPAK
   | Stakeholder | Perspektif terhadap masalah | Dampak |
   |-------------|---------------------------|--------|
   | ________    | _________________________ | ______ |
   | ________    | _________________________ | ______ |
   | ________    | _________________________ | ______ |

5. GAP ANALYSIS
   Kondisi saat ini         : ________________________________________
   Kondisi yang diinginkan  : ________________________________________
   Gap                      : ________________________________________

6. RUMUSAN MASALAH (specific, measurable, actionable)
   "________________________________________
    ________________________________________"

7. APAKAH MASALAH INI TERKAIT INFORMASI/DATA/PROSES?
   [ ] Ya → lanjutkan ke analisis kebutuhan SI (Bab 9)
   [ ] Tidak → solusi non-SI yang diperlukan: ________

8. HIPOTESIS SOLUSI AWAL
   ________________________________________
   Perlu divalidasi dengan: ________________________________________

---

SEK 8.10 — PETA KONSEP (Gambar 8.2)

mindmap
  root((Analisis Permasalahan Organisasi))
    Problem Framing
      Gejala vs Akar Masalah
      Definisi Masalah
      Spesifik & Actionable
    Teknik Analisis
      Fishbone Diagram
      5-Why Analysis
      Gap Analysis
      Stakeholder Mapping
    Validasi
      Data-driven Validation
      Multi-perspective
      Triangulasi Sumber
    Anti-pattern
      Solutionism
      Groupthink
      Single-perspective
    Jembatan ke SI
      Masalah informasi?
      Optimasi vs SI baru
      Requirements seed

---

SEK 8.11 — RANGKUMAN

Takeaway utama:

1. Mendefinisikan masalah yang benar lebih kritis daripada langsung mencari solusi SI — 60%+ kegagalan proyek SI berakar pada problem definition yang salah.
2. Gejala bukan masalah. Manajer harus menerapkan disiplin membedakan apa yang terlihat (symptom) dari apa yang mendasari (root cause) menggunakan teknik fishbone, 5-Why, dan gap analysis.
3. Stakeholder analysis memastikan masalah didefinisikan dari multi-perspective — bukan hanya dari perspektif yang paling vokal atau paling berkuasa.
4. Setiap rumusan masalah adalah hipotesis yang harus divalidasi dengan data sebelum solusi SI dirancang.
5. Tidak semua masalah organisasi membutuhkan SI baru — 40% masalah bisa diselesaikan dengan optimasi SI yang sudah ada atau intervensi non-SI.
6. "Solutionism" — kecanduan langsung ke solusi — adalah anti-pattern paling berbahaya dalam proyek SI. Organisasi perlu membudayakan: "framing dulu, solusi kemudian."
7. SI yang canggih tanpa budaya eskalasi dan problem framing hanyalah teknologi mahal yang berbunyi tanpa ada yang mendengar.

Closing Bridge (ke Bab 9):

Setelah masalah organisasi didefinisikan dengan benar, pertanyaan berikutnya: informasi apa yang dibutuhkan untuk menyelesaikannya? Bab 9 membahas cara memetakan kebutuhan informasi per level manajemen — menjadi jembatan antara "masalah yang dipahami" dan "SI yang dirancang."

🔥 Final Statement:

"Manajer yang piawai bukan yang paling cepat menemukan solusi, melainkan yang paling sabar mendefinisikan masalah yang benar sebelum beranjak ke solusi."

---

SEK 8.12 — LATIHAN & REFLEKSI

Pertanyaan Refleksi:

1. Berikan contoh di organisasi Anda di mana solusi SI diterapkan tetapi masalah tetap ada karena problem framing yang salah.
2. Mengapa orang cenderung langsung bicara solusi daripada menganalisis masalah terlebih dahulu? Kaitkan dengan konsep System 1 thinking (Kahneman).
3. Jika Anda diminta menganalisis masalah "penjualan menurun," demonstrasikan analisis 5-Why hingga menemukan akar masalah.
4. Diskusikan: apakah fishbone diagram masih relevan di era big data dan AI, atau sudah ketinggalan zaman? Argumentasikan.

Tugas Artefak:

Gunakan Template A.8 (Problem Statement Canvas) untuk menganalisis satu masalah nyata di organisasi yang Anda kenal. Lengkapi semua 8 section, termasuk validasi apakah masalah terkait informasi atau tidak.

---

REFERENSI BAB 8

1. Kendall, K. E., & Kendall, J. E. (2019). Systems Analysis and Design (10th ed.). Pearson.
2. Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2022). Systems Analysis and Design in a Changing World (8th ed.). Cengage Learning.
3. Parviainen, P., Tihinen, M., Kääriäinen, J., & Teppola, S. (2022). Tackling the digitalization challenge. International Journal of Information Systems and Project Management, 5(1), 63–77.
4. Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
5. Minto, B. (2002). The Pyramid Principle. FT Prentice Hall.
6. Standish Group. (2023). Chaos report 2023: Beyond infinity. The Standish Group International.
7. McKinsey & Company. (2022). Problem solving survey: How top teams define and solve problems. McKinsey.
8. PMI. (2023). Pulse of the Profession 2023. Project Management Institute.
9. Gartner Research. (2023). IT project failure analysis. Gartner, Inc.
10. Ishikawa, K. (1985). What is Total Quality Control? The Japanese Way. Prentice-Hall.
11. Kominfo. (2023). Laporan evaluasi proyek SI pemerintah. Kementerian Kominfo RI.
12. Laudon, K. C., & Laudon, J. P. (2022). Management Information Systems (17th ed.). Pearson.

---

QUALITY GATES CHECK

[✓] Gate 1 — THINK   : Mengubah pandangan dari "langsung cari solusi" ke "framing masalah dulu baru solusi"
[✓] Gate 2 — APPLY   : Template A.8 langsung applicable untuk analisis masalah organisasi nyata
[✓] Gate 3 — REFLECT : Pembaca merefleksikan apakah organisasinya sering terjebak solutionism