I've been talking to a number of clients recently and one common message I've taken away is that they want to align to Vanilla SAP. This could be a brand new SAP implementation, so customers who have never experienced an ERP implementation, as well as more established customers who want some new functionality activated. The size and industry sectors of the customers were very different, but each one expressed concern that any solution we implemented had to be Vanilla SAP. However when I visit existing customers to help them solve their current problems none of them have Vanilla SAP. Some have SAP ERP boxes, but the volume of bespoke code that has been written makes their version of SAP very hard to upgrade. Some don't even resemble a Vanilla SAP client as end-to-end processes have been bespoked within it.
Main reasons for change
There will be a number of reasons for customers moving away from their requirement of Vanilla SAP. I believe the most common to be...
SAP ECC6 not industry best of breed - current solution does morePoor project and change management to allow nice to have changesPoor understanding of what is Vanilla SAPLicence agreements and contracts from of 3rd party systems
Why go for Vanilla SAP?
Having the desire to start with a Vanilla SAP implementation shows a strong intention from the customer that they want to avoid costly developments. However, it is naive to believe that a large customer with multiple divisions and sites could fit their full processes into the standard Vanilla model. Customers sometimes try to remove the risk of developments by adopting the approach that they will bend their business processes to fit SAP, rather than the other way around. However let's be clear, to remove the need for development, full end to end processing would need to be performed solely in SAP, and not in 3rd party systems.
What are the implications of moving to non-Vanilla SAP?
Project sponsors are normally high ranking employees, some of whom may sit on the board. They would have spoken to similar customers who have undertaken similar exercises to try and learn from their experiences. The message that seems to be passed around is that SAP is a great product and can provide customers significant benefits in terms of cost reduction. However there will always be a warning around the evils of bespoking a solution. This will increase the cost and duration of the project, as well as the extra cost for support and maintenance of the system. This message seems to be taken the wrong way in my opinion.
If similar customers are warning of the extra cost of bespoke developments, I believe the project sponsor should take this on aboard and reflect this in their plans. If similar customers have to bespoke their solution, why does the project sponsor believe they can do without the extra costs their competitors have had? By asking SAP consultancies to quote for Vanilla SAP is one thing, but all this does is provide a cost associated to a project that wont actually be delivered. If budgets are based around Vanilla SAP, and that is not delivered the budget will be exceeded and the project may be seen as a failure. However the project sponsor has received advance warning and notification from its peers that they encountered bespoking.
Why do we reject Vanilla SAP?
The ERP system from SAP can cope with most business processes from most industry sectors. One of the main benefits of the system is the integration between modules and processes. Therefore if a customer chose to have wall to wall SAP, and no other system, integration, data mapping and interfaces would not be a problem. Further to this, the IT support department would not need to have specific teams to manage non SAP systems, and the need for non SAP hardware and licences would be removed. In most cases this is not possible. Whilst SAP spans a number of Industry sectors, the solutions in place are good not great. From experience customers will look at parts of SAP and not be that impressed when comparing it to their current IT systems.
Normally when ERP is implemented it is to tackle a specific business or technical issue. It could be that the customer wishes to reduce the volume of common IS systems. The objective to reduce as opposed to remove is telling, most customers will have some software that they believe is fine, easy to manage and do not see the benefit of removing the system and migrate it into SAP. If this is the case, any new SAP ERP implementation will need to be bespoked to send or receive information to 3rd party systems. It could be over time the 3rd party systems are removed, and by doing so this will enable the customer to move closer to Vanilla SAP.
Summary
Before coming out with the cliché of "We want Vanilla SAP", the customer should try and obtain what Vanilla SAP actually means to them. What will they gain from using the basic template, and what areas will they need to bespoke. Non SAP systems need to be considered, as issues around common master data will increase the complexity of the SAP solution. Further to this, where SAP cant meet all of the requirements the project team need to consider the best course of action, either keep with the existing non SAP solution, or bespoke part of the process in SAP. When planning a new SAP ERP implementation, having the intention to keep "as close as possible" to Vanilla SAP could be an objective - however there should be some budget spare to cope for areas where developments and interfaces will be required. Having an "eyes open" approach will lead to the final solution aligning closer to the expectations of the project sponsor.
