The Top 5 ERP Selection Mistakes

Juliette Welch: Hi everyone, thanks for joining us today for today's call: 5 Mistakes Every Executive Should Avoid When Evaluating a New ERP System.

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

Shawn 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 equates to millions of dollars in software deals each year across many industries.

Prior to ERP Advisors Group, Shawn helped establish a successful technology practice with the top 50 accounting firms here in Denver.

There are only a few people in the world with the practical experience that Shawn has gained with helping hundreds of clients across many industries with selecting and implementing a wide variety of enterprise solutions.

Now let me introduce you to Shawn Windle.

Shawn Windle: Thank you, Juliette. I always blush a little bit when you say that.

So, today we're going to talk to ERP and ERP selection, specifically five mistakes that every executive must be aware of and avoid when evaluating a new ERP system.

As Juliette had said, between myself and our organization, we have hundreds of years of experience in selecting and advising clients through implementations on enterprise software.

So, we know what we're talking about, which is really helpful so that when we work with additional clients were not repeating mistakes that have been made in the past.

So, without further ado, let's go through the top five mistakes.

So, the first mistake to avoid is too many throats to choke. So, it's quite interesting that when you are going through a selection process, very often there can be multiple people that are interested in choosing new software and something that we have seen which is a mistake that really needs to be avoided, is to have a group of people that are responsible for their selection.

You really just need one. And that one person can involve key influencers along the way. Because ultimately, one person must own the decision in selecting software. And it's always best if it's the executive who's most impacted by the new software solution.

Now if you're looking at a solution that goes across the entire enterprise, even in that instance, it's better to have one person that's really heading up the selection process and working with the team to make the final decision.

You must involve key people in the organization — those that would be impacted the most have to have some kind of — need to have a say in the process.

But again, it's really important that there's one person — it can be a CFO, it can be a controller, can be a director of IT, CIO — we sometimes see an operations head that will head it up, but one person is the person who is going to be responsible for pulling all the data together and ultimately recommending which software solution to go with.

So, too many throats to choke is the first mistake to avoid. The second one is — unfortunately we see this a lot where clients have #2, an undefined scope.

So, when you have your person who's driving your process and you have your key stakeholders that are participating in that selection process, you'll really have to decide what parts of the business do you want to automate with software.

So, another way to ask that same question is you have to understand all of the business problems you want to solve with a new ERP before you talk to any vendors.

So, looking at the breadth of the business, the depth of the business, and the issues that you're trying to handle, look across the entire organization and see what could be automated with software. And you might even need to go deep into each department to determine what functionality specifically you want to provide.

So, a good example of this is recently we worked with a services firm out of Northern Colorado — about 500 people.

And when they started their selection process, they knew they needed to replace their financial system and as we asked a few more questions, it turned out that CRM was fine, but the integration between CRM and the accounting system was broken — it was very manual.

It also turned out that on their services side — their time in billings — there were some issues. And even on their HR side, they were running software application that wasn't working quite well for them.

So, we brought together the integration, financials, HR, and projects into the full scope of the selection. And I'll tell you what, they would not have selected the right app had they not looked at that full scope because the full scope of software that's needed across the organization drives which vendors you want to be talking to.

So, another example of this is we're working right now with a company in Texas that came to us and said they needed a new ERP system and within about 2 hours of talking to him, we knew they really just need a new accounting system, so we probably saved him a couple $100,000 because all those ERP vendors are ready to sell that software even if it's not necessarily needed. So, versus just getting an accounting — a new GL package which can expand into some other areas.

So, the second mistake to avoid is definitely having an undefined scope.

And the third mistake is — we call it ERP fatigue. So, you ERP fatigue your team with too many vendors and too many demos.

The reality is that software is very confusing to those not intimately involved in the process and I would say very often that even those that are involved, well, they have day jobs. They’re driving, they’re running the HR department, they're in operations, they're in services, they're in accounting.

And when you start seeing a lot of software solutions and you're busy, it's just a lot of stuff to look at on a screen and there is certainly a beauty pageant component of it from one of our staff members wrote a blog on not choosing software based on a beauty pageant.

But what happens is after about three different applications — so three demos — the solutions start to mix together and it's very hard to differentiate in one's mind what solution is which.

And we've probably — I personally have attended many demonstrations over the years, and I even have to go back and take screenshots and make sure that I fully understand each vendor as we go through this. So, it's definitely difficult to do.

But a real key thing though, is to screen the vendors with a select team first. What I mean is have a couple people — maybe three or four people — do what we call a mini demonstration with the vendors and it might do three or four or five or six, that's fine, but it's a small group of people and have them limited. Down to maybe two or three that you put in front of your entire team

So, the third mistake there is that you avoid the ERP fatigue of your team.

But too many vendors and demos.

The 4th issue is to remember the mistake that we have that we see sometimes is that the selection is about the software. That's actually the mistake. The reality is the selection is about the software and the implementation people — it's about both.

So, it — but at the same time it's vital to ensure the software will meet your needs. That's absolutely critical.

But it's just as important, if not more, that you get really good resources who understand your industry, definitely their solution, and they're available and interested to do your project. Otherwise you end up wasting a lot of money on software that isn't configured to your business.

We had a client recently in the mining industry that I know we picked the right software and then we thought we had picked the right implementation resources and the vendor just assigned the wrong people.

And it led to budget overages on the vendor side even. The vendor ended up losing about a quarter of a million dollars on the deal, and even on the client-side they incur additional dollars because the project got extended further.

There were time delays, and more importantly, there were just some really upset people and that's the worst part about this is when these projects go south and people get frustrated.

But the fourth mistake about ensuring your selection is about the software.

But that — it's about the software and the implementation people is super vital and will save you a lot of headaches long-term.

So, that’s the fifth mistake. And by the way we actually have a bonus sixth. So, get ready for that.

But first we have to cover the fifth. The fifth mistake — and this one could save your job. I'll just be totally and completely honest with you. If you're doing a selection process, this is one that you definitely need to write down. You definitely need to think about — definitely shoot us a note after the session. We can talk about this one.

So, the mistake is that the budgeting is not an accurate total cost of ownership, and the implementation timeline is not doable. So, we have a budget and timeline that are just unrealistic.

So, some tips here are always include contingency in your budget and don't tell anyone about it but your boss.

I know that sounds kind of funny, but the person that you're ultimately reporting to if you're ultimately responsible for the selection and the implementation — you need to be honest with them and forthright on where the project’s going to come in at and that you have included a contingency.

But if you tell the software salespeople, if you tell the implementation team, even if you tell your own team sometimes, they're going to use that money — guaranteed because they know it’s there, it’s going to get used.

So, it's always better to come in under budget, but not sandbag too much, of course.

So, keep that concept in mind of building in a budget that allows for some leeway later on.

And then when we talk about total cost of ownership — this is important because we're very honest with our clients and our clients are very honest with us when they go over budget and come back to us and say, why didn't you tell me about this? So, we have a lot at stake here.

When we talked about total costs of ownership, we include the software, of course, there's a base implementation cost, so an implementation partner — let's say you select Epicor and the Epicor implementation team comes in and codes that software.

But then you also may need scripting for custom requirements you may need project management on your side to run the project, you might even need resources to go into your legacy system and extract the data and massage it. That's data migration cost.

Plus, there may even be technology infrastructure and even on a software-as-a-service cloud-based solution all within the cloud, there's no infrastructure. Well, how's your network connectivity? How are your desktops and your laptops? And the performance of your internal network is vital, so there's some investment that might need to go there.

And then there's additional technology resources that can kick in, too.

So, if you have complex integrations that need to be written, or you have a third-party tool that you're buying as well that you have to pay for that, so that's what we include in that total cost of ownership. So, you want to make sure that you budget that as accurately as possible.

And then on the implementation timeline, set an aggressive but doable implementation timeline and communicate what is real to your boss again. So, the longer the project timeline, the more other priorities will compete for your internal and even the external resources.

It sounds interest — it sounds like, what do you mean? I mean, we're paying for all these people and my team’s lined up to do it. And the reality is, especially with the implementation partner because they're very busy, there are other priorities that group slip in ahead of yours.

And guess what everybody is working on? It is not your project because there are other priorities or other projects that they just need to get done now. So, you want to set an aggressive implementation.

So, if you think that the project is realistically going to take let's say six months, you may want to set a timeline at four months or even five months and communicate that timeline again as you're talking to your CEO, the owners or — ultimately, you're responsible reporting up to tell him what I really think this is going to take six months, but I want to cut back a month. I just want — they give us that sense of urgency to get this done.

And then the other part of that, too, is to implement the project in really short phases — that helps minimize the impact of the company. And it just requires less resources, so the smaller kind of bite size you can keep your ERP, your HCM, your CRM implementation, the better.

We had a company that we worked with as an example here that I think is a really interesting example to share.

They had underestimated the cost and they underestimated the time to do the project. They were a software company. They sold software to hospitals. And what they hadn't accounted for was the cost of data migration.

So, if you think about a software company, there's a lot of contracts — same thing on the services side where there's a lot of projects, but in this case it's software contracts.

They had to convert all those contracts and put them into the new system and just the activity of finding all the contracts, extracting all the key data from those contracts, making sure it was correct and then putting it into the format that the new software needed took over a year to do and they spent a lot of money and time on that. So, that really killed the implementation. Ultimately, they did end up going live, and then they got bought.

So that's the fifth mistake, but there's one more thing that really comes out. It's kind of like the bonus mistakes here that we want to give you that you look at all the way from the sponsor that there's a defined sponsor up front — got it, check. Now you've got a scope and you've looked across the organization, decided this is exactly what we want software to automate so that you know what you're going into — check.

Now you're not taking your team through the ERP fatigue, which was our third issue. Now you're only showing — you've got a small group of people that's evaluating more about more vendors to then bring it down to a smaller group that then two or three vendors that you put in front of your entire team.

Tomorrow, I'm going to be in Oklahoma to do one of those presentations — so check done.

The fourth one was on remembering that it's about the software and the implementation resources, that's the mistake there.

And then the fifth, of course, budget and accurate TCO — total cost of ownership — and have a doable but aggressive timeline.

You can do all that stuff and your project will still fail on implementation if you don't do what I'm about to tell you.

And that is you better line up adequate internal resources for the implementation.

What I mean is your best and probably your busiest people are the ones that you're going to want to have on your software implementation. And unless you can replicate them — which we actually think we figured this out but it's with one of our bio sciences clients, but we can't release that technology yet.

But the bottom line is, is those really key people are the ones that know your processes, they know how things work today, they're the ones that are going to have to work to closest with the implementation partners. So, you have to line them up so that they can participate adequately and put adequate time into the project.

We did a cost analysis for a client recently on what it would cost them to backfill. It was a good-sized manufacturer, maybe under 100 million. Pretty complex product, mostly domestic, but pretty engineered-to-order kind of product.

And we looked across their whole organization for an ERP that would touch almost every department and we identified that their total cost for backfill was only $150,000. And that may sound like a lot, but when you're implementing software at a million or $1.5 million, you're really talking about maybe two people that can be spread across lots of others, because that's what you end up doing is you take your key folks and you take them off some of their day jobs and you have them focused on the software implementation.

So, in that vacuum then of what they used to do can bring in temporary folks or maybe temporarily promote people to do some of the more easier — more straightforward is the right word — work, that they should — that individual could now pass to basically pass a hat, right?

Where, let's say the controller knows everything because they usually — we love controllers. But the controller moves and focuses 50% of their time on the implementation. Well, who is dealing with reconciliations? Who's doing with the — dealing with really technical accounting issues? Who's dealing with the close? Who's dealing with financial statement preparation?

That's what that controller is doing for their time normally.

Well, it turns out that if the controller can define very specifically for their month end close checklist and pass some of the hats to some of their senior accounting people, or maybe even bring in a temp to do some of the tasks for them that that will alleviate a lot of pressure on the new software project as well as in the internal department.

Again, we do a lot of work with senior level accounting folks, and they usually just want to work more hours and you can do that, too, but I can tell you this fatigue is very real where you can only do that for a certain amount of time, so you really need to line up people to kind of do backfill — some of your key resources and of course organizations like ours have people that can come in and fill some of those roles and absolutely help on the implementation as well.

But we just find that that alignment of internal resources is probably the last thing you think about before you start the implementation, but it's the first thing that you spot when the you-know-what hits the fan is that our people are too busy in their day jobs to put on the project or they're working on the project and they're not getting the key task done.

Now we did have one client — a man who was a pretty famous guy in Denver — he maintains a list of people in the accounting world, that's all we'll say.

And he shared this story with us and with an entire group of people just recently. It's quite interesting. He basically told the board you ain't getting financials and then he told the customers — well, he didn't say any customers because he still took the money, but he told the vendors we're not paying you for about two months. And the board — we're not sending you financials for two months and they shut down their core operations.

And they implemented the software and they got it done in record time and then they were up and then boom they got in. They got everything caught up within a week or two and then they were off to the races.

Of course, they did that at a slow time during the year in their business and of course they set clear expectations with folks, but I love that story because it does go to show that your key people are the ones that have to be involved in the implementation and if you can take them off of their day jobs, you're really lining yourself up for success.

So, those are our five — actually six — mistakes that every executive should avoid when evaluating a new ERP system.

Juliette: Thank you again for joining us for today's call.

Let us know if we can answer any questions. Shoot us an email, give us a call, whatever works. If you would like a summary of today's talk, be sure to email us and we can send that out to you. Also, we'll be sending out a survey come so keep an eye out for that as well and we would appreciate your feedback.

Our next call is Tuesday, May 9th: Is the Cloud For Real For Accounting Systems? Please go to our website, erpadvisorsgroup.com for details and to register. Thanks again.