They take time and money - more than necessary if you're not careful. Requirements specifications should help in ERP projects keeping track of costs and time management. But even a specification is time-consuming and needs a lot of attention.
What is the point of a specification?
Just in ERP projects much revolves around time. The long hesitation of some companies before introducing a new system increases the desire for a timely implementation. The time-intensive search for the right system is also a reason for a certain tension towards protracted ERP implementations. Nevertheless, projects should not be approached under time pressure. A specification sheet is intended to remedy this. Through the precise documentation of wishes, possibilities and implementation plans, the customer as well as the ERP provider be clear about the process, the time frame and the financial background. To this end, the company must first open all doors to ensure that the provider has the necessary insight into the work processes. Then, initial suggestions can be made about the processes in the new ERP solution be made. However, the customer often already has precise ideas about which processes he would like to have, how they should be mapped or which ones he would like to take with him. This is the first point at which the actually helpful specifications become a time robber. Especially when the processes only reflect the status quo without taking into account the conditions and possibilities.
Too accurate also goes
Furthermore, it is often not the best idea to define all goals precisely from the beginning of the project. In most cases, the project is rethought during the project because work processes have to be mapped differently or in a different place. Here, a requirements specification weighs on the flexibility of the project, which nowadays can be made possible by the providers and systems. Drawing a target line right at the beginning and defining the success of the project by achieving it is limiting.
Plan between aspiration and reality
One often hears that time and cost management get out of hand without specifications. What is forgotten here is that in very few cases is the planned timeframe and the budget are adhered to. This is another point that only generates frustration and disputes and thus becomes a time-suck. Of course, nothing stands in the way of a proper schedule - but a specification sheet is not necessary for this. Instead, a constructive calculation with a flexible planning can be well harmonised. Instead of firm promises, there are honest answers here - so the company has the possibility to plan time and financial buffers in such a way that the project always remains within the bounds of what is feasible.
It all depends on the ERP partner
The legal basis also drives many companies to demand a specification from their provider. However, many of the points of contention arise precisely because of this. An ERP project is often more successful if both sides can work together openly and flexibly and do not get bogged down in detailed definitions. Of course, the provider must be contractually obliged to fulfil its obligations. However, it is more important to find a provider who knows how to fulfil their task of a good implementation even without a requirement specification than to bind them to their "obligations". The time spent searching for a suitable provider will pay off in any case. I promise!
The actual success of the project
The question remains, what can be used to measure the success of the project, if not a functional specification? Here, there is often the misconception that it is possible to determine whether the project was successful directly after the new system has been put into operation. However, project success with ERP systems means much more than simply implementing the new processes. The way the company deals with it plays a much more important role. The questions that arise here are much more: how is the system being used, are all the processes being used? employees have been integrated during the introduction and do the processes prove themselves in use? Here, internal project management and software training contribute far more to the success of the project than any requirements specification.