Episode 26: All Things ERP – Part 2

Andrew Powell: Hey everybody. This week we have part two of our ERP series. Last time we covered the basics of software selection. This week Dave Trayers and John Vancil talk through implementation, strategy, and lessons learned. Enjoy.

[tone]

John Vancil: Let’s jump ahead a little bit. We have gone through this whole selection process and certainly, we’ve glossed over a little bit of the complexity of the reality of that. We’ve done our negotiations. We’ve verified, you know, through talking to other users of the software and we’ve selected and we’re going to go to our implementation, right? So, what are some gotchas what are some things that– we just talked about one, which isn’t taking the people in your company that know the most about your processes and the way you work and putting them on the project? What are some other gotchas that we’ve seen that get in the way of companies to smoothly implement or migrate an ERP system?

Dave Trayers: One of the things in my experience that I’ve come to realize this… is in these projects like this, it’s as disruptive to the organization as just about anything. What I like to say is the human side of an ERP project is the more difficult side. It is easy to talk in terms of data. The part numbers and your bills and material. Give me your customer list. We can clean this up, we can set this up. The chart of accounts is structured this way. All of that isn’t easy necessarily, but it’s straightforward. It’s getting people to get comfortable with the new system. I’ve been in many organizations-

John: You’re talking about change management here, right?

Dave: Yeah. Human resources kind of change management and really using emotional intelligence skills, empathy skills, validation skills. You have people who are—the clock is still blinking on their microwave at home and now we’re showing them a brand new interface. An interface that’s twenty years in the future from the ERP that they were running, and they’re scared. They’re wondering about “can I do my new job?” They’re telling me that what I’ve been doing now, somebody else will do because overall the process will improve if we shift roles and responsibilities around, and they wonder what’s going to happen to me?

John: They’re wondering if they can bring their five-year-old in or 5th grader in to help them.

Dave: Yeah, exactly.

[laughter]

I’ve heard, even stated, some people say “if they upgrade this software, I will just retire because I can’t learn anything new,” and organizations that don’t address that, that don’t acknowledge that, will have a much harder time getting people to not just participate in the project, but do things like adequately test, talk about their business process to make sure that we’ve adequately mapped it to the system, participate in training, help us write documentation, and then just using the software. The worst thing to do is to say “We’re going to go and we’re going to upgrade our ERP system. We’re going to spend million dollars or more. Spend a year and go from point A right back to point A and people are back to using their spreadsheets and back to doing stuff outside the system.”

John: Right, and that change management—one of the ways that I’ve seen some of our teams impact that change management is in the way they actually develop the testing. Because I see our teams go out and develop process flows and process diagrams with the existing people on the floor or in the office. And then use those to develop the test plans and use those people to do the testing. And so all of that then familiarizes people with what’s going on and why, and some understanding because that the change management of the old way of change management of “Hey Monday Morning, You got a new system,” that-

Dave: Figure it out.

John: -figure it out.

Dave: And when you think about an organization and again the typical organizations that we’re working with may have ten, fifteen, twenty-year-old systems. The people that implemented that are long gone. What you’re left with is an organization whose people are just trying to make the system work. They have a job to do. They got to get stuff out the door. They got to pay the bills. They’ve got to do voices, that type of thing. And if the system is a hindrance because it’s so old, they’ll find workarounds.

John: You mentioned that and people have a job to do, but you also mentioned that maybe when this new system comes in somebody else does part of what you’re doing-

Dave: Exactly.

John: How would you recommend that companies approach the idea that their processes are going to change? There are a couple of schools of thought. One is: let all of your processes flow exactly as the ERP software writer envisioned, and another is to extend the software so that it matches your processes. What do you think is the right way to go about that?

Dave: I find that like most things, there’s a middle path. And it really starts in– and you talked about is, identifying processes. And in my experience and what I think we found here at OST works really well is to go in and start talking about processes first. Get those identified and by virtue of that, by figuring out the processes, what we like to call the processes that are obvious. The happy path, that order to cash, and just kind of goes. But what are all the side things that happen? What about when stuff is returned? What if the receiving some stuff and it’s damaged, what do you do? Find all those exceptions and we’re talking with the people who do those processes. A big difference that we found is that we don’t have a conference room.

Typically when you do these projects you have kind of a war room where more people can work. But we actually identify these processes out where they’re done. We’ll go out to the receiving dock and talk to the guy taking the stuff off the truck.

Show me your process. Let me just watch you and identify those. We’re turning those processes and mapping them to how it can be done in the system, and in some cases—this is where the middle path comes—in some cases, it would be better to do it as the system is defined. In other cases, there might be a reason where we want to do it differently.

John: Sounds like it might cost more money to do it that way, is it worth it?

Dave: You gotta look at it as a whole and in some cases, it might make sense to do it differently and this is where by having all the processes, we can start to put them into hand and see where things maybe get shifted around. Like most manufacturing, if you can drive things upstream, think in terms of quality, capture your quality as early as or your decisions as early as possible. There’s another notion of pushing decisions as low as possible into the organization. New ERP is gonna allow you to do that and that’s something we really haven’t talked about. But an ERP system a new one can be a catalyst to making these big process changes. So we can say no longer will we check quality at the end because of this new ERP system. We can do it in line at the time that they’re making something, capture it right then and if there’s a problem address it right then.

John: And we know that the sooner we capture a quality issue the less it costs us to fix it.

Dave: And people understand that. And so the person at the end that used to be responsible for all the quality checks will see their job change, but if we do our job right and we being not just the consultants but the client as well and how we communicate that, they understand how this is benefiting the whole organization and not that their job is going to be going away, but it may change.

John: Steering committee.

Dave: The steering committee.

John: Tell me about this.

Dave: This comes back to having leadership-

John: Yeah.

Dave: -involvement and so forth and you do need oversight. The steering committee, what’s their role? It’s to manage and watch the budget, make sure that things are happening on time. The steering committee is a communication tool to make sure all levels of the organization know what’s going on.

John: And I see the steering committee as a decision-making tool because-

Dave: Yeah.

John: -wow, people can get stuck.

Dave: Yeah. Exactly.

John: And somebody has to finally say, “okay. I’ve heard everything and this is what we’re going to do.”

Dave: And I know the example you’re talking about.

John: I remember names.

[laughter]

Dave: No, no, not at all. But that’s what it was. What was it? I think they were going on a month just arguing about whether the part number should be formatted this way or that way but these two disparate engineering groups, and finally, the steering committee stepped in and said “you have fifteen minutes to decide or I will.”

John: Finally meaning way longer than it should have.

Dave: Oh, absolutely. Absolutely. But that’s I think when, in that specific example, when the steering committee really understood their role. And started driving these decisions and driving them to saying, “Decide, people. Because we need to move this along,” and that was a pivotal moment for that team.

John: So we mentioned earlier a little bit we talked about developing testing scripts out of the process and that sort of thing, and one of the things that I’ve heard our team talk about, they say “training is testing, testing is training.”

Dave: That’s right.

John: I think it’s a great mindset to carry in and one that the steering committee needs to really push.

Dave: That’s right, that’s right. And it’s a natural progression of when you start with going through the processes and initially with the ERP especially if it’s really new. What you’ll see is in the first rounds of testing, it’s the consultant that’s doing all the driving because they know the software and that key user, that part of that team member from the client. They’re watching.

John: Over the shoulder.

Dave: Over the shoulder, because the first rounds of testing are always very ugly and you have errors and problems with the data and so forth and the consultant can get in there and fix it and then kind of move on documenting issues all along the way that need to get resolved. Then you do another round of testing after these fixes have been put in place. But the change now you will see is that it’s the key user that’s doing the driving and the consultant doing the coaching. If there are still problems and so forth that are getting addressed, and then we’ll do more testing and now we’ll see it’s the actual end-user that might be doing the driving and the key user providing the coaching. And this is how the testing and training are linked together.

John: And what you just indicated in that answer is something we’ve not really touched on. But an effective implementation is a very iterative process, is highly iterative. You’re doing the same thing in some cases over and over again and making improvements and getting it better and not unlike what we talked about, the earlier you discover quality issues the less it costs to fix it. The same thing goes for an implementation of any enterprise software, if you’re having fast iterations and you’re failing fast and discovering issues and fixing them quickly, then you don’t end up at the end with issues that require a lot of time and money to fix. But it definitely happens over and over and over again.

Dave: It does.

John: There’s a cycle to it.

Dave: And in the documentation that you’re developing as you go through this because you’ve documented a process, you found representative data, key data that you might test with, and so forth. You’re doing screenshots and what are you building? You’re building training material.

John: Right, absolutely.

Dave: And these can become standard operating procedures. So now, while after you’re live, you have new employees you can say here’s the SOP’s the operating procedures for this specific business process, and you can go onto the test system and do these exact test scripts that it started as we were testing and validating the system and now we’re using the exact same thing as training material.

John: Okay, that’s some good gotchas. Some things to watch out for and a loaded question. To use a partner to help do these implementations or do it yourself?

Dave: Yeah. That’s a question and what I’ve seen is companies that want to do it in-house ultimately find they don’t have the bandwidth for it.

John: And it’s a struggle on the expertise.

Dave: It is.

John: An experience it is.

Dave: Having a partner, having a consulting partner, whether it’s the software vendor as the partner or more of a partner like OST. That is, a partner to the vendor. What you’re bringing in is experience in environments different from yours. And so if you’re a small manufacturer you’re putting in an ERP system and you’ve been doing it this way forever, you’re going to tend to want to make the system do it that way and having a partner that can come in and say “Well, I may have a better idea; It would be crazy if we tried it this way.”

John: Because the experience and knowledge that you’re using is the experience and knowledge you’ve developed yourself. And you aren’t getting that outside experience coming in, you aren’t being able to leverage the experience of a team that might have fifteen, sixteen people with 20-25 years of experience doing this. You couldn’t afford to hire those people onto your staff.

Dave: No, exactly, exactly. And you don’t need them for the next 20 years. You need them to get through this. What you’re doing is you’re buying their knowledge for a fix or renting them basically.

John: 20 years. That’s crazy to think you would implement software that would last 20 years, but I feel it all the time.

Dave: We do. We’re supporting clients today that have 20 years or older software and in some cases, they have a philosophy “if it ain’t broke, don’t break it.”

John: If you look at that, then, and you think about doing an implementation and that implementation might take, let’s say 18 months, and you’re going to run that software for 20 years, presumably there’s some stuff you should be thinking about running, the running side of that rather than the implementation side early on.

Dave: Like?

John: Who’s going to run it? Who’s going to take care of it? Who’s going to take, if you put the software on-premise who’s going to take care of your servers and your storage and your network and all that? If you put it in the cloud, who’s going to take care of the configuring the system and making sure it’s up and running and making the changes and the extensions of those sorts of things. They don’t just sit there and run for 20 years.

Dave: And that’s the advantage of doing a cloud implementation is because somebody else that typically it’s the vendor is managing that for you. You’re hoping that they’re around in 20 years, but they’ll be caring and feeding the software providing updates, and so forth.

John: To a specified service level agreement. You can expect a certain amount of uptime and availability based upon contractual obligations.

Dave: That’s right. But even on the cloud, there’s still the support of the application in that. If a company, a client, does their own implementation, they typically may have some in-house expertise that can provide that knowledge, that level of support. And they become the go-to person. So even though it’s a cloud, you don’t have to worry about the infrastructure. It’s still the knowledge of the application that sometimes distills down to one person. What happens when that person leaves or retires or you can’t retain them? Okay by working with a partner, and having a relationship, whether it’s a third-party partner or whether it’s the software vendor themselves, you can help mitigate that risk because you are dealing with somebody who’s constantly up-to-date on the software and is working with you and if in 20 years somebody is going to retire.

John: And it’s the one or two vs. a team argument as well. Sometimes you find yourself, one or two people in your company who are supporting it and again we’re back to they’ve got their experiences and their knowledge and sometimes a partner will have ten, fifteen, twenty people that they can share a problem out amongst that team to come up with an answer quicker, maybe even a better answer.

Dave: I don’t know how to say this without it sounding disparaging, but we’ve talked with many companies that try to do it all inside because they say “We’re different. We are different. We’re nowhere a manufacturer, but we’re different from everyone else.” Well, I’m here to tell you after working with dozens or more of clients: you’re not that different. They all have many times the same issues. They have too much stuff they don’t need and not enough stuff they do need. And it just goes down to the same supply chain issues for example.

John: But there’s a human element to this and the human element says, “If I can walk down to Fred’s desk and look Fred in the eye and say “I want you to do this.” There’s a good chance I can get it done. But if I got to call Sally, someplace on the other side of the country and ask, maybe I don’t have as much impact there.”

Dave: That implies a really good relationship. If a company is going to have a partner that that partner really understands their business and we’ve seen that where we’ve worked with some clients where we understand their business better than they do sometimes and that’s the value of having a partner that’s kind of all in on supporting their client.

John: And there’s some nuance there to using the term partner vs. service providers and I agree. A partnership approach makes a big difference. So we’ve had a bit of a discussion here today. I think before we sat down we had some discussion about what were the things that we really want to make sure we hit on and we had six of those I think do you want to just kind of talk through those?

Dave: Let’s talk to through them and you can add some color. The first one that we had written down was: don’t be afraid of the ERP implementations, but you do have to take it seriously.

John: You do have to take it seriously.

Dave: Kind of like we’re talking about. It is a cultural shock and don’t underestimate that cultural shock. Don’t be afraid of it, embrace it.

John: Like all mythologies. They’re based on fact, and the mythologies of the companies that went out of business because the implemented an ERP, there have been a few of those. But it’s been a long time since I’ve heard of one.

Dave: That’s true.

John: But just take it seriously.

Dave: Take it seriously and the second one was: make sure a vendor shows you a demo using your data and your business processes. It doesn’t make a lot of sense if you’re a furniture manufacturer to see a demo of them assembling disk drives.

John: Unless you’re trying to get into a whole new business.

[laughter]

Dave: Well, yes, of course exactly. Executive sponsorship and a steering committee that works are really key to a successful implementation.

John: I don’t think you could have an effective steering committee if you did not have that strong executive sponsorship because they will not pay attention.

Dave: That’s right.

John: They’ll go pay attention to whatever the executives are asking me to pay attention to.

Dave: That’s right and there are going to be roadblocks and having that executive sponsorship, they say part of a great leader is to remove those barriers that the people—so they can do their jobs. And that’s fundamental to a good steering committee. We’ve kind of talked about this but because of the destruction: change management. Don’t ignore that. Don’t ignore the culture to the system, all of that.

John: It needs to be thoughtful and intentional.

Dave: Exactly. You talked about our phrase “training is testing and testing as training.”

John: Kind of rolls off the tongue doesn’t it?

Dave: It really does. We should trademark that. And last, don’t forget to plan for ongoing operations. Oh, okay. We’re live. And I was actually on an engagement when I was a consultant and we went live and I saw all the consultants disappear over the horizon-

John: Except?

Dave: -except me. And actually, even I disappeared. The client was “Oh we’re live. We’re good everyone can go,” and they pulled me back after about a month because they needed that ongoing support and what we learned was that that needed to continue and think in terms of that—the newness doesn’t go away once you say “Hey, we’re live with the new software.” There will be issues. And I guess maybe that’s part of that. You’ll have forgotten something.

John: Yeah, there will be issues.

Dave: And accepting that. But the good news is that in all of my experience there was nothing that when we discovered something after we were live that we were not able to fix in a very straightforward way. It isn’t like we had to say, “Oh, stop let’s go back to the old and redo it.” I’ve never had one of those.

John: And certainly if you can take a highly iterative reproach. You shouldn’t be in a situation where there’s something you can’t fix.

Dave: Absolutely and that’s one thing that I did not point out. When you’re doing this iterative approach, you’re starting to approach, they become dress rehearsals for a go-live. Because ultimately you have to do a cut over in some way shape or form, and each of these testing cycles really becomes closer to a go-live scenario. There should be no surprises when it’s done, but there’s a lot more that we’ve not even talked about here. Communication plans and all sorts of other things, so we’ve left a lot here on the table.

John: Definitely. So Dave, you know OST we are headquarters here in Grand Rapids, Michigan.

Dave: Yeah.

John: And we’re an old game manufacturer. They manufactured games here, chess and checkers and dominoes and all sorts of things like that. So, tell me, what’s your favorite game?

Dave: I have to say my favorite game actually is Scrabble.

John: Scrabble…

Dave: Growing up as a kid. We had Scrabble tournaments and in my extended family. And it could get pretty competitive with—and I have to say I was pretty inventive with some words that, Webby was one of the classic ones.

John: Webby?

Dave: Yeah. We almost came to blows over that. But Scrabble I have all sorts of great memories of that. How about you?

John: I used to love Scrabble until I got married and my wife consistently just d the floor with me in Scrabble.

[laughter]

I think for me, I’m kind of a classic. I like Monopoly. I like a game that you sit and you play for a long time and, maybe you have a cocktail while you’re playing it. You laugh and joke and it’s not quite as highly competitive because everybody knows how it’s going to end; the people who got Parkplace and Boardwalk is going to win. Somebody is going to get mad at somebody but a little traditional one.

Dave: Classic game. Did you have your favorite token? The cheaper?

John: Top hat.

Dave: Top hat?

John: Absolutely. Yeah, my brother liked the race car. That probably gives you a good insight into both of us. Well David, thank you for taking the time to talk to me today.

Dave: This is fun.

John: It’s always great to see you here in Grand Rapids and I appreciate it.

Dave: Yeah. Thanks, John.

Lizzie Williams: OST, changing how the world connects together. For more information go to ostusa.com/podcast.