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. You can find them here and here. 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!
TrackBack
• Digg This
• Add to del.icio.us
Tags: Enterprise resource planning (ERP), Supply chain management software
Posted in Supply chain management
You can leave a response, or trackback from your own site.
The title of your blog caught my eye John! Great tips on a successful deployment. I think deployments often fail because the wrong decision was made at the executive level.
Executives certainly look for risk averse strategies. However what they perceive as risk averse can often be quite the opposite. Decisions are also often made based on the culture of the organization. In many organizations the corporate IT strategy dictates software decisions.
You made a point about making sure that the software solves the business problems. Nothing against IT, but I remember hearing a senior supply chain executive from a very well known company tell their CIO…’You’re not the one that will get fired if we don’t deliver to the customer on time’ …meaning…the business needs to be very involved in any supply chain software decision.
I find that the most successful companies I work with value ‘ calculated’ risk. They are not afraid to look at disruptive technologies versus status quo. They are concerned about the future of their company and are not just focused on the future of their job. It will be interesting to see how the future generation of executives…the Gen Y….will make software decisions. They are extremely techno savy, have very little patience, and are willing to take risks.
Something else I have seen that varies widely between companies is the involvement of those using the software and supporting them through executive sponsorship. As a former supply chain practitioner, I recall my director continually challenging us to brainstorm new ways of solving problems with software. New ideas were embraced and supported. This was a continual process. We were responsible for the success of the deployment and clearly understood the value.
I am interested in hearing the opinion of others.
I’ve been a party to a number of organizations that roll in a new CEO every 2-4 years and invariably along comes a whole new ERP system autocratically required and driven by the new CEO. The company finally got the last system iteration up and running properly and suddenly a new system is forced upon the organization from above with no reasonable justification other than that’s what the new CEO wants. As you say John, hundreds of millions of dollars are spent repeatedly with no real reason and at the same time careers may be limited just from the constant change in corporate strategy trying to chase multiple new system implementations.
I read an article a few years ago published by AMA that suggested “in the face of incompetence by senior management, it is the duty for mid and technical level management to just do what’s right for the company”. To my amazement it works but it takes real guts to stand up for what’s right in the front end. With this in mind, the following are three of my own managerial tips in addition to your article.
Tip 1; I feel quite strongly that in the face of true incompetence at the highest corporate levels, user and technically knowledgeable mid and C level management must stand up and do what’s right for the company in the front end, even if it’s career limiting. If you all stand together, the new CEO and his recently hired cronies or the BOD have to listen, they can’t fire everyone.
Tip 2; Never ever let one department such as Accounting or the CEO’s crony group drive all the technical implementation decisions for all the other departments; that certainly will be career limiting when they take ownership but you can not make their foolhardy setup work.
Tip 3; Never ever decide on a system that is more complex than what your company needs, your staff can handle or your customers require. You will kill your company trying to get the system implemented.
John
great topic, serious issue and great points made by Carol and Ron. Yet, in addition to collecting tips to be implemented at the buyer/company/individual level, I suggest that there be real value in exploring the media and vendor industry colluding to block discussion about the larger elephant in the middle of the table. Vendors are selling and successful implementing their systems and getting paid, and the assumption that the goal to achieve business or operations objectives is totally the responsibility of the buyer.
There are stats and stories out there that show
1. Significant numbers of large systems implementation not meeting customer objectives or implementing system basic functions are an afterthought, e.g., in a WMS a locator system, cycle count, wave planning, etc.;
2. Sellers shifting the marketing focus to minimizing initial cost and IT criteria (e.g., cloud), and away from long term ROI and identifying and achieving business and operations objectives;
3. Growing use of the mantra that successful implementation is based on 50% people, 30% process, and 20% technology, yet little discussion about what is involved in the 50% and 30% and the majority on technologies, 90 day implementation times, etc.;
I have had client C level officers in Fortune 500 companies voice (privately) their wishes to have all their money invested in ERP or WMS or ??? back believing that their companies would be better off if they had invested it in their legacy systems.
My point is that achieving real, whole system success and real ROI will require attention, visibility, and discussion at several levels, including the company, industry and larger.