Studi Kasus ERP Discovery: Menyatukan Requirement yang Bertentangan Sebelum Implementasi

Dokumen ERP yang tebal belum tentu membuat proyek siap dikoding. Dalam proyek enterprise, masalah yang lebih berbahaya justru muncul ketika beberapa versi BRD, rancangan layar, struktur data, alur proses, dan keputusan rapat sama-sama terlihat resmi, tetapi menjelaskan aturan yang berbeda.

Studi kasus ERP discovery ini menunjukkan bagaimana bukti yang tersebar dan requirement yang bertentangan dapat diubah menjadi satu baseline implementasi yang dapat ditelusuri, diuji, dan disetujui. Identitas organisasi, nama sistem, nilai komersial, data, jumlah modul, serta artefak privat sengaja disamarkan.

Kondisi Awal: Banyak Dokumen, Belum Ada Satu Kebenaran

Sebuah organisasi merencanakan ERP untuk menghubungkan proses operasional yang kompleks. Paket awalnya terlihat meyakinkan: ada dokumen kebutuhan, rancangan antarmuka, model data, materi komersial, dan catatan pembahasan dari beberapa pihak. Namun, audit awal menemukan persoalan yang sering terjadi pada proyek besar:

• dokumen dengan tanggal lebih baru belum tentu telah disahkan sebagai pengganti versi lama;
• istilah, status transaksi, dan peran pengguna berbeda antarartefak;
• desain layar menampilkan aksi yang belum memiliki aturan bisnis;
• struktur data belum mendukung seluruh relasi yang diminta proses;
• alur pembatalan, koreksi, reversal, dan audit trail belum lengkap;
• scope komersial dan detail kebutuhan belum selalu membentuk deliverable yang sama;
• item yang masih berupa asumsi terbaca seolah-olah keputusan final.

Dalam kondisi ini, langsung menunjuk programmer bukan percepatan. Tim akan mengisi celah dengan interpretasinya masing-masing. Akibatnya, fitur dapat selesai secara teknis tetapi salah secara proses, estimasi terus berubah, dan UAT menjadi tempat pertama konflik requirement ditemukan.

Mengapa BRD, Desain, dan ERD Bisa Saling Bertentangan?

Setiap artefak melihat sistem dari sudut berbeda. BRD menjelaskan kebutuhan bisnis. Prototype menunjukkan pengalaman pengguna. ERD menggambarkan relasi data. Proposal dan kontrak menetapkan batas komersial. Notulen menangkap keputusan pada waktu tertentu. Tidak ada satu dokumen yang otomatis menjawab seluruh sistem.

Konflik muncul ketika artefak dibuat pada waktu, pemilik, atau asumsi yang berbeda. Misalnya, layar mengizinkan pengguna mengubah transaksi, tetapi BRD menyatakan transaksi final tidak dapat diedit. ERD mungkin menyimpan status tunggal, sedangkan proses bisnis membutuhkan riwayat approval berlapis. Jika konflik tidak dicatat sebagai keputusan eksplisit, kode hanya akan memilih salah satu versi secara diam-diam.

Itulah sebabnya fase discovery sebelum membuat software tidak sama dengan rapat pengenalan proyek. Discovery adalah pekerjaan analitis untuk mengubah informasi yang belum konsisten menjadi kontrak implementasi yang dapat diuji.

Tujuan Discovery pada Kasus Ini

Tujuan fase ini bukan menyelesaikan seluruh ERP, bukan pula memoles dokumen agar terlihat lengkap. Targetnya adalah membangun dasar keputusan yang cukup kuat agar pemilik proses, manajemen, dan tim teknis memahami hal yang sama.

1. menetapkan sumber dan versi yang menjadi acuan;
2. memisahkan fakta, keputusan, asumsi, pertanyaan, dan perubahan scope;
3. menormalkan requirement agar tidak ganda atau kontradiktif;
4. menghubungkan proses, peran, data, layar, integrasi, dan aturan bisnis;
5. menetapkan acceptance criteria untuk kebutuhan prioritas;
6. membentuk backlog dan estimasi yang dapat dipertanggungjawabkan;
7. memperoleh sign-off atas baseline sebelum development dimulai.

Tahapan Audit Requirement ERP

1. Inventarisasi Bukti Secara Menyeluruh

Tim mencatat seluruh BRD, FSD, prototype, ERD, spreadsheet, SOP, notulen, change request, proposal, kontrak, dan bukti proses yang tersedia. Setiap artefak diberi pemilik, tanggal, versi, status persetujuan, dan hubungan dengan scope.

Inventaris bukan sekadar daftar file. Tujuannya memastikan tidak ada dokumen penting yang tersembunyi di folder personal atau dianggap final hanya karena namanya memuat kata “final”. Jika status otoritatif belum terbukti, artefak diperlakukan sebagai kandidat baseline.

2. Menentukan Version Precedence

Tim menyusun matriks precedence untuk menjawab: dokumen mana yang berlaku, siapa yang berhak menyetujui perubahan, dan apa yang harus dilakukan bila kontrak, BRD, serta keputusan workshop berbeda. Konflik tidak diselesaikan berdasarkan tanggal file saja.

3. Menormalisasi Requirement dan Prioritas

Requirement yang duplikat digabung, istilah diseragamkan, dan kalimat ambigu diubah menjadi perilaku yang dapat diamati. Setiap item diberi aktor, pemicu, precondition, aturan, output, exception, serta acceptance criteria.

Prioritas dapat memakai MoSCoW—Must, Should, Could, dan Won’t for now—tetapi label saja tidak cukup. Item Must harus memiliki alasan bisnis, dependency, pemilik keputusan, dan konsekuensi jika tidak tersedia pada rilis pertama.

4. Membuat Traceability Requirement

Setiap kebutuhan penting dihubungkan dengan proses, layar, entitas data, aturan bisnis, role, integration point, dan test scenario. Hubungan ini membentuk traceability matrix.

Contohnya, kebutuhan “manager menyetujui transaksi” belum lengkap sebelum dijawab: manager yang mana, berdasarkan organisasi atau nilai transaksi, apa yang terjadi ketika ditolak, apakah dapat didelegasikan, siapa yang dapat melihat histori, dan data apa yang dikunci setelah approval.

5. Memetakan Proses As-Is dan To-Be

Workshop bersama process owner memetakan proses yang benar-benar berjalan dan proses target. BPMN dapat digunakan sebagai notasi bersama untuk memperjelas event, aktivitas, gateway, dan tanggung jawab. Object Management Group menyediakan spesifikasi formal BPMN 2.0.2 sebagai rujukan.

Pemetaan harus memasukkan happy path dan jalur yang sering dilupakan: penolakan, revisi, pembatalan, koreksi, reversal, timeout, data ganda, kegagalan integrasi, dan kebutuhan audit.

6. Menutup Konflik melalui Decision Register

Setiap konflik material dicatat dalam decision register: masalah, opsi, dampak bisnis, dampak teknis, pemilik keputusan, batas waktu, keputusan, dan artefak yang harus diperbarui. Dengan cara ini, keputusan tidak hilang di percakapan dan dapat ditelusuri ketika scope berubah.

Keputusan arsitektur yang berumur panjang juga dicatat sebagai Architecture Decision Record. Ini mencegah tim mengulang debat yang sama atau mengubah arah tanpa memahami konsekuensinya.

7. Memvalidasi Data, Role, Approval, dan Integrasi

ERP menyentuh lebih dari layar. Tim menyusun data dictionary, lifecycle status, role-permission matrix, approval matrix, integration map, aturan nomor dokumen, histori perubahan, serta rekonsiliasi data. Area dengan dampak keuangan atau persediaan membutuhkan aturan koreksi dan jejak audit yang eksplisit.

Referensi requirements engineering seperti ISO/IEC/IEEE 29148:2018 membantu menempatkan requirement sebagai proses sepanjang siklus hidup, bukan dokumen satu kali. Penggunaannya tetap harus disesuaikan dengan konteks organisasi dan kontrak proyek.

8. Membentuk RAID Log dan Action Plan

Risks, assumptions, issues, dan dependencies dipisahkan agar tindakan pengendaliannya jelas. Setiap item material memiliki owner, target penyelesaian, dampak, mitigasi, dan bukti penutupan. Action plan kemudian menyusun workshop, review, keputusan, dan deliverable dalam urutan dependency.

9. Menyusun Estimasi Setelah P0 dan P1 Cukup Tertutup

Estimasi awal tetap boleh dibuat sebagai rentang untuk keputusan anggaran. Namun, komitmen final sebaiknya menunggu kebutuhan prioritas tinggi, integrasi kritis, volume data, role, dan acceptance criteria cukup jelas.

Estimasi berbasis work package lebih berguna daripada satu angka besar. Setiap paket menghubungkan scope, peran, effort, dependency, risiko, deliverable, serta kondisi diterima. Unknown yang belum ditutup tetap terlihat sebagai contingency atau tahap lanjutan, bukan disembunyikan di dalam harga.

10. Review dan Sign-Off Baseline

Baseline final ditinjau oleh sponsor, process owner, PM, dan lead teknis. Persetujuan bukan berarti requirement tidak pernah boleh berubah. Artinya, perubahan setelah tanggal tersebut memiliki jalur change request, analisis dampak, dan keputusan komersial yang jelas.

Deliverable yang Membuat Development Lebih Siap

Keluaran discovery disesuaikan dengan risiko proyek, tetapi paket enterprise umumnya memerlukan:

• normalized requirement brief atau PRD beserta prioritas;
• FSD dan acceptance criteria untuk kebutuhan prioritas;
• SRS yang mencakup kebutuhan nonfungsional penting;
• BPMN as-is dan to-be;
• ERD target, data dictionary, serta lifecycle data;
• role-permission dan approval matrix;
• integration map dan kontrak antarmuka awal;
• traceability matrix;
• decision register, RAID log, dan action plan;
• architecture overview dan ADR;
• roadmap, work package, estimasi, serta release boundary;
• dokumen sign-off dan mekanisme change request.

Tidak semua proyek membutuhkan dokumen dengan nama yang sama. Yang penting adalah keputusan kritis dapat ditelusuri dari tujuan bisnis sampai bukti penerimaan. Untuk konteks yang lebih luas, lihat panduan IT blueprint perusahaan.

Apa yang Berubah Setelah Discovery?

Pada akhir pekerjaan, nilai utamanya bukan jumlah halaman. Organisasi memperoleh satu cara kerja yang lebih terkendali:

• tim tidak lagi memilih versi dokumen berdasarkan asumsi;
• konflik memiliki owner dan keputusan yang tercatat;
• kebutuhan prioritas dapat dilacak ke desain, data, proses, dan test;
• scope development terbagi menjadi work package yang terukur;
• unknown dan risiko tidak disamarkan sebagai fitur selesai;
• perubahan setelah baseline mempunyai jalur persetujuan;
• UAT dapat disusun dari acceptance criteria, bukan opini di akhir proyek.

Namun, discovery yang selesai belum membuktikan ERP telah berhasil diimplementasikan. Development, integration testing, migration rehearsal, security validation, UAT, training, deployment, dan stabilisasi produksi tetap membutuhkan bukti masing-masing.

Kapan Perusahaan Sebaiknya Memulai Audit Requirement?

Audit paling bernilai ketika salah satu kondisi berikut terjadi:

• dokumen sudah banyak tetapi tim terus memperdebatkan versi;
• vendor meminta keputusan teknis yang belum dapat dijawab process owner;
• prototype dianggap sama dengan specification;
• estimasi antarvendor berbeda jauh karena scope tidak comparable;
• proyek berpindah vendor atau tim;
• approval, data, integrasi, atau exception baru ditemukan menjelang coding;
• manajemen membutuhkan baseline untuk tender, budgeting, atau governance.

Untuk sistem dengan kompleksitas organisasi dan integrasi lebih tinggi, baca juga pembahasan discovery untuk proyek ERP kompleks.

Checklist untuk Sponsor dan Project Owner

1. Apakah ada daftar seluruh artefak beserta versi dan status persetujuannya?
2. Apakah setiap requirement prioritas mempunyai process owner?
3. Apakah konflik antara BRD, desain, data, dan kontrak tercatat?
4. Apakah role, approval, exception, reversal, dan audit trail sudah dibahas?
5. Apakah kebutuhan dapat ditelusuri sampai acceptance criteria?
6. Apakah risiko, asumsi, issue, dan dependency mempunyai owner?
7. Apakah estimasi terhubung dengan work package dan batas scope?
8. Apakah ada sign-off baseline dan mekanisme change request?

Jika beberapa jawabannya belum jelas, proyek mungkin belum membutuhkan lebih banyak programmer. Proyek membutuhkan keputusan dan baseline yang lebih kuat.

Pertanyaan yang Sering Diajukan

Apakah ERP discovery sama dengan membuat BRD?

Tidak. BRD adalah salah satu input atau keluaran bisnis. ERP discovery juga memvalidasi proses, desain, data, role, approval, integrasi, kebutuhan nonfungsional, risiko, prioritas, acceptance criteria, dan kesiapan implementasi.

Apakah prototype yang sudah lengkap membuat proyek siap coding?

Belum tentu. Prototype dapat menjelaskan layar, tetapi belum otomatis mendefinisikan validasi backend, lifecycle data, permission, exception, audit trail, performa, keamanan, dan perilaku integrasi.

Apakah semua konflik harus selesai sebelum development?

Tidak semua detail harus ditutup sekaligus. Konflik yang memengaruhi arsitektur, data, scope, compliance, integrasi, atau kebutuhan prioritas harus diputuskan sebelum work package terkait dimulai. Item lain dapat dijadwalkan dengan owner dan batas keputusan yang jelas.

Bisakah discovery dilakukan jika dokumen belum lengkap?

Bisa. Kekurangan dokumen menjadi bagian dari gap assessment. Tim dapat menggunakan workshop, observasi proses, contoh transaksi, dan bukti sistem lama untuk membangun baseline. Tingkat ketidakpastian harus tetap dinyatakan.

Apakah hasil discovery bisa dipakai untuk tender atau pergantian vendor?

Bisa, selama deliverable, scope, asumsi, hak penggunaan, dan acceptance criteria disusun secara vendor-neutral. Dokumen tersebut membantu calon vendor menaksir objek yang sama dan memudahkan evaluasi penawaran.

Bangun Baseline ERP Sebelum Mengunci Biaya dan Timeline

Jika perusahaan Anda memiliki banyak BRD, desain, SOP, atau keputusan ERP tetapi belum yakin mana yang siap menjadi acuan implementasi, Layana.ID dapat membantu melakukan audit requirement, memfasilitasi workshop discovery, menyusun traceability, dan membentuk blueprint serta work package yang terukur.

Mulai dari audit terbatas pada artefak prioritas. Tim kami akan membantu memisahkan fakta, konflik, risiko, dan keputusan yang perlu ditutup sebelum development. Pelajari layanan konsulting IT, opsi pengembangan ERP custom, atau diskusikan audit requirement bersama Layana.ID.