Program Studi Bisnis Digital • FEB UNDIP

Perencanaan Sumber Daya Perusahaan

Pertemuan 3 — ERP dan Desain Ulang Proses Bisnis: Business Process Reengineering, Faktor Keberhasilan, Stakeholder Transformasi

Mengapa sekadar memasang software ERP tidak cukup — proses bisnis lama harus didesain ulang lebih dahulu, dan manusia di dalamnya harus dikelola perubahannya.

RPS MINGGU 3 • 2×50 MENIT

Selamat pagi/siang, Anda semua. Minggu lalu kita sudah kenalan dengan konsep dasar ERP — apa itu, manfaat dan kelemahannya, serta evolusinya dari MRP sampai sistem modern. Hari ini kita masuk ke satu pertanyaan yang sering dilupakan orang saat perusahaan membeli ERP mahal: kalau proses bisnisnya masih berantakan, apakah software secanggih apa pun bisa menolong? Jawabannya tidak — dan itulah kenapa hari ini kita bahas Business Process Reengineering atau BPR, desain ulang proses bisnis secara radikal, sebelum proses itu "dikunci" ke dalam sistem ERP. Kita juga akan bahas siapa saja stakeholder yang harus dikelola dalam transformasi ini, dan faktor apa yang membuat proyek BPR berhasil atau gagal total. Bayangkan seperti merenovasi rumah: kalau pipa dan pondasinya sudah rusak, mengecat ulang temboknya tidak akan menyelesaikan masalah — begitu juga perusahaan yang proses kerjanya kacau, memasang ERP saja tidak cukup.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menjelaskan konsep desain ulang proses bisnis dan mengaitkannya dengan keberhasilan implementasi ERP. Secara rinci:

CAPAIAN 1

KONSEP BPR

Menjelaskan definisi Business Process Reengineering (BPR) dan bedanya dengan perbaikan bertahap (continuous improvement).

CAPAIAN 2

PEMETAAN PROSES

Menggambarkan proses bisnis "as-is" (saat ini) menjadi "to-be" (yang diinginkan) sebagai dasar desain ulang.

CAPAIAN 3

STAKEHOLDER

Mengidentifikasi peran dan resistensi stakeholder transformasi — manajemen, karyawan, IT, vendor.

CAPAIAN 4

FAKTOR SUKSES

Menganalisis critical success factor proyek BPR dan penyebab umum kegagalannya.

Mengapa Software Saja Tidak Cukup?

Bayangkan sebuah UMKM garmen di Bandung membeli modul ERP untuk pengelolaan gudang senilai ratusan juta rupiah. Enam bulan kemudian, stok masih sering salah catat.

Penyebabnya BUKAN sistemnya rusak — tetapi proses pencatatan lama (kertas, dua kali input manual, tanpa otorisasi jelas) dipindahkan apa adanya ke dalam ERP. Sistem baru, kebiasaan kerja lama: hasilnya tetap kacau, hanya lebih mahal.

Prinsip kunci hari ini: "Automating a mess just gives you a faster mess." — kalau proses tidak didesain ulang dahulu, ERP hanya mempercepat kesalahan, bukan menghilangkannya.

Apa Itu Business Process Reengineering (BPR)?

"Pemikiran ulang fundamental dan desain ulang radikal atas proses bisnis untuk mencapai perbaikan dramatis dalam ukuran kinerja kritis — biaya, kualitas, layanan, dan kecepatan." (Hammer & Champy, 1993)

4 Kata Kunci

Fundamental — tanya ulang "kenapa kita melakukan ini?"
Radikal — desain dari nol, bukan menambal
Dramatis — target lompatan besar, bukan 10%
Proses — fokus alur kerja lintas-fungsi, bukan per-departemen

Glosarium: proses bisnis = rangkaian aktivitas yang mengubah input (mis. pesanan pelanggan) menjadi output bernilai (mis. barang terkirim), melintasi beberapa departemen.

Definisi klasik BPR datang dari Michael Hammer dan James Champy tahun 1993, dan sampai sekarang masih jadi rujukan utama. Perhatikan empat kata kuncinya. "Fundamental" berarti kita bertanya ulang dari akar: kenapa langkah ini ada? Kalau perusahaan sudah bertahun-tahun meminta tiga tanda tangan untuk approval pembelian, apakah itu memang perlu, atau warisan kebiasaan lama? "Radikal" berarti kita tidak menambal proses lama, tetapi merancang ulang dari kertas kosong. "Dramatis" berarti targetnya bukan perbaikan tipis-tipis, tapi lompatan besar, misalnya memangkas waktu proses dari lima hari jadi lima jam. Dan "proses" berarti kita melihat alur kerja lintas-departemen secara utuh, bukan mengoptimalkan satu bagian saja seperti hanya bagian keuangan. Proses bisnis sendiri adalah rangkaian aktivitas yang mengubah input, misalnya pesanan pelanggan di Tokopedia, menjadi output bernilai, yaitu barang sampai di tangan pembeli.

BPR vs Perbaikan Bertahap (Kaizen)

Dua pendekatan perbaikan proses yang sering tertukar — penting dibedakan sebelum memilih strategi.

Aspek	Business Process Reengineering	Continuous Improvement (Kaizen)
Sifat perubahan	Radikal, dari nol	Bertahap, incremental
Kecepatan hasil	Cepat, dramatis (bisa >50%)	Lambat, konsisten (~5-15%)
Risiko	Tinggi (banyak yang gagal)	Rendah
Cocok untuk	Krisis, disrupsi kompetitor, adopsi ERP baru	Operasi stabil yang sudah cukup baik

Konteks pertemuan ini: implementasi ERP hampir selalu memaksa perusahaan melakukan BPR, karena sistem ERP dibangun di atas best practice proses standar industri — bukan proses lama perusahaan yang unik.

Banyak orang menyamakan BPR dengan istilah Jepang "kaizen" atau perbaikan berkelanjutan, padahal keduanya berbeda filosofi. Kaizen itu seperti mengasah pisau setiap hari sedikit demi sedikit — perubahan kecil, risiko rendah, cocok kalau proses sudah cukup baik dan tinggal disempurnakan. BPR itu seperti membeli pisau baru yang dirancang dari nol karena pisau lama sudah tidak relevan dengan kebutuhan sekarang — perubahan besar, cepat, tapi berisiko tinggi karena banyak yang bisa salah di tengah jalan. Ini penting untuk konteks mata kuliah kita: ketika perusahaan mengadopsi ERP, mereka hampir selalu terpaksa melakukan BPR, sebab software ERP seperti SAP atau Oracle dibangun berdasarkan praktik terbaik industri secara umum, bukan mengikuti kebiasaan unik satu perusahaan. Maka proses lama perusahaan harus disesuaikan — atau didesain ulang total — supaya cocok dengan cara kerja standar sistem.

Bagian 1 dari 3

Mengapa BPR Menjadi Fondasi ERP

Dari filosofi desain ulang, kita masuk ke metodologi konkret: bagaimana proses lama dipetakan, dianalisis, dan dirancang ulang sebelum "dikunci" ke dalam sistem.

Siklus Metodologi BPR

Lima tahap umum yang dipakai konsultan proses bisnis (mis. saat implementasi SAP di perusahaan manufaktur Indonesia).

Tahap 2 (As-Is) dan Tahap 4 (To-Be) adalah jantung BPR — inilah yang membedakannya dari sekadar "instalasi software".

Perhatikan siklus lima tahap ini yang biasa dipakai konsultan saat mendampingi perusahaan manufaktur Indonesia mengadopsi sistem seperti SAP. Tahap pertama, tim mengidentifikasi proses mana yang paling mendesak untuk didesain ulang — biasanya proses yang paling banyak keluhan atau paling lambat. Tahap kedua, mereka memetakan kondisi "as-is", yaitu bagaimana proses itu benar-benar berjalan hari ini, lengkap dengan segala kerumitannya. Tahap ketiga, mereka menganalisis kesenjangan — di mana titik-titik pemborosan, duplikasi kerja, atau kemacetan alur. Tahap keempat, mereka merancang kondisi "to-be", yaitu proses ideal yang diinginkan, biasanya mengikuti praktik terbaik dari sistem ERP. Baru di tahap kelima, hasil rancangan itu dikonfigurasi ke dalam sistem. Ingat baik-baik, tahap dua dan empat inilah jantung sesungguhnya dari BPR — bukan sekadar menyalakan software baru.

Hitung dari Nol: Efisiensi Waktu Proses BPR

Perusahaan distribusi FMCG di Surabaya mengukur dampak BPR pada proses order-to-cash (dari pesanan pelanggan sampai kas diterima).

Langkah	Perhitungan	Nilai
1. Waktu proses As-Is (sebelum BPR)	Data historis tercatat	120 jam
2. Waktu proses To-Be (target setelah BPR)	Data pilot proses baru	36 jam
3. Penghematan waktu absolut	120 − 36	84 jam
4. Persentase efisiensi	84 ÷ 120 × 100	70%

EFISIENSI WAKTU PROSES

70%

Order-to-cash: 120 jam → 36 jam

Sekarang kita hitung bersama-sama dampak nyata BPR memakai angka dari sebuah perusahaan distribusi FMCG, produk konsumen sehari-hari, di Surabaya. Perhatikan langkah pertama di tabel: sebelum BPR, proses order-to-cash — dari pelanggan memesan sampai perusahaan menerima pembayaran — makan waktu 120 jam, sekitar lima hari kerja penuh. Langkah kedua, setelah tim merancang ulang proses dan mengujinya lewat pilot project, waktunya turun jadi 36 jam saja. Langkah ketiga, kita kurangkan langsung: 120 dikurangi 36 sama dengan 84 jam yang berhasil dihemat. Langkah keempat, kita ubah jadi persentase supaya mudah dibandingkan dengan proyek lain: 84 dibagi 120 dikali 100 sama dengan 70 persen. Angka 70 persen inilah yang biasanya dilaporkan ke direksi sebagai bukti keberhasilan proyek BPR — dan inilah kenapa BPR disebut memberi perbaikan "dramatis", bukan sekadar 5 atau 10 persen seperti perbaikan bertahap biasa.

Bagian 2 dari 3

Stakeholder dan Manajemen Perubahan

Metodologi saja tidak cukup — proyek BPR menyentuh manusia yang punya kepentingan, kekhawatiran, dan bahkan penolakan terhadap perubahan.

Peta Stakeholder Transformasi ERP

Setiap kelompok punya kepentingan dan kekhawatiran berbeda terhadap proyek desain ulang proses.

MANAJEMEN PUNCAK

SPONSOR

Butuh ROI jelas & dukungan visibel. Tanpa executive sponsorship, proyek kehilangan prioritas dan anggaran.

KARYAWAN OPERASIONAL

PENGGUNA

Sering merasa terancam — takut kehilangan pekerjaan atau harus belajar cara kerja baru dari nol.

TIM IT INTERNAL

TEKNIS

Menjembatani kebutuhan bisnis dengan batasan teknis sistem; sering kewalahan bila dilibatkan terlambat.

MANAJER MENENGAH

PENJAGA STATUS QUO

Kadang paling resisten — kekuasaan mereka bergantung pada proses lama (kontrol persetujuan, informasi tersentral).

VENDOR / KONSULTAN

MITRA EKSTERNAL

Membawa keahlian best-practice, tapi tidak paham budaya kerja internal — perlu kolaborasi erat dengan tim internal.

Mari kita petakan lima kelompok pemangku kepentingan utama dalam proyek transformasi ERP. Manajemen puncak, misalnya direktur di sebuah perusahaan seperti Astra International, berperan sebagai sponsor — mereka butuh melihat pengembalian investasi yang jelas, dan tanpa dukungan visibel dari mereka, proyek gampang kehilangan prioritas saat ada masalah lain yang mendesak. Karyawan operasional, seperti staf gudang atau kasir, adalah pengguna harian sistem — mereka sering merasa terancam, takut posisinya digantikan otomatisasi atau kesulitan belajar cara kerja baru. Tim IT internal berperan menjembatani kebutuhan bisnis dan batasan teknis, tapi sering kewalahan kalau baru dilibatkan di akhir proyek. Yang menarik dan sering mengejutkan mahasiswa: manajer menengah justru kadang menjadi kelompok paling resisten, karena kekuasaan mereka selama ini bergantung pada proses lama, misalnya kewenangan menyetujui pengeluaran. Terakhir, vendor atau konsultan ERP membawa keahlian praktik terbaik dari industri, tapi mereka perlu berkolaborasi erat dengan orang dalam supaya solusinya benar-benar cocok dengan budaya kerja perusahaan.

Mengapa Manusia Menolak Perubahan Proses?

Riset manajemen perubahan (change management) menemukan pola resistensi yang berulang di berbagai proyek ERP.

Sumber Resistensi Umum

Takut kehilangan pekerjaan / kewenangan
Merasa kompetensi lama jadi tidak relevan
Kurang dilibatkan sejak awal ("dipaksa", bukan "diajak")
Trauma proyek IT gagal sebelumnya

Strategi Mitigasi

Libatkan perwakilan pengguna sejak tahap As-Is
Komunikasi rutin & transparan dari sponsor
Pelatihan intensif sebelum go-live
Rayakan "quick win" di awal untuk bangun kepercayaan

Studi kasus terkenal: kegagalan implementasi ERP di beberapa BUMN Indonesia pada 2010-an sering ditelusuri ke minimnya keterlibatan pengguna lapangan, bukan kegagalan teknis sistemnya.

Kenapa manusia sering menolak perubahan proses kerja, bahkan ketika perubahan itu secara rasional lebih baik? Pertama, ada ketakutan kehilangan pekerjaan atau kewenangan — misalnya staf administrasi yang khawatir tugasnya digantikan otomatisasi sistem. Kedua, karyawan senior merasa keahlian yang mereka bangun bertahun-tahun tiba-tiba tidak relevan lagi dengan cara kerja baru. Ketiga, dan ini paling sering terjadi, karyawan merasa hanya "diberi tahu" bukan "diajak" sejak awal proyek, sehingga merasa perubahan dipaksakan dari atas. Keempat, kalau perusahaan pernah punya pengalaman buruk dengan proyek IT sebelumnya, trauma itu membuat karyawan skeptis terhadap proyek baru. Untuk mengatasinya, strategi yang terbukti efektif antara lain melibatkan perwakilan pengguna sejak tahap pemetaan proses awal, komunikasi rutin dari pimpinan, pelatihan yang benar-benar cukup sebelum sistem baru dipakai, dan merayakan kemenangan kecil di awal supaya karyawan percaya proyek ini benar-benar membawa perbaikan, bukan sekadar proyek yang membebani mereka.

Walkthrough: Menangani Resistensi di Divisi Penjualan

Kasus PT Distribusi Elektronik (fiktif, pola umum) — tim sales menolak sistem CRM baru dalam paket ERP.

Langkah	Perhitungan	Nilai
1. Gejala awal	Observasi lapangan	Sales input data seadanya, sering kosong
2. Akar masalah (5 Whys)	Wawancara tim sales	Takut atasan pantau kinerja real-time
3. Intervensi	Perbaikan komunikasi + insentif	Sales dilibatkan desain dashboard, bonus data akurat
4. Hasil setelah 3 bulan	Audit kepatuhan input	Kepatuhan input naik dari rendah menjadi tinggi

Pelajaran: resistensi biasanya bukan soal teknologi, tapi soal rasa aman & keterlibatan — dashboard yang sama bisa terasa mengawasi atau membantu, tergantung caranya diperkenalkan.

Mari kita telusuri satu kasus langkah demi langkah, pola yang umum ditemukan di banyak perusahaan distribusi elektronik. Langkah pertama, gejala yang muncul di lapangan adalah tim sales mengisi data pelanggan seadanya di sistem CRM baru, banyak kolom dibiarkan kosong. Langkah kedua, ketika tim proyek melakukan wawancara mendalam memakai teknik "5 Whys" — bertanya "kenapa" berulang kali — ternyata akar masalahnya bukan soal sistem susah dipakai, tapi karena tim sales takut atasan bisa memantau kinerja mereka secara real-time lewat dashboard baru itu. Langkah ketiga, tim proyek melakukan intervensi: melibatkan perwakilan sales dalam mendesain tampilan dashboard supaya mereka merasa memiliki, dan menambahkan insentif bonus untuk data yang akurat dan lengkap. Langkah keempat, setelah tiga bulan, tingkat kepatuhan pengisian data naik signifikan dari yang tadinya rendah menjadi tinggi. Pelajaran pentingnya: masalah resistensi jarang soal teknologinya sulit, tapi soal rasa aman dan rasa dilibatkan — dashboard yang sama persis bisa terasa seperti alat pengawasan atau alat bantu kerja, tergantung bagaimana perusahaan memperkenalkannya.

Bagian 3 dari 3

Faktor Keberhasilan & Kegagalan Proyek

Menutup pertemuan dengan sintesis: apa yang membedakan proyek BPR-ERP yang berhasil dari yang berakhir sebagai kegagalan mahal.

Realita: Tingkat Kegagalan Proyek ERP

Berbagai studi industri (Panorama Consulting, Standish Group) secara konsisten melaporkan angka kegagalan yang tinggi.

MELEBIHI ANGGARAN

~50%

Proyek ERP over-budget signifikan

MELEBIHI JADWAL

~60%

Proyek molor dari timeline awal

GAGAL TOTAL

~10-20%

Dihentikan sebelum selesai

Angka ini adalah estimasi lintas-studi (hedge ~) — bervariasi per tahun dan metodologi survei, namun pola konsisten: mayoritas kegagalan disebabkan faktor manajemen perubahan, bukan kegagalan teknis software.

Angka-angka ini penting supaya Anda tidak naif melihat proyek ERP sebagai sesuatu yang otomatis berhasil. Berbagai survei industri, seperti yang rutin dipublikasikan Panorama Consulting, secara konsisten dari tahun ke tahun melaporkan bahwa sekitar separuh proyek ERP melebihi anggaran yang direncanakan, sekitar enam dari sepuluh proyek molor dari jadwal, dan ada kisaran sepuluh sampai dua puluh persen yang bahkan dihentikan total sebelum selesai — uang dan waktu terbuang percuma. Saya sengaja memberi tanda kira-kira pada angka-angka ini karena metodologi survei berbeda-beda dan angka bergeser tiap tahun, tapi polanya selalu konsisten dari waktu ke waktu. Dan yang paling penting untuk Anda catat: penyebab utama kegagalan itu, menurut hampir semua studi, bukan karena software-nya rusak secara teknis, melainkan karena manajemen perubahan yang buruk — persis topik yang baru saja kita bahas di bagian sebelumnya.

Faktor Kunci Keberhasilan (Critical Success Factors)

Sintesis dari literatur implementasi ERP (Umble et al.; Somers & Nelson) — enam faktor yang paling sering muncul.

Faktor	Mengapa Penting
Dukungan manajemen puncak	Menjamin sumber daya & prioritas tetap terjaga sepanjang proyek
Keterlibatan pengguna sejak awal	Desain proses lebih realistis, resistensi menurun
Business Process Reengineering dahulu	Mencegah "menyalin" proses lama yang buruk ke sistem baru
Manajemen perubahan & pelatihan	Pengguna siap & mau memakai sistem secara benar
Tim proyek lintas-fungsi yang kompeten	Menjembatani kebutuhan bisnis & batasan teknis
Data bersih & migrasi terencana	Sistem baru tidak berguna kalau datanya berantakan

Tabel ini merangkum enam faktor keberhasilan yang paling konsisten muncul di berbagai penelitian implementasi ERP, misalnya karya Umble dan rekan-rekannya, serta Somers dan Nelson yang sering dikutip di bidang sistem informasi manajemen. Dukungan manajemen puncak menjamin proyek tetap mendapat sumber daya dan prioritas meski muncul gangguan lain. Keterlibatan pengguna sejak awal membuat desain proses lebih realistis dan mengurangi resistensi seperti yang kita bahas tadi. Melakukan BPR terlebih dahulu mencegah kesalahan klasik "menyalin" proses lama yang buruk ke dalam sistem baru — ingat contoh UMKM garmen di slide awal tadi. Manajemen perubahan dan pelatihan memastikan pengguna benar-benar siap dan mau memakai sistem dengan benar, bukan mencari jalan pintas kembali ke cara lama. Tim proyek lintas-fungsi yang kompeten menjembatani bahasa bisnis dan bahasa teknis. Dan terakhir, data yang bersih serta migrasi yang terencana penting karena sistem secanggih apa pun tidak akan berguna kalau data yang dimasukkan berantakan — istilah dalam industri IT untuk ini adalah "garbage in, garbage out".

Hitung dari Nol: Skor Kesiapan Proyek BPR-ERP

Konsultan sering memakai skor sederhana (bobot 0-100) untuk menilai kesiapan organisasi sebelum proyek dimulai. Contoh perusahaan manufaktur di Cikarang.

Langkah	Perhitungan	Nilai
1. Skor dukungan manajemen (bobot 30%)	80 × 30%	24 poin
2. Skor kesiapan pengguna (bobot 30%)	60 × 30%	18 poin
3. Skor kematangan proses (bobot 20%)	50 × 20%	10 poin
4. Skor kualitas data (bobot 20%)	70 × 20%	14 poin
5. Total skor kesiapan	24 + 18 + 10 + 14	66 / 100

SKOR KESIAPAN TOTAL

66/100

Kategori "Cukup Siap" — perlu perkuat kesiapan pengguna & kematangan proses sebelum go-live

Sekarang kita praktikkan satu alat penilaian yang biasa dipakai konsultan sebelum proyek dimulai, dengan contoh sebuah pabrik manufaktur di Cikarang. Ada empat dimensi yang dinilai dengan skor nol sampai seratus, masing-masing punya bobot berbeda karena tidak semua faktor sama pentingnya. Dukungan manajemen dapat skor 80 dari 100, dengan bobot 30 persen karena ini faktor paling krusial, jadi kita kalikan 80 dengan 30 persen sama dengan 24 poin. Kesiapan pengguna dapat skor 60, juga berbobot 30 persen, jadi 60 dikali 30 persen sama dengan 18 poin — angka yang relatif rendah, tanda peringatan. Kematangan proses dapat skor 50 dengan bobot 20 persen, hasilnya 10 poin. Kualitas data dapat skor 70 dengan bobot 20 persen, hasilnya 14 poin. Kita jumlahkan semua poin ini: 24 tambah 18 tambah 10 tambah 14, sama dengan 66 dari maksimal 100. Skor 66 ini masuk kategori "cukup siap tapi perlu perbaikan" — khususnya perusahaan ini perlu memperkuat kesiapan pengguna dan kematangan prosesnya sebelum berani menekan tombol go-live.

Coba Sendiri: Skor Kesiapan Proyek Anda Sendiri

Geser keempat skor faktor (dukungan manajemen, kesiapan pengguna, kematangan proses, kualitas data) dan amati bagaimana skor total serta kategori kesiapan berubah.

Trade-off: Ubah Proses vs Kustomisasi Sistem

Ketika proses lama tidak cocok dengan standar ERP, organisasi punya dua pilihan — masing-masing berkonsekuensi.

PILIHAN A

UBAH PROSES

Ikuti best practice bawaan ERP (BPR sejati). Lebih murah jangka panjang, upgrade sistem lebih mudah, tapi butuh manajemen perubahan kuat.

PILIHAN B

KUSTOMISASI SISTEM

Ubah software mengikuti proses lama. Terasa "aman" jangka pendek, tapi mahal, rumit di-upgrade, dan sering menyimpan masalah proses lama.

Prinsip yang dipegang kebanyakan konsultan ERP: "vanilla implementation" (minim kustomisasi) lebih disukai — kustomisasi berlebihan justru sering jadi gejala BPR yang belum tuntas dilakukan.

Ini adalah salah satu keputusan paling strategis dalam proyek ERP, dan sering jadi sumber perdebatan panas antara tim IT, tim bisnis, dan vendor. Pilihan pertama adalah mengubah proses bisnis perusahaan supaya mengikuti standar bawaan atau best practice dari sistem ERP — inilah BPR yang sesungguhnya. Pilihan ini lebih murah dalam jangka panjang dan memudahkan upgrade sistem di masa depan, tapi menuntut manajemen perubahan yang kuat karena karyawan harus belajar cara kerja baru. Pilihan kedua adalah mengustomisasi software supaya mengikuti proses lama perusahaan — terasa lebih nyaman dan aman dalam jangka pendek karena karyawan tidak perlu banyak berubah, tapi biayanya mahal, sistem jadi rumit saat perlu di-upgrade di masa depan, dan sering kali justru mengawetkan masalah proses lama yang sebenarnya perlu diperbaiki. Kebanyakan konsultan ERP profesional memegang prinsip yang disebut "vanilla implementation", artinya meminimalkan kustomisasi sebisa mungkin — karena kalau tim proyek merasa perlu banyak kustomisasi, itu sering kali pertanda bahwa pekerjaan BPR-nya belum benar-benar tuntas dilakukan.

Latihan Kelas: Diagnosis Kasus

Kasus: Sebuah perusahaan ritel fashion online (mirip pola bisnis Zalora/Shopee seller besar) baru saja mengimplementasikan modul ERP untuk manajemen inventori. Tiga bulan setelah go-live, staf gudang masih mencatat stok manual di Excel sebagai "cadangan", karena tidak percaya data di sistem baru akurat. Manajer gudang mengaku tidak pernah diajak diskusi saat proses baru dirancang.

DISKUSI 1

Faktor keberhasilan apa yang paling jelas terlewat di kasus ini? Kaitkan dengan tabel Critical Success Factors.

DISKUSI 2

Sebagai konsultan, langkah manajemen perubahan apa yang akan Anda rekomendasikan untuk memperbaiki situasi ini?

Sekarang giliran Anda berlatih menganalisis. Kasusnya begini: sebuah perusahaan ritel fashion online, mirip pola bisnis penjual besar di Shopee atau platform seperti Zalora, baru saja memasang modul ERP untuk mengelola inventori gudang. Tiga bulan setelah sistem berjalan, staf gudang ternyata masih diam-diam mencatat stok secara manual di Excel sebagai cadangan, karena mereka tidak yakin data di sistem baru itu benar. Ketika ditanya, manajer gudang mengaku tidak pernah diajak berdiskusi ketika proses baru dirancang oleh tim konsultan. Saya ingin Anda diskusikan dalam kelompok kecil selama beberapa menit: faktor keberhasilan mana dari tabel yang kita bahas tadi yang paling jelas terlewat di kasus ini, dan sebagai seorang konsultan bisnis digital, langkah manajemen perubahan konkret apa yang akan Anda rekomendasikan untuk memperbaiki kepercayaan staf gudang terhadap sistem baru ini. Silakan diskusikan lima menit, nanti kita bahas bersama.

Rangkuman Pertemuan Ini

Konsep Inti

BPR = desain ulang fundamental & radikal proses bisnis, bukan tambal sulam
Metodologi: identifikasi → petakan As-Is → analisis gap → rancang To-Be → implementasi
Vanilla implementation (minim kustomisasi) lebih disukai daripada kustomisasi berlebihan

Faktor Manusia & Keberhasilan

5 kelompok stakeholder punya kepentingan berbeda-beda
Resistensi = soal rasa aman & keterlibatan, bukan sekadar teknologi
6 Critical Success Factor menentukan berhasil/gagalnya proyek

Mari kita rangkum perjalanan kita hari ini sebelum lanjut ke tugas. Kita mulai dari definisi BPR sebagai desain ulang yang fundamental dan radikal, bukan sekadar perbaikan tambal sulam — ini beda mendasar dengan continuous improvement yang bertahap. Kita pelajari metodologinya secara berurutan: identifikasi proses prioritas, petakan kondisi as-is, analisis kesenjangan, rancang kondisi to-be, baru diimplementasikan ke sistem, dengan prinsip vanilla implementation supaya kustomisasi tetap minim. Kemudian kita masuk ke sisi manusia: lima kelompok stakeholder mulai dari manajemen puncak sampai vendor, masing-masing punya kepentingan berbeda, dan resistensi terhadap perubahan biasanya soal rasa aman dan keterlibatan, bukan semata soal teknologi sulit dipakai. Terakhir, kita pelajari enam faktor kunci keberhasilan proyek yang bisa Anda pakai sebagai daftar periksa untuk menilai kesiapan organisasi mana pun sebelum memulai proyek transformasi besar seperti ini.

Penutup: Persiapan Pertemuan Berikutnya

Minggu Depan: Arsitektur ERP

Kita akan bahas fondasi teknis di balik ERP: arsitektur sistem, konsep RDBMS (database relasional), dan bagaimana data mengalir lintas modul.

Pertanyaan pemantik: kalau proses sudah didesain ulang seperti hari ini, bagaimana sebenarnya data disimpan supaya semua modul ERP bisa "berbicara" satu sama lain?

TUGAS SEBELUM PERTEMUAN 4

PETA PROSES

Pilih satu proses sederhana di sekitar Anda (mis. proses pendaftaran ulang kampus atau proses order makanan online). Gambarkan versi As-Is dan usulkan versi To-Be-nya.

Sebelum kita tutup, mari lihat sekilas ke depan. Minggu depan kita akan turun ke fondasi teknis di balik ERP: arsitektur sistemnya, konsep basis data relasional atau RDBMS, dan bagaimana data mengalir dari satu modul ke modul lain sehingga semua bagian perusahaan bisa saling "berbicara" lewat satu sumber data yang sama. Pertanyaan yang ingin Anda pikirkan sebelum pertemuan berikutnya: kalau kita sudah tahu cara mendesain ulang proses seperti hari ini, bagaimana sebenarnya data di balik layar disimpan supaya modul penjualan, gudang, dan keuangan bisa saling terhubung otomatis? Sebagai latihan sebelum pertemuan keempat, saya minta Anda memilih satu proses sederhana yang Anda alami sehari-hari, misalnya proses pendaftaran ulang di kampus kita atau proses memesan makanan lewat aplikasi online, lalu gambarkan kondisi as-is-nya dan usulkan versi to-be yang lebih efisien. Selamat berlatih, dan sampai jumpa minggu depan.