Specifications in the ERP project - help or hindrance?
10 March

Specifications in the ERP project - help or obstacle?

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.


Why 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 mapped and 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. A functional specification is a burden on the flexibility of the project, which can nowadays 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 only arise because of precisely this. An ERP project is often more successful if both sides can work together openly and flexibly and do not stiffen on petty detailed definitions. Of course, the provider must be contractually obliged to comply with its services. However, it is more important to find a provider who knows how to implement his task well, even without a specification sheet, than to bind him to his "obligations". The time taken in the search for a suitable provider will pay off in any case. Promised!

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.


Leave a Reply

Your email address will not be published. Required fields are marked *
You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>