Perusahaan memutuskan menggunakan ERP untuk merapikan operasional, menyatukan data, mempercepat laporan keuangan, dan mengurangi pekerjaan manual. Vendor dipilih, anggaran disetujui, proyek berjalan berbulan-bulan, dan sistem akhirnya diluncurkan.

Namun, beberapa waktu setelah go-live, muncul masalah yang tidak pernah benar-benar terselesaikan.

Tim finance masih merekap transaksi di Excel karena laporan dari sistem belum sesuai kebutuhan. Tim procurement menggunakan spreadsheet untuk memantau pengajuan pembelian. Gudang memiliki catatan sendiri karena stok dalam aplikasi tidak selalu cocok dengan kondisi fisik. Manajemen kembali meminta laporan manual karena angka antarbagian berbeda.

ERP tetap tersedia, tetapi pengguna mulai mengandalkan cara kerja lama.

Situasi seperti ini perlu menjadi perhatian perusahaan yang sedang merencanakan transformasi digital. Keberhasilan implementasi ERP tidak cukup diukur dari sistem yang selesai dibuat atau jumlah modul yang sudah aktif. Sistem tersebut harus benar-benar mendukung proses bisnis, menghasilkan data yang dapat dipercaya, dan digunakan secara konsisten oleh orang yang menjalankan operasional sehari-hari.

Lalu, bagaimana cara merencanakan implementasi ERP agar investasi perusahaan tidak berakhir menjadi sistem tambahan yang justru menambah pekerjaan?

Mengapa Implementasi ERP Bisa Berakhir Kembali ke Excel?

Excel bukan masalah dengan sendirinya. Spreadsheet tetap berguna untuk analisis, simulasi, dan kebutuhan ad hoc. Masalah muncul ketika Excel menjadi tempat utama untuk menjalankan proses transaksi yang seharusnya dikendalikan oleh ERP.

Ketika perusahaan harus mencatat transaksi yang sama di dua tempat, risiko perbedaan angka, duplikasi pekerjaan, keterlambatan laporan, dan lemahnya jejak audit ikut meningkat.

Ada beberapa penyebab yang perlu diperiksa sebelum perusahaan memutuskan mengganti sistem atau membeli ERP baru.

1. Perusahaan memilih software sebelum memahami proses bisnis

Sering kali diskusi awal berfokus pada daftar fitur: modul finance, inventory, purchasing, HR, sales, dan dashboard manajemen.

Daftar tersebut memang penting, tetapi belum menjelaskan bagaimana perusahaan bekerja.

Contohnya, perusahaan membutuhkan modul procurement. Apakah setiap pembelian harus melalui purchase requisition? Siapa yang memeriksa anggaran? Kapan persetujuan manajer dibutuhkan? Bagaimana jika nilai pembelian melebihi batas tertentu? Siapa yang membuat purchase order, memeriksa barang datang, dan memastikan invoice sesuai?

Jika pertanyaan tersebut belum dijawab, vendor dapat membangun atau mengonfigurasi fitur tanpa memahami alur bisnis yang harus didukung.

Solusinya: petakan proses dari awal hingga akhir sebelum menetapkan solusi teknis.

2. Kebutuhan pengguna hanya dikumpulkan dari level manajemen

Direksi biasanya membutuhkan konsolidasi laporan dan visibilitas kinerja. Manajer membutuhkan kontrol dan persetujuan. Sementara itu, staf operasional harus menyelesaikan pekerjaan harian melalui sistem.

Ketiganya memiliki kebutuhan berbeda.

Jika perencanaan hanya berdasarkan permintaan manajemen, sistem bisa terlihat baik saat presentasi, tetapi menyulitkan pengguna yang harus memasukkan puluhan atau ratusan transaksi setiap hari.

Sebelum pengembangan, libatkan perwakilan finance, accounting, procurement, gudang, sales, HR, dan unit lain yang benar-benar terdampak. Lakukan observasi pekerjaan aktual, bukan hanya wawancara mengenai fitur yang diinginkan.

3. Proses lama dipindahkan ke aplikasi tanpa evaluasi

Digitalisasi bukan berarti memindahkan seluruh formulir Excel ke dalam aplikasi.

Jika proses lama memiliki terlalu banyak persetujuan, input berulang, atau pencatatan yang tidak konsisten, memindahkannya apa adanya hanya membuat masalah lama tampil dalam antarmuka baru.

Gunakan pendekatan fit-to-standard untuk menilai apakah proses standar ERP sudah memadai. Jika ada kebutuhan khusus, lakukan fit-gap analysis untuk mengidentifikasi perbedaan dan menentukan apakah kebutuhan tersebut perlu diselesaikan melalui konfigurasi, perubahan proses, integrasi, atau pengembangan tambahan.

Pendekatan ini juga membantu menghindari kustomisasi yang mahal tetapi tidak memberikan nilai bisnis sebanding. Microsoft Learn ÃÂ¢Ã¢â€šÂ¬Ã¢Â¬Ý Fit-to-standard dan fit-gap analysis.

4. Data lama dipindahkan tanpa dibersihkan

Data pelanggan yang terduplikasi, kode barang yang tidak konsisten, saldo awal yang belum direkonsiliasi, dan master data yang tidak lengkap dapat mengganggu proses ERP sejak hari pertama.

Masalah ini tidak otomatis selesai setelah perusahaan menggunakan software baru.

Sebagai contoh, jika satu pelanggan tercatat dengan tiga nama berbeda, laporan penjualan dan piutang dapat terpecah. Jika satu barang mempunyai beberapa kode, stok dan pembelian bisa salah terbaca.

Perusahaan perlu menetapkan pemilik data, aturan validasi, format master data, serta proses rekonsiliasi sebelum migrasi dilakukan.

5. Pengguna tidak mendapat waktu untuk beradaptasi

Pelatihan satu kali sebelum go-live jarang cukup untuk perubahan sistem yang memengaruhi pekerjaan sehari-hari.

Pengguna perlu memahami bukan hanya tombol yang harus ditekan, tetapi juga alasan di balik perubahan proses, konsekuensi kesalahan input, dan langkah yang harus dilakukan jika menemukan kendala.

Tanpa dukungan yang memadai, pengguna cenderung kembali ke spreadsheet atau cara kerja informal yang lebih mereka kenal.

6. Pengujian hanya berfokus pada fitur individual

Tombol simpan yang berhasil tidak membuktikan bahwa proses bisnis sudah berjalan dengan benar.

Dalam ERP, transaksi saling berhubungan. Purchase order memengaruhi penerimaan barang, penerimaan dapat memengaruhi pencatatan utang, dan transaksi yang relevan harus tercermin dengan benar dalam laporan keuangan.

Karena itu, pengujian perlu mencakup alur ujung ke ujung, hak akses, kondisi pengecualian, integrasi, performa, dan rekonsiliasi data.

Tahapan Implementasi ERP yang Sebaiknya Dilakukan Perusahaan

Implementasi ERP perlu diperlakukan sebagai program perubahan bisnis, bukan semata-mata proyek pengadaan software.

Berikut tahapan yang dapat digunakan sebagai dasar perencanaan.

Tahap 1 Business Assessment dan Penetapan Tujuan

Sebelum membandingkan vendor, tentukan masalah bisnis yang benar-benar ingin diselesaikan.

Misalnya:

1. Penyusunan laporan keuangan membutuhkan terlalu banyak rekap manual.
2. Data penjualan, pembelian, dan persediaan tidak konsisten.
3. Persetujuan pengeluaran tidak memiliki alur dan jejak audit yang jelas.
4. Manajemen kesulitan melihat posisi anggaran dan realisasi.
5. Pertumbuhan cabang meningkatkan kompleksitas operasional.

Setiap masalah harus dikaitkan dengan hasil yang diharapkan dan indikator keberhasilan.

Contoh indikator:

MasalahIndikator yang diukurRekap laporan manualWaktu penyelesaian laporan bulananData gandaJumlah duplikasi master dataPersetujuan lambatWaktu rata-rata penyelesaian approvalSelisih stokTingkat kecocokan stok sistem dan fisikInput berulangJumlah input ulang per transaksi

Tetapkan nilai awal atau baseline sebelum proyek dimulai. Target numeriknya ditentukan setelah kondisi aktual dan kemampuan organisasi diketahui.

Output tahap ini: business case, daftar masalah prioritas, baseline KPI, sponsor proyek, dan tujuan implementasi yang disepakati.

Tahap 2 Pemetaan Proses Bisnis dan Kebutuhan Pengguna

Dokumentasikan proses yang berjalan saat ini atau as-is process. Selanjutnya, rancang proses yang diharapkan setelah perbaikan atau to-be process.

Petakan siapa yang melakukan aktivitas, data apa yang dibutuhkan, siapa yang memberikan persetujuan, sistem apa yang terlibat, dan apa yang terjadi jika transaksi ditolak atau mengalami kesalahan.

Contoh alur procurement:

1. Unit mengajukan kebutuhan barang atau jasa.
2. Sistem memvalidasi kelengkapan dan anggaran sesuai aturan perusahaan.
3. Pejabat berwenang memeriksa dan menyetujui pengajuan.
4. Tim procurement melakukan proses pembelian.
5. Purchase order diterbitkan.
6. Barang atau jasa diterima dan diverifikasi.
7. Invoice dicocokkan dengan dokumen terkait sesuai kebijakan perusahaan.
8. Finance memproses pembayaran berdasarkan kewenangan dan jatuh tempo.
9. Transaksi tercermin pada laporan dan jejak audit.

Alur sebenarnya dapat berbeda menurut jenis perusahaan. Tujuan pemetaan bukan memaksakan satu proses untuk semua organisasi, melainkan memastikan setiap langkah memiliki alasan, penanggung jawab, aturan, dan hasil yang jelas.

Output tahap ini: process map, business requirements, daftar kebutuhan fungsional dan nonfungsional, aturan bisnis, matriks peran, serta daftar pengecualian yang harus ditangani.

Tahap 3 Menentukan Solusi: ERP Siap Pakai, Konfigurasi, atau Custom

Tidak semua perusahaan perlu membangun ERP dari awal. Sebaliknya, tidak semua ERP siap pakai dapat memenuhi kebutuhan khusus perusahaan tanpa penyesuaian.

Evaluasi solusi berdasarkan kecocokan proses, total biaya kepemilikan, risiko, kebutuhan integrasi, kemampuan vendor, dan kesiapan tim internal.

Pertimbangkan tiga pendekatan berikut.

ERP siap pakai

Cocok ketika proses bisnis utama dapat mengikuti kemampuan standar produk dan kebutuhan khusus masih terbatas. Evaluasi biaya lisensi, implementasi, support, dan keterbatasan produk.

ERP siap pakai dengan konfigurasi dan ekstensi

Cocok ketika sebagian besar proses sesuai dengan ERP yang tersedia, tetapi ada kebutuhan khusus yang masih dapat ditangani melalui konfigurasi, ekstensi, atau integrasi.

ERP custom

Dapat dipertimbangkan ketika kebutuhan operasional yang benar-benar membedakan bisnis tidak dapat dipenuhi secara memadai oleh solusi yang tersedia, atau ketika kontrol terhadap arsitektur dan roadmap produk menjadi pertimbangan utama.

Namun, ERP custom berarti perusahaan juga harus memikirkan pengujian, keamanan, pemeliharaan, dokumentasi, upgrade, dan keberlanjutan tim pengembang.

Jangan memilih berdasarkan harga awal atau banyaknya fitur dalam demo saja. Bandingkan biaya dan risiko sepanjang siklus hidup sistem.

Output tahap ini: solution assessment, fit-gap matrix, evaluasi vendor, estimasi total biaya kepemilikan, serta keputusan solusi yang memiliki alasan bisnis dan teknis.

Tahap 4 Menyusun Scope, Prioritas, dan Roadmap

Salah satu risiko terbesar proyek ERP adalah ruang lingkup yang terus berkembang tanpa pengendalian.

Pada awal proyek, perusahaan mungkin hanya ingin mengintegrasikan finance dan procurement. Beberapa bulan kemudian, muncul permintaan tambahan untuk CRM, HR, payroll, aplikasi mobile, business intelligence, dan berbagai otomasi.

Permintaan tersebut mungkin bermanfaat, tetapi jika semuanya dikerjakan bersamaan, waktu implementasi dan kebutuhan sumber daya dapat meningkat.

Kelompokkan kebutuhan berdasarkan prioritas:

1. Must-have: diperlukan agar proses inti dapat berjalan dengan benar dan memenuhi kewajiban yang berlaku.
2. Should-have: memberikan manfaat penting tetapi dapat dijadwalkan berdasarkan ketergantungan.
3. Could-have: memberikan nilai tambahan dan dapat dipertimbangkan setelah fondasi stabil.
4. Out of scope: tidak termasuk dalam fase saat ini dan harus melalui keputusan perubahan scope jika ingin ditambahkan.

Tentukan pula dependensi antarfitur. Sebagai contoh, laporan keuangan yang terintegrasi tidak dapat divalidasi dengan baik jika definisi akun, aturan posting, dan sumber transaksi belum disepakati.

Output tahap ini: scope baseline, product backlog, roadmap per fase, dependensi, estimasi biaya dan waktu, serta mekanisme persetujuan perubahan.

Tahap 5 Menyiapkan Data dan Arsitektur Integrasi

Sebelum membangun fitur secara luas, pastikan fondasi data dan integrasi sudah dirancang.

Beberapa hal yang perlu diputuskan meliputi:

1. Master data pelanggan, vendor, produk, akun, karyawan, dan organisasi.
2. Aturan penomoran serta identitas unik setiap entitas.
3. Kepemilikan data dan hak untuk membuat atau mengubahnya.
4. Relasi antarentitas dan aturan konsistensi transaksi.
5. Integrasi dengan sistem perbankan, perpajakan, HR, marketplace, atau aplikasi lain jika dibutuhkan.
6. Mekanisme sinkronisasi, penanganan kegagalan, dan rekonsiliasi.
7. Backup, pemulihan, audit log, keamanan akses, dan retensi data.

Migrasi perlu dilakukan secara bertahap dengan pemetaan field, pembersihan data, validasi, dan rekonsiliasi. Data saldo awal maupun transaksi historis harus diperlakukan sesuai kebutuhan bisnis dan kebijakan akuntansi perusahaan.

Output tahap ini: data dictionary, model data, integration map, aturan kualitas data, rencana migrasi, dan prosedur validasi.

Tahap 6 Pengembangan atau Konfigurasi Secara Bertahap

Hindari membangun seluruh modul sekaligus tanpa umpan balik pengguna.

Mulailah dari proses inti yang sudah dipetakan, kemudian selesaikan satu irisan proses yang memiliki hasil bisnis nyata.

Contohnya, implementasi procurement tidak hanya berarti membuat halaman pengajuan. Satu irisan proses yang lebih utuh mencakup pengajuan, approval, pembuatan purchase order, penerimaan, validasi invoice, hak akses, audit log, dan laporan yang relevan sesuai ruang lingkup fase tersebut.

Lakukan demonstrasi secara berkala kepada pengguna yang memahami proses bisnis. Setiap perubahan harus dievaluasi berdasarkan kebutuhan yang telah disepakati, bukan hanya berdasarkan preferensi tampilan.

Output tahap ini: fitur yang dapat diuji, dokumentasi, konfigurasi, integrasi, dan hasil review pengguna untuk setiap iterasi.

Tahap 7 Pengujian dan User Acceptance Test (UAT)

Sebelum sistem digunakan secara resmi, lakukan pengujian dengan skenario yang mewakili kondisi nyata.

Pengujian sebaiknya mencakup:

1. Unit testing dan integration testing.
2. Pengujian alur transaksi ujung ke ujung.
3. Validasi perhitungan dan rekonsiliasi laporan.
4. Pengujian role-based access control dan pemisahan kewenangan.
5. Pengujian transaksi gagal, duplikasi permintaan, serta proses pembatalan atau koreksi.
6. Performance testing untuk beban penggunaan yang diperkirakan.
7. Backup dan uji pemulihan.
8. UAT oleh perwakilan pengguna bisnis.

Contoh skenario UAT procurement: pengajuan di atas batas anggaran tidak boleh melewati aturan persetujuan yang berlaku. Pengguna yang tidak berwenang tidak boleh menyetujui transaksi tersebut. Setelah transaksi diproses, status dan dampak finansialnya harus sesuai dengan aturan yang telah ditetapkan.

Jangan menjadikan UAT sebagai formalitas tanda tangan. Setiap skenario perlu memiliki hasil yang diharapkan, bukti pengujian, status, dan penanggung jawab penyelesaian masalah.

Output tahap ini: test evidence, daftar defect, hasil rekonsiliasi, persetujuan UAT, dan keputusan kesiapan go-live.

Tahap 8 Pelatihan, Pilot, dan Go-Live

Pilih strategi penerapan sesuai risiko dan kesiapan organisasi.

Perusahaan dengan proses yang kompleks atau banyak unit kerja sering kali lebih aman memulai dari pilot atau rollout bertahap. Perusahaan dengan proses sederhana dan seragam mungkin dapat mempertimbangkan pendekatan yang lebih menyeluruh setelah kesiapan terbukti.

Sebelum go-live, pastikan:

1. Pengguna telah mengikuti pelatihan sesuai perannya.
2. Data awal sudah divalidasi dan direkonsiliasi.
3. Hak akses dan persetujuan sudah benar.
4. Prosedur cutover dan rollback telah disiapkan.
5. Tim support, eskalasi, dan pemilik keputusan tersedia.
6. Proses kritis memiliki prosedur operasional jika terjadi gangguan.

Pada tahap awal, sediakan dukungan intensif atau hypercare. Pantau kendala pengguna, transaksi yang gagal, kebutuhan bantuan, serta proses yang masih dikerjakan di luar ERP.

Output tahap ini: sistem yang digunakan pada lingkup yang disepakati, pengguna terlatih, dan proses dukungan pascaimplementasi yang jelas.

Tahap 9 Evaluasi Adopsi dan Perbaikan Berkelanjutan

Go-live bukan akhir proyek.

Setelah sistem digunakan, bandingkan KPI aktual dengan baseline yang ditetapkan pada tahap awal. Evaluasi apakah laporan menjadi lebih cepat, kesalahan berkurang, proses persetujuan lebih terkendali, dan data semakin konsisten.

Cari tahu mengapa pengguna masih memakai spreadsheet untuk pekerjaan tertentu. Bisa jadi ada kebutuhan analisis yang memang lebih tepat dilakukan di spreadsheet, tetapi bisa juga ada masalah pada alur aplikasi, kualitas data, performa, pelatihan, atau desain proses.

Tentukan tindak lanjut berdasarkan bukti, tingkat risiko, dan manfaat bisnis. Hindari menambah fitur baru sebelum masalah yang menghambat proses inti ditangani.

Output tahap ini: laporan manfaat bisnis, hasil pengukuran adopsi, daftar perbaikan prioritas, dan roadmap pengembangan lanjutan.

Bagaimana Memilih Vendor ERP yang Tepat?

Vendor yang baik bukan hanya pihak yang mampu mendemonstrasikan fitur. Vendor dan tim implementasi perlu memahami proses bisnis, menjelaskan keterbatasan solusi, serta memberikan gambaran yang realistis mengenai biaya, risiko, dan tanggung jawab setiap pihak.

Sebelum memilih vendor, mintalah penjelasan mengenai hal-hal berikut:

1. Pengalaman pada proses serupa. Minta contoh implementasi yang relevan dan, jika memungkinkan, referensi pelanggan yang dapat dihubungi.
2. Metodologi implementasi. Pastikan terdapat proses discovery, pemetaan kebutuhan, fit-gap analysis, pengujian, pelatihan, dan dukungan pasca-go-live.
3. Kejelasan biaya. Pisahkan biaya lisensi, implementasi, konfigurasi, kustomisasi, migrasi, integrasi, infrastruktur, pelatihan, dan pemeliharaan.
4. Kepemilikan dan akses data. Pastikan kontrak mengatur akses, ekspor, pengembalian, dan penghapusan data sesuai kebutuhan serta kewajiban yang berlaku.
5. Dokumentasi dan keberlanjutan. Tanyakan bagaimana dokumentasi, source code jika relevan, konfigurasi, kredensial, dan pengetahuan teknis dikelola ketika kerja sama berakhir.
6. Keamanan dan operasional. Evaluasi kontrol akses, audit log, backup, pemulihan, monitoring, penanganan insiden, dan tanggung jawab keamanan.
7. Kriteria penerimaan. Tetapkan hasil yang harus dicapai pada setiap fase sebelum pembayaran atau perpindahan ke fase berikutnya, sesuai kontrak.

Jangan menilai vendor hanya dari harga termurah atau janji implementasi tercepat. Nilai proposal berdasarkan kesesuaian kebutuhan, kejelasan ruang lingkup, kualitas pendekatan, kemampuan tim, dan total biaya kepemilikan.

Checklist Sebelum Perusahaan Memulai Proyek ERP

Gunakan checklist berikut untuk menilai kesiapan awal perusahaan.

1. Tujuan bisnis dan masalah prioritas sudah disepakati.
2. Sponsor proyek dan pemilik keputusan sudah ditetapkan.
3. Pemilik proses dari setiap departemen sudah ditunjuk.
4. Proses bisnis saat ini dan proses target sudah dipetakan.
5. Kebutuhan fungsional dan nonfungsional sudah didokumentasikan.
6. Solusi ERP sudah dievaluasi berdasarkan fit-gap dan total biaya kepemilikan.
7. Scope, prioritas, dependensi, dan roadmap sudah disetujui.
8. Data dan tanggung jawab pengelolaannya sudah ditetapkan.
9. Rencana integrasi dan migrasi sudah tersedia.
10. Skenario testing, UAT, cutover, dan rollback sudah disiapkan.
11. Pelatihan, komunikasi perubahan, dan support sudah direncanakan.
12. KPI keberhasilan dan mekanisme evaluasi pasca-go-live sudah ditetapkan.

Jika sebagian besar poin belum terpenuhi, perusahaan sebaiknya tidak langsung melompat ke pengembangan skala penuh. Mulailah dengan assessment dan perencanaan agar keputusan investasi memiliki dasar yang lebih kuat.

Kapan Perusahaan Perlu Konsultasi Sebelum Membangun ERP?

Assessment sebelum implementasi sangat bermanfaat ketika perusahaan sedang mempertimbangkan ERP pertama, ingin mengganti sistem yang tidak lagi sesuai, mengalami kesulitan mengintegrasikan aplikasi, atau menemukan bahwa proses operasional masih bergantung pada banyak spreadsheet.

Konsultasi juga relevan ketika kebutuhan antarbagian saling bertentangan, scope proyek terus berubah, atau perusahaan belum dapat menentukan apakah lebih tepat menggunakan ERP siap pakai, mengembangkan ekstensi, atau membangun solusi khusus.

Dalam kondisi tersebut, langkah pertama bukan langsung memilih teknologi. Langkah pertama adalah memahami masalah bisnis, mengukur dampaknya, dan menentukan pilihan solusi berdasarkan kebutuhan yang terverifikasi.

Diskusikan Rencana ERP Perusahaan Anda Bersama Ethan Tech

Implementasi ERP seharusnya membantu perusahaan bekerja dengan lebih terstruktur, bukan menambah sistem yang harus diisi tanpa memberikan manfaat nyata.

Ethan Tech mengajak perusahaan untuk memulai transformasi digital dari pemahaman proses bisnis dan tujuan yang jelas. Sebelum menentukan pendekatan pengembangan, penting untuk menilai kebutuhan setiap departemen, sistem yang sudah digunakan, kualitas data, kebutuhan integrasi, serta kesiapan organisasi untuk berubah.

Diskusi awal dapat difokuskan pada:

1. Assessment proses bisnis dan identifikasi masalah operasional.
2. Pemetaan kebutuhan ERP dan prioritas modul.
3. Evaluasi pendekatan ERP siap pakai, konfigurasi, integrasi, atau custom development.
4. Penyusunan roadmap implementasi, tahapan delivery, dan kriteria keberhasilan.
5. Identifikasi risiko data, keamanan, operasional, serta adopsi pengguna.

Tidak semua perusahaan membutuhkan ERP custom, dan tidak semua masalah harus diselesaikan dengan membeli sistem baru. Pendekatan yang tepat bergantung pada kebutuhan bisnis, kondisi sistem saat ini, sumber daya, serta rencana pertumbuhan perusahaan.

Ingin merencanakan implementasi ERP yang lebih terarah?

Konsultasikan kebutuhan perusahaan Anda dengan Ethan Tech untuk membahas proses bisnis, pilihan solusi, dan tahapan implementasi yang sesuai dengan kondisi organisasi.

Hubungi Ethan Tech melalui halaman Kontak untuk mendiskusikan kebutuhan ERP perusahaan Anda.

Sumber riset dan referensi editorial

Naskah di atas menggunakan prinsip implementasi berbasis proses, analisis kecocokan solusi, pengelolaan perubahan, dan penerapan bertahap. Referensi berikut dapat digunakan tim Ethan Tech untuk memperdalam materi sebelum publikasi.

Microsoft Learn : Fit-to-standard dan fit-gap analysis

Panduan menilai kecocokan proses bisnis dengan fitur standar, mengidentifikasi gap, dan menentukan kapan kustomisasi layak dilakukan.

Baca panduan Microsoft

SAP : ERP Implementation Best Practices

Referensi mengenai strategi implementasi, pilot, rollout bertahap, kesiapan pengguna, dan migrasi data.

Baca panduan SAP

Microsoft Learn : Implement a solution based on business processes

Menjelaskan pentingnya pemetaan proses, penyelarasan proses dengan tujuan bisnis, dan penggunaan bahasa bisnis yang dipahami stakeholder.

Baca panduan proses bisnis

Novatama : Why ERP Implementations Fail in Indonesia

Perspektif lokal tentang gejala implementasi ERP yang tidak diadopsi pengguna dan kembalinya proses kerja berbasis spreadsheet.

Baca pembahasan kasus Indonesia