7 steps to successful systems implementation

With any major software implementation, you are changing the entire operation of the company and everyone's responsibilities. And if it's not done correctly, you can create costly disruptions to your business.

Assuming you have done a thorough shopping job and have procured the right system for your business (for more on this, see the July article “12 Mistakes to Avoid in Systems Selection”), you now have to map out the critical issues for an implementation. Paying close attention to these seven factors will help make your project a success.

1. Project management

   Conversions to new systems often get off track because companies fail to plan the project realistically or they don't execute or manage the project by the plan. Remember that major systems conversions are not just IT projects. Companies should maintain joint responsibility with the vendor in the project-planning process, maintenance of the project-plan status, as well as some degree of control over the implementation.

   All key user departments should have representation on the project team, including the call center, website, fulfillment, management, merchandising, inventory control, marketing and finance. Team members should share responsibilities for conversion, training and successful completion of the project tasks.

   The software vendor should have a time-tested project methodology and provide a high-level general plan. As the merchant client, your job is to develop the detailed plan with the vendor, backed up with detail tasks and estimates.

   For example, a generalized plan may have a list of system modifications, but lack the details that need to be itemized. These may include research, specifications, sign-offs, program specs, programming, testing and sign-off, and the various levels of testing and program integration back into the base system.

   Plan for contingencies, and try to keep disruptions to the business to a minimum. We have seen systems go live and with management initially unable to get their most frequently used reports — this can be a big problem.

   Along the same lines, you should schedule the go-live for the slowest period of the year. In consumer retail and ecommerce businesses, systems generally aren't brought live from September through Jan. 15.

   The systems project should have a senior manager who acts as the project sponsor. The project should be reviewed periodically by the steering committee to track its progress. This ensures that senior management on down to the department managers are committed to success.

   Once you have a plan that makes sense, make sure you manage by the plan. This sounds elementary, but many companies and vendors stumble on it.

   Early in the project publish a biweekly status report. Once you get within a few months, you may want to have weekly conference call meetings and status updates. Within 30 days of “go live,” hold daily meetings and list what needs to be achieved.

2. Process improvement and best-practice implementation

   Many companies fail to address process and procedure changes that could make the most of the new system faster. This means they are less apt to gain the desired efficiency from the conversion.

   So you may need to rethink how the processes and systems that surround the automated systems have to change as the new system is installed.

   These process changes will vary with the types of systems. With a warehouse management system, for example, these process changes may include vendor compliance, reporting of receipts, implementing new methods of picking, inventory cycle counting procedures and so on.

   An order management system, on the other hand, will have a different approach to servicing the customer, management reporting, interface and support of web customers, balancing and interfaces between OMS and accounting, refund and credit processes between customer service, and returns processing.

   What existing procedures and systems can you strip away to add efficiency? What new processes and procedures are required or desirable? What best practices should be considered and implemented? These are just as important as a successful implementation of the new system.

3. System parameter configurations vs. modifications

   One of the most prevalent mistakes that companies make in implementing systems is trying to replicate their existing systems. Modifications increase cost, elongate the implementation timeframe and increase risk. We've seen companies insist on modifications only to realize in the first year of operation that there were better ways of using the new system than trying to replicate the old.

   Most systems on the market can be configured using parameter switches that set options and give a different personality to the application, allowing it to be implemented in different types of businesses. This allows customizing an application without modifications; that's not to say you won't sometimes want or need some modifications.

   Many applications have hundreds to more than 1,000 system control switches. The vendor will, obviously, need to train your staff on the system and help you make prudent switch settings.

   This is detail work that often takes several weeks of consideration. It's important to understand the consequences of how a switch is set, then test, and then change the switch setting if necessary and repeat testing.

4. Successful file conversions

   There are 200 to 500 tables and files in a full-function OMS, so you need to allow enough time for file conversions. The overarching concerns for successful file conversion include:

   • Deciding what files should be converted via programming vs. building tables and files manually. You can't generally afford to program convert many files, but you should convert your customer, item and order files. What effort is involved and at what cost?

   • Who will build the hundreds of other tables and files required for the new system and how? These include warehouse bin location schema; vendor file and associated purchase orders; back orders; offer and source code files; shipping and processing tables; chart of accounts, and so on.

     Another way to look at these activities is that early introduction to the required files and functionality starts laying the groundwork for procedures and responsibilities that are required by the project team.

   • What history should you convert? Initially businesses want years of history, but what is realistic and at what cost?

   • During the conversion, assess the quality of the conversion in terms of the number of records and the accuracy of the data converted. Spend sufficient time to specify, program and test the conversion programs.

   • Consider your plan for cutting over to new system and file conversion of the most recent files and databases. How will you manage this so that your files and databases on the new system are current at the go-live time? How much time will be required to convert files?

   For larger businesses, will there be elapsed time to make the conversions from the last day on the old system and bring up the new system?

5. Multiple instances of the software and database

   You will need multiple instances or copies of the software/database and application. Most software contracts restrict you to using only one copy of the system and one backup for recovery without negotiating for multiple set use. There are additional license charges for the additional copies that are often overlooked in the contract negotiations.

   You should have at least two copies or partitions for applications: one for development and training, and one for production. Larger companies may require three copies. The advantage of this is that you can lock down production to keep users from inadvertently modifying or destroying production files.

6. Software training and procedures

   Probably the most underplanned area is in training and writing procedures. You need to understand that the vendor will provide documentation only about the application and, at best, how the system operates in terms of functionality.

   The vendor's approach is typically to “train your trainer.” From there, it's your responsibility to develop training materials and approaches for the various departments and the new policy and standard operating procedures (SOPs) that are required.

   Most companies don't have full-time trainers. It's a good idea to train each department manager on the application, and then have them develop the SOPs and set training for their department. All of this will need to be standardized so that the documentation is at the same level of detail across the operational departments.

   It generally takes six to 12 months after implementation for companies to start feeling comfortable with the new systems. It may take longer to achieve the ROI from the application. Training is the single most important thing you can do to shorten the learning curve.

   Most vendors offer not only the initial training, but also more advanced instruction for super users. Budget for the additional training; it's the smallest part of the total expense.

   And perform a post implementation audit 30 to 60 days after the go-live. Identify the individuals and departments for which additional training is necessary.

7. Thorough testing

   Everything must be thoroughly tested — systems parameters, modifications, conversion programs. Testing means having the time and the involvement of the users, and then comparing test results to expected outcomes.

   One of the best ways to be sure that the system is ready for implementation is to conduct a conference room pilot. This involves running all the application functions with a test copy of the system.

   Run all the processes from beginning to end. Use scripted test data for every type of function. Test the interfaces to other systems. Receive and process website transactions to the business system.

   Are all the warehousing functions operational? Run and print the key reports. The project team should run the conference room pilot.

   This will take some planning and coordination, but it's the best way to determine if the system has been configured correctly; if modifications are programmed and tested correctly; and how the new files, tables and databases will appear with your data. It's also an indication of whether the system is truly ready for implementation.

   As you uncover errors, problems and other surprises, go back and rerun the functionality with the corrected programs and compare the results to expected outcomes.

   If you have developed your training procedures and SOPs, this is an excellent chance to see how effective they are, and how they need to be fine-tuned.

Curt Barry (cbarry@fcbco.com) is president of F. Curtis Barry & Co., a multichannel operations and fulfillment consulting firm.