Retail

Join

What is D.A.G and Why Is It Important for Retail Anaplanners? Part I Introduction

JaredDolich
JaredDolich
in Groups

Part I | Calculations in Anaplan | Introduction

We're about to go deep into the mind of the architects of Anaplan's calculation engine, the D.A.G. or the "Directed Acyclic Graph", so fair warning for what will be a mind-blowing journey! You're probably wondering why we're writing about this. @BobD and I ( @JaredDolich ) recently found a great comparison between Blue Yonder and Anaplan written by @clouttit over at Accelytics and it got us thinking about why retailers raise their eyebrow with one of the most obvious calculation approaches between these two software solution providers, the inverse calculation and the related ability to lock and spread on rates, prices, and ratios. We recently wrote a requirements document for @DavidSmith and @rob_marshall and we thought we would share that with you here.

First, What is DAG?

In this series of posts, we will need to understand how Blue Yonder and Anaplan calculate changes made in a dimensional model, or as some like to call them, OLAP (online analytical processing). But first we need to get familiar with basic concepts of how a directed acyclic graph works.

Quick Example

Let's say we have a use case where a merchandise planner wants to either plan by editing sales (300) or by editing the sell thru % GAFS (25%). Our Anaplan module would be set up using the following line items. In Blue Yonder, we only need one equation because sell thru and sales can both be editable without using overrides.

DAG2.png

In Blue Yonder, each line item is given the direction of the calculation. To read this: if Sales is changed, then first change ending inventory, then sell thru. If sell thru is changed then first change ending inventory then change sales.

  • Sales [Ending Inventory * Sell Thru %] : Ending Inventory, Sell Thru
  • Sell Thru [Sales / Ending Inventory] : Ending Inventory, Sales

Which is more intuitive to the user? Using Blue Yonder, there is no need for overrides so there are only 6 line items and two of them are editable. With Anaplan, you have to use overrides and booleans so it requires 8 line items. The more editable line items, the more Booleans and overrides you have to create. So if we made 4 of those line items editable, I still only need 6 for Blue Yonder but I would need an astounding 14 for Anaplan. This is the reason why retailers raise their eyebrow.

The Real Truth

I should note that setting up the calculation logic for the BY modeler is very, very complicated and is the number one reason why it is nearly impossible to upgrade BY schemas. So, in essence, BY abstracted the "Directed" part of the DAG and left it in the hands of the BY modeler. The real truth, rather ironic too, is most BY implementations use inverse calculations but planners rarely use them. The eyebrow raising is, in my opinion, is a level of posturing, usually due to having an emotional investment in the current configuration or because the company is financially invested with a significant portion still on the books. 

Looking Ahead

In Part II we'll dig into the DAG and why it's so powerful and why it's important not to abstract the "directed" part of the calculation.

Categories