Dos and Don’ts for the ERP Selection Process

Juliette Welch: Good afternoon everyone. Thanks so much for joining us for today's call. We're going to go ahead and get started.

Today's call is the Dos and Don'ts for Your ERP Selection. Shawn Windle is going to be our speaker for today.

Shawn is the Founder and Managing Partner of ERP Advisors Group, based here 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 dos and don'ts for selecting your ERP software. We guarantee just one of these tips will dramatically increase your likelihood for success with your selection.

Shawn, if you're ready, I'll go ahead and pass it on to you.

Shawn Windle: Okay, thanks Juliette. Just a quick sound check — everything okay on your side?

Juliette: Yeah, it sounds great.

Shawn: Perfect okay. Thanks everybody for joining us for another edition of the trusted advisor.

This is a good one because as you know if you've listened to some of our earlier seminars, we really do try to be very specific with exact things that you can do if you're in the middle of an ERP project that'll make a huge difference for you.

So, I'm going to go through about four don'ts and five dos. I'd rather end off with the do's than the don'ts so we're going to start with the don’ts.

And as you may know from some of our other advisor calls here, our approach as a firm is to help everybody.

The industry that we work in — unfortunately, there's a lot of failures. Some studies show that it's even upwards of the vast majority, not just majority, but vast majority of ERP projects don't basically accomplish the business case that they were put in place to do.

So, what we want to try to do is help in any way that we can. Sure, we can help you with the entire project, but use one of these nine points — implement just one of them — and I know your project is going to go a lot better.

So, without further ado, let's jump into the dos and don'ts for ERP selection.

As I said, let me start off with some don'ts.

So, the first don't is don't start your project without knowing what you're doing and the why.

So, there's two important parts to that: the what and the why.

And here's the thing, when people start talking about ERP, they often really don't know what that concept means. They think it just is, oh, it's just a software or software application.

That's not the case though. ERP is a philosophical approach to business applications across your entire business with automating processes and running reports and tracking data and all that fun stuff.

But really know what you are trying to do with your software before you even start the project so when you go into it, don't go in without knowing what you're trying to do.

The other part of this one, too, is the why.

So, fundamentally if you don't know why you're doing an ERP implementation, I will guarantee you it will fail.

Our analysis and studies have shown that sometimes companies and sponsors really don't know why they're replacing the software — oh, the old one doesn't work very well or it's going to get sunsetted or people don't like it.

I can remember one client — a pretty good size software firm — that has invested quite a bit and customized the heck out of an application. And they were looking at switching and when we asked the why question it was because the executive assistant or the president didn't like it.

And when we started talking a little bit more to her and really dived into what was happening, she was responsible for running some KPI, some really important metrics reports and just didn't know how to do it. So, with some training she was happy and all of a sudden we weren't looking at switching applications anymore.

So, don't start your project without knowing what you're doing and why.

Now your second one is don't assume that everyone knows why you're doing it.

So, this one will kind of — you're going to see that these dos and don’ts build on each other.

So, often a sponsor will start a project and start doing the research, the analysis, start bringing in some vendors, start bringing in other people throughout the organization to do demonstrations. And people will come and say, yeah, for sure that makes sense, let's do it.

Okay, great. They do several demos, maybe even many demos, maybe even many, many demos, and after a while you start asking people to take a lot of their time and if they don't know the why, they're probably going to revolt against you when it comes time to then do even more time on the implementation.

So, please don't start a project and assume that everyone knows the why you are doing it. Make sure they understand the why.

Now the next don’t is much more practical. And something that we have learned over the years is don't ever do a demonstration without a demonstration script.

So, what we mean here is you talk to some vendors and you tell them what you want and need — and we did that in like 5 minutes. The salesperson is like, great, let's do a demo, let's schedule it, let's do it.

So, fine, you do the demo. You start looking at the demo like, wow, this is amazing. This thing can do everything. It's fantastic and it all looks great. And then you buy the software and start implementing it. And very often in that approach, the sponsor and people implementing it can say something to the extent of whatever the correct acronym is that my children use these days, but OMG. Or maybe there's even some additional letters I don't know in there. But they're like, oh, this doesn't do what we needed it to do. Well, that's the problem when you don't do a scripted demonstration.

Scripted demonstration basically says we're going to write down every single thing that we want each of the vendors to show us in detail, and we're going to hold the vendors accountable to showing us this.

And we might even try to stick it in as part of the contract to say we told you we needed this. Now you're going to deliver it. And so then that way if something later comes up or they didn't deliver something, you can always go back and say, guys, look you said you're going to do this.

So, don't ever do a demonstration without a demonstration script for sure. I promise — please, it will make your life so much better.

And then the last don't is a little bit of a tip here. If you've made it this far into the call, I want to reward you with that by telling you don't ever pay list price for software.

It's true that there's a lot of margin in the software business — profit margin.

What do I mean by profit margin? What I mean by that is, imagine something that you build once and you sell it to hundreds if not thousands of people, and it's the exact same thing.

I'm looking at a building right now that's being constructed, and this building is being constructed for one owner. That one owner has put in a lot of money upfront to build this building. And they're going to get a building at the other, but now they may sell it to another owner or group of owners, but it's that building is really kind of single purpose use for a single customer.

Now really in software itself, where that exact same software code can be sold to thousands, tens of thousands, hundreds of thousands of people.

So, the cost of the software was relatively minor and is marginalized more and more over more customers.

So, the bottom line is there is definitely room for negotiation in software pricing so please don't ever pay list price for software.

And I think we have another white paper in another webcast that we've done on some specific strategies for negotiation, but definitely take a look at those, they're super helpful.

So, those are the four don'ts. So, don't start your project without knowing what and why you're doing it, and then definitely don't assume that everyone knows why you're doing it — make sure that they explicitly know the why and agreed to it — and then don't do a demonstration without a demonstration script please. That's important. And then don't ever pay list price for software.

And I can give you lots of examples of those don'ts but the one that comes to mind the most is we were negotiating and helping the client through a negotiation recently. And as we had gotten through to the point where we had down selected to the finalist software vendor, the vendor had done the things that we described earlier, but especially on this list price thing, it turned out that we were able to negotiate a better price than even the private equity firm that owned the company.

And it really did go to show me that I do think there are some assumptions in the marketplace on software pricing on where it should be versus where it can ultimately end up being even a professional negotiation procurement person didn't realize that there was still more profit that they could go after —or more savings they could go after and still allow the software vendor to feel good about the deal.

Example after example, I can really go into each one of those areas, but I think that's the key on the don’ts.

Now let's talk about the dos.

So, I've got five dos that I’ve scanned — looked across the Penelope of all of our projects for different industries, different company sizes, different types of software, and it basically narrowed down to these five things that that I hope you do on your project, and I know that they're going to really help out a lot.

Here's the first do, whatever you do, make sure that you know what modules to include in your ERP.

So, what we mean here are when you look across an organization that's doing a selection, depending on who's driving the selection, that individual may be inclined to focus on just their departmental or functional needs.

Let's say it's coming from the sales organization or operations or accounting. But because the impacts of these software solutions are so broad across the entire organization, you want to make sure that you talk to the other stakeholders and see with your colleagues if there's other areas that would make sense to put in new solutions.

So, for instance, we often see that the office of the CFO will be doing an accounting selection and we had a great client here in Colorado several years ago that came to us and said, oh, we've got to replace QuickBooks and we want to do it fast, we want to get an app that just does accounting and everything.

And we said, well, what about your professional services group — several 100 people — and wouldn't it be nice if that tool was integrated into your financial system? And what about your sales function and your configured-to-order capability, do we want to tie that in, too? What about payroll and HR and how does that fit in?

And the client’s like, ah, you guys are just trying to increase the scope for the project. And it's like, no, we're just trying to save your job because we don't want you to put an application in now that then has to be replaced in a couple years because your needs were actually bigger and broader.

So, really do know what modules you're looking to include in your selection process. And frankly you could include more in the selection, but then buy less and then even implement less depending on what the needs are in that equation if you will as you look across how much change can your company take on at one time, you might not implement the modules you purchased right away — that might be phase two or phase two.

So, the first do is know exactly what modules to include in the ERP.

Now the second one is — I reuse this one a lot because I think it's the key to most of the work that we do with our with our clients is do choose an implementation partner that you're willing to bet your job on — because you are.

It's a funny thing that people — when they're going through the selection process, the focus can just be on the software.

And yeah, look, I mean you're buying the software. It's vital that you really understand the software and you like it, the user experience is good, and everything functionality is great. Super important.

But I'll tell you this, if you're doing a good selection, you get down to your top three — my guess is any of those three will be better than what you have — so then it becomes more a question of who's going to support us in this implementation? And who's going to support us later down the road when we need more training? And who’s going to support us when we need to to fit some new business models that comes out?

And so that's where these implementation partners come in and we've even gone so far as to choose an implementation partner first and oh, by the way, they offer the software solution depending on the client’s needs.

So, it's a super important one to choose an implementation partner that you're willing to bet your job on, because, like I said vaguely you are.

So, we know what modules, we have a good implementation partner, so now let's talk about leading into the backend of the selection process.

So, this is really important as you're evaluating software — and that implementation partner — is do meet with the implementation resources that are going to do your project.

So that's #3: meet with the implementation resources that are going to do your project.

It's a good one because you're not just relying on the actual salesperson that's going to do your budget.

Frankly, once you usually close — once they close the deal and then you move over to the implementation group, sometimes the salesperson has no authority or influence over your implementation at all, because it's a total separate division within the organization that you've selected that’s now during the implementation.

So, you can call your salesperson and say, hey, you said that it was going work this way. And she may say, ah, well I know I said that but I thought it did — let me call the implementation people. And she calls the implementation people, and they say, no, it doesn't, you oversold it, it's your fault. And it leads to a big debacle.

So, know that it's the implementation resources themselves — the project manager, lead consultants, technical consultants — that you want to meet even before you sign on the dotted line, so that then you can include those people in the statement of work before you sign it. And then you'll be assured that you'll get those specific people as part of your deal.

And I would say there's two people that are the most important on this point in terms of the implementation team. There's usually a practice director or an executive — it may be a VP of services.

This is the person who kind of runs the implementation function — it might be even a group of people, it might be the industry vertical for professional services practice director or something like that. You want to get to know that person, you want to have that person’s cell phone number so if there's any problems, you can call them and work through it.

But they have authority to maybe take a resource and pick it up and drop in another one because that resource didn't work out for you. So, you want to meet that person.

The other person you really want to meet is the lead architect.

So, this might not be the developer or the functional consultant, but there's usually somebody who has a ton of experience that maybe even get the demonstrations that is going to be part of their implementation.

But it's the guy or gal that knows the software the best, they know your industry, they end up knowing your business the best, and they're the ones that will tell their team what to do, what to develop and to configure. Get to know that person super well.

Okay, so that's the third item: meet the implementation resources that are going to do your project.

Now, as we're really winding the corner here coming into the homestretch, this is a really important thing — I mentioned this on the don'ts a little bit but do make sure that your contract has favorable terms in it for you and for your long-term ownership and usability of the software.

So, what we mean there is the days of let’s go spend a lot of money in year one to license software and then over time you just pay for maintenance are kind of gone. And very few apps are sold that way.

We just did a deal where they were and it was fine. But most often they're getting these subscription or software-as-a-service-based apps or cloud-based apps and they're sold on a yearly basis.

And what you can do in your contract is you can lock in terms that say you can't change my pricing for a certain amount of time and after that time is up, I want to cap on how much you can increase me because the reality is your first year is kind of shot anyway.

So, in your second year, you’re actually using the software and that better go well. And then third year you might be looking at how do you extend the software or do some more with it.

So, you really want to make sure that you lock in a good term on your contract so that each year you're not having to renegotiate with the vendor who may be willing or may be driving to increase your percentage on your contract and then you have to pay more for the software you just implemented.

So, just really be cognizant and do negotiate for favorable terms on the terms of your solution, the actual time frame that you have the software, as well as the payment terms, too. So, know the payment terms are also negotiable with most vendors, too.

So, that's the that's the fourth item here.

Now, let's say you sign the contract and you're pretty much ready to go with the kickoff and the last do here is what do you do between the time that you sign the contract and the time that the vendor shows up on site to actually kick off the project?

Because guess what — your meter is going at that point. You're already paying for the software and sometimes the vendors are so dang busy — the implementation vendors, the partners — that they may say, oh yeah, we'll see in a month. And you’re like, what, we're paying for this, let's go.

So, the final do here is do start data migration and your integration specification work as soon as you sign on the dotted line for the selection. What you'll start to see there is that there's usually a ton of issues around data that just take a long time to work out.

And so, the sooner you get into those issues and the sooner you get to resolving how are we going to pull data out of our system? How are we going to clean this stuff? How do we define a customer? But all these questions that you have to work through take a long time.

So, as soon as you get into that the better because then you have more time to work on these really key issues throughout the project.

So, that's really the last one.

Another do that everybody forgets about — not really related to the selection — but I do just want it further in here too for the implementation, is definitely celebrate the team.

I think that's something we need to do better actually as a firm, too.

But these are big projects. There's a lot of don'ts. There's a lot of do's. But know at the end that you're taking people through a really tough situation, changing a lot — people like change or don't like change, whatever. There's just a reality that change is hard.

So, my final do for you is do celebrate the wins as you get them. Maybe have a team dinner even before you start the implementation just to set expectations. And then at the end make sure to do something fun.

We've done things from massage therapists coming in and doing some massages for people, especially when they're freaking out, margarita machines depending on cultures, whatever, that's fine. But just do something that would really help out and celebrate the work that you’re going through, because this stuff isn’t easy, that is for sure.

Perfect. Thanks for your time here and Juliette, I will pass it back to you.

Juliette: Great, thank you Shawn. That’s a lot of great information. Thank you everyone. We're so glad you joined us for today's call.

If you have any questions, reach out to us. We'd be happy to help answer anything you have.

Our next call is scheduled for Tuesday, December 11^th: Surprises You Don't Want to Have During Your ERP Implementation. We'd love for you to join us again for that one. We will discuss how to structure your ERP implementation project so you can identify surprises and handle them quickly before you get surprised by your boss suggesting you find a new job.

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