BAB 13 - Implementasi Sistem Informasi

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

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

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. Selisih 36 poin persentase itu berbicara sendiri: investasi dalam champion network - identifikasi, pelatihan, dukungan, pengakuan - memberikan ROI yang jauh melebihi biayanya dalam 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

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

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

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

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.