BRD (Business Requirement Document) for ERP
What is BRD (Business Requirement Document)?
Whenever organisations contemplate implementing something big and new into their working systems or structures, a planned and project-oriented approach is helpful. Having a written layout of such projects is instrumental for gaining clarity of vision and in their execution.
A BRD or Business Requirement Document is one such methodology for preparing project planning. In many senses, it is not very different from a project planning report. So, it is better not to get confused with nomenclatures and see BRD simply as an effort of project planning that lays out the vision and other broad and critical elements of a project (implementing something new to business). And this BRD layout is done in a structured format that is useful to all stakeholders involved in that project.
What does a BRD constitute?
A BRD is required when an organisation decides to implement something. Now, implementing something or making any change is always preceded by some reasons. For example, a company may want to increase the footfall in their stores. This business goal is intended to be achieved through a planned and systematic series of steps and measures (a project, if we may call it). So, the company will prepare a BRD i.e. the project plan that draws the business requirements (goals and objectives) to be achieved and what is needed to be done to achieve these outcomes. A BRD typically constitutes the following elements:
- Business goals (e.g. increase in revenue from all stores)
- Business objectives (e.g. increase footfall in all stores by 10% in the next 6 months)
- Scope of the project (e.g. discounts, loyalty, merchandising )
- Activity requirements (e.g. plan, launch, measure, improve)
- Stakeholders (e.g. store managers, sales heads, marketing heads, regional heads)
- Constraints (e.g. maintain profitability, inventory management, standardised rollouts)
- Cost Benefits Analysis (e.g. anticipated investments and returns from the project)
What is the significance of BRD in ERP implementation?
ERP implementation is an exercise with important ramifications for business. There are business and functional goals and objectives associated with it. From planning to successful implementation, the entire exercise can take up to weeks. Multiple stakeholders are involved. Different areas of business operations slide into the zone of influence. Without a planned and systematic approach, there are high chances of failure or misfit systems and solutions coming into place. Developing BRD for ERP projects covers these challenges and brings ERP implementation into the ambit of planning and certainty. One of the most important derivatives of developing BRD in ERP implementation projects is the as-is process mapping.
An ERP must deliver the output a business requires. This connects ERPs first to business requirements and then process requirements. Outlining the business requirements is incomplete without translating them into operational requirements. Knowing the operational requirements is only half the answer because it would not tell the extent of change required in the existing state of operations. This takes the matter to analysing and defining the as-is processes. When the as-is processes or the existing state of operations are known, businesses are in a far better position to develop and outline the ERP functional requirements for use in BRDs for ERP implementation. It lets them gauge the gaps that have to be fulfilled and thus, accurately map the project requirements.
An ERP must deliver the output a business requires. This connects ERPs first to business requirements and then process requirements. Outlining the business requirements is incomplete without translating them into operational requirements. Knowing the operational requirements is only half the answer because it would not tell the extent of change required in the existing state of operations. This takes the matter to analysing and defining the as-is processes. When the as-is processes or the existing state of operations are known, businesses are in a far better position to develop and outline the ERP functional requirements for use in BRDs for ERP implementation. It lets them gauge the gaps that have to be fulfilled and thus, accurately map the project requirements.
Challenges in preparing Business Requirement Document for ERP implementation
Any deficiency in process orientation is the leading impediment to developing BRDs. If there are no demarcated ways of functioning in an organisation, identifying the business requirements for any exercise or change becomes a daunting task. An establishment not having clear processes in easy and comprehensible formats is one thing. But what is far more unfavourable is the absolute disregard for process orientation.
Developing BRDs for ERP is a time-consuming exercise. It involves the gathering of massive volumes of data and information on the prevailing processes and practices. Variances and nonconformities have to be eradicated to be on the same page with the final representation. Every detail of every operational activity has to be considered. Such an exercise can run up to weeks or months even with a dedicated squad working full time on it.
Developing BRDs for ERP also requires specific experience and expertise. After all, developing BRDs or ERP implementations is nowhere routine for businesses. For the same reason, businesses have no point in possessing any specialised internal resources for such one-off projects.
How BPX can help
BPX is a business process consulting enterprise with a scaling international presence offering cutting-edge solutions to business and non-business organisations in the areas of SOP (Standard Operating Procedure) development, process automation, process management, and quality management systems. Given below is a quick glance at how we approach developing BRDs for ERP with a focus on processes.
Redefining the business and process objectives
The awareness of the business and process outcomes is not sufficient; these must also be written down in unmistakable terms. We use surveys (including requirement gathering questions for ERP implementation) and conduct elaborate brainstorming with clients or their representatives to comprehend and define the desired process outcomes. A vital element of this step is understanding what clients want to achieve with the ERP solution under consideration. BPX deploys a team of skilled ERP implementation consultants to help clients decrypt their process and ERP requirements.
detailed process definition
The next step is the evaluation of the as-is processes and the existing organisational practices. Here, we try to find detailed information on the following areas:
- Existing procedures and workflows for a process
- Software and tools used
- Process owners, teams
- Timelines
- Standards of input and output
- Accountability, Reporting, and Supervision
- Formats of documentation involved
Process Gap Analysis
In process gap analysis, we examine the existing business processes in view of the desired process and business objectives established earlier. The aim is to spot the gaps between how a process is currently implemented and how efficient and effective it is at achieving the intended business and process objectives. By the end of this step, there is a full list of what is and what should not be.
Defining the To-Be Processes
After process gap analysis, we ascertain and define the new process workflows with the new operational standards. At this stage, our team may also implement relevant principles and practices of BPR (Business Process Re-engineering). In attempting to lay out the to-be processes, it is very critical to have a solid understanding of the ERP solution under consideration. The reason for this is that an organisation cannot have a process requirement that does not come within the capabilities of software technology.
Once our team has the insights and information from the aforementioned four stages, they are in a position to share robust inputs required for use in BRD document for ERP implementation projects which is sometimes also covered in the ERP system requirements checklist.
To know more about BPX’s ERP consulting services or if you want any business-related query on ERP implementation addressed by one of our ERP consultants, drop us a message and we will reach out to you.
Warehouse Healthometer
Start Free Assessment
FAQs
- Formulating BRD is an elaborate process. For a quick and easy grasp of the topic, here is what a BRD typically constitutes:
- Business goals (e.g. increase in revenue from all stores)
- Business objectives (e.g. increase footfall in all stores by 10% in the next 6 months)
- Scope of the project (e.g. discounts, loyalty, merchandising )
- Activity requirements (e.g. planning, launch, measure, improve)
- Stakeholders (e.g. store managers, sales heads, marketing heads, regional heads)
- Constraints (e.g. maintain profitability, inventory management, standardised rollouts)
- Cost Benefits Analysis (e.g. anticipated investments and returns from the project)