I’ll highlight the roadblocks that supply chain initiatives typically face so you can avoid a bad case of corporate fainting spells. Table 1 summarizes proposed solutions for each of these mistakes. These mistakes in supply chain optimization are driven by the need to show quick results at the lowest cost possible. Let’s look at each of these mistakes in detail.

Mistake 1

Lack of balance between long-term vision and short-term accomplishments. Supply chain transformation efforts are typically associated with tight budgets, aggressive targets, and high expected returns on investment (ROIs). In some cases, companies want the effort to be self-funding via the anticipated savings. As a result, there is a tendency to strive for short-term quick wins. The sense of urgency is understandable because the initiative can translate into success for the business. On a personal level, project members may get tangible (financial bonus) and intangible (good reputation) rewards for successful project delivery.

Short-sighted project planning typically ends up with a project that yields short-term gains offset by long- term losses. Consider the case of an initiative to lower transportation costs by integrating a transportation management system with the legacy system. In the short term, the quickest way to deliver the solution is to build and deliver a proof- of-concept (POC) pilot.

In most cases, the approach involves focusing on the pilot success without consideration for other factors, such as scalability, IT and business support requirements, integration with the existing landscape, alignment with strategic objectives and key performance indicator (KPI) targets, and the total cost of ownership (TCO) over the strategic planning horizon of the enterprise.

It is common for companies to create supply improvement projects on an ad-hoc basis driven by self-directed teams with limited or no project methodology. What’s more, these projects typically emphasize optimizing the KPIs of the sponsoring department. The end result is that quick gains are achieved at the expense of other parts of the organization.

Going back to the example of a transportation management implementation, in the short term a successful POC shows that the system meets business requirements under a particular set of assumptions. In this case, Joe, the supply chain initiative manager, calculates the ROI based exclusively on extrapolating the results of the pilot.

Joe is a highly experienced transportation manager. His functional background and experience make him suited for managing this project. His technical background, however, is relatively weak. His understanding of systems integration is limited — he sees integration as an IT function he doesn’t have to worry about.

The initiative fails as he rolls out the project to the rest of the company because his short-term objective was to deliver the POC pilot. He encounters many unforeseen obstacles. The end result is that although he had a successful pilot, his initiative failed to gain momentum. The project is ultimately shelved.

Solution

Let’s look at what happened by breaking down the analysis to four areas: process, people, strategy, and technology.

• Process. In the short term, objectives were met. The pilot ran well with data loaded manually. Although Joe knew the data would come from the legacy system, his assumption was that interfaces would handle the integration with the legacy system. This assumption, though, proves to be incorrect. The interfaces add additional functional steps the users did not expect. The users were expected to troubleshoot interface exceptions. This exception management exceeded the ability and patience of the end users.
  
  
• People. In the short term, the pilot had successful buy-in from the user community. Testing was based on manually loaded data. However, Joe didn’t perform an end-to-end integration with existing interfaces. This resulted in the end users slowly withdrawing from using the system.
  
  
• Strategy. Joe was unaware of the system performance implications of interfacing the transportation management system with the legacy system. The result is that response time exceeds minimum service levels due to system landscape constraints. Joe also realizes the maintenance of his new solution is IT resource intensive and not scalable.
  
  
• Technology. Upon getting into the details, it becomes apparent that interface complexity slows system response time. In addition, as mentioned in the process section, the temporary interfaces are difficult to troubleshoot and not well documented. Users give up on using the new system and revert to manual workarounds. Business KPIs show a dip in performance — project momentum is lost and it is shelved.

So what is the solution? Supply chain transformational projects should have a well-defined methodology that ensures solutions add value at the enterprise level. It should include a balanced supply chain scorecard for every initiative that analyzes and provides visibility on the expected ROI over the project’s life.

Table 2 shows a sample project ranking scorecard that balances the ROI with the required alignment. Here Joe has two options — he can implement a non-SAP transportation management system or he can implement SAP Transportation Management (TM). The non-SAP transportation management solution does not offer integration to the legacy SAP system, whereas SAP TM does. The scorecard shows that although the SAP TM option has a lower ROI based on Joe’s pilot results, it ranks higher because it takes into consideration all the required factors for success.

Mistake 2

Silo vs. network reward systems — resolving the risk associated with reward conflicts within the enterprise. Many corporations are moving to a decentralized management model to react faster to the competition. As a result, the reward structure favors silo mentality, which focuses on optimizing the operation at the enterprise’s expense.

For example, the IT department attempts to show project savings by skipping stress testing for Advanced Planning and Optimization (APO). The rationale is that the hardware sizing exercise was performed early on during the visioning/planning phase and there is no need to waste time, resources, and budget over stress testing. The IT department may even rationalize that if performance is slow, it can address the issue post go-live.

This type of silo mentality translates into potentially long-term damage. The end result is the realistic potential for unacceptably low system performance, frustrated users, failed planning runs, missed delivery schedules, and overall poor business performance.

Solution

This is another example in which integrated project methodology is a key to success. The methodology must align strategy, process, people, and technology. In the case of the stress testing example, the project methodology must include an approach to quantify risk associated with silo thinking.

Magnitude and probability are two key aspects of risk. A quick way to assess the magnitude is to visualize the worst-case scenario and assess the impact to KPIs. You quantify this impact in terms business process owners understand. For example, if daily transaction volume is 8,000 lines per day and the risk assessment quantifies potential post-live exceptions at 10%, then the manual intervention on 800 lines per day, 16,000 lines per month, at x dollars per line, will overwhelm the users, have a significant impact on the project budget, and above all, unfavorably affect customer-facing performance.

Table 3 provides an example of a risk matrix that balances risk magnitude and probability to prioritize timely corrective action. The matrix quantifies the magnitude of the risk in financial terms. The end result of the matrix is an increased sense of urgency to prioritize corrective action. You create the matrix in three steps.

Step 1. Identify the risk areas. Risk is defined as variability in expected outcome. As a rule, you should list any risk that could have an impact on the company.

Step 2. Identify the magnitude and the frequency of the risk. How far does the risk reach and how often could it occur?

Step 3. Quantify the financial impact on the business. Companies can use the matrix to evaluate their options relative to project resources, scope, and time line.

Mistake 3

Irrational focus on tool-based solutions. You need a balance between low-cost procedural changes and high-impact tool-based improvements. You may have seen situations in which management invested heavily in a technology solution only to realize that relatively simple procedural changes would have resolved 80% of the problem.

For example, a business having issues with bad planning runs within SAP ERP Central Component (ECC) 6.0, could be tempted to invest in APO functionality to resolve the issue. Before the company implements APO, it needs clean master data. To ensure this, the company must clearly define the business policies and procedures that relate to creating and maintaining material masters.

Solution

Understand the root cause of the problem before implementing new technology. The solutions cover the spectrum from simple procedural changes to advanced, highly integrated tools that deliver improved enterprise performance.

Figure 1 shows that your target KPI improvement is 20 points from its historical average. It also shows that the proper combination of low cost procedural changes and technology should deliver the expected results.

Figure 1

KPI improvement solutions

In the example in Figure 1, a company examines its procedures for creating and maintaining master data. The procedures specify the trigger for a material it creates. For every trigger (say, a basic view created by the engineering department), the procedure specifies the appropriate follow-up action. In this case, this is the material master update required by each functional department (e.g., sales, accounting, planning, and warehousing). Depending on the volume of master data objects, you can create this update either by performing a simple manual check using standard ECC transactions (e.g., MM60) or you can create a sophisticated custom workflow.

Going back to the example of planning runs, once you rule out master data as the root cause of the problem, then procedural changes relating to managing typical business exceptions are appropriate. The typical scenarios include production line downtime, supplier delivery non-compliance, and unplanned demand.

In most cases, ECC standard functionality supports the processing of these typical exceptions. After you achieve this level of stability (master data process works and procedures are in place), the complexity and volume of the business may call for the use of optimizers and advanced technology provided by APO. Note how the systematic, disciplined approach to troubleshooting and corrective action ensures the enterprise invests in technology that adds true value.