Comments on: 1st rule of agile ERP: deploy vanilla ERP

By: Vjekoslav Babic

Vjekoslav Babic — Mon, 19 Oct 2009 16:50:50 +0000

@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.

By: Jacques

Jacques — Mon, 19 Oct 2009 13:27:55 +0000

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

By: Peter

Peter — Tue, 02 Jun 2009 07:35:45 +0000

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

By: Vjekoslav Babic

Vjekoslav Babic — Thu, 26 Mar 2009 21:41:13 +0000

@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.

By: Fran

Fran — Thu, 26 Mar 2009 21:14:42 +0000

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.

By: Vjekoslav Babic

Vjekoslav Babic — Wed, 25 Mar 2009 07:02:23 +0000

@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)

By: Dave Roys

Dave Roys — Wed, 25 Mar 2009 00:59:26 +0000

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.

By: Vjekoslav Babic

Vjekoslav Babic — Tue, 17 Mar 2009 21:22:51 +0000

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.

By: FUnkygraz

FUnkygraz — Tue, 17 Mar 2009 15:55:45 +0000

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

By: Vjekoslav Babic

Vjekoslav Babic — Tue, 17 Mar 2009 09:55:20 +0000

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.

By: FUnkygraz

FUnkygraz — Tue, 17 Mar 2009 08:00:05 +0000

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.

By: Navigate Into Success

Navigate Into Success — Tue, 17 Mar 2009 01:14:15 +0000

1st rule of agile ERP: deploy vanilla ERP…

%u201cOur highest priority is to satisfy the customer through early and continuous delivery of valuable software…