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

# 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*)

```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
```

**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 9 — 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

| Aspek | Domain Manajer (APA) | Domain Tim Teknis (BAGAIMANA) |
|-------|----------------------|-------------------------------|
| *Input* | Sumber data, format, frekuensi | *Extract* method, API, *parser* |
| Proses | Aturan bisnis 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* |

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

| Dimensi | Perspektif Manajer | Perspektif Teknis |
|---------|-------------------|------------------|
| Pertanyaan utama | "Apa yang saya butuhkan?" | "Bagaimana cara membuatnya?" |
| Fokus | Fungsionalitas dan keputusan | Arsitektur dan 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 | "SI ini membantu saya alokasi stok" | "*Response time* < 2 detik, 99,9% *uptime*" |

💡 **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 9), 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

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

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

| Dimensi | CRM *Custom* | Salesforce |
|---------|-------------|-----------|
| *Design time* | 6–12 bulan | 4–8 minggu |
| Kustomisasi | 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*) |
| TCO 5 tahun | Rp 2–5 miliar | Rp 500 juta–1,5 miliar |

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

```mermaid
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 9 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.8 (Bab 8)
- Memenuhi kebutuhan informasi dari Template A.9 (Bab 9)
- 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.