There’s something about software that turns the sanity switch to “Off” in the minds of many otherwise sensible individuals. People who would never presume to ask, as a general inquiry, “What’s the best car on the road?” don’t hesitate to ask “What’s the best order management system?” Both questions are equally silly. But knowing exactly what makes them both so absurd is revealing and instructive.
The problem lies in the nature of “reviews,” and consists of two different issues. The first is the role of “opinions.” When it comes to entertainment (books, movies, plays, even restaurants), reviewers not only indulge their opinions wantonly: We expect them to! But then there’s the second issue: What’s at risk? At most, you’ll waste a few hundred dollars in a fancy restaurant that fails to meet expectations (for whatever reason) or at a hot new Broadway play that disappoints (again, for whatever reason). Different strokes for different folks.
The nature of “reviews” changes somewhat for things at a slightly more complex level. Take cities (for vacation travel) or cameras, for example. Name any major city in the world, and you can find people who love it and people who hate it. Do you want your guidebook reviewer to offer a general opinion, or do you want specific recommendations for hotels, restaurants, and sites? Even those can suffer from the same vagaries of taste as any other critiques. And if you are evaluating a new city to move to, you’ll be far more concerned about taxes, schools, roads, infrastructure, and property values (for instance) than about recreation and leisure. And of course, the risks in visiting a city you don’t like are much less than in moving there. Yet even so, singles may tend to like some cities better than married couples with young children, or older couples with grown children. Again, different strokes, folks!
Cameras present still another level of complexity. Even if you specify exactly what your expectations are, the “best” camera will be the one that has the best combination of features, ease of use, cost, reliability, and look and feel for you, not for some “objective” reviewer. The risks? Hundreds of dollars for something you may feel stuck with — and maybe some missed photo opportunities because you never really master the damn thing … but you’ll move on.
Which takes us back to cars. These share the same mix of issues as cameras, but the downside risks are higher and the cost much greater, of course. Yet even here, the worst-case scenario (assuming the vehicle itself is mechanically sound) is just greater aggravation. You’ll either grin and bear it for the term of the lease, or, if purchased, sell the car, even if you take a bit of a loss, and start over again.
LACK OF STANDARDS
So what about order management software? The complexity of issues and the nature of the risks are so much greater here that it defies anything like a simple “review.” And let’s get it right out on the table: The biggest issue of all is a lack of standards in the way these systems work.
There are three aspects to standards: uniformity in functions, uniformity in methods, and uniformity in formats. In applications like word processing or spreadsheets, we all expect certain baseline functions. The methods to do those functions can differ from package to package, however, and the technical formats used by the software may be totally incompatible.
When a company like Microsoft Corporation reaches a “tipping point” in market share, which it did in the mid-90s, its format will become the de facto standard. If you want to share files with others, you have to use the Microsoft formatting standard. So the Microsoft methods and functions then tend to become a de facto standard, as well.
Does that make them better? No, not by a long shot (just ask any Lotus loyalist)! But they do become a baseline.
There is nothing whatsoever like a standard in direct-commerce order management systems. Name almost any aspect of order management, and you will find that virtually every system does it a different way. Sometimes the differences are slight, sometimes dramatic. And that applies to the functions the systems have in common. When it comes to a “baseline” feature/function set, forget about it! No such baseline exists.
One would like to think that mature order management systems embody industry “best practices.” But they don’t. Leaving aside whether best practices are even a viable consideration in a business as diverse as direct commerce, the way even the largest systems handle things like inventory allocation, future orders, kits, returns, and customer profiling is frequently contradictory. Again, there are just no standards here.
MISSION-CRITICAL
What makes this all the more frightening is that the risks of making the wrong decision in an order management package are much more significant than in buying the wrong car or even moving to the wrong city. These systems are truly mission-critical, and if they don’t support your business effectively, they can severely hinder your company’s growth, at minimum, and put you out of business, at worst.
So what’s the answer? It’s very simple, really. In fact, I call it the EASIER way. We’ll look at each letter of that acronym in a minute. But first, let’s put the system selection task in perspective.
The biggest mistake companies make in their system search is to focus immediately and almost exclusively on the systems themselves, to the exclusion of their own needs and requirements. Trouble is, most systems demo very well, and most demos have an internal logic about them designed to show off a system’s best features. No wonder you can get confused by this “beauty contest.”
Looking at systems is the “aim” part of “Ready, aim, fire.” If you only do “Aim, fire,” you’ve never taken the time to get ready. Specifically, one of the major things that sets sports professionals apart from the amateurs is the care and focused effort they take to get “ready” for each action (a pitch, a golf swing, a tennis stroke).
In your systems search, you need to do exactly the same. You need to focus on your company first, and truly understand what it is you are trying to accomplish.
BPR OR NOT?
The most elusive issue for most companies looking for a new system is whether to do any business process reengineering as part of the project. If you are replacing a system that is inefficient, then of course you will be doing business process reengineering. Does it make sense to invest time and effort in specifying an elaborate BPR plan in advance of a systems search?
Generally not. You are likely to create a theoretically efficient set of business rules that no order management system can actually support.
The only time you should consider this is if you are going to develop a fully customized solution. Another exception would be if you are planning to make a major transition to, say, an automated warehouse. In that case, you will be installing a warehouse management system, and redesigning your infrastructure at the same time is the only way to do that.
To show you a more productive way to approach the business process challenge, let’s dissect the acronym EASIER:
E STABLISH A PROJECT TEAM
A SSESS OBJECTIVES
S PECIFY OPERATIONAL PARAMETERS
I NVESTIGATE OPTIONS
E VALUATE SOLUTIONS
R EVIEW ALTERNATIVES
ESTABLISH A PROJECT TEAM
No doubt about it, this is going to be a major project for your company, and it will require many hours of participation by key personnel over several months (or even years). Not treating it as such is a fatal mistake.
To manage the project you will need a team that consists of representatives from order entry and customer service (call center manager), inventory management, warehouse management and fulfillment (operations manager), merchandising, purchasing, circulation, and accounting. You will need a representative from IT, of course, and you need buy-in from top management, typically the president or CEO (who may serve as the project “sponsor” but may not actually be on the project team). The team should also include the CFO and COO.
Team members should be prepared to make a commitment to the project and to accept responsibility for its success. You will need their input and support from the start, and all the way through to system implementation, when “managing change” becomes the top priority.
ASSESS OBJECTIVES
With your team in place, you can determine objectives. These can be as broad or as specific as you please. They might be, for example, to increase your order throughput capacity to X thousands of orders per day, or to reduce average order entry time by 30%, or to facilitate “one-touch” customer service,” or better e-commerce integration, or more robust kit management or personalization, or management of serialized inventory and lot control, or Web-enabled reporting. A very common objective is “a system that is easy enough to learn that we can train temps within four hours in peak season.”
Brainstorm your objectives first (via meetings and memos), then work up the list into a prioritized group of five to ten key things you expect the new system to enable. Make sure every department can see value and benefit from this list.
You should also, of course, determine a realistic systems budget, allowing not only for software licenses but for the possibility of new hardware and networking infrastructure, as well. As a very general rule of thumb, you can easily end up spending 1% of annual sales on a new system (and 2% would not be out of line).
Whatever your initial list may be, one objective you can’t ignore is your target for a conversion date to the new system. Realistically, you can expect to spend from one to three months on preparation, another two to four months on system selection, and two to three months, at a minimum, on system implementation, conversion, and training. Tallied up, that’s five months minimum, and at least ten months maximum, although it is not unusual for a systems project to take up to two years.
You also have to coordinate backward from optimum months for any system implementation. If you have a peak season, your “go-live” date should be at least two months prior to the start of that season (ideally, of course).
A rule of thumb: The biggest challenge you are likely to face is managing the time frame on this project. Of all the variables you will have to deal with, time will be the most elusive. There won’t be enough of it (no matter how organized you and your team are), and almost certainly you will wish there were more time at the end, when non-negotiable implementation deadlines are looming. Trust me on this one.
SPECIFY OPERATIONAL PARAMETERS
This is the “tricky” part. You don’t want to document everything you currently do in detail, because (a) you are getting a new system that will do things differently, and (b) see “BPR or not?” above. The longer the list of “required” or even “desirable” functions, the more difficult it will be to find a package that will meet those requirement. On the other hand, a superficial list of bullet points doesn’t help much either. “Better kitting” doesn’t let a system vendor know your real needs.
The end result of this process will be a needs analysis that forms the core of a request for proposal (RFP) that you will send to systems vendors. The RFP needs to encapsulate the truly essential business rules for your company, and it needs to communicate these to vendors in a format to which they can respond constructively.
Thus, you should focus on the most important aspects of your business and describe these in step-by-step fashion. In their proposals, vendors can respond to these steps and confirm whether they (a) can support them with no system changes, (b) can make minor changes to support them or support them in slightly different ways, (c) will need to make major modifications to support them, or (d) cannot support or do not wish to support them. The vendors should be able to estimate the time and cost required to make any modifications.
Your RFP should also provide the vendor with details about your current operation (number of SKUs, number of customers, number of catalogs/Web sites, order volumes, systems in place, projected number of users, etc.), and should request information about the vendor and the vendor’s previous system implementations.
INVESTIGATE OPTIONS
Elsewhere in this issue of O+F is a listing of vendors offering order management solutions. If you wish, you can contact each of these with an initial request for information (RFI) to obtain technical data about each vendor’s system (programming languages, database, operating system, hardware platforms supported, typical pricing for specified numbers of users, and so on) as well as information about the company and its users, and what types of businesses these users represent. This can help you to limit the number of vendors who receive the RFP; more than seven or eight is probably overkill.
Allow vendors two weeks to respond to an RFI, and four weeks to respond to your RFP.
Notice that even now, during this phase of the project, the focus is on you, not the vendor. By using a formal RFP, you can find out what the vendor can do for you, how well, and with what cost in time and money.
EVALUATE SOLUTIONS
Chances are you will be able to eliminate half of your vendor candidates based on their proposals. Some will be way off the mark in pricing, others will require too much modification.
For the ones who make the first cut, you will want to schedule demos at your site. If possible, send all of them the same sample/test data to load on their systems in advance, so you can compare apples to apples. Have some test orders to enter, as well. In fact, the more “test scenarios” you can prepare for vendors to demonstrate, the better. Remember, it’s still all about you.
Allow at least a day for each demo. Be sure to make the vendors demonstrate some of the key things they have said in their proposals that they can do. Too many “Oh, that’s not what we thought you meant” comments, and their time is up.
The demo process should narrow your candidates to one or two finalists. Before settling on one, you should do “due diligence” on the vendor companies (obtain D&B reports, etc.), have each team member talk to a counterpart at user companies that the vendor makes available to you, visit the vendor’s offices, and even have one of your team members go through “mock training” (which you will probably pay for) on one or two systems before making a final decision.
REVIEW ALTERNATIVES
There is no perfect order management system and no perfect vendor. Each one has its trade-offs. You need to review these formally as a team to be certain you are choosing the least of the evils.
Finally, step back and review the big picture: Are you “covering the bases” well with the final candidate (call center, e-commerce, warehouse, fulfillment, reporting, accounting)? Are you taking unnecessary risks to save money? And most of all, can you get along with the vendor as a partner? This is a lot like getting married: Is the chemistry right?
The chemistry makes a big difference. After all the careful, objective, rational work you’ve done, success or failure may rest on “gut feel” about the vendor. This is an appropriate last step. But if your team is involved all the way through, there should be consensus on this point as well. If the decision feels right to the team, then go for it.
Ernie Schell is the president of Marketing Systems Analysis Inc., Southampton, PA, and author of The Guide to Catalog Management Software. He can be reached at (215) 396-0660 or [email protected].