--- marp: true theme: gaia class: invert paginate: true header: "BAB 11 — Perancangan Konseptual Sistem Informasi" footer: "Helmi Bahar Alim, S.Kom., M.Kom. | Universitas Putra Bangsa — Kebumen" style: | section { font-family: 'Segoe UI', Helvetica, sans-serif; font-size: 21px; } h1 { color: #ffd166; } h2 { color: #06d6a0; border-bottom: 2px solid #06d6a060; padding-bottom: 4px; } h3 { color: #8ecae6; } blockquote { border-left: 4px solid #ffd166; background: #ffffff15; padding: 0.5em 1em; font-style: italic; } table { font-size: 18px; width: 100%; } th { background: #06d6a040; } code { background: #ffffff20; } .lead h1 { font-size: 2em; color: #ffd166; } .lead h2 { font-size: 1.3em; border: none; color: #e0e0e0; } .bagian { font-size: 0.8em; color: #8ecae6; letter-spacing: 1px; } .lead p { font-size: 0.9em; color: #c0c0c0; } --- # BAB 11 ## Perancangan Konseptual Sistem Informasi
V — Perancangan Solusi SI
**Level:** Lanjutan --- ## 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 | Info | Detail | |------|--------| | **Bagian** | V — Perancangan Solusi SI | | **Level** | Lanjutan | | **Sub-topik** | 6 konsep inti | --- ## Pertanyaan Pemantik 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. --- _Bagaimana manajer merancang arsitektur konseptual SI yang menghubungkan kebutuhan bisnis dengan kapabilitas teknis — tanpa harus menjadi programmer?_ --- ## Model Utama — Gambar 11.1 ```mermaid 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 ``` **Signature Model — Bab 11** --- ## Definisi Kunci **Conceptual Design** Tahap perancangan SI yang berfokus pada "apa" yang harus dilakukan sistem — fungsionalitas, alur data, dan *output* yang diharapkan — bukan "bagaimana > __ --- ## Konsep Inti — Bagian 1 - **1.** Perancangan Konseptual vs Teknis: Batas yang Harus Dipahami Manajer - **2.** Model IPO dan Komponennya - **3.** Spesifikasi *Output*: Apa yang Dibutuhkan Pengguna Akhir --- ## Konsep Inti — Bagian 2 - **4.** Spesifikasi *Input*: Sumber, Format, Frekuensi Data - **5.** Aturan Bisnis sebagai Logika Proses - **6.** Komunikasi Desain Konseptual kepada Tim Teknis --- ## ⚠️ Salah Kaprah > ⚠️ _"Desain sistem itu urusan programmer, manajer tidak perlu terlibat"_ ↳ Manajer harus minimal menyusun *design brief* satu halaman sebelum *development* dimulai — mendefinisikan *output*, *input*, aturan bisnis, dan pengguna. > ⚠️ _"Kalau sistemnya canggih secara teknis, pasti memenuhi kebutuhan bisnis"_ ↳ Selalu mulai dari kebutuhan bisnis (Bab 5), bukan dari teknologi. > ⚠️ _"Cukup beri tahu vendor apa masalahnya, mereka tahu cara merancang sistemnya"_ ↳ Sediakan *design brief* SEBELUM bicara dengan vendor. --- ## 🔧 Template A.11 ### Template A.11 ``` ``` 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 | |----------------|---------------|----------------------| | ______________ | _____________ | ____________________ | | ______________ | _____________ | ____________________ | ``` --- ## Rangkuman 1. Perancangan konseptual adalah domain manajer — bukan programmer. 2. Model IPO (*Input-Process-Output*) adalah kerangka paling universal untuk perancangan konseptual. 3. *Design brief* satu halaman adalah format paling efektif untuk menghubungkan perspektif manajer dan tim teknis. 4. Aturan bisnis adalah "kecerdasan" SI — empat jenis (validasi, derivasi, *constraint*, *trigger*) yang membedakan SI dari sekadar *database* dan formulir. 5. Proyek SI di mana manajer mendominasi desain konseptual memiliki *user satisfaction* 72% vs 38% pada proyek yang didominasi *developer* (Gartner, 2023). --- ## 🔥 Final Statement > "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." --- ## Latihan & Refleksi ### 📝 Latihan 11.1 — *Design Brief* SI (Template A.11) ### ➡️ 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 _ ---