sim-manajement-book/chapters/outlines/outline-bab-11.md

OUTLINE DETAIL — BAB 11

Perancangan Konseptual Sistem Informasi

Bagian: V — Perancangan Solusi SI
Level: Lanjutan
Estimasi Halaman: 15–18
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.

---

SEK 11.1 — PEMBUKA

Hook: 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 — tetapi tidak bisa cetak surat pengantar (hal paling sering diminta warga), karena programmer merancang berdasarkan asumsinya sendiri. Manajer yang tidak bisa menyusun spesifikasi konseptual akan mendapat sistem yang dibuat "untuk" mereka, bukan "oleh" masukan mereka.

Opening Bridge (dari Bab 10):

Bab 10 memodelkan proses bisnis TO-BE — alur kerja ideal yang harus didukung oleh SI. Pertanyaan selanjutnya: secara konseptual, SI seperti apa yang dibutuhkan untuk mendukung proses tersebut? Bab ini membekali manajer dengan kemampuan menyusun "design brief" — dokumen yang menerjemahkan kebutuhan bisnis ke dalam spesifikasi yang bisa dipahami oleh tim teknis.

Central Question:

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

---

SEK 11.2 — MODEL UTAMA (Gambar 11.1)

Nama Model: Model IPO Berlapis (Three-Tier Architecture)

graph TD
    subgraph INPUT["INPUT"]
        I1[Data Transaksi]
        I2[Data Eksternal]
        I3[Data Pengguna]
    end
    subgraph PROCESS["PROCESS"]
        P1[Validasi]
        P2[Transformasi]
        P3[Analitik]
        P4[Aturan Bisnis]
    end
    subgraph OUTPUT["OUTPUT"]
        O1[Laporan]
        O2[Dashboard]
        O3[Alert]
        O4[Rekomendasi]
    end
    subgraph STORAGE["STORAGE"]
        ST1[Database]
        ST2[Data Warehouse]
    end
    INPUT --> PROCESS
    PROCESS --> OUTPUT
    PROCESS <--> STORAGE
    OUTPUT -.->|feedback loop| INPUT

Penjelasan Node:

• INPUT — semua sumber data yang masuk ke SI: data transaksi internal (penjualan, inventory), data eksternal (market data, regulasi), data pengguna (preferensi, feedback). Manajer harus menentukan: dari mana data datang, format apa, seberapa sering.
• PROCESS — logika bisnis yang memproses data: validasi (data benar?), transformasi (format standar), analitik (hitung KPI), aturan bisnis (if X then Y). Ini jantung SI — di sinilah "intelligence" berada.
• OUTPUT — produk yang dihasilkan SI untuk pengguna: laporan periodik, dashboard real-time, alert exception, rekomendasi keputusan. Output harus diturunkan dari kebutuhan informasi Bab 9.
• STORAGE — penyimpanan data: database operasional (transaksi harian) dan data warehouse (analitik historis). Manajer tidak perlu memahami teknis database — tetapi perlu memahami: data apa yang harus disimpan dan berapa lama.
• Feedback Loop — output SI menghasilkan keputusan yang menghasilkan data baru — siklus yang terus berputar.

---

SEK 11.3 — DEFINISI KUNCI

📌 Perancangan Konseptual (Conceptual Design) Tahap perancangan SI yang berfokus pada "apa" yang harus dilakukan sistem (fungsionalitas, alur, output) — bukan "bagaimana" secara teknis (bahasa pemrograman, infrastruktur). Domain manajer, bukan programmer. Relevansi manajerial: Manajer yang memahami perancangan konseptual bisa memastikan SI yang dibangun sesuai kebutuhan bisnis — bukan sesuai preferensi teknis developer.

📌 Design Brief Dokumen satu halaman yang merangkum spesifikasi konseptual SI: siapa penggunanya, input apa, proses apa, output apa, aturan bisnis apa, dan constraint apa. Menjadi "kontrak" antara manajer dan tim teknis. Relevansi manajerial: Design brief memaksa manajer mengartikulasikan kebutuhannya secara terstruktur — mencegah "saya bilang kan saya mau begini, bukan begitu" di akhir proyek.

📌 Aturan Bisnis (Business Rules) Kebijakan, prosedur, atau constraint yang harus diimplementasikan dalam logika SI — misalnya: "Persetujuan kredit di atas Rp100 juta harus melalui Direksi" atau "Notifikasi otomatis jika stok di bawah safety stock." Relevansi manajerial: Aturan bisnis adalah "kecerdasan" SI yang membedakannya dari sekadar database. Manajer adalah sumber utama aturan bisnis — bukan developer.

---

SEK 11.4 — KONSEP INTI (6 sub-seksi)

11.4.1 Perancangan Konseptual vs Teknis: Batas yang Harus Dipahami Manajer

• Argumen: Manajer tidak perlu merancang database, menulis kode, atau memilih infrastruktur. Tetapi manajer HARUS bisa mendefinisikan: apa input SI, proses apa yang dilakukan, output apa yang diharapkan, siapa penggunanya, aturan bisnis apa yang berlaku.
• Data pendukung: 47% proyek SI gagal karena "miscommunication antara bisnis dan IT" (Standish Group, 2023). Design brief yang jelas mengurangi risiko ini hingga 40%.
• Tabel batas tanggung jawab:

Aspek	Domain Manajer	Domain Tim Teknis
Input	Sumber data apa, format apa	Bagaimana data di-extract, API mana
Proses	Aturan bisnis apa yang berlaku	Bahasa pemrograman, algoritma
Output	Laporan/dashboard apa, untuk siapa	UI/UX design, rendering technology
Storage	Data apa disimpan, berapa lama	Database engine, schema, indexing
Security	Siapa boleh akses apa	Authentication, encryption method

11.4.2 Model IPO dan Komponennya

• Argumen: IPO (Input-Process-Output) adalah kerangka paling universal dan paling intuitif untuk manajer merancang konseptual SI. Setiap SI pada dasarnya menerima input, memproses, dan menghasilkan output.
• Penekanan: Mulai dari OUTPUT (apa yang dibutuhkan pengguna), lalu mundur ke PROCESS (logika apa yang menghasilkan output), lalu mundur lagi ke INPUT (data apa yang dibutuhkan). Pendekatan "output-first" mencegah overbuilding.
• Contoh: Output: dashboard real-time penjualan per region. Process: aggregation per hari per region + YoY comparison. Input: data transaksi POS per toko.

11.4.3 Spesifikasi Output: Apa yang Dibutuhkan Pengguna Akhir

• Argumen: Output adalah hal pertama yang harus didefinisikan — karena output-lah yang langsung menjawab kebutuhan informasi (Bab 9). Tanpa kejelasan output, developer cenderung membangun fitur yang "keren" tetapi tidak dipakai.
• Kategori output: (1) Laporan periodik (harian, mingguan, bulanan), (2) Dashboard real-time, (3) Alert/notifikasi berbasis aturan, (4) Rekomendasi keputusan, (5) Dokumen cetak (surat, invoice, SK).
• Data pendukung: 65% fitur SI yang dibangun tidak pernah digunakan (Standish Group, 2023) — mayoritas karena output tidak sesuai kebutuhan.

11.4.4 Spesifikasi Input: Sumber, Format, Frekuensi Data

• Argumen: Setelah output jelas, manajer harus mendefinisikan: data apa yang diperlukan, dari mana, dalam format apa, seberapa sering. Input yang tidak didefinisikan dengan benar menghasilkan "GIGO" — garbage in, garbage out.
• Pertanyaan kunci: (a) Data sudah ada atau harus dikumpulkan? (b) Sumber internal atau eksternal? (c) Manual entry atau otomatis? (d) Real-time atau batch?
• Contoh: Untuk dashboard penjualan real-time, input harus real-time dari POS — bukan export Excel harian. Spesifikasi input menentukan arsitektur teknis.

11.4.5 Aturan Bisnis sebagai Logika Proses

• Argumen: Aturan bisnis adalah instruksi yang memberi "kecerdasan" pada SI. Tanpa aturan bisnis, SI hanyalah database dan form. Aturan bisnis yang lengkap dan tepat menghasilkan SI yang benar-benar membantu keputusan.
• Jenis aturan: (a) Validasi: "NIP tidak boleh duplikat," (b) Derivasi: "Total = Qty × Harga − Diskon," (c) Constraint: "Approval kredit > 100 juta perlu Direksi," (d) Trigger: "Alert jika stok < safety stock."
• Contoh: SI Kepegawaian tanpa aturan bisnis: hanya menyimpan data. Dengan aturan bisnis: otomatis menghitung masa kerja, mengingatkan pensiun 6 bulan sebelumnya, memblokir mutasi jika belum 2 tahun di posisi.

11.4.6 Komunikasi Desain Konseptual kepada Tim Teknis

• Argumen: Desain konseptual harus dikomunikasikan dalam format yang dipahami oleh manajer DAN tim teknis. Design brief satu halaman adalah format paling efektif: ringkas, terstruktur, dan tidak membutuhkan keahlian teknis untuk membaca.
• Struktur design brief: Latar belakang → Tujuan → Pengguna → Input → Proses/Aturan bisnis → Output → Constraint → Timeline/Budget.
• Data pendukung: Proyek dengan design brief formal memiliki rework rate 35% lebih rendah dari proyek tanpa design brief (Satzinger et al., 2022).

---

SEK 11.5 — KOMPARASI (Tabel 11.1)

Judul: "Perspektif Manajer vs Perspektif Teknis dalam Perancangan SI: 6 Dimensi"

Dimensi	Perspektif Manajer	Perspektif Teknis
Pertanyaan utama	"Apa yang saya butuhkan?"	"Bagaimana cara membuatnya?"
Focus	Fungsionalitas & keputusan	Arsitektur & performa
Output yang dipikirkan	"Saya butuh laporan penjualan harian"	"REST API → aggregation service → React dashboard"
Bahasa	Terminologi bisnis	Terminologi teknologi
Timeline	"Saya butuh 3 bulan sebelum peak season"	"Sprint planning, 6 sprint × 2 minggu"
Risiko yang dilihat	"Kalau telat, revenue hilang"	"Kalau data inconsistent, dashboard error"
Kriteria sukses	"Dashboard ini membantu saya memutuskan alokasi stok"	"Response time < 2 detik, 99.9% uptime"

💡 Insight: Perracangan SI gagal ketika kedua perspektif ini tidak saling bicara. Design brief adalah translator — 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.

---

SEK 11.6 — REALITAS LAPANGAN (3 fenomena)

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

Banyak desa di Indonesia memperoleh SID dari program pemerintah pusat. Masalahnya: SID dirancang oleh developer Jakarta tanpa memahami kebutuhan operasional desa. Sistem memiliki modul "data mining" dan "GIS" tetapi tidak bisa mencetak surat keterangan domisili — hal yang diminta warga 10× per hari. Spesifikasi konseptual dibuat oleh developer, bukan oleh perangkat desa.

💡 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, bukan fitur yang paling impresif untuk presentasi.

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

Salesforce merancang CRM yang digunakan oleh 150.000+ perusahaan di ratusan industri berbeda. Rahasianya bukan kode yang kompleks — tetapi arsitektur konseptual yang fleksibel: model IPO yang bisa di-customize tanpa coding (low-code/no-code). Setiap perusahaan bisa mendefinisikan input, aturan bisnis, dan output sendiri — sesuai design brief mereka.

💡 Insight: Arsitektur konseptual yang baik bukan yang paling canggih — tetapi yang paling adaptable. Salesforce membuktikan bahwa satu kerangka konseptual (IPO + business rules) bisa melayani kebutuhan yang sangat beragam jika dirancang dengan benar.

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

Penelitian terhadap 500 proyek SI di Asia Tenggara (Gartner, 2023) menunjukkan bahwa proyek dengan spesifikasi yang didominasi tim teknis memiliki satisfaction rate 38%, vs 72% untuk proyek di mana bisnis aktif mendefinisikan spesifikasi konseptual. Manajer yang terlibat di fase desain konseptual menghasilkan SI dengan user adoption 2× lebih tinggi.

💡 Insight: Involvement manajer bukan opsi — ia prasyarat. Perancangan konseptual yang didominasi developer menghasilkan SI yang technically excellent tetapi functionally irrelevant.

---

SEK 11.7 — SALAH KAPRAH (⚠️)

⚠️ Jebakan 1: "Desain sistem itu urusan programmer, manajer tidak perlu terlibat"

Mengapa salah: Programmer memahami teknologi, bukan konteks keputusan bisnis. Manajer yang tidak terlibat di desain konseptual akan menerima SI yang technically correct tetapi business-irrelevant — dan baru mengeluh setelah sistem sudah dibangun (mahal dan terlambat). Koreksi: Manajer harus minimal menyusun design brief satu halaman, mendefinisikan: output, input, aturan bisnis, dan pengguna.

⚠️ Jebakan 2: "Kalau sistemnya canggih secara teknis, pasti memenuhi kebutuhan bisnis"

Mengapa salah: Kompleksitas teknis tidak berkorelasi dengan nilai bisnis. Sistem dengan machine learning dan real-time analytics tidak berguna jika output-nya bukan informasi yang dibutuhkan manajer untuk keputusan sehari-hari. Koreksi: Mulai dari kebutuhan bisnis (Bab 9), bukan dari teknologi. Pertanyaan pertama: "Informasi apa yang dibutuhkan?" bukan "Teknologi apa yang bisa kita pakai?"

⚠️ Jebakan 3: "Cukup beri tahu vendor apa masalahnya, mereka tahu cara merancang sistemnya"

Mengapa salah: Vendor memiliki incentive untuk menjual solusi mereka — bukan solusi terbaik untuk organisasi Anda. Tanpa design brief yang jelas dari manajer, vendor akan merancang SI berdasarkan template mereka, bukan kebutuhan unik organisasi Anda. Koreksi: Sediakan design brief SEBELUM bicara dengan vendor. Vendor harus merespons spesifikasi Anda — bukan Anda yang merespons demo mereka.

---

SEK 11.8 — STUDI KASUS (📊)

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

❌ Kondisi Awal: Desa di Bantul memiliki SID yang diberikan pemerintah pusat. Modul: kependudukan, aset desa, GIS, data mining. Tetapi perangkat desa hanya menggunakan 20% fitur — yang mereka butuhkan (cetak surat, laporan APBDes) justru sulit dilakukan.

✅ Setelah Design Brief oleh Perangkat Desa: Perangkat desa diminta menyusun design brief sederhana berdasarkan pertanyaan: "Output apa yang paling sering Anda butuhkan?"

Output (Prioritas)	Frekuensi	Input	Aturan Bisnis
Surat keterangan domisili	10×/hari	NIK, nama, alamat	Validasi NIK di database
Surat pengantar	8×/hari	Data warga + tujuan surat	Template otomatis
Laporan APBDes	1×/bulan	Data transaksi keuangan	Format sesuai Permendagri
Data statistik desa	1×/kuartal	Aggregasi data penduduk	Klasifikasi usia, pekerjaan

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

📊 Studi Kasus Lanjutan — Salesforce: Arsitektur Konseptual yang Scalable

❌ Kondisi Awal: Sebelum Salesforce, setiap perusahaan membangun CRM custom — mahal, lama, dan sulit di-maintain. Setiap perubahan kebutuhan bisnis memerlukan coding ulang.

✅ Arsitektur Konseptual Salesforce: Salesforce merancang model IPO yang configurable: Objects (data entities) → Fields (input) → Validation Rules (aturan bisnis) → Reports/Dashboards (output) — semua bisa dikustomisasi tanpa coding oleh business analyst.

Dimensi	CRM Custom	Salesforce
Design time	6-12 bulan	4-8 minggu
Customization	Butuh developer	Business analyst (low-code)
Perubahan aturan bisnis	Request IT → sprint → deploy	Admin konfigurasi → langsung live
Scalability	Rebuild jika skala berubah	Auto-scale (cloud)
Total cost (5 tahun)	Rp 2-5 miliar	Rp 500 juta – 1.5 miliar

💡 Pelajaran: Salesforce membuktikan bahwa arsitektur konseptual yang baik memprioritaskan adaptability — manajer bisa mengubah aturan bisnis tanpa menunggu developer. Ini adalah ideal yang harus diperjuangkan di setiap perancangan SI: manajer mengendalikan logika bisnis, developer mengendalikan infrastruktur.

---

SEK 11.9 — TEMPLATE PRAKTIS (🔧)

Nama: 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 kita tahu SI ini berhasil?)
   ________________________________________
   ________________________________________

---

SEK 11.10 — PETA KONSEP (Gambar 11.2)

mindmap
  root((Perancangan Konseptual SI))
    Model IPO
      Input: sumber & format data
      Process: aturan bisnis
      Output: first priority
      Storage: apa & berapa lama
    Design Brief
      Dokumen 1 halaman
      Translator bisnis-teknis
      Output-first approach
    Batas Tanggung Jawab
      Manajer: WHAT
      Tim Teknis: HOW
      Design Brief: penghubung
    Anti-pattern
      Spec by developer only
      Feature-driven bukan need-driven
      Tanpa design brief
    Kaitan
      Input dari Bab 9-10
      Output ke Bab 12

---

SEK 11.11 — RANGKUMAN

Takeaway utama:

1. Perancangan konseptual adalah domain manajer — bukan programmer. Manajer mendefinisikan "apa" yang dibutuhkan; tim teknis mendefinisikan "bagaimana" membangunnya.
2. Model IPO (Input-Process-Output) adalah kerangka paling universal untuk perancangan konseptual. Mulai dari OUTPUT — apa yang dibutuhkan pengguna — lalu mundur ke proses dan input.
3. Design brief satu halaman adalah format paling efektif untuk menghubungkan perspektif manajer dan tim teknis — mengurangi miscommunication hingga 40%.
4. Aturan bisnis adalah "kecerdasan" SI. 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.
6. SI yang dirancang tanpa design brief dari pengguna akan selalu menjadi "sistem developer" bukan "sistem organisasi."

Closing Bridge (ke Bab 12):

Desain konseptual sudah tersusun — input, proses, output, aturan bisnis sudah didefinisikan. Pertanyaan selanjutnya: apakah membangun sendiri, membeli paket jadi, atau menyewa dari cloud? Bab 12 membahas evaluasi alternatif solusi SI.

🔥 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."

---

SEK 11.12 — LATIHAN & REFLEKSI

Pertanyaan Refleksi:

1. Pernahkah Anda mendapatkan SI yang "tidak sesuai" dengan kebutuhan? Apakah ada design brief yang disusun sebelumnya? Menurut Anda, apa yang bisa diperbaiki?
2. Mengapa pendekatan "output-first" lebih efektif daripada "input-first" dalam perancangan konseptual?
3. Diskusikan: siapa yang seharusnya memiliki "ownership" atas aturan bisnis dalam SI — manajer atau developer?

Tugas Artefak:

Gunakan Template A.11 (Design Brief SI) untuk menyusun spesifikasi konseptual satu halaman bagi SI yang menyelesaikan masalah dari Template A.8 (Bab 8) dan memenuhi kebutuhan informasi dari Template A.9 (Bab 9). Pastikan setiap output terhubung ke kebutuhan informasi yang sudah didefinisikan.

---

REFERENSI BAB 11

1. Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2022). Systems Analysis and Design in a Changing World (8th ed.). Cengage Learning.
2. Laudon, K. C., & Laudon, J. P. (2022). Management Information Systems (17th ed.). Pearson.
3. Rainer, R. K., Prince, B., & Watson, H. J. (2023). Management Information Systems (5th ed.). Wiley.
4. O'Brien, J. A., & Marakas, G. M. (2021). Management Information Systems (11th ed.). McGraw-Hill Education.
5. Standish Group. (2023). Chaos report 2023: Beyond infinity. The Standish Group International.
6. Gartner Research. (2023). IT project delivery benchmarks in Southeast Asia. Gartner, Inc.
7. Kendall, K. E., & Kendall, J. E. (2019). Systems Analysis and Design (10th ed.). Pearson.
8. Valacich, J. S., George, J. F., & Hoffer, J. A. (2021). Essentials of Systems Analysis and Design (7th ed.). Pearson.

---

QUALITY GATES CHECK

[✓] Gate 1 — THINK   : Mengubah pandangan dari "desain SI urusan IT" ke "manajer harus define what, IT define how"
[✓] Gate 2 — APPLY   : Template A.11 langsung applicable untuk menyusun design brief SI satu halaman
[✓] Gate 3 — REFLECT : Pembaca merefleksikan apakah selama ini ia menyerahkan desain sepenuhnya ke developer