The creation of an ERP requirements document is one of the most significant steps on the way to implementing an ERP system. It creates the basis for successful supplier selection and the implementation of a suitable solution. For this reason, those responsible regularly ask themselves what the optimal requirements document structure looks like in practice.
On the one hand, it is important to keep costs to a minimum and, on the other hand, to choose a level of detail that takes all important factors into account. This guide will show what an ideal ERP requirements document looks like.
Creating an ERP requirements document: basic considerations
The preparation of a requirements document requires a structured approach. First, clarify some basic questions:
- What does the company need an ERP system for?
- Which corporate goals should be achieved with the introduction of the system?
- Which processes do you want to optimize?
An in-depth discussion of these factors is the basis of a successful system implementation. Your later requirements should be consistently oriented towards these goals, and the corporate strategy must never be ignored. Particularly in the context of digitalization and Industry 4.0, considerations must be made as to what the future direction of the company should look like. In the requirements document, you ultimately express how the new ERP system contributes concretely to supporting your goals, strategy and processes.
Want tips on writing a better ERP RFP? Click to download the guide here:
ERP requirements documents are used multiple times
Keep in mind that a requirements sheet is not only written for the purpose of evaluating ERP providers. It will later be converted into a functional ERP requirements document and become part of the contract with the selected ERP provider. In addition, during the implementation process, it will also provide the basis for testing and acceptance. Because of this, the requirements document must be written to be understandable both for the ERP providers and for your own users inside your company.
An ERP system must be able to adapt to your processes - and not vice versa
When creating a requirements document, you shouldn't limit yourself to describing required functions. Rather, focus on clearly defining and describing the required business processes. If no complete or current process descriptions are available, they must be created. In this context, it makes sense to correct any known vulnerabilities by planning a definition of optimal target processes. Once the optimal processes have been defined, the required features can be determined in the second step. Of course, the rule of thumb always applies: An ERP system must be able to adapt to your processes - and not vice versa.
Define, refine and correct your business processes as part of writing your ERP requirements document
Involve specialized departments
After considering your processes and strategy, it's time to involve other departments in the company. After all, these are the users who will work most with the future ERP solution. It makes sense to have workshops to discuss the specific requirements for each of the departments, including production, accounting, sales, service and warehouse / inventory. Here, a distinction should be made between necessary and nice-to-have requirements, so that no excessively long wish lists arise. Include critics of the ERP project, which will pay off down the line with better acceptance of the implemented solution.
Once you have collected the input of all areas, an overall consideration must be made. The goal is not to optimize individual departments, but to harmonize the entire organization.
ERP requirements document: the right level of detail
The goal is not to optimize individual departments, but to harmonize the entire organization.
After defining the strategic and department-specific goals, next you can build the specific functional requirements. You're ready to start creating the spec sheet. While this this no trivial task, the trick is to choose an appropriate depth of information.
A too superficial requirements document leads to numerous questions and misunderstandings. The other extreme - a requirements document with maximum detail, which covers every eventuality - can hardly be addressed by ERP providers and leads to a workload that is not in proportion to the benefit. To achieve a balance between these two characteristics, the following rules of thumb are helpful:
- Describe processes and ERP requirements so that outsiders understand them.
- Do not lose yourself in unnecessary details.
- Avoid unrealistic "nice-to-have" features.
- Don't focus on standard features that are provided in all ERP systems (for example, purchase order-based invoice verification).
Ready to talk about your ERP project? Contact us today to set up a conversation or demo.
Don't specify a solution in the requirements
Another important rule for the ERP requirements document is to describe your requirements, but not their implementation. To put it another way: The requirements should always be solution-neutral.
This is best illustrated by an example. Let's say you need a feature to start your production. It's not wise to write something so specific as: "On the top left should be a red button, with which a production order can be issued," so you strictly exclude all ERP vendors who can not realize the desired button. You may even sort out solutions that automatically start the production order - for example, if it falls below a defined minimum stock level. A solution-neutral formulation of the requirement would be, for example: "A function is needed to start production".
Requirements document structure: The optimal structure
Of course, you can not simply string your requirements together without a structure when you create a requirements sheet. It is best to make a clean outline that looks like this:
- Description of the company
- Products, Services and Market Environment
- Strengths and unique selling points
- Current IT landscape (including number of users)
- Process-oriented description of functional ERP requirements (including reporting functions and interfaces)
Thus, you ensure that the requirements allow software vendors to interpret your requirements correctly.
Conclusion: ERP requirements documents are a critical part of ERP selection
ERP requirements documents support the selection of a suitable ERP provider and form the basis for a successful ERP implementation process. In creating your requirements document, it's important to consider higher-level corporate goals and strategies. In addition, close cooperation with specialized departments that will use the ERP system most is necessary. Ideally, you should create the requirements document in a process-oriented, structured, solution-neutral manner, with an appropriate level of detail.
Continue your learning with the abas ERP Resource Library, where you will find ERP white papers, how-to guides, and more, all related to ERP selection, implementation, pricing, and requirements.