Seven Practices You Need to Succeed

Supply Chain Execution Systems Implementations

By David Meyers, Director, Tompkins Associates

A common assumption about supply chain execution (SCE) systems implementations is that, while they have the potential to provide value, in the end, they are not worth the risk or hard work required. At worst, many fear that the organizational changes brought on by this kind of investment could ultimately damage relationships with customers if things go wrong. Because of these common fears, many companies who really need to replace or improve old systems never pursue supply chain execution projects.

Before throwing the baby out with the bath water, make sure that you understand the benefits that can be realized by implementing a SCE system the right way:

• Enhance the visibility of product throughout your supply chain
• Real-time information that can be used to make an array of time-sensitive decisions
• Increased data accuracy and reliability
• Increased throughput within your operations
• Higher inventory turns and lower inventory carrying costs
• Reduced transportation costs
• Ability to offer incentives for increased productivity and more accurate performance
• Increased customer service and customer satisfaction levels regarding order accuracy and delivery times
• Ability for higher conformance and performance with customer requirements

Many years of experience working on and eventually leading SCE systems implementations projects have led to an understanding of what works and what doesn't, what approach will succeed and which will fail. If you're considering purchasing a completely new system or upgrading an old one, following these seven best practices will help you destroy the myths that hold many companies back.

1. Realistic Objectives and Expectations-Defining business requirements

Before undertaking any implementation project, the first step is to understand your business needs:

• What you need from your suppliers
• What your shareholders need from you
• What you need to do to gain market share
• What you need to do to increase revenue and reduce costs across the entire supply chain
• What information you need to provide to your host and/or legacy systems
• What you need to comply with governmental regulatory agencies
• What you need to retain employees and improve their work experience
• What you need to do to protect your customers.

One of the best ways to communicate these needs is through a leadership roundtable conducted by an experienced facilitator. Key executives participate in a four- to eight-hour working session that covers each of these areas. Starting out at a strategic level and working down through some key tactical details, the facilitator aids in producing a vision for the project, goals to be achieved and an action plan to define your path forward. Armed with the action plan, the project team, once formed, has direction from which to deliver results that will meet the business needs.

2. The Right Systems-Meeting business objectives

Once the action plan has been developed, system selection can begin. Selecting the right SCE system is the result of many steps: requirements gathering, requests for information from vendors, site visits, scripted demos and an objective evaluation process It is important to understand that no single system can be everything to everyone, so it is at this time that a gap analysis is performed.

In a typical request for information, vendors are asked to respond to specific business requirements. Typical templates have a form to which vendors reply, "Base Functionality," "Configuration Required," "Modification Required" or "System Architecture Does Not Allow." Within the "Modification Required" category, it is common to request that vendors also quantify that response depending upon the level of effort on their behalf to design, code and integrate the modification. A gap analysis establishes where business needs and systems functionality do not coincide as per the pieces of functionality where the vendor has replied "Modification Required" or "System Architecture Does Not Allow." At that time, decisions need to be made-again through an objective process-whereby it is determined to modify the base package, change business requirements or to meet somewhere in the middle. This aids in refining the budget and setting a more realistic project execution plan.

It is worth the time and expense to visit the actual facilities of vendors' references. Ask about the pros and cons of the system, the good and the bad aspects of the implementation, the support they currently receive from the vendor's help desk and the quality of the implementation team that the vendor provided. This is also a good time to ask the host about the level of resources they committed to the project and whether they believe that level of commitment was sufficient.

3. The Right Team-Executing the action plan

To ensure a successful implementation, the project team must be comprised of team members with the right stuff. For a SCE system, a cross-functional team made up of manufacturing, customer service, receiving, inventory control, quality assurance, logistics/transportation and shipping personnel is a step in the right direction. Although some team members' experiences are more critical to the validation of the system's core functionality, the extended team can help ensure that a holistic approach is taken and will ultimately result in a system that will benefit the entire business rather than just the day-to-day system operators.

Projects that impact the way you do business require significant resources (human and monetary) and take time. There are three factors that will dictate the successful implementation of the action plan: quality people, dedicated time and an appropriate number of people to complete the project. Reducing one of those factors requires an adjustment in one (or both) of the other areas. Since people cost money and time is money, it often comes down to, guess what? Money.

A Tale Of Two Businesses, Part 1

In one SCE system implementation, the customer committed early in the process to having key business and operations personnel actively engaged in the design, configuration, testing, validation and training components of the project. While the customer's intentions were good, the current day's business needs got in the way of the project team's objectives for a successful implementation that would support tomorrow's business needs. Sales were rapidly increasing and team resources went back to managing the day-to-day activities. Other project teams and new company initiatives were competing for resources, and the lack of forceful direction from senior management allowed the project to become understaffed. What were originally classified as key business requirements began to dissolve into non-essentials. The result was a frustrated customer, limited functionality, lost sales, customer service issues, inventory control problems, unrealized ROI for the project, a burned-out project team, and a lot of finger-pointing.

In another implementation, the customer's commitment was strictly monitored against the team's charter. In weekly update meetings, the charter was reviewed and every aspect of the project was measured against that charter. When it became clear that certain team members would better serve the company by working in other areas, they were replaced with personnel better suited to gaining results. The end result was a satisfied customer, happy customers, increased sales and throughput, ROI goals that were met and actually surpassed, increased inventory accuracy, better supply chain visibility, and a general feeling of euphoria after go-live.

4. The Right Processes-Realizing system benefits

The final SCE system design must have its foundation in operational best practices. These processes must be defined and designed down to the front line end-user's key-stroke level system interaction. Although at this stage of the project, the right objectives and expectations, the right system and the right team are in place, it is time to fine-tune the processes.
System design is a tedious, yet important process that begins with interviewing key users of the current system to gain comprehensive understanding of the entire business process. Without this knowledge, bad assumptions are made and flawed processes are put into place. It is critical to understand everything from where goods come from to where they are going and everything in between, including the software and hardware architecture and infrastructure that has supported the old way and will be expected to support the new way of doing things.
The project team must ensure that at every turn, they are taking advantage of the systems' functionality while not shortcutting, or conversely complicating, the needs of the business. Many times, the best answer is the simplest. Get input from everyone in the operation and in the support organization, and analyze the input to make the right decision when it comes to your processes and your business.

5. The Right Plan-Testing the system

Before putting your system into production, it is a given that it will need to be tested. To get the desired results, you must be certain that every operational process is tested (along with any of the associated functions that may trigger transactions that are sent to other systems). Furthermore, the respective business owners of the data (and the owners of any other system with which the new system is interfacing) must review the results of the tests. Prepare a detailed business scenario tracking matrix and provide the business owners with an opportunity to review and to provide input to the business conditions to be tested. The supply chain execution implementation project will, and should, have farther-reaching effects than just your supply chain, so it is critical that every system that has an interface to or from the supply chain execution package is considered when developing your test plan.

A Tale of Two Businesses, Part 2

In one implementation, a detailed test plan was written, all of the expected results were documented and the tests scripts executed. The core testing team reported that everything looked great: inventory levels were as expected, tight lot control was assured, customer orders could be fulfilled and essentially everything worked according to design. The customer even went through the process of a "mock conversion" and "mock go-live" to make sure that there would be no obstacles to a perfect implementation. The "go/no-go" decision was made. It was a "go." Shortly after startup, it was discovered that the customer service centers were being deluged with calls from customers, and the service reps could not answer the questions they were being asked. The missing piece of this puzzle was that the call center reps did not buy into the system, nor did they participate in the process of validating that all of the business conditions were tested or being met. They left that up to the warehouse people and assumed that everything would work as before. They took no ownership of the new "warehouse" system.

In another implementation, all of the testing was conducted in the same manner, with the exception that this team included a representative from customer service. This team member participated in design, testing and training to ensure that the entire business would be serviced by the new application and that regular and casual users would use it effectively. Calls to the service center actually decreased and the call center associates were able to give even more specific feedback to the customers than before the new system was implemented. The one team member alone did not make the difference, but this approach is indicative of the level-of-commitment to the level-of-success ratio.

The best testing involves using "real" data copied from production, using real users and business owners and real-life processes. Do not underestimate the importance of volume testing and mock tests-these are no longer luxuries but essentials. In today's business climate, companies can ill afford to be down for an hour, much less a day.

6. The Right Training-Using the system effectively

If a SCE system implementation fails, it often fails not due to a flawed design, but by ineffective use by system operators on the floor. You cannot make a system foolproof. Rather, you must ensure that your users know how to use the system to get the expected results. Use simulation whenever possible and perform mock facility tests using the same equipment and processes that will be used after you throw the switch. Another key component of the training process is the need to convey information consistently and in accordance with the tested and proven design. The primary mechanism to ensure this consistency is the standard operating procedure (SOP). Even the most thoroughly tested system can fall apart if users resort to workarounds that have not been made part of the final design. When writing the new SOPs, keep in mind that most of the operators will be more inclined to use them if they include screen shots and easy-to-follow bullets that apply to the specific tasks that they will be expected to execute. It is equally important to include non-system related processes in the SOPs, as most of the system users do a lot more work than just key data and scan bar codes. Make sure that there is an exception section in every SOP to help users through those situations that may happen rarely, yet are certain to happen. These situations often have the greatest potential for negative impacts downstream.

Before you can go live, you must be able to determine, objectively, that the users understand what they are doing and why they are doing it. Competency assessment must be an integral part of any successful training program so that those who understand can be certified, and those who do not understand can receive additional guidance. Make sure that managers understand the system as well as, if not better than, their subordinates.

7. The Right Timing and Support-Minimizing impact to your customers

Support for the entire implementation project must come straight from top leadership in your organization. Believe it or not, not everyone will be as excited as you are about the new system. Many people in the business would rather keep using the old system because they are comfortable with it. The challenge of learning the new system and the time and effort required may not seem worthwhile to the rest of the organization. You must work to ensure buy-in at all levels and continue to communicate the benefits of the new system to those who will be impacted by the transition.

A critical component of the implementation process is a conversion and ramp-up plan. This plan is a roadmap to ensure that incremental steps are taken during the go-live activities to prevent anything that may have been missed from crippling the business. If things are not going well, you have to be brave and consider your options. Ultimately, no one will remember whether you hit your target go-live date, but everyone will remember if you succeeded or not. The conversion and ramp-up plan will provide the critical success factors and key performance indexes that you need to help make these decisions.

A Tale of Two Businesses, Part 3

In one implementation, the operations personnel, charged with the responsibility for its execution, developed a conversion and ramp-up plan. All of the systems had been tested and the day of go-live was at hand. Orders were bridged from the host system to the supply chain execution system and it was noticed that the host inventory was not diminished as orders were shipped. Rather than stopping and taking the time to assess the root cause of the problem (it was later determined that an old version of the interface program had been migrated to production rather than the validated version) the sales organization exerted pressure on the distribution group to increase the volume of orders being processed in order to meet some rather arbitrary goals. Orders continued to get shipped and host system inventory continued to get more out of line with the physical inventory levels. Things got so bad that there were demands to cut back to the old system even though this switch would have caused several days worth of effort and an array of other serious systems issues. If the entire organization had been brought into the ramp-up plan and followed the plan, the downtime and host inventory issues would have been insignificant compared to the situation that ultimately developed. It took one month before the operation was up to pre-conversion production levels and left several customers with hard feelings.

In another implementation, the conversion and ramp-up plan had support from the VP level across the entire organization. An hour-by-hour snapshot of projected key performance indicators was developed in coordination with the implementation team. The ramp-up plan was also communicated to the customers so that expectations were set and allowances could be made for delivery contingencies. The switch was thrown and the operation went live with the new system. As issues arose, and there will always be issues, they were triaged and team members were assigned to resolve them. The core implementation team continued to map progress against the plan and was able to make objective business decisions regarding the path forward. The company was back up to full production volumes within two business days and saw a faster than expected pay back on the project.

Executing for Success

Don't allow yourself to be talked out of implementing an SCE system because you believe all of the bad press. The business benefits are there for the taking if you plan your implementation properly.

Yes, embarking upon a supply chain execution system implementation project and following through to putting the system into production is not easy. However, most worthwhile business improvement strategies are rarely easy endeavors. Don't be intimidated. Go into the process armed with the knowledge of experienced veterans who know and have conquered the pitfalls. By applying these best practices to and throughout an SCE implementation, you can make your project a success.