Best Practices for a Seamless ERP Transition

By Porter Jeppson
—

I’ve played a variety of different roles in ERP software implementations over the years. From client advocate to project manager to system architect to data conversion lead, I’ve had a very broad exposure to the tasks required at each step of the implementation process. With each implementation, I learn from what went wrong, what went right and what was passable but could have been a home run. Each company is different and unique in how they like to approach these implementation projects, but there are a few things that have stayed consistent. These consistencies end up being critical to the success of each project. Let’s simplify these learnings to the acronym PRUNES. Like its fruit, utilizing the principles behind the acronym PRUNES will keep your ERP transition project regular, healthy and blockage free: 

• Project Visibility 

• Risk Mitigation 

• User Buy-In 

• Nice-to-Haves 

• Exception Workflows 

• Self-Training 

One of the fastest ways for a project to lose momentum is for people to panic. When panic sets in, project work almost always slows (or stops) until everyone gets a chance to discuss and get on the same page. I regularly find that someone in the group has a good answer to whatever is causing the panic, the problem is visibility. This is relatively easy to mitigate is the good news, but requires someone (hope you’ve got a good project manager) to keep information up to date. Some ideas for these tools might be a project plan, weekly or bi-weekly project status meetings, “problems-to-address” punch list, deadlines and specific assignments on project tasks and many others. The key is to discuss early, and revisit “how is our communication?” regularly. Panic is easier to mitigate before it starts than after it is rampant. 

Identifying risks (“what could go wrong will go wrong”) early and planning for them properly is not only critical for project success, but also for every team member’s comfort and confidence in the project. One example of a risk could be a physical count for the go-live. Physical counts take time and significant team dedication, as well as a halt on inventory movement. These are notoriously stressful for the team and for impact on customers, and pairing this with a go-live amplifies that. The key is planning. Get a written plan, specific timing, steps and team member assignments. “What could go wrong will go wrong” turns into “we are ready for whatever will go wrong”.

One of the biggest mistakes (that doesn’t always seem like a mistake until its too late) that seems to happen consistently is not letting end users have the ability to buy in to the project until the design is done. In these scenarios, we will hear complaints about “we don’t do it that way” or “that is way harder than how we used to do it”. In many of these cases the users may end up liking the new workflow, but they didn’t design it. Humans desire to feel like they have control and ownership over what they do. If you let the end users (the ones who will actually be doing the workflows) design and give input, the change management shock will be much less. 

Implementations are thought to be successful if everyone can do their jobs on go live. As long as the need-to-haves are covered, that’s successful right? Take it further. One of the best ways to gain good favor and positive view of the change management is to throw in several smaller nice-to-have wins for the end users. With proper planning, there is always time to fit in a nice-to-have. The psychological impact of relieving a user’s pain point can turn a resistant team member into an eager team member on a dime. Showing them their opinions and wants are valid can fix a potential blockage. While seemingly less important, giving stubborn actors this part of the “PRUNES” can ease tension and make for an easier transition.

When telling us their workflows, clients are very good at telling us the way they normally do things. During this discovery, I always asked “is there anything else you do that might be different from that?” I can’t think of a single time that question has gotten more info out of someone, but there are always exception workflows. Something that requires handling the process differently. Instead, recontextualize the question to something that puts greater stakes on the question. Something like “If you had to train a new employee how to do your job, what’s the thing that would make you say ‘oh, watch out for this customer, we handle them differently’?” or maybe “If I had to take over your job for the day, what process would I have to do that you haven’t described yet?” By posing the risk of someone else having to do their job (and maybe messing something up on that job), you can get these hidden workflows out and designed early.

Have you ever had someone teaching you something that works perfectly while they are sitting there, but the second they leave it stops working? Let me guess, as soon as they come back it starts working again too, right? In my experience this phenomenon is because of comfort level. If you have someone who can correct you or tell you to stop if you do something wrong, you aren’t afraid to make mistakes. However, the trainer can’t be there all the time for everyone. This is why it’s critical to overcome this feeling in the training sandboxes before go live. If you can spend time making mistakes and learning from them before the data matters and get used to not having your trainer around, go live efforts become much easier. This particular “gotcha” leans more toward psychological comfort than just being used to the system.