In early November, we discussed standards for the selection of ERP systems. Now we are following this up with the next step, the requirement specifications.
A new ERP system is not selected randomly: After all, it is the backbone of the company. Thus, a structured set of requirements facilitates the thorough preparation for the decision. And to rearrange the terminology once again, as requirement and technical specifications are often mixed up: In the requirement specification, the client defines the entirety of his requirements. The technical specifications later describe in concrete form how and with what the contractor wants to solve these requirements.
Describing requirements
This sounds simple at first. But in most cases it’ s not. When people describe things, they often assume that their counterparts have the same level of knowledge. Assumptions that are taken for granted are therefore not explained in detail. In addition, in any communication between sender and receiver, information does not arrive or is left to be interpreted by the receiver. All of this can lead to misunderstandings and confusion.
On the other hand, aspects that would be helpful or even indispensable for a correct understanding are often overlooked. Many approach this by giving detailed descriptions of all requirements. However, this has the disadvantage that the volume of work is enormously high, and the requirement specifications turn in to an overflow of work that can no longer be mastered.
For this reason, the questions should not be answered over and over again, but instead briefly and concisely. Too many details can make it difficult to understand. As is often the case, everything comes down to a happy medium: Among the rather concise texts are sketches, drawings, functional analyses, models or a matrix, which provide ample opportunities to describe the requirements.
Not all requirements that are selected for a specification are equally important. It is always important to ask: Where is the highest level of discomfort at the moment? Which goals are to be achieved? What distinguishes us from other companies? What are the functional requirements for a new ERP system and why do they exist?
When should one begin?
The question of when to start with the specifications does not normally arise. When the desire is born to replace the ERP system, there has already been experience with processes and functions that have proven to be disruptive in existing systems or software solutions and which should be avoided with a new system. This is a good basis and the first step towards the requirement specification.
With this piece of background information, the person responsible for ERP selection should sit down with the departments in the company as early as possible. Since the company’s strategic goals are usually at the forefront, the management is of course called upon to do so again (I have already explained in the article pertaining to the ERP-Guideline, that the selection of an ERP system is a matter for the management). We are looking for answers to the following questions: Where are we heading as a company over the next few years? In which direction is the market going? Which legal framework conditions could change? Are there any new trends that we need to think about today? What makes us strong and how can we build on these strengths?
„A requirement specification is not a doctoral thesis. Supplementary sketches, drawings, functional analyses or a morphological matrix are often more suitable than endless texts. Contradictions are usually easier to uncover and resolve when the requirement specification is converted into a technical specification“ – Bernd Zipper.
The next step is to define a timetable. Three months would be realistic for drawing up a requirement specification. But it can also take much longer if the creation of the specifications trigger a reorganization project. However, one should not lose sight of when the decision for the ERP system must be made.
Do not use the wish list method
When discussing the task at hand with the departments one should not make the mistake of asking everyone to submit proposals. Some departments respond with ten-page wish lists; others limit themselves to two lines. This inevitably leads to a considerable need for clarification. Therefore, the “wish list method” does not lead to a meaningful requirement specification. It is better to have discussions within the departments in which interfaces to other departments must then also be clarified.
In which department should you start? The decision is made using either the “added value” method or the “emergency response” method. The value-added method is based on the processes of the company. The value chain is outlined in a corresponding degree of abstraction, starting with the department that is the first link in the chain and continuing successively until the last link. The content of the specifications grows organically with this method.
With the emergency response method, an overview of all ERP-relevant issues in the company must first be obtained and sorted by severity. This method offers more possibilities for an entrepreneurial design. They often say that diamonds are created under pressure.
Structure of requirement specifications
Not all arguments in a requirement specification are equally relevant: Some are indispensable, others unnecessary, but desirable. Therefore, here is an outline of how a requirement specification can be structured:
- Company description: Introduction to the company, its subsidiaries, branches and the like. Are the company locations independent of each other? How many employees are there? Is there a guiding principle? A growth forecast will round off the picture.
- Contact person: Small organization chart and who does what. How far do the competencies of the people in the evaluation team go?
- Market environment, products and services: What does the market in which the company operates look like? What products and services does the company provide?
- Unique selling points and strengths: What are the unique selling points or special strengths? What will be improved in the future with the help of a new ERP system?
- Current IT infrastructure: Cloud or on-site? Is there a purchase or rental model for the licenses? It is important here to name the interfaces.
- Functional requirements: Standard functions that are provided by modern ERP are negligible. On the other hand, special features must be dealt with in detail: Where does the company perform differently from its competitors?
- Timetable: When will the requirement specifications be sent to the suppliers and by when should the offers be received? When will the shortlist be drawn up and when are one- or two-day workshops with the individual providers planned? Six months is a realistic period for evaluating a comprehensive ERP system. Vacation times and production peaks must also be taken into account.
In order to assess which functions are standard in an ERP system, you need either experience or help from an expert.
