Exception reporting

In our daily lives, we use exception reporting quite frequently. Think of alarm systems in your house that signal unlawful entry, the signal on the dashboard in your car telling you to fill up the tank or the set timer of the oven, notifying you that your recipe is ready. Straightforward to use and to understand, the signal that something has gone over (or under) a set threshold. The reason: to warn us in time and prepare any mitigation actions to resolve the issue at hand. We do not constantly need to check for example the fuel level in our car, but get an early warning once the minimum level has been reached. This offers many advantages, like:
– get an early warning signal that things might go wrong
– focus attention on topics that really matter

We use this in our lives every day, but why don’t we use this in our planning processes? I have seen planners going over thousands of data points to check a system generated forecast, per product, per customer, per month. And that process repeated itself every new month when an updated forecast was ready. This work is labour intense, cumbersome and does not add much value to the planning process.

For most product – market combinations, the forecast can be checked at aggregate, not detail level. Unless a set threshold on a Key Performance Indicator (KPI) is reached. This should trigger an exception alert for the planner to start to pay attention. To give an example: sales of a specific product in a market always fluctuates between -10% of the baseline and +25%, reflecting for example seasonality. In normal conditions (no promotions) the forecast stays within these boundaries (-10% to +25%), no specific action is required from the planner. As soon as the forecast goes over (>25%) or under (<10%) this threshold, a warning should be generated in the planning software. The planner should start to pay attention to this warning and do a deep dive into the data to find the reason this forecast is outside the set thresholds. Depending on the cause, the planner can decide to take a corrective action or leave the plan as is.

With the use of these kinds of exceptions, the planner can focus on the areas where his effort adds most value to the planning process and business. This accelerates the planning process and allows for quick interventions in the areas of the plan where it is most needed. In one (or just a few) dashboards, the planner should immediately see where he needs to focus his attention and start to work on finding the root cause and possible mitigation actions.

Because of a (misplaced) sense of control when we go over every data point in a plan, we think we add value. But we don’t, in most cases a planner (which we proved in an assignment at a customer), who starts to tweak a forecast that remains within the set boundaries, worsens the forecast. This can cause all kinds of disruptions up- and downstream of your supply chain. And with time being our most valuable asset (as a human), we need to be very strict in how we spend the time and at which topics. Exception reporting can play a huge and important role in adding more value to the planning process by shifting the focus of the planners to the areas where it is most needed and adds the most value.

Are you using exception reports in your planning process? Does your planning platform support this use of exception reporting in the dashboards? With the latest, state-of-the-art planning platform, that should not be a problem. For example, the planning platform Pigment is planner centric built, to support the planner to be as effective as possible.