With so many vendors and platforms to choose from, you need a fail-safe formula for evaluating which one will ultimately be right for your organization. In this episode of The ERP Advisor, we will discuss the best ERP system selection criteria and provide a sneak peek at our Total Certainty System for vetting enterprise software solutions. Check out our selection guide here.
If you are wondering how to select an ERP solution, it helps to have a breakdown of what tasks are involved. The process can be complex, so we condensed all major components of the ERP Selection Process into simple milestones to help you plan your project. (We also provided some guideposts to the hazards that can spoil an ERP selection, so you know what not to do.)
- Gather User Requirements
Collect feedback from the people who will use the software, paying particular attention to any manual processes that can slow down your users. Make sure to engage the subject matter experts who will eventually help you to implement the system — without input on what their issues and challenges are, you can face resistance or protest. Missing critical considerations that should have been known in the very beginning can ultimately result in ERP implementation failure, so take care to be thorough and comprehensive in your requirements gathering.
- Request for Information vs. Request for Proposal
A Request for Information (RFI) provides background information on why you select software and only asks for high-level pricing information. This is in contrast to a Request for Proposal (RFP), which asks the vendor to provide detailed cost information. Important note: with either an RFI or an RFP, any cost information the vendor provides at this stage is only an estimate. The software demonstration process, discovery, and due diligence are all necessary to provide an accurate software and professional services quote.
- Requirements Document
Write your requirements in a logical format that breaks down the primary workflow of your company. For instance, a wholesale distribution company sells an order, passes it to Fulfillment, and Accounting sends out an invoice. Start the document with the requirements for your sales process, then outline the unique requirements for your inventory management and fulfillment processes, including whether a purchase needs to be made to procure items for the order. Then, lay out the sequence of unique steps Accounting must take with the incoming order and billings. While your users may have their own workarounds and unique ways to handle their business processes, you do not have to spell this out in your requirements document. Just tell the software vendor what you would like the software to do (i.e., tracking revenue recognition schedules, or automatically sending out invoices for upcoming due payments). You are looking for new software to bypass faulty workarounds, so don’t include the workarounds as a requirement.
- Avoid Boilerplate Requirements Documents
We advise against using a boilerplate requirements document or template from an online service. These often include thousands of lines of requirements, and they are a big turn-off to vendors because they are so difficult to digest. Vendors won’t pay attention to your deal if you provide them with a lengthy, convoluted document. Companies that rely on boilerplate documents usually do not know what their requirements actually are, and thus they fail to understand what functionality they need from their new software.
- Non-Disclosure Agreement (NDA)
To have honest discussions with the vendor, you will need to share sensitive information with them. Get an NDA in place before sharing your company’s private information, or an RFI. Most vendor NDAs are acceptable — and while some of them will sign your NDA, most vendors will want you to sign theirs.
Check out more resources on selecting a software solution for your business.
Intro:
This is The ERP Advisor. Today's episode: "Vetting Software Solutions in an ERP Selection."
Juliette:
Shawn Windle is one of our speakers today. Shawn is the Founder and Managing Principal of ERP Advisors Group, based in Denver, Colorado. Quentin DeWitt is our guest joining us today as well. Quentin is the Consulting Manager at ERP Advisors Group. On today's call, we will discuss the best ERP selection criteria and provide a sneak peek at our Total Certainty System for vetting enterprise software solutions.
Welcome Shawn, Quentin. Thanks for being here with us. I appreciate it. So, well, if you're ready, we can just dive right in. Are you good with that?
Shawn:
Yep, we're ready. Right, Shaun, we're good? We're going, great, good.
Juliette:
Perfect. So: Vetting software solutions in an ERP selection. Shawn, can you give us an overview of how we evaluate which ERP app will be right for a particular organization?
Shawn:
Yeah, for sure. I think along the way, we identified some best practices for ERP selection. And we looked at how do we codify or codify that into a methodology? And so we have what we call our Total Certainty Selection process, where the goal, the outcome is that our clients are absolutely certain. They have total certainty with not only the software that they've chosen, but also the implementation partner.
And I still to this day, I'm like, can I really do that? Like, if Quentin gets the selection and working with like, do we really do that? How do you do that? Because there's hundreds and hundreds and hundreds, thousands of options for software. And then if you pick a product like a Microsoft product, there's hundreds and hundreds of vendors that implement it.
So how can you be totally certain? So, fortunately we've come about a way -- we've developed a recipe if you will, for how to get there. And it's pretty straightforward, too. It sounds like, well, of course, this just works, but going through the process is a little bit more tedious. But the first thing we do is we help the client figure out what they really need.
So that's really important, right? For any problem in life, you wish you had somebody --
Juliette:
Not just for software, right?
Shawn:
I know! Like, I'm hungry: well, the problem that you have is you don't have the right food in the garage, or in your freezer in the garage or your kitchen or whatever, right? Basically what we do with our clients is say, what problems are we trying to solve with software?
And are those problems really solvable with a new software application? Or are we making them worse? So we will look at a client's strategy, we'll look at their people, we'll look at their business processes and their technology. Which is sort of a framework that's left over from an old consulting firm I used to work with, but it's really good though, because it helps us to understand and observe exactly what the client is. What is really happening with these folks. And then we get into what their real pain points and limitations to growth are with their business processes. And from there we can launch right into, can software really help or not? Ideally, what kind of software solutions would you have to solve these pain points?
So, yeah, it's sort of an organic process actually, where it just kind of is how life and business and management and executive teams and users think about things. And like I said, we've been able to develop this methodology so that, you know, at the end of that basic needs analysis -- the first part of it, anyway -- the client can say, "Yeah, that's really what is broken."
And we can say, this is how software can fix it. But then we go into even a lot more detail, which I'm sure we'll cover here in a little bit on our call, but we'll also look at benefits and costs and apps in the market. To then come up with some final recommendations where we could say to the client, like this is it, you got a list of a couple apps and here's what the cost is going to be.
Are you sure you really want to do this as a team and as an ownership team and as shareholders and stakeholders in that? So it's a very much a process of really helping our clients, really getting down to the nitty gritty of what we're trying to solve. And it's not like it's some special recipe, like some magical thing that we pulled out of the air.
It's just all the steps you need to go through to make a really complex decision simple. Makes sense?
Juliette:
Absolutely. Right. If it was just that easy, but it's a great process. That's for sure.
So Quentin, earlier today, you and I had a little bit of a discussion about the importance of demonstrations. What can you tell us about this and how it fits into this process?
Quentin:
Well, as Shawn was saying, we have a very, unique way and a workable way to identify what you need. So the next part of that is finding the actual software to fit that. And that's part of our selection process, software selection process.
What that starts with is sort of a vendor vetting process, but that leads into a very important aspect of that vendor vetting, which is doing demonstrations. And those demonstrations can really show you the look and the feel of the application, they can show you its functionality, if it's going to meet your baseline requirements, high level requirements.
And then, we usually have like a two to three part step in it: a presentation demonstration to see what it looks like and see if it's the right software for your needs from a look-and-feel perspective. Then we'll go into a mini demonstration, we call it. So it's where you're starting to align the requirements that you have with the software.
And you can hit a few high level points, look at the functionality, just see if it's flowing right, or if it works with your processes. And then from there we take it to probably the most important part: to fully match up those functional requirements to the software, which is a full demonstration.
And I can't stress the high level of importance enough on that, because a lot of times software vendors will just show you what they want you to see. And there are so many of them out there that, how do you really know if it's going to meet your needs versus what the software is company is telling you your needs are.
So those demonstrations are highly important to that. And by the end of that process, you know: not only is the software really close to what you need, you've seen it. You've seen if it works with your culture, your processes, it has a good look and feel.
But you've also met your vendors. You've gotten a relationship started with your vendors, and you know if that particular software vendor or implementation partner can really help you to get to the finish line of implementing this new software package -- that may be huge, and you haven't done it before -- to get to the finish line, successfully implemented, and helping your business to grow. So there's lots more that could be said around that. But I think that's a good baseline.
Shawn:
I want to ask him a question.
Juliette:
Of course.
Shawn:
So Quentin, what do you think the difference is in a selection, between selecting the right app and the right partner? So the folks that do the implementation ...
Quentin:
There's a big difference. A lot of the time you can have the right software. It can meet all of your needs. But the partner or the vendor selling it is not right. The relationship, their communication, they weren't responsive. When you ask them questions about how they were going to resolve something, they had no answer.
And it's a really sad point when you found the right software, but you haven't found the right partner. Oftentimes though, you can go and find another partner that can implement that same software package, if it's right.
Vice versa, sometimes you find the right partner and they are amazing: the communication, the business process, the knowledge of your industry is all there. But the software package that they're trying to have you go with is the wrong package. Sometimes you can mitigate this, they can do a different software package.
But getting that relationship right is an important part of the whole mix. And you shouldn't move forward with selecting a software package until you have that worked out and you know for sure on both sides of the equation that you have the right answer.
Juliette:
Because it would be pretty terrible to get into a project and an implementation and realize you're not a good fit. Then what?
Shawn:
It sort of reminds us of maybe a marriage that can go that way. That's not a good thing. Let's stay away from that, if we can. Not that any of us in the room would have any knowledge on that.
Juliette:
So none of this is without difficulties, as we know. But Shawn, what sort of problems can someone reasonably expect to encounter during an ERP selection? I know that's a big question
Shawn:
But it's a great question though, because there's realities, right? And then there's kind of what you think is going to happen. And then what doesn't happen. It's all over the place. But there's probably four areas that I think are the most important to look at for problems to try to mitigate them in advance.
The first one is just internal time. The people that are going to be required from a change management perspective. So you got to make sure that the people that are going to be using the new software have some say in what app gets selected. So that one in and of itself can just be very difficult, not quite nightmarish, but it can be difficult because people are busy.
And not everyone wants the same thing or thinks the same thing is usable or easy or what have you.
That's exactly it. And then you've got all these different viewpoints, and people would want to share their stuff, and sometimes they should, sometimes it doesn't matter, but you have to work through that. So that's the first area.
The second area is, which partners to bring to the table.
So just like Q said -- Q is short for Quentin, he's our Q guy, like James Bond -- we need to find a partner that knows the industry, that is somebody that you'd want to work with and would enjoy spending time with, as well as paying a lot of money. Because you're about to do that, but also knows the software app really well. Again, just like you said, we've got to find those partners. So that can be pretty tricky for sure.
Then, I mean it wouldn't be a good software selection discussion if we didn't bring up the magic of the sales demonstration. The bells and whistles. But what I really need to see are the gears and the shifter. Why do you keep showing me the bells and the whistles?
And actually as a confession, which I do sometimes on these calls, we were in a demo earlier today with a specific vendor. I do want to mention them, but I'm not going to. And this is a pretty good selection for a good-sized business, and a pretty complex software.
And we gave the vendor a script to do the mini demo, like Quintin talked about, which is a little bit high-level. But we were watching the clock, that's what we do: we help clients by being like the traffic cop or just making sure that the demo gets through what it needs to get through.
And I'm watching this demonstration go. One of my guys is really running the meeting, but I'm like, we're not getting into the app. First there was PowerPoint. Okay, can you add a little bit about-- and this is after the intro, by the way.
So there's PowerPoint, this is how the app works. And I'm like, "Huhhh, okay, great. Why aren't you showing it to us?" Are you telling us that it works this way in PowerPoint because it really doesn't do it? Then they go to the reporting and the analytics and the pretty dashboards. Right? The bells and whistles. Oh, well, that's good. I kinda like to see that too.
Then I'm like, "Okay, let's see some transactions." Because that's what we're buying. That's what all the users are going to be using the app for.
Juliette:
Is to see what what it can actually do.
Shawn:
Exactly! Then it gets into this other thing, this workflow configuration, and he said, "Oh yeah, well, one person's gonna set up the workflow. Everybody's going to use the workflows." We're like, wait a minute, show us the app.
So at about 59 minutes into it, I'm like, "you need to get into the product NOW." And he was like, "okay." So it was fine. But I was trying to kind of work with my internal people too, who were on the call and kind of communicating about the way the demo was going.
And I said, have we seen the product to my team? "No." So, isn't it interesting that you give somebody a couple hours to do this? Now I will tell you this, that from that point he covered all the functionality. So it was great.
Juliette:
Thank goodness.
Shawn:
Yeah. Thank goodness. But you know, again, this is kind of our third item, of the software sales person magic and pizazz, that some people have a tendency to focus on those things versus just the real app.
So watch out for it. But the good guys, they get it, and the good gals, they know, "okay, we're done with the dashboards and reporting. Let's jump into, how do you do a journal entry upload and set up an amortization chart" or some "boring" quote unquote thing, but that's what we're buying. So just watch out for that. That's a problem.
I'd say the fourth problem is definitely, really getting to the final pricing. Like what is this thing really, no kidding going to cost us. Because if we get into something and it's more than we thought, people get fired over that.
So in this selection process, we want to be very, very, very, very certain that we know exactly what we're buying. We know the services that are going to be required to do the buying. We need to know the data migration that has to get moved. And if there's some additional costs with that, do we need a PM? Do we need to hire a massage therapist? Or do we need to bring in margarita machines to keep people going? You know, whatever the costs are, let's look at those. Those are four areas to think about.
Juliette:
And that, I'm sure, isn't all of it.
Shawn:
There's tons more, but those are good.
Juliette:
So Q: I was wondering, can you provide some real world advice to our listeners today based on your experience with vendor vetting?
Quentin:
Absolutely. So I think probably one of the biggest pieces of advice I can give you is, don't just go out and start contacting software vendors. There are a lot of software vendors out there, but there's a few things you need to do before you talk to any software vendors or even look at software.
You need to know your requirements. Even if it's just a high level set of requirements, baseline. But before you do anything, know your requirements, because otherwise you will get sidetracked. The sales flashiness will direct you in one direction or another. You may even be looking in the wrong vertical for software.
So know your requirements upfront. Once you know them, don't contact the software vendor immediately. Do some online research, really find out what software packages, what level of software packages -- there's different tiers of software. So go and vet some vendors and assemble a short list of vendors.
Go look at them, do online vetting, take a look at the company, take a look at the software packages, how long they've been in business. There's a lot that you can do online before you talk to any of them. Because what you don't want to go out and do is talk to 20 or 30 software vendors. Then you're going to have an influx, day after day, of salespeople calling you, trying to get you to look at their software. And it may be the right software, it may not be. But you're going to get too much back if you do it that way.
So if you know your requirements and then you pre-vet your vendors, to get your short list together -- maybe three, four, five vendors, sometimes a little bit more -- then you can reach out specifically to them and tell them what your requirements are. And get feedback specifically around those requirements.
Shawn:
What would be an example of that? That's what I'm trying to think of.
Quentin:
I'll give a sort of off -- side industry, on the fire industry. It's not a typical finance or manufacturing or wholesale distribution. But the fire industry is a great example. If you think, "Oh, there can only be a handful of fire apps out there." There's more than 80 core fire apps that you could be looking at if you just went out searching.
So when you really did narrow it down though, there are about three to four really good fire apps that you might want to put in your fire department. If you had contacted those 80, you would just have a nonstop flood of information, too much to deal with, too much to sort. By the time you got through 10 or 15, you wouldn't even know which one you had talked to first, or who had what feature, et cetera.
So by narrowing the scope first and getting to the real good golden eggs, or the diamonds in the rough, you narrow the field, then you can really dive in with them. You can start a relationship. You can do the demo process that we were talking about. Make sure that you've seen it, "Oh, it looks pretty good." Then go to a high level of demonstration.
So that's one of the things, once you have done that pre-vetting and you have reached out, given them your requirements, you get responses back. And then this gives you another opportunity to even further narrow the field. And it's not wasting a lot of their time or your time, so you can narrow the field down.
You can have two or three vendors, and then you can take them into your real final selection round to pick the right one. Because there's too much out there to do it any other way. And you'll fail to even select if you don't do it in a very organized fashion. So there's lots of other things that can be said about this. There's details that you can look at like, is the company going to get bought by another company?
This is a sort of a jewel of what we do here, is really vetting the vendor, even to a certain degree more than the software. Because in the business world, as you well know, companies buy other companies, they see something nice over there or their competitor, and they just want to buy them out and that software is going to go away.
So you need to know that they're going to be there for you down the road. Is this just, "Oh, for the next year I'm going to use this." Or is this five years, 10 years? So vetting the vendor is of the utmost importance and there's a lot more that can be set around that.
Juliette:
I mean, because it sounds overwhelming, right? Trying to just approach it, high level. You know, as you say, I mean, it's a lot of information out there, right?
Shawn:
I think we've got a few minutes, I have to interject on something that's kind of funny. Again, I mean, if I look at -- I know you both very well, of course, I love you guys.
And working with you, it's been a lot of fun over the years. We do have some things in common. We have some things that aren't. Well, if you look at our relationships, right, we've been through good things, bad things, all of us together. And it's kind of funny because a client or a prospect to us who doesn't laugh at this analogy is probably not a good client for us.
Honestly, because we're kind of like real people, and we get into it. Because if you look at a software selection process, I think about what I did at some of the former consulting firms, super big projects and very serious and everything else, that's not us. We will always get to the right answer, but we're going to have fun and make sure we know everybody along the way.
And my wife is in the next room too. If you don't see the similarity of what we're talking about with dating, then you're missing the whole point. What everybody should do who's hearing this, is go back -- literally right now, go back about three minutes and listen to what Quentin said, and think about it from your own perspective of dating.
Because it really is important. The thing about it though, is that you are vetting options. You're going to be tied in, and basically your job is dependent on the software going well. So there's the dependencies and the creation, and the importance is at that level, if not higher sometimes.
So it is really funny when you talk about real world scenarios of things that have happened, where we've had clients say, "this is the application I want to go with." And we're like, "Oh boy, that's the wrong one." And now I have to show you, like you would like your best buddy or your best gal.
Oh my gosh, you're dating this guy and he's bad for you. But how do you get the person to see it? You go to facts. That's why we always do a fact-based selection process with that Total Certainty process.
So Quentin did a really good job with that public safety organization recently. Had come down to two vendors and you had to say, "okay, there's Vendor A, Vendor B, what's really going to happen with these guys long-term?" Like for real, how are they financially structured, which one's taking private equity, which one's still family owned?
How long have they been family owned? For 30 years? Well, they're not really looking at growing and expanding, necessarily. Whereas these other guys are taking in a lot of money, there's going to be a liquidity event. Are they going to sell to somebody else? Well, you dig in deeper and deeper, and it turns out these folks are on an acquisition spree.
They're probably going to buy the one that's owned by the family. Because when you give the family a big check, they know they want to run the business and all that, but you put $25 million, $30 million, $40 million or whatever in front of them, they're like, "okay!"
So that was really good because we ended up going with the vendor in that scenario who was more financially backed and had a growth strategy.
Whereas the other one was more kind of harvesting and just doing what they were doing. So again, you know, friends don't recommend bad dating partners.
Quentin:
It goes back to the relationship. It's like, you are making a relationship and do you want a long-term partner? Most likely if you're selecting software, you want a long-term partner.
Juliette:
That's exactly right. And one you like.
Shawn:
Because you're stuck with them. And you might as well have fun with it and enjoy it.
Juliette:
Shawn, you and your dating analogies.
Shawn:
Yeah, exactly.
Juliette:
So with that said, I know we've covered a lot today. Is there one thing, Shawn, that you would want our listeners to remember most today about vetting ERP solutions?
Shawn:
You know, I've been looking at that. There's actually two different viewpoints that I'll take. The one is you're on your own to do it. So if you're on your own to do this, the one thing you have to keep in mind is, you'll know who the right one is to do business with. If you're not sure, keep doing the selection, keep doing your diligence, find out what's different.
Never, ever, ever will you ever have two vendors that do the exact same thing. It's sort of like, again, two people. Super, super important. I mean, we have had, Intacct vs. NetSuite. We've had Microsoft vs. Infor. We've had all these names of all these vendors in the market that we have taken down to the finalist.
And you'd be just astonished when you really dig in into the differences between all these vendors, like Quentin said, the companies, their software solutions, and the implementation partners, as well as costs, as well as fit with your organization, and knowing your industry. Every single vendor is different. So if you're like, "Oh, I could go with the other one," you have to keep digging and find out what the differences are.
Juliette:
And then it'll become obvious.
Shawn:
It's just obvious. Like, it is literally like, the whole team is like, "well, yeah, we have to go with those guys." Cool. Let's go. Like you do it. Then you start the hard part, which is the implementation. That's where the risk is.
But the other view I would say is, people really need to understand that there is real help in the market for here. I mean, there's us, you know, we like people that are fun and don't mind the relationship metaphor. Some people are like, "I'm too serious for that." Fine, we're probably not the best firm for you honestly.
But, you know, we have tons and tons and tons of stuff on our website. Thanks to Shaun and to you for pulling a lot of things together, Shaun Orthman, our Digital Marketing Manager, he's over there on his headphones, cranking things out. He's amazing.
But also you know, some of the other folks that do what we do, we won't mention their names. But they got lots of great stuff on their websites and you can find a lot of assistance and help out there.
Like we've kind of evolved past this, "Oh, ERP is this magical, scary thing that I have to do that I'm going to get wrong." Right. It's not like that anymore. You know, it's like getting a tooth -- a filling or a crown or whatever. It's pretty everyday stuff. Companies and organizations are selecting the right software for them right now.
That is happening. I mean, all of our customers do it. As I look back, who's going to yell at me after this? There's one, and it was like, oh, that'd be it. But we've done tons and tons and tons of projects where clients are totally certain.
So it can happen. It's not like there's some big barrier in ERP that makes the selection a failure, or the implementation too. You can do this stuff successfully. Find the information that's there to do it right.
Juliette:
Well, this is a great start, because I know there's a lot more to it. As Quentin mentioned, Shawn mentioned. So we will revisit this at a later date, I am sure. But thank you guys for your time today. Thank you for joining us.
Outro:
ERP advisors group is one of the country's top independent enterprise software consulting firms, advising mid to large size businesses on selecting and implementing business applications, including ERP, CRM, HCM, business intelligence, and other enterprise applications, which equate to millions of dollars in software deals each year across many industries.
This has been The ERP Advisor.