“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.
Pingback: Navigate Into Success
I like the premise of this blog, but I wouldn’t want to be the one pitching this to people. I wonder if anyone has some real world experience with an implementation along these lines. That might point out some bottlenecks.
FUnkygraz: you are right – pitching this to people is probably unpopular, because everybody is so used to traditional approaches. I’m not affraid to express my thoughts, after all this is blog, not a customer project, and there is nothing bad in sharing opinion, no matter how wrong it might be. I don’t have real world experience in implementing the agile way, but I’ve seen many projects implemented the traditional way. They made me think of possible different approaches 🙂 Specifically about “vanilla” approach, I do have some evidence that it works – I’ve got confirmation from a manager of one NAV customer who said that “it’s the right way to go”, and also I saw statistics: those that tell us how unsuccessful customizations can really be, and those that tell us how ROI is sometimes unattainable with heavy customizations. I have also read somewhere (and I am mad that I can’t recall where exactly, and I can’t google it up) that only 5% of Fortune 1000 companies that implemented ERP actually customized the ERP. They implemented the “vanilla” ERP and modified the processes.
“Vanilla” approach definitely has problems associated with it, and it calls for change in organization, attitude, approach, processes… It emphasizes the role of every single participant in the project, and if there is no user involvement, project management, executive support and commitment, then agile will turn into anarchy and failure. But no project should go without user involvement, project management or executive support–those that do, fail no matter the project approach, agile or waterfall.
What I am arguing here is investment/benefit ratio of agile vs. waterfall all other things being equal.
Your blog actually led me to read the Report from the Panorama consulting group again. Personally i think that the agile methods could be very efficient when combined with other modern software engineering principles so ill be looking forward to the other posts.
And the question for real world experience was more a call for other readers to comment with their “tales of wonder”.
PS: I think that the new crops of software engineers being hatched right now ( Much like myself ) could really benefit from posts like this. I was educated with Agile in mind but coming into ERP projects its hard to remember them sometimes.
P.S: I just want to get XP programming so i can have someone second chair me and get coffee
FUnkygraz: Mark Polino has shared some of his experiences with agile ERP at http://msdynamicsgp.blogspot.com/2009/03/agile-erp.html, check it out.
Hi Vjeko. This is certainly an interesting topic and I commented on your earlier post about my belief that vanilla may only be possible in the rarest of circumstances. I also agree that most customers do not really know what they want or what the vanilla product can do and the waterfall approach doesn’t really give them an opportunity to get to know the product properly before asking for changes. I mentioned in the last post comment that we should probably go live with Vanilla+Must Have features (such as interfaces). I think I am going to read those links you put up so that I can get a bit more of an understanding of what agile is before I try and comment on whether it can be applied or not. In a recent project we used the MOSCOW (Must Have, Should Have, Could Have, Wish List) categorisation for requirements and we only took the Must Have and Should Have requirements through to the next phase of detailed analysis and design. I think that this goes some way towards being more agile in our implementation but like I say, I don’t understand the methodology well enough yet to really comment. Cheers, Dave.
@Dave: it’s about the comparison from our very book: how do you sell a car (plus options) to someone who’s only seen a horse? Before they start telling you how they think they should use the spurs, or what kind of a saddle they prefer, or whether they prefer leather or rope hackamore, it just might make much more sense to sit them in a care and take them for a ride. It migth be a revealing experience for them, even though a saddle and a hackamore might have seem a completel Must Have requirements up front. I don’t understand agile either 🙂 but after a discussion I participated in where I’ve seen a consultant defend waterfall against an agile activist, both pushing their ends and unwilling to give up an inch, I rethought my approach: before that I was all “agile is wrong; waterfall is great” thinker, just because I didn’t give agile a proper thought. Then I did, and I experimented a little with this series of posts – to solicit other opinions, to see whether it has worked for someone in practice, and to compare what I’ve seen work against what I’ve seen fail many times. That’s what this series of posts is all about; next week, I might change my mind 🙂 (especially in face of very strong points and facts)
I do agree with the idea of the vanilla implementation, but in practice it usually doesn’t work. We are currently in the midst of yet another upgrade to a newer version of our ERP, and the vanilla model just doesn’t work for our line of business. At the end of the day, value just isn’t the only thing that you are looking for.
Ease of use for users & reporting ability are highest on the list of priorities. If users are not comfortable with the interface or if you can’t get easy access to the information you need, then the “value added” benefit of sticking with vanilla is no longer a reality.
There is certainly some consideration needed of cost/benefit to the company. And you do need to make sure that you find out what users actually need (as opposed to just the “nice to have” or “wouldn’t this be great”). There is also some buy in needed from the users. It’s difficult for them to forget what they “used to” have. However, you have to look at how the system will work for you as a company. If some minor customizations to screen views or reports are all that is needed to render a moderately useable system much more functional, then I have to say that this is definitely the road to take.
@Fran: thanks for sharing your thoughts, they explain well what it is to watch out about during implementations. As you might have noticed, my post is not about “deploying vanilla, full stop”, but “deploying vanilla first”. I don’t think it is absolutely possible to have a completely vanilla ERP, especially if you are big. But starting from vanilla, instead of starting with a huge development appetite, can really turn a high-risk project into a very smooth one. As you say, some minor customizations are the road to take, and I agree. If something can be solved with minor customizations, then it should be done, but huge changes rarely work out very well.
About value, I don’t think “value” is something abstract. If you are focusing on ease of use & reporting ability, aren’t you talking about value? Ease of use translates into increased productivity and higer adoption rates, reporting ability translates into better decision making–all of this is value. And I am totally convinced that value must be the ultimate goal, nothing else. Because if you don’t get value, what’s the opposite of value? The problem with big customizations is often in that you are developing functionality and streamlining something that doesn’t contribute to the bottom line (i.e. value), directly as in reducing inventory, or indirectly as in increased user adoption. If your ERP doesn’t earn you value in the end of the day, then it’s a failed investment.
I would never say that “sticking with vanilla” is a long-term strategy, it’s merely a first step. Important thing is that value is not added based on some theoretic idea someone has come up with during analysis, but from real-life proof. When you know exactly that someting is needed, then you go and modify the vanilla ERP. Dave’s post about requirement analysis (Everyone lies at http://gaspodethewonderdog.blogspot.com/2008/09/everybody-lies.html) explains exactly how requirement analysis usually works, and why it fails, and how it should really be approached. My opinion is that it’s done the easiest (and least costly) way around exactly by going vanilla way first, then gradually doing step-by-step implementation of features that really add value, directly or indirectly.
The move to agile has been a gentle progression for me as expectations for outcomes from business system implementations increases, and becomes driven by real value and desire to improve processes. Software service companies using the traditional models are driving themselves out of the market by not grasping the opportunities to correctly assess value-add activities and functions, and use their system experience to help realign business processes. I liken the agile and lean processes with the Pareto princilple or 80/20 rule, that directs us all to focus on the issues that add the most value and have the biggest business impact.
Peter
Hi all,
How about the customer? You cannot impose the vendor’s will on the customer.
The vanilla approach is acceptable if the software has configuration flexibility built-in. In reality it is the contrary: Due to poor design and shortcut taking, the software has no valuable tool to adapt to the company’s business process. It’s usually all hype, vendor style.
My 2 cents
@Jacques: Thanks for the comment. You are completely right about the customer. It should never go against the will of the customer, and that’s precisely what fit/gap should tell both the vendor and the customer. If fit/gap shows less than say 60% then it’s risky, if it shows more – why not going immediately into production with that functionality? Or at least partially, or in parallel with old system or as a pilot? The fact is that (no matter how many customers will disagree) the customers often don’t know exactly what they are shopping for and they are evaluating everything through their knowledge of their current software. What they should do instead is evaluate it through the knowledge of their processes. The problem is – the processes are often shaped after the software, because there is no 100% fit software. So – if it’s vendor hype – don’t go for that vendor, just choose another one where you see more fit in their “vanilla”. But if you choose to go for customizations, then you are probably facing an ERP project which will just go along statistics: 93% chance of going over schedule, 65% chance of going over budget, and only 43% of being happy with the result. Customizations can’t be avoided, but if you are looking for a way to completely shape the software to your business processes, then you should rather seek a software which you don’t have to adapt – there are usually many of those. IMHO, you stand much better chances of getting your investment back (and actually earning money) if you focus on how you can improve your processes with the help of the software rather than spending a lot of money on shaping the software to your processes. 57% of SAP customers (just look up SAP on Wikipedia and look under References) who invested in customizations never got their investment back – and I don’t wonder why – even though I haven’t seen a similar research on other ERP products, but from the practice and experience I can tell it’s pretty close. If you believe you should really just shape and bend the software to your needs, then it’s just all hype, customer style. To sum it up – invest into research, find the product which offers biggest fit, and pick it, don’t just pick NAV or SAP or Oracle or AX or whichever because it can be shaped – you stand better chances of earning value with your system.