Identifying the ROI of a Software Application for SCM Part 3: Performing the Data Analysis

  • Written By: Mark Wells
  • Published: July 17 2001

Identifying the ROI of a Software Application for SCM

Executive Summary   

The competitive environment for every industry grows increasingly intense. Fast, reasonably accurate information about the impact of a software investment decision grows more critical. Many decision-makers look for an exact forecast of return on investment (ROI) from the purchase of a supply chain management application. At least four very real challenges make such perfect information elusive. Commonly, executives meet these challenges with responses that are not carefully considered. The challenges and the corresponding reactionary refrains are as follows:

  1. Limited time exists to perform analysis - "We need to know now!"

  2. Business analysis skills are lacking - "We are looking for the vendor to tell us!"

  3. The data to perform the analysis are almost always not available in the corporate databases - "We have tons of data, but we don't have it broken down like that."

  4. It is always difficult to predict the future … like forecasting, certain laws about a prediction of ROI will forever hold true…

    • the prediction will always be wrong

    • the prediction will always change for as long as the analysis continues

    • someone is going to be held accountable for the prediction

    - "Just give us the bottom line!"

After a quick look at these issues, one might question the effort to undertake the analysis to predict an ROI, as well as the validity of the outcome. Perfect, or even complete, information may not be feasible, but if a few basic principles are followed, some analytical work can provide an understanding of the potential for bottom line impact. It can also yield insight into the root causes of undesirable symptoms from which your business may be suffering.

The reactions of some decision-makers to each of the four challenges that are listed above provide a convenient outline for exploring a more thoughtful and strategic approach to evaluating a potential investment in supply chain management software.

About This Note: This is a four part note, each part addressing one of the four challenges.

Part One covered "We need to know now!"

Part Two covered "We are looking for the vendor to tell us!"

Part Four contains links to the prior parts.


Part 3. "We have tons of data, but it is not telling us what we need to know."   

Performing the Data Analysis

If the data exist, you need to trace a symptom, like excess work-in-process (WIP) inventory, to the root cause such as forecast error that drove production of the wrong product. Once that is done, then powerful, but relatively simple analysis can be performed by collecting the data from the data warehouse, or wherever it is stored, by putting it into a spreadsheet and then creating a cumulative distribution (see Figure 1) of the symptom by reason code.

Figure 1.

More commonly, however, the data cannot be readily segmented by root cause. This is probably because the symptoms and the root causes have not been identified and linked. Using a simple fishbone diagram (see Figure 2), a few folks who know the business processes involved can probably identify symptoms and trace them to possible root causes. Naturally, a skilled facilitator (possibly a consultant) will help, but you can also learn by reading up on the idea1 and by doing it.

Figure 2. Cause and Effect (Ishikawa or fishbone) diagram with potential root causes marked with capital letter reason codes.

Click here to view larger image

Once the root causes have been identified, then a system of recording the incidents by reason code has to be put in place. In some cases, while occurrences will not be tied to a reason code or other explanatory data, there will be some data that can be used as an approximate surrogate to estimate the order of magnitude of the root cause. In those cases, you can get to an answer sooner, albeit a less precise one.

As an example, forecasting may be coming from sales. You can probably measure the accuracy pretty well by saving the forecast and then by comparing it with orders or shipments. What is harder to determine is how much better your purchasing, manufacturing and distribution would have been if forecasts were 50% more accurate, or what the bottom line benefits would have been. But by making some observations like how often a job had to be interrupted to start another one based on a canceled order or a forecast that was wrong, you can begin to build a collection of data that will be the foundation for answering that question. Then, by creating a cumulative distribution that shows the schedule changes by reason code, you will get an understanding of the size of this problem. Both inventory turns and customer service will go up if you can create a plan that is more flexible, responsive and accurate by attacking the root cause. That root cause might very well be the fact that visibility into the future demand ends with your enterprise. Additional information may be available from your customer, but you do not have access to it.

A basic production/operations management text such as will probably help. One good author is Stevenson whose text has been published by Irwin.

Refine Your Forecasting   

By using software tools that help you forecast and work together with others inside your organization, and even with your customers, the forecasts may become more accurate. You can make an assumption on how much improvement might be possible. Then, hypothetically, reduce the schedule changes due to forecast errors by that amount. Research average WIP and reduce that by the same factor. Put a procedure in place to track premium shipments that are paid by your company by reason code. Take the premium freight that is caused by bad forecasts to the bottom line.

Then, since you made an assumption that forecasts could be 50% more accurate, you will need to perform some sensitivity analysis. Vary the 50% and see what the results tell you. This kind of simulation model can be created with a spreadsheet tool.

Data Analysis Challenge Summary   

Borrowing the Pareto and Ishikawa tools from TQM practices can help you find data and create information that you did not know was there, but the speed with which this kind of analysis can be performed increases with the availability and accuracy of data. Recent developments in software that support data warehousing, activity based management (ABM) and business scorecard metrics, as well as cause and effect relationships, can enable ongoing evaluation and direction of a given investment decision. In addition, activity based costing (ABC) can provide detailed actual costing data that may increase the breadth and depth of decision support from a supply chain management application.

This concludes part three of a four part note.

Part One covered "We need to know now!"

Part Two covered "We are looking for the vendor to tell us!"

Part Four contains links to the prior parts.

About the Author   

MARK WELLS has extensive experience on many aspects of supply chain management from within the industry, as a supply chain consultant, and as part of a software development organization. He has CPIM certification and an MBA from Drexel University where he has also taught operations management and operations research. He currently works for the applications development division of Oracle Corporation, focusing on supply chain planning.

He can be reached at

comments powered by Disqus