Don’t expect everyone to describe the same ‘elephant’
Ninety-nine Percent Tedium
One of the most challenging projects for any systems manager at a direct commerce company is selecting and implementing a new system for customer service, order processing, and fulfillment. The endeavor requires all departments of the company to participate actively, at all levels. It’s an expensive and time-consuming process. It is also fraught with peril, not only because there are so many variables and tradeoffs but also because it is difficult to separate reality from wishful thinking on the part of the vendor and optimists inside your own company.
Crash and burn
To be successful, the system selection and implementation process itself must be excruciatingly detailed. It’s like the saying about flying an airplane: 99% tedium, 1% terror. If you lose perspective during the tedium, you will surely wander off course. And if you don’t handle the terror effectively, you will crash and burn.
Any good system selection process starts with an evaluation of the current systems in place, and some type of enterprise systems plan (ESP) to assess your systems goals and high-level systems requirements. This need not be a formal document, but it should at least identify the primary systems objectives, suggest how you envision meeting those objectives, summarize the current systems in place, indicate which of those are working just fine and are not expected to be replaced, and contain specifics on time frame and budget for new applications.
Producing the ESP is also a good opportunity to consider systems integration, e-commerce issues, and related subjects like workflow management and external and internal communications (such as extranet or intranet options). Does your Web site support customer self-service, voiceover IP, and other technologies? Do you want it to? How about merchandise forecasting?
Finally, you should address the critical issue of operational and managerial reporting. A larger organization may need to consider a formal data warehouse or data mart infrastructure. A smaller organization is more likely to be concerned with getting the right reporting tools. The ESP should spell out not only what information you want the reporting structure to manage but how you want to use that information to run the business.
Needs must
The next step in the systems selection process is producing a detailed needs analysis. There are five major challenges in developing such a document:
-
The forest and the trees. First you must discover the features and functions that users and managers want, then you must prioritize and classify them. You should involve a broad range of company associates in this process, but don’t expect everyone to describe the same “elephant.” Beware of conflicting agendas, as well. While there is not adequate space to provide a checklist here, you can see an example at www.schell.com/functions.html.
-
Business process reengineering. It is not enough to simply discover current business practices. Your needs analysis should include some discussions of new ways to approach business methods that can add value, reduce costs, improve efficiency, or otherwise rationalize what may have been work-arounds, stopgaps, or arbitrary procedures.
-
Best practices. Do you want to try to incorporate some industry best practices as part of your reengineering? Which ones? For what purposes? Examples might be implementing a WMS, a merchandise forecasting system, or a collaborative workflow system. Be wary of adopting procedures for the sake of abstract improvement. Any new methods imported from the outside should be enthusiastically championed by both management and the potential users before becoming part of your plan.
-
Description vs. development. This is one of the trickiest and stickiest challenges. You want to describe your requirements fully so that you can ascertain whether a vendor’s system meets them, yet you are not designing a system from scratch. There is no pat answer here, other than to advise that you focus on what you believe are not only the most important requirements but also the ones that are likely to be least “standard.”
-
Clarity and precision of communications. Finally, your needs analysis should be as clearly and precisely written as possible. You are going to ask vendors to understand your business by reading this document, so clarity is a major priority. Have someone in your company who is regarded as a good communicator read it over before releasing it to make sure it really does communicate effectively.
Natural selection
A word about selection is in order here. Your needs analysis will become the core of a request for proposal to be sent to the vendors who you believe can most likely meet your requirements. Their proposals should address your specified needs in detail. In all likelihood, none of the vendors will be able to meet all your specifications without some modification.
You will need to consider a number of tradeoffs in making a final selection, including system price, vendor size and reputation, quality of support, platform, system architecture, integration options, modules available and required, and e-commerce integration.
As far as features and functions are concerned, the general rule is the fewer the modifications the better. Discuss in detail with the vendor what approach they take to doing modifications, have them specify what impact this will have on implementing upgrades, and talk to at least three users who have undertaken modifications similar in scope to yours to see how well they were done.
You may have to decide between a feature-rich system that will require major modifications and a less complex system that requires fewer modifications but has less long-term potential and may come from a smaller vendor. Or you may be called on to choose either an inexpensive system with major modifications versus a more expensive solution with fewer modifications.
Whatever the tradeoffs, expect to be confronted with some difficult decisions, no matter how carefully you’ve done your job. The only consolation is that you are weighing known variables as opposed to shaking the dice on a lot of unknowns.
Implementation
There is a natural rhythm to many system conversions: An enormous amount of time, energy, and effort is expended to get to the point of selecting a new system, which appears to be the climax of the story. All the rest is denouement, and the quicker the better.
Unfortunately, implementation may require even more work and effort than selection did. Since the outcome is already known, however, you won’t have the same level of emotional commitment from anyone in the organization. As far as most people will be concerned, this is just a clean-up effort.
This is not the case. You need to plan this phase of the project as carefully and administer it as assiduously as you did the search and selection phases, or risk seeing all your efforts go for naught.
First and foremost, you must freeze the project. If modifications are being done to the system (as is usually the case), there is an inevitable tendency, once the system has been selected, for individuals within your organization to want to add “just one more” feature or function to the application.
Do not give in to any of these requests, unless you somehow neglected an item of paramount importance, or your business itself has taken a dramatic turn. Otherwise, stand firm against all incremental changes. There will be plenty of time for fine-tuning once the system is up and running. Chances are that the requested changes will prove unnecessary in the long run, anyway.
Ernie Schell is president of Marketing Systems Analysis, Inc. He can be reached by phone at (215) 396-0660, by fax at (215) 396-0696, and by e-mail at [email protected].