OEG Best Practice: PLANS: This is how we model

AnaplanOEG
AnaplanOEG
edited May 23 in Community Knowledge Base

PLANS

PLANS_Main_33530.png

PLANS is the new standard for Anaplan modeling—“the way we model.” This covers more than just the formulas and includes and evolves existing best practices around user experience and Data Hubs. It is a set of rules on the structure and detailed design of Anaplan models. This set of rules will provide both a clear route to good model design for the individual Anaplanner and common guidance on which Anaplanners and reviewers can rely when passing models amongst themselves.

In defining the standard, everything we do will consider or be based around:

  • Performance – Use the correct structures and formula to optimize the Hyperblock
  • Logical – Build the models and formula more logically – See D.I.S.C.O. below
  • Auditable – Break up the formula for better understanding, performance, and maintainability
  • Necessary – Don’t duplicate expressions. Store and calculate data and attributes once and reference them many times. Don't have calculations on more dimensions than needed
  • Sustainable – Build with the future in mind, thinking about process cycles and updates
PLANS_Axes_33530.png

The standards will be based around three axes:

  • Performance - How do the structures and formula impact the performance of the system?
  • Usability/Auditability - Is the user able to understand how to interact with the functionality?
  • Sustainability - Can the solution be easily maintained by model builders and support?

We will define the techniques to use that balance on the three areas to ensure the optimal design of Anaplan models and architecture.

D.I.S.C.O

PLANS_DISCO_33530.jpg

As part of model and module design, we recommend categorizing modules as follows:

  • Data – Data Hubs, transactional modules, source data; reference everywhere
  • Inputs – Design for user entry, minimize the mix of calculations and outputs
  • System – Time management, filters, list attributes modules, mappings, etc.; reference everywhere
  • Calculations – Optimize for performance (turn summaries off, combine structures)
  • Outputs - Reporting modules, minimize data flow out

Why build this way?

  • Performance
    • Fewer repeated calculations
    • Optimized structures and formulas
  • Logical
    • Data and calculations reside in logical places
    • Model data flows can be easily understood
  • Auditable
    • Model structure can be easily understood
    • Simplified formula (no need for complex expressions)
  • Necessary
    • Formulas and structures are not repeated
    • Data is stored and calculated once, referenced many times, leading to efficient calculations
  • Sustainable
    • Models can be adapted and maintained more easily
    • Expansion and scaling simplified

Recommended content

Video

https://www.youtube.com/watch?v=gv8JEp8BDQg


Performance

Logical

Auditable

Necessary

Sustainable

Author David Smith.

Tagged:

Comments

Categories