# BAB 9 — Kebutuhan Informasi Manajerial


```
Bagian          : IV — Analisis Masalah & Kebutuhan Informasi
Reader Outcome  : Pembaca mampu memetakan kebutuhan informasi per level manajemen,
                  menerapkan teknik penggalian kebutuhan informasi, dan menyusun
                  tabel kebutuhan informasi sebagai input perancangan SI.
Level           : Lanjutan
Estimasi Halaman: 15–18
```

---

## 9.1 Pembuka

Bab 8 membekali Anda dengan disiplin *problem framing* — membedakan gejala dari akar masalah, menyusun rumusan masalah terstruktur, dan mengevaluasi apakah masalah tersebut memang memerlukan intervensi SI. Template A.8 (*Problem Statement Canvas*) menghasilkan rumusan masalah yang sudah divalidasi dengan data. Tetapi masalah yang sudah terdefinisi belum otomatis menunjukkan solusi. Antara "masalah yang dipahami" dan "SI yang dirancang" terdapat satu jurang yang sering diabaikan: memetakan kebutuhan informasi secara eksplisit.

Seorang kepala dinas di Jawa Barat mengeluhkan: "Sistem kepegawaian lengkap, tetapi saya tetap tidak tahu berapa ASN yang perlu pensiun dini tahun depan." Sistem menyimpan 200.000+ *record* data pegawai — tetapi tidak satu pun dirancang untuk menjawab pertanyaan strategis itu. Bukan datanya yang kurang. Bukan *hardware*-nya yang lambat. Yang kurang adalah pemahaman tentang informasi apa yang dibutuhkan, oleh siapa, dalam format apa, dan untuk keputusan apa.

Bagaimana manajer memetakan kebutuhan informasi yang relevan untuk pengambilan keputusan di setiap level — dan mengapa *gap* antara "informasi yang tersedia" dan "informasi yang dibutuhkan" menjadi sumber kegagalan SI?

---

## 9.2 Model Utama

### Gambar 9.1 — Piramida Kebutuhan Informasi Manajerial

```mermaid
graph TD
    subgraph STRATEGIC["Level Strategis — Top Management"]
        style STRATEGIC fill:#4a1a5c,stroke:#333,color:#fff
        S1["Informasi Agregat & Trend"]
        S2["External Environment"]
        S3["Long-term Projection"]
    end
    subgraph TACTICAL["Level Taktis — Middle Management"]
        style TACTICAL fill:#6b3a7d,stroke:#333,color:#fff
        T1["Informasi Ringkasan Periodik"]
        T2["Exception Reports"]
        T3["Comparative Analysis"]
    end
    subgraph OPERATIONAL["Level Operasional — Lower Management"]
        style OPERATIONAL fill:#8c5a9e,stroke:#333,color:#fff
        O1["Informasi Detail Real-time"]
        O2["Transaction Records"]
        O3["SOP Compliance Data"]
    end
    OPERATIONAL --> TACTICAL --> STRATEGIC
    CONTEXT["Konteks Keputusan"] -.-> STRATEGIC
    CONTEXT -.-> TACTICAL
    CONTEXT -.-> OPERATIONAL
    style CONTEXT fill:#f5f5f5,stroke:#4a1a5c,color:#333
```

**Level Operasional** — kebutuhan informasi detail, *real-time*, transaksional. Supervisor gudang membutuhkan stok per SKU saat ini, bukan rata-rata bulanan. Perawat membutuhkan daftar pasien per poli hari ini, bukan tren kunjungan tahunan. Karakteristiknya: granular, frekuensi tinggi, sumber internal, format terstruktur.

**Level Taktis** — kebutuhan informasi ringkasan periodik (mingguan atau bulanan), berbasis *exception*, dan komparatif antar unit. Kepala instalasi rumah sakit membutuhkan *occupancy rate* per poli minggu ini dibandingkan bulan lalu — bukan detail setiap kunjungan. Campuran antara terstruktur dan semi-terstruktur.

**Level Strategis** — kebutuhan informasi agregat, tren jangka panjang, dan *intelligence* dari lingkungan eksternal. Direktur utama membutuhkan proyeksi demografi wilayah layanan 5 tahun ke depan, bukan transaksi per hari. Sebagian besar tidak terstruktur, frekuensi rendah, dan sangat kontekstual.

**Konteks Keputusan** — setiap level membutuhkan informasi yang berbeda tergantung keputusan yang sedang dihadapi. Kebutuhan informasi bukan statis — ia berubah seiring perubahan situasi organisasi, regulasi, dan kondisi pasar. Seorang kepala divisi yang minggu lalu membutuhkan *comparative analysis* antar cabang bisa saja minggu ini membutuhkan *detail* transaksi cabang tertentu karena ada anomali. Piramida adalah panduan umum, bukan penjara kaku.

---

## 9.3 Definisi Kunci

📌 ***Information Requirement* (Kebutuhan Informasi)**
Spesifikasi tentang informasi apa yang dibutuhkan, oleh siapa, dalam format apa, seberapa sering, dan untuk keputusan apa — yang menjadi dasar perancangan SI. Gagal mendefinisikan kebutuhan informasi berarti SI dirancang berdasarkan asumsi *developer*, bukan kebutuhan pengguna. Satzinger et al. (2022) menekankan bahwa *requirement* yang tidak terdefinisi eksplisit akan diisi oleh asumsi tim teknis — dan asumsi hampir selalu salah.

📌 ***Information Gap***
Selisih antara informasi yang tersedia dalam SI saat ini dengan informasi yang sesungguhnya dibutuhkan untuk pengambilan keputusan di setiap level manajemen. Gap ini terjadi karena tiga sebab utama: SI dirancang tanpa *needs assessment*, kebutuhan berubah tetapi SI statis, atau data tersedia tetapi format dan granularitasnya tidak sesuai. Standish Group (2023) melaporkan 65% fitur SI yang dibangun tidak pernah digunakan — sering karena fitur tersebut menjawab kebutuhan informasi yang tidak pernah ditanyakan oleh pengguna.

📌 ***Critical Success Factor* (CSF)**
Faktor-faktor kunci yang harus berjalan dengan baik agar organisasi mencapai tujuannya — diperkenalkan oleh Rockart (1979) sebagai teknik mengidentifikasi kebutuhan informasi *top management* tanpa harus menyusun daftar panjang. Pertanyaan kunci CSF sederhana: "Apa 3–5 hal yang harus berjalan baik agar Anda sukses?" Dari jawaban itu, analis bisa men-*derive* kebutuhan informasi yang fokus pada hal yang *matter* — bukan hal yang *nice-to-have*.

---

## 9.4 Konsep Inti

### 9.4.1 Piramida Kebutuhan Informasi: Operasional, Taktis, Strategis

Anthony (1965) memperkenalkan klasifikasi tiga level aktivitas manajemen yang menjadi dasar pemahaman kebutuhan informasi: *operational control*, *management control*, dan *strategic planning*. Gorry dan Scott Morton (1971) memperkaya kerangka ini dengan menghubungkan setiap level ke tipe keputusan (terstruktur, semi-terstruktur, tidak terstruktur) dan implikasinya terhadap desain SI.

Kesalahan paling umum dalam proyek SI: sistem dirancang satu-ukuran-untuk-semua. Akibatnya, *top management* mendapat terlalu banyak detail sehingga *drowning in data*, sementara supervisor operasional tidak mendapat data *real-time* yang mereka butuhkan karena sistem hanya menyediakan ringkasan bulanan.

| Dimensi | Operasional | Taktis | Strategis |
|---------|------------|--------|-----------|
| Granularitas | Detail per transaksi | Ringkasan per unit/divisi | Agregat organisasi |
| Frekuensi | *Real-time* / harian | Mingguan / bulanan | Kuartalan / tahunan |
| Sumber | Internal, transaksional | Internal + komparatif | Internal + eksternal |
| Struktur keputusan | *Highly structured* | Semi-*structured* | *Unstructured* |
| Contoh | Status order X | *Revenue* per region Q3 | Tren pasar 5 tahun |

Di era *self-service BI* (lihat Bab 7), batas antar level semakin *blurred*. Manajer taktis bisa *drill-down* ke data operasional; eksekutif strategis bisa mengakses *real-time dashboard*. Tetapi prinsip dasar tetap berlaku: setiap level memiliki kebutuhan informasi yang berbeda secara struktural, dan desain SI harus mengakomodasi perbedaan tersebut.

### 9.4.2 Teknik Penggalian Kebutuhan Informasi

Manajer sering tidak bisa mengartikulasikan kebutuhan informasinya secara eksplisit. Ini bukan kelemahan manajer — ini adalah keniscayaan. Mereka ahli dalam konteks bisnis, bukan dalam spesifikasi teknis. Teknik penggalian harus proaktif, bukan reaktif.

**JAD (*Joint Application Development*)** — *workshop* terstruktur yang mempertemukan manajer, analis, dan tim IT dalam satu ruangan. Fasilitator mengarahkan diskusi untuk menghasilkan *consensus requirement* dalam 2–3 sesi. Keunggulan JAD: menghilangkan *telephone game* antara pengguna dan *developer* karena semua pihak mendengar hal yang sama secara langsung.

**CSF *Method* (Rockart, 1979)** — tanya tiga pertanyaan kepada manajer: (1) Apa tujuan utama Anda? (2) Apa 3–5 hal yang harus berjalan baik untuk mencapai tujuan itu? (3) Informasi apa yang Anda butuhkan untuk memantau faktor-faktor tersebut? Dari jawaban ketiga, analis men-*derive* kebutuhan informasi yang fokus dan terukur. CSF efektif khususnya untuk level strategis di mana kebutuhan informasi paling sulit diartikulasikan.

**_Prototyping_ dan *Mockup*** — tunjukkan contoh *dashboard*, laporan, atau *interface* kepada manajer. Reaksi manajer terhadap contoh konkret jauh lebih informatif daripada jawaban mereka terhadap pertanyaan abstrak "informasi apa yang Anda butuhkan?" Kendall dan Kendall (2019) menekankan bahwa *prototyping* mengungkap kebutuhan yang tidak terartikulasikan: manajer berkata "oh, ternyata saya juga butuh ini" ketika melihat kemungkinan yang sebelumnya tidak terbayangkan.

**Observasi dan Analisis Dokumen** — amati proses kerja nyata: apa yang ditulis manajer di *sticky notes*, apa yang di-*copy* ke Excel dari SI formal, laporan apa yang dicetak dan ditandai dengan stabilo. Dokumen-dokumen informal ini sering mengungkap kebutuhan informasi yang tidak pernah disebutkan dalam wawancara formal karena manajer sudah meng-*workaround* ketiadaan fitur SI.

### 9.4.3 *Information Gap*: Antara Tersedia dan Dibutuhkan

Organisasi sering memiliki SI yang menghasilkan banyak data tetapi sedikit informasi yang *actionable*. Survei Gartner (2023) menemukan bahwa 73% manajer merasa "*overwhelmed by data but starved of insight*." Gap ini terjadi karena tiga pola:

Pertama, SI dirancang tanpa *needs assessment* — tim teknis membangun fitur berdasarkan asumsi tentang apa yang "pasti dibutuhkan." Hasilnya: 120 jenis laporan tersedia, tetapi manajer tetap membuat laporan sendiri di Excel.

Kedua, kebutuhan berubah tetapi SI statis. Organisasi berevolusi — merger, reorganisasi, perubahan regulasi — tetapi SI tetap menyediakan informasi berdasarkan struktur tiga tahun lalu. Data tentang "divisi pemasaran" masih muncul padahal divisi itu sudah dipecah menjadi "pemasaran digital" dan "pemasaran konvensional."

Ketiga, data tersedia tetapi format dan granularitasnya tidak sesuai. Contoh klasik: sistem kepegawaian memiliki data lengkap 200.000 ASN, tetapi tidak bisa menjawab "berapa ASN yang *eligible* pensiun dini tahun depan per unit?" karena *field* tanggal lahir, masa kerja, dan unit tidak bisa di-*query* bersamaan.

### 9.4.4 Siapa Menentukan Kebutuhan: Manajer, Analis, atau Teknolog?

Ada paradoks klasik dalam penentuan kebutuhan informasi. Manajer tahu apa yang dibutuhkan tetapi tidak bisa mengartikulasikannya dalam bahasa teknis. Analis bisa memformalisasikan kebutuhan tetapi tidak memahami konteks keputusan sehari-hari. IT bisa membangun apa pun tetapi cenderung berpikir dalam fitur dan *database schema*, bukan dalam kebutuhan keputusan.

Solusinya bukan memilih salah satu, melainkan *triad collaboration*: manajer menyediakan konteks bisnis, analis memformalisasikan kebutuhan, IT mengevaluasi *feasibility*. Data PMI (2023) mendukung pendekatan ini: proyek SI dengan *triad collaboration* memiliki *success rate* 62% — dua kali lipat dari proyek yang didominasi satu perspektif (31%).

Yang sering terjadi di lapangan: IT mendominasi proses karena "manajer tidak mengerti teknologi" atau manajer mendominasi karena "IT harus nurut *user*." Kedua skenario menghasilkan SI yang cacat — yang pertama secara fungsional (fitur canggih tetapi tidak menjawab kebutuhan), yang kedua secara teknis (menjawab kebutuhan tetapi tidak *scalable* atau tidak terintegrasi).

### 9.4.5 Kebutuhan Informasi di Era Digital: Pergeseran Paradigma

Teknik penggalian kebutuhan informasi klasik (wawancara, JAD, CSF) dikembangkan di era di mana output SI berbentuk laporan cetak yang dikirim ke meja manajer setiap akhir bulan. Konteks sudah berubah secara radikal.

Manajer modern membutuhkan: *real-time dashboard* yang bisa diakses dari ponsel saat perjalanan dinas, *predictive alert* yang memperingatkan anomali sebelum menjadi masalah, *self-service query* yang memungkinkan eksplorasi data tanpa menunggu laporan dari IT, dan — di frontier terbaru — AI-*assisted recommendation* yang merekomendasikan informasi berdasarkan pola keputusan sebelumnya.

Implikasinya terhadap penggalian kebutuhan: analis harus mengakomodasi kebutuhan "yang belum diketahui" (*unknown unknowns*). Manajer yang belum pernah melihat *predictive analytics* tidak mungkin memintanya dalam wawancara. Teknik *prototyping* menjadi semakin kritis — bukan untuk mengkonfirmasi kebutuhan yang sudah diartikulasikan, tetapi untuk mengungkap kebutuhan yang belum terbayangkan.

Contoh pergeseran: era pre-BI, manajer meminta "laporan penjualan bulanan." Era post-BI, kebutuhan bergeser ke "*alert* otomatis jika penjualan region tertentu turun 10% di bawah *forecast* minggu ini" — kebutuhan yang hanya bisa diartikulasikan setelah manajer melihat bahwa *alert* semacam itu dimungkinkan.

### 9.4.6 Dari Kebutuhan Informasi ke Spesifikasi SI: Jembatan ke Bagian V

Kebutuhan informasi yang sudah divalidasi menjadi input utama untuk tiga bab selanjutnya di Bagian V: pemodelan proses bisnis (Bab 10), perancangan konseptual (Bab 11), dan pemilihan solusi (Bab 12). Tanpa kebutuhan informasi yang terdefinisi, desain SI menjadi latihan teknis tanpa arah.

Jembatan dari kebutuhan ke desain bekerja seperti ini:

- Kebutuhan informasi **apa** yang harus dihasilkan → menentukan *output* SI (Bab 11)
- Kebutuhan **siapa** yang membutuhkan → menentukan *role-based access* dan *views*
- Kebutuhan **seberapa sering** → menentukan arsitektur (*batch processing* vs *real-time*)
- Kebutuhan **dari sumber mana** → menentukan integrasi data (internal, eksternal, atau keduanya)

*Information requirement table* — yang akan Anda susun menggunakan Template A.9 — adalah dokumen jembatan yang menghubungkan analisis (Bagian IV) dengan desain (Bagian V). Dokumen ini menjadi "kontrak" antara manajer yang mendefinisikan kebutuhan dan tim teknis yang merancang solusi.

---

## 9.5 Komparasi

### Tabel 9.1 — Kebutuhan Informasi: Operasional vs Taktis vs Strategis — Kasus Rumah Sakit

| Dimensi | Level Operasional (Perawat/Admin) | Level Taktis (Ka. Instalasi) | Level Strategis (Direktur) |
|---------|----------------------------------|------------------------------|---------------------------|
| Keputusan tipikal | Jadwal *shift* hari ini | Alokasi staf per poli bulan depan | Buka poli baru atau tidak |
| Informasi dibutuhkan | Daftar pasien per poli, status *bed* | *Occupancy rate* per poli, tren kunjungan | Demografi wilayah, *competitor analysis* |
| Format | Detail, *real-time* | Ringkasan grafik mingguan | *Dashboard* tren tahunan |
| Sumber | Internal: SIMRS | Internal + *benchmark* RS regional | Internal + eksternal (BPS, BPJS) |
| Frekuensi *update* | Per menit | Mingguan | Kuartalan |
| Jika tidak tersedia | Pasien salah poli, antrian kaotik | *Over/under-staffing*, keluhan meningkat | Investasi salah arah, pangsa pasar turun |

💡 **Insight:** Satu organisasi yang sama — rumah sakit — membutuhkan tiga "jenis SI" yang berbeda di tiga level. SI operasional yang sempurna tidak menggantikan kebutuhan SI strategis, dan sebaliknya. Kegagalan banyak SIMRS di Indonesia: dirancang hanya untuk level operasional (registrasi, rekam medis, *billing*), sehingga direktur tetap membuat keputusan strategis berdasarkan intuisi — bukan karena malas, tetapi karena SI tidak menyediakan informasi yang ia butuhkan.

---

## 9.6 Realitas Lapangan

### Fenomena 1: SI Kepegawaian Pemerintah Jawa Barat — "Data Lengkap, Informasi Kosong"

Provinsi Jawa Barat memiliki SI Kepegawaian dengan *database* 200.000+ ASN. Data lengkap: nama, NIP, jabatan, pangkat, TMT. Tetapi ketika Gubernur membutuhkan proyeksi kebutuhan ASN 5 tahun ke depan per OPD, SI tidak bisa menjawab. Tim IT harus mengekspor ke Excel, memproses manual selama 3 minggu baru bisa menghasilkan proyeksi yang diminta.

Akar masalahnya bukan keterbatasan teknologi — SI dibangun dengan *database* relasional yang secara teknis mampu melakukan *query* kompleks. Masalahnya: SI dirancang tanpa memahami kebutuhan informasi level strategis. Semua *requirement* dikumpulkan dari staf administrasi BKD (level operasional), sehingga SI hanya melayani: cetak SK, verifikasi data, proses kenaikan pangkat. Tidak satu pun *stakeholder* strategis dilibatkan dalam *requirement gathering* (Supriyadi & Handoko, 2023).

💡 **Insight:** Kelengkapan data bukan jaminan kelengkapan informasi. SI yang dirancang tanpa *needs assessment* per level manajemen akan selalu menyisakan *blind spot* — terutama di level strategis, yang paling jarang didengar saat *requirement gathering* tetapi paling kritis untuk keputusan organisasi.

### Fenomena 2: *Report Overload* — Ketika SI Terlalu Rajin

Penelitian IBM (2022) menemukan bahwa manajer rata-rata menerima 120+ email notifikasi dari berbagai SI per hari. Dari jumlah itu, hanya 15% yang benar-benar relevan untuk keputusan mereka. Sisanya: *FYI*, *CC*, laporan *auto-generated* yang tidak diminta. Dampaknya paradoks: semakin banyak SI, semakin sedikit informasi yang benar-benar dicerna.

Fenomena ini terjadi karena desain SI mengasumsikan bahwa "menyediakan lebih banyak informasi = lebih baik." Padahal kebutuhan informasi bukan hanya tentang konten yang disediakan, tetapi juga tentang *noise* yang disaring. Manajer yang menerima 120 notifikasi per hari belajar satu *coping mechanism* yang kontra-produktif: mengabaikan semuanya — termasuk notifikasi yang sebenarnya kritis.

💡 **Insight:** *Good information requirement* bukan hanya soal "informasi apa yang harus disediakan" tetapi juga "informasi apa yang harus disaring." Desain SI harus mencakup *noise reduction* — bukan hanya *content provision*. Prinsipnya: *less is more*, selama "less" itu tepat sasaran.

### Fenomena 3: IBM Watson for HR — Ketika AI Memprediksi Kebutuhan Informasi

IBM mengimplementasikan Watson AI di divisi HR untuk memprediksi *attrition* karyawan. Watson tidak hanya menjawab "siapa yang mungkin *resign*" tetapi secara proaktif menyusun *information package* per manajer: *flight risk score* per anggota tim, faktor-faktor kontribusi, dan rekomendasi intervensi.

Hasilnya: *attrition rate* turun dari 15% menjadi 11,2% per tahun — penurunan 25%. Bukan karena Watson menggantikan keputusan manajer, tetapi karena Watson menyajikan informasi yang sebelumnya tidak diketahui manajer bahwa mereka membutuhkannya. Watson menemukan bahwa "jarak rumah ke kantor" dan "jumlah proyek simultan" adalah prediktor *attrition* yang tidak pernah dipertimbangkan manajer — karena data itu tersimpan di dua sistem berbeda dan tidak pernah dianalisis bersamaan (IBM, 2022).

💡 **Insight:** AI menggeser paradigma *information requirement* dari "manajer menentukan apa yang dibutuhkan" ke "SI merekomendasikan apa yang sebaiknya dilihat." Ini adalah evolusi dari kebutuhan informasi di era AI — dari *pull* (manajer meminta) ke *push* (sistem merekomendasikan). Implikasi lebih luas dibahas di Bab 17.

---

## 9.7 Salah Kaprah

⚠️ ***"Manajer pasti tahu informasi apa yang mereka butuhkan"***

> Pernyataan ini terdengar masuk akal — siapa lagi yang lebih tahu kebutuhan informasi kalau bukan penggunanya sendiri? Tetapi riset dan pengalaman lapangan menunjukkan sebaliknya. Sebagian besar manajer hanya bisa mengartikulasikan kebutuhan informasi yang sudah mereka kenal: yang sudah tersedia, atau yang sudah biasa mereka gunakan. Kebutuhan informasi "yang belum diketahui" (*unknown unknowns*) tidak akan pernah muncul di wawancara biasa.
>
> **Koreksi:** Gunakan teknik proaktif: *prototyping*, CSF *method*, analisis keputusan. Jangan hanya bertanya "apa yang Anda butuhkan?" — tunjukkan opsi dan minta reaksi. Kebutuhan informasi paling bernilai justru yang belum disadari oleh manajer.

⚠️ ***"Semakin banyak informasi yang disediakan SI, semakin baik"***

> Secara intuitif, tampak logis: lebih banyak informasi = keputusan lebih baik. Realitasnya, *information overload* justru menurunkan kualitas keputusan. Schwartz (2004) mendokumentasikan bahwa terlalu banyak opsi dan data tanpa *filtering* membuat pengambil keputusan *paralyzed* — fenomena yang disebut *paradox of choice*. Dalam konteks SI, manajer yang mendapat 120 notifikasi per hari berhenti membaca semuanya.
>
> **Koreksi:** SI yang baik mengimplementasikan *information filtering*: *default view* yang ramping, *drill-down* untuk detail, *exception-based alert* untuk anomali. Prinsip desain yang benar bukan "sediakan segalanya" melainkan "sediakan yang relevan, sembunyikan yang tidak."

⚠️ ***"Requirement gathering cukup dilakukan sekali di awal proyek"***

> Asumsi ini berasal dari era *waterfall development* di mana proyek SI memiliki fase *requirement*, *design*, *build*, dan *deploy* yang sekuensial. Di realitas modern, kebutuhan informasi berevolusi seiring perubahan organisasi, pasar, dan regulasi. SI yang dirancang berdasarkan *requirement* 3 tahun lalu mungkin sudah tidak relevan. Forrester (2023) melaporkan 68% organisasi mengakui bahwa kebutuhan informasi mereka berubah signifikan setiap 12–18 bulan.
>
> **Koreksi:** Bangun mekanisme *feedback loop*: *review* kebutuhan informasi setiap 6–12 bulan, adopsi *iterative development*, dan sisakan fleksibilitas desain untuk mengakomodasi perubahan kebutuhan tanpa merombak seluruh SI.

⚠️ ***"Kebutuhan informasi di semua level sama — cukup satu dashboard untuk semua"***

> Pernyataan ini muncul dari keinginan efisiensi: bangun satu *dashboard*, semua level menggunakannya. Tetapi piramida kebutuhan informasi menunjukkan bahwa setiap level membutuhkan granularitas, frekuensi, dan format yang berbeda secara struktural. *Dashboard* operasional yang memuat ribuan transaksi tidak berguna untuk CEO; *dashboard* strategis yang menampilkan tren tahunan tidak berguna untuk supervisor yang butuh data *real-time*.
>
> **Koreksi:** Desain SI dengan *role-based views*: setiap level mendapat tampilan yang sesuai kebutuhan keputusan mereka. Satu *database* — ya. Satu tampilan — tidak.

---

## 9.8 Studi Kasus

### 📊 Studi Kasus Dasar — SI Kepegawaian Provinsi: Dari *Data Warehouse* ke *Decision Dashboard*

**❌ Kondisi Awal:**
SI Kepegawaian Provinsi Jawa Barat menyimpan data 200.000+ ASN secara lengkap: nama, NIP, jabatan, pangkat, TMT, riwayat mutasi. Tetapi SI hanya melayani kebutuhan administrasi: cetak SK, verifikasi data, proses kenaikan pangkat. Manajer SDM di tingkat OPD harus *hunting* data manual di Excel ketika Gubernur membutuhkan informasi strategis — distribusi usia ASN, *gap* kompetensi per OPD, proyeksi kebutuhan rekrutmen.

**✅ Setelah *Information Requirements Mapping*:**
Tim analis melakukan CSF *interview* dengan tiga level:
- **Staff BKD (Operasional):** kebutuhan verifikasi data, cetak SK, dan proses administrasi — hampir semuanya sudah terlayani SI lama.
- **Kabid (Taktis):** kebutuhan distribusi per OPD, *exception report* absensi antar-unit, dan *gap* kompetensi per jabatan — hanya sebagian terlayani.
- **Sekda dan Gubernur (Strategis):** kebutuhan proyeksi pensiun 5 tahun, *manpower planning*, dan *succession map* — tidak satu pun tersedia di SI lama.

Ditemukan 40+ *gap* informasi yang kemudian diprioritisasi menjadi 12 *critical requirements*.

### Tabel 9.2 — Hasil *Information Gap Analysis* SI Kepegawaian Jawa Barat

| Level | Kebutuhan Top 3 | Status di SI Lama | Intervensi |
|-------|-----------------|-------------------|-----------|
| Operasional | Data pegawai *real-time*, riwayat mutasi, status gaji | ✅ Tersedia | *Minor enhancement* |
| Taktis | Distribusi per OPD, *exception report* absensi, *gap* kompetensi | ⚠️ *Partial* | *Dashboard* baru |
| Strategis | Proyeksi pensiun 5 tahun, *manpower planning*, *succession map* | ❌ Tidak tersedia | Modul *analytics* baru |

Setelah intervensi, waktu respons terhadap permintaan informasi strategis turun dari 3 minggu (ekspor manual Excel) menjadi *real-time* melalui *dashboard*. Gubernur membatalkan dua usulan rekrutmen massal yang ternyata tidak perlu setelah melihat proyeksi pensiun per OPD — menghemat anggaran miliaran rupiah.

💡 **Pelajaran:** SI yang "lengkap" dari perspektif data belum tentu "lengkap" dari perspektif kebutuhan informasi. *Gap* terbesar justru di level strategis — level yang paling jarang dilibatkan dalam *requirement gathering* tetapi paling kritis untuk keputusan organisasi.

### 📊 Studi Kasus Lanjutan — IBM Watson for HR: AI-*Driven Information Needs*

**❌ Kondisi Awal:**
IBM menghadapi *attrition rate* yang meningkat secara konsisten. HR *Manager* memiliki banyak data — *performance review*, *salary history*, *tenure*, *engagement survey* — yang tersebar di 5 sistem berbeda. Tetapi tidak ada yang tahu data mana yang harus diprioritaskan untuk memprediksi *employee flight risk*. Keputusan manajer tentang retensi bersifat reaktif: bertindak setelah karyawan menyerahkan surat pengunduran diri, bukan sebelumnya.

**✅ Setelah AI-*Assisted Information Requirements*:**
Watson dilatih menggunakan data historis untuk mengidentifikasi 24 variabel paling prediktif terhadap *attrition*. Watson tidak hanya menjawab "siapa yang berisiko *resign*" tetapi menyusun *proactive information package* per manajer: *flight risk score* per anggota tim, faktor-faktor kontribusi, dan rekomendasi intervensi yang spesifik.

### Tabel 9.3 — Sebelum dan Setelah Watson for HR

| Dimensi | Sebelum Watson | Setelah Watson |
|---------|---------------|----------------|
| Identifikasi *at-risk employee* | Reaktif (setelah *resign*) | Prediktif (3–6 bulan sebelum *resign*) |
| Informasi ke manajer | Tersebar di 5 sistem | *Consolidated proactive dashboard* |
| Analisis variabel | Manual, 4–5 variabel | AI-*selected*, 24 variabel |
| *Attrition rate* | 15% per tahun | 11,2% per tahun (turun 25%) |
| Keputusan manajer | Berbasis intuisi | *Data-informed* + AI-*recommended* |

Temuan mengejutkan Watson: dua prediktor *attrition* terkuat — "jarak tempuh rumah ke kantor" dan "jumlah proyek simultan yang ditangani" — tidak pernah dipertimbangkan oleh HR *Manager* mana pun. Data itu tersimpan di sistem yang berbeda dan tidak pernah dikaitkan. AI membuka kategori kebutuhan informasi yang sebelumnya tidak diketahui bahwa ia dibutuhkan.

💡 **Pelajaran:** AI tidak menggantikan manajer dalam menentukan kebutuhan informasi — ia memperkaya cakupan kebutuhan informasi yang bisa diidentifikasi. Kolaborasi manusia-AI dalam *requirement analysis* membuka *unknown unknowns* yang tidak bisa dicapai oleh teknik konvensional.

---

## 9.9 Template Praktis

🔧 **Template A.9 — *Information Requirement Table***

```
TEMPLATE A.9 — INFORMATION REQUIREMENT TABLE

Tanggal              : ________________________________________
Organisasi/Unit      : ________________________________________
Analis               : ________________________________________

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

A. PROFIL STAKEHOLDER
   Nama/Jabatan      : ________________________________________
   Level Manajemen   : [ ] Operasional  [ ] Taktis  [ ] Strategis
   Keputusan kunci   : ________________________________________

B. KEBUTUHAN INFORMASI

| No | Informasi Dibutuhkan      | Untuk Keputusan Apa        | Format | Frekuensi | Status Saat Ini            | Gap   |
|----|---------------------------|----------------------------|--------|-----------|----------------------------|-------|
| 1  | _________________________ | __________________________ | ______ | _________ | [ ] Ada [ ] Partial [ ] Tidak | _____ |
| 2  | _________________________ | __________________________ | ______ | _________ | [ ] Ada [ ] Partial [ ] Tidak | _____ |
| 3  | _________________________ | __________________________ | ______ | _________ | [ ] Ada [ ] Partial [ ] Tidak | _____ |
| 4  | _________________________ | __________________________ | ______ | _________ | [ ] Ada [ ] Partial [ ] Tidak | _____ |
| 5  | _________________________ | __________________________ | ______ | _________ | [ ] Ada [ ] Partial [ ] Tidak | _____ |

C. CSF ANALYSIS
   CSF 1: _________________________ → Informasi yang dibutuhkan: _______________
   CSF 2: _________________________ → Informasi yang dibutuhkan: _______________
   CSF 3: _________________________ → Informasi yang dibutuhkan: _______________

D. PRIORITAS GAP (urutkan dari yang paling kritis)
   Gap #1: _________________________ → Dampak jika tidak diatasi: _______________
   Gap #2: _________________________ → Dampak jika tidak diatasi: _______________
   Gap #3: _________________________ → Dampak jika tidak diatasi: _______________

E. REKOMENDASI UNTUK PERANCANGAN SI (input untuk Bab 10-12)
   ________________________________________
   ________________________________________
   ________________________________________
```

---

## 9.10 Peta Konsep

### Gambar 9.2 — Peta Konsep Kebutuhan Informasi Manajerial

```mermaid
mindmap
  root((Kebutuhan Informasi Manajerial))
    Piramida Level
      Operasional
        Detail & Real-time
        Terstruktur
      Taktis
        Ringkasan & Exception
        Semi-terstruktur
      Strategis
        Agregat & Trend
        Tidak terstruktur
    Teknik Penggalian
      Interview & JAD
      CSF Method Rockart
      Prototyping & Mockup
      Observasi & Dokumen
    Information Gap
      Data ada, informasi tidak
      Format & granularitas salah
      Kebutuhan berevolusi, SI statis
    Era Digital
      Self-service BI
      Predictive Alert
      AI-recommended info
    Output
      Information Requirement Table
      Input ke Desain SI Bagian V
```

---

## 9.11 Rangkuman

**Poin-poin Penting:**

1. Kebutuhan informasi berbeda per level manajemen — SI yang dirancang satu-ukuran-untuk-semua akan gagal melayani setidaknya dua dari tiga level. Anthony (1965) dan Gorry & Scott Morton (1971) memberikan kerangka klasik yang tetap relevan.

2. Manajer sering tidak bisa mengartikulasikan kebutuhan informasinya secara eksplisit. Teknik proaktif — CSF *method*, *prototyping*, observasi — jauh lebih efektif daripada sekadar bertanya "apa yang Anda butuhkan?"

3. *Information gap* — selisih antara informasi yang tersedia dan yang dibutuhkan — adalah sumber utama kegagalan SI. Data Standish Group (2023): 65% fitur SI tidak pernah digunakan, sering karena fitur tersebut menjawab kebutuhan informasi yang tidak pernah ditanyakan.

4. Kelengkapan data bukan jaminan kelengkapan informasi. SI dengan *database* 200.000 *record* bisa "buta" jika tidak dirancang untuk *query* yang relevan bagi pengambil keputusan.

5. Di era digital, kebutuhan informasi berevolusi: dari laporan periodik ke *dashboard real-time*, dari reaktif ke prediktif, dari manajer-*defined* ke AI-*recommended*. Teknik penggalian kebutuhan harus mengakomodasi *unknown unknowns*.

6. *Information requirement table* (Template A.9) adalah jembatan kritis dari analisis (Bagian IV) ke desain (Bagian V) — tanpanya, perancangan SI menjadi latihan teknis tanpa arah.

---

**Menuju Bab 10:**

Kebutuhan informasi sudah terpetakan — Template A.9 menghasilkan daftar informasi yang dibutuhkan, oleh siapa, dalam format apa, dan seberapa sering. Tetapi informasi tidak muncul dari ruang hampa: ia dihasilkan oleh proses bisnis yang mengolah data menjadi *output* yang relevan. Proses bisnis mana yang perlu diubah, ditambah, atau didesain ulang agar informasi dalam Template A.9 bisa diproduksi dan mengalir ke pengambil keputusan yang tepat? Bab 10 membuka Bagian V dengan pemodelan proses bisnis — langkah pertama menerjemahkan kebutuhan informasi menjadi desain SI konkret.

---

🔥 *"Kebutuhan informasi bukan tentang apa yang manajer minta, tetapi tentang apa yang mereka butuhkan untuk membuat keputusan yang tidak akan mereka sesali besok."*

---

## 9.12 Latihan & Refleksi

### Pertanyaan Diagnostik

Seorang kepala divisi meminta *dashboard* yang memuat seluruh data agar pengambilan keputusan berlangsung lebih cepat. Analisis mengapa permintaan tersebut bermasalah, bagaimana jabatan, tujuan keputusan, horizon waktu, dan risiko keputusan diterjemahkan menjadi kebutuhan informasi yang spesifik, serta tanda bahwa organisasi sedang menghadapi *information overload*, bukan *information gap*.

### Pertanyaan Reflektif

1. Pilih satu keputusan rutin yang Anda buat di pekerjaan atau studi. Informasi apa yang Anda butuhkan untuk membuat keputusan itu? Apakah informasi tersebut tersedia dalam SI yang ada? Jika tidak — mengapa, dan bagaimana Anda meng-*workaround* ketiadaan itu?

2. Mengapa kebutuhan informasi level strategis paling sering diabaikan dalam perancangan SI? Identifikasi minimal dua faktor penyebab dan dampaknya terhadap kualitas keputusan organisasi.

3. Apakah AI akan menggantikan peran manajer dalam mendefinisikan kebutuhan informasi, atau justru membuat peran manajer lebih penting? Argumentasikan posisi Anda dengan merujuk kasus IBM Watson for HR.

4. Berikan contoh *information overload* yang pernah Anda alami — di pekerjaan, studi, atau bahkan dari notifikasi ponsel Anda. Bagaimana desain SI bisa membantu alih-alih memperparah situasi tersebut?

### Latihan Artefak

**Latihan 9.1 — *Information Requirement Table* (Template A.9)**

Gunakan Template A.9 untuk memetakan kebutuhan informasi **satu jabatan** di organisasi yang Anda kenal. Idealnya, lakukan di **tiga level** berbeda (operasional, taktis, strategis) dalam organisasi yang sama.

Langkah:
1. Identifikasi satu organisasi nyata (kampus, tempat kerja, organisasi mahasiswa)
2. Pilih tiga jabatan yang mewakili tiga level manajemen
3. Untuk setiap jabatan, identifikasi 3–5 kebutuhan informasi beserta keputusan yang didukung
4. Evaluasi status saat ini (tersedia / *partial* / tidak tersedia)
5. Identifikasi minimal 3 *information gap* dan prioritaskan

**Kriteria output yang baik:**
- Organisasi nyata yang bisa diobservasi, bukan hipotetis
- Kebutuhan informasi spesifik dan terkait keputusan konkret — bukan generik
- *Gap* yang diidentifikasi realistis dan didukung bukti (pengamatan, wawancara informal)
- Rekomendasi Section E mengarah ke implikasi desain SI yang spesifik

*Output Artefak 9.1 menjadi input untuk pemodelan proses bisnis di Bab 10.*

---

## Referensi

Anthony, R. N. (1965). *Planning and control systems: A framework for analysis*. Harvard Business School Press.

Forrester Research. (2023). *The state of business requirements practices*. Forrester.

Gartner Research. (2023). *Data-driven decision making survey*. Gartner, Inc.

Gorry, G. A., & Scott Morton, M. S. (1971). A framework for management information systems. *Sloan Management Review*, *13*(1), 55–70.

IBM. (2022). *Smarter workforce: Watson for HR case study*. IBM Corporation.

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

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

O'Brien, J. A., & Marakas, G. M. (2021). *Management information systems* (11th ed.). McGraw-Hill.

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

Rockart, J. F. (1979). Chief executives define their own data needs. *Harvard Business Review*, *57*(2), 81–93.

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

Schwartz, B. (2004). *The paradox of choice: Why more is less*. Harper Perennial.

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

Supriyadi, D., & Handoko, T. (2023). Evaluasi sistem informasi manajemen kepegawaian berbasis e-government di Indonesia. *Jurnal Administrasi Publik*, *11*(1), 78–94.
