ERP implementations are hard and I have a couple of mantras regarding them. “ERP users only like their current ERP system when a company is considering choosing a new one.” And “ERP consultants can make an otherwise good man or woman look bad.” There are several reasons for this and I will touch on a couple. First, people just don’t like change. Second, people are afraid of job displacement or “loss of value” through automation. Third, ERP implementations are infrequent and there is often a misalignment of expectations between management teams, employees, and external consultants. Finally, the consulting industry, for all of their PMPs on staff, aren’t very good, in my experience, of delivering on time or on budget. #godblesssaphire
Here are a few of my thoughts on how to conduct a successful ERP implementation as someone who has managed them as a user in Brazil, the Netherlands and the United States.
Internal Project Management
I believe that hands on internal project management needs key resources from three distinct areas.
There should be two individuals dedicated to the project on the company side. The development of the ERP system will be full-time jobs and smart executive teams and boards won’t expect these two individuals to do any additional work over the duration the ERP project.
Internal Project Manager who also manages the external consultants
First, there should be a relatively high accounting or operations person or a temporary consultant hired to manage the internal project management and interface or liaise with the external consultants.
The benefit of using an internal resource is that they know the company better and the benefit of a consultant is that they know the implementation process better. This person is ultimately the one with the responsibility of scope, time, and cost.
Think about this, how can teams logically expect a CFO to oversee accounting, close the books, go through an audit, and manage an ERP implementation?
ERP Expert
The second key resource is what I call an “ERP Expert”. Some might call it a Power User. This person is going to be the “go to” for users during testing and upon completion of the implementation. They should participate in every meeting with the outside consultants. They will ultimately help create written IT and business processes. They can be an accountant or an IT person. Once a system is chosen, I highly recommend that this person be put into “consultant school”. There are a lot of certification programs for people who want to become Microsoft, SAP, Workday, NetSuite, and other types of consultants. These classes pay for themselves in short order. First, the ERP Expert will be able to do a lot of troubleshooting that would otherwise be spent on external consultants. Second, they will develop a good idea of how long things take and how deep they go, ultimately helping manage some of the time and cost spent on projects.
Department Heads
The third key resource, and probably the most important, is having the department heads involved. At one of my recent clients, they defined their departments as:
Internal Accounting
External Accounting
Sales
Production
Packaging
Shipping.
It seems appropriate.
Most people hate change. The last thing that a company wants to do is wait until the 11th hour and tell these people “this is how you do it”. It won’t go well. They need to be involved from day one. Actually before. They need to be involved in vendor selection. They need to have ownership. They need to be the primary decision makers, but have the understanding that all departments will likely need to make some compromises. There should be regular meetings and the department heads should be the ones reporting and questioning consultant strategy and each other to create a system of buy-in and accountability. Ultimately, they need feel like and actually be controlling the process.
Vendor Selection
A lot of work needs to be done prior to selecting a vendor. All of this “pre-work” is probably the most important part of process.
The Internal Project Manager and ERP Expert should conduct departmental assessments (interviews) of:
What each department does and how they do it. They should collectively go through the current steps of the ERP process to learn in detail.
What works and doesn’t work or specifically, what are the gaps in the current system.
A wish list or what a successful ERP implementation would look like to their department.
What reports they currently use and if they have any faults.
The Internal Project Manager and ERP Expert should speak with the CEO, CFO, COO as well and ask some of the same questions, but with an emphasis on reporting.
Next, the Internal Project Manager should begin to solicit some options for ERP vendors. They should go through some basic demos, exchange ideas on the basics of the business, etc.
This should only be viewed as preliminary.
Once the Internal Project Manager has a good idea of a few providers, the prospective vendors should be invited to individually provide department heads with hands on demos. The department heads should be the ones hands on in the demo system and going through their own process. If they see an issue or deficiency, it should be noted. If the vendor is doing the dri
ving the demo system, they are using a very simplified company that was configured to perfection. It’s one of the primary complaints that I’ve heard and committed myself, “when I saw the demo, everything worked great.”
And don’t settle. If you are food company, and the vendor can’t provide you with a lot tracking demo then you probably have the wrong vendor.
Hopefully, now, a company would have a pretty good idea who you’d like to work with. Let them know and let them know how you would like to proceed.
There is one step between this marketing phase and real launch.
After you think you have the right vendor, make them interview each department and ask the same questions and do the same walkthroughs that the Internal Project Manager and ERP Expert did. This may have a cost. It will be worth it. But, don’t be pulled into a full “business assessment”. These seem to be popping up and they aren’t needed. They aren’t going to assess the business better than the company can assess themselves. They should be happy to visit and get paid for it as it will make the rest of the project work better. If you pay the external consultant for this, pay them by the hour or for the project.
Also, the primary criteria for vendor selection, should be based on the feedback of the department heads.
Vendor Project, Progress, and Payment Structure
Some of the following may or may not be possible based on the type of vendor and industry demand. In a slow economy, clients have more negotiating leverage obviously. That being said, many of these aspects should be adopted.
I have done “fixed cost” projects and I have done “hourly” projects as a user working with external consultants. Fixed cost projects usually take less actual time (not consulting time, see below). Sometimes though, you will pay a lot more than what it costs for hourly projects. Hourly is just what it says. The client, you, pay by the hour. Hourly projects usually take longer and not necessarily in billable hours. Sometimes external consultants are willing to do a hybrid where it’s an hourly, but up to a max number of hours.
Break the project down into milestones or “sprints”. Everyone will be overwhelmed as it is and it’s easier to focus on the micro than the macro. Only pay the consultant based on satisfactory completion of the milestone or sprint and make this clear in the contract. If they only have 80% of the chart of accounts in the system and the contract says completion of the chart of accounts, don’t incentivize them to do 80% of the work and expect to get paid when the contract says they get paid on completion of the work.
Clearly define the “specs”. This is more the company’s job than the consultant’s job. There is no downside to relative minutia and including all of the notes/data from the interviews that were conducted internally and by the external consultants and reports provided from the legacy systems. Both sides, the company and the consultant, should aim to avoid ambiguity and interpretation. It will be better for everyone. It will help them understand what it will take in time and money for each milestone and it will help the company understand what they are getting. Don’t assume things. Don’t only show the consultant that you do wholesale sales and then ask them why there was no tax setup for your retail sales.
Get the details of the “who” and “how long”. External consultants will generally provide you with their project managers, but you must ask who specifically will be working on each part of project. The specific persons who will be doing system configurations and the specific persons who will be doing integrations with other software, for example.
I can’t emphasize enough the concept of time in a consulting environment. There are two concepts, and they often don’t line up well. A consultant may tell you that “it will take 30 hours to complete” a part of the project. What they won’t tell you is that they can’t start for 3 weeks and they can only dedicate 3 hours per week to the project. Always get a clear understanding of who, starting time, hours of work expected, and an estimated delivery date.
Recording meetings is good for everyone. That way if there is ever a conflict, both parties can revert back to the meetings to see who was right or approximately right or if there was just poor communication.
Get your act together if you expect your external consultant too. The company sets the standard for how the project advances. If the company provides all of the information on time and in a complete and organized fashion, the external consultant generally follows suit, and the project goes smoothly. If the company slacks off, forgets stuff, requests delays, a new standard of work has been demonstrated to the consultant, the consultant will follow suit and mirror the company’s behavior. And I have heard a lot of “But, we are paying them?”. It doesn’t matter.
Monitoring Progress
Everyone needs more meeting like they need head lice, but they are really important. There should be both meetings with the external consultants and
internal only meetings. I have two somewhat conflicting perspectives on meetings as well. One, it is always better to start with meeting too much. It’s easier to cut back than to add. Second, don’t be afraid to change the variability. At project launch it may require 30 minute meetings per day, every day. After a month, maybe it makes sense to have meetings weekly. Then, right before the go live, it may make sense to have meetings every day again.
I recommend a few “aids” for the “monitoring progress” part of the process. First, create and update an entire project or milestone Gantt or checklist of deliverables for that phase of the project. Make it visible for everyone involved in the project to see (Kanban principle). Second, at some point, the department heads need to identify the users within their department. Create a public spreadsheet where all users, department heads, and managers input on a weekly basis a) their confidence in the ERP system and b) their confidence in their ability to do their job in the ERP system. The trend lines will help align testing and training. Third, create a public “issues log” for all users that will exist in perpetuity. You want to ensure employees that they are being heard. If you don’t have the log, they will become a broken record. Finally, review these aids in meetings so that there is constant communication.
Testing and Written Processes
Department heads should be responsible for their own department’s testing. Expecting someone else to do it is foolhardy. They know their business and they can do their own testing. This ensures that they can’t say at the end, “it doesn’t work” or “it doesn’t work how I thought it was supposed to.”
Testing should include, one, all of the testing scripts provided by the external consultant, and, two, all of the information collected as part of the interviews. For example, the external consultant may give you a script to verify the chart of accounts. They may not ask you to test month end adjusting entries and the person who does that should test how to do those entries and reversals and make sure that everything is posting correctly and hitting the income statement and balance sheet correctly.
I have a specific individual philosophy in that I require all departments to write their own user’s manual. The external consultants will generally provide a generic guide. I require company and department specific guides. If I get pushback on this from a department head, my response is “if you can’t create an elegant step by step manual, it’s not your fault, but you don’t understand the system well enough and need more training”. These manuals become important in setting standards and training new employees and for when someone is sick or leaves the company. One thing of note. When making these guides be very aware of what I call “handoff points”, or where something moves from the responsibility of one department to another. For example, in your legacy ERP system, maybe sales printed off the packing slips and the pick paper. In the system, it maybe that the packing slips are printed by shipping and the picks are generated by shipping in a handheld device.
Go Lives and Final Thoughts
Go Lives are never comfortable. At some point a go / no go decision needs to be made. If you feel that the system has been tested well, but perhaps the teams haven’t been well “practiced”, you should probably still go live. There will always be apprehension and in my experience if you have some concerns about understanding the system and training two weeks before go live and decide to push the go live for a month, those same exact concerns will exist two week before the adjusted go live date. People will tend to push the training and learning for two weeks and they will be in same exact situation for the new go live month as they were for the old.
I am not an IT expert, but all of these things have been proven out based on my experience. I sometimes say that I haven’t learned a lot from some of my business failures, but the one exception is that I have learned a ton from my ERP implementation failures.
I hope that this helps and if you have any questions, feel free to reach out to me.
Comments