ERP
Pemetaan Proses ERP: Pekerjaan Persyaratan yang Menyelamatkan Proyek Anda
Desember 202511 menit baca
ERP
Pemetaan proses ERP adalah fase yang paling tidak menarik dan paling penting dari implementasi apa pun. Ini adalah pekerjaan yang mendefinisikan apa yang sebenarnya perlu dilakukan sistem — sebelum satu layar dirancang atau satu baris kode ditulis. Tanpanya, Anda membangun sistem berdasarkan asumsi. Dengannya, Anda membangun sistem berdasarkan cara bisnis Anda benar-benar bekerja.
Pemetaan proses adalah praktik mendokumentasikan bagaimana proses bisnis bekerja saat ini (keadaan 'as-is') dan bagaimana seharusnya bekerja dalam ERP baru (keadaan 'to-be'). Kesenjangan antara as-is dan to-be mendefinisikan persyaratan ERP Anda. Pemetaan proses mengungkapkan: siapa melakukan apa, apa yang memicu setiap langkah, keputusan apa yang dibuat dan oleh siapa, data apa yang dibutuhkan dan dihasilkan, apa yang bisa salah, dan apa yang terintegrasi dengan sistem lain.
Sebelum memetakan proses apa pun secara detail, buat inventaris proses — daftar lengkap proses bisnis yang akan didukung ERP. Untuk ERP UKM Indonesia yang mencakup HR, keuangan, dan operasi, inventaris mencakup 20–40 proses berbeda. Atur berdasarkan modul: HR (pengajuan permintaan cuti, persetujuan cuti, persiapan penggajian), Keuangan (entri faktur AP, persetujuan pembayaran AP, pembuatan faktur AR, pengiriman pengingat AR, rekonsiliasi bank).
Diagram swimlane mengatur langkah-langkah proses berdasarkan peran (setiap peran memiliki 'jalur' sendiri dalam diagram) dan menampilkan serah terima antar peran sebagai aliran yang melintasi jalur. Mereka adalah format terbaik untuk pemetaan proses ERP karena membuat hierarki persetujuan dan serah terima langsung terlihat.
Swimlane: Accounts Payable Invoice Approval (As-Is → To-Be)
AS-IS (current process — manual):
┌──────────────────────────────────────────────────────────────┐
│ VENDOR │ Sends paper/PDF invoice via email │
├──────────────────────────────────────────────────────────────┤
│ FINANCE STAFF │ Receives email → enters into Excel │
│ │ → emails manager for approval (via Outlook) │
├──────────────────────────────────────────────────────────────┤
│ MANAGER │ Replies "Approved" via WhatsApp or email │
│ │ (no formal record, approval can be missed) │
├──────────────────────────────────────────────────────────────┤
│ FINANCE MGR │ Checks Excel, approves payment │
│ │ → instructs bank transfer manually │
├──────────────────────────────────────────────────────────────┤
│ ACCOUNTING │ Records payment in separate ledger file │
└──────────────────────────────────────────────────────────────┘
Average time: 3–5 business days | Data in: 4 separate places
TO-BE (ERP workflow — automated):
┌──────────────────────────────────────────────────────────────┐
│ FINANCE STAFF │ Enters invoice in ERP │
│ │ ↓ (system validates required fields) │
├──────────────────────────────────────────────────────────────┤
│ SYSTEM │ Routes to Manager based on amount threshold │
│ │ Sends push notification + email to Manager │
├──────────────────────────────────────────────────────────────┤
│ MANAGER │ Approves/rejects in ERP (mobile or web) │
│ │ ↓ (system routes to Finance Manager if >Rp X│
├──────────────────────────────────────────────────────────────┤
│ FINANCE MGR │ Final approval → payment scheduled │
│ │ ↓ (system generates payment instruction) │
├──────────────────────────────────────────────────────────────┤
│ ACCOUNTING │ Payment recorded automatically on confirm │
│ │ Audit trail: every action logged │
└──────────────────────────────────────────────────────────────┘
Average time: 4–8 hours | Single source of truth
Gap analysis: 3 steps eliminated, 2 manual notifications automated,
approval record now immutable in system.Dari pengalaman saya mengimplementasikan ERP di Commsult: jalankan workshop pemetaan proses dengan orang yang sebenarnya melakukan pekerjaan, bukan manajer mereka. Manajer menggambarkan bagaimana proses seharusnya bekerja. Staf menggambarkan bagaimana proses sebenarnya bekerja. Perbedaannya adalah tempat persyaratan ERP Anda tersembunyi.
Setelah memetakan proses as-is, petakan proses to-be — bagaimana alur kerja akan bekerja dalam ERP baru. Peta to-be harus mencerminkan praktik terbaik di mana berlaku, tetapi harus divalidasi oleh pengguna yang akan mengeksekusinya. Peningkatan umum dalam peta to-be: menghilangkan entri data manual berulang, menghapus langkah notifikasi manual, menambahkan validasi yang diterapkan sistem.
# Process Map → Functional Requirements Template
# Format: "When [TRIGGER], system shall [ACTION], so that [OUTCOME]"
requirements = [
{
"id": "AP-001",
"trigger": "Finance staff submits a new AP invoice",
"action": "System validates required fields (vendor, amount, date, "
"invoice number, supporting document) and rejects submission "
"if any required field is missing",
"outcome": "No incomplete invoice records enter the workflow",
"testable": "Attempt to submit invoice without each required field → "
"expect validation error per field"
},
{
"id": "AP-002",
"trigger": "AP invoice is submitted with amount ≤ Rp 5,000,000",
"action": "System automatically routes to direct manager of submitting "
"staff for approval within 15 minutes",
"outcome": "Low-value invoices are approved same day without "
"Finance Manager bottleneck",
"testable": "Submit invoice ≤ Rp 5M → verify notification sent to "
"correct manager within 15 minutes"
},
{
"id": "AP-003",
"trigger": "AP invoice is submitted with amount > Rp 25,000,000",
"action": "System routes to Manager AND Finance Manager simultaneously "
"for dual approval",
"outcome": "High-value payments have mandatory dual control per "
"internal audit requirement",
"testable": "Submit invoice > Rp 25M → verify both managers notified "
"and both must approve before payment is released"
},
]
# Each requirement maps to: 1 database constraint / workflow state / UI element
# Each testable description becomes a UAT test caseSetiap peta proses diterjemahkan menjadi serangkaian persyaratan fungsional untuk sistem ERP. Persyaratan fungsional menyatakan: 'Ketika [pemicu], sistem harus [tindakan], sehingga [hasil].' Persyaratan yang baik cukup spesifik sehingga pengembang dapat mengimplementasikannya dan penguji dapat memverifikasinya.
Saya telah melihat workshop pemetaan proses berubah menjadi sesi daftar keinginan di mana pemangku kepentingan menggambarkan proses masa depan ideal mereka daripada realitas hari ini. Keduanya berharga, tetapi melayani tujuan yang berbeda. Peta as-is harus sangat akurat — termasuk semua solusi sementara, pengecualian yang tidak terdokumentasi, dan jalan pintas informal.
Kesalahan yang paling sering saya lihat: hanya memetakan jalur bahagia dan mengabaikan pengecualian, tidak mengidentifikasi siapa yang memiliki setiap titik keputusan, merekayasa berlebihan peta to-be dengan proses ideal yang tidak akan pernah diadopsi siapapun, dan melewatkan langkah validasi di mana peta proses ditinjau oleh peserta proses yang sebenarnya.
Proses bisnis Indonesia memiliki karakteristik spesifik yang memerlukan pemetaan yang cermat. Hierarki persetujuan sering lebih dalam dan lebih hierarkis dari norma bisnis Barat. Saluran komunikasi informal (grup WhatsApp untuk persetujuan, tanda tangan lisan) umum dan perlu secara eksplisit digantikan dalam peta to-be. Persyaratan regulasi (jejak audit BPK, pelaporan BPJS, pemformatan faktur pajak untuk e-faktur) harus secara eksplisit ditangkap dalam peta proses.