A discussion on the traditional challenge to propagate information input at aggregate levels belonging to the same hierarchy, down to the granular level.
1 The Challenge
1.1 What is the Double Lift Issue?
Let’s consider the following challenge: a Plan by Channel and Salesman should drive a Plan by Customer. So users would plan at a higher level and then BOARD would allocate and propagate down to the lower level the plan.
Channel and Salesman are both aggregations of the entity Customer.
The Cube A (by Salesman and Channel) must be propagated to the Cube B (by Customer).
1.2 Version Compatibility
BOARD 10.1 and following manage the above situation under the following conditions:
- The dataflow should be a simple copy of the amounts from the aggregated level to the granular level (b=a)
- The dataflow should be performed using the method HBMP or HBMP+
1.3 DATAFLOW Schema
Let’s consider this Data Flow Schema and how it drives the Data Allocation
1.3.1 Step 1
Thanks to the E/R Model each Customer is given the correct value, but the salesman[R] dimension isn’t recognized as belonging to the Customer Hierarchy. Therefore, per each Customer, all the salesman[R] items are populated. The criteria is given by the relationship between the Customer and the Channel.
The adoption of an [R] Entity is only to guarantee the item alignment with the Hierarchical Entity (Salesman). A standalone entity could be used as well.
1.3.2 Step 2
Now the Diagonal Matrix (Cube C), thanks to the Relationship with the Salesman Dimension, identifies which item of the Salesman[R] dimension should be kept per each Customer
1.3.3 Step 3
Finally, you can copy the Cube D into a cube by customer only (the salesman [R] dimension is collapsed) as per our initial requirement.
Attached you can find an example illustrating the process needed for BOARD versions earlier than BOARD 10.1