Best Of

@cbrookes

Wow, you did your homework, but you always have to be careful following what @jasonblinn has to say. Obviously, I am kidding about Jason, just seeing if he will respond.

Without seeing your model, it is going to be hard to figure out, but there might be a chance to use a lookup for the previous member if it is stored in a SYS module.

You up for a call to discuss?

@cbrookes

Ok, here you…in the module where you have your attrition percentages, that is my "Russ" module which will contain the final Attrition number when we are done. On the rows, will be your "tenure" list.

Create a SYS Time Days module dimensionalized by Time, at the Day level. We will use the day of the month as our tenure, in this case, 1-10, which will work until you have more than 28 tenures.

Create a module (Calc Russ). The only dimension/list I am missing from the module above is the Tenure list, but have replaced that with the Time, at the Day level. Why the Day level, because you have tenures more than 12 and we need to make sure we have encompassed all tenures. Also, I created a Time Range (One Year) so this only spans one year which will help with space and performance. Again, we are using the Time dimension to do the calcs and since each Native Time period is its own block of data, we will be able to use the Previous function.

Note, if you are using Polaris, you won't need to do that as Polaris will allow you to get the Previous/Next member of a list.

Data: Russ.data[LOOKUP: SYS Time Days.Month, LOOKUP: SYS Time Days.Tenure]
Cumulate: IF Data = 0 THEN 0 ELSE IF Data + PREVIOUS(Cumulate) >= SYS Global.CBrookes Threshold THEN Data ELSE Data + PREVIOUS(Cumulate)

Now that we have the data, we need to get it back to our "Russ" module, but we need to link the above module (dimensionalized by Day) to a module dimensionalized by Month. Before we do that, we need to create a couple of line items in our SYS Time Month module.

In your SYS Tenure (my SYS Test Upload Module) you will need to create a number representing the Tenure, we will use this later to represent the DAY.

Now, create a module dimensionalized by Time (Month) and Tenure with one line item.

Day: DATE('SYS Time - Month'.YearNum, 'SYS Time - Month'.MonthNum, SYS Test UpLoad.Number)

Back to our "Russ" module, create a line item (Attrition) that will get the Cumulate line item from the Calc module using the "mapping" module above. Remember, we can only use two formats in lookups, list formatted line items and Date/Time Periods.

Hope this helps and is clear,

Rob

The Anaplan Data Management System is not currently available and as such all statements below are subject to our standard safe harbour statement and are subject to may change.

The Data Management System is aimed at a technically savvy business user that is comfortable building models in Anaplan and working in Excel. They have a good knowledge of the business problem to be solved and the data that is available to do it, but are not necessarily Master Anaplanners, experts in SQL or database management. We call them Data Modellers.

Connect

Data Modellers configure connections to common on-premises and cloud source systems through intuitive interfaces tailored to the data source. Modellers will authenticate, be guided through the selection of source data defaulting to delta loads where that is supported by the source application and schedule execution. Executions will be logged to support failure alerting, monitoring, summary reporting and housekeeping.

The modeller will be able to connect to Anaplan models as an inbound data source to support inter model data transfer and reporting and analysis capabilities outside of Anaplan.

The approach is to build a connector framework into which connectors for specific data sources can be introduced quickly and without significant effort. In the longer-term partners should be able to certify and register additional connectors.

Convert

Data Modellers restructure the extracted data into the format required for modelling and planning by configuring a repeatable sequence of transforms through an intuitive graphical interface. In addition to basic primitives (filter, lookup, join, calculate, sum, union) there will be extended capabilities for OLAP such as balance and validate hierarchies, aggregation to dimension levels, and data quality and anomaly detection capabilities.

Catalogue

The catalogue exists at a tenant level and Modellers across workspaces in the tenant can consume accessible Data and Master data objects into their models. It also allows the Data Modeller to assign semantics to objects to simplify, accelerate, and automate the mapping for consumption of data into Anaplan models.

The Data Modellers will have access to statistics for objects in the library (for example where these are consumed, how frequently and recently, volatility, quality) for housekeeping and maintenance purposes.

Consume

Data Modellers will be able to create and update lists and data in their models from accessible objects in the DMS catalogue for faster model development and maintenance.

When consumptions are executed, these are logged for success / failure, data volumes, execution time and rejected data so that the Data Modeller can report on statistics of catalogue object use.

In alter releases:

• An end user can drill from the UX through to the underlying details in the DMS.
• A page builder should be able to surface accessible data from the DMS through the NUX so that this can be displayed to the end user based on them having suitable permission to that data. Combining this with the connector for Anaplan modelling allows for reporting from static plans which have been published into the DMS without a need to open the underlying model.

What the Data Management System is and what it is not

The DMS will be the solution for extracting, transforming, enriching, validating, staging, and orchestrating the incoming and outgoing data for Anaplan.

It is not:

• A replacement or alternative persistence layer for Anaplan models.
• An enterprise or generic ETL tool.
• An enterprise data lake or data warehouse, although it could be considered as a “DataMart for your planning data”.
• An alternative modelling or calculation engine, although it can transform and enrich data it does this as part of data integration and not interactively.

Since Supply chain use cases are picking up, do you feel it will be good to have supply chain specific functions in Anaplan. If yes, then kindly promote the new idea I posted.

Thanks Amaya, your advise resolved my issue.