BAB 11 — Perancangan Konseptual Sistem Informasi

Bagian          : V — Perancangan Solusi SI
Reader Outcome  : Pembaca mampu merancang arsitektur konseptual SI menggunakan
                  model IPO dan menerjemahkan kebutuhan manajerial ke dalam
                  spesifikasi sistem yang dapat dikomunikasikan kepada tim teknis.
Level           : Lanjutan
Estimasi Halaman: 15–18

11.1 Pembuka

Bab 10 membekali Anda dengan kemampuan memodelkan proses bisnis — dari pemetaan AS-IS yang apa adanya hingga perancangan TO-BE yang mengeliminasi bottleneck dan redundansi. Template A.10 (Worksheet Diagram AS-IS) menghasilkan dokumentasi proses lengkap dengan analisis value-adding dan non-value-adding. Proses TO-BE sudah tergambar. Tetapi model proses belum menjawab pertanyaan berikutnya: secara konseptual, SI seperti apa yang dibutuhkan untuk mendukung proses tersebut?

Seorang kepala desa di Kabupaten Bantul membutuhkan sistem administrasi kependudukan. Ia memanggil "orang IT" dan berkata: "Buatkan saya sistem informasi desa." Enam bulan kemudian, sistem jadi — lengkap dengan modul GIS dan data mining. Tetapi sistem itu tidak bisa mencetak surat keterangan domisili, hal yang diminta warga 10 kali per hari. Programmer merancang berdasarkan asumsinya tentang "apa yang keren untuk desa" — bukan berdasarkan apa yang benar-benar dibutuhkan perangkat desa. Akar masalahnya: kepala desa tidak pernah menyusun spesifikasi konseptual sebelum menyerahkan pekerjaan ke programmer.

Bagaimana manajer merancang arsitektur konseptual SI yang menghubungkan kebutuhan bisnis dengan kapabilitas teknis — tanpa harus menjadi programmer?

11.2 Model Utama

Gambar 11.1 — Model IPO Berlapis (Three-Tier Architecture)

graph TD
    subgraph INPUT["INPUT"]
        style INPUT fill:#1a4a5c,stroke:#333,color:#fff
        I1["Data Transaksi"]
        I2["Data Eksternal"]
        I3["Data Pengguna"]
    end
    subgraph PROCESS["PROCESS"]
        style PROCESS fill:#1a4a5c,stroke:#333,color:#fff
        P1["Validasi"]
        P2["Transformasi"]
        P3["Analitik"]
        P4["Aturan Bisnis"]
    end
    subgraph OUTPUT["OUTPUT"]
        style OUTPUT fill:#1a4a5c,stroke:#333,color:#fff
        O1["Laporan"]
        O2["Dashboard"]
        O3["Alert"]
        O4["Rekomendasi"]
    end
    subgraph STORAGE["STORAGE"]
        style STORAGE fill:#f5f5f5,stroke:#1a4a5c,color:#333
        ST1["Database Operasional"]
        ST2["Data Warehouse"]
    end
    INPUT --> PROCESS
    PROCESS --> OUTPUT
    PROCESS <--> STORAGE
    OUTPUT -.->|feedback loop| INPUT

INPUT — semua sumber data yang masuk ke SI: data transaksi internal (penjualan, inventori, kehadiran), data eksternal (data pasar, regulasi, cuaca), dan data pengguna (preferensi, feedback, parameter query). Manajer harus menentukan: dari mana data datang, dalam format apa, seberapa sering, dan apakah data itu sudah tersedia atau harus dikumpulkan.

PROCESS — logika bisnis yang mengolah data mentah menjadi informasi bernilai: validasi (apakah data benar dan lengkap?), transformasi (konversi ke format standar), analitik (hitung KPI, agregasi, perbandingan), dan aturan bisnis (jika X terjadi maka lakukan Y). Di sinilah "kecerdasan" SI berada — tanpa logika proses, SI hanyalah tempat penyimpanan data.

OUTPUT — produk SI yang digunakan pengambil keputusan: laporan periodik, dashboard real-time, alert berbasis pengecualian, dan rekomendasi keputusan. Output harus diturunkan langsung dari kebutuhan informasi yang sudah dipetakan di Bab 5 — bukan dari imajinasi developer tentang apa yang "seharusnya" dibutuhkan manajer.

STORAGE — penyimpanan data dalam dua kategori: database operasional untuk transaksi harian dan data warehouse untuk analitik historis. Manajer tidak perlu memahami teknis schema atau indexing — tetapi perlu memahami: data apa yang harus disimpan, berapa lama, dan siapa yang boleh mengaksesnya.

Feedback Loop — output SI menghasilkan keputusan yang menghasilkan tindakan yang menghasilkan data baru — siklus yang terus berputar. Dashboard penjualan menunjukkan penurunan di region tertentu → manajer memutuskan promosi → data promosi masuk kembali sebagai input → dashboard menunjukkan dampak promosi.

11.3 Definisi Kunci

Conceptual Design (Perancangan Konseptual) Tahap perancangan SI yang berfokus pada "apa" yang harus dilakukan sistem — fungsionalitas, alur data, dan output yang diharapkan — bukan "bagaimana" secara teknis (bahasa pemrograman, database engine, infrastruktur server). Perancangan konseptual adalah domain manajer. Valacich et al. (2021) membedakan tegas: manajer mendefinisikan requirements, tim teknis menerjemahkannya menjadi design specifications.

Design Brief Dokumen terstruktur (idealnya satu halaman) yang merangkum spesifikasi konseptual SI: siapa penggunanya, input apa yang dibutuhkan, proses atau aturan bisnis apa yang berlaku, output apa yang diharapkan, dan constraint apa yang harus diperhatikan. Design brief berfungsi sebagai "kontrak" antara manajer dan tim teknis — mencegah momen "saya bilang saya mau begini, bukan begitu" di akhir proyek. Proyek dengan design brief formal memiliki rework rate 35% lebih rendah (Satzinger et al., 2022).

Business Rules (Aturan Bisnis) Kebijakan, prosedur, atau constraint yang harus diimplementasikan dalam logika SI — misalnya: "persetujuan kredit di atas Rp 100 juta harus melalui Direksi," "notifikasi otomatis jika stok di bawah safety stock," atau "NIP tidak boleh duplikat." Aturan bisnis adalah "kecerdasan" yang membedakan SI dari sekadar database dan formulir. Manajer adalah sumber utama aturan bisnis — bukan developer.

11.4 Konsep Inti

11.4.1 Perancangan Konseptual vs Teknis: Batas yang Harus Dipahami Manajer

Manajer tidak perlu merancang database, menulis kode, atau memilih infrastruktur server. Tetapi manajer harus bisa mendefinisikan: apa input SI, proses apa yang dilakukan terhadap data, output apa yang diharapkan, siapa penggunanya, dan aturan bisnis apa yang berlaku. Garis batas ini sederhana tetapi sering dilanggar — ke dua arah.

Pelanggaran pertama: manajer tidak terlibat sama sekali, menyerahkan seluruh desain ke tim teknis. Hasilnya: SI yang technically sound tetapi tidak menjawab kebutuhan bisnis. Pelanggaran kedua: manajer terlalu detail mendikte aspek teknis ("pakai database Oracle, bukan MySQL") padahal itu bukan kompetensinya. Hasilnya: keputusan teknis yang suboptimal.

Tabel 11.2 — Batas Tanggung Jawab: Manajer vs Tim Teknis

Data Standish Group (2023) menunjukkan 47% proyek SI gagal karena miscommunication antara sisi bisnis dan IT. Design brief yang jelas — di mana manajer mendefinisikan "apa" dan tim teknis merespons dengan "bagaimana" — mengurangi risiko ini hingga 40%.

11.4.2 Model IPO dan Komponennya

IPO (Input-Process-Output) adalah kerangka paling universal untuk perancangan konseptual. Setiap SI — dari aplikasi kasir warung hingga enterprise resource planning — pada dasarnya menerima input, memprosesnya, dan menghasilkan output. Kekuatan IPO bukan pada kecanggihan konsepnya, melainkan pada universalitasnya: manajer dari industri apa pun bisa menggunakan kerangka ini untuk menspesifikasikan kebutuhan SI.

Pendekatan yang paling efektif: mulai dari OUTPUT. Apa yang dibutuhkan pengguna? Dashboard real-time penjualan per region? Laporan bulanan deviasi budget? Alert jika inventory di bawah safety stock? Setelah output jelas, mundur ke PROCESS: logika apa yang diperlukan untuk menghasilkan output tersebut? Agregasi harian per region, perbandingan year-over-year, threshold monitoring. Lalu mundur lagi ke INPUT: data apa yang dibutuhkan? Data transaksi POS per toko, data budget per departemen, data stok per gudang.

Pendekatan "output-first" ini mencegah overbuilding — membangun fitur yang secara teknis memungkinkan tetapi tidak dibutuhkan siapa pun. Jika output tidak bisa dijustifikasi oleh kebutuhan keputusan (lihat Bab 5), fitur tersebut tidak perlu dibangun.

11.4.3 Spesifikasi Output: Apa yang Dibutuhkan Pengguna Akhir

Output adalah hal pertama yang harus didefinisikan karena output-lah yang langsung menjawab kebutuhan informasi dari Template A.5 (Bab 5). Lima kategori output SI:

1. Laporan periodik — harian, mingguan, bulanan. Format terstruktur, jadwal tetap. Contoh: laporan penjualan mingguan per region.
2. Dashboard real-time — visualisasi KPI yang di-update secara kontinu. Contoh: dashboard operasional gudang dengan stok per SKU.
3. Alert dan notifikasi — pemberitahuan berbasis aturan ketika terjadi pengecualian. Contoh: notifikasi ke manajer jika defect rate melebihi 2%.
4. Rekomendasi keputusan — output analitik yang menyarankan tindakan. Contoh: "region X menunjukkan pola penurunan — pertimbangkan promosi."
5. Dokumen cetak — surat, invoice, SK, sertifikat. Contoh: surat keterangan domisili yang dicetak oleh SI desa.

Data Standish Group (2023) melaporkan 65% fitur SI yang dibangun tidak pernah digunakan — mayoritas karena output tidak sesuai dengan apa yang benar-benar dibutuhkan pengambil keputusan. Spesifikasi output yang jelas dari awal mencegah pemborosan ini.

11.4.4 Spesifikasi Input: Sumber, Format, Frekuensi Data

Setelah output terdefinisi, manajer harus menspesifikasikan input: data apa yang diperlukan untuk menghasilkan setiap output yang sudah ditetapkan. Empat pertanyaan kunci:

• Ketersediaan: apakah data sudah ada di sistem yang dimiliki, atau harus dikumpulkan dari awal?
• Sumber: internal (dari SI lain dalam organisasi) atau eksternal (data pasar, regulasi, API pihak ketiga)?
• Metode entry: manual (input operator) atau otomatis (feed dari sensor, API, impor file)?
• Frekuensi: real-time (setiap transaksi langsung masuk), harian (batch upload), atau periodik (mingguan/bulanan)?

Spesifikasi input menentukan arsitektur teknis — meskipun manajer tidak perlu memikirkan arsitektur itu sendiri. Contoh: dashboard penjualan real-time mensyaratkan input real-time dari POS — bukan ekspor Excel harian. Jika input tidak mendukung, output yang diharapkan tidak bisa terwujud. Prinsip lama tetap berlaku: garbage in, garbage out — input yang buruk menghasilkan output yang tidak bisa dipercaya, sekeren apa pun visualisasinya.

11.4.5 Aturan Bisnis sebagai Logika Proses

Aturan bisnis adalah instruksi yang memberi "kecerdasan" pada SI. Tanpa aturan bisnis, SI hanyalah database dan formulir — menyimpan data tetapi tidak melakukan apa-apa dengannya. Empat jenis aturan bisnis yang harus didefinisikan manajer:

Validasi — memastikan data yang masuk benar dan konsisten. "NIP tidak boleh duplikat." "Tanggal lahir tidak boleh di masa depan." "Total invoice harus sama dengan jumlah detail item." Aturan validasi mencegah garbage in di titik entry.

Derivasi — perhitungan otomatis berdasarkan data yang ada. "Total = Qty × Harga − Diskon." "Masa kerja = Tanggal hari ini − TMT." "Sisa cuti = Jatah tahunan − Cuti terpakai." Aturan derivasi menghilangkan kalkulasi manual yang rawan error.

Constraint — pembatasan yang mencerminkan kebijakan organisasi. "Approval kredit di atas Rp 100 juta memerlukan tanda tangan Direksi." "Mutasi pegawai baru bisa diajukan setelah minimal 2 tahun di posisi saat ini." Aturan constraint mengotomasi kepatuhan terhadap kebijakan.

Trigger — aksi otomatis yang dipicu oleh kondisi tertentu. "Alert ke manajer gudang jika stok < safety stock." "Kirim pengingat ke HRD 6 bulan sebelum tanggal pensiun pegawai." "Eskalasi tiket ke supervisor jika tidak direspons dalam 24 jam." Aturan trigger membuat SI proaktif, bukan sekadar reaktif.

Contoh dampak aturan bisnis: SI Kepegawaian tanpa aturan bisnis hanyalah gudang data digital. Dengan keempat jenis aturan di atas: si menghitung masa kerja otomatis (derivasi), mengingatkan pensiun 6 bulan sebelumnya (trigger), memblokir mutasi jika belum 2 tahun (constraint), dan menolak NIP duplikat (validasi). SI yang sama, data yang sama — tetapi nilai manajerialnya berlipat ganda.

11.4.6 Komunikasi Desain Konseptual kepada Tim Teknis

Desain konseptual yang tersimpan di kepala manajer tidak bernilai — ia harus dikomunikasikan dalam format yang dipahami oleh manajer DAN tim teknis. Design brief satu halaman (Template A.11) adalah format paling efektif: cukup ringkas untuk dibaca dalam 5 menit, cukup terstruktur untuk menjadi acuan development, dan tidak membutuhkan keahlian teknis untuk menyusunnya.

Struktur design brief mengikuti alur logis: Latar Belakang (mengapa SI ini dibutuhkan) → Tujuan (apa yang ingin dicapai) → Pengguna (siapa yang menggunakan) → Output (apa yang dihasilkan) → Input (data apa yang masuk) → Aturan Bisnis (logika apa yang berlaku) → Constraint (batasan budget, waktu, regulasi) → Kriteria Sukses (bagaimana mengukur keberhasilan).

Data dari 500 proyek SI di Asia Tenggara (Gartner, 2023) menunjukkan bahwa proyek dengan design brief formal dari sisi bisnis memiliki user satisfaction 72%, dibandingkan 38% untuk proyek tanpa design brief. Satzinger et al. (2022) mengonfirmasi bahwa rework rate turun 35% ketika design brief ada sebelum coding dimulai.

Satu prinsip komunikasi yang sering dilanggar: design brief harus disusun SEBELUM bicara dengan vendor atau tim teknis — bukan setelah. Jika manajer mendengar demo vendor terlebih dahulu, pikirannya sudah ter-anchor pada solusi vendor, bukan pada kebutuhan asli organisasi.

11.5 Komparasi

Tabel 11.1 — Perspektif Manajer vs Perspektif Teknis dalam Perancangan SI

Insight: Perancangan SI gagal ketika kedua perspektif ini tidak saling bicara — manajer frustrasi karena "IT tidak paham bisnis" sementara IT frustrasi karena "bisnis tidak bisa menjelaskan maunya." Design brief berfungsi sebagai penerjemah: ia menerjemahkan "saya butuh laporan penjualan harian" menjadi spesifikasi yang cukup jelas bagi tim teknis, tanpa manajer harus memahami REST API dan tanpa developer harus memahami strategi revenue.

11.6 Realitas Lapangan

Fenomena 1: Sistem Informasi Desa (SID) — Ketika Kebutuhan Sederhana Bertemu Developer Kompleks

Ribuan desa di Indonesia memperoleh SID dari program pemerintah pusat atau CSR perusahaan teknologi. Pola yang berulang: SID dirancang oleh developer di kota besar tanpa pernah mengunjungi desa atau mewawancarai perangkat desa. Sistem memiliki modul GIS (Geographic Information System), data mining, dan visualisasi statistik — tetapi tidak bisa mencetak surat keterangan domisili dengan format yang sesuai regulasi kabupaten setempat.

Perangkat desa yang diwawancarai mengungkap bahwa 80% aktivitas hariannya adalah mencetak surat (domisili, pengantar, keterangan tidak mampu, keterangan usaha) dan menyusun laporan APBDes. Modul GIS tidak pernah dibuka satu kali pun. Spesifikasi konseptual SID dibuat oleh developer — bukan oleh perangkat desa yang menggunakannya setiap hari.

Insight: SI yang dirancang tanpa design brief dari pengguna akan selalu menjadi "sistem developer" — bukan "sistem organisasi." Design brief memastikan fitur yang paling sering dibutuhkan menjadi prioritas pembangunan, bukan fitur yang paling impresif untuk presentasi di seminar.

Fenomena 2: Salesforce CRM — Arsitektur Konseptual yang Melayani Ribuan Industri

Salesforce digunakan oleh 150.000+ perusahaan di ratusan industri berbeda — dari bank multinasional hingga organisasi nonprofit. Rahasianya bukan kode yang sangat kompleks, melainkan arsitektur konseptual yang fleksibel: model IPO yang bisa dikustomisasi tanpa coding.

Salesforce memisahkan tiga lapisan: Objects (entitas data yang bisa didefinisikan business analyst), Validation Rules dan Process Builder (aturan bisnis yang bisa dikonfigurasi tanpa coding), dan Reports/Dashboards (output yang bisa di-drag-and-drop). Setiap perusahaan mendefinisikan input, aturan bisnis, dan output sendiri — sesuai design brief mereka — tanpa mengubah satu baris kode pun.

Insight: Arsitektur konseptual yang baik bukan yang paling canggih — tetapi yang paling adaptif. Salesforce membuktikan bahwa satu kerangka konseptual (IPO + business rules) bisa melayani kebutuhan yang sangat beragam jika dirancang dengan fleksibilitas sebagai prinsip dasar.

Fenomena 3: "Spec by Developer" vs "Spec by Business" — Data dari 500 Proyek SI

Gartner (2023) menganalisis 500 proyek SI di Asia Tenggara dan membandingkan dua pola: proyek di mana spesifikasi konseptual didominasi tim teknis vs proyek di mana manajer bisnis aktif mendefinisikan spesifikasi. Hasilnya kontras:

• User satisfaction: 38% (spec by developer) vs 72% (spec by business)
• User adoption setelah 6 bulan: 45% vs 83%
• Rework rate: 52% vs 18%
• Proyek selesai tepat waktu: 29% vs 58%

Angka-angka ini menegaskan satu hal: keterlibatan manajer di fase desain konseptual bukan opsi — ia prasyarat. SI yang dispesifikasi oleh developer saja menghasilkan sistem yang technically excellent tetapi functionally irrelevant.

Insight: Manajer yang berkata "saya tidak mengerti teknologi, serahkan saja ke IT" sedang membuat keputusan yang mahal. Tidak perlu mengerti teknologi — cukup mengerti kebutuhan bisnis sendiri dan mengartikulasikannya dalam design brief.

11.7 Salah Kaprah

"Desain sistem itu urusan programmer, manajer tidak perlu terlibat"

Programmer memahami teknologi, bukan konteks keputusan bisnis. Programmer tahu cara membangun dashboard — tetapi tidak tahu dashboard mana yang dibutuhkan manajer untuk memutuskan alokasi budget kuartal depan. Manajer yang tidak terlibat di desain konseptual akan menerima SI yang technically correct tetapi business-irrelevant — dan baru mengeluh setelah sistem sudah dibangun, ketika perubahan sudah mahal dan proses sudah terlambat.

Koreksi: Manajer harus minimal menyusun design brief satu halaman sebelum development dimulai — mendefinisikan output, input, aturan bisnis, dan pengguna. Bukan memprogram sistem — melainkan mengarahkannya.

"Kalau sistemnya canggih secara teknis, pasti memenuhi kebutuhan bisnis"

Kompleksitas teknis tidak berkorelasi dengan nilai bisnis. Sistem dengan machine learning, real-time analytics, dan arsitektur microservices tidak berguna jika output-nya bukan informasi yang dibutuhkan manajer untuk keputusan sehari-hari. SID dengan GIS dan data mining yang tidak bisa mencetak surat domisili adalah contoh sempurna: canggih secara teknis, gagal secara fungsional.

Koreksi: Selalu mulai dari kebutuhan bisnis (Bab 5), bukan dari teknologi. Pertanyaan pertama yang benar: "Informasi apa yang dibutuhkan untuk keputusan ini?" — bukan "Teknologi apa yang bisa dipakai?"

"Cukup beri tahu vendor apa masalahnya, mereka tahu cara merancang sistemnya"

Vendor memiliki insentif untuk menjual solusi yang mereka miliki — bukan solusi terbaik untuk organisasi Anda. Tanpa design brief yang jelas dari manajer, vendor akan merancang SI berdasarkan template mereka yang sudah ada, ditambah beberapa kustomisasi kosmetik. Hasilnya: organisasi membeli "solusi vendor" yang kemudian harus disesuaikan secara mahal — atau lebih sering: organisasi yang menyesuaikan prosesnya agar cocok dengan sistem vendor.

Koreksi: Sediakan design brief SEBELUM bicara dengan vendor. Vendor harus merespons spesifikasi Anda — bukan Anda yang merespons demo mereka. Organisasi yang datang tanpa design brief ke presentasi vendor akan pulang dengan membeli apa yang vendor jual, bukan apa yang organisasi butuhkan.

11.8 Studi Kasus

Studi Kasus Dasar — SID Bantul: Perancangan Konseptual untuk Administrasi Desa

Kondisi Awal: Sebuah desa di Bantul memiliki SID yang diberikan melalui program digitalisasi desa. Modul tersedia: kependudukan, aset desa, GIS, data mining. Tetapi perangkat desa hanya menggunakan 20% fitur — dan fitur yang paling mereka butuhkan (cetak surat harian dan laporan APBDes) justru sulit dilakukan karena template surat tidak sesuai format kabupaten.

Setelah Design Brief oleh Perangkat Desa: Fasilitator memandu perangkat desa menyusun design brief sederhana dengan satu pertanyaan inti: "Output apa yang paling sering Anda butuhkan setiap hari?"

Tabel 11.3 — Design Brief Hasil Penggalian Kebutuhan Desa

Dengan design brief ini, pengembang merevisi SID: memprioritaskan template surat yang bisa dicetak dalam 2 klik, formulir input yang sesuai alur kerja perangkat desa, dan laporan APBDes yang otomatis mengikuti format regulasi. Modul GIS tetap ada tetapi dipindahkan ke menu sekunder.

Pelajaran: SID yang dirancang dari perspektif developer memiliki GIS dan data mining — fitur yang tidak pernah digunakan. Design brief dari perangkat desa menunjukkan bahwa 80% kebutuhan adalah cetak surat dan laporan standar — fitur yang sederhana tetapi kritis dan harus bekerja sempurna setiap hari.

Studi Kasus Lanjutan — Salesforce: Arsitektur Konseptual yang Scalable

Kondisi Awal: Sebelum era cloud CRM, setiap perusahaan membangun CRM custom — proyek yang memakan 6–12 bulan development, biaya miliaran rupiah, dan menghasilkan sistem yang sulit di-maintain. Setiap kali kebutuhan bisnis berubah (produk baru, reorganisasi tim penjualan, perubahan pricing), diperlukan coding ulang yang memakan waktu berminggu-minggu.

Arsitektur Konseptual Salesforce: Salesforce merancang arsitektur IPO yang configurable: Objects (entitas data) → Fields (input) → Validation & Process Rules (aturan bisnis) → Reports/Dashboards (output) — semuanya bisa dikustomisasi oleh business analyst tanpa coding.

Tabel 11.4 — CRM Custom vs Salesforce

Kunci kesuksesan Salesforce bukan fiturnya yang banyak — melainkan keputusan arsitektural untuk memisahkan "logika bisnis" dari "kode program." Manajer bisa mengubah aturan bisnis (menambah field, mengubah workflow, membuat laporan baru) tanpa menunggu developer. Ini mewujudkan prinsip perancangan konseptual: manajer mengendalikan "apa," developer mengendalikan "bagaimana."

Pelajaran: Arsitektur konseptual yang baik memprioritaskan adaptability di atas kompleksitas. Salesforce membuktikan bahwa manajer bisa — dan seharusnya — mengendalikan logika bisnis SI tanpa bergantung penuh pada tim teknis untuk setiap perubahan kecil.

11.9 Template Praktis

Template A.11 — Design Brief SI (Satu Halaman)

TEMPLATE A.11 — DESIGN BRIEF SI (1 HALAMAN)

Tanggal            : ________________________________________
Penyusun           : ________________________________________
Organisasi/Unit    : ________________________________________

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

1. LATAR BELAKANG (2–3 kalimat)
   Masalah yang mendorong kebutuhan SI ini:
   ___________________________________________________________
   ___________________________________________________________

2. TUJUAN SI (1 kalimat, action verb)
   "SI ini dirancang untuk ___________________________________
    sehingga ________________________________________________"

3. PENGGUNA

| Pengguna       | Level         | Frekuensi Penggunaan |
|----------------|---------------|----------------------|
| ______________ | _____________ | ____________________ |
| ______________ | _____________ | ____________________ |
| ______________ | _____________ | ____________________ |

4. SPESIFIKASI OUTPUT (mulai dari sini!)

| Output         | Format        | Frekuensi   | Untuk Keputusan      |
|----------------|---------------|-------------|----------------------|
| ______________ | _____________ | ___________ | ____________________ |
| ______________ | _____________ | ___________ | ____________________ |
| ______________ | _____________ | ___________ | ____________________ |

5. SPESIFIKASI INPUT

| Data           | Sumber        | Format      | Frekuensi            |
|----------------|---------------|-------------|----------------------|
| ______________ | _____________ | ___________ | ____________________ |
| ______________ | _____________ | ___________ | ____________________ |

6. ATURAN BISNIS KUNCI
   a. ________________________________________________________
   b. ________________________________________________________
   c. ________________________________________________________

7. CONSTRAINT
   Budget       : ________________________________________
   Timeline     : ________________________________________
   Integrasi    : Harus terhubung dengan ________________
   Regulasi     : ________________________________________

8. KRITERIA SUKSES (bagaimana mengukur SI ini berhasil?)
   ________________________________________________________
   ________________________________________________________

11.10 Peta Konsep

Gambar 11.2 — Peta Konsep Perancangan Konseptual SI

mindmap
  root((Perancangan Konseptual SI))
    Model IPO
      Input: sumber & format data
      Process: aturan bisnis 4 jenis
      Output: first priority
      Storage: apa & berapa lama
      Feedback loop
    Design Brief
      Dokumen 1 halaman
      Translator bisnis — teknis
      Output-first approach
      Sebelum bicara vendor
    Batas Tanggung Jawab
      Manajer: APA
      Tim Teknis: BAGAIMANA
      Design Brief: penghubung
    Anti-pattern
      Spec by developer only
      Feature-driven bukan need-driven
      Tanpa design brief
      Vendor-led specification
    Kaitan
      Input dari Bab 5 dan 10
      Output ke Bab 12

11.11 Rangkuman

Poin-poin Penting:

1. Perancangan konseptual adalah domain manajer — bukan programmer. Manajer mendefinisikan "apa" yang dibutuhkan (fungsionalitas, aturan bisnis, output); tim teknis mendefinisikan "bagaimana" membangunnya (arsitektur, coding, infrastruktur).

2. Model IPO (Input-Process-Output) adalah kerangka paling universal untuk perancangan konseptual. Pendekatan yang paling efektif: mulai dari OUTPUT — apa yang dibutuhkan pengguna akhir — lalu mundur ke proses dan input.

3. Design brief satu halaman adalah format paling efektif untuk menghubungkan perspektif manajer dan tim teknis. Proyek dengan design brief formal memiliki rework rate 35% lebih rendah dan user satisfaction hampir dua kali lipat (Satzinger et al., 2022; Gartner, 2023).

4. Aturan bisnis adalah "kecerdasan" SI — empat jenis (validasi, derivasi, constraint, trigger) yang membedakan SI dari sekadar database dan formulir. Manajer harus mendefinisikan aturan bisnis; developer hanya mengimplementasikannya.

5. Proyek SI di mana manajer mendominasi desain konseptual memiliki user satisfaction 72% vs 38% pada proyek yang didominasi developer (Gartner, 2023). Keterlibatan manajer bukan opsi — ia prasyarat.

6. Design brief harus disusun SEBELUM bicara dengan vendor atau tim teknis. Vendor yang merespons design brief akan memberikan solusi yang sesuai kebutuhan; manajer yang merespons demo vendor akan membeli apa yang vendor jual.

Menuju Bab 12:

Desain konseptual sudah tersusun — input, proses, output, dan aturan bisnis sudah terdefinisi dalam design brief. Pertanyaan selanjutnya bersifat strategis: apakah membangun SI sendiri (custom development), membeli paket jadi (COTS — Commercial Off-The-Shelf), atau menyewa dari cloud (SaaS)? Setiap opsi memiliki implikasi biaya, fleksibilitas, risiko, dan ketergantungan yang berbeda. Bab 12 membahas evaluasi alternatif solusi SI — keputusan make vs buy vs rent yang menentukan nasib investasi SI organisasi.

"Sistem informasi yang baik tidak dimulai dari kode program, melainkan dari pemahaman mendalam tentang keputusan apa yang harus didukung oleh setiap byte data yang dikumpulkan."

11.12 Latihan & Refleksi

Pertanyaan Diagnostik

Organisasi telah memiliki gambaran proses as-is dan daftar kebutuhan informasi, tetapi solusi yang diusulkan masih berupa daftar fitur yang tidak terpadu. Analisis apakah perancangan konseptual tersebut telah koheren dari sisi aktor, data, alur input-output, dan business rules, serta jelaskan konsekuensi ketika tim melompat ke desain layar sebelum logika sistem dimatangkan.

Pertanyaan Reflektif

1. Pernahkah Anda menggunakan SI yang "tidak sesuai" dengan kebutuhan — fitur yang dibutuhkan tidak ada, atau fitur yang ada tidak pernah digunakan? Apakah ada design brief yang disusun sebelumnya? Apa yang bisa diperbaiki jika proses perancangan diulang?

2. Mengapa pendekatan "output-first" lebih efektif daripada "input-first" dalam perancangan konseptual SI? Berikan contoh konkret di mana memulai dari input menghasilkan fitur yang tidak dibutuhkan.

3. Siapa yang seharusnya memiliki "ownership" atas aturan bisnis dalam SI — manajer atau developer? Apa risikonya jika ownership dipegang oleh pihak yang salah?

Latihan Artefak

Latihan 11.1 — Design Brief SI (Template A.11)

Gunakan Template A.11 untuk menyusun spesifikasi konseptual satu halaman bagi SI yang:

• Menyelesaikan masalah dari Template A.4 (Bab 4)
• Memenuhi kebutuhan informasi dari Template A.5 (Bab 5)
• Mendukung proses TO-BE dari Template A.10 (Bab 10)

Langkah:

1. Ambil rumusan masalah dari Problem Statement Canvas (A.8) sebagai latar belakang
2. Ambil kebutuhan informasi dari Information Requirement Table (A.9) sebagai dasar output
3. Ambil proses TO-BE dari Worksheet AS-IS (A.10) sebagai dasar input dan aturan bisnis
4. Integrasikan ketiganya menjadi satu design brief yang koheren
5. Pastikan setiap output terhubung ke kebutuhan informasi yang sudah didefinisikan

Kriteria output yang baik:

• Output spesifik dan terhubung ke keputusan konkret (bukan generik "laporan manajemen")
• Aturan bisnis minimal 3 — mencakup validasi, derivasi, dan constraint atau trigger
• Constraint realistis (termasuk estimasi budget dan timeline yang masuk akal)
• Kriteria sukses terukur (bukan "sistem berguna" tetapi "waktu proses turun dari 14 hari ke 5 hari")

Output Artefak 11.1 menjadi input untuk evaluasi alternatif solusi di Bab 12.

Referensi

Gartner Research. (2023). IT project delivery benchmarks in Southeast Asia. Gartner, Inc.

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

Rainer, R. K., Prince, B., & Watson, H. J. (2023). Management information systems (5th ed.). Wiley.

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.

Valacich, J. S., George, J. F., & Hoffer, J. A. (2021). Essentials of systems analysis and design (7th ed.). Pearson.