# BAB 13 — Implementasi Sistem Informasi


```
Bagian          : VI — Implementasi, Evaluasi & Risiko
Reader Outcome  : Pembaca mampu menganalisis faktor kritis keberhasilan dan
                  kegagalan implementasi SI, serta merancang strategi manajemen
                  perubahan yang relevan.
Level           : Lanjutan–Mahir
Estimasi Halaman: 15–18
```

---

## 13.1 Pembuka

Bab 12 membantu Anda mengevaluasi dan memilih solusi SI — *custom*, COTS, SaaS, atau kombinasi *hybrid* — menggunakan Matriks Keputusan Solusi SI (Template A.12). Keputusan sudah dibuat. Tetapi inilah titik di mana sebagian besar proyek SI gagal.

Proyek e-KTP Indonesia: anggaran Rp 5,9 triliun, teknologi biometrik canggih (*fingerprint* + *iris scan*), *database* terpusat untuk 300+ juta penduduk. Secara teknologi, proyek ini setara standar internasional. Tetapi bertahun-tahun bermasalah — bukan karena *scanner*-nya rusak atau *database*-nya lambat. Operator di kecamatan hanya dilatih 3 hari untuk perangkat yang kompleks. Jaringan internet di daerah terpencil tidak stabil. Data dari KTP lama dimigrasikan tanpa pembersihan, menghasilkan jutaan duplikasi. *Governance* pengadaan bermasalah. Satu per satu, masalah yang bukan masalah teknologi menumpuk menjadi kegagalan sistemik.

Proyek e-KTP memperlihatkan pola yang berulang di implementasi SI di seluruh dunia: Standish Group (2023) melaporkan bahwa hanya 31% proyek SI "berhasil" — tepat waktu, tepat anggaran, dan memenuhi kebutuhan. Sisanya mengalami *overrun*, gagal sebagian, atau dibatalkan total. Dan penyebab dominannya konsisten: bukan teknologi, melainkan manusia.

Mengapa implementasi SI lebih sering gagal karena faktor manusia daripada faktor teknologi — dan bagaimana manajer merancang strategi manajemen perubahan yang memastikan SI benar-benar diadopsi?

---

## 13.2 Model Utama

### Gambar 13.1 — Model Implementasi SI Berbasis Manajemen Perubahan

```mermaid
graph LR
    PLAN["Perencanaan<br>Scope, timeline,<br>resource, risk"] --> READY["Kesiapan<br>Organisasi<br>Infra, SDM, data"]
    READY --> UAT["Pengujian<br>UAT"]
    UAT --> GO["Go-Live &<br>Hypercare"]
    GO --> STAB["Stabilisasi<br>& BAU"]
    CM["Manajemen<br>Perubahan"] ---|komunikasi| READY
    CM ---|pelatihan| UAT
    CM ---|resistensi| GO
    CM ---|champion| STAB
    STAB -.->|continuous improvement| PLAN
    style PLAN fill:#5c1a1a,stroke:#333,color:#fff
    style READY fill:#5c1a1a,stroke:#333,color:#fff
    style UAT fill:#5c1a1a,stroke:#333,color:#fff
    style GO fill:#5c1a1a,stroke:#333,color:#fff
    style STAB fill:#5c1a1a,stroke:#333,color:#fff
    style CM fill:#f5f5f5,stroke:#5c1a1a,color:#333
```

**Perencanaan** — fase di mana *scope*, *timeline*, alokasi sumber daya, dan rencana mitigasi risiko ditetapkan. Kesalahan di fase ini berakumulasi: *scope* yang tidak jelas menghasilkan *requirement* yang berubah-ubah, *timeline* yang tidak realistis memaksa *shortcut* di fase berikutnya, dan anggaran yang tidak memperhitungkan *change management* membuat organisasi tidak siap.

**Kesiapan Organisasi** — sebelum sistem di-*deploy*, empat hal harus diperiksa: apakah infrastruktur siap (jaringan, *hardware*, *server*)? Apakah SDM siap (terlatih, *aware*, mau berubah)? Apakah proses bisnis sudah dirancang ulang ke kondisi TO-BE? Apakah data lama sudah dibersihkan dan siap dimigrasikan? Jika satu saja tidak siap, *go-live* berisiko tinggi.

**Pengujian UAT (*User Acceptance Testing*)** — pengguna akhir menguji SI dalam skenario kerja nyata. UAT bukan tes apakah sistem "tidak *crash*" — ia tes apakah SI menghasilkan *output* yang benar, mendukung alur kerja yang sudah dirancang, dan bisa dioperasikan oleh pengguna dengan tingkat kompetensi yang realistis.

***Go-Live* & *Hypercare*** — periode 2–4 minggu pasca peluncuran di mana tim *support* *standby* penuh. Masalah terburuk biasanya muncul di sini: data yang ternyata tidak kompatibel, *workflow* yang tidak sesuai ekspektasi, pengguna yang frustrasi dan ingin kembali ke cara lama. Intensitas *support* di periode ini menentukan apakah SI bertahan atau ditinggalkan.

**Stabilisasi & BAU (*Business As Usual*)** — SI sudah menjadi bagian dari operasi harian. Tetapi stabilisasi bukan akhir — *continuous improvement* harus terus berjalan berdasarkan *feedback* pengguna dan perubahan kebutuhan bisnis.

**Manajemen Perubahan** — perhatikan posisinya di diagram: bukan fase terpisah yang datang setelah *go-live*, melainkan aktivitas paralel yang berjalan di seluruh siklus. Di fase kesiapan: komunikasi "mengapa berubah." Di fase UAT: pelatihan *hands-on*. Di fase *go-live*: penanganan resistensi. Di fase stabilisasi: pemberdayaan *change champion*. Organisasi yang memperlakukan manajemen perubahan sebagai *afterthought* — "nanti saja, setelah sistem jadi" — adalah organisasi yang menyiapkan kegagalan.

---

## 13.3 Definisi Kunci

📌 **Manajemen Perubahan (*Change Management*)**
Pendekatan terstruktur untuk membantu individu, tim, dan organisasi bertransisi dari kondisi saat ini ke kondisi yang diinginkan. Dalam konteks SI, manajemen perubahan memastikan pengguna *mau* dan *mampu* menggunakan sistem baru — bukan sekadar "disuruh pakai." Kotter (2012) mengidentifikasi 8 langkah perubahan; Prosci (2024) menyederhanakan menjadi model ADKAR: *Awareness*, *Desire*, *Knowledge*, *Ability*, *Reinforcement*. Teknologi yang tidak diadopsi pengguna bernilai nol — berapa pun biaya investasinya.

📌 ***User Adoption***
Tingkat di mana pengguna akhir benar-benar menggunakan SI baru dalam pekerjaan sehari-hari secara konsisten — bukan sekadar "bisa *login*" atau "pernah mencoba sekali." *User adoption* adalah *ultimate metric* keberhasilan implementasi. SI dengan fitur sempurna tetapi hanya diadopsi 20% pengguna adalah kegagalan mahal: 80% investasi tidak menghasilkan nilai.

📌 ***Change Champion***
Individu di dalam organisasi — biasanya manajer menengah atau *power user* — yang secara aktif mendukung perubahan, membantu rekan kerja beradaptasi, dan menjadi jembatan antara tim proyek dan pengguna akhir. *Champion* mengatasi resistensi *peer-to-peer*: rekan kerja lebih percaya "salah satu dari mereka" dibandingkan arahan *top-down* dari manajemen. Prosci (2024) merekomendasikan rasio minimal 1 *champion* per 25 pengguna.

---

## 13.4 Konsep Inti

### 13.4.1 Mengapa 70% Proyek SI Gagal: Pola yang Berulang

Angka 31% keberhasilan dari Standish Group (2023) bukan statistik baru — ia pola yang persisten selama dua dekade, meskipun teknologi semakin matang dan metodologi semakin canggih. Pola kegagalan yang berulang:

- ***Scope creep*** — kebutuhan terus bertambah tanpa penambahan waktu dan anggaran. "Sekalian tambahkan fitur X" adalah kalimat paling mahal dalam proyek SI.
- **Sponsor eksekutif menghilang** — di bulan pertama, direksi hadir di setiap *meeting*. Di bulan keenam, mereka sudah "sibuk" dan mendelegasikan ke staf. Tim proyek kehilangan *authority* untuk membuat keputusan lintas departemen.
- **Resistensi pengguna** — bukan karena pengguna "anti teknologi," tetapi karena mereka tidak dilibatkan sejak awal, tidak memahami mengapa perubahan diperlukan, atau merasa SI baru membuat pekerjaan mereka lebih rumit.
- **Pelatihan tidak memadai** — *training* sehari dianggap "cukup" untuk mengubah kebiasaan kerja bertahun-tahun.

McKinsey (2022) menemukan bahwa proyek transformasi digital dengan *change management* aktif memiliki *success rate* 6× lebih tinggi dibandingkan yang tidak. Angka ini bukan kebetulan — ia menunjukkan bahwa kegagalan implementasi bukan masalah nasib, melainkan masalah pendekatan.

### 13.4.2 *People–Process–Technology*: Urutan yang Sengaja

*Framework* PPT (*People–Process–Technology*) sudah ada sejak 1990-an, tetapi organisasi terus mengulangi kesalahan yang sama: memulai dari teknologi, baru kemudian memikirkan proses dan manusia. Urutan yang benar — dan alasannya:

**People (Orang)** — pertama dan paling kritis. Apakah pengguna memahami mengapa perubahan diperlukan? Apakah mereka memiliki *skill* yang dibutuhkan? Apakah ada resistensi yang harus ditangani? Deloitte (2023) melaporkan bahwa 85% CEO mengakui *people issue* sebagai hambatan terbesar transformasi digital.

**Process (Proses)** — setelah orang siap, pastikan proses bisnis sudah dirancang ulang. Mengotomatisasi proses yang buruk hanya menghasilkan "proses buruk yang lebih cepat." Proses TO-BE dari pemodelan di Bab 10 harus sudah final sebelum teknologi di-*deploy*.

**Technology (Teknologi)** — terakhir. Teknologi adalah *enabler*, bukan *driver*. SI yang canggih tetapi ditempatkan di atas proses yang belum diperbaiki dan orang yang belum siap akan gagal — persis seperti e-KTP.

### 13.4.3 Manajemen Perubahan: ADKAR sebagai Kerangka Kerja Praktis

Prosci (2024) mengembangkan model ADKAR sebagai kerangka kerja manajemen perubahan yang bisa dioperasionalkan per individu:

- ***Awareness*** — "Mengapa perubahan ini diperlukan?" Jika pengguna tidak paham alasannya, mereka akan melihat SI baru sebagai "beban tambahan," bukan solusi.
- ***Desire*** — "Apakah saya mau berubah?" *Awareness* saja tidak cukup. Pengguna bisa paham alasannya tetapi tetap tidak mau — karena perubahan mengancam *comfort zone*, status, atau cara kerja yang sudah familiar.
- ***Knowledge*** — "Bagaimana cara menggunakan SI baru?" Pelatihan teknis masuk di sini — dan posisinya di urutan ketiga bukan kebetulan: tanpa *Awareness* dan *Desire*, pelatihan tidak efektif.
- ***Ability*** — "Apakah saya mampu melakukannya di pekerjaan nyata?" Ada jarak antara "tahu caranya" (dari *training*) dan "mampu melakukannya" (di tekanan kerja harian). *On-the-job coaching* dan *job aid* menjembatani jarak ini.
- ***Reinforcement*** — "Apakah saya akan konsisten?" Tanpa penguatan — apresiasi, *feedback*, *metric*, konsekuensi — perilaku lama kembali dalam hitungan minggu. *Change champion* berperan krusial di elemen ini.

Setiap elemen ADKAR harus dipenuhi secara berurutan. Jika *Awareness* rendah, *training* (*Knowledge*) tidak akan efektif — pengguna mengikuti *training* dengan sikap "terpaksa." Jika *Ability* rendah, *Reinforcement* menjadi tekanan — pengguna dipaksa menggunakan SI yang belum mereka kuasai.

### 13.4.4 Strategi *Deployment*: *Phased*, *Big Bang*, *Pilot*

Tidak ada strategi *deployment* yang superior secara universal — masing-masing memiliki konteks yang tepat:

### Tabel 13.2 — Perbandingan Strategi *Deployment*

| Aspek | *Phased* | *Big Bang* | *Pilot* |
|-------|---------|-----------|--------|
| Mekanisme | Deploy per modul/unit bertahap | Deploy seluruh sistem serentak | Deploy di 1 unit uji coba dulu |
| Risiko | Rendah–menengah | Tinggi | Rendah |
| *Timeline* | Panjang (berbulan-bulan) | Pendek (sekali *switch*) | Menengah |
| Biaya | Lebih tinggi (paralel lama) | Lebih rendah (sekali transisi) | Menengah |
| *Rollback* | Mudah (per modul) | Sangat sulit (seluruh organisasi) | Mudah (1 unit saja) |
| Cocok untuk | Organisasi besar, risiko tinggi | Sistem yang harus *live* serentak (regulasi) | Validasi sebelum *rollout* massal |

***Phased*** — setiap modul atau unit bisnis di-*deploy* secara bertahap. Unit yang sudah *live* menjadi referensi bagi unit berikutnya. Kelemahan: periode transisi panjang di mana sebagian organisasi masih menggunakan sistem lama dan sebagian sudah baru — menciptakan kompleksitas integrasi.

***Big Bang*** — seluruh sistem di-*deploy* sekaligus pada satu tanggal. Transisi cepat, tidak ada periode paralel yang membingungkan. Tetapi risikonya sangat tinggi: jika ada masalah kritis, seluruh organisasi terdampak secara bersamaan. Hershey (1999) adalah contoh klasik kegagalan *big bang*.

***Pilot*** — di-*deploy* di satu unit atau cabang sebagai uji coba. *Feedback* dan *lesson learned* dari pilot menjadi masukan untuk perbaikan sebelum *rollout* ke seluruh organisasi. Cocok untuk organisasi besar dengan unit yang beragam — tetapi pilot yang "terlalu bersih" (dipilih unit terbaik, didukung *support* ekstra) bisa menghasilkan *false confidence*.

### 13.4.5 *User Adoption*: Lebih dari Sekadar *Training*

Davis (1989) dalam *Technology Acceptance Model* (TAM) mengidentifikasi dua faktor utama *user adoption*: ***Perceived Usefulness*** (seberapa berguna SI menurut pengguna) dan ***Perceived Ease of Use*** (seberapa mudah SI dioperasikan). Jika salah satu rendah, *adoption* terancam — SI yang sangat berguna tetapi sulit digunakan akan dihindari, dan SI yang mudah tetapi dianggap tidak berguna akan diabaikan.

Strategi meningkatkan *adoption*:

1. **Libatkan pengguna sejak fase desain** — jika pengguna merasa "sistem ini dibuat dengan masukan saya," resistensi turun secara alami. Keterlibatan bukan hanya formalitas (*sign-off*) tetapi partisipasi aktif dalam menentukan *workflow* dan *interface*.
2. ***Training hands-on*, bukan kuliah** — demonstrasi di depan kelas menghasilkan *awareness*, tetapi *hands-on practice* dengan data nyata menghasilkan *ability*. Rasio ideal: 20% teori, 80% praktik.
3. ***Quick wins* yang terlihat** — tunjukkan manfaat SI dalam minggu pertama. Jika pengguna harus menunggu 3 bulan untuk merasakan manfaat, motivasi menguap. Identifikasi 1–2 fitur yang langsung meringankan pekerjaan dan soroti di awal.
4. ***Support* responsif** — pertanyaan pengguna di hari pertama yang dijawab dalam 10 menit membangun kepercayaan. Pertanyaan yang dijawab 3 hari kemudian membangun frustrasi. *Help desk* yang responsif bukan *cost center* — ia investasi *adoption*.
5. ***Metric adoption* yang di-*track*** — mengukur jumlah *login*, transaksi per hari, fitur yang digunakan, dan *support ticket*. Data *adoption* memberi sinyal awal di mana intervensi diperlukan.

### 13.4.6 *Change Champion* dan Peran Manajer Menengah

Manajer menengah adalah *kingmaker* atau *dealbreaker* implementasi SI. Mereka menerjemahkan visi *top management* ke tindakan operasional. Mereka yang membagi tugas, menentukan prioritas, dan memberi contoh perilaku. Jika manajer menengah menggunakan SI baru di rapat dan meminta *report* dari SI — timnya akan mengikuti. Jika manajer menengah masih minta laporan dari *spreadsheet* lama — timnya membaca sinyal: "SI baru tidak penting."

Prosci (2024) mendokumentasikan dampak *change champion*: proyek dengan minimal 1 *champion* per 25 pengguna memiliki *adoption rate* 78%, dibandingkan 42% tanpa *champion*. Perbedaan 36 poin persentase ini menunjukkan bahwa investasi dalam *champion network* — identifikasi, pelatihan, dukungan, pengakuan — memberikan ROI yang sangat tinggi terhadap keberhasilan implementasi.

Siapa yang menjadi *champion* yang efektif? Bukan selalu orang yang paling "jago IT." *Champion* terbaik adalah orang yang dipercaya oleh rekan kerja, memiliki pengaruh informal, dan bersedia meluangkan waktu untuk membantu orang lain. Mereka menjawab pertanyaan "kecil" yang tidak sampai ke *help desk*, menenangkan rekan yang frustrasi, dan menunjukkan bahwa "sistem baru memang bisa bekerja."

### 13.4.7 *Hypercare* dan Stabilisasi Pasca *Go-Live*

Dua sampai empat minggu pertama pasca *go-live* — periode yang disebut *hypercare* — adalah momen paling kritis dalam seluruh siklus implementasi. Di periode ini, masalah yang tidak terdeteksi di UAT muncul, pengguna yang sudah dilatih ternyata lupa prosedur, dan frustrasi akumulatif bisa memicu gelombang resistensi.

*Checklist hypercare* yang efektif:

- ***Help desk* khusus** — bukan *help desk* IT umum, melainkan tim *support* yang memahami SI baru dan konteks bisnis pengguna. Waktu respons target: < 30 menit untuk masalah kritis, < 4 jam untuk pertanyaan umum.
- ***Daily standup* tim proyek** — setiap pagi, selama *hypercare*, tim proyek berkumpul 15 menit untuk membahas masalah yang muncul kemarin dan prioritas hari ini. Kecepatan eskalasi menentukan apakah masalah kecil tetap kecil atau membesar menjadi krisis.
- **Eskalasi cepat ke vendor/developer** — masalah teknis yang tidak bisa diselesaikan tim internal harus sampai ke vendor dalam hitungan jam, bukan hari.
- **Perayaan *quick wins*** — tunjukkan bahwa SI baru bekerja. "Pak Andi berhasil memproses 50 transaksi hari ini tanpa error" — cerita seperti ini, di-*share* di grup internal, membangun *momentum* positif.

Setelah *hypercare*, SI memasuki fase stabilisasi — menjadi *Business As Usual*. Tetapi stabilisasi bukan berarti implementasi "selesai." *Continuous improvement* berdasarkan *feedback* pengguna, perubahan kebutuhan bisnis, dan peluang optimasi harus terus berjalan. Garis putus-putus di Gambar 13.1 — dari stabilisasi kembali ke perencanaan — menunjukkan bahwa implementasi SI adalah siklus, bukan proyek linier dengan titik akhir.

---

## 13.5 Komparasi

### Tabel 13.1 — Faktor Kritis Keberhasilan vs Kegagalan Implementasi SI: 8 Dimensi

| Dimensi | Implementasi Berhasil | Implementasi Gagal |
|---------|----------------------|-------------------|
| Sponsor eksekutif | Aktif, *visible*, konsisten sampai akhir | Pasif, delegasi penuh ke IT |
| *Change management* | Terintegrasi sejak perencanaan | *Afterthought* — "nanti saja" |
| Pelatihan | *Hands-on*, bertahap, dengan pendampingan | 1× *training* massal, selesai |
| Keterlibatan pengguna | Sejak desain konseptual | Baru dilibatkan saat UAT (terlambat) |
| Komunikasi | Transparan, menjelaskan "mengapa berubah" | *Top-down*, "lakukan saja" |
| Migrasi data | Dibersihkan, divalidasi, diuji | "*Copy paste*, perbaiki nanti" |
| *Support* pasca *go-live* | *Hypercare* 2–4 minggu, *help desk* khusus | "Hubungi *help desk* kalau ada masalah" |
| *Metric* keberhasilan | *User adoption*, *business outcome* | "Sistem sudah *live*" = selesai |

💡 **Insight:** Tujuh dari delapan dimensi di atas terkait manusia dan proses — hanya satu (migrasi data) yang bersifat teknis. Tabel ini mengilustrasikan mengapa implementasi SI lebih sering gagal karena faktor manusia: bukan karena faktor manusia "sulit," tetapi karena organisasi secara sistematis mengalokasikan lebih banyak perhatian dan anggaran ke teknologi dibandingkan ke manusia dan proses.

---

## 13.6 Realitas Lapangan

### Fenomena 1: e-KTP Indonesia — Kegagalan Sistemik Berskala Nasional

Proyek e-KTP dimulai tahun 2011 dengan tujuan menerbitkan KTP elektronik berbasis *chip* untuk seluruh WNI. Teknologi yang diadopsi bertaraf internasional: 10 *fingerprint*, *iris scan*, *chip* tersertifikasi, *database* terpusat di Kemendagri. Anggaran: Rp 5,9 triliun.

Masalah implementasi muncul bukan di *data center* Jakarta, melainkan di 7.000+ kecamatan yang menjadi titik perekaman:

- **Operator** — dilatih 3 hari untuk perangkat yang kompleks. *Turnover* tinggi: operator kontrak yang sudah terlatih sering diganti setelah masa kontrak berakhir, dan penggantinya belum terlatih.
- **Infrastruktur** — *scanner* biometrik sensitif terhadap suhu dan kelembaban. Di banyak kecamatan, perangkat sering *error*. Jaringan internet yang dibutuhkan untuk sinkronisasi data ke *server* pusat tidak stabil di luar Jawa.
- **Data** — migrasi dari KTP lama menghasilkan jutaan data duplikat. Satu orang bisa tercatat di dua kecamatan berbeda. Pembersihan data yang seharusnya dilakukan sebelum *go-live* baru dikerjakan *on-the-fly*.
- ***Governance*** — masalah pengadaan yang berujung kasus hukum menambah kompleksitas non-teknis.

💡 **Insight:** Proyek SI berskala nasional yang mendesain implementasi untuk kondisi ideal (jaringan stabil, operator kompeten, data bersih) akan selalu gagal di lapangan yang kondisinya jauh dari ideal. Implementasi harus dirancang untuk "mata rantai terlemah" — kecamatan dengan internet paling lambat, operator paling baru, dan perangkat paling tua.

### Fenomena 2: SAP Hershey (1999) vs SAP P&G (1999–2004)

Dua perusahaan FMCG (*Fast-Moving Consumer Goods*) global, teknologi yang sama (SAP), periode yang sama — tetapi *outcome* yang bertolak belakang:

**Hershey** memilih *big bang*: SAP, CRM, dan *supply chain management* di-*deploy* secara paralel dengan *go-live* September 1999 — satu bulan sebelum *peak season* Halloween dan Thanksgiving. Hasilnya: sistem *overloaded*, pesanan senilai $150 juta terlambat dikirim, penjualan kuartal turun 19%, dan harga saham turun 8%. Investigasi internal menemukan bahwa *change management* "hampir tidak ada" — karyawan diharapkan beradaptasi sendiri dengan sistem baru di tengah musim tersibuk.

**P&G** memilih *phased*: implementasi SAP dilakukan selama 5 tahun (1999–2004), *wave by region*. Setiap *wave* mencakup 6 bulan persiapan, 3 bulan *parallel run* (sistem lama dan baru berjalan bersamaan), dan 2 bulan *hypercare*. Tim *change management* berjumlah 200+ orang yang bergerak dari satu *wave* ke *wave* berikutnya. Hasilnya: efisiensi *supply chain* meningkat 35%, biaya inventori turun 22%.

💡 **Insight:** Hershey dan P&G menggunakan teknologi identik di industri yang sama. Perbedaan satu-satunya adalah strategi dan eksekusi implementasi. Hershey memperlakukan implementasi sebagai proyek IT — cepat dan efisien. P&G memperlakukan implementasi sebagai transformasi organisasi — *people first*, bertahap, dengan investasi besar di *change management*. Hasilnya berbicara sendiri.

### Fenomena 3: *Workaround Culture* Pasca Implementasi SI di Rumah Sakit

Studi terhadap 80 rumah sakit di Indonesia (2023) menemukan fenomena yang memprihatinkan: 45% perawat mengembangkan *workaround* untuk SI rekam medis elektronik yang baru diimplementasikan. Bentuk *workaround*: mencatat data pasien di kertas terlebih dahulu, baru menginput ke sistem di akhir *shift*; meminta staf administrasi yang "lebih jago IT" untuk menginputkan data mereka; atau hanya mengisi *field* wajib dan mengosongkan sisanya.

Dampaknya: data di SI tidak *real-time* (padahal ini tujuan utama implementasi), akurasi data menurun karena *transcription error* dari kertas ke sistem, dan manfaat yang dirancang — seperti *real-time patient monitoring* dan *automated drug interaction alert* — tidak berfungsi karena data yang masuk tidak lengkap dan tidak tepat waktu.

Akar masalahnya bukan perawat yang "anti teknologi." Interface SI dirancang oleh *developer* yang tidak memahami alur kerja keperawatan. *Input* data memerlukan 15 klik untuk satu tindakan yang di kertas hanya butuh 1 *checklist*. *Training* diberikan sekali saat peluncuran — perawat yang masuk setelahnya tidak mendapat pelatihan sama sekali.

💡 **Insight:** *Workaround culture* adalah sinyal bahwa implementasi belum berhasil — sistem ada, tetapi *adoption* belum terjadi. Manajer harus aktif mendeteksi *workaround* dan mendiagnosis akarnya: apakah SI perlu disederhanakan, apakah *training* perlu diulang dengan metode berbeda, atau apakah proses kerja perlu disesuaikan. Mengabaikan *workaround* sama dengan menerima bahwa investasi SI tidak menghasilkan nilai.

---

## 13.7 Salah Kaprah

⚠️ ***"Proyek SI gagal karena teknologinya, bukan karena manusianya"***

> Data Standish Group (2023) menunjukkan bahwa kurang dari 15% kegagalan proyek SI disebabkan faktor teknis murni. Sisanya — 85% — berakar pada faktor manusia dan organisasi: resistensi pengguna, *scope creep*, komunikasi yang buruk, sponsor eksekutif yang menghilang, dan pelatihan yang tidak memadai. Menyalahkan teknologi adalah *defense mechanism* organisasi — lebih mudah mengatakan "sistemnya jelek" daripada mengakui "kesiapan organisasi tidak memadai."
>
> **Koreksi:** Alokasikan minimal 20–30% anggaran implementasi untuk *change management* — komunikasi, pelatihan, *champion network*, dan *hypercare*. Jika seluruh anggaran habis untuk teknologi, implementasi sedang menyiapkan kegagalannya sendiri.

⚠️ ***"Pelatihan singkat sudah cukup untuk user adoption"***

> Satu hari *training* tidak mengubah kebiasaan kerja yang sudah terbentuk bertahun-tahun. *Forgetting curve* Ebbinghaus menunjukkan bahwa 70% materi pelatihan dilupakan dalam 24 jam tanpa *reinforcement*. Pelatihan massal di aula — 50 orang menonton presentasi — menghasilkan *awareness*, bukan *ability*. Pengguna keluar dari *training* dengan perasaan "sepertinya paham," tetapi saat kembali ke meja kerja keesokan harinya, mereka tidak ingat langkah ketiga dari prosedur yang diajarkan kemarin.
>
> **Koreksi:** Rancang pelatihan bertahap: (1) *Awareness session* — mengapa perubahan ini penting; (2) *Hands-on training* — praktik dengan data nyata, kelompok kecil; (3) *On-the-job coaching* — pendampingan di minggu pertama penggunaan; (4) *Refresher* — sesi ulang setelah 1 bulan. Sertai dengan *job aid* (*quick reference card*) dan akses ke *change champion*.

⚠️ ***"Manajer tidak perlu terlibat detail di implementasi — itu urusan IT"***

> Manajer adalah pemilik proses bisnis dan pemimpin tim yang akan menggunakan SI. Ketidakhadiran manajer di proses implementasi mengirim sinyal kuat ke seluruh tim: "SI ini bukan prioritas." Jika manajer tidak menghadiri *kick-off*, tidak menguji sistem sendiri, dan tidak menggunakan SI di rapat — timnya akan memprioritaskan hal lain.
>
> **Koreksi:** Manajer wajib *visible* di setiap tahap: hadir di *kick-off* dan *town hall*, menguji sistem secara langsung, menggunakan SI di rapat (bukan masih minta laporan dari *spreadsheet* lama), dan memberi apresiasi publik kepada *early adopter* di timnya.

⚠️ ***"Kalau sistemnya bagus, orang pasti mau pakai"***

> TAM model (Davis, 1989) menunjukkan bahwa *perceived usefulness* DAN *perceived ease of use* keduanya harus tinggi agar *adoption* terjadi. Sistem yang secara objektif "bagus" — fitur lengkap, performa cepat, *security* kuat — tetapi dipersepsikan pengguna sebagai "ribet" dan "tidak membantu pekerjaan saya" tidak akan diadopsi. Persepsi pengguna, bukan spesifikasi teknis, yang menentukan *adoption*.
>
> **Koreksi:** Libatkan pengguna sejak fase desain konseptual — bukan hanya saat UAT. Validasi bahwa SI mempermudah (bukan memperumit) pekerjaan mereka. Jika pengguna merasa "ini dibuat dengan masukan saya dan mempermudah pekerjaan saya," *adoption* meningkat secara alami.

---

## 13.8 Studi Kasus

### 📊 Studi Kasus Dasar — e-KTP: Kegagalan Implementasi Berskala Nasional

**❌ Kondisi Awal:**
Proyek e-KTP bertujuan menerbitkan KTP elektronik berbasis *chip* bagi seluruh WNI — 300+ juta penduduk. Teknologi biometrik yang diadopsi (10 *fingerprint* + *iris scan*) memenuhi standar internasional. Anggaran: Rp 5,9 triliun. Target *go-live*: 2014 untuk seluruh Indonesia.

**✅ Analisis dari Perspektif *People–Process–Technology*:**

### Tabel 13.3 — Evaluasi PPT Proyek e-KTP

| Dimensi | Kondisi | Evaluasi |
|---------|---------|----------|
| *People* | Operator kecamatan: *training* 3 hari, kontrak jangka pendek, *turnover* tinggi | ⚠️ Tidak memadai |
| *Process* | SOP perekaman berbeda per kabupaten, migrasi data lama tanpa pembersihan | ❌ Tidak standar |
| *Technology* | *Scanner* biometrik + *chip card* bertaraf internasional | ✅ Memadai |

Skor PPT: 1 dari 3 dimensi memadai — artinya implementasi berjalan dengan hanya mengandalkan kekuatan teknologi, tanpa fondasi *people* dan *process* yang solid.

Jika menggunakan model ADKAR:
- ***Awareness*** — rendah. Banyak penduduk dan operator tidak paham mengapa e-KTP diperlukan selain "diwajibkan."
- ***Desire*** — rendah di level operator. Beban kerja tinggi, insentif rendah, status kontrak tanpa jenjang karir.
- ***Knowledge*** — parsial. *Training* 3 hari untuk perangkat kompleks, tanpa *refresher*.
- ***Ability*** — rendah. Operator menghadapi perangkat sensitif, jaringan tidak stabil, dan antrian panjang tanpa *support* memadai.
- ***Reinforcement*** — tidak ada mekanisme *reinforcement* yang terstruktur.

💡 **Pelajaran:** e-KTP gagal bukan karena teknologinya — teknologinya justru satu-satunya dimensi yang memadai. Kegagalannya berada di *people* (operator tidak siap) dan *process* (SOP tidak standar, data tidak bersih). Proyek berskala nasional harus dirancang untuk kondisi terlemah di lapangan, bukan untuk kondisi ideal di pusat.

### 📊 Studi Kasus Lanjutan — SAP: Hershey vs Procter & Gamble

**❌ Hershey (1999) — *Big Bang* di Waktu Terburuk:**
Hershey mengimplementasikan SAP secara *big bang* — SAP R/3, CRM, dan *supply chain management* di-*deploy* bersamaan. *Go-live*: September 1999, satu bulan sebelum *peak season* Halloween dan Thanksgiving. Tidak ada *parallel run*, *change management* minimal, dan *hypercare* tidak direncanakan.

Hasilnya: sistem tidak mampu memproses volume pesanan *peak season*. Pesanan senilai $150 juta terlambat dikirim. *Revenue* kuartal turun 19%. Harga saham turun 8%.

**✅ P&G (1999–2004) — *Phased* dengan Investasi *Change Management*:**
P&G mengimplementasikan SAP selama 5 tahun, *wave by region*. Setiap *wave*: 6 bulan persiapan, 3 bulan *parallel run*, 2 bulan *hypercare*. Tim *change management* berjumlah 200+ orang yang bergerak antar *wave*.

### Tabel 13.4 — Kontras Implementasi Hershey vs P&G

| Dimensi | Hershey | P&G |
|---------|---------|-----|
| Strategi | *Big bang* (serentak) | *Phased* (5 tahun, per *region*) |
| *Timing go-live* | September — 1 bulan sebelum *peak* | *Off-peak* per *region* |
| *Change management* | Minimal, tidak terstruktur | 200+ *change agent* global |
| *Parallel run* | Tidak ada | 3 bulan per *wave* |
| *Hypercare* | Tidak direncanakan | 2 bulan per *wave* |
| *Outcome* Q1 pasca *go-live* | *Revenue* −19% | Efisiensi +12% |
| *Outcome* 3 tahun | *Recovery*, reputasi rusak | *Supply chain best-in-class* |

💡 **Pelajaran:** Teknologi yang sama, industri yang sama, periode yang sama — *outcome* bertolak belakang. Perbedaannya 100% di implementasi. Hershey memperlakukan SAP sebagai proyek IT yang harus cepat selesai. P&G memperlakukannya sebagai transformasi organisasi yang memerlukan waktu, investasi *people readiness*, dan *change management* yang serius. Implementasi SI bukan *sprint* — ia *marathon*.

---

## 13.9 Template Praktis

🔧 **Template A.13 — *Change Readiness Assessment***

```
TEMPLATE A.13 — CHANGE READINESS ASSESSMENT

Tanggal           : ________________________________________
Proyek SI         : ________________________________________
Asesor            : ________________________________________

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

A. PEOPLE READINESS

| Aspek                           | Skor (1–5) | Evidence          | Action Needed     |
|---------------------------------|-----------|-------------------|-------------------|
| Sponsor eksekutif aktif         | ___       | _________________ | _________________ |
| Manajer menengah mendukung      | ___       | _________________ | _________________ |
| Pengguna aware & willing        | ___       | _________________ | _________________ |
| Training plan tersedia          | ___       | _________________ | _________________ |
| Change champion teridentifikasi | ___       | _________________ | _________________ |

B. PROCESS READINESS

| Aspek                           | Skor (1–5) | Evidence          | Action Needed     |
|---------------------------------|-----------|-------------------|-------------------|
| Proses TO-BE sudah divalidasi   | ___       | _________________ | _________________ |
| SOP baru sudah disiapkan        | ___       | _________________ | _________________ |
| Data migration plan ada         | ___       | _________________ | _________________ |
| Rollback plan ada               | ___       | _________________ | _________________ |

C. TECHNOLOGY READINESS

| Aspek                           | Skor (1–5) | Evidence          | Action Needed     |
|---------------------------------|-----------|-------------------|-------------------|
| Infrastruktur siap              | ___       | _________________ | _________________ |
| UAT selesai & sign-off          | ___       | _________________ | _________________ |
| Integration tested              | ___       | _________________ | _________________ |
| Help desk ready                 | ___       | _________________ | _________________ |

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

TOTAL SKOR: ___/65

Interpretasi:
  50–65 : GO — siap implementasi
  35–49 : CONDITIONAL GO — perbaiki semua item dengan skor ≤ 2
  < 35  : NO-GO — tunda implementasi sampai readiness memadai

CATATAN & ACTION PLAN:
________________________________________________________
________________________________________________________
________________________________________________________
```

---

## 13.10 Peta Konsep

### Gambar 13.2 — Peta Konsep Implementasi SI

```mermaid
mindmap
  root((Implementasi SI))
    Mengapa Gagal
      Hanya 31% berhasil
      Faktor manusia 85%
      Resistensi pengguna
      Scope creep
      Sponsor hilang
    PPT Framework
      People — siap berubah?
      Process — sudah TO-BE?
      Technology — terakhir
    Change Management
      ADKAR Model
      Change Champion 1:25
      Komunikasi berkelanjutan
    Strategi Deploy
      Phased — risiko rendah
      Big Bang — risiko tinggi
      Pilot — validasi dulu
    Pasca Go-Live
      Hypercare 2–4 minggu
      Deteksi workaround
      Continuous improvement
```

---

## 13.11 Rangkuman

**Poin-poin Penting:**

1. Hanya 31% proyek SI berhasil (Standish Group, 2023) — dan 85% kegagalan berakar pada faktor manusia, bukan teknologi: resistensi pengguna, *scope creep*, sponsor eksekutif yang menghilang, dan pelatihan yang tidak memadai.

2. *Framework People–Process–Technology* harus diikuti urutannya. Pastikan orang siap dan mau berubah, proses bisnis sudah dirancang ulang ke TO-BE, baru *deploy* teknologi. Mengotomatisasi proses yang buruk hanya menghasilkan proses buruk yang lebih cepat.

3. Manajemen perubahan bukan *afterthought* — ia aktivitas paralel yang berjalan dari perencanaan hingga stabilisasi. Model ADKAR (*Awareness, Desire, Knowledge, Ability, Reinforcement*) memberikan kerangka operasional per individu.

4. Strategi *deployment* — *phased*, *big bang*, atau *pilot* — harus dipilih berdasarkan konteks organisasi, bukan preferensi. *Big bang* berisiko tinggi tetapi kadang diperlukan; *phased* lebih aman tetapi periode transisi lama; *pilot* cocok untuk validasi sebelum *rollout*.

5. *User adoption* adalah *ultimate metric* keberhasilan implementasi, bukan "sistem sudah *live*." *Change champion* dengan rasio 1:25 meningkatkan *adoption* dari 42% ke 78% (Prosci, 2024).

6. *Hypercare* 2–4 minggu pasca *go-live* menentukan apakah SI bertahan atau ditinggalkan. *Support* yang responsif membangun kepercayaan; *support* yang lambat membangun frustrasi.

7. *Workaround culture* adalah sinyal bahwa *adoption* belum terjadi — sistem ada, tetapi pengguna menemukan cara untuk menghindarinya. Manajer harus mendeteksi dan mengatasi *workaround*, bukan mengabaikannya.

---

**Menuju Bab 14:**

SI sudah dipilih, diimplementasikan, dan berjalan. Pertanyaan berikutnya dari *C-suite* pasti muncul: "Apakah investasi ini *worth it*?" Klaim bahwa SI meningkatkan efisiensi perlu dibuktikan — bukan dengan anggapan, melainkan dengan angka. Bab 14 membahas evaluasi kelayakan dan ROI SI: bagaimana membuktikan nilai bisnis investasi SI secara kuantitatif dan kualitatif, dan mengapa "tidak berinvestasi di SI" juga memiliki harga yang jarang dihitung.

---

🔥 *"Implementasi sistem informasi bukan tentang menyalakan server, tetapi tentang meyakinkan manusia untuk berpikir dan bekerja dengan cara yang berbeda."*

---

## 13.12 Latihan & Refleksi

### Pertanyaan Diagnostik

Implementasi SI selesai tepat waktu dan sesuai anggaran, tetapi tingkat adopsi pengguna rendah setelah *go-live*. Analisis kemungkinan sumber kegagalan pada *change management*, desain proses, pelatihan, *project governance*, dan kualitas solusi, indikator dini yang seharusnya telah muncul sebelum *go-live*, serta intervensi yang perlu diprioritaskan.

### Pertanyaan Reflektif

1. Pernahkah Anda mengalami implementasi SI yang gagal atau bermasalah — di kantor, kampus, atau layanan publik? Dengan menggunakan *framework* PPT, di dimensi mana kegagalannya paling terasa?

2. Mengapa manajer menengah disebut "*kingmaker* atau *dealbreaker*" implementasi SI? Berikan contoh konkret bagaimana sikap manajer menengah bisa memengaruhi *adoption* timnya.

3. Jika Anda harus mengimplementasikan SI baru di unit kerja Anda besok, tiga hal pertama apa yang akan Anda lakukan — dan mengapa urutan itu penting?

4. Apakah strategi *big bang* pernah *justified*? Diskusikan satu situasi di mana *big bang* mungkin merupakan pilihan terbaik meskipun risikonya tinggi.

### Latihan Artefak

**Latihan 13.1 — *Change Readiness Assessment* (Template A.13)**

Gunakan Template A.13 untuk mengevaluasi kesiapan implementasi SI di sebuah organisasi atau unit kerja yang Anda kenal.

Langkah:
1. Pilih satu proyek SI yang sedang atau akan diimplementasikan (atau gunakan skenario hipotetis berbasis pengalaman)
2. Isi seluruh aspek di tiga dimensi (*People*, *Process*, *Technology*) dengan skor 1–5 dan *evidence*
3. Hitung total skor dan tentukan interpretasi: GO / CONDITIONAL GO / NO-GO
4. Untuk setiap item dengan skor ≤ 2, rumuskan *action plan* spesifik dengan *timeline* dan penanggung jawab

**Kriteria *output* yang baik:**
- Skor didukung *evidence* konkret, bukan estimasi tanpa basis
- *Action plan* bersifat spesifik dan *actionable* — bukan "perlu diperbaiki" melainkan "training ulang 2 hari untuk 15 operator, penanggung jawab: Koordinator IT, target: minggu ke-2"
- Interpretasi konsisten dengan total skor — jika ada item skor 1 di *People Readiness*, interpretasi GO perlu justifikasi yang kuat

---

## Referensi

Ali, M., & Miller, L. (2021). ERP system implementation in large enterprises. *Journal of Enterprise Information Management*, *34*(1), 299–320.

Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. *MIS Quarterly*, *13*(3), 319–340.

Deloitte. (2023). *Digital transformation survey 2023*. Deloitte Global.

Kane, G. C., Phillips, A. N., Copulsky, J., & Andrus, G. (2022). *The transformation myth*. MIT Sloan Management Review.

Kotter, J. P. (2012). *Leading change* (New ed.). Harvard Business Review Press.

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

McKinsey & Company. (2022). *The state of digital transformations*. McKinsey Digital.

PMI. (2021). *A guide to the PMBOK Guide* (7th ed.). Project Management Institute.

Prosci. (2024). *ADKAR model: A change management methodology*. Prosci Inc.

Standish Group. (2023). *Chaos report 2023: Beyond infinity*. The Standish Group International.
