Model Building Excellence & Application Lifecycle Management

Occasional Contributor

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

My company is also interested in the upcomming Dynamic Cell Access feature. Specifically arround using it with Break Back to control which cells are updated. Is there a place you can recommend we look for more information on the feature? I don't see much about it on Anapedia yet.

 

Thank you.

Highlighted
Certified Master Anaplanner

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Hi David,

Which advice would you give for creating and managing lists and subsets of those lists (naming convention, order in which they are created, etc.)

I am asking that because when you have multiple lists and multiple subsets for each list, finding them in the "applies to" of a module is a nightmare. The order they appear on, seems completely random.

I am attaching a screenshot of a very simple example with 4 lists and 10 subsets to illustrate what I mean.

Thanks

Highlighted
Occasional Contributor

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Hello,

 

Most of the customer we talk, they want to see almost all the data in one model (eg: They dont want to switch between models / workspace to make a business decision). What do you suggest should be the design approach if we have multiple models distributed into multiple workspace still business want to see combined set of data / information in one model without taggling between models

Highlighted
Master Anaplanner/Community Boss

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Hi Ashish

It is a good question, and the ideal situation is to have everything in one model.  But, in certain circumstances we do need to split models

  1. Model Size
  2. Model Performance
  3. User Concurrency

In these situations, I usually ask the following questions?

  1. Are there defined parts of the process that follow on from each other with different users?
  • Let’s assume we have a 12-day S&OP process. The Demand plan is completed in working days 1-4 in the cycle.  The output of this feeds an Operations plan, to be completed in working days 5-8 and finally that feeds an Inventory plan in working day 9-12.  The inventory plan does not need to be updated in real time as the Demand plan is updated, so this is a good candidate to split the model functionality in three models (Demand, Operations and Inventory) and import the data between them (maybe overnight, or using a schedule)
  1. Can you split the model by hierarchies?
  • It is important that we minimise the number of models a user needs to access to complete their planning, so think about splitting the models along those lines of responsibility (maybe be Region, or by Product).  For example.  Let’s assume we now have three parts of a process; Contract Setup, Contract Rules and Scenario Modelling.  As described above, we could split the model by these three, but if the same user needs move quickly from one process to another, switching between models is not a satisfactory solution.  So in this case, it would be better to try and keep all of the process calculations and modules in one model and split the model based on the main contract hierarchy.
  1. Does all central reporting/analysis need to be real time?
  • Often the models pull everything together for Central consolidation and Reporting. As with the first example, in many cases, this doesn’t need to be updated in real time and can be split out into a separate model and update regularly.  Quite often these updates are overnight in existing systems, so we are often able to improve the latency of the reporting from the existing state, even if not in real time

I hope this is helpful, if you have any follow up quesitons, please post the question in the relevant Topic forum (from the left hand navigation panel)

Highlighted
New Contributor

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Hello David,

 

My questons are around Bulding a Data Hub - Best Practices in this article:

https://community.anaplan.com/t5/tkb/articleprintpage/tkb-id/IEBestPractices/article-id/8#toc-hId--6...

 

1. How literally should we take this?  It makes complete sense with big lists, in a list with 5M records, it is a no-brainer.  But where is the limit?  If the list has only 100 items in it, would we still take the same approach?  What if it only has 5 items in it?

 

2.  Is this approach recommended when importing data from one model to another model?  For example:

  • In Data Hub, customer master is imported from a csv file into a multiple hierarchical key lists and then  corresponding property module as needed.  Would we import the Data Hub key lists and property module(s) to a:
    • Demand Planning model key lists and property module(s)?
    • Demand Planning normal list (not key list).  If this is the case, is the property module created in Demand Planning model?

Thank you!

Highlighted
Master Anaplanner/Community Boss

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Hi Terrie

I presume your first question refers to the incremental data load.

I think, as with most cases, common sense needs to prevail.  The key point is to try and make the imports as efficient as possible and that is why we advocate the incremental load.  But, as you point out, sometimes, this doesn’t make sense for all (small) lists and isn’t really practical.  As I mentioned in the video, most of the best practices are guidelines that will have exceptions.

The really important thing to point out here is it is BAD practice to clear out the list and re-load each time it is imported, be that into the hub itself, or the downstream models.  There is a limit on the number of times this can be done before our Technical team need to get involved to reset it. Please try and avoid this method of updates.  I will be posting an article on Best Practice for List Imports soon.

 

On your second question, if by a KEY list you mean a numbered list, then it will depend on the reason for the numbered list.

If the numbered list was created in the hub because of a lack of a key, then creating the key in the hub and using that as the code in the downstream models negates the need for a numbered list.  It is much easier to try and avoid using numbered lists when importing or exporting data between models.  This is due to the #id that is used to identify the numbered list entry.  Using a code is always much more preferable. 

However, if the numbered list was used because of flexibility/limitations on the display name, then you can still have a numbered list in the downstream model.  I would still try and use a code wherever possible (it is much easier to tie the lists together)

 

I would always advocate a properties or attributes module though.  As I mentioned as part of DISCO, creating a System module and referencing the details everywhere is key to good model performance, design and understanding.

 

I hope this is helpful, if you have any follow up quesitons, please post the question in the relevant Topic forum (from the left hand navigation panel)

Highlighted
Community Manager

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Remember to let us know what you thought about the AMA by taking the survey. We want to hear from you!

Highlighted
Master Anaplanner/Community Boss

Re: Model Building Excellence & Application Lifecycle Management - Featuring David Smith

Hi Fabien

Apologies for not being able to answer this on the session last week.

 

Firstly, we recommend adding a “placeholder” dummy list at the bottom of the general lists because subsets will always appear at the bottom.  So, something like <-- Subsets -->

Secondly, we recommend naming the subset with the name of the list as a prefix, e.g. Cost Centres:EMEA, or Products P7:Active Products.  This helps identify the lists (and their purpose)

 

Finally, addressing the order.  As mentioned, they will appear at the bottom of the list (below the users list - see attached) and the order is made up of two elements:

  1. The order the lists were created in general lists and
  2. The order in the subsets tab

I have raised a request to the product team that 1. above is amended to reflect the current order in general lists as this will help with the ordering

 

I hope this helps, 

If you have any further questions please post a message on community under the relevant Topic (from the left hand navigation bar)