After the first part In our ERP costs series, we looked at the basic orientation of an SAP Business One implementation. AddOns and their - also financially sensible - use in B1. Now it's time to move on to a part of the topic that is particularly important to us as a provider and consultant: working together with the customer in the SAP Business One project.
Cooperation between customer & provider: Relevant for the costs?
But yes! If all attention in the SAP Business One project is focused on licences and service costs, the customer's own efforts are quickly forgotten. The customer's own commitment is not an option, but is necessary for the success of the project. Project success. One hour of time invested by the consultant equates to two hours of work for the customer. However, this calculation can only be applied to projects of a certain size - the larger the project, the less.
Questions also cost: Evaluation can be expensive
You are already investing in your ERP system when you are still looking for it. Selecting the right offer requires many hours of work, which must also be remunerated. All relevant colleagues should also be present at the meetings and presentations of the providers. This also costs money. You can save money if you make it clear from the outset that the priorities for the new system are in line with the company's objectives and that "nice-to-have" requests cannot necessarily be taken into account (see Part 1). This will save you a lot of time, effort and therefore costs.
Tip: Define the procedure and evaluation - e.g. questions - for the presentations in advance. This makes it possible to compare the offers.
The reality is that personal sensitivities always play (too) big a role in the selection process. That is why process analysis it may make sense to seek external help. Although this costs money, it is often more effective for selecting processes that are relevant to the company.
Furthermore, you should not be too hasty in choosing a provider. Often it is only during the elaboration of the Specifications clearly what your requirements are and who can best fulfil them. You should also orientate yourself to the company's objectives here. Requirement specifications based on the current status are simply not useful for the ERP project - but they cost time. Here, too, an external consultant may save money, as utopian requirements are often set out in the specifications, which can lead to the wrong choice of ERP partner.
Our tip: Involve your favourite providers in the creation process. They know best what advanced options await you in the new software and what you can expect.
Focus: specifications instead of contract negotiations
The implementation of the Specifications is required by the customer. The processes you require must be harmonised with the existing processes in the ERP system. It is only in your interest to co-operate in this. This allows you to check whether the implementation makes sense during the creation phase and correct any misinterpretations of processes. The investment of time and effort is also worthwhile at this point. Because the more realistic and detailed the specifications are, the greater the chances of achieving a realisable fixed price.
In return, you can cut back a little during contract negotiations. The rule is: concentrate on the essentials! If you want to regulate everything contractually, it often leads to a hedging reflex. This increases the size of the contract immensely and soon requires the assistance of a lawyer - on both sides. It's better to rely on a partner you can (and want to) trust. This is the only sensible approach in the long term anyway.
Tip: It's better to put off drawing up service contracts until later. Especially if you are relying on a trusting collaboration in the project, it is better to set out the service conditions in a contract afterwards. Then both parties know each other better and know what to expect from each other.
Invest correctly and avoid hidden costs in the SAP Business One project
We have reached the realisation stage. If you look at the work involved up to this point, you can imagine what you will be facing. It may therefore be necessary to assign one or more employees - depending on the size of the project - to the implementation. After all, you are not doing yourself any favours in any cost plan with employees who can only half-dedicate themselves to various tasks. Furthermore, from a certain company size, it is advisable to deploy one key user per department. Not only can they create realistic user documentation, they can also serve as internal support for their colleagues. However, this should not be a reason for the management to withdraw from the project. Decisions or short-term changes can only be understood if you are part of the process. It also does no harm if someone keeps an eye on the project as a whole.
An important topic in every ERP implementation is the preparation of legacy data - often a "hidden" cost driver. The effort involved is often underestimated by customers, even for an SAP Business One project, as the data records usually do not meet the standard for transfer to the new system. Anyone who tries to assign employees to perform short-term miracles using Excel usually ends up on the wrong end of the stick. Better to bite the bullet and enter the data manually into the new system. Software transfer - or have them transferred 😉
You should also not skimp on training. There are two options here. Either you try to get all employees around the same table and have a corresponding coordination effort. Or you simply invest in more training. It also makes sense to invest in sufficiently trained employees, as only they can test the software.
Tip: The same applies here as for the provider presentations. Before testing, draw up a guideline on how you want to proceed: How to test, how to document and when.
Data quality & AI : AI can only be as good as your data
AI-ERP transformation basics and AI governance
Monolithic ERP systems in SMEs: challenges, solutions and risk management
From data tomb to think tank: AI in ERP systems
Software validation in medical technology
