NEWS & EVENTS: Columns

Evaluating Your Options

Well it’s a new year and like everyone else, I’ve finally raised my head up from my inundated In Box to take stock of what 2008 may bring when it comes to channel management. You know, I’ve spent a lot of time writing about my version of channel marketing’s golden rules, what trends I’m following, how to make sure that you’re channel ready, and Marilyn has weighed in about what we should all be thinking about when it comes to the channel data hub but I think that it’s time we took a step back.

We’ve been talking about what you should be doing and even given you some of our thoughts on “how” the perfect channel management system should work, but I’m not a techie guy and when I talk to most people in the channel, they’re not really techie people either. Now Marilyn, on the other hand, has been the keeper, maintainer, and chief bottle washer of some very strategic (worth hundreds of millions of dollars in revenue) channel data hubs. Translation: Marilyn is far more technical than me, but she probably thinks of herself as a non-techie too.

So here’s what I’ve been thinking about and been asked about by a number of very large channel management organizations: how do you evaluate channel management systems and is it even possible to compare them?

Not an easy question to answer. And by that I mean these kinds of systems are very hard to evaluate because you’re actually asking a number of questions:

• What do I need to do my job successfully? (These are the features and functionality you need to get the job done.)
• What does the vendor have that I need? (These are their features and functionality stuff that might get your job done.)
• How do I compare that with other vendors' stuff? (This is everyone's features and functionality, including yours, and how they match up against each other.)
• What do I need to deploy the solution? (This is where your IT guys talk about cpu speeds, memory, database size, redundancy, security, and all the software and hardware you need to buy and if you're like me, you get very, very lost and you just want them to "bottom line" it for you.)
• How much is this all going to cost me? (This is where one solution comes in at 10x versus another and you're left wondering how you can justify any of the costs to the person who needs to sign off on the purchase req.)

Lots of “stuff” to think about! And some of it can be excruciatingly technical but here’s the thing: when it comes to channel management solutions those of us who are evaluating systems need to be able to understand what to look for (in a business user-friendly kind of language) and how to evaluate it. So, over the next several columns Marilyn and I are going to look at each of the questions that need to be asked when evaluating solutions and hopefully, provide you with an evaluation framework. That way, when you evaluate any solution you’ve got tools you can use to compare systems that may be very different (you know, apples versus oranges) while being able to understand the strengths and weaknesses of each one.

So stay tuned. The next few columns are going to cover a lot of ground and may require a bit of “heavy lifting” and it should—after all, when you evaluate and select any enterprise software solution you are placing a pretty hefty bet (in terms of cost and operational execution) that this choice will make you and your business successful. My next column is going to cover the best way to determine the features and functionality you need to get your job done. So sharpen your pencils, get your spreadsheets ready, and take a look at the folks in your company that may become a member of your evaluation team.

So remember last column when I said that you need to be prepared for some heavy lifting? Well, I hope you’ve been working out because it’s time to get moving. Evaluating software can be viewed as an onerous task, but it’s time to change that mindset. Instead, think of it as an excellent way to really learn how your business operates. Yes, it’s challenging and there are always a million other things to do, but by taking the right steps you can actually simplify the selection process. Here’s the thing that you need to keep top of mind: you will be living with the decision you make (in other words, the enterprise solution you buy) for many years, you will also have to justify the cost of the decision in terms of money and those great intangibles that involve operational changes, business process improvements, and the right personnel to both manage and successfully deploy the solution, and you will have to show the ROI so that upper management will be happy with your selection. And there will be costs associated with everything (when it comes to software, there is no such thing as a free lunch)—some will be hidden (we will spend a lot of time on this in another column) as well as other costs that are carefully delineated on the vendor’s quote.

This is what I’ve learned after going through this process several times and helping other companies to navigate what can be very turbulent waters as they try to make the “right” decision: you need to understand where you are before you can figure out where you want to be. More times than I can count, I have sat in meetings where much to my surprise, I had no idea that things worked the way they did. And this is usually discovered after you purchase say, your new inventory control system, or worse, after you’ve implemented it. In other words, you bought something before you knew all the facts. And that thing that you bought may or may not address your real pain points and problems.

So before you talk to vendors about your problems and the functionality you are looking for to fix them, be sure that you understand them yourself. By the way, this is not something you should be doing by yourself. You need a team for this (I am writing this column after watching the Giants upset the Patriots in the Super Bowl and the reason they were able to do this is because they operated as a team). Consider the following functions as possible choices: Sales, Marketing, Fulfillment and Operations, Information Technology (IT), Sales Operations, Analysis and Market Research, and Finance. Now, don’t have a heart attack as I can already hear you saying this is just too many people. Keep in mind that these folks will ebb and flow into this as you explore how things are handled when it comes to managing the flow of product through your retail sales channels and by handle I mean the following:

• How is product moved through your retail sales channel?
• Is the process different for each retail partner? If so, what are those differences? For example, some of your retailers may require direct store delivery, others may require distribution center delivery, and even others may want a mix of both.
• What kinds of data do you receive from your retailers (POS, inventory, EDI, RFID)?
• What do you do with this data? Do you clean and normalize it? Do you put it in some sort of database or data warehouse? Do you need to support multiple fiscal or reporting calendars for your retailers?
• How do you access the data? And what software do you use to run reports and perform analysis on it?
• What are the reports and analytics (maybe KPIs like year-over year growth, OOS, or GMROI) you use to make product inventory decisions? How often do you run them (daily/weekly/monthly)?

Now keep in mind that these questions are probably just the tip of the iceberg—I just want to get you to start thinking about your processes and the relationship and requirements you have with each of your retailers. Here’s what I suggest: document your processes and maybe even draw some pictures (some folks like to call these process diagrams but the point here is that you need to understand how things work today) and understand where the different functions (you know, channel sales, shipping, receiving, IT, etc.) figure in as well as what kinds of paper or systems (like ERP, financial accounting, etc.) are involved.

Once you understand where you are today I want you to ask yourself (and all those folks who helped you to understand your operations) the following question: if I could have anything I want, what do I need to make these processes more efficient and effective? I suggest you consider this question across three areas:

• Data Capture and Management. Consider how you would like to get, clean, and normalize the data you receive from your retailers. Think about storage and access issues and by this I mean can you get at the data easily, does it take forever to run a query, is the data you’re looking at in a format that you can use?
• Reporting and Analysis. Consider what reports and analytics would help you to prevent stockout situations at retail outlets, predict how much inventory is needed for in-store promotions, or assist you in determining how to move your inventory around at the retailer-, region-, or store-level to take advantage of sales trends (these are just suggestions and you may have more/less/different reports and analytics that you need) and then list them out. Also think about exception management and the conditions that you want to be notified about such as stock-outs, excess inventory, or significant deviations from forecast. How would you like to be notified when these conditions occur?
• Business Process Standardization. Look at where you could change business processes to improve performance or where automating the process or process changes could make them more efficient and effective. But also identify where the process is dependent on the retailer and your relationship which means that you must have some flexibility.

I like to create a spreadsheet with different pages for these areas. Each page lists out my requirements and a description. Then as you talk to your vendors, you will probably create a new column that lists the functionality, followed by your requirements, and a description. You might wonder why I don’t just include the “functionality” at the beginning of this exercise and here’s why: I find that we often tend to think in “buckets,” for example, “I need analytics,” instead of I need these specific analytics to run my business. And guess what? Just because a vendor tells you that they have “analytics” it does not mean that you will have the specific analytics you need to get your job done. So be as detailed as possible—and who knows? After you talk to some vendors, you may be adding stuff to your list!

So you’ve got your processes down and created your spreadsheet, what’s next? It’s time to talk with your vendors and get them to do some work too. And as you go through the evaluation process, you will find yourself going back to your spreadsheet and reviewing how you do your work today again and again as you consider all your vendor and solution options. But you’ll be happy to note that your heavy lifting is pretty much done (well, at least for now)—in my next column I talk about what your vendor should be doing and providing.

If you’re like me, you don’t fix what’s broken until it has caused you a great deal of heartache. Translation: Out-of-stocks are killing you, your competition is gaining ground, or your retail partner is screaming at you because you have not stocked enough product for a promotion. Lesson to be learned: don’t be like me. Over the years, I have learned that it is much better (and far less stressful) to operate proactively instead of reactively. And if you are evaluating your options, you probably have already learned to be proactive!

So, you have decided that it is time to change the way you do business and you have done most of your heavy lifting: you know how your processes work today, what systems and groups are involved, how you access your data, and what reports and analytics you use to run your business. You’ve also created your wish list of requirements—what things, whether it’s capturing and managing your data, reporting and analysis, or changed or automated business processes—that you are looking for in a solution. And most importantly, all of your requirements are listed out in a spreadsheet or document that you can pass along to vendors who are competing for your business.

Now, it’s time to create a vendor list. Here’s the thing that you should keep in mind: the more you know about your business and what you need to make it operate better, the easier it will be for you to select the “right” solution and the “right” vendor. I know that this process seems to take up a lot of your time but the more time you spend now, the less time you spend regretting your choice later. Think of this part as the stuff you do when you decide to buy a car—you notice the cars you like driving around, you do some research on them (using Consumer Reports, car buying sites, etc.), you check them out further at the automaker’s website, go to some dealers, look at the cars, take some for a test drive, talk to your friends about the car you’re thinking of buying, decide exactly what options you want, make price comparisons, and finally, buy the car. Okay, so acquiring a new system to run your business isn’t nearly as much fun as getting a new car but it still deserves that same amount of due diligence (well, actually more)!

First up, you need a list of vendors that may have a solution that “might” be right for you. You may already have a few vendors in mind because they’ve reached out to you through a call, email, or brochure. If you haven’t already, take a look at research about your problem and possible solution(s) from research firms (like AMR, IDC, Gartner, or Forrester). Also, check out the magazines (and websites) that cover your industry—there usually are some interesting customer stories around that may showcase solutions that pertain to your needs. Once you have a preliminary list, go to each vendor’s web site to see if they look “promising.”

You’re probably thinking that “promising” is an interesting term to use because it sounds sort of wishy-washy. And that is exactly my intent. Just because a web site looks good and sounds good, it does not mean that the solution is good. Translation: great marketing, sub-par product. Don’t let yourself get caught up in a vendor’s hype. Your job is to sift through the hype to determine whether the solution is the gem you’re looking for. So, anyone that meets most/all/more of the requirements you have should go on your list.

Now it’s time to invite these vendors to your evaluation party. Call them up—believe me, they will be happy to talk with you and even happier when they find out how much upfront work you’ve already done because you know what you’re looking for. Ask each of them to give you a short (no more than an hour) pitch on their solution, how it meets your requirements (you should give or email them a summary of what your problem is and what you’re looking for to fix it), and perhaps a short demo to get a quick look at the product. This can be done either online using WebEx or some other online presentation tool or in person. You can do this meeting alone or bring along a few people that are important to moving the evaluation process along (I think the formal term is “stakeholders”).

Okay, after researching websites, talking with analysts, reading trade journals, etc, you’ll probably have a list of five or six vendors who may fit the bill. Now it’s time to talk to these vendors—maybe spend an hour or so hearing their pitch and discussing your problem and requirements in depth. Your goal from these conversations is to narrow your possible vendor list down to the three who will go thru an evaluation process with you. How do you do this? Well, most likely there’s one vendor who demos their product and you go, “this is it, this is what we need, it can grow with us, etc.” There’s another vendor who you think has an interesting solution, something perhaps that you never thought of before. And then there’s that third vendor who is the best known, who has more name recognition, etc. However you cut it, these three are the ones you want to take a further look at.

Once you’ve narrowed down your vendors, share your requirements specification with them. A quick word about the requirements specification. Remember in my last column when I talked about creating a spreadsheet that lists your requirements across three main areas (data capture and management, reporting and analysis, and business process standardization)? This is really your requirements specification for a new system and at this point in the process, you should be asking each one of your remaining vendors to indicate whether they have a given requirement, the functionality it pertains to, how it works, etc.

Also, keep in mind that one or two of these vendors may be taken off your list after further discussions because they don’t meet your criteria. If that happens, go to your fourth and give them an opportunity to work with you to see if there’s a fit. Now, let’s pause for a moment and consider the fact that you have been calling all the shots so far—and that’s okay—but as the vendors go through this process with you, they are going to ask you some questions to make sure that there’s a potential fit on their side. Most of these questions will center around the following:

• Is there a budget and if so, how much is budgeted? This is the beginning of a “long dance” as price can always be negotiated but the vendor wants to get an idea of how much you are willing to spend. They’ll let you know if there’s a disconnect—in other words, if they cost way more than you’re willing to spend. But at this point in the evaluation process, they just want to get an idea of what you’re thinking. And later in the process (another column) I’ll show you how to take apart a price and look at all the components to determine what a solution really costs.
• Who are the players in the buying decision? Your vendor will want to know who the business users are, the influencers (usually IT), the decision-makers, and who signs the purchase order. Some folks have a hard time sharing this information with their vendors, but I am not in that camp and here’s why: you are going to embark on a long-term relationship with one of these guys so give them the information upfront. Eventually, you will want your vendors to talk to all your players and understand what part they play in the evaluation process. And if one of your players is known to be “difficult,” you may need your vendor to help influence that person in the “right” direction.
• What is your buying process? Let the vendor know your evaluation process and what you are looking for in order to make a buying decision. Tell them that you will provide them with your requirements and ask them to respond to whether they have the functionality to do what you’re looking for. You will also want each vendor to walk you through your requirements and how they can help you in a follow-on meeting that includes a demo of the product—make sure that you can see how the solution solves your problem before signing off that it does. You may also want to be able to use the software on your own (I call this “trying before buying”) or if you like two or three of the solutions, you may want a bake-off. This is where you give each vendor the same “test” and see how they perform based on your criteria. It’s okay if your buying process changes a bit after you get your basic answers because you now have more information, which may have impacted your requirements and buying decision.

So now what? You’ve answered their questions, shared your requirements, what’s next? Well, you wait to get their responses to your requirements specification. I like to give vendors seven to ten working days to respond. If they’re faster than that (and I can tell that they’ve done a good job), they get a bonus point for being responsive. If they’re later than ten days and did not tell me why upfront, I ask myself whether I want to continue with them. You get the picture.

Once you’ve gotten all their responses, copy and paste all of them in one single spreadsheet so that you can easily compare and contrast them. Some vendors may want to walk you through their response in person or on the phone which can help you if you don’t quite understand what they’re saying. Then it’s time to decide which ones you want to move forward with. More on that in my next column!

Okay, now we’re swimming in some rough waters as it’s getting close to vendor selection time. Why rough you ask? Well, if you’re like me, you’re going to wonder if you made the right decision, especially when you sign off on the deal and tell purchasing to cut a check. And you should be a little worried—this is a big commitment and if it goes south you’ve just wasted valuable resources. But you’ve been doing your homework and that should go a long way towards easing some of your concerns.

So, let’s review for a moment. You created a preliminary list of vendors and after meeting with them and sharing your requirements, you created a short list of evaluation vendors—those three to five vendors that appear to be a “fit.” By this I mean that they have the functionality that looks like it can meet your requirements. You have shared your requirements specification with them and they have responded to it and you have pasted all the responses into one spreadsheet. Why one spreadsheet you ask? Because it’s a great way to review all vendors’ features and functionality at the same time and it keeps you on point with regards to what you’re looking for. More often than not, I have found that vendors can change the conversation on you without you realizing what happened—but if you keep looking at your requirements and then each vendor’s response, you can decide what’s important to you and what’s not.

I need to digress a moment on vendor responses. Remember what I told you in an earlier column? Don’t let the “marketing language” fool you. And don’t let a nicely written and presented response fool you either. Just because something “sounds good” does not mean that it is in fact going to solve your problem. You need to “read between the lines” and ensure that what the vendor is saying that they have is what you need and that it works in way that makes sense to you. If you don’t understand something in their response, call or email them and give them an opportunity to address it with you. Trust me, they will be happy you called and the information that they give you could make the difference when it comes to vendor selection.

Now, in the best of all worlds, there’s one—maybe two—vendors who meet all your requirements. And if so, you’re very lucky because you have a clear winner. More likely, however, there’s one or two vendors that meet most of your requirements and have workarounds or solutions for the rest. If this is the case, it’s time to consider what criteria you’re going to use to “pick” the winner.

If it’s close and there is no overarching “favorite,” you may want to consider a “bake off.” But before you do that, sit down with the rest of your team and rank vendor responses across your three areas (data capture and management, reporting and analysis, and business process standardization). I like to use the following ranks:

• 2—Exceeds requirement. The vendor response has more functionality than you need today. Why give it a 2? Because the added functionality might be nice to have at a future date.
• 1—Meets requirement. The vendor’s functionality meets your requirements for what you need today.
• 0—Does not meet requirement but has workaround. The vendor has a workaround within their solution to meet your requirement.
• -1—Does not meet requirement. The vendor cannot meet your requirement with their solution.

Now, I suggest that for each vendor you tally up the 2’s, 1’s, 0’s, and -1’s they have. Sounds kind of childish? Maybe so, but this simple ranking process can help you to quickly identify those vendors that have more well-rounded solutions (lots of 2’s and 1’s) versus those that don’t. It also helps to keep you and the team focused on requirements versus the salespeople who are trying very hard to build relationships with you. We all tend to be biased in favor of those folks that we “like” and that may play a part in your final decision, but you first want an unbiased snapshot on how each of the vendor’s solution meets your requirements.

Here’s where it can get interesting. There may be only one vendor who has all/most of what you’re looking for and no one else gets even close. But you have some issues with this vendor—maybe it’s size of company, number of customers, bad press, etc. Before you move further, have a frank discussion with them. Tell them your concerns and ask them how you can work together to alleviate those concerns. Remember that as you move through this process you are getting more and more data points on how responsive the vendor is, how flexible they are, whether they are willing to share some of your risk, etc. This kind of interaction is incredibly valuable as it gives you a clear picture of how that vendor will be to work with as you go through an implementation and deployment process. And needless to say, if during this process your concerns actually grow, well, they’re not the vendor for you.

Now you could also have one or two vendors that are very close in terms of requirements, responsiveness, etc., so you may want to have what we call a bake off—both vendors use their solution to address a specific problem you have. This is kind of like a case study where you give the vendor a business issue and ask them to solve it. You and the vendor will probably also have to come up with some guidelines as well—for example, access, platform, performance, scalability, and security are all areas where you might want to define what is “acceptable.” This might sound like a lot of work, but you really can’t have a bake off unless you can not only define the problems, but give some parameters, and define what “success” will mean as well.

Usually, whoever wins the bake off is the vendor of choice unless they both do or are so close that it’s a draw. In that case, you may want to consider some intangibles: for example, how responsive was the vendor’s team, how easy were they to work with, do they have expertise in your industry, and were they willing to share that expertise with you? Positives answers to questions like these often make the difference but if it’s still a draw, it just might come down to price.

Now, our next column is going to breakdown pricing for you because I have found that solutions can sometimes cost anywhere from 25% to 100% of what was in the original quote and this is often due to some things which are very difficult to scope and other things that you should be investigating fully as you negotiate the price. All prices are not the same and quite often, the vendor who looks better on “paper” is far more expensive than the one who was not as budget friendly. More on that in our next column!

Well, for the last four columns we talked about how you should “think” about evaluating enterprise software solutions. And we’ve gone through a lot of hurdles together and you’re probably feeling pretty good about “life in enterprise software land.” I mean, after all you’ve done your bake off, compared your top three vendors, and finally, settled on a solution. But you’ve still got one more hurdle to go and it can often cause you to go back and revisit why you chose what you chose.

It’s time now to talk about price. And by price I mean the true cost of implementing and supporting a solution. Translation: you’ve probably chatted about the price a bit and gotten a ballpark figure as you went through your evaluation process because one of the things that you were considering is what you had budgeted and whether the vendors you looked at where falling in the same “cost arena.” But here’s the important thing that you’ve got to remember. That figure you were quoted is just a ballpark estimate of what implementing the solution costs in terms of hardware, software, people resources, training, etc. It’s now time to get down to the “brass tacks” of a proposal and make sure that you understand the total cost of what you’re undertaking.

Here’s how I go about figuring out the “real” cost of a solution. First, we need to break out the costs along the following categories:

• Software Costs—All the software costs associated with the solution. By this I mean all the licensing and subscription costs for the vendor’s software solution plus any other items. Vendor is the key thing to remember here as there may be other software costs from other vendors that your vendor uses as part of its total solution that may not be embedded in the cost of their software solution. As you go through the cost proposal, you will want to clarify what costs the vendor is responsible for and what costs you are responsible for.
• Hardware Costs—Okay, this area can get very tricky as you will want to understand what underlying hardware is required to support the application. And keep in mind that hardware spans a number of areas (servers, storage, PCs/Clients, networking equipment, etc.) as well as meets specific business requirements (mission-critical performance, high availability, redundancy, etc.).
• People—What kinds of folks are needed to support the application, underlying infrastructure, etc.? Sometimes you may not have the skillset in house and may have to hire or contract (in other words, hire a consultant or services firm) out for it. In either case, there are ongoing costs associated with this.
• Other—Yes, this is the “all other items” cost bucket which should include consulting, training, support, and any other costs you just have no other place for.

This is beginning to sound like a very long list isn’t it? Not to worry as over the next few columns we are going to “dive deep” into each area to give you a better grasp of what you should be thinking about and looking at. Once we’re done, you may, like me, begin to understand why software-as-a-service (SaaS) is so popular these days. Under this model you simply pay a yearly fee and “rent” the software and hardware to run your application. That way, you don’t need to worry about most of the costs outlined above as all these components are bundled together and supported by the vendor as a part of their “service.” But, even if you are looking at a SaaS solution, I think that it’s always good to be able to break out costs so that you can understand the “true cost” and “true value” of the software solution that you are considering.

Buying an enterprise “software” solution is not the same as buying Microsoft Office. With Office, you get a suite of products, a simple installation program, and as long as you have enough memory and storage on your laptop or desktop, you’re good to go. Now, one could argue that an enterprise software solution should be as easy (see my last column and comments on SaaS) to install and use, but really—have you ever had that experience? I certainly haven’t!

In fact, more often than not, getting successfully up and running can be arduous, tedious, and just mired in bottlenecks—you figure out the “fix” to one problem and suddenly you have two more problems in its place. This is often due to the fact that that you don’t have all the software and hardware you need, or that it’s not up to spec, or you have the wrong version, or IT didn’t install it properly, or someone in your company decided that you really didn’t need that much bandwidth or you could use an earlier version of the software instead. You get my drift. Getting up and running can often be a minefield.

That’s why it’s so important that you understand what software you need to run your solution from the very beginning. That way it’s in your budget, you know it’s purchased, and you know it’s installed. And by costing it out ahead of time, you won’t have those additional costs creep in an as you go through your implementation process—you know, “cost creep” as opposed to “feature creep.”

Okay, here’s how I try to evaluate the software costs for my solution. First, there’s the solution itself. That’s what the vendor is selling to you and sometimes that cost actually reflects all the software costs that make up the “platform” as well because the vendor has bundling deals with the other vendors and bundles everything together (and the price of course reflects that). But that’s pretty rare because enterprise software solutions usually requires mission-critical platforms that are made up of servers and routers and all that hardware and then on top of that resides the operating system, database software, business intelligence toolset software and each of these “items” have versions and minimum system requirements, optimal system requirements, etc. The list goes on. And all of this costs money.

Now, this may sound counter-intuitive since we’re talking about software costs, but I recommend that you look at costs from the bottom up. By that I mean that you need to understand the underlying infrastructure (how many servers, what is the capacity, how much storage do you need, etc.) first and then overlay your business requirements. For example:

Once your vendor understands your business requirements, he/she can then tell you what the “infrastructure platform” should look like in order to meet or exceed your performance requirements. And that’s when you can start working through the software costs. For each “piece of hardware”, ask the following questions:

• What are the software requirements and costs?
• Are there license-based costs associated with it?
• Are there maintenance costs associated with it?
• Are there specialized services costs associated with it?

So, here’s the thing: evaluating the true cost of your solution should require as much time and thoroughness as your vendor selection process. And if you spend some time doing this, you will not only know the true cost of your solution but will have an excellent understanding of what your infrastructure will look like in order to support your solution. That’s a win-win in my mind; you know the cost and you will end up with the infrastructure environment that fully supports your business/performance requirements which leads to a successful and relatively stress-free implementation and deployment.

I know that this is a lot to digest and I’ve got a couple more columns of material on this. But once I’m done, I hope you will have a better understanding not only of costs, but what’s involved in order to successfully deploy your solution. And in my last column on this topic, I will also provide you with a handy-dandy table that breaks out all the categories and costs you should be thinking about when evaluating the Total Cost of Ownership. And if you’d like to have this table sooner rather than later, just send me an email and I’ll email you a copy!

In my next column, we’re going to talk some more about hardware costs.