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

OUTLINE DETAIL — BAB 12

Alternatif Solusi: Custom, Komersial, dan Cloud

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

---

SEK 12.1 — PEMBUKA

Hook: Sebuah kabupaten harus memilih: menggunakan SIPD (Sistem Informasi Pemerintah Daerah) yang satu platform untuk seluruh Indonesia, atau membangun sistem anggaran kustom yang sesuai "keunikan" daerah? Pilihan pertama murah tetapi rigid; pilihan kedua fleksibel tetapi mahal. Mana yang benar? Spoiler: pertanyaannya salah — yang benar adalah: "kebutuhan mana yang paling kritis, dan solusi mana yang paling fit?"

Opening Bridge (dari Bab 11):

Bab 11 menghasilkan design brief — spesifikasi konseptual SI yang siap dikomunikasikan ke tim teknis. Pertanyaan berikutnya: siapa yang membangun? Apakah organisasi membangun sendiri (custom), membeli paket jadi (COTS), atau menyewa layanan cloud (SaaS)? Bab ini membekali manajer dengan kerangka evaluasi untuk memilih jalur yang tepat.

Central Question:

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

---

SEK 12.2 — MODEL UTAMA (Gambar 12.1)

Nama Model: Kerangka Keputusan Solusi SI

graph TD
    BK[Kebutuhan Bisnis dari Design Brief] --> A[Analisis 3 Dimensi]
    A --> DIM1[Kompleksitas Kebutuhan]
    A --> DIM2[Anggaran & Kapasitas IT]
    A --> DIM3[Urgensi & Timeline]
    DIM1 --> EVAL{Evaluasi Alternatif}
    DIM2 --> EVAL
    DIM3 --> EVAL
    EVAL --> CUSTOM[Custom Development]
    EVAL --> COTS[COTS / Paket Komersial]
    EVAL --> SAAS[Cloud / SaaS]
    CUSTOM --> TCO[Evaluasi TCO + Risiko + Skalabilitas]
    COTS --> TCO
    SAAS --> TCO
    TCO --> REC[Rekomendasi Terargumentasi]

Penjelasan Node:

• Kebutuhan Bisnis — dari design brief Bab 11. Keputusan solusi dimulai dari kebutuhan, bukan dari teknologi.
• 3 Dimensi Analisis: Kompleksitas (apakah kebutuhan unik?), Anggaran/Kapasitas IT (budget dan tim internal), Urgensi (berapa cepat harus jadi?).
• Custom Development — dibangun dari nol oleh tim internal atau vendor. Fleksibel, mahal, lama.
• COTS (Commercial Off-The-Shelf) — paket jadi (SAP, Oracle, Odoo). Proven, butuh kustomisasi, license cost.
• Cloud/SaaS — layanan subscription (Salesforce, Google Workspace). Cepat deploy, recurring cost, dependensi vendor.
• TCO — total biaya kepemilikan selama siklus hidup SI (5 tahun), bukan hanya biaya awal.
• Rekomendasi Terargumentasi — keputusan yang didukung data dan analisis, bukan preferensi subjektif.

---

SEK 12.3 — DEFINISI KUNCI

📌 Total Cost of Ownership (TCO) Perhitungan total biaya SI selama siklus hidupnya — mencakup biaya akuisisi (license, hardware, development), biaya operasional (maintenance, hosting, support), dan biaya tersembunyi (training, downtime, migration). Relevansi manajerial: Manajer yang hanya membandingkan harga beli/license akan membuat keputusan yang salah. SI "murah" bisa menjadi mahal jika maintenance cost tinggi.

📌 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. Relevansi manajerial: Lock-in mengurangi bargaining power dan fleksibilitas strategis. Manajer harus mengevaluasi exit strategy sebelum memilih vendor.

📌 SaaS / PaaS / IaaS (X as a Service) Tiga model layanan cloud: SaaS (software siap pakai, e.g. Google Workspace), PaaS (platform development, e.g. Heroku), IaaS (infrastruktur, e.g. AWS EC2). Manajer perlu memahami mana yang relevan untuk kebutuhan mereka. Relevansi manajerial: Tidak semua "cloud" sama. SaaS untuk quick deployment, PaaS untuk development team yang ingin agility, IaaS untuk organisasi dengan kebutuhan infrastruktur spesifik.

---

SEK 12.4 — KONSEP INTI (6 sub-seksi)

12.4.1 Tiga Jalur Solusi: Bangun, Beli, atau Sewa

• Argumen: Setiap jalur memiliki trade-off. Tidak ada "solusi terbaik" universal — hanya ada "solusi paling tepat" untuk konteks organisasi tertentu.
• Custom: Maksimal kontrol, biaya dan risiko tinggi, butuh tim IT internal yang kuat.
• COTS: Best practice bawaan, butuh kustomisasi, risiko vendor dependency.
• SaaS: Quick deploy, recurring cost, risiko data sovereignty.
• Data pendukung: 62% organisasi di Asia Tenggara menggunakan hybrid approach (Gartner, 2024).

12.4.2 TCO: Biaya yang Sering Diabaikan

• Argumen: Harga beli hanyalah 30-40% dari total biaya SI selama 5 tahun. Biaya tersembunyi: training, customization, data migration, downtime, opportunity cost, dan exit/migration cost.
• Data pendukung: Gartner (2024) menunjukkan bahwa organisasi yang tidak menghitung TCO mengalami budget overrun rata-rata 45%.
• Contoh TCO 5 tahun:

Komponen	Custom	COTS (SAP)	SaaS
Akuisisi awal	Rp 2M	Rp 1.5M (license)	Rp 0
Development	Rp 3M	Rp 1M (customization)	Rp 0
Subscription/tahun	Rp 0	Rp 300K maintenance	Rp 500K
Training	Rp 500K	Rp 700K	Rp 200K
Total 5 tahun	Rp 5.5M	Rp 4.7M	Rp 2.7M
Hidden cost risk	Tinggi (bug fix, turnover dev)	Menengah (upgrade, kustomisasi lanjut)	Rendah (tapi lock-in)

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

• Argumen: Evaluasi solusi harus mencakup 3 lapisan: (1) Fungsional — apakah solusi memenuhi kebutuhan dari design brief? (2) Non-fungsional — performa, keamanan, skalabilitas, (3) Strategis — alignment dengan strategi jangka panjang organisasi.
• Weighted scoring: Berikan bobot pada setiap kriteria sesuai prioritas organisasi. Hindari keputusan berdasarkan demo vendor yang impresif tanpa evaluasi terstruktur.

12.4.4 Risiko Vendor Lock-in dan Strategi Mitigasi

• Argumen: Lock-in terjadi di semua jalur: custom (tergantung developer tunggal), COTS (tergantung vendor license), SaaS (data di server vendor). Mitigasi: data portability, open standards, kontrak exit clause.
• Data pendukung: 34% organisasi mengalami masalah signifikan saat migrasi dari satu vendor ke vendor lain — rata-rata 18 bulan dan 150% over-budget (Forrester, 2023).

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

• Argumen: Manajer tidak perlu memahami teknis cloud — tetapi harus memahami implikasi bisnis dari setiap model. SaaS = cepat tapi rigid, PaaS = fleksibel tapi butuh developer, IaaS = full control tapi butuh sysadmin.
• Contoh per model: SaaS: Google Workspace, Zoom. PaaS: Google App Engine, Heroku. IaaS: AWS EC2, Azure VM.
• Data pendukung: McKinsey (2022) melaporkan bahwa 70% spending cloud organisasi besar di SaaS, 20% IaaS, 10% PaaS.

12.4.6 Tren: Composable Architecture dan Ekosistem API

• Argumen: Era "satu sistem untuk semua" sedang berakhir. Tren menuju composable architecture: merakit SI dari komponen-komponen terbaik (best-of-breed) yang terhubung via API. Manajer tidak perlu memilih satu vendor — tetapi harus memahami bahwa integrasi antar komponen membutuhkan governance.
• Contoh: Organisasi menggunakan Salesforce (CRM) + SAP (ERP) + Tableau (BI) + Slack (komunikasi) — semua terintegrasi via API. Tidak ada satu vendor yang mendominasi, tetapi ekosistem ini membutuhkan integration strategy.

---

SEK 12.5 — KOMPARASI (Tabel 12.1)

Judul: "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 (license + support)	Tinggi (subscription)
Kustomisasi	Unlimited	Terbatas	Minimal
Scalability	Manual	Butuh upgrade	Auto-scale
Risiko utama	Developer turnover, bug	Vendor lock-in, upgrade force	Data sovereignty, outage
Cocok untuk	Kebutuhan sangat unik	Proses standar industri	Quick deployment, UMKM

💡 Insight: Tidak ada pemenang universal. Custom cocok untuk organisasi dengan kebutuhan unik dan tim IT kuat. COTS cocok untuk proses standar (akuntansi, HR) yang sudah proven. SaaS cocok untuk UMKM dan organisasi yang menginginkan agility tanpa beban infrastruktur. Sebagian besar organisasi modern menggunakan hybrid.

---

SEK 12.6 — REALITAS LAPANGAN (3 fenomena)

Fenomena 1: SIPD — Ketika Platform Nasional Bertemu Keunikan Daerah

SIPD (Sistem Informasi Pemerintah Daerah) dirancang sebagai platform nasional tunggal untuk perencanaan dan penganggaran 548 kabupaten/kota. Keuntungan: standardisasi, data terpusat, biaya per-daerah rendah. Tantangan: setiap daerah memiliki kekhususan (otonomi khusus, desa adat, format kelembagaan berbeda) yang sulit diakomodasi oleh satu platform. Beberapa daerah tetap memelihara "sistem bayangan" untuk kebutuhan yang tidak terlayani SIPD.

💡 Insight: Platform one-size-fits-all efisien dalam skala — tetapi selalu menyisakan gap di level lokal. Manajer daerah harus memahami mana kebutuhan yang bisa "mengalah" ke standar nasional dan mana yang benar-benar membutuhkan solusi pelengkap.

Fenomena 2: UMKM Indonesia dan Dilema Cloud

Survei LIPI (2023) menunjukkan bahwa 78% UMKM Indonesia yang mengadopsi SaaS (POS, akuntansi) melaporkan peningkatan efisiensi operasional. Tetapi 42% di antaranya mengalami masalah: data tidak bisa di-export ketika ingin pindah provider, fitur yang dibutuhkan hanya ada di tier berbayar yang lebih mahal, dan ketergantungan pada internet stabil yang tidak selalu tersedia.

💡 Insight: Cloud adalah game changer untuk UMKM — tetapi bukan tanpa trade-off. Sebelum memilih SaaS, tanyakan: bisakah saya export data kapan saja? Apa yang terjadi jika internet mati? Berapa total cost dalam 3 tahun termasuk tier upgrade?

Fenomena 3: Slack vs Microsoft Teams — Platform War yang Menentukan Produktivitas

Ketika perusahaan memilih platform kolaborasi, keputusan terlihat sederhana: "pilih yang banyak orang pakai." Tetapi studi Accenture (2023) menunjukkan bahwa pilihan Slack vs Teams berdampak pada seluruh ekosistem SI: Teams terintegrasi native dengan Microsoft 365 (Word, Excel, SharePoint), Slack terintegrasi lebih baik dengan tool non-Microsoft (Jira, GitHub, Notion). Pilihan yang "kecil" ini ternyata menentukan arsitektur SI selama bertahun-tahun.

💡 Insight: Setiap keputusan solusi SI — bahkan yang terlihat kecil — memiliki ripple effect terhadap seluruh ekosistem. Evaluasi bukan hanya fungsionalitas tool individual, tetapi bagaimana tool tersebut berintegrasi dengan ekosistem yang sudah ada dan yang akan dibangun.

---

SEK 12.7 — SALAH KAPRAH (⚠️)

⚠️ Jebakan 1: "Sistem yang dibangun sendiri selalu lebih baik karena disesuaikan"

Mengapa salah: Custom development memberikan kontrol penuh tetapi membutuhkan kapasitas yang sering di-underestimate: tim developer yang kompeten, maintenance jangka panjang, dan risiko single-point-of-failure jika developer resign. Koreksi: Evaluasi kapasitas IT internal secara realistis. Jika tidak ada tim developer permanen dengan track record, custom development berisiko tinggi.

⚠️ Jebakan 2: "SaaS lebih murah, jadi selalu lebih baik untuk UMKM"

Mengapa salah: SaaS memang murah di awal (subscription bulanan), tetapi akumulasi 5 tahun subscription bisa melebihi one-time purchase COTS. Ditambah tier upgrade, add-on fee, dan biaya migration jika pindah provider. Koreksi: Hitung TCO 5 tahun, bukan hanya biaya bulanan. Bandingkan SaaS vs COTS termasuk hidden cost.

⚠️ Jebakan 3: "Cloud berarti tidak ada risiko keamanan data"

Mengapa salah: Cloud memindahkan tanggung jawab infrastruktur ke provider, bukan memindahkan risiko. Data sovereignty (data di server mana?), compliance (sesuai UU PDP?), dan outage risk tetap ada. Shared responsibility model: provider bertanggung jawab atas infrastruktur, organisasi bertanggung jawab atas data dan konfigurasi. Koreksi: Tanyakan: di mana data disimpan? Apakah encrypted at rest dan in transit? Bagaimana SLA uptime? Apakah compliant dengan UU PDP?

⚠️ Jebakan 4: "Sekali sistem dipilih, tidak bisa diganti"

Mengapa salah: Switching cost memang tinggi tetapi bukan prohibitif jika sejak awal direncanakan exit strategy: data portability, open format, dan kontrak dengan exit clause. Koreksi: Masukkan exit strategy dalam evaluasi awal: bisakah data di-export? Format apa? Berapa lama proses migrasi?

---

SEK 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 kustom yang dibangun 2016. Biaya awal Rp 1.2M. Tetapi developer resign 2018, sistem tidak bisa di-update, dan tidak compatible dengan format laporan terbaru. Sementara itu, pemerintah pusat meluncurkan SIPD (gratis, wajib).

✅ Analisis Make vs Buy vs SIPD:

Dimensi	Custom Lama	Custom Baru	SIPD (Gratis)
Biaya 5 tahun	Rp 3M (maintenance + fix)	Rp 5M (development + team)	Rp 0 (tapi butuh training Rp 200K)
Waktu deploy	Sudah ada (tapi declining)	12 bulan	Sudah tersedia
Compliance	Perlu update manual	Bisa dirancang compliant	Auto-updated oleh pusat
Keunikan daerah	Fully customized	Fully customized	Terbatas (template nasional)
Risiko	Developer resigned, no support	Repeat risk	Dependency pada BPKP/Kemendagri

💡 Pelajaran: Keputusan make vs buy bukan hanya soal biaya — tetapi soal sustainability. Custom yang lebih terpersonalisasi bisa menjadi liability jika organisasi tidak memiliki kapasitas maintenance jangka panjang. SIPD yang "gratis" memiliki hidden cost berupa keterbatasan kustomisasi.

📊 Studi Kasus Lanjutan — Slack vs Microsoft Teams: Platform Decision dengan Ripple Effect

❌ Kondisi Awal: Perusahaan tech startup di Jakarta menggunakan Slack sejak 2017. Tim engineering sangat produktif dengan Slack + GitHub + Jira integration. Tetapi 2021, manajemen memutuskan migrasi ke Teams karena "Microsoft 365 sudah di-subscribe perusahaan."

✅ Impact Assessment:

Dimensi	Slack (sebelum)	Teams (setelah)
Integration engineering	Excellent (Slack + GitHub + Jira)	Partial (Teams + GitHub, Jira terbatas)
Cost	$8/user/bulan (terpisah)	$0 (bundled M365)
Developer satisfaction	4.5/5	3.1/5
Productivity (3 bulan pasca migrasi)	Baseline	-15% (adaptation period)
File management	Third-party (Google Drive)	Native (SharePoint)
12-bulan assessment	N/A	Kembali positif, +5% vs baseline

💡 Pelajaran: Keputusan platform bukan hanya perbandingan fitur — ia keputusan ekosistem. Migrasi dari Slack ke Teams "menghemat" subscription fee tetapi menimbulkan productivity dip selama 3-6 bulan dan memaksa perubahan workflow seluruh tim engineering. ROI baru positif setelah 12 bulan. Manajer harus menghitung switching cost secara holistik.

---

SEK 12.9 — TEMPLATE PRAKTIS (🔧)

Nama: 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

| 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 | __/10 | __/10 | __/10 | |

C. ANALISIS TCO 5 TAHUN (Rp juta)
   | Komponen | Custom | COTS | SaaS |
   |----------|--------|------|------|
   | Akuisisi/license | ____  | ____ | ____ |
   | Development/customization | ____ | ____ | ____ |
   | 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. ____________________________________

---

SEK 12.10 — PETA KONSEP (Gambar 12.2)

mindmap
  root((Alternatif Solusi SI))
    3 Jalur
      Custom Development
        Kontrol penuh
        Risiko developer turnover
      COTS
        Best practice bawaan
        License cost
      Cloud SaaS
        Quick deploy
        Vendor lock-in risk
    Evaluasi
      TCO 5 tahun
      Weighted scoring
      Exit strategy
    Cloud Models
      SaaS
      PaaS
      IaaS
    Tren
      Composable architecture
      Best-of-breed via API
      Hybrid approach
    Anti-pattern
      Banding harga awal saja
      Abaikan hidden cost
      No exit strategy

---

SEK 12.11 — RANGKUMAN

Takeaway utama:

1. Tiga jalur solusi SI — custom, COTS, SaaS — masing-masing memiliki trade-off. Tidak ada solusi universal terbaik; hanya ada solusi paling tepat untuk konteks organisasi.
2. TCO 5 tahun harus menjadi dasar perbandingan, bukan biaya awal. Harga beli hanyalah 30-40% dari total biaya kepemilikan.
3. Vendor lock-in adalah risiko di semua jalur. Mitigasi dimulai sejak evaluasi awal: data portability, open format, exit clause dalam kontrak.
4. Cloud bukan berarti aman otomatis. Shared responsibility model: provider bertanggung jawab atas infrastruktur, organisasi bertanggung jawab atas data dan konfigurasi.
5. Keputusan platform — bahkan yang terlihat kecil — memiliki ripple effect terhadap seluruh ekosistem SI organisasi.
6. Tren menuju composable architecture: organisasi merakit SI dari best-of-breed components via API, bukan mengandalkan satu vendor monolitik.

Closing Bridge (ke Bab 13):

Solusi sudah dipilih — custom, COTS, atau SaaS. Tetapi memilih solusi baru awal perjalanan. Bab 13 membahas tantangan implementasi SI: mengapa 70% proyek gagal bukan karena teknologinya, tetapi karena manusianya, dan bagaimana manajemen perubahan menjadi kunci keberhasilan.

🔥 Final Statement:

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

---

SEK 12.12 — LATIHAN & REFLEKSI

Pertanyaan Refleksi:

1. Organisasi Anda saat ini menggunakan solusi SI jenis apa (custom/COTS/SaaS)? Apakah keputusan tersebut dibuat berdasarkan evaluasi terstruktur atau "ikut tren"?
2. Hitung secara kasar TCO 5 tahun dari satu aplikasi SaaS yang Anda gunakan. Bandingkan dengan opsi alternatif — apakah masih layak?
3. Diskusikan: apakah vendor lock-in selalu buruk? Adakah situasi di mana lock-in justru menguntungkan?

Tugas Artefak:

Gunakan Template A.12 (Matriks Keputusan Solusi SI) untuk mengevaluasi 3 alternatif solusi bagi SI yang sudah dispesifikasikan di Template A.11 (design brief). Lengkapi TCO 5 tahun dan berikan rekomendasi terargumentasi.

---

REFERENSI BAB 12

1. Gartner Research. (2024). Magic Quadrant for Cloud ERP for Service-Centric Enterprises. Gartner, Inc.
2. Wirawan, I. M. A., & Suryadi, K. (2023). Transformasi digital UMKM Indonesia: Analisis adopsi SI berbasis cloud. Jurnal Manajemen Teknologi, 22(3), 201–218.
3. Tasevska, F., Damm, R., & Daneva, M. (2022). Empirical study on ERP systems customization for SMEs. Enterprise Information Systems, 16(2), 247–270.
4. Armbrust, M., et al. (2010). A view of cloud computing. Communications of the ACM, 53(4), 50–58.
5. McKinsey & Company. (2022). The data-driven enterprise of 2025. McKinsey Digital.
6. Forrester Research. (2023). Vendor switching cost analysis in enterprise software. Forrester.
7. Laudon, K. C., & Laudon, J. P. (2022). Management Information Systems (17th ed.). Pearson.
8. LIPI. (2023). Survei adopsi teknologi digital UMKM Indonesia. Lembaga Ilmu Pengetahuan Indonesia.

---

QUALITY GATES CHECK

[✓] Gate 1 — THINK   : Mengubah pandangan dari "pilih yang paling canggih/murah" ke "evaluasi terstruktur berdasarkan TCO + konteks"
[✓] Gate 2 — APPLY   : Template A.12 langsung applicable untuk evaluasi alternatif solusi dengan weighted scoring
[✓] Gate 3 — REFLECT : Pembaca merefleksikan apakah keputusan SI di organisasinya dibuat berdasarkan evaluasi atau ikut tren