ERP
ERP Software Knowledge Transfer - Is it Just Part of the Sales Pitch?
It is very common among ERP projects for consultants to make big promises to transfer software knowledge to their client. For example, we often hear the proverbial statement: “One of our goals is to work ourselves off the project, by teaching you the new system!” Yet once a project is over, many clients are clueless when it comes to making software configuration changes, and may even struggle with performing basic transactions in the system. So what gives?
No doubt, in some cases the client is more than partly to blame for a lack of software knowledge. But even when they are serious about learning the new system, unfortunately many consulting firms have no real strategy to make knowledge transfer more than just a promise.
The stakes are pretty high. Implementing ERP is a huge investment for any company. Are we now saying it does not matter if anyone knows how to use the new tools? This is similar to consultants building a spaceship to take you to Mars with the understanding you will not plan the return trip until after you get there. There are consequences for assuming knowledge of the system will automatically cross-pollinate. The issues listed below can cost your company plenty.
- Paying expense consultants to perform project tasks that the organization should be doing. Without a certain level of software knowledge, it will be difficult for the client to fulfill even their most basic project responsibilities. Of course, most consulting firms are more than happy to pick up the slack. The less you can do, the more money they make!
- Fostering a “Let it Fail” mentality with the user community. When it comes to managing change, many times we are our own worst enemy. It is not hard to imagine why employees refuse to buy into software they do not understand. When consultants are running the project (because the client team hasn’t learned a thing), understandably many employees will run away from the project or will not be eager to help it succeed.
- Software quality suffers (and this is not just a perception). Lack of software knowledge limits the ability of the client team to become proactive in the design of new business processes and the software. In this case, it is a given many important business needs will fall between the cracks. On the other hand, a client that acquires an understanding of the system can at least ask their consultants the right questions or spot issues with the software set-up.
- Consultants camp out for months (or years) after the initial go-live. After all, someone must hold the hands of untrained users and make simple software configuration changes required by the business. A similar issue exists with regard to the client’s ability to implement new releases without an army of consultants.
- The software remains static while the business needs change. The reasons: a) No one internally is aware of what the software is capable of doing; b) No one internally understands how to make the configuration changes, or c) The alternative of hiring consultants costs too much. In the meantime, users are told to “live with it” and work around inflexible software.
- As employees change jobs, leave the organization, and are replaced by new individuals, consistency in user procedures and knowledge of the system slowly erodes. This is inevitable considering no one can explain the big picture or the original software design intent. Therefore, new users are not trained correctly or simply left to fend for themselves.
- Software modifications are made to the system to support business needs that are inherently addressed by the software. Not knowing any better, some organizations write custom programs to provide software features and functions that are already available within the ERP package (right out of the box or with a few set-up changes).
- After several years of struggling with the software, the organization finally hires an employee from the outside with the expertise to provide needed support. Unfortunately, if this was done prior to implementation, they could have saved themselves a lot of time and money.
- The software support is outsourced with the hope that the problem goes away. Don’t kid yourself — if no one internally can make sense of user requests from a software design and set-up standpoint or actually make the configuration changes, vendor change order costs may eat you alive.
Software Knowledge as a Project Management Thread
The successful transfer of software knowledge from the consultant to the client does not necessarily happen by chance. Furthermore, it goes beyond initial project team training, training “on the fly” during the project, and even end-user training. Also, in order to achieve consistent results, the techniques applied should not be left up to each consultant that happens to be working on the project.
Similar to other key areas of project management such as issue management, technology management, etc., knowledge transfer should be viewed as a “project management thread” that runs throughout the implementation cycle. This means there should be “knowledge transfer deliverables” within each project phase. When done correctly, these deliverables enable the project team to crest software learning curves early on and then accelerate learning so the team can be productive and fully engaged during the implementation.
Want more on ERP? You can find additional reading material in specific ERP categories like cloud ERP and free open source ERP in our ERP research page. We offer exclusive ERP reports and whitepapers such as ERP 101: A Guide to Getting Started with Enterprise Resource Planning Software and side-by-side comparisons of the best software in our Top 20 ERP Software report.
- Consultant
