Skip to Content

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.


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. 

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Non-Vanilla – I think the biggest reason is because a company’s software (business processes) can save a lot of money.  Therefore, Each company’s processes slightly differ to deliver the best advantage.  Once that happens, most likely SAP will no longer be “vanilla”.


    1. Former Member Post author
      the key to any ERP implementation is business benefit. If Vanilla does not provide the benefits a customer is looking for the need for Vanilla is removed.

      However too much bespoking and they end up creating a beast that costs a lot to support and maintain.

  2. Otto Gold
    I liked reading your blog despite the topic is not very new, we ale were asked to provide vanilla SAP and none of us has ever delivered vanilla SAP. It`s like yeti, everybody speaks about it but no one has ever seen this:))
    My opinion is that one should also blame the consulting companies. Why? Less development = less money, nothing close to vendor lock-out etc. There is another important reason for that – lack of expertize of top quality resources: if you`re asked to deliver vanilla, you need a team of skilled people who know what is the vanilla capable of, how that works, how it must beconfigured etc. And I have never worked on a project where all the members of the team, or at least a half of the team (it was FAAR less) possesed enough knowledge to be able to deliver vanilla SAP:
    * to explain what it can do and what it can`t do
    * help the customer find the best balance between the standard and custom development
    * blah blah
    I have heard some nice things about your company, so please don`t feel offended, but could you deliver the vanilla SAP? Do you have enough knowledgeable people who don`t have other stuff on their plates to send them to such project?
    Cheers Otto
    1. Former Member Post author
      Hi Otto,

      Thanks for your reply.

      I dont think you can put the whole blame on the consultants, if a client is insistent that their system must do a, b, c which are not standard then you would move away from standard SAP.

      Consultancies are there to provide direction and insight, however there is a famous saying

      ” you can take a horse to water, but you cant make it drink”

      In terms of your view around consultants not knowing Vanilla, I would disagree with this.

      If you take ERP for example, a typical certified consultant would have good knowledge around Vanilla SAP, however without good process knowledge providing bespoke solutions could be more challenging.

      I would feel comfortable deliverying vanilla SAP to clients. However, if the end product were to be pure vanilla, I would look at the project to ensure that change management was being performed as the client would need to change its processes.


Leave a Reply