VOLUME 1, NUMBER 1 | SPRING 1998 Selecting and implementing a new integrated manufacturing software package is one of the most risky events faced by most businesses. Most companies can usually recover from a sales slump or a bad profitability quarter, but a failed system implementation can easily cause a serious crisis for a company that can last for a few years or more, and can even lead to bankruptcy. The first thing that escapes the attention of many business people is that this is not just a computer project, it's a major business decision challenge. While choosing a solid technology is very important for success, the technology must not overshadow the business needs. Choosing a poor technology or one that is unlikely to stand the test of time can lead to a series of problems, but choosing a system that does not truly match the needs of the business can create even more serious difficulties, even if it is based on the latest and greatest technology. If the software selection and implementation project is being driven by the technology gurus rather than by the operational experts in the company, the company runs a sizable risk of coming up with the right answer to the wrong question, and this of course could easily be a formula for disaster. It all must start with a statement of high level business objectives -- where does the company want to go? -- that is quickly followed with a definition of functional requirements for the new system -- what must the new system do and how must it work? Functional requirements definition is a team sport; all major functional areas of the company must have a voice if the project is to be successful. The technology experts should be a very strong voice in this decision, as long as the technology choice does not become the overriding factor. The company's technology vision should be the backbone of the project, but not necessarily its arms and legs. Having said that, these projects are still extremely risky even with full team involvement and a well structured technology vision. There is probably more confusion on the subject of software selection now than there ever was before -- although many might argue that point. Given the time crunch put on us by the pending Year 2000 dilemma, and the frequently voiced opinion that the software package market will see significant consolidation and shakeout after the Year 2000 bubble passes, many people feel that most of the decisions have already been made for them. Others realize that this thinking may be shortsighted and not in the best interest of the companies involved. There was a saying in the computer industry not too many years ago: "You won't get fired for buying IBM." IBM was easily seen as the industry leader, and it was the safest bet; the mainframe was king. So how did the other alternatives become so popular? The UNIX vendors, Microsoft and so on -- the better mousetrap, or perhaps just different mousetrap -- proved the industry visionaries to be wrong. The future of technology holds tremendous uncertainty. Now, while that statement might be accepted in people's minds, this belief is not necessarily reflected in their actions. Selecting a software package based on the fact that it has become a household name may look like a viable strategy now, but a few years from now the decision makers may look like they missed the proverbial boat. There are many software packages on the market that will not only survive, but will do quite well beyond the dreaded year 2000. So companies should not fear striving for a nice custom, and should resist flocking to the one-size-fits-all rack without investigating the industry niche specialists. So, with that perspective in mind, let's take a look at the big picture. Selecting the right software package for any given company is far more than just a quick decision based on a popularity contest. Time and effort spent on an in-depth requirements definition and software selection project will pay back handsomely during the very intensive implementation project, not to mention the years the company will be living with the system long after the implementation struggle. Finding a really good functionality fit eliminates many of the battles that will otherwise flare up during the implementation war. Taking the approach of finding the packages with the best functionality fit, and then scrutinizing those for which have the most attractive technology base and direction gives you the best of both worlds. One of the opinions that we encounter frequently goes something like this: Why should we be so concerned with functionality differences when, before long, all major software packages will begin to look alike from a functionality perspective? While it is quite true that most of the major popular software packages have significantly broadened their scope of functionality and are likely to continue on that trend, this does not mean that it is becoming a one-size-fits-all market at the expense of the industry specialists. No matter how many options GM adds to its Cadillac, the Cadillac line will never be the only game in town, or even close. In fact, adding too many options in an attempt to be all things to all people would spell disaster for a car company. There are many successful car makers because there are many different types of people with many different sets of needs. This is no different than the array of companies with their own operating styles. This is why the functionality testing of software packages can no longer be a simple yes or no exercise. There is a big difference between just having a piece of functionality and truly specializing in it -- and an equally big difference between simply having it and understanding how it should look and feel for a particular industry segment. What has changed is not so much that software cannot be differentiated by functionality ratings, but that functionality differentiators must now look at both quantity and quality, instead of quantity alone. Common Pitfalls that Cause Problems in Software Selection Doing it yourself without outside expertise is dangerous unless you have enough systems expertise and current knowledge of the software package marketplace. Few companies have this -- especially in knowledge of the current market offerings, which is a constantly moving target. Establishing a system requirements definition without professional outside expertise carries the risk of the company failing to entertain and understand new ideas and concepts. If the company is not "thinking outside the box" as part of the planning for a new information system, the new system may do little more than saddle the operation with the shortcomings of the past. Picking a system without doing a targeted search almost always spells trouble. Choosing a system that you've heard is probably a good fit for you is like investing in a stock you heard about at a cocktail party without bothering to evaluate the other investment opportunities. The good fit you heard about may be for a different size of company, or one that's in the same business as yours, but has a drastically different internal operating style. It could be that the opinion came from a company that failed to do a proper search and ended up with a package that, although it does work for them, does not really represent the best fit. One of the biggest problems in this approach is that people start talking to software vendors too early in the definition process, often long before they have clearly defined what it is they're looking for. It's almost impossible to be objective when individual team members start developing favorites before the requirements definition is established. The result of this approach is often that the team arrives at the answer before it fully understands the question, and then endeavors to craft the question so that it fits the answer they have already found. Asking the right questions and the right number of questions during each stage of the process is the key to success, and it's harder than most people think. The proper software selection process looks like a funnel. You start out with a large number of software packages that are potential candidates. You don't want to ask a thousand or so functionality questions to 200 vendors, and then try to sort out the answers. So you do the evaluation questioning in iterative rounds, starting with a large population of vendors and a small number of high level qualifier questions. With proper questioning, more than half the vendors are removed from contention with as few as 10-20 questions. With each succeeding round, the vendor population decreases and the questions are greater in number and deeper in detail. Getting through several iterative rounds to the few semi-finalists fast enough to keep from losing the project's momentum is the biggest challenge. Taking too much time in the preliminary analysis phase is dangerous. Once the decision is made to go look for a new system, the clock starts ticking. The enthusiasm engendered by the kickoff of the project will disappear if the requirements definition and preliminary software evaluation drags on for months. The faster the company gets to the action steps of kicking the tires during software demonstrations and planning the implementation, the easier it will be to maintain a high level of enthusiasm and commitment. Asking too few questions causes you to miss some good alternatives. Asking too many questions causes confusion that hides the really important issues in reams of detail. The "candy store" syndrome -- developing the all-inclusive wish list to get to the short list of best fit packages -- will guarantee that the only packages showing up on your short list will be the big, expensive one-size-fits-all packages. The packages on the second or third shelf that actually represent better custom fits for your company will be ignored. The Rush to Beat the Year 2000 Problem Concerning all the hype about the Year 2000 situation, many companies are wondering if they still have time to find and implement a new ERP system before the crunch. That's a tricky issue, and the answer is yes and no. If a company is going to make a long, convoluted project out if it, it probably doesn't have time -- and some companies don't know how to do this kind of project any other way. If a company has a good focus, a committed team and finds a package that closely matches its needs, and therefore does not require significant modification, there is still time -- but certainly not an overabundance of time. The popular phrase, "If you don't have time to do it right, how are you going to find the time to do it over?" comes to mind on this issue. Although time is tight for Year 2000 resolutions, investing an extra month or two in doing a proper software selection project to find the absolute best fit can easily pay back by saving three to six months on the implementation of a package that does not quite fit the business. Summary -- Questions Can Be More Valuable Than Answers If arriving at a safe answer is the goal of your software selection project, the job is much easier now than it was a few years ago: just pick up a list of the most widely advertised software packages, tack it on the wall and toss a dart. With the right amount of compromise and hard work, you will probably survive. But, if your goal is to find the best software package fit for your business, and the one that represents the best value on the market, the software selection task may be much tougher than in prior years. The lines that differentiate packages are finer; surface appearances of modern technology can hide many shortcomings and the battle between the "one-size-fits-all" vendors and the custom fit niche players has created a decision-making dilemma of giant proportions. To further complicate matters, many differing "expert" opinions have flooded the market, adding another layer of confusion. There has never been more of a need to focus on the questions before speculating on the answers. The company that takes a good hard look at its information requirements and gets the key players in agreement on priorities before scurrying off to the software market stands a much better chance at finding the software package that will bring them the greatest success. ABOUT THE AUTHOR Dick Kuiper is president of Expert Buying Systems, Inc., a company specializing in assisting manufacturing and distribution companies in selecting integrated software packages. Kuiper has more than 25 years experience developing, evaluating, selecting and implementing software packages. He has been project manager on more than 15 major software implementation projects. He is an author and public speaker covering many subjects related to the proper use of technology in business. Kuiper can be reached at (800) 832-6434. Web Site © Copyright 2020 by Lionheart Publishing, Inc. All rights reserved. Lionheart Publishing, Inc. 2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA Phone: +44 23 8110 3411 | E-mail: Web: www.lionheartpub.com Web Design by Premier Web Designs E-mail: [email protected]