# 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
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"] 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* | 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.