ERP specifications - what are the contents? Business processes and process requirements are the basis for this. Analysing these are important tasks in the context of an independent ERP selection. Conducting cross-functional workshops to compare software requirements is one of the crucial activities in defining ERP system requirements. An ERP requirements specification and an ERP specification based on it are the most useful and efficient forms of documenting the existing requirements.
The ERP specifications mainly describe the processes that are required in the context of a new ERP implementation. The ERP specifications contain existing, necessary requirements as well as new processes to be supported. The ERP specification is one quality level more.
The requirements specification as documentation was supplemented by the possibilities of the software in question, it is possible ERP workflows and solutions that the ERP provider is able to deliver with its ERP system. In many cases, the ERP provider can also propose solutions that may be used in the customer's process landscape.
Where can this occur?
Mostly when the software provider can present a solution proposal in its ERP software with which the customer can solve its requirements without individual programming.
ERP specifications - this is a question that all entrepreneurs, project managers and IT managers who have to deal with the renewal of ERP software or other IT systems are faced with. Many different terms are sometimes used as representatives:
From the point of view of the ERP system provider (software supplier), what has to be achieved is described. From the point of view of the client - i.e. the investor - it is described what he expects from a new ERP software. This makes it easy to see that there can be different ideas - simply because of the points of view or the interests involved,
First, a little note on the legal situation: what do the legal regulations say about buying ERP software or renting ERP software or using an ERP cloud solution?
Crucial for companies that need to select ERP systems is first of all the difference between:
Service Contract according to BGB §611, and
Contract for Work and Labour according to BGB §631.
Another point that is important in ERP projects is related to the implementation methodology.
The term agile project management is often used by software suppliers at sales events or in marketing information. Sounds good at first. Sounds very modern. But it also harbours dangers for the buyer and user.
From now on, it becomes exciting for companies looking for ERP software, as it is now a matter of looking at the contractual obligations.
In agile project management, the exact goal is defined during the project. All participants in the ERP project have a large tolerance to define in terms of scope, time, cost and quality of the IT project. The characteristic approach is to focus on a piece of work where user approval is the main focus.
Since there is as yet no real standardisation of what can be understood by agile project management or agile ERP implementation, this term is also often used to represent a new way of thinking or a new way of project management. It is meant to make clear that it differs significantly in agility and dynamics from project methodologies such as Prince or waterfall methodologies.
But:
It is elusive, even impossible, in contract management to realise an ERP implementation with the ideas of the contract for work, because the work owed is only defined in the course of project management. This risk must be clear to the buyer.
What we want to make you aware of:
In the case of the service contract, you will buy or use software where the software house assures you - as far as it is possible - that the software itself will perform its service without errors. At the moment, it does not matter whether you install the ERP software in the data centre or use it in a cloud as Software as a Service (SaaS).
Within the framework of a contract for work and services, the software company guarantees you features that you, as a potential customer and ERP user, require from the system. Mostly, these are special workflows and processes in your company. Workflows and approval procedures are also among the individual requirements that companies place on ERP software.
The software supplier usually wants to sell his software. He will assure that it runs - as far as possible - without errors, complies with quality standards for operation and interface and can operate interfaces. This sounds good at first. But is this what companies are really looking for when they select software, renew or replace ERP systems?
Actually, you as a company want your processes to be supported and improved. This should be done with software support.
We find that in all our ERP consultations - and there are now more than 400 ERP selection processes - this is only a small aspect that is taken for granted.
Companies want to improve processes to varying degrees, to obtain features and functions that they did not have in the old systems. They want to reduce interfaces and, if possible, also like to get everything from "one source".
The progress in IT technology, the speed of innovation and the possibilities of modern hardware have increased enormously in recent years. Where a few years ago it was unthinkable to work on computers and solutions in a cloud - today it is standard. Requirements for mobility and access to ERP systems 24/7 now standard. Ease of integration and short learning curve for new staff with ERP systems - now standard Hybrid solutions, - storage in the cloud and working in your own hosted solutions (on premise) - now standard. This applies to a whole range of new business solutions and process supports of modern IT architectures.
For all the functionality, technology and beautiful management cockpits, it must not be forgotten that the only reason for a new ERP system is:
Above all, however, our customers want to improve competitiveness and enhance performance for the customer.
This also includes the restructuring or redesign of business processes, the reorganisation of workflows, the automation of recurring processes and much more.
However, all these requirements, process improvements and process optimisations must be described. Most sensibly as a business process. As an unambiguous process in a comprehensible language and notation.
As a rule, the preliminary stage of the ERP specification is an ERP specification. This is then developed into a functional specification together with a software provider. The requirements specification then becomes part of the contract.
This gives companies the opportunity to define the changed business process as a target specification in the requirements specification. The process support is provided by the new ERP software. This brings us to the possibilities offered by a contract for work and services according to BGB §631, which calls for the fulfilment of a service. A fulfilment of a new business process that helps our customers to improve their competitiveness. This can be done through efficiency gains, through a reduction in inventory and an increase in the goods turnover rate, or through process acceleration.
In the course of the Covid pandemic, it became clear that a decisive competitive advantage can also be the availability of goods. Goods availability presupposes an intact supply chain. These are elements and requirements that must be described in ERP specifications. This is because they are very different from realising efficiency gains by reducing inventories, as they take a different approach. Be it by improving the supply chain or by the ability to generate new processes to better meet customer requirements through an end-to-end ERP system.
This service, these ERP requirements, are of course much more difficult for a software company to carry out because the process performance has been defined. At the same time, it is more binding than simply delivering an executable ERP software. We are not necessarily loved by the software suppliers for this. But our customers can be sure that the ROI, i.e. the "return on your investment", is calculable and achievable. This knowledge about the best processes, workflows, selection and project strategies for the introduction of an ERP, MDM or other software is usually not always available in companies. The rapid changes in customer requirements require professional knowledge of skills to map these into a software selection. An external consultant must know the requirements of the industry and be able to lead.
Even from the small list of these points it becomes clear that software selection by Excel list, in which only functions of ERP systems are queried, is an outdated method. For companies that are concerned with their future competitive strength and customer processes, this cannot be an option, nor should it be, because it only cements the existing.
With every investment in a machine, plant or even an office chair, companies usually have clear definitions of what they are ordering and what is to be delivered.
Complex systems such as software that affects the entire company are difficult to define in terms of what has been delivered. ERP software is ordered from the software house or the ERP software partner. The basis is a description of what the ERP software or, more specifically, the ERP industry solution can basically do. The basis is often sales and demo presentations as well as rudimentary descriptions of the software requirements.
But isn't it the case that you buy software because you want to realise a competitive advantage? And because you want to optimise, streamline, improve and make more cost-effective the value-added processes to your customers?
If this is the case, then it is an absolute necessity to create a process description (first the ERP specifications and then, after evaluation, the document enriched with notes from the ERP software company, the ERP specifications).
This will decisively describe your business processes that are supported by the ERP software. The interfaces, the inputs and the presentation of results, as well as the user concept are mandatory criteria of an ERP specification.
Only with this ERP specification can you describe the support performance of the software, the ERP specification becomes part of the contract and thus you also have a document that you can use for the acceptance of the ERP system and as a template for the test management.