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

# BAB 4 — Analisis Permasalahan Organisasi


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

---

## 4.1 Pembuka

Bab 6 membangun fondasi penting: data bukan sekadar angka yang tersimpan dalam sistem, melainkan aset organisasi yang diukur kualitasnya melalui empat dimensi — akurasi, kelengkapan, konsistensi, dan ketepatan waktu. Template A.6 membantu Anda mengaudit kualitas data yang ada. Tetapi ada satu pertanyaan yang belum terjawab di sana: **data berkualitas tinggi untuk menjawab pertanyaan apa?** Data yang valid dan lengkap tetap tidak berguna jika pertanyaan yang ingin dijawab itu sendiri salah atau kabur. Di sinilah banyak manajer terjebak — membangun sistem informasi yang mahal untuk menjawab masalah yang didefinisikan secara terburu-buru.

Sebuah rumah sakit tipe B di Jawa Tengah mengeluhkan "pasien menumpuk di rawat jalan." Solusi yang diusulkan manajemen: tambah 5 dokter spesialis — investasi miliaran rupiah. Tetapi analisis alur informasi menunjukkan bahwa dari 3 jam rata-rata waktu kunjungan, hanya 25 menit dihabiskan untuk konsultasi dokter. Sisanya: registrasi manual, pencarian rekam medis fisik, dan *input* data ganda di tiga sistem berbeda. Menambah dokter tidak menyelesaikan masalah — memperbaiki alur informasi yang menyelesaikannya. Solusi yang benar dimulai dari definisi masalah yang benar.

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

---

## 4.2 Model Utama

### Gambar 4.1 — Kerangka *Problem Framing* Manajerial

```mermaid
graph TD
    SYM[" Gejala Terlihat<br/>(keluhan, penurunan KPI, keterlambatan)"]
    PAT[" Identifikasi Pola<br/>(fishbone, 5-Why)"]
    IDEAL["Kondisi Ideal"]
    GAP[" Gap Analysis"]
    ROOT[" Akar Masalah"]
    PS[" Rumusan Masalah<br/>(spesifik, measurable, actionable)"]
    HYP["Hipotesis Solusi Awal"]

    SYM --> PAT
    PAT --> ROOT
    IDEAL --> GAP
    GAP --> ROOT
    ROOT --> PS
    PS --> HYP
    HYP -.->|"validasi data"| ROOT

    style SYM fill:#4a1a5c,color:#ffffff
    style PAT fill:#4a1a5c,color:#ffffff
    style IDEAL fill:#7a4a8c,color:#ffffff
    style GAP fill:#7a4a8c,color:#ffffff
    style ROOT fill:#4a1a5c,color:#ffffff
    style PS fill:#4a1a5c,color:#ffffff
    style HYP fill:#7a4a8c,color:#ffffff
```

**Gambar 4.1 — Kerangka *Problem Framing* Manajerial: alur dari gejala yang terlihat menuju hipotesis solusi, dengan *feedback loop* validasi data.**

Model ini mencerminkan satu kebenaran yang sering dilanggar: solusi harus datang terakhir, bukan pertama.

1. **Gejala Terlihat** — Apa yang tampak oleh manajer: antrian panjang, laporan terlambat, keluhan pelanggan meningkat, *turnover* tinggi. Gejala bukan masalah — ia sinyal bahwa ada sesuatu di bawah permukaan yang perlu digali.

2. **Identifikasi Pola** — Manajer mencari pola di balik gejala: apakah terjadi berulang? Di unit mana? Sejak kapan? Teknik *fishbone diagram* dan *5-Why* membantu memisahkan penyebab dari gejala secara sistematis.

3. **Kondisi Ideal + Gap Analysis** — Membandingkan kondisi saat ini dengan kondisi yang seharusnya. Tanpa gambaran kondisi ideal, kritik terhadap kondisi saat ini hanya menjadi keluhan tanpa arah. *Gap* antara keduanya adalah masalah sesungguhnya.

4. **Akar Masalah** — Penyebab yang paling mendasar — jika diatasi, gejala akan hilang. Akar masalah sering tidak terlihat langsung dan membutuhkan penggalian berlapis.

5. **Rumusan Masalah** — Pernyataan yang spesifik, *measurable*, dan *actionable*. "Proses lambat" bukan rumusan yang baik. "Proses verifikasi data memakan 3 hari padahal standar 1 hari karena *input* manual dari 4 sumber berbeda" jauh lebih berguna.

6. **Hipotesis Solusi** — Baru di sini SI muncul sebagai kandidat. Solusi SI hanya valid jika akar masalahnya memang terkait informasi, data, atau proses pengelolaan informasi. Garis putus-putus ke akar masalah menegaskan: hipotesis solusi harus divalidasi dengan data — bukan diterima begitu saja.

---

## 4.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 (Minto, 2002).
**Relevansi manajerial:** Manajer yang terburu-buru mencari solusi tanpa *framing* yang tepat berisiko membangun sistem informasi yang canggih tetapi menjawab pertanyaan yang salah. Investasi puluhan miliar untuk solusi SI yang salah sasaran tidak bisa di-*undo* dengan mudah.

---

***Root Cause Analysis* (Analisis Akar Masalah)**
Metode sistematis untuk mengidentifikasi penyebab paling mendasar suatu masalah — berbeda dari gejala atau penyebab antara — menggunakan teknik seperti *fishbone diagram*, *5-Why*, atau *fault tree analysis* (Ishikawa, 1985).
**Relevansi manajerial:** Investasi SI yang mengatasi gejala (bukan akar masalah) hanya menghasilkan pengulangan masalah dengan teknologi yang lebih mahal. Sistem baru dipasang, masalah yang sama muncul lagi — dan manajer menyalahkan "sistemnya yang jelek," padahal masalahnya tidak pernah didefinisikan dengan benar sejak awal.

---

***Gap Analysis***
Perbandingan sistematis antara kondisi aktual dan kondisi yang diinginkan (*desired state*), mengidentifikasi celah yang harus dijembatani melalui intervensi — termasuk potensi SI (Kendall & Kendall, 2019).
**Relevansi manajerial:** *Gap analysis* memaksa manajer mengartikulasikan "seperti apa seharusnya" sebelum mengkritisi "seperti apa saat ini." Tanpa target yang jelas, kritik menjadi keluhan tanpa arah dan solusi menjadi tembakan tanpa sasaran.

---

***Stakeholder Analysis***
Identifikasi dan pemetaan semua pihak yang berkepentingan dengan suatu masalah organisasi — kepentingan, pengaruh, dan perspektif mereka terhadap masalah tersebut (Satzinger et al., 2022).
**Relevansi manajerial:** Masalah yang sama terlihat berbeda dari perspektif berbeda. Kegagalan SI sering terjadi karena masalah didefinisikan hanya dari perspektif satu *stakeholder* — biasanya yang paling vokal atau paling berkuasa — sementara *stakeholder* lain yang terdampak langsung tidak pernah ditanya.

---

## 4.4 Konsep Inti

### 4.4.1 *Problem Framing*: Mengapa Mendefinisikan Masalah Lebih Kritis dari Solusi

Einstein pernah menyatakan: "Jika saya punya satu jam untuk menyelesaikan masalah, saya akan menghabiskan 55 menit memikirkan masalahnya dan 5 menit memikirkan solusinya." Dalam konteks SI, perbandingan ini bahkan lebih ekstrem: solusi SI yang salah sasaran bisa menghabiskan miliaran rupiah dan bertahun-tahun implementasi — untuk menyelesaikan masalah yang sebenarnya tidak ada.

Standish Group (2023) melaporkan bahwa hanya 31% proyek SI yang dikategorikan "berhasil." Dari proyek yang gagal, 45% faktor kegagalannya berakar pada *requirements* yang salah — yang jika ditelusuri lebih dalam, berakar pada definisi masalah yang tidak pernah dilakukan dengan benar. Organisasi melompat dari "kami punya masalah" langsung ke "kami butuh sistem baru" tanpa melalui proses *framing* yang memastikan masalah yang diselesaikan adalah masalah yang tepat.

Contoh: perusahaan *retail* menginvestasikan CRM senilai Rp2 miliar karena "pelanggan tidak loyal." Setelah CRM dipasang dan berjalan 12 bulan, pelanggan tetap pergi. Analisis yang seharusnya dilakukan *sebelum* membeli CRM menunjukkan bahwa masalah sebenarnya adalah kualitas produk yang menurun — pelanggan pergi bukan karena *relationship* yang buruk, melainkan karena produk yang kalah dari kompetitor. CRM tidak bisa memperbaiki kualitas produk.

### 4.4.2 Gejala vs Akar Masalah: Kesalahan yang Paling Sering Terjadi

Otak manusia secara natural cenderung langsung melompat ke solusi — Kahneman (2011) menyebutnya *System 1 thinking*: cepat, intuitif, tetapi sering salah di masalah yang kompleks. Membedakan gejala dari akar masalah membutuhkan *System 2 thinking*: lambat, deliberatif, dan membutuhkan disiplin.

72% manajer mengakui pernah mengimplementasikan solusi yang hanya mengatasi gejala, bukan akar masalah (McKinsey, 2022). Angka ini tidak mengejutkan — tekanan waktu, tekanan atasan, dan bias kognitif semuanya mendorong manajer untuk "bertindak cepat" alih-alih "berpikir tepat."

Contoh berlapis:
- **Gejala:** "Laporan keuangan selalu terlambat."
- **Solusi cepat (salah):** Beli *software reporting* yang lebih canggih.
- **Akar masalah level 1:** *Input* data dari cabang terlambat.
- **Akar masalah level 2:** Cabang tidak memiliki koneksi internet yang stabil.
- **Akar masalah level 3:** *Budget* infrastruktur IT cabang dipangkas 2 tahun lalu.
- **Solusi yang tepat:** Alokasikan ulang *budget* infrastruktur — bukan beli *software* baru di pusat.

Setiap level "mengapa" membawa manajer lebih dekat ke akar masalah — dan lebih jauh dari solusi intuitif pertama yang terlintas.

### 4.4.3 Teknik Analisis: *Fishbone*, *5-Why*, dan *Gap Analysis*

Tiga teknik ini membentuk *toolkit* dasar manajer untuk analisis masalah. Tidak membutuhkan keahlian teknis, tetapi membutuhkan disiplin bertanya "mengapa" berulang kali dan kesabaran untuk tidak melompat ke solusi.

***Fishbone Diagram* (Ishikawa)**
Mengorganisir kemungkinan penyebab ke dalam kategori. Dalam konteks SI, enam kategori yang relevan:

| Kategori | Pertanyaan Panduan | Contoh Penyebab |
|----------|--------------------|-----------------|
| *People* | Siapa yang terlibat dan apa perannya? | *Data literacy* rendah, resistensi perubahan |
| *Process* | Proses mana yang bermasalah? | SOP tidak di-*update*, proses manual redundan |
| *Technology* | SI/infrastruktur mana yang terlibat? | Sistem *legacy*, integrasi gagal |
| *Data* | Data apa yang terlibat dan bagaimana kualitasnya? | Data duplikat, tidak *real-time* |
| *Policy* | Kebijakan apa yang mempengaruhi? | Regulasi, *governance* tidak jelas |
| *Environment* | Faktor eksternal apa yang berpengaruh? | Pasar berubah, kompetitor baru |

**Tabel 8.1 — Kategori *fishbone diagram* dalam konteks SI: pertanyaan panduan dan contoh penyebab.**

***5-Why Analysis***
Teknik paling sederhana namun paling efektif: bertanya "mengapa?" secara berulang — minimal 5 kali — hingga mencapai penyebab yang tidak bisa di-"mengapa"-kan lagi. Kuncinya: setiap jawaban harus berdasarkan fakta atau data, bukan asumsi.

***Gap Analysis***
Membandingkan kondisi saat ini dengan kondisi ideal dalam format terstruktur. Hasilnya menjadi *input* langsung untuk rumusan masalah dan identifikasi kebutuhan SI.

### 4.4.4 *Stakeholder Analysis*: Masalah Siapa yang Sedang Diselesaikan?

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 — biasanya pihak yang paling berkuasa di ruang rapat, bukan pihak yang paling terdampak.

48% proyek SI gagal karena *scope* tidak mencakup kebutuhan semua *stakeholder* (PMI, 2023). Contoh: sistem absensi digital di perusahaan manufaktur.

| *Stakeholder* | Perspektif terhadap Masalah | Ekspektasi terhadap Solusi |
|---------------|---------------------------|---------------------------|
| HR | Data kehadiran tidak akurat — sulit menghitung gaji | Akurasi data 100%, integrasi dengan *payroll* |
| Karyawan | Absensi manual merepotkan, sering lupa | Kemudahan — *tap* dan selesai |
| Manajer produksi | Tidak tahu siapa yang hadir *real-time* | *Dashboard* kehadiran per *shift* |
| Serikat pekerja | Khawatir sistem digunakan untuk *surveillance* | Transparansi penggunaan data, hak akses |

**Tabel 8.2 — *Stakeholder analysis* sistem absensi digital: satu masalah, empat perspektif berbeda.**

Jika hanya perspektif HR yang dipertimbangkan, sistem mungkin akurat tetapi tidak ramah pengguna — dan karyawan menolak menggunakannya. Jika hanya perspektif manajer yang dipertimbangkan, sistem mungkin menampilkan *dashboard real-time* tetapi menimbulkan konflik dengan serikat pekerja. *Problem framing* yang baik mengakomodasi semua perspektif — minimal yang kritis.

### 4.4.5 Validasi Hipotesis: Data Harus Bicara Sebelum Solusi Dirancang

Setiap rumusan masalah adalah hipotesis yang harus divalidasi dengan data sebelum solusi SI dirancang. Tanpa validasi, organisasi membangun SI berdasarkan asumsi — dan asumsi yang salah menghasilkan solusi yang salah.

Hanya 35% proposal proyek SI di Indonesia menyertakan data validasi masalah (Kominfo, 2023). Sisanya langsung ke deskripsi solusi dan spesifikasi teknis — seolah-olah masalah sudah pasti benar tanpa perlu dibuktikan.

Contoh validasi yang mengubah arah solusi:
- **Hipotesis awal:** "Keluhan pelanggan meningkat karena sistem *customer service* lambat."
- **Data validasi:** Rata-rata waktu respons sistem: 2 detik (dalam standar). Rata-rata waktu penyelesaian tiket: 48 jam (jauh di atas standar 4 jam).
- **Temuan:** Sistem responsif, tetapi *script customer service* tidak di-*update* selama 2 tahun — agen menjawab pertanyaan baru dengan jawaban lama. Masalah SDM dan SOP, bukan SI.
- **Solusi yang tepat:** *Redesign* SOP + pelatihan agen, bukan ganti platform *customer service*.

### 4.4.6 Dari Masalah ke Kebutuhan SI: Jembatan yang Harus Dibangun dengan Hati-hati

Tidak semua masalah organisasi membutuhkan SI baru. 40% implementasi SI baru sebenarnya bisa diselesaikan dengan optimasi SI yang sudah ada (Gartner, 2023). Jembatan dari "masalah" ke "kebutuhan SI" harus dibangun hanya jika akar masalah memenuhi setidaknya satu dari empat kriteria:

1. **Informasi tidak tersedia** — manajer membutuhkan data yang saat ini tidak dikumpulkan
2. **Informasi tidak akurat** — data ada tetapi tidak bisa dipercaya (lihat Bab 3)
3. **Informasi terlambat** — data akurat tetapi datang setelah keputusan harus diambil
4. **Proses informasi tidak efisien** — data ada dan akurat, tetapi proses pengolahan memakan waktu dan sumber daya yang tidak proporsional

Jika akar masalah tidak terkait keempat kriteria ini — misalnya masalah budaya, masalah kompetensi SDM, atau masalah strategi bisnis — maka SI baru bukan solusinya, dan memaksakan SI hanya menambah kompleksitas tanpa menyelesaikan masalah.

---

## 4.5 Komparasi

### Tabel 4.3 — Gejala vs Akar Masalah: 6 Kasus Organisasi

| No | Gejala Terlihat | Akar Masalah | Solusi Salah (berbasis gejala) | Solusi Tepat (berbasis akar masalah) |
|----|----------------|-------------|-------------------------------|-------------------------------------|
| 1 | Laporan keuangan terlambat | *Input* data dari cabang via Excel manual, koneksi tidak stabil | Beli *software reporting* canggih di pusat | Digitalisasi *input* data dan perbaiki infrastruktur cabang |
| 2 | Keluhan pelanggan meningkat | SOP *customer service* tidak di-*update* 2 tahun | Ganti platform *customer service* | *Redesign* SOP + pelatihan agen CS |
| 3 | Stok sering kosong | Data *inventory* tidak *real-time* — *stock count* manual mingguan | Tambah *safety stock* 200% | Implementasi *barcode/RFID tracking real-time* |
| 4 | *Turnover* karyawan tinggi | 60% waktu kerja dihabiskan untuk tugas manual repetitif | Program retensi + bonus | Otomasi proses repetitif |
| 5 | *Budget overrun* proyek SI | *Scope creep* tanpa *governance* — setiap *stakeholder* menambah fitur | Tambah *budget* proyek | Terapkan *change request governance* |
| 6 | Data di *dashboard* tidak akurat | Tidak ada validasi otomatis di titik *input* data | Audit data manual setiap bulan | Implementasi validasi otomatis di *form entry* |

**Insight:** Pola yang konsisten di keenam kasus: solusi yang "logis" dan populer (kolom 4) hampir selalu merespons gejala, bukan akar masalah. Solusi berbasis gejala menambah biaya tanpa menghilangkan masalah — ia hanya menyembunyikannya di balik teknologi atau anggaran yang lebih besar.

---

## 4.6 Realitas Lapangan

### Fenomena 1: *Solutionism* di Proyek SI Indonesia

Pola yang terlalu umum: rapat membahas masalah, 10 menit kemudian seluruh diskusi sudah tentang solusi. Spesifikasi teknis dibahas sebelum masalah didefinisikan. Vendor sudah dipanggil sebelum *requirements* jelas.

Studi Kemenpan RB (2023) menemukan bahwa 67% proposal proyek SI pemerintah tidak menyertakan analisis masalah terstruktur — langsung ke deskripsi solusi dan spesifikasi teknis. Dokumen 100 halaman yang 95 halamannya berisi arsitektur sistem dan 5 halaman berisi "latar belakang masalah" yang generik: "pengelolaan data belum optimal, perlu sistem yang terintegrasi."

Hasilnya bisa diprediksi: sistem dibangun, diluncurkan dengan upacara, digunakan beberapa bulan, lalu ditinggalkan — karena tidak menyelesaikan masalah yang benar. Atau lebih buruk: sistem yang dibangun menambah masalah baru (beban *input* data ganda, proses yang lebih rumit dari sebelumnya).

**Insight:** *Solutionism* — kecanduan langsung melompat ke solusi — adalah anti-*pattern* paling mahal dalam proyek SI. Organisasi perlu membudayakan disiplin: "jangan bicara solusi sampai masalah benar-benar dipahami dan divalidasi."

### Fenomena 2: *Fishbone* yang Bagus di Teori, Sulit di Praktik

*Fishbone diagram* diajarkan di hampir semua pelatihan manajemen dan *quality improvement*. 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 yang paling sering disampaikan: "Terlalu sederhana — terlihat tidak serius untuk proposal jutaan rupiah." "Hasilnya subjektif — tergantung siapa yang di ruangan." "Tidak ada yang memimpin prosesnya — kami gambar tulang ikan, lalu bingung mau apa selanjutnya."

Ironi: *tools* yang "terlalu sederhana" ini, jika digunakan dengan fasilitator yang disiplin dan data yang mendukung, jauh lebih efektif dari analisis teknis yang rumit tetapi tidak pernah menyentuh akar masalah.

**Insight:** *Tools* analisis masalah tidak gagal karena kesederhanaan — ia gagal karena tidak ada pemimpin yang memfasilitasi proses dengan disiplin dan memastikan *output*-nya ditindaklanjuti. *Fishbone* tanpa fasilitator dan *follow-up* hanya menjadi pajangan *flipchart* yang difoto lalu dilupakan.

### Fenomena 3: Target Corporation — SI yang Sempurna, Respons yang Gagal

Desember 2013. Sistem keamanan FireEye di Target Corporation mendeteksi *malware* pada 30 November dan mengirimkan *alert*. Tim keamanan di Bangalore menerima *alert* dan meneruskan ke tim di Minneapolis. *Alert* diklasifikasikan sebagai "*routine*" — karena volume *alert* harian sudah sangat tinggi (ratusan per hari) dan tidak ada *framework* yang membedakan *alert* kritis dari *noise*.

Dua belas hari kemudian, data 40 juta kartu kredit pelanggan Target berhasil diekstraksi oleh penyerang. Kerugian: $292 juta dalam biaya langsung, CEO mengundurkan diri, kepercayaan pelanggan hancur.

Kegagalan Target bukan kegagalan SI — sistem FireEye mendeteksi serangan dengan benar dan tepat waktu. Kegagalannya ada di organisasi: tidak ada *escalation path* yang jelas, tidak ada *decision owner* untuk *security alert*, dan tidak ada budaya "*better safe than sorry*" untuk anomali keamanan.

**Insight:** SI yang sempurna sekalipun tidak berguna jika organisasi tidak memiliki *problem framing culture* yang menghubungkan deteksi masalah ke eskalasi dan tindakan. Alarm yang berbunyi di ruangan kosong bukan masalah alarm.

---

## 4.7 Salah Kaprah

***"Masalahnya jelas — yang dibutuhkan adalah sistem baru"***

> *"Tidak perlu analisis lagi. Masalahnya sudah jelas: sistem lama tidak memadai. Kita butuh ERP baru."*

"Butuh sistem baru" bukan definisi masalah — ia adalah *premature solution*. Masalah harus didefinisikan dalam empat elemen: apa yang terjadi, seharusnya bagaimana, mengapa *gap* itu ada, dan siapa yang terdampak. Baru kemudian dievaluasi apakah SI baru diperlukan — atau apakah SI yang ada bisa dioptimasi, atau bahkan apakah masalahnya membutuhkan SI sama sekali.

**Koreksi:** Sebelum membahas solusi SI, jawab tiga pertanyaan diagnostik: "Apakah akar masalahnya sudah teridentifikasi?" → "Apakah akar masalah terkait informasi/data/proses?" → "Apakah SI yang ada sudah dimaksimalkan?"

***"Kalau semua setuju ini masalahnya, pasti benar"***

> *"Seluruh jajaran manajemen sepakat: masalahnya adalah sistem lama. Tidak mungkin semua salah."*

Konsensus bukan bukti. *Groupthink* bisa membuat seluruh tim sepakat atas definisi masalah yang salah — terutama jika kelompok tersebut homogen (latar belakang sama, level sama, perspektif sama). Dalam budaya organisasi yang menghargai harmoni, sangat mungkin satu orang menyatakan masalah, yang lain mengangguk, dan "konsensus" tercapai tanpa validasi data.

**Koreksi:** Validasi definisi masalah dengan data, bukan dengan *voting*. Undang perspektif yang berbeda: *end-user*, *front-liner*, tim IT, bahkan pelanggan — bukan hanya manajer di ruang rapat. Triangulasi sumber (wawancara + observasi + data) mencegah *groupthink* menentukan arah proyek.

***"Cukup tanya pimpinan untuk tahu apa masalahnya"***

> *"Pak Direktur sudah bilang masalahnya apa. Ikuti saja, beliau yang paling paham."*

Masalah yang terlihat dari lantai C-*suite* sangat berbeda dari masalah yang dialami *front-liner*. Pimpinan melihat gejala yang sudah teragregasi: KPI turun, *revenue* menurun, efisiensi rendah. Tetapi akar masalah sering ada di level operasional yang jarang terlihat dari atas: proses *input* data yang memakan 2 jam per hari, formulir yang meminta informasi yang sama tiga kali, atau sistem yang memaksa karyawan membuka 4 aplikasi untuk satu transaksi.

**Koreksi:** Gunakan *multi-method*: wawancara *top-down* (apa yang dilihat pimpinan) + observasi *bottom-up* (apa yang terjadi di lapangan) + analisis data (apa yang ditunjukkan angka). Ketiga perspektif ini sering tidak selaras — dan *gap* di antaranya justru menunjukkan di mana masalah sebenarnya berada.

---

## 4.8 Studi Kasus

### Studi Kasus A (Dasar): SIMRS — *Bottleneck* Informasi di Rawat Jalan

**Sumber:** Parviainen et al. (2022); Kendall & Kendall (2019)

**Kondisi Awal:**
Rumah sakit tipe B di Jawa Tengah: antrian rawat jalan rata-rata 3 jam. Keluhan pasien meningkat 45% dalam 6 bulan. Manajemen RS mengajukan proposal: "Tambah 5 dokter spesialis" — investasi rekrutmen, ruang praktik, dan peralatan senilai miliaran rupiah. Asumsi: antrian panjang karena jumlah dokter tidak cukup.

**Setelah *Problem Framing*:**
Tim analis melakukan observasi waktu (*time-motion study*) di instalasi rawat jalan selama 2 minggu. Hasilnya mengejutkan:

| Fase Kunjungan | Waktu Rata-rata | % dari Total |
|----------------|----------------|-------------|
| Registrasi (manual, formulir kertas) | 45 menit | 25% |
| Pencarian rekam medis (arsip fisik) | 40 menit | 22% |
| Konsultasi dokter | 25 menit | 14% |
| *Input* data ganda (3 sistem berbeda) | 30 menit | 17% |
| Menunggu antar-proses | 40 menit | 22% |
| **Total** | **180 menit** | **100%** |

**Tabel 8.4 — Analisis waktu kunjungan rawat jalan: hanya 14% dihabiskan untuk konsultasi dokter.**

Akar masalah: *bottleneck* informasi di proses administratif, bukan kekurangan tenaga medis. 86% waktu kunjungan dihabiskan untuk proses yang bisa diotomasi atau dieliminasi dengan SI yang terintegrasi.

**Solusi berbasis akar masalah:**
- Registrasi *self-service* via kios digital → 45 menit → 5 menit
- *Electronic Medical Record* (EMR) menggantikan arsip fisik → 40 menit → 0
- Integrasi 3 sistem menjadi *single entry* → 30 menit → 0
- Total setelah intervensi SI: **55 menit** (pengurangan 69%)

**Pelajaran:** Menambah dokter mengurangi 25 menit dari 180 menit — perbaikan marginal dengan biaya besar. *Problem framing* yang benar menemukan bahwa 86% waktu bukan di konsultasi, dan SI yang tepat menghilangkan *bottleneck* informasi tanpa menambah tenaga medis. Solusi yang tepat dimulai dari diagnosis masalah yang tepat.

### Studi Kasus B (Lanjutan): Target Corporation — Ketika SI Bekerja, Organisasi Gagal

**Sumber:** Laudon & Laudon (2022); Standish Group (2023)

**Kondisi Awal:**
Target Corporation memiliki investasi keamanan SI senilai ratusan juta dolar. Sistem FireEye mendeteksi *malware* pada 30 November 2013. *Alert* dikirim. Tim keamanan menerima *alert*. Namun: *alert* diklasifikasikan sebagai "*routine*" di tengah ratusan *alert* harian lainnya. Tidak ada yang mengambil tindakan selama 12 hari.

**Analisis *Problem Framing*:**
Masalah Target bukan kegagalan teknologi — FireEye bekerja sempurna. Masalahnya ada di empat dimensi organisasional:

| Dimensi | Kondisi Aktual | Kondisi yang Seharusnya |
|---------|---------------|------------------------|
| Klasifikasi *alert* | Semua *alert* diperlakukan setara | *Framework severity level* dengan respons time berbeda |
| *Escalation path* | Tidak jelas — *alert* diteruskan via email biasa | Prosedur eskalasi tertulis: Severity 1 → CISO dalam 1 jam |
| *Decision owner* | Tidak ada satu orang yang bertanggung jawab | CISO dengan otoritas *system shutdown* |
| Budaya respons | "*Noise filtering*" — terlalu banyak *alert* | "*Zero tolerance*" untuk anomali keamanan |

**Tabel 8.5 — Target Corporation: gap analysis antara kondisi aktual dan kondisi yang seharusnya.**

Kerugian: 40 juta data kartu kredit dicuri, biaya langsung $292 juta, CEO mengundurkan diri, reputasi hancur.

**Pelajaran:** SI yang sempurna tanpa budaya eskalasi dan *problem framing* adalah alarm kebakaran di gedung yang penghuninya tidak pernah dilatih evakuasi. Deteksi masalah tanpa respons organisasional yang terstruktur hanya menghasilkan dokumentasi kegagalan, bukan pencegahan.

---

## 4.9 Template Praktis

### Template A.4 — *Problem Statement Canvas*

```
==========================================
Template A.4 — PROBLEM STATEMENT CANVAS
==========================================

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

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

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

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

3. ANALISIS 5-WHY
   Mengapa 1 : ________________________________________
   Mengapa 2 : ________________________________________
   Mengapa 3 : ________________________________________
   Mengapa 4 : ________________________________________
   Mengapa 5 : ________________________________________

   → AKAR MASALAH : ________________________________________

4. STAKEHOLDER YANG TERDAMPAK
   Stakeholder 1 : ______________ | Perspektif: ______________ | Dampak: ______
   Stakeholder 2 : ______________ | Perspektif: ______________ | Dampak: ______
   Stakeholder 3 : ______________ | Perspektif: ______________ | 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 5)
       Kriteria yang terpenuhi:
       [ ] Informasi tidak tersedia
       [ ] Informasi tidak akurat
       [ ] Informasi terlambat
       [ ] Proses informasi tidak efisien
   [ ] Tidak — solusi non-SI yang diperlukan: ________________

8. HIPOTESIS SOLUSI AWAL
   ________________________________________
   Perlu divalidasi dengan data: ________________________________________
```

---

## 4.10 Peta Konsep

### Gambar 4.2 — Peta Konsep Bab 4: Analisis Permasalahan Organisasi

```mermaid
mindmap
  root((Analisis Permasalahan<br/>Organisasi))
    Problem Framing
      Gejala vs Akar Masalah
      Rumusan Masalah
      Spesifik dan 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 terkait informasi?
      Optimasi SI vs SI baru
      4 kriteria kebutuhan SI
```

**Gambar 4.2 — Peta konsep analisis permasalahan organisasi: lima kluster dari *problem framing* hingga jembatan ke kebutuhan SI.**

---

## 4.11 Rangkuman

**Poin-poin Penting:**

1. Mendefinisikan masalah yang benar lebih kritis dari menemukan solusi yang canggih. 45% kegagalan proyek SI berakar pada *requirements* yang salah — yang berakar pada definisi masalah yang tidak pernah dilakukan dengan benar.

2. Gejala bukan masalah. Antrian panjang, laporan terlambat, dan keluhan pelanggan adalah sinyal — bukan diagnosis. Manajer harus menerapkan disiplin membedakan gejala dari akar masalah menggunakan *fishbone diagram*, *5-Why*, dan *gap analysis*.

3. *Stakeholder analysis* memastikan masalah didefinisikan dari berbagai perspektif — bukan hanya dari perspektif pihak yang paling berkuasa di ruang rapat. SI yang hanya melayani satu *stakeholder* akan ditolak oleh *stakeholder* lain.

4. Setiap rumusan masalah adalah hipotesis yang harus divalidasi dengan data. Hanya 35% proposal proyek SI di Indonesia menyertakan data validasi masalah — sisanya langsung ke spesifikasi solusi.

5. Tidak semua masalah organisasi membutuhkan SI baru. Jembatan dari "masalah" ke "kebutuhan SI" hanya valid jika akar masalah terkait: informasi tidak tersedia, tidak akurat, terlambat, atau prosesnya tidak efisien. 40% kasus bisa diselesaikan dengan optimasi SI yang sudah ada.

6. *Solutionism* — langsung melompat ke solusi tanpa *framing* masalah — adalah anti-*pattern* paling mahal dan paling umum dalam proyek SI di Indonesia. 67% proposal proyek SI pemerintah tidak menyertakan analisis masalah terstruktur.

---

**Menuju Bab 5:**

Setelah masalah organisasi didefinisikan dengan benar — dan dikonfirmasi bahwa masalahnya terkait informasi — pertanyaan berikutnya: informasi apa tepatnya yang dibutuhkan? Bab 5 membahas cara memetakan kebutuhan informasi per level manajemen, teknik penggalian kebutuhan, dan bagaimana memastikan bahwa SI yang akan dirancang menjawab kebutuhan yang nyata — bukan kebutuhan yang diasumsikan.

---

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

---

## 4.12 Latihan & Refleksi

### Pertanyaan Diagnostik

Pimpinan organisasi mendorong penggantian sistem karena keluhan pelanggan meningkat 20 persen dalam tiga bulan terakhir. Lakukan diagnosis dengan membedakan gejala, masalah inti, akar masalah, dan isu informasi, tentukan data serta pemangku kepentingan yang harus dilibatkan, dan jelaskan kriteria yang menempatkan SI sebagai bagian dari solusi, bukan sekadar objek yang dipersalahkan.

### Pertanyaan Reflektif

1. Berikan contoh dari organisasi yang Anda kenal di mana solusi SI diterapkan tetapi masalah tetap ada — karena *problem framing* yang salah. Apa gejala yang direspons, dan apa akar masalah yang sebenarnya?

2. Mengapa orang cenderung langsung bicara solusi daripada menganalisis masalah terlebih dahulu? Kaitkan jawaban Anda dengan konsep *System 1 thinking* dari Kahneman (2011).

3. Demonstrasikan analisis *5-Why* untuk masalah: "Penjualan menurun 20% selama 3 bulan terakhir." Telusuri hingga menemukan akar masalah — setiap jawaban harus berbasis fakta atau asumsi yang bisa divalidasi, bukan spekulasi.

4. Apakah *fishbone diagram* masih relevan di era *big data* dan AI, atau sudah ketinggalan zaman? Argumentasikan posisi Anda dengan contoh konkret.

### Latihan Artefak

**Latihan 4.1 — *Problem Statement Canvas* (Template A.4)**

Gunakan Template A.4 untuk menganalisis satu masalah nyata di organisasi yang Anda kenal. Lengkapi seluruh 8 *section*:

1. Identifikasi minimal 3 gejala yang terlihat dan dukung dengan data kuantitatif
2. Lakukan analisis *5-Why* hingga menemukan akar masalah
3. Petakan minimal 3 *stakeholder* dengan perspektif berbeda terhadap masalah
4. Evaluasi apakah masalah tersebut terkait informasi (gunakan 4 kriteria di Sek 8.4.6)

**Kriteria output yang baik:**
- Masalah nyata dari organisasi yang bisa diobservasi, bukan hipotetis
- *5-Why* setiap jawaban berbasis data atau observasi — bukan asumsi
- *Stakeholder* minimal mencakup perspektif manajemen, operasional, dan pengguna akhir
- Kesimpulan Section 7 jujur — jika masalah bukan terkait informasi, akui dan jelaskan

*Output Artefak 4.1 menjadi input untuk pemetaan kebutuhan informasi di Bab 5.*

---

## Referensi

Gartner Research. (2023). *IT project failure analysis*. Gartner, Inc.

Ishikawa, K. (1985). *What is total quality control? The Japanese way*. Prentice-Hall.

Kahneman, D. (2011). *Thinking, fast and slow*. Farrar, Straus and Giroux.

Kendall, K. E., & Kendall, J. E. (2019). *Systems analysis and design* (10th ed.). Pearson.

Kominfo. (2023). *Laporan evaluasi proyek SI pemerintah*. Kementerian Komunikasi dan Informatika RI.

Laudon, K. C., & Laudon, J. P. (2022). *Management information systems* (17th ed.). Pearson.

McKinsey & Company. (2022). *Problem solving survey: How top teams define and solve problems*. McKinsey.

Minto, B. (2002). *The pyramid principle*. FT Prentice Hall.

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.

PMI. (2023). *Pulse of the profession 2023*. Project Management Institute.

Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2022). *Systems analysis and design in a changing world* (8th ed.). Cengage Learning.

Standish Group. (2023). *Chaos report 2023: Beyond infinity*. The Standish Group International.