Requirements gathering is a crucial step in any ERP implementation project, as it lays the foundation for the entire project. It involves collecting and documenting all the necessary information about an organization's existing business processes and future goals. This process should begin even before engaging with a solutions partner/advisor, as it is often a project in itself.
To collect and document requirements, organizations can start by identifying key stakeholders who will be affected by the ERP implementation and soliciting their input. This can be done through interviews, surveys, or focus groups. The focus of requirements gathering should cover all aspects of the existing business processes, as well as the future state of the business processes.
Requirements can be classified into different categories, such as functional requirements (what the system should do), non-functional requirements (how the system should perform), technical requirements (what technology should be used), and data requirements (what data is needed and how it should be managed).
To ensure that all requirements are collected, it is important to have a structured approach to requirements gathering, which includes a well-defined scope, a clear understanding of the stakeholders, and a systematic approach to documentation. External firms and advisors can be engaged to support the organization in this process, as they bring in niche expertise and the ability to pay attention to important details. Ultimately, a successful ERP implementation project requires an exhaustive requirement collection and analysis to ensure that the final solution meets the organization's needs and achieves its business goals.
To ensure that there is a clear connection between business processes and requirements, it is important to collect requirements in detail and link them explicitly to each process and sub-process. One helpful technique is to ask the five or six W's (Why, What, Where, Who, When, and Which/How) to gather enough information.
It is important to consider all the business processes and their sub-processes to prepare the requirements list. All requirements should be linked to at least one process/sub-process, and there should be no process/sub-process without any requirements.
To document requirements, a hierarchical approach is recommended, where goals lead to business processes, which lead to sub-processes, and ultimately to requirements. Any requirement that does not belong to a business process should be validated with the out-of-scope criterion and addressed by the change control board.
Business goals refer to the high-level objectives that a project is intended to achieve. In a project, goals are defined in the project charter and are achieved by following a project plan. The project plan breaks down the goals into smaller, manageable tasks.
A business process is a set of interconnected activities or requirements that can be represented in a flowchart. A business process can be broken down into sub-processes, which are also represented in a flowchart.
In many organizations, business processes are categorized into specific domains based on industry-specific nomenclature. For example, record to report involves managing financial and ledger information, order to cash involves receiving and processing customer sales, procure to pay involves ordering and processing vendor invoices, and plan to produce involves creating and building products or services.
Business processes are typically represented visually using flowcharts and can be used for training, testing, and solution acceptance. A set of business processes needs to be followed to achieve the goals of a project, as per a generic industry nomenclature.
Sub-Processes
Sub-processes are an essential component of business process modeling and help in breaking down a larger process into smaller, more manageable parts. Each sub-process represents a set of related activities or functions that are required to achieve a specific outcome.
By breaking down a complex business process into sub-processes, it becomes easier to analyze and optimize each individual step of the process. It also helps in identifying the dependencies and interconnections between different parts of the process, allowing for better coordination and communication between different teams and stakeholders involved in the process.
In the example given, the sub-processes required to cash a business process include order intake, order processing, order release and credit checks, product and service sales, pricing and term agreements, consignments, picking, packing, and shipping, customer invoicing, customer payments, intercompany documents, and returns. Each of these sub-processes represents a specific step in the overall process of cashing a business process and must be performed in a specific sequence to achieve the desired outcome.
Overall, sub-processes are an important tool for business process modeling and help in improving the efficiency, effectiveness, and transparency of business processes. They allow for better communication and coordination between different teams and stakeholders involved in the process and help in identifying areas for improvement and optimization.
To ensure the success of a Microsoft D365FO implementation, it is important to gather requirements in a structured way. This can be done by defining requirements as SMART, providing detailed information about business needs, assigning each requirement to one person, and sharing and reusing requirements in multiple sub-processes. It is also beneficial to have the business blueprint, processes, and sub-processes prepared before starting the initiative. Requirements can be collected at the start or during the CRP pilot, and documentation of the requirements is necessary using various techniques.
