When products such as mobile phones can become obsolete in less time than it takes the supply chain to move them from drawing board to store shelf, it is clear that producers cannot succeed unless they plan and execute their supply chain operations with great precision, speed, and flexibility. In such cases—and they are increasingly typical—there is almost no margin of error for big shifts in demand, let alone for serious supply chain disruptions.

Yesterday’s sequential, inflexible manufacturing resource planning tools have long since ceased to be effective for managing supply chains of any size or complexity. They have given way to advanced planning and scheduling (APS) solutions whose sophisticated algorithms can ensure that raw materials and production capacity are optimally allocated to meet demand.

Designed to address complex trade-offs between competing priorities—between meeting a tight delivery window or adding a shift, say—APS tools have existed as a distinct class of applications for more than 10 years. They are offered by best-of-breed vendors as well as by the enterprise resource planning (ERP) giants such as Oracle and SAP. They are purchased by almost all mid-sized and large manufacturers. Implementations take from nine to more than 18 months, and then require more time for the business to start seeing the benefits.

APS solutions pave the way for broad operational changes such as sales and operations planning (S&OP) or lean supply chain initiatives. When properly deployed, APS can improve supply chain operations significantly, as gauged by traditional measures such as inventory and customer delivery performance. One electronics company, for instance, found that with APS, it could respond to customer order demand and determine the impact on the supply chain in a matter of minutes versus the previous response in a week. On-time delivery improved as much as 15 percent as a result.

But the key word here is “properly.” APS deployments have often garnered negative publicity for their failures, and many more failures no doubt remain undisclosed. In our experience, most companies are likely to encounter a set of common challenges regardless of whether they are considering APS solutions for the first time, extending them, or re-implementing them (and even though they may have ample assistance from a vendor or a systems integrator). In this article, we describe the peaks and valleys of typical APS deployments and identify effective strategies for anticipating and tackling these common challenges. In addition, an accompanying sidebar spotlights a company that successfully rolled out an APS solution in only six months.

APS deployments typically follow a well-defined pattern, with predictable periods of difficulty that we call the three “valleys of despair” (See Exhibit 1). Minimizing those valleys and maintaining the momentum of the deployments are the keys to ensuring that the solution ultimately delivers the intended benefits.

The first crisis usually surfaces right after the design phase. The second occurs in the period immediately before and after the go-live event. The third emerges after the solution has been in use for some time. What leads to each of these crises and what can you do to avoid or minimize their impact? Let’s look at each crisis point in turn.

Users meet the first valley of despair when expectations collide with reality. APS deployments are usually based on a compelling business case and backed by significant investments in software, hardware, and resources. It is typically the business users who identify the need and initiate the search for an APS solution, although it is not unheard of for an IT organization to lead the charge. Evaluation can take three months or more; licensing costs can run into several millions of dollars.

However, as the implementation transitions from the design phase into the first conference-room pilot, trouble strikes. When the solution is run for the first time with a production data set, the project team is likely to get an unwelcome surprise: seemingly unintelligible output, often accompanied by system performance problems. In one implementation we were involved with, the first few attempts at running the application with a full volume of data resulted in run times of over 24 hours—with no results to show for it.

The gap between anticipation and reality is large. Executives and everyday users alike have high expectations (“this will solve all our problems”) that are often based on promises made by solution vendors. But in most cases, the vendor and systems integrator (SI) will be doing exactly what was asked of them. The problem lies with the interpretation of the results.

Discouraged, the project team struggles to determine whether the solution is functioning correctly—and then incorrectly concludes that it isn’t. When this period of uncertainty lasts too long, the project runs the risk of losing priority or of being cancelled outright. Users continue with their legacy tools and processes, and the business fails to achieve any benefit from its sizeable investment up to this point.

In fact, in most cases, the solution does work exactly as it was designed to, but the APS output at this stage is difficult to interpret because of three factors: complexity of the underlying model, poor data quality and the team’s lack of familiarity with the solution’s algorithms and rules. Moreover, those factors tend to interact with each other, making it extremely difficult for the team to diagnose the root cause of any specific problem. Each factor merits a closer look.

1. Complexity of the Underlying Model. APS solutions belong to a broader class of applications often referred to as decision support systems. These differ from transactional systems, such as ERP, in several key aspects (see Exhibit 2).

One of the most important distinctions is that APS solutions model business reality through some level of abstraction and data aggregation instead of creating an exact representation. For example, when modeling a final test facility at a semiconductor plant, APS planning solutions often represent the capacity availability of a group of similar testers by using one representative tester’s capacity as the proxy for total capacity of all the testers. This as opposed to modeling each individual tester and its available capacity. Translating a business problem into a model with the right level of abstraction is as much art as it is science: Too much abstraction and the results may be too far removed from reality to be of any use. Too little abstraction and the system may grind to a halt given the complexity and data volume required for the model.

The choice of the model must be appropriate for a company’s particular operations strategy. Consider the examples of two companies with very different requirements for supply planning. The first, a consumer electronics company, had fully outsourced its manufacturing and had mature, trust-based collaborative relationships with its contract manufacturers. Although its chosen APS tool could model multiple levels in the supply chain in great detail, the company decided that all it needed was planning based on a single supply commitment from the final assembly level. This decision resulted in a simple and easily manageable planning model with relatively low data requirements that could be implemented quickly.

In the second example, a fabless semiconductor company had a less collaborative supply chain and could not count on any one contract manufacturer to provide a complete picture of supply capability. The company also experienced frequent capacity and material constraints and had to manage material allocation between its contract manufacturers. This required the management team to gain visibility and control that extended deep into the supply chain. Consequently, the company decided to include all of its suppliers across multiple stages of manufacturing into its planning model. The resulting model was more complex, more data-intensive, and more sensitive to data quality than the model in our first example. For these reasons, it took longer to implement and required more effort to maintain. However, it gave the company’s supply chain managers the requisite amount of control over their supply chain operations.

Both APS implementations were appropriate to their circumstances. Yet when designing the model for an APS solution, project teams tend to focus on meeting a long list of stakeholder functional requirements. They often lack the time to work through the nuances of alternate model designs and their implications. It is challenging enough to define a model that best supports the company’s operational strategy. It is even more challenging to configure this model into the APS solution in a way that minimizes data requirements while maximizing output quality.

Not surprisingly, inexperienced teams tend to replicate legacy business practices in the new APS solution as well as add unnecessary complexity. They might, for example, insist on adding complex functionality to a demand planning application to publish a forecast at the weekly level—even though the entire demand planning process occurs at a quarterly or monthly level (because their current tool does so).

Successful deployments allocate sufficient time up front in order to consider the pros and cons of alternative models. The project teams carefully weigh the costs and benefits of adding complexity to their APS models. To that end, they often form a modeling team under the APS project umbrella to “own” the company’s approach to solution deployment. In our experience, such a modeling team is most effective when it exists within the supply chain organization rather than IT. Moreover, the team should report to an executive who is senior enough for the team to be able to support multiple functional groups without conflicts of interest. The members of this team—including titles such as supply chain architect and master data manager—will typically report to a supply chain director or vice president. Often they are former planners. They understand the business requirements as well as the process of modeling these requirements in specific APS solutions, and they take an active role in driving the model design decisions.

2. Data Quality. APS solutions typically require some data elements that have not been used before or that are in a form different from the data being used by transactional systems. For example, the work in process (WIP) tracking system for a semiconductor manufacturer may track individual wafers in each lot at each step of the wafer fabrication and sort process, but a planning model may require a time-phased schedule of the total quantity of good die expected to be received at the end of the sort operation from all the wafers currently in WIP.

Problems with data quality will compound any APS model configuration issues. Consider the case of a semiconductor company implementing a supply chain planning solution. The planning model represented the major stages of semiconductor manufacturing at an aggregate level and called for WIP to be represented at the end of each stage, with appropriate due dates. The company’s manufacturing execution system (MES), the source of all WIP data, had been heavily customized over many years and contained many non-standard representations of product routing. For example, the same manufacturing step definition was used for representing an operation at both an internal and external facility. But that made it tough to determine which facility was under discussion without the use of additional information such as the part-naming convention.

The IT team did not know all the customizations in the MES, so the initial data extracts grossly underestimated WIP and positioned the in-process inventory incorrectly in the planning model. This caused the planning tool to suggest significantly increased starts across all stages of manufacturing.

For users already struggling to understand the planning model, this only served to increase their distrust of the solution. It took many weeks of troubleshooting, plus development of extremely detailed mapping logic in the interface between the two systems, to minimize the errors. This led to delays in the overall implementation schedule. It took several more weeks after that to regain user confidence, and the effects of the experience still lingered well past go-live, adversely affecting user adoption. The APS system was being run in the production environment, but users remained wary and demanded proof that the outputs were correct for months after the go-live event. Inexperienced teams tend to grossly underestimate the effort required to identify and resolve data issues. They also delay tackling the problem until they are already deep in the first valley of despair, where they end up being overwhelmed by the magnitude of the problem.

Successful implementations recognize the importance of data quality as well as the need for a thorough understanding of the data usage within the model. To that end, these projects create a “data quality” team that works closely with the modeling team to identify and resolve data issues from the start. Successful teams also leverage the APS solution itself as a diagnostic tool to quickly identify data issues; some problems can only be detected by running the data through the model. Iterative cycles of model and data testing during development help to minimize the magnitude and duration of the first valley.

3. Lack of Familiarity with APS Algorithms and Rules. Many APS solutions use a variety of mathematical algorithms and solution techniques to solve complex supply chain problems. An early understanding of the underlying APS solution technique is critical. Without it, a company may make key design decisions about the model only to run into a host of problems later, such as inability to configure the design into the solution, serious system performance issues, and difficulty in interpreting results. As a result, many deployments waste precious time and resources redesigning the model or customizing the solution to fit the model.

Consider supply planning solutions. In very general terms, supply planning “engines” fall into two major categories: optimization-based and heuristics-based. Optimizers typically formulate the planning problem as a single holistic mathematical model, such as a linear programming model, to arrive at the optimal solution. Modeled correctly and at the right level of detail, these engines can produce high-quality solutions. However, the underlying models and solution techniques can be extremely sensitive to model complexity and data. They can encounter significant performance issues and may arrive at seemingly counter-intuitive solutions if not modeled with care.

Heuristics-based engines, on the other hand, typically solve the overall planning problem as a series of smaller problems using various business rules and simpler algorithms. The specific set of heuristics used in a given APS solution is usually proprietary to the vendor. The solutions arrived at by these engines, while not guaranteed to be optimal, tend to be feasible and more easily understood than an optimized solution. However, they often require a large number of parameters or business rules to be configured, and the quality of the solution may suffer if not configured with care. Business users must carefully consider the solution methodology when selecting an APS solution and when making model design decisions.

At the companies that manage to launch successful deployments, supply chain managers recognize the need for deep familiarity with the algorithms and solution approach of a given APS solution. They send members of their modeling team for extensive training on the solution before the design phase. This not only ensures that the right model design decisions get made but also provides the expertise to interpret the solution’s output, thus minimizing the impact and duration of the first valley of despair.

The second valley of despair emerges when the solution moves into production. The new solution has gone live and is technically operational. Yet the business users—the supply or demand planners in the supply chain organization—find it difficult to interpret the output. Much like the implementation team earlier, they are confused by the planning model and the behavior of the APS solution. They are also unprepared to deal with the sheer volume of data presented in the solution. After some struggle, many tend to revert to the comfort of familiar spreadsheets and abandon the solution altogether. Even deployments involving fewer users and smaller scope tend to suffer from the same user-adoption issues if the root causes are not addressed.

There are two reasons for this. First, the implementation team’s performance is measured by near-term project deadlines rather than medium-to-long-term user adoption of the solution. And companies often are overly optimistic in their estimates of user adoption rates. It’s typical for the implementation team, which has the best understanding of the solution at this point, to be disbanded shortly after the go-live, leaving the users with limited support and no place for questions.

Second: User training is often relegated to the software vendors that typically provide only off-the-shelf packaged training. Such training focuses on application navigation but not on the specific manner in which the solution was modeled to represent the company’s business. Further, the training is typically provided by individuals not directly involved in the deployment and thus without an understanding of the design choices made or the reasons for them. Consequently, users are left without the requisite knowledge and skills to utilize the APS solution effectively.

Successful deployments recognize the need for comprehensive training of users. They extend the training well beyond the system basics and navigational skills to ensure that all users understand the underlying model design and its representation within the system. In our experience, a three-phase approach to training can be very effective for minimizing the second valley of despair:

• Phase I: Before the beginning of the design phase, members of the deployment team, especially those in the modeling and data quality teams, are given basic and advanced training on the APS solution by the vendor. This enables them to develop the model that meets the business requirements, leverages the solution’s unique capabilities, and minimizes complexity to the extent possible.

• Phase II: Just prior to user testing of the solution, the user community is provided with training in basic tool navigation and usage by the vendor. This enables the users to conduct testing of key system modules and functionality.

• Phase III: In the weeks leading up to the go-live, the modeling team provides a comprehensive training session for the entire user community on the specific model implemented along with its inputs and usage. This prepares the users to make the best use of the new solution. The key here is that since the business objectives and operating structure vary from company to company, it is the modeling team and not the vendor that is best suited to deliver this training.

The last valley tends to develop as business conditions change, after solutions have been successfully implemented. That was the situation facing integrated device manufacturers in the semiconductor industry whose operational strategies shifted from captive manufacturing to outsourced fabless models. When their facilities were shuttered, existing planning practices became obsolete and the chip makers had to rapidly develop new planning models to communicate demand and supply with their external business partners. The models in their APS solutions had to be quickly updated to reflect the new operational reality.

All companies experience changes in their product structure, supply chain networks, constraints, business practices, and other operational variables over time. For example, the addition of new manufacturing sites or distribution centers typically requires new information such as sourcing rules, lead times, and parameters for APS solutions. However, business users don’t always fully understand how such events affect the APS model and its output, and they fail to update their APS solutions in a timely manner. Consequently, the models begin to “drift” away from business reality while users attempt to fill the gaps with ad-hoc reports and spreadsheets.

Left unattended long enough, APS solutions cease to be relevant to the business and become mostly or completely supplanted by manual, spreadsheet-based processes. Soon, the existing solutions are declared ineffective and decommissioned. Shortly thereafter, spreadsheet-based processes are deemed inefficient and the entire APS deployment cycle begins anew—often with different solutions.

Successful deployments recognize the need to protect the heavy initial investments made by making continuous small investments to support the APS solutions over time. They do this by evolving the role of their modeling team to provide ongoing support, continuity, and a single point of ownership. As business circumstances change, the APS team works with the user community to update the APS solutions in order to keep them relevant to current business needs.

Granted, it may never be possible to completely eliminate all three valleys of despair when deploying APS solutions. However, by correctly diagnosing their current problems and anticipating the challenges ahead, companies can mitigate the impact of these predictable difficulties and steer their projects to success.