← Chapters

BAB 5 — Kebutuhan Informasi Manajerial

BAB 5 — Kebutuhan Informasi Manajerial

Bagian          : II — Fondasi Berpikir Manajerial
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

5.1 Pembuka

Bab 4 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.4 (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?


5.2 Model Utama

Gambar 5.1 — Piramida Kebutuhan Informasi Manajerial

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.


5.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.


5.4 Konsep Inti

5.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 9), 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.

5.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.

5.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.

5.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).

5.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.

5.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.5 — 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.


5.5 Komparasi

Tabel 5.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.


5.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.


5.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.


5.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 5.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 5.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.


5.9 Template Praktis

Template A.5 — Information Requirement Table

Template A.5 — 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)
   ________________________________________
   ________________________________________
   ________________________________________

5.10 Peta Konsep

Gambar 5.2 — Peta Konsep Kebutuhan Informasi Manajerial

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

5.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.5) adalah jembatan kritis dari analisis (Bagian IV) ke desain (Bagian V) — tanpanya, perancangan SI menjadi latihan teknis tanpa arah.


Menuju Bab 6:

Kebutuhan informasi sudah terpetakan per level manajemen — Template A.5 menghasilkan daftar informasi yang dibutuhkan, oleh siapa, dalam format apa, dan untuk keputusan apa. Pertanyaan berikutnya: di departemen mana data itu sebenarnya diproduksi, dan sistem informasi fungsional apa yang secara konkret mendukung aktivitas sehari-hari di pemasaran, keuangan, operasional, dan SDM? Bab 6 menjawab pertanyaan itu dengan memetakan sistem informasi pada tiap fungsi bisnis — menjembatani kebutuhan informasi manajerial dengan kapabilitas SI yang tersedia di lapangan.


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


5.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 5.1 — Information Requirement Table (Template A.5)

Gunakan Template A.5 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 5.1 menjadi input untuk pemahaman SI fungsional dan ekosistem sistem lintas-departemen di Bab 6.


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.

Helmi Bahara
About the author Helmi Bahara

Systems Architect & AI Workflow Thinker