Program Studi Bisnis Digital • FEB

Perencanaan Sumber Daya Perusahaan

Pertemuan 6 — Siklus Hidup ERP: Tahap Implementasi

Dari paket terpilih menuju sistem berjalan: metodologi implementasi, big bang vs bertahap, migrasi data, pelatihan pengguna, dan mengapa banyak proyek ERP gagal di tahap ini.

RPS MINGGU 6 • 2×50 MENIT

Selamat pagi/siang, Anda semua. Minggu lalu kita sudah membahas bagaimana perusahaan merencanakan kebutuhan ERP dan memilih paket yang tepat — apakah SAP, Oracle, atau Odoo, misalnya. Hari ini kita masuk ke babak paling menegangkan dari siklus hidup ERP: tahap implementasi, yaitu proses mengubah paket software yang masih "kosong" menjadi sistem yang benar-benar berjalan dan dipakai karyawan sehari-hari. Bayangkan Anda baru saja membeli mobil baru — paket software sudah dibeli, tapi mobil itu belum ada bensinnya, belum disetel sesuai kebutuhan Anda, dan Anda belum tahu cara menyetirnya. Itulah yang terjadi di tahap implementasi. Kita akan belajar mengapa riset menunjukkan mayoritas proyek ERP mengalami keterlambatan atau pembengkakan biaya justru di tahap ini, dan apa yang bisa dilakukan agar organisasi Anda tidak menjadi bagian dari statistik itu.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menjelaskan tahap implementasi dalam siklus hidup ERP secara menyeluruh. Secara rinci:

CAPAIAN 1

METODOLOGI

Menjelaskan tahapan metodologi implementasi ERP dan peran konsultan implementasi.

CAPAIAN 2

STRATEGI GO-LIVE

Membandingkan strategi big bang, bertahap (phased), dan paralel.

CAPAIAN 3

MIGRASI DATA

Menjelaskan proses migrasi data (extract-transform-load) dan risikonya.

CAPAIAN 4

FAKTOR GAGAL

Mengidentifikasi faktor kritis keberhasilan dan penyebab umum kegagalan proyek ERP.

Kenapa Tahap Ini Paling Berisiko?

Paket ERP sudah dibeli. Tapi survei tahunan Panorama Consulting (konsultan ERP global) terhadap ratusan perusahaan menunjukkan pola yang konsisten setiap tahun:

DURASI

~60%

proyek ERP molor dari jadwal awal yang direncanakan.

ANGGARAN

~50%

proyek melampaui anggaran yang disepakati di kontrak.

MANFAAT

SEBAGIAN

organisasi hanya merasakan sebagian manfaat yang dijanjikan vendor.

Angka persisnya berubah tiap edisi survei (hedge: ~) — tapi polanya konsisten selama satu dekade terakhir: tahap implementasi, bukan pemilihan paket, adalah titik kegagalan paling umum.

Coba bayangkan Anda adalah manajer proyek di sebuah perusahaan retail sekelas Indomaret yang baru membeli ERP senilai puluhan miliar rupiah. Software-nya sudah dibayar, kontrak sudah ditandatangani — tapi enam bulan kemudian proyek masih belum selesai, biaya konsultan membengkak, dan karyawan gudang masih bingung cara input transaksi. Ini bukan skenario fiksi; ini pola yang berulang di banyak organisasi nyata, dan itulah sebabnya survei tahunan seperti dari Panorama Consulting selalu menyorot tahap implementasi sebagai fase paling kritis. Angka-angka di slide ini saya beri tanda kira-kira, karena persisnya berubah setiap edisi survei, tetapi arah temuannya konsisten. Pertanyaannya untuk kita hari ini bukan "apakah implementasi ERP berisiko", tapi "bagaimana mengelola risikonya secara sistematis" — itulah yang akan kita bahas.

Bagian 1 dari 4

Posisi Implementasi dalam Siklus Hidup ERP

Dari perencanaan & pemilihan paket, menuju implementasi, lalu operasi & pemeliharaan — memetakan di mana kita berada hari ini.

Tiga Tahap Besar Siklus Hidup ERP

Implementasi adalah jembatan antara keputusan strategis (paket apa yang dibeli) dan penggunaan sehari-hari (sistem yang benar-benar dipakai).

Fokus hari ini: apa yang terjadi di dalam kotak tengah — dari paket ERP yang masih generik hingga sistem yang siap dipakai seluruh perusahaan.

Diagram ini menunjukkan tiga kotak berurutan. Kotak pertama, perencanaan dan pemilihan, sudah kita lewati — di sana perusahaan menganalisis kebutuhan dan memilih vendor, misalnya antara SAP S/4HANA, Oracle NetSuite, atau Odoo untuk UMKM. Kotak tengah yang lebih besar dan gelap adalah implementasi, tahap yang kita bahas hari ini — di sinilah paket generik itu dikonfigurasi, data lama dipindahkan, karyawan dilatih, hingga sistem akhirnya "go-live" alias mulai dipakai sungguhan. Kotak ketiga, operasi dan pemeliharaan, adalah masa hidup sistem sehari-hari setelah go-live, termasuk perbaikan bug dan upgrade — itu akan kita bahas minggu depan. Perhatikan bahwa kotak tengah sengaja saya gambar lebih besar dan gelap, karena secara riil inilah tahap yang paling memakan waktu, biaya, dan tenaga dalam seluruh siklus hidup ERP.

Apa Itu "Implementasi ERP"?

Implementasi ERP adalah proses mengubah paket software generik yang dibeli dari vendor menjadi sistem operasional yang sesuai proses bisnis spesifik organisasi Anda.

Analogi Sederhana

Software ERP = rumah kosong yang baru dibeli dari pengembang — struktur sudah ada, tapi belum ada perabot dan belum disetel sesuai kebutuhan penghuni.
Implementasi = proses mengecat, memasang perabot, menyambung listrik-air, dan memindahkan barang lama Anda ke rumah baru.
Go-live = hari pertama Anda benar-benar tinggal dan beraktivitas di rumah itu.

Istilah kunci: konfigurasi (configuration) = menyetel opsi bawaan sistem tanpa mengubah kode program — beda dengan kustomisasi (customization) yang mengubah kode, dan sudah kita bahas di pertemuan sebelumnya.

Metodologi Implementasi: Lima Tahap Umum

Vendor besar (SAP Activate, Oracle AIM, Microsoft Sure Step) punya nama berbeda, tapi kerangka intinya serupa:

Konsultan implementasi (mis. tim dari Accenture atau Soltius, partner resmi SAP di Indonesia) biasanya mendampingi tahap 2–5 secara intensif.

Setiap vendor ERP besar punya nama metodologi sendiri — SAP menyebutnya SAP Activate, Oracle punya AIM, Microsoft punya Sure Step — tapi kalau kita bandingkan, kerangka intinya hampir selalu sama, lima tahap seperti di layar ini. Tahap pertama, persiapan, adalah membentuk tim proyek dan menyepakati ruang lingkup. Tahap kedua, analisis dan desain, adalah memetakan bagaimana proses bisnis perusahaan akan berjalan di sistem baru — dokumennya sering disebut "blueprint". Tahap ketiga, konfigurasi dan build, adalah eksekusi teknis: menyetel sistem dan memindahkan data. Tahap keempat, pengujian, melibatkan user acceptance testing atau UAT, di mana calon pengguna sungguhan mencoba sistem sebelum dipakai resmi. Tahap kelima, go-live, adalah momen sistem lama dimatikan dan sistem baru mulai dipakai penuh — di Indonesia, perusahaan besar sering menyewa konsultan implementasi seperti Accenture atau partner lokal SAP untuk mendampingi proses ini karena kompleksitasnya tinggi.

Siapa Saja di Tim Proyek Implementasi?

Implementasi ERP bukan proyek IT semata — butuh kolaborasi lintas fungsi.

SPONSOR PROYEK

EKSEKUTIF

Direksi/CFO yang memberi mandat & anggaran, menyelesaikan konflik antar-departemen.

KEY USER

PENGGUNA KUNCI

Karyawan tiap departemen (keuangan, gudang, penjualan) yang tahu proses harian sungguhan.

KONSULTAN

IMPLEMENTOR

Ahli teknis dari vendor/partner yang melakukan konfigurasi & migrasi.

Kesalahan umum: perusahaan menyerahkan proyek sepenuhnya ke tim IT tanpa melibatkan key user — akibatnya sistem "benar secara teknis" tapi tidak sesuai cara kerja nyata karyawan.

Salah satu kesalahpahaman terbesar mahasiswa baru soal ERP adalah menganggap ini murni proyek departemen IT. Padahal tim proyek implementasi yang sehat selalu melibatkan tiga pihak ini secara seimbang. Sponsor proyek biasanya direktur keuangan atau bahkan direktur utama — perannya memberi mandat, menyediakan anggaran, dan menjadi penengah kalau ada konflik kepentingan antar-departemen, misalnya saat tim penjualan dan tim gudang berbeda pendapat soal alur pemesanan. Key user adalah karyawan biasa di lapangan — staf akuntansi, staf gudang, staf penjualan — yang justru paling tahu detail proses harian sesungguhnya, bukan seperti yang ditulis di prosedur formal. Konsultan implementor adalah pihak teknis dari vendor atau partner resmi yang mengeksekusi konfigurasi. Kalau perusahaan seperti sebuah startup e-commerce menyerahkan seluruh proyek ke tim IT saja tanpa melibatkan staf gudang sebagai key user, hasilnya sering sistem yang "benar" secara teknis tapi menyulitkan pemakaian sehari-hari.

Bagian 2 dari 4

Strategi Go-Live: Big Bang vs Bertahap vs Paralel

Keputusan paling strategis dalam implementasi: bagaimana caranya beralih dari sistem lama ke sistem baru.

Tiga Strategi Go-Live

Pilihan ini menentukan seberapa besar risiko yang ditanggung organisasi saat beralih ke sistem baru.

BIG BANG

SERENTAK

Seluruh modul & lokasi beralih di satu tanggal. Cepat, tapi risiko tinggi.

PHASED

BERTAHAP

Modul/lokasi beralih satu per satu secara berurutan. Risiko lebih terkendali.

PARALLEL

PARALEL

Sistem lama & baru berjalan bersamaan sementara waktu untuk verifikasi.

Tidak ada strategi yang "selalu terbaik" — pilihannya tergantung ukuran organisasi, toleransi risiko, dan kompleksitas proses bisnis.

Bayangkan tiga cara berbeda untuk pindah rumah. Big bang seperti pindah dalam satu hari — semua barang diangkut sekaligus, rumah lama langsung ditinggalkan. Cepat selesai, tapi kalau ada barang yang lupa terangkut atau rusak di jalan, Anda tidak punya "cadangan" untuk kembali. Strategi phased atau bertahap seperti memindahkan barang kamar per kamar selama beberapa minggu — lebih lama, tapi jauh lebih terkendali risikonya karena Anda bisa evaluasi tiap tahap sebelum lanjut. Strategi paralel seperti tetap tinggal di rumah lama sambil mencicil menata rumah baru, baru pindah total setelah yakin semuanya berfungsi — paling aman tapi paling mahal karena Anda membayar dua rumah sekaligus. Perusahaan retail besar dengan ratusan cabang, misalnya jaringan minimarket seperti Alfamart, hampir selalu memilih strategi bertahap per wilayah, bukan big bang nasional, justru karena skala risikonya terlalu besar untuk ditanggung sekaligus.

Kapan Memilih Strategi Mana?

Perbandingan Trade-off

Strategi	Kecepatan	Risiko	Biaya Transisi	Cocok Untuk
Big Bang	Tercepat	Tertinggi	Rendah	Organisasi kecil, proses sederhana
Bertahap	Sedang	Terkendali	Sedang	Organisasi besar, multi-cabang
Paralel	Terlambat	Terendah	Tertinggi	Sistem kritis (mis. perbankan)

Rule of thumb: makin besar konsekuensi kalau sistem baru gagal (mis. bank, rumah sakit), makin layak strategi paralel dipilih meski lebih mahal.

Tabel ini merangkum trade-off yang perlu Anda pertimbangkan sebagai calon konsultan atau manajer proyek. Big bang paling cepat dan paling murah biaya transisinya, tapi risikonya paling tinggi karena tidak ada jaring pengaman — begitu sistem baru dinyalakan, sistem lama langsung dimatikan. Strategi bertahap menyeimbangkan kecepatan dan risiko, cocok untuk organisasi besar dengan banyak cabang seperti jaringan ritel atau bank dengan ratusan kantor cabang, di mana Anda bisa uji coba di satu wilayah dulu sebelum ekspansi. Strategi paralel paling aman karena kedua sistem berjalan bersamaan sehingga hasil bisa dibandingkan, tapi paling mahal dan paling lama karena staf harus mengerjakan input data dua kali. Aturan praktisnya sederhana: kalau sistem yang gagal bisa berakibat fatal — bayangkan sistem inti perbankan atau sistem rumah sakit — biaya ekstra strategi paralel jauh lebih murah dibanding risiko kegagalan totalnya.

Migrasi Data: Jantung Teknis Implementasi

Data lama perusahaan (Excel, sistem legacy) harus dipindahkan ke ERP baru lewat proses ETL (Extract–Transform–Load).

Risiko terbesar: data duplikat, tidak lengkap, atau format tak konsisten (mis. nomor telepon pelanggan ditulis beda-beda) — kalau tidak dibersihkan dulu, sistem baru mewarisi "kotoran" data lama.

Migrasi data sering disebut sebagai jantung teknis dari implementasi karena di sinilah pekerjaan paling detail dan paling berisiko human error terjadi. Prosesnya mengikuti tiga langkah yang disebut ETL — extract, transform, load. Extract berarti menarik keluar data dari sistem lama, misalnya ribuan baris data pelanggan yang selama ini tersimpan di file Excel terpisah-pisah di tiap cabang. Transform berarti membersihkan dan menyesuaikan format data itu supaya cocok dengan struktur ERP baru — misalnya menyeragamkan format nomor telepon yang tadinya ditulis campur aduk, ada yang pakai 08, ada yang pakai +62. Load berarti akhirnya memasukkan data bersih itu ke dalam sistem ERP. Bayangkan sebuah UMKM fesyen online yang selama bertahun-tahun mencatat stok barang di banyak file Excel berbeda dengan format tak konsisten — kalau data ini langsung dipindah tanpa dibersihkan dulu, sistem ERP baru yang mahal itu justru akan berisi data stok yang kacau sejak hari pertama.

Hitung dari Nol: Estimasi Beban Kerja Migrasi Data

Kasus: sebuah distributor FMCG (barang konsumsi bergerak cepat) skala menengah punya 12.000 baris data pelanggan yang perlu dimigrasi. Tim menemukan 15% baris bermasalah (duplikat/tidak lengkap) saat tahap transform, dan kecepatan pembersihan tim adalah 200 baris/jam per staf dengan 3 staf bekerja paralel.

Langkah	Perhitungan	Nilai
1. Baris bermasalah	15% × 12.000	1.800 baris
2. Total jam-kerja pembersihan	1.800 ÷ 200 baris/jam	9 jam-kerja
3. Jam-kerja per staf (3 staf paralel)	9 ÷ 3	3 jam/staf
4. Hari kerja dibutuhkan (8 jam/hari, 1 staf setara)	3 jam ÷ 8 jam/hari	≈ 0,4 hari

HASIL

≈ 0,4 HARI

waktu pembersihan data bermasalah dengan 3 staf paralel

Mari kita hitung bersama, langkah demi langkah, seperti seorang manajer proyek yang menyusun estimasi jadwal. Langkah pertama, kita cari berapa baris data yang benar-benar bermasalah: 15 persen dikali 12.000 baris sama dengan 1.800 baris yang perlu dibersihkan manual. Langkah kedua, kita ubah itu menjadi total jam kerja: 1.800 baris dibagi kecepatan 200 baris per jam per staf, hasilnya 9 jam-kerja total. Langkah ketiga, karena ada 3 staf bekerja paralel, kita bagi 9 jam itu dengan 3, hasilnya 3 jam per staf. Langkah keempat, kita konversi ke hari kerja dengan asumsi 8 jam kerja sehari, hasilnya sekitar 0,4 hari saja. Perhatikan bagaimana angka yang tadinya terlihat menakutkan — 1.800 baris bermasalah — ternyata bisa diselesaikan kurang dari setengah hari kalau tim bekerja paralel dan efisien; inilah pentingnya estimasi kuantitatif sebelum menyusun jadwal proyek, bukan sekadar menebak-nebak.

Coba Sendiri: Estimasi Beban Migrasi Data Anda

Ubah jumlah baris data, persentase baris bermasalah, kecepatan pembersihan, dan jumlah staf, lalu amati bagaimana estimasi hari kerja berubah.

Bagian 3 dari 4

Pelatihan Pengguna & Manajemen Perubahan

Sistem tercanggih pun gagal kalau karyawan tidak siap atau menolak memakainya.

Pelatihan Pengguna: Tiga Lapisan

Pelatihan bukan acara sekali jalan — perlu berlapis sesuai peran pengguna.

LAPIS 1

TRAIN-THE-TRAINER

Konsultan melatih key user secara mendalam untuk tiap modul.

LAPIS 2

END-USER TRAINING

Key user meneruskan pelatihan ke karyawan operasional harian.

LAPIS 3

DUKUNGAN PASCA GO-LIVE

Help desk & dokumentasi untuk minggu-minggu awal pemakaian.

Model "train-the-trainer" lebih efisien biaya daripada konsultan melatih ratusan karyawan satu per satu — key user jadi "penerjemah" antara sistem dan rekan kerjanya.

Pelatihan yang efektif hampir selalu berlapis tiga, bukan sekadar satu sesi workshop sehari. Lapis pertama disebut train-the-trainer — konsultan implementasi melatih key user secara mendalam untuk modul yang jadi tanggung jawabnya, misalnya staf senior akuntansi dilatih detail modul finance. Lapis kedua, end-user training, di mana key user tadi meneruskan pelatihan itu ke rekan-rekan kerjanya yang memakai sistem sehari-hari — ini lebih efisien biaya karena konsultan mahal tidak perlu melatih ratusan karyawan satu per satu. Lapis ketiga adalah dukungan pasca go-live, biasanya berupa help desk internal dan dokumentasi tertulis, karena minggu-minggu pertama setelah sistem baru dinyalakan selalu penuh pertanyaan dan kebingungan kecil. Bayangkan sebuah perusahaan distribusi dengan 200 karyawan gudang di berbagai kota — model train-the-trainer memungkinkan hanya 10 key user yang dilatih intensif oleh konsultan, lalu mereka yang menyebarkan ke 190 rekan lainnya di lapangan.

Manajemen Perubahan: Mengapa Karyawan Menolak?

Resistensi terhadap ERP baru bukan soal teknologi — hampir selalu soal manusia dan kebiasaan.

Sumber Resistensi Umum

Takut kehilangan pekerjaan (otomatisasi tugas manual)
Cara kerja lama terasa "lebih cepat" karena sudah terbiasa
Kurang dilibatkan sejak tahap desain (bukan cuma dilatih di akhir)
Tidak melihat manfaat langsung untuk pekerjaannya sendiri

Mitigasi yang Terbukti Efektif

Libatkan key user sejak tahap desain, bukan hanya pelatihan
Komunikasi rutin dari sponsor eksekutif soal alasan perubahan
"Quick win" — tunjukkan manfaat nyata di minggu-minggu awal
Dukungan intensif di masa transisi (bukan dilepas begitu saja)

Ini adalah salah satu pelajaran paling penting dalam mata kuliah kita: kegagalan proyek ERP jauh lebih sering disebabkan faktor manusia daripada faktor teknis. Di sisi kiri, kita lihat sumber-sumber resistensi yang umum — karyawan bisa takut kehilangan pekerjaan kalau tugas manual mereka diotomatisasi sistem, atau merasa cara kerja lama sudah nyaman meski sebenarnya kurang efisien, atau yang paling sering, mereka tidak pernah dilibatkan sejak tahap perencanaan sehingga sistem baru terasa "dipaksakan" dari atas. Di sisi kanan, kita lihat mitigasi yang terbukti efektif menurut riset manajemen perubahan — melibatkan key user sejak tahap desain membuat mereka merasa memiliki sistem itu, bukan sekadar korban perubahan. Sponsor eksekutif yang rutin berkomunikasi soal alasan di balik perubahan juga penting, karena karyawan lebih menerima perubahan kalau paham alasannya. Bayangkan divisi keuangan sebuah BUMN yang terbiasa memakai spreadsheet selama 15 tahun — resistensi mereka terhadap ERP baru bisa diredam signifikan kalau sejak awal mereka dilibatkan menentukan bagaimana laporan baru akan terlihat.

Hitung dari Nol: Estimasi Biaya Pelatihan Karyawan

Kasus: perusahaan manufaktur menengah punya 150 end-user yang perlu dilatih. Biaya pelatihan per karyawan Rp 350.000 (materi + konsumsi + waktu instruktur internal). Perusahaan mendapat diskon volume 8% dari total biaya karena melatih dalam satu paket dengan penyedia modul e-learning internal.

Langkah	Perhitungan	Nilai
1. Biaya dasar total	150 × Rp 350.000	Rp 52.500.000
2. Nilai diskon volume	8% × Rp 52.500.000	Rp 4.200.000
3. Biaya bersih pelatihan	Rp 52.500.000 − Rp 4.200.000	Rp 48.300.000
4. Biaya efektif per karyawan	Rp 48.300.000 ÷ 150	Rp 322.000

HASIL

Rp 48,3 JUTA

total biaya bersih pelatihan 150 karyawan

Mari kita hitung anggaran pelatihan langkah demi langkah, sesuatu yang akan sering Anda lakukan sebagai calon analis proyek ERP. Langkah pertama, kita hitung biaya dasar sebelum diskon: 150 karyawan dikali Rp 350.000 per orang sama dengan Rp 52,5 juta. Langkah kedua, kita hitung nilai diskon volume yang diberikan penyedia: 8 persen dikali Rp 52,5 juta sama dengan Rp 4,2 juta. Langkah ketiga, kita kurangi biaya dasar dengan nilai diskon itu untuk mendapat biaya bersih: Rp 52,5 juta dikurangi Rp 4,2 juta sama dengan Rp 48,3 juta. Langkah keempat, untuk keperluan pelaporan ke manajemen, kita hitung biaya efektif per karyawan: Rp 48,3 juta dibagi 150 orang, hasilnya Rp 322.000 per karyawan. Angka-angka seperti ini penting Anda kuasai karena setiap proposal anggaran proyek ERP yang diajukan ke direksi harus bisa menjustifikasi setiap rupiah, termasuk komponen pelatihan yang sering dianggap remeh padahal krusial bagi keberhasilan proyek.

Bagian 4 dari 4

Faktor Kritis Keberhasilan & Studi Kasus

Merangkum apa yang membedakan proyek ERP yang berhasil dari yang gagal — lalu berlatih menganalisis kasus nyata.

Faktor Kritis Keberhasilan Implementasi ERP

Lima Faktor yang Konsisten Muncul di Riset

Faktor	Mengapa Penting
Dukungan manajemen puncak	Anggaran & keputusan cepat saat ada konflik antar-divisi
Manajemen ruang lingkup	Mencegah "scope creep" — penambahan fitur tanpa henti
Kualitas data sejak awal	Data kotor yang bermigrasi = keputusan bisnis keliru
Pelatihan & keterlibatan pengguna	Sistem hanya berguna jika benar-benar dipakai
Tim proyek lintas fungsi	Menjamin sistem sesuai proses bisnis riil, bukan cuma teori

Slide ini merangkum lima faktor yang berulang kali muncul di berbagai riset akademik dan laporan konsultan tentang keberhasilan implementasi ERP di seluruh dunia, termasuk di Indonesia. Dukungan manajemen puncak berarti direksi harus benar-benar berkomitmen, bukan sekadar menandatangani anggaran lalu menghilang — karena konflik antar-divisi pasti muncul dan butuh keputusan cepat dari level atas. Manajemen ruang lingkup mencegah fenomena yang disebut "scope creep", di mana permintaan fitur tambahan terus mengalir tanpa henti sehingga proyek tak kunjung selesai — ini penyebab umum proyek molor yang kita bahas di awal kelas. Kualitas data sejak awal sudah kita bahas mendalam di slide migrasi data tadi. Pelatihan dan keterlibatan pengguna sudah kita bahas di bagian tiga. Tim proyek lintas fungsi memastikan sistem dirancang sesuai kenyataan lapangan, bukan asumsi konsultan semata. Kalau kelak Anda ditugaskan mengevaluasi sebuah proyek ERP — di tugas akhir atau di dunia kerja — lima faktor inilah kerangka checklist yang bisa Anda pakai.

Diskusi Kelas: Kasus PT Nusantara Boga

Skenario Singkat

PT Nusantara Boga, produsen makanan olahan skala menengah dengan 3 pabrik di Jawa, mengimplementasikan ERP dengan strategi big bang di seluruh pabrik sekaligus untuk menghemat biaya konsultan. Tim IT menyusun jadwal migrasi data hanya 2 minggu tanpa melibatkan staf gudang. Karyawan gudang menerima pelatihan 1 hari sebelum go-live. Tiga minggu setelah go-live, laporan stok di sistem sering tidak cocok dengan stok fisik.

DISKUSI 1

IDENTIFIKASI

Faktor kritis keberhasilan mana saja yang diabaikan PT Nusantara Boga? Kaitkan ke slide sebelumnya.

DISKUSI 2

REKOMENDASI

Strategi go-live apa yang lebih tepat untuk kasus ini, dan mengapa?

Sekarang giliran Anda berlatih menerapkan seluruh konsep yang kita bahas hari ini pada satu kasus. Silakan berdiskusi dalam kelompok kecil selama beberapa menit, lalu kita bahas bersama di kelas. Perhatikan detail-detail di skenario ini dengan cermat — strategi big bang di tiga pabrik sekaligus, jadwal migrasi data yang sangat singkat hanya dua minggu, staf gudang yang tidak dilibatkan, dan pelatihan yang hanya satu hari. Semua detail itu sengaja saya masukkan karena masing-masing berkaitan langsung dengan faktor kritis keberhasilan yang baru saja kita pelajari. Cobalah petakan setiap kesalahan PT Nusantara Boga ke salah satu dari lima faktor kritis di slide sebelumnya, lalu pikirkan strategi go-live alternatif yang lebih sesuai untuk perusahaan manufaktur dengan tiga lokasi pabrik seperti ini.

Rangkuman: Peta Implementasi ERP

Elemen	Poin Kunci
Definisi implementasi	Mengubah paket generik menjadi sistem operasional sesuai proses bisnis
Metodologi	Persiapan → Analisis-Desain → Konfigurasi-Build → Pengujian → Go-Live
Strategi go-live	Big bang (cepat, berisiko) · Bertahap (seimbang) · Paralel (aman, mahal)
Migrasi data	ETL: Extract → Transform → Load; risiko utama = data kotor
Pelatihan	Berlapis: train-the-trainer → end-user → dukungan pasca go-live
Kegagalan proyek	Lebih sering karena faktor manusia (resistensi) daripada teknologi

Slide ini adalah cheat sheet yang bisa Anda pakai untuk mengulang materi sebelum ujian. Semua elemen di tabel ini saling berkaitan sebagai satu rangkaian: implementasi dimulai dari definisi dasarnya, dijalankan lewat metodologi lima tahap, dengan keputusan strategis soal cara go-live, dieksekusi lewat migrasi data yang hati-hati, didukung pelatihan berlapis, dan semuanya dibayangi oleh risiko kegagalan yang justru paling sering berasal dari faktor manusia, bukan teknologi. Saya sarankan Anda menutup slide ini, lalu coba jelaskan tiap baris dengan kata-kata Anda sendiri tanpa melihat catatan — kalau bisa, berarti Anda sudah menguasai materi pertemuan keenam ini dengan baik. Ingat juga studi kasus PT Nusantara Boga tadi sebagai contoh konkret bagaimana mengabaikan faktor-faktor ini berakibat nyata pada operasional perusahaan.

Lima Kesalahan Umum yang Harus Dihindari

KESALAHAN 1

RUANG LINGKUP MELEBAR

Menambah fitur/modul di tengah proyek tanpa evaluasi ulang jadwal & biaya.

KESALAHAN 2

DATA TAK DIBERSIHKAN

Memigrasi data lama apa adanya tanpa proses transform yang memadai.

KESALAHAN 3

PELATIHAN TERBURU-BURU

Menganggap pelatihan 1 sesi singkat sudah cukup untuk sistem kompleks.

KESALAHAN 4

MENGABAIKAN KEY USER

Mendesain sistem tanpa melibatkan pengguna yang paham proses harian.

Kesalahan ke-5: tergesa-gesa go-live demi memenuhi target kalender, padahal UAT (user acceptance test) belum tuntas.

Slide ini adalah rangkuman peringatan praktis — semacam daftar hal yang tidak boleh Anda lakukan kalau kelak menjadi bagian tim proyek ERP. Kesalahan pertama, ruang lingkup yang terus melebar tanpa evaluasi ulang, adalah pembunuh anggaran nomor satu di banyak proyek. Kesalahan kedua, data yang tidak dibersihkan, akan membuat laporan manajemen keliru sejak hari pertama sistem berjalan. Kesalahan ketiga, pelatihan terburu-buru, membuat karyawan panik dan frustrasi begitu sistem live. Kesalahan keempat, mengabaikan key user, membuat sistem "benar di atas kertas" tapi menyulitkan di lapangan — ingat kembali kasus PT Nusantara Boga tadi. Dan kesalahan kelima yang saya tambahkan di callout, tergesa-gesa go-live hanya demi mengejar target kalender proyek meski pengujian penerimaan pengguna atau UAT belum selesai, adalah kombinasi paling berbahaya karena menggabungkan risiko teknis dan risiko manusia sekaligus.

Latihan Mandiri: Cek Pemahaman Anda

Kerjakan Sebelum Pertemuan Berikutnya

Sebutkan lima tahap metodologi implementasi ERP secara berurutan beserta output utamanya.
Jika Anda adalah manajer proyek di perusahaan retail dengan 50 cabang, strategi go-live apa yang Anda rekomendasikan? Jelaskan alasannya dalam 3-4 kalimat.
Jelaskan mengapa migrasi data yang tidak dibersihkan bisa berdampak pada keputusan bisnis, beri satu contoh konkret.
Sebutkan minimal 3 dari 5 faktor kritis keberhasilan implementasi ERP.

Bawa jawaban Anda ke pertemuan berikutnya — kita akan bahas singkat sebelum masuk topik operasi & pemeliharaan ERP.

Sebelum kita menutup pertemuan hari ini, saya ingin Anda mengerjakan empat pertanyaan reflektif ini secara mandiri di rumah, bukan sekadar dibaca sekilas. Pertanyaan pertama menguji apakah Anda hafal urutan metodologi implementasi beserta output di tiap tahapnya — ini fondasi yang akan terus dipakai di pertemuan-pertemuan berikutnya. Pertanyaan kedua mengajak Anda berpikir sebagai praktisi sungguhan: bayangkan Anda benar-benar menjadi manajer proyek di perusahaan retail seperti Alfamart atau Indomaret dengan puluhan cabang, strategi mana yang masuk akal dan mengapa. Pertanyaan ketiga menguji pemahaman Anda tentang konsekuensi migrasi data yang buruk terhadap keputusan bisnis nyata. Pertanyaan keempat menguji ingatan Anda soal lima faktor kritis keberhasilan. Kerjakan dengan jujur tanpa membuka catatan dulu, baru cocokkan jawaban Anda dengan slide rangkuman tadi — cara ini jauh lebih efektif untuk mengingat materi jangka panjang dibanding sekadar membaca ulang.

Sebelum Pertemuan Berikutnya

Minggu Depan: Operasi & Pemeliharaan ERP

Apa yang terjadi setelah go-live: dukungan harian, patch, upgrade
Total Cost of Ownership (TCO) jangka panjang sistem ERP
Kapan perusahaan perlu upgrade vs bertahan di versi lama

TUGAS

4 SOAL REFLEKTIF

Selesaikan latihan mandiri di slide sebelumnya sebagai bekal diskusi pembuka minggu depan.

Anda sekarang memahami bagaimana paket ERP "kosong" berubah menjadi sistem berjalan — fondasi penting sebelum kita masuk ke modul-modul fungsional ERP di paruh kedua semester.

Sampai di sini, kita sudah menuntaskan pembahasan tahap implementasi dalam siklus hidup ERP secara menyeluruh — dari metodologi lima tahap, strategi go-live, migrasi data, pelatihan pengguna, hingga faktor kritis keberhasilan. Minggu depan kita akan melanjutkan ke tahap terakhir siklus hidup ERP, yaitu operasi dan pemeliharaan: apa yang terjadi setelah sistem live dan dipakai bertahun-tahun, termasuk konsep total cost of ownership dan kapan waktu yang tepat untuk upgrade sistem. Jangan lupa kerjakan empat pertanyaan reflektif di slide sebelumnya sebagai bekal diskusi pembuka pertemuan berikutnya. Terima Kasih atas partisipasi aktif Anda hari ini — pemahaman tentang tahap implementasi ini adalah fondasi penting sebelum kita mendalami modul-modul fungsional ERP seperti financial management dan supply chain management di paruh kedua semester.