Announcer: This is the ERP Advisor.

Introduction: Today’s episode: How to Get the Best Deal on Your ERP Selection.

Juliette: Thank you everyone for joining us for today's call: How to Get the Best Deal on your ERP Software. Shawn Windle will be our speaker for today. Shawn is the founder and managing principal of ERP Advisors Group based here in Denver, CO. 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. 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 software solutions. On today's call, Shawn will discuss how to get the best deal on your ERP and the factors you must consider before signing on the dotted line. Shawn, can I hand it over to you?

Shawn Windle: Thanks Juliet, I always appreciate your intros. I wrote it so it sounds good.

Juliette: Yeah, it's great.

Shawn Windle: No, but it is kind of interesting. I was reflecting, while preparing for the call today, on the amount of deals that we do close each year, or even since we've been in business, and we literally do 10s of millions of dollars in software and services, whether it's implementation services from the implementation partner, or integration services, or our own services, but that's per year. So, you know, since our founding, we've done well over $100 million. So, basically helping clients to determine what kind of deals they should get for their software. So, we know what we're talking about is the basis of what I'm trying to get in. We've learned a ton during that tenure in doing this work. I'm really, really grateful to be able to share some of those insights and thoughts with you. Definitely look to the website here. We'll take the content that I'm going to talk to with our great marketing firm, and we'll go ahead and make that available online as some whitepapers and some other downloadable information. So please, please, please feel free to use this information. This is one of those calls that will probably save you a lot of money on your software deal, so we're really glad to be able to do that.

What I'd like to do is—I'm going to give you a little bit of background, as I always try to on these calls, to get you set up to where you need to be. Then we'll talk about the types and categories of negotiation factors that you have in doing any enterprise software deal. That could be enterprise resource planning applications like a big SAP or Oracle, all the way down to customer relationship management, professional service automation for services firms, HR software—don't care—it's all applicable, but enterprise software is what we’re going to talk about here.

Hopefully, if you've listened to some of our other calls, you've gone through a good needs analysis process to really understand what it is that your organization wants and needs for software. That's the first thing you've got to do. So, do you need HR software or just payroll? Are you looking for talent management? Or do you also need to put in some applications around onboarding just, for instance, in the HCM area or for ERP? We talk about this a lot. ERP is a philosophical approach to deciding what kind of software to use across your enterprise, so hopefully, you've done that work of saying, “this is exactly what software we need.” or “The kind of software that we need.” So, that's done. You know what you need out of the software. Phase One done.

Then, you've done a really good selection process where you've kind of written down your requirements. You've had vendors demonstrate, as a demonstration script to you, your exact requirements, not just have the vendors say, “OK, well show me what you got.” Don't ever do that with the vendors because they're only going to show you the great stuff. But if you say, “Show me this, this, this, this, this, and this” in the sequence that you want to see it—so maybe it’s order-to-cash and exactly how your organization places orders, and the processing of orders that happen, and how you do fulfillment, and how you do billing, and you push that out. Then say, “Show me how you would do that in your software.” That's what you want to do for a demonstration process.

Then, you've also kind of worked through the number of users that you needed for each module that they're suggesting that you have. So, you want to make sure that you've got those modules that are required identified. Then, you've also vetted the implementation team that's going to be doing your implementation. I've said this before, and I will keep saying it, that the implementation resources are so important. You're basically betting your job on their capability. So, you better make doggone sure you know who they are, you know their skill set, you know that they're going to be on your project, and you know that the lead from that implementation team that you have, their cell phone number, and then you can call them anytime.

So, let's say you've been through all those steps, you're down to the last vendor, and you are absolutely certain that that software is the best fit for you. Now, you know there are going to be problems in the implementation—don't kid yourself on that—but now that you've done a really good process, now is the time to start talking about negotiating software, the pricing, and everything else that I'm about to get into. That's really, really important guys on the phone here. You don't really want to get into the negotiation on software until you are absolutely certain that they're the best fit.

Now, you may do that with two vendors for sure, but in our selections, we're doing about five or six selections. Literally, right now, we really don't do a final negotiation—we only do a final negotiation with one vendor. We don't take the time to negotiate with a vendor, that's just not a good fit. So, you know, you really want to get it down to that last option that you know is the best fit. OK, I've said that enough.

So, let's say you get to that point. Now it's time to negotiate the deal, so here are a couple of things that I want you to understand. The deal is made up of, usually about four or five components. So, the first component is the software—the software order form, some vendors call it an order form, some call it a quote, but it's basically here's the software that you're going to buy. That's the first thing.

The second thing is a service’s statement of work, and sometimes you may buy that after you get the software, but it's always best to buy it at the same time. That's the implementation services required to configure and to implement your software. That's the second thing.

The third thing are general terms and conditions, so this includes things like warranties and other, kind of, “more legalese” that go into usually supporting the software, but there's terms and conditions documents.

The fourth thing is a support contract. Almost every software vendor has some form of support that they offer, and so that'll be in a separate document or documents that you have to include in your due diligence.

Then the last thing can be hosting fees. So, if you buy a product, a software product that's offered on Prem (?), but you want to put it at a hosting provider, like a Flexential or somebody like that, then there's hosting fees that go with it, and even some of the vendors, like Infor for instance, when you buy software from them, they'll have a separate hosting fee agreement set.

So those are four to five areas of the deal, so again, those are the software order form, the service’s statement of work, general terms and conditions, support contract and agreement, and then potentially hosting fees that go with it. Now some vendors may have other types of agreements too, but the first four are the key categories that I really want to focus in on for this call.

So, what is the software order form? That basically lays out what you're going to buy. So, it could be the modules, the specific software versions or editions that you're purchasing, the number of users for those modules, and it usually lists what's included as part of those modules. So, it might say advanced pricing is made up of multi-tier pricing by different customer segments. There's like a description of the modules that are in there and then the number of users that you're paying for to use. Some vendors do concurrent licensing, user license. Some do name or seat licenses. The difference, basically, there is the concurrent license says: “We don't care how many people use this software, but you can only use it up to 20 users, or up to 100, or up to 500 users.” Whereas other applications, other vendors, will sell specific seats. So, this is the number of users that you have. You have 20 seats, and they don't even care if those twenty people use the software or not, but they, basically, those individuals have the ability to use the software. So, it lists what you're buying. It also lists the terms of the software as well as the payment terms for the software.

So, we talked about what you're buying, modules, users, et cetera. How much, basically, of the modules that you're buying. The terms of the software would include the length of time that you're buying the software for. So, a lot of our contracts are with applications that reside purely in the cloud. They're called software as a service multi-tenant application. So, SAS, basically. You hear that phrase a lot. What that basically means is you pay for the software every year. Now, you may get a 36-month term on your software. So, you're basically saying, “Yeah, I'm going to contract to use your software and pay for your software for 36 months.” 36 months is the term of the use of the software. Then you might negotiate, also, what happens at the end of those 36 months. So, renewal terms are usually defined in the software order form as well as the discount that you're getting on the software. Then the other thing that’s kind of, listed in there are payment terms too. So, all of those items are, basically, levers that you can pull in your negotiation.

Don't just focus on getting the best discount as part of your software negotiation. I can't stress that enough.

What matters more often is, “Hey, let's get a good discount.” But then let's lock that in for a longer term. So, instead of a one-year term, let's go for three years or let's go for even five years. Some vendors will even go 10 years on this contract, but the key thing about the term of the software is you are locked in at that software price throughout that whole time.

Now, what a lot of savvy clients will do, and what you all better do because you're on this call, is negotiate the renewal terms also. So, at the end of, let's say, a three-year term, what happens. Very often you can say, “Look, let's put a cap in a 2% increase, and then you can even say, “At the end of this first term, I want a renewal cap that's 2% on a renewal term that's also 36 months or three years.” So, you might have six years basically locked up with a bit of a renewal in the middle, and then that gives you the ability after the three years to say, well, maybe we got bigger, and we need to get into a bigger application.

So again, key terms to look at for the software order form are: What you're buying, the number of users, the length of time of the contract, the renewal terms, the discount, and then the payment terms. So those are kind of the key items. I could probably do a call on just discounts and also on payment terms but let me leave that area and go on to the statement of work with just two more thoughts on the discount.

Software is one of those businesses where the margins are super, super, super high. The cost of service or cost of goods sold of software is very, very minimal. You write the software once and then you sell it to a ton of people and yeah, you have to pay for a bunch of hardware to run it and all that, but just know that there's some good room on your discounting that you can get. So, if a vendor says, “I'm going to give you 10%.” Fine, they're going to start with a discount percentage, but know that they can go more. Can they go 80%?

Well, we've gotten that for some clients, but it was a very unusual circumstance. But, you know, vendors are willing to go 25% easily. That's a minimal amount. Very often we’re able to negotiate the whole deal, not just the software, to basically pay for our fees for our clients—oh, I'm sorry—one last thing on the software order form, too, is the payment terms. So, don't pay for your software upfront. If there's any way that you can push out the payment terms on your software so that you basically get some value from the software first, before you have to pay for it, that's always better.

I could do a whole call on that, so if you need more information on that, just let us know. We can talk through that.

OK, a couple more areas here to cover. I think we're doing good on time. Now we may do a follow-up call on this too if there's enough interest, just let us know.

So, the next area of the body of the deal is the service’s statement of work and “Oh my gosh!” I wish you all could see all the lessons that I've learned in my mind right now so that you don't make these mistakes. Lots of focus goes into the software contract and then the service is like, “Oh yeah, that's fine. Go ahead. We trust you guys.” It doesn't work that way. What basically makes up a service’s statement of work are the exact services that you're purchasing. So, when we're talking about buying software, those services are the services to implement the software, which may include project management, the analysis and requirements design, times configuring the software, testing the software, go-live, post-go-live support, all the things you would expect to be in there. What you really, really have to watch out for are the following three things.

Training. “Oh yeah, we’ll do your training.” OK, that sounds great and then they put in the contract “We’ll train your trainer.” Ok Good. Now you get into your implementation. You're rolling along, and that software somehow turns out OK, and now it's time to train everybody and they say, “OK, we'll train your trainer.” What do you mean train the trainer?

Well, they're going to train one person and then that one person has to go train the thousands of employees that are impacted by the software. You're like, “What are you talking about?” And they said that's what was in the contract. So, very often the implementation vendors will not include a lot of time for training, so watch out for that and that’s OK if you know it. Just be aware of it.

Data migration is kind of like the Tesla to the gas-powered engines. Data migration to us is a form that is very, very sticky. Fortunately, we've been through this a million times, so we know what to look out for, but if you look at a large-scale professional services firm that has hundreds or thousands of projects that are in flight, and when you go to go live with the new app, all those projects have to be moved over because people are billing time to them still.

So, you can't just say, “Oh, we're not going to bring over all the old projects.” Well, fine, you don't have to do that, but you have in-flight projects that are open and have to get moved. Who's going to move them? Who's going to go to the old system and figure out the data structure in the old system to be able to then extract those projects out, then convert them or transform those projects into the new format for the new system? Then someone’s got to upload them into the new system and make sure they get uploaded and then someone has to review those projects in the new system to make sure that the year-to-date billings in the new system are the same as the old system.

Much less, we've had a large-scale engineering firm we worked with that had extremely complex revenue recognition rules on their projects, so then they had to make sure it was set up the same in the new system as the old. So, data migration can be a bear and a lot of times the vendor will say we'll help you to load your data. Well, who's going to help me to get it out? Who could help me to clean it? Who's going to help me to transform it? And then, even when there's a problem, the vendor pushes the import button then it bombs, or it errors out. Who's going to fix that error? They're going to come back to you and expect you to fix that. So really be aware of what you're getting with your data migration.

Then the last real gotcha in a statement of work on what's included are customizations. So, during the demonstration process, we have a large steel distributor, for instance, that we're working with right now that has some very complex requirements around how steel is cut and some other things. We know that's going to be a customization. So, we're able to tell the vendors, “You need to scope that out now and put it into your statement of work going forward so that we know what that customization cost is going to be.”

The only problem is, in reality, the vendor is going to spend like an hour, maybe, asking a bunch of questions, and then their guys or their gals going to sit back in some conference room and say, “Well it's 300 hours.” Then you say, “Where did you come up with that?” It's usually a lag, you know, a wild, whatever guess. They have lots of experience in “da da da da da” so, fine. But we often asked our vendors to say, “Just show us your assumptions that went into building your customization estimates.”

“Oh well, we're going to have to create a couple new records and then there's some code that does this and then we have some new fields that do that, and then there's an interface with the AR module that does this.”

“Oh, and then your estimate was 300 hours. Now that makes total sense great. Well, but what about training on it?”

“Because it's new.”

“Oh, you're right.”

You know estimates are only going to go up on customizations, but you need to at least make sure if you have customizations in scope that they're part of that statement of work. So those are the three gotcha areas in the statement, in the service’s statement of work: training, data migration, and customization. So, look out for those.

Now, related to the service’s statement of work, what levers do you have to pull? What negotiation points do you have to pull with the statement of work? There's certainly just the number of hours that are included in it. There's always the rate, which is usually an hourly rate that most of the services are based off of, and then there's also payment terms on the services. So, on the rate, let's talk about that.

We really prefer hourly projects. We have a lot of clients, and we work with private equity firms and, private equity firms I think are notorious for this, they want a fixed rate. What they're really saying is “When we increase the scope, we don't want to pay for it.” That's not just private equity firms, but you know an hourly rate keeps everybody honest. We will always ask the implementation vendor to give us a weekly report on what their actual hours were on the project, whether it's a fixed fee or hourly. So, we know exactly how many hours are going into the work. When you're negotiating a deal, it's better to see all the components that make up some gigantic number. So, if you're doing an hourly, you can see where they're estimating 200 hours for analysis, 400 hours for configuration, 200 hours for testing, and then five hours for training. That's how you know, “Wait a minute, 5 hours for training. We have thousands of users. What's going on here?” Then you can dig into it a little bit more. So we like the visibility of hourly projects, but I'll talk in a minute here about some tips for negotiations on that, so I'll get to that in just a moment.

Another really key thing on the service’s statement of work are the payment terms. Please, please, please, please, please—I can't say that enough—don't pay for a lot of services upfront, ever, especially in software projects. So, some firms may ask for a small deposit just to help with their payment, basically, their contractor payments or employee payments. Fine, maybe 10%--OK, fine, but really anything beyond that, and you start to lose leverage over the vendor.

Now it's not just leveraged like, “Oh, you delivered a bad product, so I'm not going to pay you.” That's usually not the problem. Honestly, the problem anymore is, “We contracted with you guys, where the heck are you? You're supposed to be doing our project, but your people aren't spending time with us. Where are they?”

“Well, they're just busy with other clients that are yelling more than you are to get their resources, to be honest with you.” That doesn't happen with our clients, by the way, when we're managing the implementation, but the payment terms are always best when they're based off of a milestone or, certainly, in arrears for the actual time that's incurred. So, definitely make sure your services payment terms are not too much in advance.

OK, so software order form and service’s statement of work. There are two key areas—components of the deal. The third component is general terms and conditions.

Now these general terms and conditions are definitely—there's a lot of “legalese” that's put into these software contracts and—my wife works with me in the business here and she loves my dating analogies, so I always love for software contracts to give this analogy that I basically say to my wife. “Honey, I can't warrant that I'm going to do anything good. All the reasons why you married me, I’m really not going to do them, that at any given time, I'm probably not going to be able to deliver what you really want. But go ahead and sign here and say that you're agreeing to this relationship, please.”

Maybe you guys are getting away with that, but I'm not. If anybody knows my wife on the calls, you know I'm not getting away for that but, literally the warranty language that's in these general terms and conditions is—It's horrific.

I just pulled up a vendor that—I won't name a specific name other than they're called Impact—and the company says here: Impact disclaims all warranties with respect to the service’s system and documentation. They basically disclaim all warranties to any implied warranty or merchantability, fitness for a particular purpose, or non-infringement. So, they agree that Impact—the party will solely be individually responsible to comply with the laws.

They're basically saying here that you're buying the software as is and we can't warranty that the reason why you're buying it is that it's actually going to do what you want it to do.

Now, they all—and that’s not—I just happened to look at Impact. NetSuite’s the exact same. Oracle is parable. SAP is a joke. Microsoft is like, “Are you kidding me?” The exact same Oracle is parable. SAP is a joke. Microsoft is like “Are you kidding me?” Infor is like, “Really?” They're all that way. They all have those disclaimers of warranties. I'm getting kind of raw here, so I suppose I should watch it. I get pretty worked up for my clients here.

Anyway, the thing about it is that language isn't going to change. Now, the reality is, if the software doesn't work, clients will stop. First, they will call, they will complain, you'll see stuff on the Internet, and then they'll just start dropping off the apps like flies and just leave it. They will. So, it's the market that keeps these vendors in check. It's not these darn legal agreements, to be honest with you, it's the market that says, “Yes, you are. Your software is up, and it does what it's supposed to do. So, I'm going to buy it more and more and more and more, thankfully.

So anyway, just know that language is there. There's a bunch of other stuff in the terms and conditions. Just looking through an SFP contract right now, and they usually have billing terms, and that kind of thing can be listed in there. So, if you've changed the billing terms, which you really should try to, just make sure it gets updated in these terms and conditions documents as well. Know that a lot of the “legalese” that's in here would take legal counsel and hundreds of thousands of dollars in legal fees to change them. So, you just kind of don't, but just be aware of it. The limitation of liability is another one. That's like, “What are you kidding?” But that's just kind of the way this industry works. It's a bit embarrassing honestly.

Anyway, there you go. The other thing to look for in general terms and conditions is also the software availability. So how much is the software supposed to be available? Well, it's 99.9% of the time, but notice there's language in there that says, “outside of maintenance windows.”

“Oh, when are the maintenance windows?”

“Well, it's four hours every week.”

“Wait a minute, what?”

So again, just take a look at those general terms and conditions and know what you're getting yourself into.

Just a couple things here and then I'm just going to wrap up. The last component of the deal is called the support contract. So, you really do want to understand what kind of support you're getting from the vendor to support your product. Sometimes you don't buy any support, other times you can buy “Platinum” or “24/7”--you have your own account representative who's helping you. It kind of depends on how big the software deal is and how much complexity you have. But know that you are making that support decision and it's part of the agreement too. Then things like hosting fees and some other technology fees, those are kind of just independent—or dependent, pardon me—on each deal and those can be a little bit different. So just know that there might be a technology component that you also have as part of your software agreement in your overall kind of deal.

So, again the four or five areas of the software deal are the software order form, the service’s statement of work, the general terms and conditions, the support contract, those are all for sure, and then there may be hosting fees or some other technology. Look at all of them. For sure, for sure, for sure.

And then, just quickly, I know we're right at our time here, but let me just spend the next two minutes mentioning just a couple other tips and tricks here for negotiation.

Here's the first one: You have to really look at discounts, renewal caps, payment terms as levers, and if you pull one lever down, you might not be able to pull the other one down as far. So, if you're really shooting for a big discount, the vendor might not be willing to give you better payment terms. So, you have to really look at what's best for you. If cash is an issue maybe payment terms, pushing those out are more helpful, so pull that lever more than this. Honestly, the more software you buy, the better your discount’s going to be. Always. So, that's definitely a big factor. Then, when you're negotiating on software costs, you really can go pretty deep, like, probably even deeper than you think. You'll know when you go too deep, because the software salesperson will really start to push back on you pretty hard, not just, “Oh, we can't do that,” but like, “I'm going to get fired if I try to do that.” So, you want to take the indicators from the software person that you're negotiating with. Now, negotiating services costs, though, can be totally different. If you're buying services from a large company like an Oracle or NetSuite or Intacct or SAP. They have a lot of room that they can do also on those deals. But if you're buying from an implementation partner, there's not as much room there, and you're now dealing with an entrepreneur, usually of a smaller organization--$25 million or less company—and if you ask for too much of a discount from your implementation partner, you're going to get what you pay for. So, really keep that in mind for sure. Don't push those guys too far because then they won't support you.

Terms and conditions. Like I said, not much you can change on those, but look at the rate caps, the term of the contract, those are things you can change. Then, you know, remember you have a lot riding on your software in your services, so don't push the negotiation too far. It's not one of those times to try to prove your capability as a negotiator. You want to get a good deal for sure. Just don't push it too far because it will come back to haunt you. You will need help down the road, and you want to have a great relationship with those that you've worked with and make sure that they're willing to help you. So, definitely be fair, but also be super informed so you know what you can negotiate on or not. I hope that this call will help you with that.

Definitely, any questions, let us know we're here for you all. We can do a consultative call for 15 minutes and give you a ton of advice that would be helpful.

So, thank you, Juliette back to you.

Juliette: Thank you, Shawn, that's a lot of great information. Thank you.

Thank you everyone for joining us for today's call and as Shawn said, definitely let us know if we can answer any questions you have. You can email us, call us, contact us through our website.

Our next call is on April 10^th: What to Do When You Need to Replace Your Records Management System

So be sure to join us for that. We'll discuss the key factors to consider if you are thinking of replacing your RMS, please go to our website erpadvisorsgroup.com for more details and to register. Thanks again.