Combining the Hierarchies of Two Different Demand Planning Systems

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Why hierarchy combination can be important.
The importance of keeping the hierarchy in the receiving demand planning system.

Introduction

In several articles, I have described the importance of recognizing that many very popular enterprise demand planning applications are not good enough at aggregation and disaggregation to make it worthwhile to attempt to perform much more than the most basic aggregation in them.

See our references for this article and related articles at this link.

Secondly, that some systems can perform forecast aggregation very efficiently and that rather than trying to get a system to do something it is not naturally designed to do, that the aggregation and disaggregation capabilities of a second demand planning system can be effectively “blended” with the first system.

How To Combine The Aggregations

One of the first questions I receive is how two demand planning systems can be technically integrated. For this, I am happy to report that demand planning systems are probably the easiest supply chain planning systems to integrate. In fact, extremely few companies only rely upon a single enterprise demand planning system to generate the forecast, although the more common approach is to informally integrate offline analysis in spreadsheets with the enterprise system. However, a more formal enterprise demand planning system to enterprise demand planning system is quite feasible.

Several issues arise, such as how the forecast file is passed and uploaded, and which system becomes the primary system that the demand planners interact with, however for this article, I will focus on the integration of the hierarchies.

Several Options

Flatten the Hierarchy in the Receiving Demand Planning System

One of the simplest is to have no hierarchy in the receiving system. Once an auxiliary system which is well designed for aggregation and disaggregation, in many cases, it is unnecessary to maintain any hierarchy in the second system. Under this design, every manner of aggregation can be performed in the sending demand planning system, but the forecast is disaggregated to the product location combination (i.e., the lowest level) and send to the receiving system.

Keep the Hierarchy in the Receiving Demand Planning System

In most cases, when I speak with companies, they have already configured a hierarchy, which is typically based on the sales or organizational structure in the system with weak aggregation capabilities. Not understanding that they have set up a hierarchy in a system that can only present one hierarchy at a time (while many hierarchies are almost always necessary, and hence the need for attribute-based forecasting data back-ends) (see this article for details).

At this point the limitations of the poorly performing aggregated forecasting system become apparent. They may contact a consultant to help them “get forecasting aggregation” working in the application, unaware that the time to select a reliable attribute-based forecasting system was back in software selection. And that software can most often not be configured out of its design restrictions.

This is a long way of saying that most often a pre-existing hierarchy exists in the system they installed. So the question becomes,

If we use a secondary demand planning system, how do we combine the new hierarchy in the new system with our present hierarchy. – Prospective Client

The answer is that the sending system, with flexible attribute-based and hierarchical capability, can disaggregate to the lowest level, can be brought into DP and DP can then aggregate to the hierarchy that it has set up.

This allows both the best of breed application, that is competent at attribute-based forecasting to be blended with a pre-existing DP solution. Part of the company that wants to use DP as the interface to the forecast can then do so.

Go to top

Conclusion

Clients have problems getting attribute-based forecasting to work in some systems like SAP DP because they are not designed for it. However, several systems can do attribute base forecasting and can have their output blended with DP or the existing system to create a blended system that meets customer requirements for forecast aggregation both regarding top-down forecasting, as well as simple viewing at a reasonable cost.