How do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records. Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report. One way or the other.
ERP software is huge. It contains thousands of features potentially touching every single tiniest aspect of your business. Implementing ERP is about introducing change into your company, and change can be evolutionary, or revolutionary. Your pick.
The biggest pitfall of the waterfall model is that the longer it takes to cascade all the way downstream, the less chances of delivering valuable results. Why? Because of the change. The change is cranky. It doesn’t wait for your implementation to complete. It happens on its own. Market changes. People come and go. Business grows. Goals and priorities shift.
Deep into the project, change can cause total panic. As the deadline approaches, and budget is drained, tradeoffs are made in response to legitimate change requests. Late change requests raise difficult issues: if you don’t have enough time, or money, or both, to address them properly, you can ignore them and risk failure, or you can trade off. Neither results in anticipated value. The bigger the elephant, the riskier it all gets.
Furthermore, big bang deployment of whole ERP at once may have detrimental effect on morale and productivity. Users can get overwhelmed with the new solution, new user interface, new logic and new features; it may take a long time for them to come to terms with the ERP, causing lost productivity and more errors.
So, instead of trying to make a perfect solution for finances, sales, purchases, warehouse, manufacturing, service, human resources, project management, payroll, distribution, plant maintenance, with all industry specifics, all at once, you go step by step. You start by deploying financial management. Then you deploy sales. Then you deploy purchases. You get the gist.
Gradual doesn’t mean you need to deploy whole departments. You can narrow down your function focus as much as you want. You can deploy sales orders before you deploy ATP or CTP; you can deploy production orders before you deploy MRP or MPS.
Deploying gradually, department by department, or function by function, you allow your customer to gradually understand and master the principles of the solution.
ERP implementations usually define measurable goals: productivity increase, overhead decrease, higher inventory turnover, less inventory time, better insight into cost structure and whatnot. If you wait for big bang deployment, you also wait for your goals to start realizing. As achieved goals translate into earned value, the longer you wait to achieve the goals, the longer you wait for value to realize.
Gradual deployments have an overwhelming benefit: they start generating value quickly. As soon as you deploy a function, if it was properly aligned with a project goal, it starts generating value for you immediately. If you deploy 10 functions over 10-months period (a function a month), then by the time all of them are in production, you have 45 months of accumulated generated value. No matter how little value these functions generate individually, it is infinitely larger than zero, which is how much value is generated by a big-bang ERP before it goes live.
This approach isn’t without problems, though. The more distinctly you address the functions, the more temporary integration you have to build. Naturally, it costs money. But it shouldn’t scare you away. You need to take these integrations carefully into account, and handle them properly. Even though they cost, this can be significantly lower than the benefit you gain. And sometimes, the integration might be skipped altogether as you rearrange the process not to rely on the integration. I’ll talk more about integration in the last article of the agile series (scheduled for Saturday).
Tomorrow, with the next article, I focus on value, and value alone, and I’m looking forward to seeing you around. Meanwhile, please share your thoughts!
P.S. I expected my agile series to ignite discussion, but I didn’t anticipate it to spread to other blogs. Mark Polino at DynamicAccounting.net has contributed a couple of valuable ideas to the whole agile theory (and his ideas seem to have strong foundation in practice). Thanks, Mark!
Pingback: Navigate Into Success
Plus an added benefit is its much easier to train smaller groups of people with the same “Roles”.
I know, you might think: “train all your users in advance”, but this step needs to be viewed in combination with the 1st rule of deploying vanilla I think. And then the shorter timeframe can sometimes not allow for that, plus… who ever paid attention in class?
I’m curious if you considered hardware / software costs though. In terms of licensing this might get costly? *Shrug*
FUnkygraz: didn’t you pay attention in class? Naughty-naughty 🙂 I believe that training should always be delivered by user roles, regardless of agile, waterfall or whichever approach. The benefit in more granular function-by-function deployment approach is that overall you might spend less time in training. When you train a lot of functionality at once, much gets forgotten. If you train a function a month (or depending on your delivery schedule), users retain more of the new knowledge. Plus, I believe that after a couple of smaller trainings and exhaustive on-the-job hands-on experience with the product, you might not even need to deliver full trainings for consecutive function releases – users will already understand the principles of the application and it will be much easier for them to learn new things (even without formal training).
About hardware cost – I don’t think that agile helps here. Unless you are spreading functions to several servers, you might not be able to save much on hardware.
About licensing, there is no increased cost in agile, there can only be saving. With big bang approach you generally purchase licenses at the beginning of the implementation, and you start using them much later. With agile, if you go function by function, you buy additional users as you go and when you go–it reflects better on your cash flow. It will affect your volume savings, though, and if it really hurts you, you can always just purchase all the licenses at once, just as with big bang approach, and it shouldn’t cost you a cent more.
I found your site on Google and read a few of your other entires. Nice Stuff. I’m looking forward to reading more from you.
Simonn: Thanks! Anything in particular that you like, or did you just want to get a link back to your site from here? Please let me know, and I’ll reconsider putting the link back.
Hey, Vjekoslav!
your post is great!!! I´ve been working with agile development for many years and, few months ago I started working with Ax implementation… I’ve seen that the customers faces the same problems that our waterfall customers had, but, as you said, ERP implementation is not software development.
I am sure this discussion can be a big break toward a better way to implement ERP… thanks for your thoughts and light over this subject!!!
Hi Vjekoslav,
I don’t understand how ERP can be deployed gradually since the modules are so closely interconnected. For example, purchasing links closely to accounts payable. You can’t implement purchasing without accounts payable. How would the vendor get paid?
And once the purchasing module is deployed in the new ERP, do we stop using it in the old ERP? Would the users have to use both systems in parallel?
Similarly, Materials are closely linked to BOMs and Production Orders and Inventory. How can you deploy one without the other?
Well, this is kind of what this blog series is about, isn’t it? 🙂 It addresses the very first issue that you make, how to do that.