Noted! Using model notes in Anaplan
Author: Hillary Sich is a Certified Master Anaplanner and Consultant Manager at Allitix.
We use sticky notes, OneNote, Evernote….
Even if we can’t agree on the type of notes we use in everyday life, we can all agree that notes are an important tool. We use them for organization and communication.
The big question here is, how do you use the notes feature in Anaplan? The answer for some is “not at all.” Personally, I use the notes feature at every level — modules, lists, and line items. Notes are a great way to promote self-documentation of models and leave our Anaplan clients/colleagues with a living document. Additionally, notes promote P.L.A.N.S. — specifically the Performance, Auditable, and Necessary concepts.
The “how”
During development, use line item notes to save formulas, document line purpose, and note “temporary” lines, etc. All of these notes will help in model organization and particularly in the “N” (is the line necessary?).
During development wrap-up and UAT preparation, use the notes feature as a basis for final documentation and aid in final model cleanup which will ultimately help with “P” (performance). It is surprising how much we build along the way that is not used in the final product.
- Lists: Identify the use of each list in the model in the notes field in general lists. While documenting the use, verify that the list is actually being used in the model. If not actively used, mark for deletion in the final phase of model clean up.
- Modules: Add a short description of the purpose of the module as it relates to process, area of use, and module function. While documenting modules, verify they are necessary by checking the referred to field. Be sure to check for dashboard use (an entirely new subject for self documentation — hint: use data tags!). Mark unused modules for deletion in the final phase of model cleanup.
- Processes: Add a short description of the purpose of the process and note the dashboards where the processes are published. While making notes, make a quick review of all actions. If following best practices, all actions should be part of a process. Mark any actions not included in a process for deletion in the final phase of model clean up.
All of the above may be obvious uses of notes, so now how do you make fantastic use of all the documentation efforts? Create a technical document by building a documentation model.
- Export the processes, module list, and general lists with completed notes to .csv files.
- Import the data into a documentation model (there is some data manipulation that will have to be done in excel).
Once the data is landed, the sky is the limit!
Processes: Add Frequency, Integrated? Boolean and publish.
Modules: Publish with “Applies to” and “Referenced by” for model owner documentation.
Lists: Publish with “Used in Applies to” and “Used in Formats” for model owner documentation.
Why go to the effort to create a model documentation model?
- Easily keep documentation up to date as any part of a model changes.
- Repeatable documentation across all clients.
Aside from the documentation advantages of using model notes, using notes forces compliance with the P, A, and N in P.L.A.N.S.:
- Performance: By reviewing every list, action, and module easily determine what is not needed which minimizes size and there for increases performance.
- Auditable: Good documentation within the model decreases the need for knowledge transfer between model builders and allows model owners to easily follow a model build.
- Necessary: Using model notes probably has the largest effect here. By reviewing each action, list, and module forces a model builder to evaluate use of these elements in the model.
How are you using notes? Leave a comment!
Comments
-
Here here!!! Kudos @hsich1020 on a great post!
Notes are one of the most powerful, under utilized resources at our disposal. It's one of the factors can make a model really standout as being "well built", logical and impactful notes are a game changer for sustainability. The most difficult question to answer when picking up a model you did not build it "why", leaving those breadcrumbs behind in notes can answer that question for your successors.
One tip I have regarding line items - if you have intentionally enabled Summary methods to support downstream calculations, call that out! In larger modules it can be a knee jerk reaction to want to set summary to None to eliminate sparsity but that can have calculation output repercussions in certain instances. Part of being intentional with our build decisions is documenting why that decision was made.
3 -
Feeling very self-conscious about my (lack of) documentation practices in my models! Has anyone put together a "How I Built It" video around this topic? I'll admit I've never used Data Tags before (or paid attention to them, frankly) and this is the first time I've heard of a documentation model. Would be great to see how others have done this well!
0 -
@dameyer01 We don't have a 'How I Built It' on that topic, but we do have a blog coming out later this month on model documentation, so keep an eye out for that! I'll add the idea to my list for 'How I Built It' videos too!
Thank you!
Ginger, Community Manager
2
