BAB 4 - Analisis Permasalahan Organisasi

4.1 Pembuka

Bab 3 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.3 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

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:

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.

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

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:

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:

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

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.