An article came through my newsfeed recently from “the doctor” at Sourcing Innovation, titled “Want to fail faster? Automate it!” It referred to a case study, “A better way to automate service operations” presented in McKinsey Quarterly. Now, I know that the typical reader of this here blog is a supply chain professional and that the article is all about the service industry, but I saw some interesting lessons in the article that can be applied to supply chain.
How many times have we seen ERP implementations that have taken years to complete, were late, were over budget and in the end didn’t even come close to meeting the goals established for the project? One of the key points in the article is that automating a bad process simply means that the bad process happens faster. If fact, with ERP deployments, the bad process often happens slower because the system isn’t designed around the current process. This means that users need to figure out work-arounds in order to perform the old process in the new software.
Implementing new software should be seen as an opportunity to review the ways things are done and leverage new capabilities to make things more efficient and effective. I’ve written a few posts about the difficulty of deploying ERP systems.
There are many ways that an ERP implementation can fail; often, it is because projects were far too ambitious (usually driven by the underhanded “Sell ‘em more” sales tactics by the ERP vendors). Sometimes it’s because the software simply doesn’t do what the salesperson promised. Sometimes it’s because the company doesn’t commit (or understand the need to commit) anything beyond the purchase price of the software. Sometimes it’s because the company doesn’t have a reasonable implementation plan (“whadya mean it’ll take more than a week to deploy that ERP system across the enterprise?!?”)
Regardless of the reason, failures are spectacularly expensive and usually career limiting (“Sorry mister CEO...that $100 million we just spent on implementing ERP? We need to start over...it’s um...not really working. Um...that’s not a problem...is it?“ ) So how do we ensure that our software deployment will be a success? Let’s look at some ideas;
- Clearly articulate the goals for the deployment. What problems do you need to solve? By what metrics will you know that you have solved these problems?
- When you purchase software, make sure that the software you buy solves the problems you’ve identified. Don’t let the sales guys “suite talk” you into buying more than you need. Remember: the software price is only a part...a SMALL part...of the overall cost. If you buy more than you need, your costs will go up, the project will take longer (and with it the time to value) and you will lose focus on why you were implementing software in the first place.
- What processes will the software impact? What changes could we make to the process to streamline it BEFORE we implement the software. (Consider investing in a value stream mapping exercise where the current process is mapped, ruthlessly analyzed to eliminate waste then reassembled). Further, what changes could we make to the process to leverage the capabilities of the software? (The value stream mapping exercise would be a huge benefit here too).
- Make sure you include the people that are doing the work (and who will be using the software) in the requirements gathering, software selection and deployment processes. They have the knowledge to ensure that some small, but critical detail is not overlooked.
- Have a plan for implementing across the company, but start in one area. Learn from the mistakes you make (and you will make mistakes) and revise your deployment for the next phases.
- Run conference room pilots and parallel runs to tryout the new processes before cutting over.
- And of course, train and educate everyone involved in the new systems.
What tips can you offer to ensure deployment success? Comment and let us know!