Organizational Change Management and ERP Success

Enterprise resource planning initiatives mean change. Often the question is how to manage change while you’re reshaping company goals, processes and technology. Organizational change management (OCM) is the process of preparing employees for adoption of new technology.

ERP software projects tend to falter without an effective change management strategy. Join us for an inclusive conversation of how a company’s culture is impacted during this time, and how to achieve the buy-in of employees.

Connect with us!

https://www.erpadvisorsgroup.com

866-499-8550

LinkedIn:
https://www.linkedin.com/company/erp-advisors-group

Twitter:
https://twitter.com/erpadvisorsgrp

Facebook:
https://www.facebook.com/erpadvisors

Instagram:
https://www.instagram.com/erpadvisorsgroup

Pinterest:
https://www.pinterest.com/erpadvisorsgroup

Medium:
https://medium.com/@erpadvisorsgroup

Transcript

Juliette Welch: Good afternoon everyone. Thank you for joining us for today's call: Organizational Change Management and Its Impact on ERP Success.

Shawn Windle will be our speaker for today. Shawn is the Founder and Managing Principal of ERP Advisors Group based in Denver, Colorado. ERP Advisors Group is one of the country's top independent enterprise software advisory firms.

ERP Advisors Group advises mid to large sized businesses on selecting and implementing business applications from enterprise resource planning, customer relationship management, human capital management, business intelligence, and other enterprise applications which equate to millions of dollars in software deals each year across many industries.

On today's call, Shawn will discuss tips for taking on organizational change management in order to help increase employee buy-in and to ensure your ERP implementation is a success.

Shawn, are you there? Are you ready to take it away?

Shawn Windle: Sure, yeah, thanks Juliette. I appreciate your introduction and welcome everybody to the call here on Organizational Change Management and Its Impact on ERP Success.

So, I'm just going to talk for about 15 to 20 minutes here on this particular topic, which is quite near and dear to us. And I think you'll probably get some nuggets out of this discussion. Please feel free to use them as you’re looking at your internal initiatives.

As well as give us a call if there's anything that we can provide in addition to what I'm going to talk through. But hold onto your hat, because there's a lot to go through. We will make the recording available online if people need to go back and catch some of the specifics as we go.

So, here's the most important thing on organizational change management as it relates to ERP success — OCM, as it's known in the market. It is not a gimmick.

This is really important because I think some of the other firms in the marketplace use this as a tagline to create services and offerings, and oh, OCM’s important, OCM’s important. It absolutely, positively is. But it really is just part of an overall ERP implementation.

You can't have a good, successful project if the software is configured and it meets the requirements and all the data is migrated and all the integrations are built, that's great, but can the organization actually use the product? Can the end users — the people that are stuck with this thing — do they know what they're doing with it?

So, we look at organizational change management I think a little bit differently from other firms in that that's the context that we're most concerned with is how are people actually going to use the software when we go-live? Are they ready to use it? And are they willing to use it?

So, with that more pragmatic approach, we've developed a five-step process to apply organizational change management that I'm going to go through. But again, I really want to emphasize that our approach is extremely practical, in the trenches — I'll even talk to some of the experiences where we did do these things and where we didn't, and what the results were.

So, the first step and the most important thing is to truly assess your organization. And this is probably the most important thing. I think it's a big reason why clients engage us because we do have the ability to look very honestly and objectively at an organization. And what we're really looking for in this assessment is its willingness to change.

You'll have some people that are very willing — those are usually the people that are driving the project. And you'll have others that are very unwilling — they're usually the ones that aren't around the project. And then you have a lot of people in between.

The key thing there though is to be objective and look at from a highest of level of strategy of the business and the owner's view on what their goals are, all the way down to the end users and what's really happening with them on the on a day-to-day basis. And really look at why the organization needs to do this software change, and do they really believe they need to do it?

So, the assessment is more focused on not just the existing culture and the tone level if you will of the organization where high-toned or medium-toned or low-toned — that's kind of a relative concept. But you really need to assess the organization from the standpoint of, are people really wanting to change and do they really see the need for it?

So, this may come down to, maybe the owners, maybe even in a private equity situation they actually do need the organization to change the software solution, but the entity itself doesn't. You may have a long-term owner of an organization that sees the need for change, and the organization is unwilling to do that. You may have an organization and the key subject matter experts from each of the functional areas that see the need, but the owner doesn't see the need.

There's a whole book that could be written on just that one topic. But start with that assessment and be honest, too, about where your individual stakeholders are at with their willingness and need for change.

Once you have that done, now you can put into place a real change management plan that has very doable tactics that will get results. This is the second step.

So, what we mean there is looking from the beginning of the ERP initiative all the way to the end, what do you have to do in between then to get to the result that you want at the end? Again, this isn't rocket science, but the execution is where the failures and successes are made.

So, for instance, communication is a huge part of change management plan, training is a huge part. There may even be some financial incentives that you do for some of the key people that have a day job already, maybe even a night job, and now you're going to put the ERP implementation on them. So, there might be some bonuses or some extra comp that you get for them for change management tactics if you will.

And then there may be some other things that you end up doing, maybe even having the company go visit another company that's using the software already.

We've even done things like having massage therapists come in as a change management tactic at the end of the implementation to physically ease the stress of the team going into the go-live. I thought that was actually quite interesting and I thought quite clever. That was the Erica on our team, her suggestion.

Especially for accounting people that are coming up with a lot of data migration. They usually have a year end or quarterly end that they’re trying to do and month end and everything else, so they can tend to get a little stressed right before go-live. So, massage is one of the tactics we use for change management.

So, you want to put into place those tactics and make it very specific with what needs to get done, who's going to do it, and when. So, simple change management plan that includes that will be huge.

Now the third thing is to keep doing the change management tactics no matter what.

So, I'm going to give you a really good example here, because another tactic is — if you think about managing change, one of the best and most important tactics is actually doing system walkthroughs with the users while the development is occurring. That will help so much for people to actually see what the software is going to do so they don't get yip-yap about it. They actually have to go into the product and see it.

And so, we had a client that we had scheduled several walkthroughs for, and within a couple of days of the first walkthrough there was a major shift in the business and they had to cancel the walkthrough.

We were able to put it back on the books a couple weeks later, and at that time we only had half the people that showed up for the walkthrough and those people were able to give their feedback and give their perspective on what needed to happen in that.

So, we got that in and those core people that had been removed to focus on that another initiative basically didn't become available until go-live.

So, then we had a go-live that was literally like user acceptance then. It was the system walkthrough — it was one of the first times that they had seen the product.

We were brought in to facilitate the project so that wouldn't happen. And very honestly, we did everything within our power for it not to, but there were just realities with the way that the business was operating in the amount of resources, or lack thereof of resources, that were available. Our go-live basically became a, like I said, a user acceptance test.

So, when I look back at the best practice here, this third item of keep doing the change management tactics, no matter what — even if we would have had a couple people show up for those system walkthroughs upfront for one of the first things we did, but we just stopped after that, even if we would’ve had a couple more people continue to show up, we probably should have done it because it led to a very rocky go-live.

Again, when you have that plan, really stick to it no matter what happens or what disruptions occur in the business. I mean, they're just realities.

The fourth item here under our best practices for organizational change management, and I've alluded to this already, is test, test, test. Nothing beats having users in the product during the configuration stage. Nothing beats happy users in the product during their user acceptance testing phase where they should be testing it. Make sure that they do test them. Nothing beats having the users in the product after the user acceptance test changes have been made by the development folks.

I'm getting kind of technical here. But then even having the final true end users in the product during training. So, when we're training, that kind of becomes a test cycle in another set of people who haven't seen it.

When we talk about testing, we always think with this concept of expanding influencers where we always start the tests off with just a couple really key people that have a broader view and they really understand what we're trying to do with the product which is a fancy way of saying they have imagination so they can look at an earlier version of the product and they can say, “yeah, this is going on the right track” or “no, it's not right.”

They might not see the whole thing, but they can see an earlier preview of it and they like it. That's good indicators.

Then we open up to the next biggest group of influencers which is maybe one or two people at first group. Maybe we have four or five people who then are getting into the product and doing a little bit of a of a test drive — it's more like sitting in the in the in the driver’s seat and just turning the wheel, not really starting it.

But just starting to look at the software and starting to understand what it's going to mean for their life basically for how they do their business. And then they can provide some feedback that will be helpful.

So, then you build that feedback back into the product to then go to the biggest end group of influencers. This might be ten to 20 people that are in the product now, and they're actually doing the test drivers. There’s enough of the product there for them to run their end-to-end business processes, and they're able to provide a lot of user experience feedback, but they shouldn't be telling us, “you don't support blanket purchase orders and I need that,” like we should have found that out in the first couple iterations of testing.

Then from that group you go to the final group, which includes all of the end users. Like I said earlier, that usually happens during training. And you want those end users in the product as close to go-live as you can so that they work through things even like passwords and login. Where do I go to login? You don't want that question to be asked on go-live. Let's get that one solved earlier.

So, there's this test concept of going out to that, four different types of influencers flash users will help you so much to manage the change because the biggest factor that people are afraid of in an enterprise software rollout — whether it's the ERP or HCM or supply chain management or eCommerce, whatever — it's the unknown. They don't know what they don't know. So if people can see the product now, they know what it looks like, then they don't have to dub in if you will what they think it's going to be and they feel a lot more comfortable with the change from there.

So, the fourth strategy is the test test test test.

And then the last one is on go-live have all hands ready to support that go-live no matter what — from the CEO down to anybody in the entire organization.

When you go-live with software, you need to plan with the worst in mind.

We have a friend of mine actually, who works for a large corporation, a Fortune 500, and they just rolled out — actually, it wasn't even app change per say, it was more of a technology infrastructure change. They moved all their apps from on-premise servers to the cloud. Sounds easy enough.

Friday you'll shut down the old app, on Monday you open up your new link to the same app, it just resides someplace differently. What could the problem be? Well, the apps didn't work for multiple weeks. Unfortunately, people got fired over that one.

And that goes back to the example of when you do go-live with any enterprise software, you have to have people available to handle any kind of problems that could come up.

In the instance I just told you about, had more people been available, there could have been the last minute tweaking that was needed to make sure that the users could get into the system and that things could work for them.

So at go-live having all hands ready is probably the — call it the icing on the cake for a good change management plan.

So, with those five strategies in mind, you see how organizational change management goes away from surveys and more touchy-feely things — how are people feeling about the project? What do they think the biggest risks are?

It's important to collect that upfront and your initial assessment. But I wouldn't spend a lot of time on that as you go on. You really have to observe for yourself what the key users are thinking and how they're feeling about the application and be willing to communicate and confront all of the key resources during the project. I say confront because oftentimes the project fails not in an area that was unknown. It was something that was known that either somebody didn't communicate to the right party, or they did, and the current party just didn't take the time to really understand what the impact is going to be.

I hope that what I've done in this this this call is given you some real tactical things to do in your implementation of enterprise resource planning software, as well as other stuff.

Know that OCM is not just some gimmick. It's actually kind of baked into a solid process that you have to have, or you're never going to go-live successful. And you don't want to be that person that is behind the project, whether it's a couple hundred thousand to $50,000 to several millions of dollars — tens of millions of dollars. Doing these really simple strategies will help you to increase your likelihood of success probably 500%.

There's always other risks, the implementation partner, and other stuff. We have lots of calls on some of those other areas, but this is an exciting area for us, I think, because we really pride myself on our firm in that all of our people think with the concepts that we just said — very practical and can certainly help you out.

But definitely keep these points in mind as you go forward on an ERP project and you’re going to be a lot better off.

Juliette, I'm ready to get off my soapbox.

Juliette: Shawn, thanks for that. That was a lot of great information.

Thank you everyone for joining us for today's call. Please let us know if you have any questions. We're happy to answer them, so set up a call, just reach out to us either through our phone number or website.

Our next call is September 11th: Can On-Premise and Cloud-Based Systems Coexist? In this next edition of The ERP Advisor, we will discuss the differences and benefits of on-premise versus cloud-based systems and whether or not an organization can deploy both.

Please go to our website erpadvisorsgroup.com for more details and to register. Thanks again everyone.