image“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” That’s the very first principle of the Agile Manifesto.

The problem with ERP is that the first deliveries are all but early: they typically occur only after about twenty months.

Twenty months is a heck of a long time. And value achieved after a twenty-month implementation is often far below expectations.

The largest share of the implementation time is usually spent on customizations. Their goal here is simple: to turn a standard (or “vanilla” as I call it here) ERP solution into a custom one, tailored specifically for the customer’s needs. The most value is achieved when the solution reflects the processes directly, so the closer you get to the specifics, and the closer match you make between the processes and the solution, the more value is achieved.

This is theory.

The practice shows that only one out of five companies achieves more than half of anticipated benefits. With SAP, more than half of the companies who did customizations never got the invested money back. After the implementation, the match between the processes and the solution is obviously not that close at all.

Agile calls for something radically different: instead of waiting for twenty months before you deliver something (which often doesn’t even meet the expectations), you should try delivering value as soon as possible.

How soon is as soon as possible? With ERP, it’s immediately.

With ERP you don’t have to develop anything before you get something valuable. ERP software, such as Microsoft Dynamics NAV, comes packed with generic best-practices functionality. The value in such functionality is that you can put it to work immediately, without any coding, and be sure that you are on a good track: it’s the common denominator of thousands of implementations worldwide. If it has worked for thousands of others, it should work for you.

With months-long customizations you aren’t guaranteed to deliver value and you don’t know whether success will follow or in what extent. With vanilla deployment you know both: your degree of fit tells you where to expect success and exactly how successful you are going to be.

Most customers suffer from “the old software syndrome”, and whatever you bring to the table will be judged from that perspective. In their old software they could do this or that; if their new software can’t offer at least that, it won’t be received well. Naturally, the customer wants their new software to be better, but with an abstract requirements analysis conducted over a telltale of perceived needs, followed by a year or so of design and development, it’s difficult to hit the target.

With vanilla deployment you have a unique chance to make NAV (or whichever ERP) their old software up front. You first deploy it, and make them use it without much theory about what they are going to get. What they see is what they get. Full stop. Give the customer a chance to use the vanilla ERP in daily operations—they will be much more qualified to tell you what you need to customize, and you’ll be much more sure that they are actually right.

Whatever you do to modify the vanilla flavor, you make it more difficult for you to maintain the software and for your customer to use it. So, every change you do should translate into clear added value for your customer. The customizations are aimed at adding value, but they aren’t guaranteed to do so.

Ironically, customizations don’t add value by default. By default they subtract value. Every customization subtracts value in the short run, through analysis, design and development time; and long run, through upgrade, maintenance and support. You must make extra sure that all these tasks add more value than they subtract, through increased productivity, reduced error or another measurable benefit, in order to achieve positive grand total balance of investment and return.

With vanilla, you don’t have this problem. The initial investment is low—certainly lower than with big-bang customizations approach—and return is more certain.

Tomorrow I’ll continue with the second rule: gradual deployment. Agile is about continuously adding value, and with vanilla deployment you have only made your first step.

In the meantime, please share your opinion. Let’s discuss.

Read this post at its original location at, or visit the original blog at