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

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)

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

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

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

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

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.