Bagaimana Menyusun Business Requirement Document untuk Proyek ERP?

Business Requirement Document (BRD) adalah dokumen yang merinci kebutuhan bisnis sebelum sistem ERP dibangun. Isinya mencakup tujuan proyek, proses kerja, kebutuhan fungsional, dan batasan. Dokumen ini menjadi acuan bersama antara perusahaan dan penyedia sistem agar implementasi tidak melenceng.

Kenapa Proyek ERP Sering Bermula dari Salah Paham

Banyak proyek ERP tersendat bukan karena teknologinya, melainkan karena kebutuhan dipahami berbeda-beda. Bagian gudang menganggap persetujuan stok cukup satu tingkat. Bagian keuangan justru mengharapkan dua tingkat.

Perbedaan seperti ini baru terlihat saat sistem sudah berjalan. Biaya perbaikannya pun jauh lebih besar dibanding saat masih di atas kertas. BRD hadir untuk menangkap perbedaan itu lebih awal.

Isi Dokumen yang Perlu Ada di Dalamnya

BRD yang baik tidak harus tebal, tetapi harus bisa dipahami semua pihak. Tujuan bisnis ditulis lebih dulu, misalnya mempercepat penutupan buku bulanan. Setelah itu, alur proses saat ini dipetakan apa adanya. Kebutuhan fungsional dan non-fungsional menyusul di bagian berikutnya.

Ruang lingkup perlu ditegaskan, termasuk hal yang sengaja tidak dikerjakan pada fase pertama. Asumsi, risiko, dan kriteria penerimaan juga dicatat. Dengan begitu, hasil akhir bisa diuji terhadap daftar yang jelas.

Mengumpulkan Kebutuhan Tanpa Terjebak Daftar Keinginan

Wawancara dengan pengguna harian sering lebih berguna daripada rapat besar. Staf gudang tahu persis di mana pencatatan sering terlambat. Staf keuangan paham titik rekonsiliasi yang memakan waktu. Setiap masukan sebaiknya dikaitkan dengan masalah bisnis yang terukur.

Daftar keinginan perlu disaring dengan skala prioritas, misalnya wajib, penting, dan opsional. Tanpa penyaringan, cakupan proyek membengkak dan jadwal ikut molor.

Perbandingan BRD yang Matang dan yang Asal Jadi

Tabel berikut membandingkan empat kriteria yang biasa diperiksa sebelum dokumen disetujui.

Dokumen yang lolos keempat kriteria itu memudahkan penyusunan estimasi dan jadwal.

Langkah Praktis Menyusun BRD Versi Ringkas

1. Tunjuk satu penanggung jawab dokumen dari sisi bisnis, bukan dari tim IT.
2. Petakan lima proses terpenting, misalnya pembelian, penjualan, stok, akuntansi, dan persetujuan.
3. Gambar alur tiap proses dalam diagram sederhana, lalu validasi bersama pengguna.
4. Tulis kebutuhan dalam kalimat singkat, satu kebutuhan untuk satu baris.
5. Beri label prioritas dan catat laporan wajib yang harus keluar dari sistem.
6. Minta persetujuan tertulis dari kepala setiap departemen terkait.

Peran Pendamping Eksternal dalam Penyusunan Dokumen

Perusahaan yang baru pertama kali menerapkan ERP kerap kesulitan menerjemahkan proses ke bahasa sistem. Di titik ini, jasa software ERP atau konsultan Odoo biasanya dilibatkan untuk memfasilitasi lokakarya kebutuhan. Mereka membantu mengubah keluhan operasional menjadi kebutuhan yang bisa dikonfigurasi. Keputusan akhir tetap berada di tangan pemilik proses.

Pendamping yang baik lebih banyak bertanya daripada menawarkan fitur. Pola ini mencegah dokumen berubah menjadi katalog produk.

Pertanyaan yang Sering Muncul Soal BRD

• Apa bedanya BRD dengan spesifikasi teknis? BRD menjelaskan kebutuhan bisnis, sedangkan spesifikasi teknis menjelaskan cara sistem memenuhinya.
• Berapa lama BRD ERP biasanya disusun? Lamanya bergantung pada jumlah departemen dan kompleksitas proses yang dipetakan.
• Apakah BRD boleh direvisi setelah disetujui? Revisi boleh dilakukan lewat prosedur perubahan yang disepakati agar jadwal dan biaya tetap terkendali.

Arah ERP ke Depan Bergantung pada Kualitas Kebutuhan

Implementasi ERP kini kerap dijalankan secara bertahap, modul demi modul. Pendekatan ini menuntut kebutuhan bisnis yang tertulis rapi sejak awal. Rujukan tentang pendampingan penyusunan kebutuhan sistem dapat dipelajari di www.i2cstudio.com, situs milik i2C Studio. Pada akhirnya, BRD yang jelas menentukan seberapa mulus sistem diterima pengguna.