Skip to content

Moving Beyond Predictions – Second Order Analytics

Last month, I wrote about why simply making predictions isn’t enough to drive value with analytics. I made the case that behind stories of failed analytic initiatives, there is often a lack of action to take the predictions and turn them into something valuable. It ends up that identifying and then taking the right action often leads to additional requirements for even more complex analyses beyond the initial effort to get to the predictions! Let’s explore what that means.


Once I have a prediction, simulation, or forecast, the next step is to identify what action is required to realize the potential value uncovered. Let’s consider the example of using sensor data for predictive or condition based maintenance. In this type of analysis, sensor data is captured and analyzed to identify when a problem for a piece of equipment is likely. For example, an increase in friction and temperature within a gear might point to the need to replace certain components before the entire assembly fails.

Identifying the problem ahead of time sounds great. All we have to do is to identify when something is going to break and then fix it before it breaks. Doing so saves money and allows us to avoid unplanned maintenance downtime. We’re ready to move forward, right? Wrong! It can be a complicated process to identify how to best execute the repair.


I had a discussion on this very topic with a senior executive at a large aircraft manufacturer. He was discussing the complexities of managing maintenance in an assembly facility for equipment that costs tens, if not hundreds, of millions of dollars. His point was that his team is now able to identify the need for certain major repairs well in advance. That’s great – and it helps them make their products safer, more reliable, and cheaper over time. However, he also lamented the difficulty in determining the best way to actually interrupt planned processes to make the repair.

Let’s assume that a component on the assembly line gets flagged as likely to break in the next 60 days. The good news is that replacing the part proactively can save millions of dollars and there is plenty of lead time to make the repair. The bad news is that choosing when to make the repair isn’t a simple exercise. My client explained that his team’s decision process has to take into account a wide variety of factors:

  • How likely is the part to fail sooner rather than later in the window identified?

  • What orders will be interrupted or delayed depending on which date and time the line is taken down for the repair?

  • What are the contractual terms for the various upcoming orders that depend on the assembly line?

  • Which scheduled facility outputs are a critical path to other major activities and which are not?

  • When is downtime already scheduled for other reasons?

  • And more…

In the end, it is necessary to do an entire second layer of analysis to determine the best time to actually make the repair. Causing a delay on a critical order for a major customer with strict contract terms guaranteeing delivery could end up costing as much or more than the money saved by an early repair. On the other hand, a slower day where the assembly line is creating components of a less critical order where a day or two of delay will not matter is an ideal time to make the switch.


The decision of when to act to make the necessary repair really becomes an optimization problem that balances the increasing risk of failure as days pass with the costs associated with a repair at any point in time. Waiting a bit longer and taking a bit of extra risk could be much more profitable in the long run. However, it requires an entire second layer of analytics to figure out when that optimal repair time is.

In my client’s case, the complexity of the secondary analytics to act upon the results of the predictive maintenance models wasn’t fully understood and accounted for up front. He felt that his organization had certainly saved some costs in their initial efforts by making repairs at the first feasible moment. However, it quickly became obvious that there was a lot more value to be captured if they could not just predict failure, but also identify the best time to make the repair.

The lesson here is that capturing the maximum value from analytics can be hard in situations where complex, large scale business problems are being addressed. Moving from a prediction to an action is a necessity. However, you may also require additional layers of analysis to identify the best time, method, order and/or combination of actions to execute once you’ve identified them. It is critical to recognize and plan for not just your initial analysis, but also any secondary analytics, up front. That way you can budget, plan, and execute in a fashion that will lead to success. I look forward to hearing an update from my client on how their next generation analytic process turns out.