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

# BAB 12 — Alternatif Solusi: *Custom*, Komersial, dan *Cloud*


```
Bagian          : V — Perancangan Solusi SI
Reader Outcome  : Pembaca mampu mengevaluasi dan merekomendasikan pilihan solusi
                  SI yang sesuai berdasarkan kebutuhan, anggaran, dan kapasitas
                  organisasi.
Level           : Lanjutan
Estimasi Halaman: 15–18
```

---

## 12.1 Pembuka

Bab 11 membekali Anda dengan kemampuan menyusun *design brief* — spesifikasi konseptual SI satu halaman yang mendefinisikan *output*, *input*, aturan bisnis, dan pengguna. Template A.11 menghasilkan dokumen yang siap dikomunikasikan kepada tim teknis. Tetapi *design brief* belum menjawab satu pertanyaan strategis: siapa yang membangun SI-nya?

Sebuah kabupaten di Indonesia harus memilih: menggunakan SIPD (Sistem Informasi Pemerintah Daerah) yang menjadi platform tunggal untuk seluruh Indonesia, atau membangun sistem anggaran kustom yang sesuai "keunikan daerah." Pilihan pertama gratis tetapi rigid — format nasional yang tidak bisa diubah. Pilihan kedua fleksibel tetapi mahal — dan pengembang sebelumnya sudah *resign* sehingga sistem lama tidak bisa di-*update*. Mana yang benar? Pertanyaan itu sendiri kurang tepat. Yang lebih tepat: "kebutuhan mana yang paling kritis, berapa total biaya kepemilikan di setiap opsi, dan solusi mana yang paling *fit* dengan kapasitas organisasi?"

Bagaimana manajer mengevaluasi dan memilih antara membangun sendiri, membeli paket komersial, atau menyewa solusi *cloud* — dan apa *trade-off* strategis dari setiap pilihan?

---

## 12.2 Model Utama

### Gambar 12.1 — Kerangka Keputusan Solusi SI

```mermaid
graph TD
    BK["Kebutuhan Bisnis<br>dari Design Brief"] --> A["Analisis 3 Dimensi"]
    A --> DIM1["Kompleksitas<br>Kebutuhan"]
    A --> DIM2["Anggaran &<br>Kapasitas IT"]
    A --> DIM3["Urgensi &<br>Timeline"]
    DIM1 --> EVAL{"Evaluasi<br>Alternatif"}
    DIM2 --> EVAL
    DIM3 --> EVAL
    EVAL --> CUSTOM["Custom<br>Development"]
    EVAL --> COTS["COTS / Paket<br>Komersial"]
    EVAL --> SAAS["Cloud /<br>SaaS"]
    CUSTOM --> TCO["Evaluasi TCO<br>+ Risiko + Skalabilitas"]
    COTS --> TCO
    SAAS --> TCO
    TCO --> REC["Rekomendasi<br>Terargumentasi"]
    style BK fill:#1a4a5c,stroke:#333,color:#fff
    style A fill:#1a4a5c,stroke:#333,color:#fff
    style DIM1 fill:#1a4a5c,stroke:#333,color:#fff
    style DIM2 fill:#1a4a5c,stroke:#333,color:#fff
    style DIM3 fill:#1a4a5c,stroke:#333,color:#fff
    style EVAL fill:#f5f5f5,stroke:#1a4a5c,color:#333
    style CUSTOM fill:#1a4a5c,stroke:#333,color:#fff
    style COTS fill:#1a4a5c,stroke:#333,color:#fff
    style SAAS fill:#1a4a5c,stroke:#333,color:#fff
    style TCO fill:#1a4a5c,stroke:#333,color:#fff
    style REC fill:#1a4a5c,stroke:#333,color:#fff
```

**Kebutuhan Bisnis** — titik awal yang bersumber dari *design brief* (Bab 11). Keputusan solusi dimulai dari kebutuhan organisasi, bukan dari demo vendor atau tren teknologi.

**Tiga Dimensi Analisis** — setiap organisasi memiliki profil berbeda di tiga dimensi: (1) Kompleksitas Kebutuhan — apakah kebutuhan sangat unik atau cukup standar? (2) Anggaran dan Kapasitas IT — berapa *budget* yang tersedia dan seberapa kuat tim IT internal? (3) Urgensi dan *Timeline* — seberapa cepat SI harus beroperasi?

**Tiga Alternatif Solusi:**
- ***Custom Development*** — dibangun dari nol oleh tim internal atau vendor. Kontrol penuh, biaya tinggi, waktu *development* lama.
- **COTS (*Commercial Off-The-Shelf*)** — paket jadi seperti SAP, Oracle, atau Odoo. *Best practice* bawaan, butuh kustomisasi, biaya lisensi.
- ***Cloud* / SaaS** — layanan *subscription* seperti Salesforce, Google Workspace, atau Zoho. Cepat di-*deploy*, biaya berulang, ketergantungan pada vendor.

**TCO (*Total Cost of Ownership*)** — menghitung total biaya kepemilikan selama siklus hidup SI (biasanya 5 tahun), bukan hanya biaya akuisisi awal.

**Rekomendasi Terargumentasi** — keputusan akhir yang didukung data dan analisis terstruktur, bukan preferensi subjektif atau tekanan vendor.

---

## 12.3 Definisi Kunci

📌 ***Total Cost of Ownership* (TCO)**
Perhitungan total biaya SI selama siklus hidupnya — mencakup biaya akuisisi (lisensi, *hardware*, *development*), biaya operasional (*maintenance*, *hosting*, *support*), dan biaya tersembunyi (*training*, *downtime*, migrasi data, *opportunity cost*). Manajer yang hanya membandingkan harga beli atau biaya *subscription* bulanan akan membuat keputusan yang bias. Gartner (2024) melaporkan bahwa organisasi yang tidak menghitung TCO mengalami *budget overrun* rata-rata 45%.

📌 ***Vendor Lock-in***
Situasi di mana organisasi menjadi sangat bergantung pada satu vendor sehingga biaya beralih (*switching cost*) menjadi prohibitif — membuat organisasi "terjebak" meskipun solusi vendor tidak lagi optimal atau harganya naik signifikan. *Lock-in* mengurangi *bargaining power* dan fleksibilitas strategis. Forrester (2023) mendokumentasikan bahwa 34% organisasi yang mencoba migrasi antar vendor mengalami durasi 18 bulan dan biaya 150% di atas estimasi.

📌 **SaaS / PaaS / IaaS (*X as a Service*)**
Tiga model layanan *cloud*: SaaS (*Software as a Service* — aplikasi siap pakai, misalnya Google Workspace), PaaS (*Platform as a Service* — platform *development*, misalnya Heroku), IaaS (*Infrastructure as a Service* — infrastruktur virtual, misalnya AWS EC2). Manajer perlu memahami perbedaannya karena implikasi bisnis berbeda: SaaS untuk *quick deployment* tanpa tim IT, PaaS untuk tim *development* yang butuh *agility*, IaaS untuk organisasi dengan kebutuhan infrastruktur spesifik.

---

## 12.4 Konsep Inti

### 12.4.1 Tiga Jalur Solusi: Bangun, Beli, atau Sewa

Setiap jalur memiliki *trade-off* — dan tidak ada "solusi terbaik" universal. Yang ada adalah "solusi paling tepat" untuk konteks organisasi tertentu. Gartner (2024) melaporkan bahwa 62% organisasi di Asia Tenggara menggunakan pendekatan *hybrid*: campuran *custom*, COTS, dan SaaS untuk fungsi bisnis yang berbeda.

***Custom Development*** — organisasi membangun SI dari nol, baik oleh tim internal maupun vendor kontrak. Keunggulan: kontrol penuh atas fungsionalitas, desain yang 100% sesuai kebutuhan unik. Risiko: biaya dan durasi *development* sering melampaui estimasi, ketergantungan pada *developer* tertentu (*single point of failure*), dan beban *maintenance* jangka panjang yang tidak kunjung selesai.

**COTS (*Commercial Off-The-Shelf*)** — organisasi membeli paket perangkat lunak yang sudah jadi (SAP, Oracle, Odoo, MYOB). Keunggulan: *best practice* industri sudah tertanam, komunitas pengguna besar, vendor menyediakan *support* dan *update*. Risiko: kustomisasi yang berlebihan bisa membuat produk tidak lagi kompatibel dengan versi baru, biaya lisensi dan *maintenance* berulang, dan organisasi harus menyesuaikan proses bisnisnya dengan logika *software*.

***Cloud* / SaaS** — organisasi menyewa akses ke *software* yang di-*hosting* oleh provider melalui *subscription* bulanan atau tahunan. Keunggulan: *deployment* cepat (hitungan hari, bukan bulan), tidak perlu infrastruktur sendiri, *auto-update*. Risiko: data berada di server provider (*data sovereignty*), akumulasi biaya *subscription* jangka panjang, dan *vendor lock-in* jika data sulit di-*export*.

### 12.4.2 TCO: Biaya yang Sering Diabaikan

Harga beli atau biaya *subscription* awal hanyalah 30–40% dari total biaya SI selama 5 tahun. Sisanya: *training* pengguna, kustomisasi atau konfigurasi, migrasi data dari sistem lama, *downtime* selama transisi, *opportunity cost* (waktu staf yang dialihkan untuk implementasi), dan biaya *exit*/migrasi jika ingin pindah di kemudian hari.

### Tabel 12.2 — Simulasi TCO 5 Tahun: *Custom* vs COTS vs SaaS (dalam juta Rupiah)

| Komponen | *Custom* | COTS (SAP Business One) | SaaS |
|----------|---------|------------------------|------|
| Akuisisi awal / lisensi | 2.000 | 1.500 | 0 |
| *Development* / kustomisasi | 3.000 | 1.000 | 0 |
| *Subscription* / tahun × 5 | 0 | 300 × 5 = 1.500 | 500 × 5 = 2.500 |
| *Training* | 500 | 700 | 200 |
| *Maintenance* dan *support* | — (termasuk di *development*) | — (termasuk di lisensi) | — (termasuk di *subscription*) |
| **Total TCO 5 tahun** | **5.500** | **4.700** | **2.700** |
| Risiko tersembunyi | *Bug fix*, *developer turnover* | *Upgrade* kompatibilitas | *Lock-in*, *tier upgrade* |

Tabel ini menunjukkan bahwa SaaS memang paling murah dalam TCO — tetapi angka itu belum memperhitungkan risiko tersembunyi. Jika organisasi perlu *tier upgrade* di tahun ke-2 (dari Rp 500 juta/tahun menjadi Rp 800 juta/tahun), TCO SaaS melonjak ke Rp 4.100 juta — mendekati *custom*. Analisis TCO harus melibatkan skenario pesimistik, bukan hanya proyeksi ideal.

### 12.4.3 Kriteria Evaluasi Solusi: Fungsional, Non-Fungsional, Strategis

Evaluasi solusi yang terstruktur mencakup tiga lapisan:

**Fungsional** — apakah solusi memenuhi kebutuhan yang tercantum dalam *design brief* (Bab 11)? Berapa persen fitur yang tersedia *out-of-the-box* vs yang perlu dikustomisasi? Apakah *output* yang dihasilkan sesuai spesifikasi?

**Non-fungsional** — aspek teknis yang tidak terlihat oleh pengguna tetapi kritis: performa (*response time*), keamanan (enkripsi, *access control*), skalabilitas (bisa menangani peningkatan *user* dan data), *availability* (*uptime guarantee*), dan *interoperability* (kompatibel dengan sistem lain).

**Strategis** — apakah solusi selaras dengan arah organisasi 3–5 tahun ke depan? Bagaimana *exit strategy*-nya? Apakah vendor stabil secara finansial? Apakah solusi memungkinkan integrasi dengan ekosistem SI yang lebih luas?

Pendekatan *weighted scoring* membantu menghindari keputusan berbasis demo vendor yang impresif. Berikan bobot pada setiap kriteria sesuai prioritas organisasi (misalnya: kesesuaian fungsional 30%, TCO 25%, waktu *deploy* 15%, skalabilitas 10%, keamanan 10%, *exit strategy* 10%), lalu beri skor setiap alternatif. Keputusan berbasis skor total jauh lebih defensible daripada "perasaan" setelah presentasi vendor.

### 12.4.4 Risiko *Vendor Lock-in* dan Strategi Mitigasi

*Lock-in* terjadi di ketiga jalur — bukan hanya SaaS:

- ***Custom*:** *lock-in* ke *developer* atau vendor yang membangun sistem. Jika *developer* *resign* atau vendor bubar, organisasi memiliki *source code* tetapi tidak ada yang bisa memeliharanya.
- **COTS:** *lock-in* ke *ecosystem* vendor. SAP → SAP HANA → SAP Analytics Cloud → SAP SuccessFactors. Semakin banyak modul dari vendor yang sama, semakin tinggi *switching cost*.
- **SaaS:** *lock-in* melalui data. Jika data sulit di-*export* (format proprietary, API terbatas), organisasi terjebak meskipun layanan menurun atau harga naik.

Strategi mitigasi yang harus dievaluasi sebelum memilih solusi:

1. **Data portability** — bisakah data di-*export* kapan saja dalam format standar (CSV, JSON, XML)?
2. **Open standards** — apakah solusi menggunakan standar terbuka atau format proprietary?
3. **Kontrak *exit clause*** — apakah kontrak mencakup prosedur transisi, durasi, dan bantuan migrasi?
4. **Multi-vendor strategy** — hindari menempatkan semua fungsi bisnis di satu vendor.

Forrester (2023) mendokumentasikan bahwa organisasi yang merencanakan *exit strategy* sejak awal mengeluarkan biaya migrasi 60% lebih rendah dibandingkan organisasi yang baru memikirkannya saat ingin pindah.

### 12.4.5 *Cloud Architecture*: SaaS, PaaS, IaaS — Relevansi Manajerial

Manajer tidak perlu memahami teknis *containerization* atau *virtual machine* — tetapi harus memahami implikasi bisnis dari setiap model *cloud*:

**SaaS (*Software as a Service*)** — *software* siap pakai yang diakses via *browser*. Contoh: Google Workspace, Salesforce, Zoom. Manajer langsung menggunakan tanpa perlu tim IT. Cocok untuk fungsi standar (email, kolaborasi, CRM). Keterbatasan: kustomisasi minimal, data di server provider.

**PaaS (*Platform as a Service*)** — platform *development* yang menyediakan *environment* untuk membangun aplikasi. Contoh: Google App Engine, Heroku, Azure App Service. Butuh *developer*, tetapi *developer* tidak perlu mengurus server. Cocok untuk organisasi yang membutuhkan *custom application* tanpa beban infrastruktur.

**IaaS (*Infrastructure as a Service*)** — infrastruktur virtual (server, storage, network) yang disewa. Contoh: AWS EC2, Azure VM, Google Compute Engine. Kontrol penuh atas *environment*, tetapi butuh *sysadmin*. Cocok untuk organisasi besar dengan kebutuhan infrastruktur spesifik.

McKinsey (2022) melaporkan distribusi *spending cloud* di organisasi besar: 70% SaaS, 20% IaaS, 10% PaaS. Angka ini mengonfirmasi bahwa mayoritas penggunaan *cloud* bersifat pragmatis — menggunakan *software* jadi — bukan membangun *custom application* di *cloud*.

### 12.4.6 Tren: *Composable Architecture* dan Ekosistem API

Era "satu sistem untuk semua kebutuhan" sedang berakhir. Tren menuju *composable architecture*: merakit SI dari komponen-komponen terbaik (*best-of-breed*) yang terhubung melalui API (*Application Programming Interface*).

Contoh: sebuah perusahaan *e-commerce* menggunakan Salesforce untuk CRM, SAP Business One untuk ERP, Tableau untuk BI, Slack untuk komunikasi, dan *custom microservice* untuk logistik — semuanya terintegrasi via API. Tidak ada satu vendor yang mendominasi, dan setiap komponen bisa diganti tanpa merombak seluruh sistem.

Implikasi untuk manajer: keputusan "solusi mana" bukan lagi pilihan tunggal A, B, atau C. Manajer perlu berpikir dalam ekosistem — komponen mana untuk fungsi mana, dan bagaimana komponen tersebut berkomunikasi satu sama lain. Ini membutuhkan *integration strategy* dan *API governance* — topik yang menjadi semakin penting di era digital (lihat juga Bab 16).

---

## 12.5 Komparasi

### Tabel 12.1 — *Custom* vs COTS vs SaaS: 8 Dimensi Perbandingan

| Dimensi | *Custom Development* | COTS (Paket Komersial) | SaaS (*Cloud*) |
|---------|---------------------|----------------------|-------------|
| Kontrol | Penuh | Terbatas oleh fitur vendor | Minimal |
| Waktu *deploy* | 6–18 bulan | 3–9 bulan | 1–4 minggu |
| Biaya awal | Tinggi | Menengah–tinggi | Rendah |
| Biaya *recurring* | Rendah (*maintenance*) | Menengah (lisensi + *support*) | Tinggi (*subscription*) |
| Kustomisasi | Tidak terbatas | Terbatas (konfigurasi + add-on) | Minimal |
| Skalabilitas | Manual (perlu *upgrade*) | Perlu *upgrade* modul | *Auto-scale* |
| Risiko utama | *Developer turnover*, *bug* | *Vendor lock-in*, *forced upgrade* | Data *sovereignty*, *outage* |
| Cocok untuk | Kebutuhan sangat unik | Proses standar industri | *Quick deployment*, UMKM |

💡 **Insight:** Tidak ada pemenang universal di antara ketiga jalur. *Custom* cocok untuk organisasi dengan kebutuhan sangat unik dan tim IT yang kuat. COTS cocok untuk proses yang sudah terstandarisasi (akuntansi, HR, *supply chain*). SaaS cocok untuk UMKM dan organisasi yang menginginkan *agility* tanpa beban infrastruktur. Sebagian besar organisasi modern menggunakan *hybrid* — dan keputusan "mana yang di-*custom*, mana yang COTS, mana yang SaaS" sebaiknya dibuat per-fungsi bisnis, bukan per-organisasi.

---

## 12.6 Realitas Lapangan

### Fenomena 1: SIPD — Ketika Platform Nasional Bertemu Keunikan Daerah

SIPD dirancang sebagai platform nasional tunggal untuk perencanaan dan penganggaran 548 kabupaten/kota di Indonesia. Dari perspektif efisiensi skala, SIPD adalah keputusan yang rasional: satu platform, satu *database* nasional, satu format pelaporan, biaya per daerah mendekati nol.

Tetapi implementasi menunjukkan *trade-off* yang tidak trivia. Setiap daerah memiliki kekhususan: otonomi khusus (Papua, Aceh), desa adat (Bali), format kelembagaan berbeda, dan program lokal yang tidak terakomodasi dalam *template* nasional. Beberapa daerah akhirnya memelihara "sistem bayangan" — *spreadsheet* atau aplikasi kecil di samping SIPD — untuk kebutuhan yang tidak terlayani.

💡 **Insight:** Platform *one-size-fits-all* efisien dalam skala tetapi selalu menyisakan *gap* di level lokal. Manajer daerah perlu memilah: kebutuhan mana yang bisa "mengalah" ke standar nasional (dan mendapatkan efisiensi skala) dan kebutuhan mana yang benar-benar memerlukan solusi pelengkap. Jawaban "SIPD atau *custom*" sering kali adalah "SIPD DAN solusi pelengkap *custom*."

### Fenomena 2: UMKM Indonesia dan Dilema *Cloud*

Survei LIPI (2023) terhadap 1.200 UMKM Indonesia menunjukkan bahwa 78% yang mengadopsi SaaS (POS, akuntansi, *e-commerce*) melaporkan peningkatan efisiensi operasional. *Cloud* memungkinkan UMKM mengakses *software* kelas enterprise dengan biaya *subscription* bulanan yang terjangkau — sesuatu yang tidak mungkin 10 tahun lalu.

Tetapi 42% dari UMKM yang sama melaporkan masalah: data tidak bisa di-*export* ketika ingin pindah *provider* (format proprietary), fitur yang benar-benar dibutuhkan hanya ada di *tier* berbayar yang 3× lebih mahal, dan ketergantungan pada internet stabil yang tidak selalu tersedia di luar Jawa. Satu UMKM *fashion* di Bandung menghitung: *subscription* SaaS POS yang dimulai Rp 200.000/bulan naik menjadi Rp 800.000/bulan dalam 2 tahun karena *tier upgrade* dan *add-on* — akumulasi 5 tahun mencapai Rp 38 juta, lebih mahal dari membeli *software* POS *offline* seharga Rp 15 juta.

💡 **Insight:** *Cloud* adalah *game changer* untuk UMKM — tetapi bukan tanpa *trade-off*. Sebelum memilih SaaS, tiga pertanyaan wajib: (1) Bisakah data di-*export* kapan saja dalam format standar? (2) Berapa total biaya termasuk *tier upgrade* dalam 3–5 tahun? (3) Apa yang terjadi jika internet mati — apakah ada mode *offline*?

### Fenomena 3: Slack vs Microsoft Teams — Keputusan Platform dengan *Ripple Effect*

Ketika sebuah perusahaan teknologi di Jakarta harus memilih platform kolaborasi, keputusan terlihat sederhana: "pilih yang paling banyak dipakai." Tetapi studi pasca-migrasi menunjukkan dampak yang jauh melampaui *chat application*.

Perusahaan ini menggunakan Slack sejak 2017. Tim *engineering* sangat produktif dengan integrasi Slack + GitHub + Jira. Tahun 2021, manajemen memutuskan migrasi ke Teams karena "Microsoft 365 sudah di-*subscribe*, Teams gratis." Penghematan *subscription* Slack: $8/user/bulan × 200 *user* = $19.200/tahun.

Dampak yang tidak diperhitungkan: integrasi GitHub–Teams kurang mulus dibanding GitHub–Slack, *developer satisfaction* turun dari 4,5/5 ke 3,1/5, dan produktivitas tim *engineering* menurun 15% selama 3 bulan adaptasi. Baru setelah 12 bulan — dan investasi tambahan untuk konfigurasi integrasi — produktivitas kembali di atas *baseline*.

💡 **Insight:** Setiap keputusan solusi SI — bahkan yang terlihat kecil seperti *chat platform* — memiliki *ripple effect* terhadap seluruh ekosistem. Evaluasi bukan hanya fungsionalitas *tool* individual, tetapi bagaimana *tool* tersebut berintegrasi dengan ekosistem yang sudah ada. *Switching cost* bukan hanya biaya lisensi — ia mencakup produktivitas yang hilang selama adaptasi.

---

## 12.7 Salah Kaprah

⚠️ ***"Sistem yang dibangun sendiri selalu lebih baik karena disesuaikan"***

> *Custom development* memberikan kontrol penuh — tetapi membutuhkan kapasitas yang sering di-*underestimate*: tim *developer* yang kompeten dan *committed* jangka panjang, *maintenance* yang tidak pernah berhenti, dan risiko *single-point-of-failure* jika *developer* kunci *resign*. Kasus kabupaten yang *developer*-nya *resign* dan sistem lama tidak bisa di-*update* bukan anomali — itu pola yang berulang di banyak instansi.
>
> **Koreksi:** Evaluasi kapasitas IT internal secara realistis sebelum memilih *custom*. Pertanyaan kunci: "Jika *developer* utama keluar besok, apakah ada yang bisa melanjutkan?" Jika jawabannya tidak — *custom development* berisiko tinggi.

⚠️ ***"SaaS lebih murah, jadi selalu lebih baik untuk UMKM"***

> SaaS memang murah di awal — *subscription* bulanan yang terjangkau tanpa investasi infrastruktur. Tetapi akumulasi 5 tahun *subscription* bisa melebihi biaya beli COTS *one-time*. Ditambah *tier upgrade* yang hampir pasti terjadi (fitur yang dibutuhkan selalu ada di *tier* yang lebih mahal), *add-on fee*, dan biaya migrasi jika ingin pindah *provider*.
>
> **Koreksi:** Hitung TCO 5 tahun — bukan hanya biaya bulanan bulan pertama. Sertakan skenario pesimistik: *tier upgrade* di tahun ke-2, *add-on* di tahun ke-3, migrasi di tahun ke-5. Baru kemudian bandingkan dengan alternatif.

⚠️ ***"Cloud berarti tidak ada risiko keamanan data"***

> *Cloud* memindahkan tanggung jawab infrastruktur ke provider — tetapi tidak memindahkan risiko. *Shared responsibility model*: provider bertanggung jawab atas keamanan infrastruktur (server, jaringan, *physical security*), organisasi bertanggung jawab atas keamanan data dan konfigurasi (*access control*, enkripsi data sensitif, *compliance* regulasi). Kesalahan konfigurasi oleh pengguna adalah penyebab terbesar *data breach* di *cloud* — bukan kelemahan infrastruktur provider.
>
> **Koreksi:** Tanyakan sebelum memilih *cloud*: (1) Di mana data disimpan secara fisik — apakah sesuai UU PDP? (2) Apakah data di-*encrypt at rest* dan *in transit*? (3) Bagaimana SLA *uptime*? (4) Siapa yang bertanggung jawab jika terjadi *breach*?

⚠️ ***"Sekali sistem dipilih, tidak bisa diganti"***

> *Switching cost* memang tinggi — tetapi bukan prohibitif jika direncanakan sejak awal. Organisasi yang menyusun *exit strategy* sebelum memilih solusi — *data portability*, format terbuka, *exit clause* dalam kontrak — memiliki fleksibilitas untuk bermigrasi ketika kebutuhan berubah. Organisasi yang tidak merencanakan *exit* bukan hanya menghadapi biaya tinggi — ia menghadapi ketidakpastian total: berapa lama, berapa biaya, dan apakah data bisa diselamatkan.
>
> **Koreksi:** Masukkan *exit strategy* dalam kriteria evaluasi awal. Sebelum *sign* kontrak, tanyakan: "Bagaimana prosedur jika kami ingin migrasi ke platform lain dalam 3 tahun?" Jawaban vendor terhadap pertanyaan ini sangat informatif.

---

## 12.8 Studi Kasus

### 📊 Studi Kasus Dasar — Pemda dan SIPD: Analisis Keputusan *Make vs Buy* di Sektor Publik

**❌ Kondisi Awal:**
Kabupaten X memiliki SI perencanaan anggaran kustom yang dibangun tahun 2016 dengan biaya Rp 1,2 miliar. Sistem berfungsi baik selama 2 tahun. Tahun 2018, *developer* utama *resign* — tidak ada dokumentasi lengkap dan tidak ada staf IT internal yang memahami *source code*. Sistem tidak bisa di-*update* untuk mengakomodasi perubahan format pelaporan nasional. Sementara itu, pemerintah pusat meluncurkan SIPD — platform gratis dan wajib digunakan.

**✅ Analisis Terstruktur:**

### Tabel 12.3 — Perbandingan 3 Opsi untuk Kabupaten X

| Dimensi | Terus Pakai *Custom* Lama | Bangun *Custom* Baru | Migrasi ke SIPD |
|---------|--------------------------|---------------------|-----------------|
| TCO 5 tahun | Rp 3.000 jt (*maintenance* + *fix*) | Rp 5.000 jt (*dev* + tim) | Rp 200 jt (*training* saja) |
| Waktu *deploy* | Sudah ada (menurun) | 12 bulan | Sudah tersedia |
| *Compliance* nasional | Perlu *update* manual per regulasi | Bisa dirancang *compliant* | Auto-*update* oleh pusat |
| Keunikan daerah | *Fully customized* | *Fully customized* | Terbatas (*template* nasional) |
| Risiko | Tidak ada *support*, usang | *Repeat risk developer resign* | Dependensi BPKP/Kemendagri |

Kabupaten X memutuskan: SIPD sebagai sistem utama (perencanaan dan penganggaran standar nasional) + *custom dashboard* ringan (Rp 150 juta) untuk kebutuhan analitik lokal yang tidak terakomodasi SIPD. Total investasi Rp 350 juta — jauh di bawah opsi *custom* baru, dengan risiko yang terkelola.

💡 **Pelajaran:** Keputusan *make vs buy* bukan hanya soal biaya — melainkan soal *sustainability*. *Custom* yang terpersonalisasi bisa menjadi *liability* jika organisasi tidak memiliki kapasitas *maintenance* jangka panjang. Solusi *hybrid* — platform nasional untuk fungsi standar + pelengkap lokal untuk kebutuhan unik — sering kali merupakan jawaban paling pragmatis.

### 📊 Studi Kasus Lanjutan — Slack vs Microsoft Teams: Keputusan Platform dengan *Ripple Effect*

**❌ Kondisi Awal:**
Perusahaan teknologi di Jakarta (200 karyawan) menggunakan Slack sejak 2017 dengan ekosistem integrasi yang matang: Slack ↔ GitHub ↔ Jira ↔ Google Drive. Tim *engineering* (60% karyawan) sangat bergantung pada integrasi ini untuk *workflow* harian.

**✅ Analisis Dampak Migrasi ke Teams:**

### Tabel 12.4 — *Impact Assessment* Migrasi Slack → Teams

| Dimensi | Slack (sebelum) | Teams (setelah) |
|---------|----------------|----------------|
| Integrasi *engineering* | Excellent (Slack + GitHub + Jira) | *Partial* (Teams + GitHub, Jira terbatas) |
| Biaya | $8/user/bulan (terpisah) | $0 (*bundled* M365) |
| *Developer satisfaction* | 4,5/5 | 3,1/5 (bulan ke-3), 3,8/5 (bulan ke-12) |
| Produktivitas (3 bulan pasca-migrasi) | *Baseline* | −15% |
| *File management* | *Third-party* (Google Drive) | *Native* (SharePoint) |
| Penilaian 12 bulan | N/A | Kembali positif, +5% vs *baseline* |

Penghematan langsung: $19.200/tahun dari penghapusan *subscription* Slack. Biaya tersembunyi: *productivity loss* 3 bulan × 200 *user* + biaya konfigurasi integrasi baru ≈ $45.000. ROI positif baru tercapai setelah bulan ke-14.

💡 **Pelajaran:** Keputusan platform bukan hanya perbandingan fitur dan harga *subscription*. Ia keputusan ekosistem. Migrasi dari Slack ke Teams "menghemat" biaya langsung tetapi menimbulkan *productivity dip* selama adaptasi dan memaksa perubahan *workflow* seluruh tim. Manajer harus menghitung *switching cost* secara holistik — termasuk biaya yang tidak muncul di invoice.

---

## 12.9 Template Praktis

🔧 **Template A.12 — Matriks Keputusan Solusi SI**

```
TEMPLATE A.12 — MATRIKS KEPUTUSAN SOLUSI SI

Tanggal          : ________________________________________
Organisasi       : ________________________________________
Proyek SI        : ________________________________________

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

A. RINGKASAN KEBUTUHAN (dari Design Brief A.11)
   Tujuan SI        : ________________________________________
   Output kritis    : ________________________________________
   Timeline         : ________________________________________
   Budget           : ________________________________________

B. EVALUASI 3 ALTERNATIF (skor 1–10)

| Kriteria (bobot)              | Custom | COTS | SaaS | Keterangan        |
|-------------------------------|--------|------|------|-------------------|
| Kesesuaian fungsional (30%)   | __/10  | __/10| __/10| _________________ |
| TCO 5 tahun (25%)            | __/10  | __/10| __/10| _________________ |
| Waktu deployment (15%)        | __/10  | __/10| __/10| _________________ |
| Skalabilitas (10%)           | __/10  | __/10| __/10| _________________ |
| Keamanan & compliance (10%)  | __/10  | __/10| __/10| _________________ |
| Exit strategy (10%)          | __/10  | __/10| __/10| _________________ |
| TOTAL SKOR TERTIMBANG         | ______ | _____| _____| _________________ |

C. ANALISIS TCO 5 TAHUN (Rp juta)

| Komponen                       | Custom | COTS | SaaS |
|--------------------------------|--------|------|------|
| Akuisisi / lisensi            | ______ | _____| _____|
| Development / kustomisasi     | ______ | _____| _____|
| Subscription / tahun × 5     | ______ | _____| _____|
| Training                       | ______ | _____| _____|
| Maintenance                    | ______ | _____| _____|
| Hidden cost estimate           | ______ | _____| _____|
| TOTAL TCO                      | ______ | _____| _____|

D. ANALISIS RISIKO
   Custom : ________________________________________
   COTS   : ________________________________________
   SaaS   : ________________________________________

E. REKOMENDASI
   Alternatif terpilih : ________________________________________
   Alasan utama (3)    : 1. ____________________________________
                          2. ____________________________________
                          3. ____________________________________
   Exit strategy        : ________________________________________
```

---

## 12.10 Peta Konsep

### Gambar 12.2 — Peta Konsep Alternatif Solusi SI

```mermaid
mindmap
  root((Alternatif Solusi SI))
    3 Jalur
      Custom Development
        Kontrol penuh
        Risiko developer turnover
      COTS — Paket Komersial
        Best practice bawaan
        License cost
      Cloud SaaS
        Quick deploy
        Vendor lock-in risk
    Evaluasi
      TCO 5 tahun
      Weighted scoring
      Fungsional + Non-fungsional + Strategis
      Exit strategy
    Cloud Models
      SaaS — software siap pakai
      PaaS — platform development
      IaaS — infrastruktur virtual
    Tren
      Composable architecture
      Best-of-breed via API
      Hybrid approach 62%
    Anti-pattern
      Bandingkan harga awal saja
      Abaikan hidden cost
      Tanpa exit strategy
```

---

## 12.11 Rangkuman

**Poin-poin Penting:**

1. Tiga jalur solusi SI — *custom*, COTS, SaaS — masing-masing memiliki *trade-off* yang berbeda. Tidak ada solusi universal terbaik; hanya ada solusi paling tepat untuk konteks organisasi tertentu. Sebagian besar organisasi modern menggunakan pendekatan *hybrid*.

2. TCO 5 tahun harus menjadi dasar perbandingan, bukan biaya awal atau *subscription* bulanan. Harga akuisisi hanyalah 30–40% dari total biaya kepemilikan; sisanya: *training*, kustomisasi, *maintenance*, dan biaya migrasi.

3. *Vendor lock-in* adalah risiko di ketiga jalur — bukan hanya SaaS. Mitigasi dimulai sejak evaluasi awal: *data portability*, *open standards*, dan *exit clause* dalam kontrak.

4. *Cloud* bukan berarti aman otomatis. *Shared responsibility model*: provider mengamankan infrastruktur, organisasi mengamankan data dan konfigurasi. Kesalahan konfigurasi pengguna adalah penyebab terbesar *data breach* di *cloud*.

5. Setiap keputusan platform — bahkan yang terlihat kecil seperti *chat application* — memiliki *ripple effect* terhadap seluruh ekosistem SI. *Switching cost* mencakup lebih dari biaya lisensi: ia mencakup produktivitas yang hilang selama adaptasi.

6. Tren menuju *composable architecture*: merakit SI dari komponen *best-of-breed* yang terhubung via API. Manajer perlu berpikir dalam ekosistem, bukan dalam satu vendor tunggal.

---

**Menuju Bab 13:**

Solusi sudah dipilih — *custom*, COTS, SaaS, atau kombinasi *hybrid*. Tetapi memilih solusi baru permulaan. Tantangan sebenarnya ada di implementasi: mengapa 70% proyek SI gagal bukan karena teknologinya salah, tetapi karena manusianya tidak siap berubah? Bab 13 membuka Bagian VI dengan membahas implementasi SI dan manajemen perubahan — faktor yang menentukan apakah investasi miliaran rupiah menjadi aset strategis atau monumen kegagalan.

---

🔥 *"Memilih solusi SI bukan tentang teknologi terbaik di pasaran, tetapi tentang teknologi yang paling tepat untuk kebutuhan organisasi Anda hari ini dan strategi Anda lima tahun dari sekarang."*

---

## 12.12 Latihan & Refleksi

### Pertanyaan Diagnostik

Dua vendor menawarkan solusi SaaS yang dapat dipasang dengan cepat, tim internal mendorong solusi *custom*, sedangkan CFO menginginkan paket komersial berbiaya paling rendah. Lakukan penilaian dengan mempertimbangkan kesesuaian strategis, TCO, fleksibilitas proses, risiko *vendor lock-in*, kapabilitas internal, dan *exit strategy*.

### Pertanyaan Reflektif

1. Organisasi yang Anda kenal saat ini menggunakan solusi SI jenis apa (*custom*, COTS, SaaS)? Apakah keputusan tersebut dibuat berdasarkan evaluasi terstruktur atau sekadar "ikut tren" dan rekomendasi vendor?

2. Pilih satu aplikasi SaaS yang Anda gunakan sehari-hari. Hitung secara kasar TCO 3 tahun (termasuk *subscription*, *tier upgrade*, dan *add-on*). Bandingkan dengan alternatif *one-time purchase* — apakah SaaS masih lebih layak?

3. Apakah *vendor lock-in* selalu buruk? Diskusikan satu situasi di mana dependensi pada satu vendor justru memberikan keuntungan (misalnya: integrasi ekosistem yang mulus, dukungan teknis yang konsisten).

### Latihan Artefak

**Latihan 12.1 — Matriks Keputusan Solusi SI (Template A.12)**

Gunakan Template A.12 untuk mengevaluasi 3 alternatif solusi bagi SI yang sudah dispesifikasikan di Template A.11 (*design brief*).

Langkah:
1. Ambil *design brief* dari Latihan 11.1 sebagai dasar kebutuhan
2. Identifikasi 3 alternatif yang realistis — bisa berupa nama vendor/produk spesifik
3. Beri skor setiap kriteria dengan justifikasi singkat
4. Hitung TCO 5 tahun untuk setiap alternatif — gunakan estimasi realistis
5. Rumuskan rekomendasi terargumentasi dengan minimal 3 alasan

**Kriteria output yang baik:**
- Alternatif realistis dan bisa di-*benchmark* (bukan hipotetis)
- TCO mencakup biaya tersembunyi: *training*, adaptasi, *exit cost*
- Bobot kriteria disesuaikan dengan prioritas organisasi — bukan *copy-paste* dari contoh
- Rekomendasi mempertimbangkan risiko dan *exit strategy*, bukan hanya skor tertinggi

*Output Artefak 12.1 menutup Bagian V. Bab 13 memulai fase implementasi — di mana rancangan menjadi kenyataan.*

---

## Referensi

Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., & Zaharia, M. (2010). A view of cloud computing. *Communications of the ACM*, *53*(4), 50–58.

Forrester Research. (2023). *Vendor switching cost analysis in enterprise software*. Forrester.

Gartner Research. (2024). *Magic Quadrant for cloud ERP for service-centric enterprises*. Gartner, Inc.

Laudon, K. C., & Laudon, J. P. (2022). *Management information systems* (17th ed.). Pearson.

LIPI. (2023). *Survei adopsi teknologi digital UMKM Indonesia*. Lembaga Ilmu Pengetahuan Indonesia.

McKinsey & Company. (2022). *The data-driven enterprise of 2025*. McKinsey Digital.

Tasevska, F., Damm, R., & Daneva, M. (2022). Empirical study on ERP systems customization for SMEs. *Enterprise Information Systems*, *16*(2), 247–270.

Wirawan, I. M. A., & Suryadi, K. (2023). Transformasi digital UMKM Indonesia: Analisis adopsi SI berbasis cloud. *Jurnal Manajemen Teknologi*, *22*(3), 201–218.