A good friend of mine called me this week to explain how his company is on the path to ERP implementation failure.
The sad part of this tale is that so many blunders could have been avoided.
Let me explain.
My friend is 67. He is an experienced IBM i programmer with over 41 years of experience. He is also the IT manager for a western wear garment manufacturer. Over the years he has told me how he has customized the legacy garment software to fit his employer’s business. (Sound familiar?)
Now, newer managers think the software is antiquated because it is character-based “green screen”. (Sound familiar?)
Without involving my friend, the IT manager (with decades of experience with this company), they selected a web-based garment solution to replace their IBM i software.
In essence, this garment software had a slick graphical browser interface. It looked modern. It is Software-as-a-Service. And the salesman and presentation team sounded very knowledgeable.
Check, check, check and check.
New managers who may not have known the inner workings of the company combined with highly motivated commission based salesman and a presentation team who also knew very little about the client’s inner workings, processes, data or outputs……what could possibly go wrong?
First, there was NO thorough needs assessment. In other words, no one took the time to determine what functionality was currently in place that is essential to run the business.
Nor, was adequate time and study spent to analyze and document the need for new functionality. So how could the software vendor possibly know what the real needs of the data, logic or output are?
However, during the implementation many (but not always all) of these needs do get identified. Let’s hope that the purchased solution can deliver.
And if not, that the vendor is willing to modify and support software modifications or that the client is willing and truly able to change their processes to fit the new product.
Second, once they dug more deeply into the database of the software they discovered that this was a “new face” on an “old” package with fixed field lengths that were too short to handle their current part numbers. The database is really flat files, not a relational database. OMG!
With a complete RFP based demonstration and defined vendor responses, this huge mistake could have been avoided.
Third, they discovered limited functionality in the new system that their current system already had.
So, while the rest of the team has not come to terms with this consideration, my friend already sees this huge flaw.
The ramifications of these limitations will come to bear during the system testing and user training and could have been avoided or properly addressed during the RFP vendor response cycle and software demonstration.
How do you address these limitations when your company is only weeks away from Go-Live and has already spent serious $$$$$$, time and effort? Good luck with that.
Fourth, the company has selected their network administrator as the project leader. This network guy is smart, in his early 30’s and energetic.
BUT, he does NOT know how to program and has NEVER done an ERP implementation and does not have a background in the company’s ERP processes or in the department’s missions, goals and responsibilities.
Also, he has a full-time job as a network administrator.
So when will he have the time to roll out an ERP solution with the skills to customize the software to fit the unique needs of the business?
And of course this assumes that the software vendor will allow customization, the client can define the additional functions needed well enough and that the application software design can actually be modified to perform the new functions.
While many readers may know how to avoid these blunders, let’s highlight some basics so this does not happen at your operation.
1) What are the BUSINESS REASONS to change the software in the first place?If there are clear business reasons to replace the software, clearly document them.
2) From within your company, select the software project leader and team that have the expertise and time to study and implement the software all the way to success.
3) Document the essential needs the new software must include. Then select someone within the company who knows the business operation, the current software and has the skills and time to assess current and future needs.
The project leader needs to review the current software files and functionality and talk to the key department heads to gain clarity of the essential processes that will be vital in the search for the new solution.
Ideally your needs document includes critical files, fields and related lengths, screen shots, functionality, input data, application logic, output data and reports. The needs document will be your Request for Proposal (RFP).
The bidding software vendors will greatly appreciate a detailed RFP (so they know what their product and company need to deliver) but also by your internal assessment team so they will have a defined guideline to follow when assessing the different vendors’ proposed solutions.
4) Search for software providers that fit your needs and have them review your RFP. Reputable software providers appreciate prospective clients that have detailed documented needs. It means they know their business. With detailed documentation, both the software buyer and the providers can determine the software fit more quickly and with far less misunderstanding.
5) Request software providers give you a detailed proposal to your RFP including software fit, licensing price, deployment and any customization. Be clear that this will become the scope of work for the project, the defined deliverables for all parties and that you will not tolerate future billings due to misunderstanding. Said another way, the RFP will be designed to not only define the expected product functionality but also will be used to avoid misunderstandings.
6) Have your software provider explain where they have a good fit and where they will have to customize their software to fit your needs. Insist they be as specific as possible, how much they will charge for developing and supporting the customizations and how they will address these customizations during the future upgrades of their product.
7) Give samples of your data so that they can demonstrate their software to prove to you that it works. Be sure they can demonstrate their software running your most difficult procedures. (To be sure, this requires that you understand your data and most difficult procedures as well as the prospective software providers.) Pay close attention to files, field lengths, functionality, data entry, screens, input data, logic, output data and reports. (You don’t want to discover your new software cannot handle your current part numbers!)
8) Require your software provider to give you an implementation schedule with clear milestones and explain they get paid upon milestone attainment. In essence, you and the software provider have to have a clear understanding of what each milestone success looks like so there are no disputes. That way you will both know when each step of the project is satisfactorily completed. You know it will work. Your software provider knows he gets paid. Everyone is going to be happy.
9) Select your software provider and convert your RFP and related documentation into a working project agreement. You have done all the hard work. Now you can easily convert your RFP and your software vendor’s documentation into a working agreement so you both know what to expect and how to get paid.
When you think about it, the detail of assessing the software gets done either before your select the software (best case) or during implementation (worst case…you may discover the software is a terrible fit).
While these 9 steps represent a lot of work and cost money, the rewards far outweigh the cost of ERP implementation failure.
Need Help? Call Bob Losey at 714-593-0387 or email JD Liford at jdl1951@aol.com
Leave a Reply