A Business Case for an ERP System Upgrade

Erica Windle: Thank you for joining us for today's call: To upgrade your ERP…or Not. A Business Case that Guarantees Absolute Certainty.

Shawn Windle is 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 the four key components that every business case for new ERP must have to ensure support for your project.

I'll turn it over to Shawn.

Shawn Windle: Okay, thank you Erica. So, this is Shawn Windle. I’m the Managing Principal and Founder of ERP Advisors Group. And I'm excited to talk to you more about a business case for upgrading your ERP or not.

And so, as always for the call, I do like to define some really key terms that we're going to talk about here.

And I will tell you from doing this for years and years, 80% of all of the work in enterprise resource planning is literally in just understanding what needs to get done, what ERP is, what the impacts of it really are — just truly understanding enterprise software, specifically ERP.

The other 20% is execution, which is hard, but once you have that really good understanding, you're in great shape.

So that's the purpose of the calls that we do with this trusted advisor. So, here's a couple terms I'm going to define.

I'm going to talk about what ERP is, what a road map is, where cost benefit analysis is, a business case for new ERP, and I'll also actually talk about what upgrading means to as it relates to ERP.

Okay, so here's the first one. ERP — enterprise resource planning — ERP is not a sound that a little child makes after they drink too much soda. It just actually stands for enterprise resource planning and basically it's a philosophical approach to using business applications to automate business processes across the entire organization, it's as simple as that.

Meaning, how do you use software to execute really key processes and computations and calculations and store data and report on stuff throughout the business?

And it can really be any of the business processes from HR — human resources — employee lifecycle, all the way through the customers and vendors and manufacturing and projects and government accounting and everything that a business or organization or nonprofit does.

Enterprise resource planning, basically like I said is a philosophical approach to determine how best to automate those processes.

And then the word upgrade is interesting. So, we talk about upgrade or not on an ERP, what we're basically saying is taking an existing ERP application — let's just say Infor Syteline, which is now called CloudSuite Industrial, or maybe you're running an older version of it and you're trying to decide if you should move up to a newer version.

Could be the same thing for SAP, could be the same thing for Microsoft Dynamics AX, so it could be the same thing for really any ERP package, but the idea is that the upgrade really means taking the existing software and getting it into its current state.

The state that the vendor, the software house or even software manufacturer — you could say — is basically offering at that time in present time.

So again, going back to our example, say we implemented Syteline five years ago and we did a bunch of stuff to it; we didn't take the upgrades. And now we're trying to decide if we should upgrade or not — basically moving it up to the most recent version. That's what an upgrade is.

Okay, now when we talk about a road map. What we really mean with a road map is how we get from where we're at today to where we want to get to in the future.

So literally, you're in a car and you're in Los Angeles and you want to get to Seattle, let's say, and how do you get there? Well, that's a bad example because you jump on the five and you just go. That's easy. You don't really need a road map, but let's say there's a specific neighborhood that you need to get to. So, use a map to get from where you're at to where you want to go.

And this term is often used in ERP to say, where are we at with our systems today? And how do we get to that next level that we want to accomplish? Usually driven from a certain level of functionality that we need that we don't have today. And how do we get there?

Cost-benefit analysis is another term we use here, and it's important because what that kind of drives towards is an objective view of what are the costs of upgrading and what are the benefits of upgrading and let's take a look at those and compare them and see which one is better.

If we have more costs, that's bad. If we have more benefits, that's good.

We definitely want to take a look at that cost-benefit analysis. That's part of it, too. And the last word here is business case.

So, business case for new ERP really entails all of what we just talked about there. There is a definition of what ERP is. There's a definition of what the upgrade means. There is a road map that says here's where we're at now. Here's where we want to go. Here's how. And then here's the cost-benefit analysis proving that we are going to get more benefits than we are cost.

And really encompassing all of those factors into one set of communicable — could be slides, could be a word document or just one specific package — we call that the business case.

So, there's one other piece, too, that we need to add to that business case, which I'll talk to you here in a little bit.

So, I hope that's more clear on what ERP is — upgrade, roadmap, cost-benefit analysis, and business case.

So, let's talk about this. So, as the title of our presentation says today — To upgrade your ERP…or Not. A Business Case that Guarantees Absolute Certainty — well, how in the heck do you get absolute certainty on if you should upgrade or not? Well, I'm going to tell you.

And this is based off of many years of doing these kinds of projects, but it's probably more about working with some of the best people in the industry are clients — also many people on the software side over the years.

And so, I've seen what works for a business case, what executive committees, what boards are willing to do and approve versus what they're not willing to approve, and so ultimately that's what we're trying to do is to get that that approval from the board to do the upgrade.

And the way to do that is through the business case.

So, the first important thing that you have to do for your business case — that's going to guarantee absolute certainty here — is you have to perform this cost-benefit analysis.

So, I talked about this a little bit earlier, but I'm going to be really specific right now on exactly what that means.

So when we talk about costs, we don't just talk about like, well, how much does the software cost? Now there's a lot more to it, and on one of our earlier trusted advisor calls, we even go so far as to tell you the exact components that make up costs and how to negotiate on them. So, I'd highly recommend you take a look at that.

But in this instance, when we're talking about costs, we are talking about the costs of the software, which could be a recurring cost. So, you have to look at it over multiple years.

You have to look at the services to install the software, the technical services. Then there may be project management or facilitation fees that first year that you incur — the first year you're implementing.

There may also be hardware costs that you have to do to just upgrade your machines, whether it's laptops, remote devices like iPads or iPhones, or barcode scanners and readers and all that kind of stuff.

Maybe even your network. Like if you go to a cloud-based solution that's only available through the cloud, well, your internet connection might need to be upgraded, so you really have to include all of that in your analysis of costs.

And you want to look at it on an annual basis. So, what's year one going to cost? What's year two, year three, and maybe even go out to year five?

That takes a little bit of working to get that down honestly with the vendors, and to figure out which vendor’s your best fit.

We also have some calls on how to do the selection process. So that's how you do the cost side.

Now the benefits side — benefits are a little bit tricky.

When I worked for a large management consulting firm — the largest in the world — and we would do these kind of benefits analysis, a lot of those analysis were based off of benefits from eliminating stats and leveraging technology.

So, when you have a larger organization, there's certainly those opportunities, but even then it just seemed to me in the real world those people didn't get let go, and they usually got redeployed to more value-added activities.

So, benefits are a little bit more difficult to estimate, but we think about benefits in two categories: there's hard benefits and there's soft benefits.

Hard benefits are absolute benefits you're going to get by replacing your existing ERP or upgrading your ERP to the next level.

So, for instance, on some of the apps these days they have gone from on-premise where you have to run — you have to have the servers the heating, the cooling, the security, environmental software, all of the other software that has to be in place, you have to have it resources to support all that stuff when you're on premise.

So, we may be upgrading from an on-prem solution to a version that's in the cloud and woah, all those costs just went away. Well, kind of. Somebody else is going to do that for us.

So, by doing the upgrade from on-prem to cloud, there's a hard benefit. We don't have to have as much IT resources, whether it's hardware or even people dedicated to supporting the environment that the software runs in. That's a great example of a hard benefit.

Now a soft benefit of upgrading would be something that is maybe more like, oh, we can improve our revenue.

That's a little bit harder to measure frankly, but if we're running on, let's say an old green screen application, and we want to move to a more modern application that our sales division is more likely to use because it's easier to use and the web-based forms kind of speak to the generations that are using the app now instead of them going in and being turned away by the green screen and not wanting to get into it.

They are probably going to do a better job of tracking their pipeline and they are going to do a better job of reporting with their actual statuses and that gives you the opportunity as let's say a sales manager or as an executive over sales to manage your group better and maybe you will be able to drive a percent or maybe even 5% increase in revenue come out of your salespeople because they are actually utilizing the system better.

That's a great example of a soft benefit right there, and you can literally go through each division or each function of your business that the software hits — I should say even just each department — and say for sales this is the expected benefits we get, for purchasing this is the expected benefits we get, for overall accounting this is the expected benefits, for operations expected benefit, for professional services, for support.

The key divisions of your organization are going to be impacted by software. It better be a benefit that that department is going to get and it should be easy to do even just a real simple estimate that says if we replace the software for customer support, we think we're going to be able to retain more customers because we're going to provide better customer support. That's why we're doing the software upgrade in the first place.

Okay, well, how many more customers do you think we'll retain?

Let's say we're $100 million business and every year we lose 5% of our customers because of different reasons. Okay, good so. And let's say those 5% of customers or 5% of the overall revenue would be about $5 million, so okay, that's a pretty big chunk of change.

Now, how much of that do we think we can keep? Because we can offer better customer service through our systems. Well, let's say we can reduce that by half, so we can take that customer’s levy down from 5% to 2.5%.

Well, if that's if the if the ratio of customer revenue to the customers staying is the same, we just saved the company $2.5 million of revenue that would have gone someplace else, so that's a good example of another soft benefit. It's not hard.

It's very hard to measure it, but it is true. And what will happen is if you do those soft benefits across each of the divisions, you'll start to see there's a lot in there that that we can do that will really be a good reason why we should upgrade our software.

So, you got the hard and the soft benefits. Then of course going back to the upper level here of the cost-benefit analysis, now you can compare the two and you can say, hey, we expect our costs over five years to be this and now we have some benefits that we can look at that are that.

And I will tell you nine times out of ten you will see that the benefits will far exceed the costs, and I'm not talking about like 200% more, but there have been instances where we've had customers that have said we're going to have 10X the benefits versus the cost. So, if our costs are expected to be $3,000,000, we're expecting thirty million over a five year period.

The benefits out of this, so it's going to depend on the size of your organization, number of transactions we have, but that's the basics of cost-benefit analysis.

So, that's good. That's a big part of your business case. The last thing that goes into your business case, though that's important is what we call change management risks and mitigations plan.

So, what we're looking at there is okay, great, we have a business case for change, we see the benefits are higher than the costs. But wait a minute, what happens for real when we change like do all the employees freak out and run out the door?

We get to see that thankfully. But what is really going to happen when we pull the software out and put in something new — the upgraded version? And you need to look at a couple different factors there, too.

The first one is definitely the people, so the users of this system. How are they really going to be impacted by the software?

And sometimes it's like, eh, an upgrade, it just changes a few things, it's not that big of a deal all the way to, yeah we're going from green screen to internet and maybe the population of our users is such that they’re not very technically savvy. So, we're going to make this change, and it's going to change everything for them.

So, you really need to look at your people and assess what is the risk that we're going to have with them changing. And then you also say what's the mitigation? Like what can we really do? Oh, we do really good training and we have a lot of brown bags and we do a lot of the normal stuff that you do we’ll be fine. Good, don't care, that's fine, just get it done.

So, people is one of the first change management risks and mitigations that you need to plan for.

You also need to look at the project itself.

So, do we have time to do an upfront job with the needs analysis and selection? Who's going to do that work?

Those are usually the people that do that are your best people in the organization, so if they're super busy, you're not going to be able to do the project, so you want to always look at the actual project itself and the impact to the organization, specifically, the people involved in the project and if they have time and the skill set to do it.

And then the third thing to look for with change management is just the impact to the overall business.

So, one of our consultants who's been in the industry longer than I have — I think he's on his 30th year — he had a great analogy saying that this project we were particularly doing, it felt like we were an airplane flying in the sky, 30,000 feet going 500 miles an hour.

And now we're going to pull out the engines, like both engines, not just one of them, but both of them. And we're going to hope that there's no turbulence for the for the passengers inside, and that the little air thing doesn't come down and they all freak out.

Well, unfortunately, that was actually really troubling implementation down to a success. But you really do need to keep in mind that you have people, you have processes, but you also have a business that has to operate and continue to operate while you're doing this project.

So, you have to look for things like, oh, we're going to acquire two companies in the next six months. Or oh our private equity firm is probably going to sell us, and we're going to have to go back up on the block to get bought by somebody else. Or we're going to go public, or it could even be, oh yeah, we're going to open up five new offices here.

You've got a lot of business initiatives, corporate initiatives that are happening while you're trying to do the ERP project. It's risky so, but you can mitigate it. You can find ways to mitigate it, just be aware of it.

So, the key change management risk to keep in mind definitely our people, the project itself, as well as just the company, the overall business, and what's happening.

So that's kind of a lot of stuff to kind of talk through there but let me just summarize this into the four key components that the business case has to have for the upgraded software to really be supported by others within the organization.

So just to kind of summarize, you have to have a clearly defined recommendation, so this is what we're going to do. This is the why we're doing it, and this is what we hope to achieve out of it.

And here's where we're going to go, and here's how we're going to get there. So really, your road map explains a lot of that. Here's where we're going, and here's how we're going to get there.

Secondly, you have to be honest about what the costs are and you know what, don't hide anything and be conservative.

I've seen this over and over that sometimes champions — project champions — can feel like, oh if I tell them all the costs they're not going to do the project. That's an indicator in and of itself. You shouldn't do it anyway.

So, you want to flush out all the costs and look across maybe three years or five years so that you're looking at a really comprehensive view of what your total cost of ownership is.

As well as by all the components that we mentioned earlier, not just how much the software cost in the implementation, but the other fees that go with it.

The fourth component that you have to have are the benefits. It's kind of funny, right? We talk a lot about costs and ERP, but we don't talk that much about benefits.

So, you give an executive a number. It's okay, I want $5 million for the next five years to do this project. And they're going to say no. And then say what? What did you ask me again? All I remember is saying no, because you asked me for money.

You better make sure that you really covered this third component, which are the benefits I talked to that a little bit that there's hard benefits that are very easily measured and are for sure going to happen.

There's soft benefits that are really what we hope to expect and drive out with the new upgrade, so make sure you've got those benefits defined.

And then the fourth component is kind of this risk assessment, change management risks and mitigation, and this isn't just some namby pamby oh yeah, people are going to be mad and upset because their new system is going to change the way they do business.

No, like what's really going to happen to the key stakeholders who are using the system and how can we really — to the key people — how can we really mitigate those risks for them?

For instance, just as another example — your bankers are going to be impacted by this, because very often companies have loans, and if they have loans, they have covenants, limits they have covenants they have to report their earnings to the bank.

Or even to the, even if it's a public organization, certainly to the SEC. So, if we're going to change systems that may impact our ability to do our reporting on time, our financial reporting. So fine, that's a risk. Now, how do we mitigate it?

So, those risks are in the area of people, the project itself, how to manage the project risk and then the company and the overall business.

So those are the four components to keep in mind: clearly defined recommendation with a road map, the costs of the upgrade, the benefits of the upgrade, and the risk.

So, listen, it's pretty straightforward. It might not seem that way, and I'm glad you're listening to this and came to this webinar to get more information about it but let us know if we can help in any way. We can help clarify a lot of this stuff for you.

Erica, I'll turn it back to you.

Erica: Great, that was a lot of awesome information. Thank you, Shawn.

Thank you again for joining us for today's call. Please let us know if we can answer any questions you have.

Our next call is January 15^th: Why it seems so difficult to write an RFP for your ERP project. In this next edition of the ERP advisor, we will discuss how to avoid the stumbling blocks that will prevent you from writing this key document that you will need for communicating with software vendors.

Please go to our website www.erpadvisorsgroup.com for more details and to register. Thank you.