Here are just a few of the top reasons an ERP project may be perceived as a failure, or fail to produce desired results:
- Insufficient end user training
- Users resisting change
- Failure to engage business stakeholders and system users, resulting in poor design
These seem like easy things to address, but are very often challenging to get under control. Below are a few simple tactics that can help.
Involve end users early and often to increase adoption
Who are the right users?
You'll notice that each of the 3 bullet points I included in the list above included the word 'user.' The first question to answer here, is who to involve. There's not one answer to that, as there are many factors. A key that is consistent, regardless of size or complexity of organization, is that you must be willing to allocate time from key subject matter experts (SME) across various functional areas from the business. That means you must be willing to pull people from their day jobs, which requires back-filling or asking for extra effort. I do not recommend the latter, as you do not want this to be what they think about during hours 60-80 of the week. That will result in fatigue and burnout. Ideally, these individuals would have a deep knowledge of the business processes in their functional area. It is also very important that the SMEs feel empowered to make decisions on process and solution design. On larger teams, you may have multiple SMEs on a functional work stream. If that is the case, you will want to appoint an Owner of that work stream.
Use their time wisely
From the very beginning of our implementation projects, we use an approach we call(pronounced jay-pod). This is our twist on what you might otherwise call JAD. At the center of the JPD is a demonstration of our client's business process, in the new system, using the industry standard best practice. Just to re-emphasize, this is not a generic training course on the ins and outs of the product. This is laser-focused demonstrations in the context of the individual business processes relevant and in scope for the ERP deployment. During the demonstration, it is important for the SMEs to provide feedback on the degree of fit between process and system. This is the 'Joint' in the JPD. The JPD cycle is as follows: Demonstrate > Tweak/Fix/Update Configuration > Demonstrate > Tweak/Fix/Update Configuration > Demonstrate (Do this until you have it nailed - Sometimes it only takes one iteration) The JPD (or some similar process) is critical, as it accomplishes the following:
- Trains the core team (system users), from the very beginning of the project, and throughout the project, not waiting until the end.
- Exposes the users to the benefits of the system.
- Users are Influencing the design, and feel ownership of it.
- Self-sufficiency - nobody wants to depend entirely on their ERP partner to support and enhance their system after deployment. This process ensures a strong internal knowledge of the new system.
Broaden the audience
The subject matter experts involved with the JPDs will have colleagues and counterparts that are not directly involved. The core project team member should set up time to discuss and review key design decisions with a broader group throughout the JPD cycle. They should also look for opportunities for inclusion in certain JPD sessions. Maybe key functional areas, once the design is fully developed. These could be smaller 'Design Validation' sessions, or simply during a CRP. The difference being that CRP should be cross functional and end to end, while design validation sessions can be held within a single functional work stream.
Create a user community
Leading up to the end of an ERP deployment, or immediately following, I'd recommend developing a community among end users of the system. Give them a forum to discuss challenges they are facing and share new discoveries that make their lives easier. I've been amazed at some of the knowledge sharing and innovation that can happen when you create this environment. Yammer (or some enterprise social network tool) is a great way to enable ad-hoc knowledge sharing and Q&A dialog. You may also want to schedule round-table sessions or 'open office hours' with power users or key consultants from the project. Encourage users to come to those meetings with questions, but also with knowledge to share/demonstrate to other users.
Also look for a user group outside of your organization. Many software vendors have user groups that host Q&A forums, webinars, and conferences. I've found that user group participants are very knowledgeable of the systems, and have great ideas on how to best utilize it, as well as other related technology solutions.
These are just a couple of small steps that can make a large impact on overall organizational change management for your ERP project. This is not a replacement for a fully structured organization change management plan.
and serves as a Solution Architect and Vice President of Services. Cody joined Stoneridge in December 2012 from Microsoft where he spent 5 years in the Support and Premier Field Engineering organizations as the go-to resource for functional expertise on Microsoft Dynamics AX 2012, 2009 and 4.0. He’s worked on all areas of the application lifecycle, assisting with analysis and design and helping customers develop and deploy AX successfully.
is a Fargo, ND and Minneapolis, MN area Dynamics AX, Dynamics NAV and Dynamics CRM partner. If you're interested in learning more about our JPD philosophy or contact 612-354-4966 or solutions@stoneridgesoftware.com.
by Stoneridge Software
