RPS minggu 13 · 2x50 menit

Teknologi Informasi dan Sistem ERP dalam Operasi

Pertemuan 12 — Manajemen Operasi dan Teknologi

Dari digitalisasi rantai pasok menuju tulang punggung informasi terintegrasi: ERP sebagai keputusan investasi, bukan sekadar proyek IT.

Selamat datang kembali, Anda baru saja menyelesaikan pembahasan Supply Chain 4.0 dan digitalisasi rantai pasok pada pertemuan sebelumnya — hari ini kita masuk ke lapisan yang menopang semua itu secara teknis, yaitu sistem informasi dan Enterprise Resource Planning. Sebagai manajer S2 yang sudah berpengalaman, Anda tidak perlu lagi penjelasan dasar apa itu database atau apa itu perangkat lunak; fokus kita adalah bagaimana Anda mengambil keputusan investasi ERP, menimbang skema on-premise versus cloud, dan mengelola risiko implementasi yang sering menjadi kuburan proyek transformasi digital. Sepanjang sesi ini kita akan menggunakan kasus nyata seperti kegagalan implementasi ERP di sejumlah BUMN dan keberhasilan adopsi SAP di industri manufaktur Indonesia sebagai bahan diskusi. Siapkan pengalaman kerja Anda sendiri, karena keputusan ERP hampir pasti sudah pernah menyentuh organisasi tempat Anda bekerja, baik sebagai pengguna maupun pengambil keputusan.

Bagian 1 dari 3

Arsitektur Informasi Operasi: dari Silo ke Integrasi

Diskusi kelas: mengapa begitu banyak organisasi besar di Indonesia masih menjalankan operasi dengan puluhan sistem informasi terpisah yang tidak saling bicara, padahal risikonya sudah lama diketahui?

Dari Sistem Fungsional Terpisah ke ERP Terintegrasi

Sebelum ERP meluas, organisasi mengelola operasi lewat sistem fungsional terpisah — legacy silos: keuangan, produksi, dan SDM masing-masing punya basis data sendiri. Masalahnya bukan teknis semata, melainkan keputusan koordinasi: siapa yang punya "kebenaran tunggal" atas data stok, biaya, dan kapasitas.

Konsekuensi Manajerial Silo

Rekonsiliasi manual antar-sistem → biaya koordinasi tinggi & rawan human error.
Keputusan real-time (harga, alokasi kapasitas) tertunda menunggu laporan lintas divisi.
Audit trail lemah → risiko kepatuhan & fraud lebih tinggi.

Anatomi ERP: Modul Inti dan Keterkaitannya dengan Operasi

Modul Operasi & SCM

Perencanaan produksi, MRP, manajemen persediaan real-time.
Terhubung langsung ke topik minggu-minggu sebelumnya: peramalan, kapasitas, persediaan.

Modul Keuangan & Akuntansi

General ledger, biaya produksi, costing otomatis per unit output.
Basis kepatuhan pelaporan (PSAK, pajak) tanpa rekonsiliasi manual.

Modul SDM & CRM

Kapasitas tenaga kerja terhubung ke jadwal produksi.
Data permintaan pelanggan (CRM) menjadi input peramalan operasi.

Nilai strategis ERP bukan pada modul individual, melainkan pada satu tulang punggung data yang membuat keputusan operasi, keuangan, dan SDM saling konsisten secara real-time.

Keputusan Strategis: On-Premise, Cloud, atau Hybrid ERP

On-Premise

Kontrol penuh atas data & kustomisasi — relevan untuk industri dengan regulasi data ketat.
Capex besar di muka, siklus upgrade lambat, beban IT internal tinggi.

Cloud (SaaS ERP)

Opex berlangganan, time-to-value lebih cepat, update otomatis vendor.
Risiko: ketergantungan vendor (vendor lock-in) & kedaulatan data lintas-negara.

Keputusan ini bukan soal "mana yang lebih baik", melainkan kesesuaian dengan profil risiko & skala organisasi — bank dan BUMN strategis cenderung hybrid/on-premise untuk data inti, sementara startup dan UMKM naik kelas memilih cloud murni untuk kecepatan.

Ingatkan Anda bahwa perdebatan on-premise versus cloud sudah bergeser dari isu teknis menjadi isu tata kelola risiko perusahaan, terutama pasca berlakunya Undang-Undang Perlindungan Data Pribadi yang mengatur ke mana data boleh disimpan dan diproses. Berikan contoh bahwa perbankan nasional cenderung mempertahankan sebagian data inti secara on-premise atau di data center domestik karena tuntutan regulasi OJK, sementara perusahaan rintisan digital lebih memilih ERP cloud seperti NetSuite atau Odoo demi kecepatan implementasi. Tanyakan kepada mahasiswa yang bekerja di sektor keuangan atau pemerintahan, apakah organisasi mereka memiliki kebijakan eksplisit tentang lokasi penyimpanan data operasional. Dorong diskusi tentang skema hybrid sebagai jalan tengah yang semakin populer, di mana data sensitif tetap on-premise namun modul non-kritis berjalan di cloud.

Lanskap Vendor ERP: Memilih Tier yang Sesuai Skala Organisasi

Tier 1 — Enterprise Global

SAP S/4HANA, Oracle Fusion Cloud.
Cocok organisasi multi-entitas, multi-negara, kompleksitas regulasi tinggi.
Investasi & waktu implementasi terbesar.

Tier 2 — Mid-Market

Oracle NetSuite, Infor, Microsoft Dynamics 365.
Cocok perusahaan menengah yang butuh integrasi tanpa kompleksitas Tier 1.
Implementasi cloud-native, siklus lebih cepat.

Tier 3 — Lokal/UMKM Naik Kelas

Odoo, Accurate Online, Jurnal by Mekari.
Biaya rendah, modul terbatas namun cukup untuk skala UMKM naik kelas.
Risiko: keterbatasan skalabilitas saat organisasi tumbuh cepat.

Kesalahan manajerial umum: memilih Tier 1 karena reputasi merek padahal kebutuhan organisasi sebenarnya cukup dilayani Tier 2 atau 3 — over-engineering investasi ERP.

Coba Sendiri: Total Cost of Ownership ERP

Ubah horizon waktu dan skala organisasi, lalu amati titik impas antara skema on-premise dan cloud ERP.

Mini-Kasus: Migrasi ERP Semen Indonesia — Konsolidasi Pasca-Akuisisi

Pasca-konsolidasi grup semen nasional, perusahaan menghadapi tiga sistem ERP warisan berbeda dari masing-masing anak usaha — keputusan manajerial: migrasi paksa ke satu platform, atau biarkan berjalan paralel dengan lapisan integrasi (middleware)? Angka berikut ilustrasi untuk keperluan diskusi.

Opsi Migrasi Penuh

~24 bln

satu platform, ilustrasi

Opsi Middleware

~6 bln

integrasi cepat, ilustrasi

Risiko Status Quo

biaya rekonsiliasi tahunan, ilustrasi

Keputusan manajerial: migrasi penuh memberi konsistensi data jangka panjang tetapi menunda manfaat sinergi akuisisi; middleware memberi manfaat cepat tetapi mewariskan kerumitan teknis (technical debt) yang harus diselesaikan kelak.

Bagian 2 dari 3

Implementasi ERP: Mengapa Proyek Ini Sering Gagal

Diskusi kelas: riset industri secara konsisten menunjukkan mayoritas proyek implementasi ERP mengalami keterlambatan atau pembengkakan biaya — mengapa kegagalan ini terus berulang meski sudah menjadi pengetahuan umum di kalangan manajer?

Akar Kegagalan Implementasi ERP: Bukan Soal Perangkat Lunak

Faktor Organisasional

Resistensi perubahan (change resistance) dari karyawan yang terbiasa dengan proses lama.
Kurangnya sponsor eksekutif (executive sponsorship) yang konsisten sepanjang proyek.
Proses bisnis tidak dipetakan ulang — sistem baru "dipaksakan" pada proses lama (vanilla vs. customization trap).

Faktor Teknis & Proyek

Migrasi data warisan (legacy data) yang kotor & tidak terstandardisasi.
Ruang lingkup proyek melebar tanpa kendali (scope creep).
Pelatihan pengguna akhir diperlakukan sebagai afterthought, bukan jalur kritis proyek.

Sampaikan bahwa temuan riset klasik tentang kegagalan ERP, termasuk kasus terkenal Hershey pada akhir 1990-an yang gagal memenuhi pesanan musim Halloween akibat implementasi terburu-buru, secara konsisten menunjukkan akar masalah pada sisi manusia dan organisasi, bukan pada kualitas perangkat lunak itu sendiri. Berikan contoh bahwa beberapa BUMN Indonesia pernah mengalami penundaan implementasi ERP karena resistensi karyawan yang merasa proses kerja lama lebih nyaman meski kurang efisien. Tekankan bahwa perangkap vanilla versus kustomisasi berarti organisasi harus memilih antara mengadopsi praktik terbaik bawaan software atau memaksa software mengikuti proses lama yang mungkin justru tidak efisien. Ajak mahasiswa memikirkan proyek IT di perusahaan mereka yang pernah mengalami scope creep dan bagaimana dampaknya terhadap jadwal dan anggaran.

Change Management ERP: Kerangka ADKAR sebagai Walkthrough Manajerial

Karena resistensi perubahan adalah akar kegagalan paling sering, gunakan kerangka ADKAR (Hiatt, 2006) sebagai walkthrough bertahap mengelola sisi manusia dari proyek ERP.

Walkthrough 1: Sebelum Go-Live

Awareness — karyawan memahami MENGAPA ERP diperlukan, bukan sekadar diperintahkan memakainya.
Desire — insentif & keterlibatan karyawan dalam desain proses, bukan sekadar sosialisasi satu arah.
Knowledge — pelatihan berbasis peran (role-based), bukan pelatihan generik seragam.

Walkthrough 2: Setelah Go-Live

Ability — pendampingan langsung (super-user/champion) di lantai kerja selama minggu-minggu awal.
Reinforcement — evaluasi KPI adopsi & insentif berkelanjutan agar tidak kembali ke kebiasaan lama.
Kegagalan pada tahap ini → "shadow system": karyawan diam-diam kembali memakai Excel lama.

Investasi teknologi terbaik tetap gagal bila kelima tahap ADKAR tidak dikelola berurutan — melompati satu tahap membuat tahap berikutnya rapuh.

Jelaskan bahwa kerangka ADKAR ini secara khusus dirancang untuk manajer yang harus mengelola perubahan pada level individu karyawan, bukan hanya pada level proses atau sistem. Berikan contoh bahwa banyak proyek ERP di Indonesia berhasil pada tahap teknis instalasi namun gagal pada tahap reinforcement karena karyawan diam-diam kembali menggunakan spreadsheet lama yang mereka anggap lebih cepat, fenomena yang dikenal sebagai shadow system. Tekankan bahwa keterlibatan karyawan dalam tahap desire, misalnya dengan melibatkan mereka merancang alur kerja baru, jauh lebih efektif dibanding sekadar sosialisasi searah dari manajemen. Tanyakan kepada mahasiswa yang pernah mengalami implementasi sistem baru di perusahaan mereka, tahap ADKAR mana yang menurut pengalaman mereka paling sering diabaikan oleh manajemen.

Hitung dari Nol: Analisis Biaya-Manfaat Implementasi ERP

Ilustrasi: perusahaan manufaktur menengah mengevaluasi kelayakan investasi ERP cloud selama horizon lima tahun.

Langkah	Perhitungan	Nilai
1. Investasi awal (lisensi, migrasi data, konsultan)	diberikan	Rp 2.400.000.000
2. Biaya langganan & pemeliharaan tahunan	diberikan (x5 tahun)	Rp 600.000.000/thn
3. Total biaya 5 tahun	2.400.000.000 + (600.000.000 x 5)	Rp 5.400.000.000
4. Penghematan tahunan (rekonsiliasi manual + persediaan berlebih)	diberikan (x5 tahun)	Rp 1.500.000.000/thn
5. Total manfaat 5 tahun	1.500.000.000 x 5	Rp 7.500.000.000
6. Net benefit 5 tahun	7.500.000.000 − 5.400.000.000	Rp 2.100.000.000
7. Payback period (linier)	2.400.000.000 / (1.500.000.000 − 600.000.000)	~2,7 tahun

Keputusan Kelayakan

2,7 thn

payback di bawah horizon evaluasi 5 tahun — investasi layak dilanjutkan bila risiko implementasi terkendali

Kerangka Analisis Risiko Implementasi ERP

Untuk keputusan implementasi yang bersifat kualitatif-strategis, gunakan rubrik lima langkah berikut sebagai kerangka mitigasi risiko sebelum go-live.

Langkah	Fokus Analisis	Pertanyaan Kunci
1. Kesiapan Organisasi	Sponsor eksekutif & budaya perubahan	Apakah pimpinan puncak berkomitmen penuh sepanjang proyek?
2. Pemetaan Proses	Vanilla vs. kustomisasi	Proses mana yang harus diselaraskan ke praktik terbaik sistem?
3. Kualitas Data Migrasi	Legacy data cleansing	Seberapa bersih & terstandardisasi data warisan?
4. Manajemen Ruang Lingkup	Scope creep & change control	Adakah mekanisme formal persetujuan perubahan lingkup?
5. Kesiapan Pengguna Akhir	Pelatihan & adopsi	Apakah pelatihan menjadi jalur kritis, bukan tambahan di akhir?

Kesimpulan kerangka: proyek ERP yang berhasil selalu bisa menjawab kelima pertanyaan ini secara eksplisit sebelum go-live — bukan sesudah masalah muncul.

Mini-Kasus: Implementasi SAP di Grup Manufaktur Nasional

Sebuah grup manufaktur otomotif nasional mengadopsi SAP S/4HANA untuk menggantikan tujuh sistem warisan berbeda di seluruh anak usaha — proyek berlangsung 18 bulan dengan pendekatan bertahap (phased rollout) per pabrik, bukan serentak (big bang). Detail ilustrasi berbasis pola umum industri.

Keputusan Manajerial Kunci

Phased rollout dipilih untuk membatasi risiko gangguan produksi — pabrik dengan risiko terendah menjadi pilot.
Tim inti lintas-fungsi (bukan hanya IT) ditempatkan penuh waktu selama proyek — sinyal komitmen eksekutif.
Proses bisnis "vanilla" SAP diadopsi untuk 70% modul, kustomisasi dibatasi hanya pada proses yang menjadi keunggulan kompetitif.

Analitik Operasi Berbasis ERP: dari Pencatatan ke Prediksi

ERP modern bukan sekadar sistem pencatatan transaksi (system of record) — modul analitik terintegrasi memungkinkan pergeseran dari deskriptif (apa yang terjadi) ke prediktif & preskriptif (apa yang akan terjadi & apa yang harus dilakukan).

Aplikasi Operasional

Peramalan permintaan otomatis dari data transaksi ERP real-time, bukan laporan bulanan.
Deteksi anomali persediaan & kualitas sebelum eskalasi menjadi masalah produksi.
Dashboard eksekutif lintas-modul mendukung keputusan kapasitas & harga secara simultan.

Tata Kelola Data Master: Prasyarat Tersembunyi Kesuksesan ERP

ERP hanya sebaik data yang diinputkan ke dalamnya — master data governance (kode item, struktur pelanggan, hierarki pemasok) adalah keputusan yang harus tuntas sebelum go-live, bukan diperbaiki setelahnya.

Keputusan Tata Kelola Kunci

Siapa pemilik data (data owner) per domain — produksi, keuangan, atau SDM?
Standar penamaan & kodifikasi item/SKU tunggal di seluruh entitas grup.
Proses persetujuan perubahan data master (change control) pasca-go-live.

Sampaikan bahwa banyak proyek ERP menghabiskan anggaran besar untuk konfigurasi sistem namun mengabaikan pembersihan data master, sehingga setelah go-live sistem canggih tetap menghasilkan laporan yang tidak akurat karena mengikuti prinsip garbage in, garbage out. Berikan contoh bahwa perusahaan dengan banyak anak usaha sering memiliki kode item berbeda untuk produk yang sama persis, sehingga tanpa standardisasi kodifikasi, modul analitik dan peramalan yang sudah dibahas sebelumnya tidak dapat menghasilkan angka yang andal. Tekankan bahwa penentuan data owner per domain adalah keputusan tata kelola, bukan sekadar tugas teknis tim IT, karena menyangkut siapa yang bertanggung jawab atas akurasi data dalam jangka panjang. Tanyakan kepada mahasiswa apakah organisasi mereka memiliki kebijakan formal tata kelola data master atau masih menyerahkannya sepenuhnya kepada tim IT tanpa keterlibatan unit bisnis.

Bagian 3 dari 3

ERP sebagai Fondasi Menuju Transformasi Digital Operasi

Diskusi kelas: dalam studi kasus kelompok yang akan Anda kerjakan, bagaimana Anda meyakinkan direksi bahwa investasi ERP adalah prasyarat transformasi digital, bukan sekadar biaya IT yang bisa ditunda?

Gunakan pertanyaan ini untuk mempersiapkan mahasiswa menuju studi kasus transformasi digital operasi yang akan menjadi tugas kelompok pada pertemuan berikutnya, sekaligus mengingatkan bahwa argumen investasi ERP harus menghubungkan analisis biaya-manfaat dengan kerangka risiko implementasi yang sudah dipelajari hari ini. Tanyakan pengalaman mahasiswa dalam mengajukan atau menolak proposal investasi sistem informasi kepada manajemen puncak, dan argumen apa yang paling efektif meyakinkan mereka. Dorong mereka untuk mulai memikirkan bagaimana ERP menjadi fondasi data bagi topik keberlanjutan dan Industri 5.0 yang akan dibahas pada pertemuan-pertemuan selanjutnya. Ingatkan bahwa kerangka yang baik bukan untuk menggantikan penilaian manajerial, melainkan membuat argumen investasi lebih terstruktur dan defensibel di hadapan pemangku kepentingan.

ERP sebagai Prasyarat Teknologi Operasi Lanjutan

Tanpa Fondasi ERP yang Solid

Inisiatif AI/machine learning kekurangan data bersih & terstruktur untuk dilatih.
Otomasi proses (RPA) hanya menambal gejala, bukan menyelesaikan akar masalah integrasi.
Supply Chain 4.0 & IoT tidak punya "rumah data" tunggal untuk sinkronisasi.

Dengan Fondasi ERP yang Solid

Data real-time menjadi input langsung model peramalan & optimasi kapasitas.
Modul ERP baru (sustainability tracking, IoT integration) dapat ditambah bertahap.
Organisasi siap menuju paradigma Industri 5.0 — kolaborasi manusia-mesin berbasis data terpercaya.

Keputusan berinvestasi pada ERP hari ini adalah taruhan pada kapabilitas digital jangka panjang organisasi, bukan sekadar penggantian sistem lama.

Persiapan Studi Kasus Kelompok: Transformasi Digital Operasi

Instruksi Kerja Kelompok (Pra-Pertemuan Studi Kasus)

Pilih satu organisasi Indonesia (dapat dari sektor tempat Anda bekerja) yang pernah melakukan atau sedang merencanakan implementasi ERP/transformasi digital operasi.
Terapkan kerangka lima langkah risiko implementasi: kesiapan organisasi, pemetaan proses, kualitas data, manajemen ruang lingkup, kesiapan pengguna akhir.
Sertakan minimal satu perhitungan kuantitatif (analisis biaya-manfaat atau payback period) sebagai bukti analisis, bukan opini semata.
Rujuk minimal tiga sumber ilmiah (APA edisi ketujuh) yang mendukung argumen — bukan hanya sumber berita populer.
Siapkan presentasi ringkas untuk sesi diskusi studi kasus transformasi digital operasi pada pertemuan berikutnya.

Ringkasan Pertemuan 12 & Jembatan ke Pertemuan Berikutnya

Yang Sudah Kita Bangun

Arsitektur ERP sebagai integrasi satu tulang punggung data dari sistem fungsional yang terpisah (silo).
Keputusan strategis on-premise vs. cloud vs. hybrid berdasarkan profil risiko organisasi.
Analisis biaya-manfaat & payback period sebagai argumen kuantitatif investasi ERP.
Kerangka lima langkah mitigasi risiko implementasi — akar kegagalan ERP bersifat organisasional, bukan teknis semata.

Pertemuan Berikutnya

P13

Studi Kasus Transformasi Digital Operasi

Kerangka ERP dan risiko implementasi hari ini akan langsung diuji pada analisis kelompok atas kasus transformasi digital operasi nyata, sebelum kita menutup semester dengan diskusi keberlanjutan dan Industri 5.0.

Tutup sesi dengan merangkum bahwa keputusan ERP bukan sekadar proyek IT, melainkan keputusan strategis yang menentukan kapabilitas data jangka panjang organisasi dan kesiapannya menghadapi teknologi operasi generasi berikutnya. Ingatkan mahasiswa bahwa kerangka lima langkah yang telah dipelajari hari ini akan langsung mereka gunakan untuk menganalisis studi kasus transformasi digital operasi pada pertemuan berikutnya, sehingga penting benar-benar menguasainya, bukan sekadar mencatat. Tanyakan apakah ada pertanyaan tersisa dari materi hari ini sebelum kelas ditutup, khususnya terkait analisis biaya-manfaat atau kerangka risiko implementasi yang mungkin masih membingungkan sebagian mahasiswa. Sampaikan juga bahwa tugas kelompok yang telah dijelaskan sebaiknya mulai dikerjakan sejak sekarang agar diskusi pada pertemuan berikutnya dapat berjalan lebih produktif.