One common mistake to avoid at the outset is viewing the implementation effort purely as a systems project.⁴ As suggested by the tasks listed above, planning software implementation is actually about integrating data, business processes, and supporting systems. These three components can be thought of as the three legs of a stool in the implementation project. As our own experience showed, the three legs mutually support the entire implementation process, and each leg is critical to the project's overall success.

In the discussion that follows, we first compare the traditional plan generation process with the state-of-the-art plan generation process. A state-of-the-art plan can be defined as one that uses optimization and artificial intelligence, two advanced technologies not found in a traditional plan. The solution that we selected was the Supply Chain Planner from i2 Technologies. Next, we go into the details of the four main tasks, highlighting the challenges and the success factors. We then conclude with a summary of the key lessons learned.

Like many organizations, ICBD needed two sets of production plans. One was the demand-driven plan, which gave us long-term capacity needs. This plan is the same as the Material Requirements Planning (MRP) plan. (MRP generates the material requirements needed to meet current and future production demands in a manner that maximizes on-time delivery while minimizing inventory.) The other was the committed plan, often called the build plan or plan of record, which gave us what we needed for execution. Broadly speaking, the main difference between the MRP plan and the build plan is that the former does not reconcile demand/capacity imbalance, while the latter does. The MRP plan often is used to identify bottlenecks in the supply chain and validate the build plan; the build plan is usually incorporated into a shop-floor scheduling system for execution.

Traditional legacy planning systems can generate an MRP plan that explodes demand requirements backward through a supply chain via such techniques as work-in-progress and on-hand inventory netting, back yielding, and time phasing. In the absence of a state-of-the-art planning system, however, generation of the build plan involves multiple manual iterations among the organization's planning groups. The planners scrutinize the MRP plan and make changes to conform to capacity or material constraints, adhering to various business rules such as capacity smoothing.

The traditional and state-of-the-art processes for generating the MRP plan are basically the same. But the two are quite different when it comes to generating the build plan.

The traditional build plan is generated via Excel and MS Visual Basic macros. Two of the major problems with Excel-based planning, however, are the proliferation of spreadsheets and the difficulty of sharing.

The process for generating the state-of-the-art build plan as it applies to the semiconductor industry and heavy-process industries (petrochemical refineries, paper mills, steel and aluminum plants, and so forth) is shown below:

Linear Programming¡úLot Sizing Heuristic¡úFine-tuning Strategies

First, the linear programming (LP) module generates an initial build plan by solving a series of linear programs. Each program corresponds to a business rule in a hierarchical planning model subject to resource and demand constraints. Because the LP decision variables take values from some continuous range rather than from a set of integers, the LP plan rarely satisfies the lot-sizing requirements. Furthermore, because of simplifying assumptions in the commercial planning software, the linear programming plan might have some small area of material infeasibility. Therefore, some lot-sizing heuristic and fine-tuning strategies need to be applied to smooth out the "rough edges" while maintaining the priority of the various business rules in the LP formulation.

The state-of-the-art plan generation process has demonstrated advantages over the traditional approach. Specifically, by implementing a state-of-the-art planning system, companies can reap the following benefits within a relatively short payback period:

• Enhanced reliability and optimality of production planning. Without a highly automated planning system, the planning process is more art than science, which leads mostly to local optimization efforts. By contrast, the state-of-the-art planning process is more predictable, consistently providing output of globally optimized plans.
• Improved automation level in the plan generation process. As a rule of thumb, the automation level in the plan generation process tends to correlate positively with most manufacturing and financial performance metrics, such as on-time delivery and return on assets.
• Reduced planning cycle time. By reducing planning cycle time, the state-of-the-art build plan becomes more responsive to customers. In addition, the planners can get involved in more value-added activities such as strategic and financial analysis instead of just trying to get the plan out.

The first step toward a successful implementation is to assemble the implementation team. At Agilent, the team included executive sponsors, planners, IT support staff, and internal and external consultants. One of the implementation team's main goals is to foster a strong partnership with both stakeholders and users. Here, the term stakeholders mainly refers to management, and users refers to planners. Often organizations place heavy emphasis on getting buy-in from management but not necessarily from the planners. It's true that executive sponsorship, both financial and political, is a prerequisite for the project's success. It's also true that the planners rarely determine project funding. Yet the planners should be treated as true customers, because they ultimately determine when to go live with the new planning system and how to follow it. Given this reality, the planners must be actively involved throughout the project's life to increase the probability of success.

After ensuring that a strong partnership foundation is in place, the implementation team begins to analyze business needs and define the project's scope in detail. During this phase, the team interviews stakeholders and users to understand planning processes and to identify the key business drivers that serve as the catalyst for the project.

After the key business drivers are identified and assessed, the next challenge is to thrash out the actionable scope of the project. It's important to set realistic, sustainable expectations. Sometimes stakeholders and users expect unrealistically high returns given the available resources and specified timeframe. To minimize the risk of "scope creep" and overengineering in later steps, the implementation team needs to perform iterative and rigorous reviews of target business values with both stakeholders and users. Target business values are core strategic objectives such as assuring adequate supply and satisfying customer demand.

The key here is to think big and start small. After determining the target business values, the team can make a more informed decision on the project's scope. Team members can more accurately pinpoint which specific capabilities of the software are required. They also can determine the timing of these deliverables based on their relative business impact.

The implementation team faces a number of challenges during this critical initial phase. Based on our experience, these challenges can be met by following certain key principles¡ªtwo of the most important of which are discussed below.

First, no critical assumptions about planning business processes should be left unverified or remain ambiguous after the stakeholder and user interviews. The importance of establishing a solid, unambiguous foundation early on cannot be emphasized enough. The reason: Project deliverables will be built around the findings from the interviews. Indeed, our implementation team had to contend with the consequences of not verifying a seemingly innocuous assumption. We incorrectly assumed that MRP existed solely to help generate the traditional build plan. Because a state-of-the-art build plan is not derived from the MRP plan, we assumed that the new planning process would not need the MRP plan at all. However, the materials requirements plan is needed for strategic planning activities such as identifying intelligent options for adding capacity at various bottlenecks in the supply chain. Also, without MRP, non-technical users would find it hard to visualize and understand the correlation between the demand profile and the loading profile in the build plan.

Unfortunately, we did not realize that the users needed both the build plan and the MRP plan until midway through the project. This necessitated a scope change in midstream, thereby placing additional stress on the implementation team.

Second, there needs to be complete organizational alignment on the migration to the new planning system. Criteria should be established in detail as soon as possible that put target business values in perspective. At ICBD, the high-level project scope was to replace the legacy planning system. Yet many off-line tools and processes depended on the legacy system. The natural question then was, Which dependent off-line tools do we have to replace or redesign and what surrounding business processes do we have to reengineer?

This question is much more difficult than it first appears. For example, the traditional planning process looks at the nodes in the supply chain one by one, whereas the advanced planning system considers the planning process as an integrated whole. However, because different planners own different portions of the supply chain at ICBD, they may lack incentives to adopt the required global perspective. Their inclination may be to stick to their legacy-dependent tools¡ªeven if those tools are at odds with the new holistic planning philosophy. Because we did not have early organizational alignment on this issue, some planners initially rejected portions of the new plan that ran counter to their established localized perspectives.

Certain other challenges that may arise during this initial phase also bear mention. For one, the project scope should focus first and foremost on delivering real business value instead of trying to maximize the use of the software's available functionalities. Indeed, many implementation projects run into trouble because of a functionality-driven tendency to try to get the most out of the planning system all at once. In addition, the project scope should be flexible on how to deliver against the sometimes-polarized needs of stakeholders and users, while not overcommitting one way or the other. Though this balance often can be hard to achieve, it's essential to a successful implementation.

As a guiding principle, data requirements should be tackled ahead of¡ªor in parallel with¡ªimplementation. In fact, data migration and cleanup is a critical-path activity in most, if not all, planning implementation projects.

Planning data sources often reside in distributed legacy systems that are either not linked or are inter-linked in a complex manner. Furthermore, a lack of data standardization, such as inconsistent part numbering, often complicates the situation. As the first step in data migration, data sources must be identified and evaluated against the planning engine's information requirements. Gap analysis then is conducted to ensure that the data are available to support the information requirements. Finally, database linkages need to be developed to integrate scattered planning data sources into centralized data extracts in a format compatible with the planning engine.

For the company to load the data extracts into the planning engine and then generate a credible plan, the data extracts have to be sufficiently consistent, complete, timely, and accurate.⁵ This is where data cleanup comes into play. The process includes identifying the business rules for error exception and handling, scrubbing and cleansing, and audit and control. Using these business rules, the implementation team can develop procedures and tools to support the requirements for quality data.

The data-flow diagram we developed at ICBD (see Exhibit 1) illustrates a typical plan input data-generation process. The diagram points to the two root causes of errors in the data extracts¡ªone is related to the planning data sources, the other to the data transformation processes.

As for the data transformation issue, some types of translation errors are inevitable¡ªat least in the beginning of the data transformation process. For example, even if the bill of materials (BOM) is perfect in source data tables, the BOM data extracts for some complex parts may become corrupted or "broken" because of complicated translation rules. The end-item demand for a complex part cannot be propagated all the way to the first node in the supply chain if a data link between any of the nodes is missing. When converting legacy system data feeds into data extracts, corrupted BOM data extracts can be one of the toughest problems facing the implementation team.

As a matter of fact, more than 70 percent of our overall implementation effort has been devoted to the identification, extraction, transformation, transportation, cleansing, and validation of data. We learned that when attempting to run the planning engine on a production data set for the first time, you should be prepared to see a variety of input data problems. In general, these problems can be classified into three categories: (1) incomplete or inconsistent data, (2) wrong data values, and (3) wrong data formats.

As a best practice, data-integrity routines should be used to automatically check data completeness and consistency. Data-error reports then need to be sent to the data owners. Unfortunately, the data-error reports usually cannot identify wrong data values unless those values are abnormally low or high. Even though wrong data values seldom crash the planning engine, they do affect the accuracy of the plan¡ªand thus need to be aggressively addressed. Problems with the data's format are the easiest to identify because they usually manifest themselves when the data extracts are loaded into the planning engine.

Based on our experience, we would advise against attempting to work around data-extract errors that are inherent in planning data sources. (Exceptions may be made for those errors that prevent the engine from running.) Such temporary fixes are no substitute for a formal data management discipline. Errors that are inherent in planning data sources should be communicated to the appropriate data owners, who must be held accountable for data quality assurance. Importantly, assignment of data ownership must be made an organizational priority.

The main message of this discussion of data requirements is an important, though often overlooked, one: Data control and improvement must be aggressively pursued throughout the life of the implementation project.

As with any far-reaching implementation initiative, you can expect a certain amount of organizational resistance to a new planning system. A rigorous plan validation process helps overcome this resistance by demonstrating the real practicality and value of the system before actually going live with it. Throughout the plan validation process, test plans must be executed with precision and issue logs maintained with great discipline. Shortcuts or lack of discipline in the plan validation process will ultimately stiffen that natural resistance to change.

The plan validation process consists of two parts. First, the implementation team validates the new planning logic shoulder to shoulder with the planners. This is known as the functionality test. Next, to convince the planners that the new plan is at least as good as the old one in terms of utilization value, you need to be able to compare the new plan with the old one. This process is referred to as a parallel run. This section explains the methodology we used in our functionality test. The next section explains our methodology on the parallel run¡ªthe last implementation phase before we went live with the new planning system.

The purpose of the first step in the plan validation process is to validate the functionality supported by the planning engine. The user scenarios designed for this activity should isolate functionalities to comprehensible levels so as to better predict the desired outcomes. The goal is for the scenario outcomes to be immediately obvious without detailed calculations or analyses. One way of achieving this is to limit the number of scenarios and the number of factors used in the scenarios.

Based on best practices and our own implementation experiences, we've drawn up the following list of "golden rules" for the functionality test:

• Let the planners design and run the user scenarios.
• Keep the user scenarios simple.
• Do not get hung up on the exceptions¡ªthe "corner cases."
• Compile a user scenario library.

Let the planners design and run the user scenarios. This rule is intended to give the planners a strong sense of ownership and accountability in the new planning system while overcoming their resistance to change. Even if the new system includes some user scenarios in the reference manual, these are usually generic and tailored to technical developers rather than to business users. Further, they may not address certain concerns that are important to a particular company. Just as importantly, by running a functionality test of their own user scenarios, the planners will be motivated to understand the hows and whys of the new planning system¡ªanother factor in overcoming any resistance to change. Typically, planners do not fully understand advanced planning software until they actually attempt to use it for problem solving. Put another way, this approach manifests the concept of "learning by doing," the most effective mechanism of organizational learning.⁶

Keep the user scenarios simple. The second rule is intended to help you interpret the test results in a meaningful way. As the user scenario becomes more complex, it becomes increasingly difficult to calculate the expected outcomes by hand. Perhaps even more importantly, the intuitive connection between the business case and the outcomes can be easily lost in the more complex scenarios.

Do not get hung up on "corner cases." This rule is based on the reality that no planning engine is bulletproof. No matter how robust the solution algorithm, it cannot guarantee an optimal solution in each and every case because the business rules incorporated in the planning engine involve tradeoffs between objectives. In fact, many of the objectives may conflict with one another. If some reasonable user scenarios do fail the functionality test, they either should be resolved in the model or monitored¡ªdepending on the urgency and importance of the situation.

Compile a user scenario library. The fourth rule is designed to facilitate organizational knowledge. Insufficient documentation can lead to "circular efforts" such as asking the same question over and over again. A user library that documents the different scenarios tested and establishes baseline assumptions is especially important in a highly cross-functional implementation project.

The planners at ICBD have designed more than a dozen user scenarios for testing the functionalities of capacity balancing, capacity smoothing, alternative routing, layered demand, binning, lot sizing, material flow policy, on-hand inventory, time-phased yield, time-phased capacity, and more. They are satisfied that virtually all of the user scenarios have passed these functionality tests in the first pass, a situation that significantly boosts their confidence in the new planning system. Because the planners are able to design their own scenarios, the seemingly mundane functionality test has become a fun experience for both the implementation team and the planners.

Parallel run is the process of running both the old and new planning systems on actual production data and then comparing their output. In addition to simulating the live planning environment, this activity gives stakeholders and users greater confidence in going live with the new system. We will first discuss the methodology used and lessons learned for our MRP test and then do the same for our build-plan validation.

Because the traditional and state-of-the-art MRP plan generation processes are the same, it made sense to compare both plans directly. Under certain circumstances, however, the MRP logic is not as simple as one would think. Unfortunately, our implementation team did not realize this intricacy until midway through the parallel run. Because MRP was considered to be so simple, we spent most of our initial effort on testing the linear programming module of the planning engine. But after we found that the MRP logic provided by the software vendor ignored WIP (work in process) on the secondary routes, we had to redirect most of our activity to fixing this problem. This turned out to be a painstaking and difficult exercise because of the considerable bookkeeping involved. The lesson learned here is don't take seemingly simple things like MRP for granted. The discipline of following a rigorous test plan is essential to getting the implementation project on the right track.

After making sure that the old and new planning systems do employ the same MRP logic, you can compare the plans in a straightforward fashion. If they do not match, the most likely reason is that the two systems do not have the same data feeds. For example, one data team member accidentally changed the forecast data extract by adding one second to demand due date. To illustrate, April 1, 2000, was represented as "04/01/2000 00:00:01" in the forecast data extract. Somehow, because of this extra one second, the forecast demand data could not be loaded correctly into the new planning system. Small problems like this can actually take hours to debug. The lesson learned here is that you cannot be certain that the data feeds are clean until the final test is complete. Again, data control and improvement are critical throughout the life of the implementation project.

Now we turn to the validation methodology for the build plan. The traditional build-plan generation process is more art than science, while the state-of-the-art build-plan generation process is more science than art. In this sense, it is hard to validate the new build plan simply by comparing it with the old one.

Based on best practices and our own experiences, we advocate a discrete test approach that progressively shows that the new build plan is a reasonable refinement of the MRP plan. Because the MRP plan is well understood by the planners, it can serve as a baseline for validating the new build plan. Furthermore, because the new MRP plan and build plan are generated by the same planning system, they presumably both have the same format, which facilitates comparison considerably.

Let B1 represent the new build plan without capacity constraints and B2 represent the new build plan with capacity constraints. Denote the new MRP plan by M. The goal is to prove that B2 is a reasonable refinement of M. If we can verify that B1 is a reasonable refinement of M and that B2 is a reasonable refinement of B1, then we can state that B2 is a reasonable refinement of M. Note that the validity of M presumably is already established in the MRP parallel run.

Recall that the goal of MRP is to maximize on-time delivery with minimum inventory, which is the same as the goal of the build plan. The MRP plan, however, does not reconcile demand/capacity imbalances as the build plan does. Therefore, in the absence of capacity constraints, the MRP plan is optimal. As such, you might expect B1 to be exactly the same as M. However, as explained in our discussion of the plan generation process, the state-of-the-art planning system makes certain simplifying assumptions in the linear programming module that may require some fine tuning.

After we show that B1 is reasonably close to M, we add capacity constraints to see how they change B1. We often think of a constraint as one number that says we cannot consume more capacity than what is available. In practice, however, there are usually three capacity numbers: available capacity, minimum capacity, and upside capacity. The minimum capacity and upside capacity constraints are generally hard constraints, while the available capacity constraints are normally soft constraints. (Hard constraints generally are physical in nature and must be followed; soft constraints are man-made rules that can be changed if necessary.) After we show that B2 is reasonably close to B1, we can safely say that the new build plan does what it is intended to do.

During the plan validation process, you need to pay close attention to user interface requirements. A good plan is one that gets used. A plan that doesn't get used¡ªno matter how optimal¡ªcannot be considered a good plan. Without a good user interface, the planners will have a difficult time transitioning to the new planning system. To satisfy various user interface needs, the plan should be designed so that its output is saved in a relational database that end users can gain access to through database-query software. The graphical user interfaces offered by software vendors often are much slower and less configurable than database-query software. Furthermore, the plan output has to be combined with some additional information from the planning database to make it usable for the planners.

Once the planners endorse using the new planning system, the project's first business release (BR1) officially comes to a close. This by no means signals the completion of the implementation, but it is the most important milestone in a multiphase effort. The project now enters into a period of stabilization during which the planners concentrate on delivering high-quality plans under the new system. At this point, the implementation team starts to look forward to the next phase. It reflects back on BR1 and discusses what to preserve and what to change in BR2 and beyond. The legacy planning system should remain in place during the stabilization period as a reference point for the new planning system as well as a backup in case of any unforeseen difficulties.

Implementation of the planning software is just one of several supply chain initiatives that have been taking place at Agilent's Integrated Circuits Business Division in the past few years. Other efforts include inventory-reduction programs like vendor-managed inventory (VMI), data warehousing projects for improved data quality, enhanced demand forecasting methods, optimized safety-stock calculations, and targeted supply chain metrics. Although it's difficult to isolate the impact of any single one of these initiatives, collectively they have produced some impressive results to date, including:

• Reduced planning cycle time. (The new planning software is at least 50 times faster than Excel.)
• High on-time delivery rates (consistently over 95 percent and often reaching 99 percent).
• Lower inventory levels at all points in the supply chain.
• More efficient capacity utilization of the supply chain.
• Higher-quality planning data. (Because the new planning software has stringent data requirements, data quality must be upgraded before the information can be used in the software.)

Reflecting on the lessons learned and successes recorded, we keep coming back to the three-legged stool analogy introduced at the beginning of this article. That is, to ensure a successful planning system implementation, all three legs¡ªthe data, the business process, and the systems¡ªmust be firmly in place. It's true that strengthening one leg can drive improvements in the other legs. But it's also true that implementation will be stalled until all the legs are equally sturdy. The data, business process, and systems do not have to be built up simultaneously, but they all must provide stability.

Adherence to this principle increases the probability of a successful implementation from a technical perspective. Yet a supply chain planning software implementation will test an organization in myriad ways that are not purely technical. The organizational commitment from the stakeholders and users is critical to the project's success. The challenge is to engage the stakeholders and users without compromising the rigor necessary in the software testing and validation. With the technical and organizational components in place, the implementation project is well positioned for success.