NEW Community Q&A Challenge — join the discussion and collect a badge!

becky.leung

In the Anaplan Community, we believe that success stems from members connecting, sharing, and helping one another. As we witness members supporting each other daily in forum discussions, sharing ideas and best practices, and showcasing their expertise across various content, we are excited to introduce a new challenge that offers everyone the opportunity to engage and learn from one another.

Introducing our very first Community Q&A Challenge, where we present an Anaplan-related question for all of you to reflect upon and share your perspectives!

Question for the Q&A Challenge: As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

Please comment in this post with your answer!

How to participate in the Q&A Challenge:

• The challenge starts today, September 5, 2023, and will conclude on September 22, 2023.
• Provide a response to the Q&A Challenge question by leaving a comment in this post: As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?
• Community members who participate in the discussion will receive a unique participant badge at the end of the challenge.

• But that’s not all! In addition to the participant badge, we’re introducing a "Top Answer" badge that will be awarded to the top three responses with the highest number of "likes" from fellow Community members. You can vote for answers by "liking" your preferred responses in the comments. Feel free to "like" more than one answer – in fact, we strongly encourage it!

We will announce the winners of our Q&A Challenge and showcase their answers during the week of September 25!

Are you ready to join the discussion? Participate in the Q&A Challenge by commenting below in this post. Don’t forget to show your support by liking for your favorite answers.

We look forward to seeing your responses!

For a full outline of our challenge rules and restrictions, read our full Terms & Conditions here.

JaredDolich

Changing Production Models

Corporate Psychology vs. Customer Satisfaction

As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

Consider this cartoon from Clowncurls.

Maybe a bit exaggerated but sadly not too far from how Anaplan change requests come in. The question is how should you respond?

Long ago I was a service desk manager for a 5000-store retailer, and we received 900,000 contacts per year from store associates, customers, and corporate employees. Fortunately, I was exposed to the Information Technology Infrastructure Library, or ITIL, and Lean Six Sigma, or LSS, to help ensure quality responses to most of these contacts such as incidents, problems, and service requests.

I am fond of a concept from LSS that, to this day, is predominantly used by most IT organizations which is to create a 2x2 impact effort matrix regarding how to prioritize service requests. Anaplan Way uses the same approach as part of the planning poker and sprint review. It would look something like the chart below, but instead of effort, we’ll replace that with YOUR tolerance and discipline to best practices.

The key to your response to any production change is understanding customer expectations. So, let’s assume your goal with any Anaplan change is customer satisfaction. In that light, let’s shine intense beams at each quadrant of this 2x2 grid and see what consequences manifest.

But first..

I want to mention all the Anaplan best practices related to production changes here to be thorough. I won’t go into detail of each one, rather leave that to you to look them up or refresh your understanding.

• DISCO
• PLANS
• ALM
• The Planual – @Misbah and @rob_marshall newest version
• The Anaplan Way – especially user stories with success criteria, sprint reviews, testing, and planning poker
• Data Hub – especially hub to spoke synchronization.
• Center of Excellence best practices – unique to each organization (e.g., naming conventions)

Did I mention testing?

• Test Scripts
• Unit Testing
• User Acceptance Testing
• Dev-QA-Prod Migration Testing
• System Integrated Testing

Awesome. Now let’s look at the four quadrants with our best practices in mind.

Anaplan Champion– Yeah, this is intense and takes a lot longer than usual, but you cannot risk making a mistake, especially one that cannot be recovered. Consider a process that has 100 to 200 actions to synchronize your data hub to your applications and across multiple workspaces. There’s not much chance of recovery.

Gambler – This is where your professional integrity and self-interests are going to collide. The boss wants the changes now! Will you be a hero, quickly migrate your half-baked changes to production, and leave it to the next modeler to deal with the short cuts you took? It’s possible no one will remember it was you that made this change, but one thing is certain. If Anaplan is causing business delays while the next modeler is figuring out what you did, you’ll tarnish Anaplan’s reputation. Be professional. Use best practices. You’ll win the long-term reputation for you, and Anaplan.

Sinister – It’s called sinister because the change is trivial and the process to migrate the simplest edit is immense. Sinister to you and frustrating to your customer short-term. Will you cave for short-term heroic status or make the investment to maintain a highly functioning application that will last a lifetime? Look superficially beautiful now or have personal satisfaction of professional work later? Not an easy decision, especially if the ones demanding the change are intimidating.

Naïve Quick Hit– The easiest of the four in my opinion because you should only encounter this quadrant when you’re training, sandboxing a POC, or doing some research. This is your personal quadrant. Have fun with it. Just make sure you never promote anything from this quadrant into production as-is. Like what you see? Great. Now move this to the next sprint and use first quadrant.

Summary

Only you can decide where you will draw the line between corporate expediency and long-term sustainability. Unfortunately, the two rarely complement each other. What I can tell you is that the best models out there are built using the best practices, PLANS in particular, and tools mentioned above. If you’re fortunate enough to be working with an Anaplan COE then you should be able to find colleagues that will support your interest in avoiding Anaplan deprecation. At the very least, leverage the ongoing sprints to get your changes prioritized along with everything else that’s happening.

Puneeth H P

Hi all,

This question itself holds the best motive is that the changes we are doing must not be affecting any other places or outputs. The significant steps which one should check always are;

1. Always find the references which are there in the blueprint within a module and also check the references of the module with other modules or lists
1a. If any line items we are changing are removing has referred to other modules line items, then we need to export the output values which are correct and make the changes, to validate the values.
1b. Check if any new line items are added, make sure to update the properties of the line items such as; format, summary method, styles, Read & Write access etc.
2. Making sure that all the "SAVED VIEWS" doesn't get effected from the changes. This can be achieved by having the information already stored before making any changes in the module; the information like saved view names, filters and columns which are mandated in the saved views.
2a. In few other cases, once the main changes are done, these saved views and filters needs to be re-applied and saved, so that new changes wouldn't get recognized by the saved views.
3. Notifying actions which are aligned with the modules or line items which we are changing might be a significant step. We have to edit each actions and see if all the mappings are updated correct and line items are mapped to correct target line items.
4. If the changes related to any lists, let's say we are dealing with GL Account and some definitions we are changing regarding any particular account, we need to make sure the structure of list doesn't change and look for any subsets or system modules which does the connections for any altercations.
5. If the module is assigned to Line Item subset, we should always make sure that the Line items are mapped to where it supposed to map and try to put it formula for these kinds of line item subsets mapping. Also, make sure to not change the line items format to any other than NUMBER format which is referred to as LIS is a good habit.
6. Major changes which affects the other parts usually are Time settings, list update, System modules changes, line item deletion or addition, not updating summary levels, changing Saved views names and filters not updated correctly, process errors, Access issues.

Please let me know if I have missed anything.
Happy modelling.

Thanks,
Puneeth HP

CommunityMember121571

2 ways:

• logical check - it is widely described above
• data check - create data copy before changes (best and easiest way inside the same model); check, when you've finished your build (preferably on a test model with ALM)

PhilippErkinger

I would love to see many customers applying everything from the best practices tool kit. Unfortunately, two extremes can be found too often:

1. Business Owned Models. In the best case, there is a Center of Excellence with some guidelines. Impacts are managed on the fly. There is a genuine belief that the high pace of new feature developments outweighs any small (or large) impact. Do you wish for a new report tonight? It's already in place tomorrow morning.
2. IT Owned Models. They have learned from the best and implemented the most theoretical change management processes in existence. These generally contain loads of paperwork and sign-off processes to foresee the potential impact of a model change. Nobody really knows where all the paperwork ends up. The good thing is, models stay mostly the same.

It makes me already very happy when customers apply a rigid DTAP street. Develop→Test→Acceptance→Production. This can be very practical, releases can be often and defects are naturally found during a testing process. 😎

Tiffany.Rice

As the old adage goes an ounce of prevention is worth a pound of cure and this definitely holds true when it comes to changing a production deployed model.

When I pick up a model enhancement, before making any changes I'm going to start by laying out my plan of action. I start by narrowing in on the objective - what changes do I expect to see and what should stay the same. From there I work backwards, for example if I expect to see a methodology change to a specific forecast account I'd start with the reporting output module and trace the formulas back to the originating inputs.

My action plan will layout any and all module/list/actions that need to be updated - both formula and production data updates. This can help to surface questions early that might need clarifications from business partners on requirements before they become roadblocks. A key point I always contemplate are any implications to connected models, the potential for ripple impacts grows as your ecosystem evolves and it is important to solution not just for impacts within the model itself but also to any connection points (integrations).

Once I've got a firm grasp on objectives and steps - it's time to contemplate dependencies, sequencing and execution. Certain changes might necessitate a series of ALM revision tags - for example, if modifying an input module to be based on a subset, the subset is defined on one tag and populated in PROD before the tag with the module revision is synced. Contemplate the optimal order of execution to ensure no production data is lost and the development is logical and meticulous. Finally, ensure the appropriate baselines for validation are captured. We use a STAGE model concept which gives us a prod like data set we use to validate revision quality, I will capture the core output modules to validate before/after impacts of the revisions.

Once you've got the plan, there is nothing left but to do it! This is the fun part where you get to see all you careful preparation become a reality! I like to take screenshots of my progress along the way as a supporting documentation which may seem a bit over the top but does come in handy when needing to help my collegues to understand the changes that were executed.

HimanshuRaj

This is one of the most interesting part of the model building as one has to figure out the impacts of a change during development.

When I make a change, there are a set of things I ensure to check before proceeding with the change.

1. Check the references of the line items, module to other modules.
2. Take the export of data so that a confidence can be ensured by matching the data after the new change
3. If line items are part of line item subset, then making sure that "Is Summary" doesn't get updated after the change as it will disturb the mapping modules using LISS from this module
4. Update the actions relevant to this module
5. Ensuring that saved views are intact by comparing it with the copied module (copy of this module before making a change)
6. I like to check and store my progress after each step of a change which comes in handy later on to follow my own work

Finally, Enjoying Anaplanning!!

AkhilEmmanual

Hi everyone,

Here are the few things i would like to ensure before making any changes to an existing module.

1. Take a Snapshot of the module so that I can compare the values after changes have been done.
2. Check the line items which are Referred to other modules (will take an export of everything before changing) .
3. If line items are referred or if that module is used for reporting I will make sure that the correct Summary is been used.
4. Ensure all the Saved Views are not affected by this change by taking a copy of the module before changing.
5. Ensure Filters are working fine.
6. Ensure all the DCA are working fine which has been applied to both module level and line item level.
7. Check each and every Actions associated with this particular module and will make sure everything is working well .
8. If LISS is created from this module will make sure all the line items associated with LISS will be number formatted and also confirm that mapping related to LISS are not affected.
9. If the module is published in dashboards I will ensure proper Style is applied to each and every line item .

Finally i will make sure that the changes done will help to improve overall model performance.

Regards,

Akhil Emmanual

willridge

As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

As is often the case, it depends. If you change a line item that is referenced by others, then I would check a sample of the downstream calculations to see I was getting the right results. I would also consider building a new line item in the referenced module with the new calculation, then test that and if successful copy the formula into the existing line item.

gfraotero

Hi,

"Believe only half of what you see and nothing that you hear." Edgar Allan Poe

As an Anaplan model builder, ensuring that changes made to an existing module do not yield unexpected results in the module where the changes were made and in other modules is critical to maintaining model integrity and data accuracy. Here's a process to address this issue:

1.- Detailed Documentation: Before making changes to a module, ensure you have detailed documentation of how it currently functions. This should include formulas, relationships, and any other relevant configuration.

2.-Test environment: Use a separate test environment to make changes. As we know, Anaplan allows you to create copies of models for testing without affecting the production environment.

3,.Backup: Create a backup of the model or module before making significant changes. This allows you to revert to the previous state in case of issues.

4.-Potential Impact: Assess the potential impact of your changes on other modules. Will existing formulas be affected? How will input and output data change in other modules?

5.-Thorough Testing: Conduct thorough testing in your test environment to ensure that changes work as expected. This includes reviewing data and outcomes in other modules.

6.-Communication: Communicate planned changes to other users or teams that may be affected. This ensures that everyone is informed and can make necessary adjustments to their processes.

7.- Cross-Review: Collaborate with other model builders or Anaplan experts to review your changes and assess their potential impact from different perspectives.

8.-Change Log: Maintain a change log that includes details of what was modified and why. This facilitates traceability and troubleshooting in the future.

9.-Continuous Monitoring: After implementing changes in the production environment, continuously monitor results and be prepared to address any issues that may arise promptly.

10.Training and Documentation: Provide training and updated documentation to end users so they understand the changes and know how to adapt their processes accordingly.

"We are what we repeatedly do. Excellence, then, is not an act, but a habit." Aristóteles

I hope this helps!!!. Best

KirillKuznetsov

Hi everyone,

I like the approaches of every one of you who already shared your thoughts. Thank you for sharing!

Now to the question:

This always depends on what kind of changes are done, but generally, this is my way of thinking:

1. Take a backup of the module before making any changes.

Making a Copy and archive is a quick way to have both blueprint and data saved, but I have to admit that in smaller cases blueprint Export might be enough.

2. Reviewing the impact of changes on the module and other modules in the model before committing them.

I’d always make sure that:

a. All formula references to and from the module would not cause an error for this only change;

b. View-affecting changes such as dimensionality, new line items, etc. are silent though can be a cause of big disturbances in imports, filters and on the dashboards - all should be reviewed.

For example, if a change is in the module’s dimensionality (Applies to/Time/Versions) many things have to be checked:

• all references (to and from) might require additional mappings (LOOKUP, SUM, FIRSTNONBLANK, etc.) in the formulas;
• it affects imports into the module with new dimensionalities - all imports related have to be reviewed and mapping rules to be adjusted;
• filters in saved views and on the dashboards should be reviewed and reapplied;
• DCA does not break;
• Exports from the module also can be affected.

3. Testing the changes in a test model before deploying to production.

Very easy if you have ALM in your models.

4. Documenting the changes made.

Here you may say that "Anaplan is a self-documenting platform when the model is built in accordance with best practices". But there is nothing better than a self-check. So documentation is a way to recap what you have built and it helps to find what you have possibly missed at least from a technical point of view.

I have come up with my own checklist that I always go through before saying that change is completed. This is a kind of bureaucracy, but believe me, it works very well, especially with new model builders who are still learning. Using this checklist you go through each entity you have changed in Anaplan by hand (by attaching evidence against each of the points in any form you want). A quick glance at my checklist template in text form:

Best regards,

Kirill

kpasko

You can only maintain what is simple enough to repeat, therefore:

1. Dwell on a problem in your head for way too long and overcomplicate it by overthinking it outside of your working hours (just kidding, you can skip this one).
2. Backup your work.
3. Self-test your work in DEV.
4. Peer-test your work in DEV (if possible).
5. Push to from DEV to TEST and test your changes.
6. Push to PROD and confirm data continuity.
7. Document the applied changes.
8. Check your sanity levels.

Repeat every now and then, and you should be good 😅

pyrypeura

I'd like to add my contribution by describing my dream environment for doing continuous integration/continuous development(CI/CD) in Anaplan end. In this approach DTAP approach mentioned by @PhilippErkinger . In my dream approach the crucial parts of Anaplan model would have been identified and regression testing would have developed to cover important bits of the model. Regression tests would write to Anaplan cells with Transactional API, read other cell values with Transactional API and validate correctness of values. In overall flow of development to integration would go like this

1. Model builder would do changes in development
2. MB would unit test changes in development
3. MB would click a link that would trigger CI/CD pipeline (Link would be using AWS Lambda, Azure Functions or other similar solution enabling clicking a link triggering script)
4. CI/CD pipeline would sync changes from Development to Test
5. Regression tests would be run in Test
6a. Failed tests would end the pipeline and send MB report of failed tests via email - END OF FLOW
6b. Successful tests would continue the flow and send MB confirmation of successful tests
7. CI/CD pipeline would sync changes from Test to Acceptance and send Email to manager responsible of approving changes
8. Manager receives email with link to Anaplan and link to approve promotion of changes
9. When manager is happy with changes they click link to approve promotion of changes
10. CI/CD pipeline syncs changes from Acceptance to Production and sends email to MB team confirming that production has been updated with newest changes.

Flow described above also as flowchart below

jziemer

Thanks for all the comments above! It is worth a read through all of them if you are new to Anaplan and making changes to a production model. Much of this is repeat, but here are my thoughts on approach:

1. Be sure to understand the requested change, and what exactly the User wants to see.
   1. Is it a process change (this will likely require some change management/training outside of Anaplan)
   2. Is it potentially just a different view of an existing build? (Work with User to create a mockup)
   3. Is it a formula or dimensionality change? (whenever possible, have user give an example of the new formula and expected results that you test against).

BEFORE MAKING ANY CHANGES:

1. See @Tiffany.Rice and other comments above for an excellent plan of attack. Other tips:
   1. Understand the delta between current state and requested state of the model.
   2. Identify the appropriate "point(s) of change" within the model to most efficiently and effectively make the change(s). This takes a solid review and understanding of the User's process, the data flow within the model, and the dimensionality of the various modules in the flow. Tip: use "Referenced By" column in the blueprint view to understand the flow. The model Map can also be helpful it the model is not too complex.
   3. Understand all dimension lists involved in all the connection points from b. above. Will there be a change to the dimensions?
2. Once you identify where the changes need to be made, make sure you review the Actions and Pages that will be impacted by the change. This is critical because the "Referenced By" column in blueprint view do not identify Actions and Filters that may be impacted by changes:
   1. I export the "Imports" tab in the Action Settings into Excel so I can easily filter on the "Source Object" and "Target object" columns. I then filter on each module and list identified in 1) above to identify any actions that will be impacted by the changes. This is critical because the "Referenced By" column in blueprint view do not identify Actions and Filters that may be impacted by changes. Document any changes that will need to be made to action related lists and modules in your plan.
   2. Unfortunately, the "Used in Dashboards" column in the Modules settings has not yet been updated the New UX in Anaplan, so determining which pages will be impacted by the changes is cumbersome. From the Pages settings in the model, you can click on each page and then in the "Modules" tab on the right hand Pannel, you can then see which modules are on each page. Hopefully you know the App well enough to narrow down which pages to look through. Identify all pages that your changes will impact and review the views and filters on each to determine what updates need to be made based on proposed changes. Helpful tip for model builders: When you use a line item of a module as a filter for any page/view, use the notes column of the blue print to note that it is used as a filter in xx page. This will help tremendously in this process. Also, keep your module views up to date (clean out unused views; name appropriately)
3. Thoroughly think through a testing plan. Once I have updated my plan for making changes, I export the key modules/reports (data) using appropriate views so I can compare the new changes and ensure I did not cause unexpected changes to results.

ONCE READY TO MAKE CHANGES:

Again, read through all comments above for process guidance. I really like how KirillKuznetsov gfraviseo have laid the steps out in above comments. (e.g. back up model, have test plans, Understand ALM models and have a plan for revision tags, etc.)

Happy Modeling!

ryan_kohn

As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

The answer to this question is conceptually quite simple — in order to avoid unexpected results, you need to know what the expected results are!

Anaplan Governance

This is why you need a solid and consistent framework for your Anaplan governance. This may be @JaredDolich's corporate psychology vs. customer satisfaction approach, the Anaplan Way, the Anaplan CoE maturity model, or the concepts I've presented along with @kyle_welling_1 at CPX and Anaplan Live around Anaplan governance and CoE maturity. Or, most likely, some combination of the above that you fuse together into your Anaplan CoE Charter.

Model Building Standards

Once I know that I am building the right functionality for the right user at the right time, I find that focusing on model building best practices protects me from a lot of unintended consequences. My key focus area is following consistent naming conventions as well as the DISCO standard.

Why such a rigorous focus on standards?

I find that existing formulas and structures tend to get more robust over time, since they get used and tested more often. I want to leverage those existing structures whenever possible and avoid building net new structures that require net new tests to be created. This is much easier to do when those structures are easy to find.

Test-Driven Development

I think we are all aware that while solid governance and conventions are important, we also need to be brutally practical and get things done in order to satisfy our users.

One framework that I find helpful is test-driven development, which comes from the world of software development. In test-driven development, the idea is to build something that works first, and then improve it once you're done. This helps me to avoid making perfect the enemy of good enough.

Here is a good visual outline of test-driven development:

(source)

I also like this more fun visual presentation and it helps me remember each step!

(source)

Final Thoughts

The other posts in this thread are absolutely incredible and have a lot more detail about the practical side of things. I can't wait to here more from other posters!

Misbah

Wow…What great responses already. Anyway, let me keep it simple here. I divide my response into five categories i.e., Formula Change, Name Change of a Line Item, Name Change of Module/Saved Views, Deletion of Line Item and Addition of Line Item.

CHANGE	WHERE?	WHAT COULD HAPPEN?	WHAT DO I DO?
Formula Change	Line Item	May change the desired output	Check the "Referenced by" column in the blueprint and make sure all the lines referencing this line do not give unexpected results. End to End testing is the key Note: If this formula change is expected to touch more than 10 percent of the modules of the model I use "Copy and Archive" Option of PROD model before I push the change to PROD as part of Disaster Recovery Management
Name Change	Line Item	It could break Imports.	To test this I go to Actions-> Imports and take the dump of all my imports. I filter down on the Source Object column to find out the module of this line item and take all those imports and start editing to find out if the mappings look alright. Once I am done with Source Object I repeat it for Target Object
	Module and Saved View	It could make Source Objects of Imports outdated. However Source Labels don't change	I go to Actions->Imports-> Copy the Source Label of this import (where this Module or Saved View is being used). Go to Import Data Source tab and search for the copied Source Label. Edit it and hit ok. It updates the Source Objects of the Imports in question.
Deletion	Line Item	It may break Imports and/or Filters	Unless I know and Own the model I DO NOT delete line items. Reason could be that it may be in use for Filters or for Imports. If by any chance this was deleted there is no other way than to build that line item back and restore Imports and filters
Addition	Line Item	It could inadvertently become part of Line Item Subset which may throw the numbers off in downstream modules	I visit Line Item Subsets and make sure that "Include New Items" column stays unchecked

Misbah

Miz Logix

DeepakK

Wow! So much good stuff. Nothing big I can add.

But here is one I learned the hard way recently:

If there is a structural or composite list change, make sure to back up any user comments on those old codes. Not super hard since all you have to do is create the new code and export with it. Then import back into new model.

m.angeles11

Am impressed by the quality of a lot of the previous responses! Well done all!

As there have been lots of great answers already regarding non-formula related changes in a model, I will focus on a concept that reveals the impact of formula changes on other relevant modules in a model. I would have loved to say that I came up with this idea but the fact is, I have learnt this method from one of my previous client projects and have used this modified technique for another client model recently which works like a charm.

The Problem:

One of the most critical things to check when making formula changes to a model is reviewing the impact of the formula change(s) to other line items in the same module as well as other modules in the model. In most circumstances, when we make a formula change, we know (or are told by those requesting the change) what we are expecting to see in one or more modules after making the change and checking this is normally easy enough to do although at times can be time consuming depending on how many modules you need to check.

What we sometimes don't expect and don't see straight away is how a formula change impacts other modules in the model that we are not focussed on. To properly review the model for this, we would have to do a robust review of the entire model using techniques that have already been mentioned in the earlier posts… and this takes a lot more time to do! And when we make another change…. guess what, we have to do the same thing again! Painful!!!

A Solution:

The solution I am presenting here is something that I have implemented in a couple of recent projects. It has given the client transparency on the initial impacts of any model changes and are be able to more promptly test and confirm if changes made provide the expected changes.

It must be noted that this solution will take up additional workspace as it requires the creation of additional modules that will allow the variances to be exposed whenever a formula change is made. With this said, choosing the modules and line items that need to be checked is critical as it will have a direct impact to the additional workspace taken up by this solution.

The solution comprises of 3 key components:

1. Variance Check Summary module:
   • A module that will show all the Variance Check modules and which ones have a variance.
   • Only modules that are required to be checked (e.g. calculation, reporting, data export modules) need to be included. Deciding which ones to include will depend on which are key modules to users. A good guide will be the ones which are viewed by users on Apps as part of their results review process. Input modules generally don't need to be included.
2. Variance Check modules:
   • These modules are structurally the same (i.e. have the same lists) as the module (source) that needs to be checked but will only contain line items that need to be checked. In fact, they would normally be a direct copy of the source module but with modified line items.
   • Line Items will contain:
     • the same line items in the source module that needs to be checked; and
     • variance check line items for each line item being checked; and
     • a Boolean flag (e.g. "Variance Exists?" ) used to check if any variances exists in any of the line items being checked.
3. Actions/Process
   • An action needs to be built to copy the values of the line items that are being checked from the source module into the relevant Variance Check module so that the Variance Check module will have a static copy of the line item values that existed at the time the copy process is run (i.e. just before any formula changes are done to the model)
   • Variances in ALL Variance Check modules should be NIL after the copy process has been completed.

High-level Steps when making changes to model (after creation of Variance Check modules):

• Create a backup of the entire model
• Run process to copy static values from the relevant modules into the Variance Check modules
• Check that no variance exists in the Variance Summary module
• Make the required formula change(s) to the model
  • when making multiple changes, it is best that the Variance Summary module is checked for variances as each formula (or group of related/similar formulas) change(s) is(are) made so that it is clear that any variances were caused by the change(s) and not to do with other changes.
• Review variances and update formula changes as needed until ONLY expected variances appear
• Review and update App pages impacted
• Review and test any actions may have been impacted
• Deploy changes to UAT environment for user testing and sign-off

Example:

Below is an example of the Var Check Summary module, a Var Check module for one module, and the source module being checked.

Variance Check dashboard (using Classic Dashboard for simplicity)…

Var Check module (Blueprint mode):

Source module:

Final Notes:

• Comparing non-numeric values will be a bit more work but should still work at the child-item level.
• Comparing line items that are a subsidiary view is not supported by this solution as the copy process does not work in the expected manner for subsidiary view line items.
• Solution may not be practical for all models but could be applied to only the critical parts of the model if space consumption is an issue.
• Steps outlined in the solution need to adhere to Planual (obviously).

kavinkumar

"Great start and happy to share some ideas!

Here are my checklists for making changes to an existing module:

Changes to an existing module:

First and foremost, the step I would recommend is to make a copy of the module.

Note: This copy can be deleted once the changes have been successfully implemented (Still copy and archive recommended for future reference)

Changing the dimension of a module (e.g., changing the time granularity from Month to Week, L3 Product Family to L4 SKU, adding new dimensions, etc.)

[Note: In the case of modifying Anaplan Time Settings in a module header, ensure that all the required line item time granularities have also been manually set, or they will remain with the previous time settings created as a subsidiary view.]

[INPUT/DATA] The data stored in the module's line items that don't have formulas (manual input or loaded data) will be affected, as the system tries to equally spread the data that is already present in the line items to the newly updated dimensions. Hence, the proper data should be loaded once the module's dimensions have been updated.

[Formulas Update] The formulas or the results of calculated line item data will be affected, and sometimes the system will not allow dimension changes. Therefore, remove all the formulas, then modify the dimensions, and refer to the copy/backup module to replicate the same formulas with the correct mappings (using aggregation/time functions like SUM, LOOKUP, ANY, ALL, FIRSTNONBLANK, LASTNONBLANK, YEARVALUE, MONTHVALUE, etc.).

[Formula References] The calculated data present in the target modules (the line items present in the target modules referring to a source module where the dimensions are intended to be modified) will be affected, or sometimes the system may not allow modification of the dimensions in the source module. To overcome this, back up the formulas in the target module, remove all the formulas, change the dimensions in the source module, and then replicate the formulas in the target modules with the correct mappings (using aggregation/time functions like SUM, LOOKUP, ANY, ALL, FIRSTNONBLANK, LASTNONBLANK, YEARVALUE, MONTHVALUE, etc.).

[Saved Views Update] All the saved views in the module where we attempt to modify the dimensions will be affected. Therefore, after dimension modification, each saved view has to be verified along with the proper filters.

[Filters Update] All the saved views using a line item from the module (where we intend to change the dimension) as a filter will be affected. Hence, after dimension changes, all the saved views filter should be verified/updated. Also, the views published in the User Interface (NUX or Classic) using a line item from the module (where we intend to change the dimension) as a filter will be affected, so those views in the NUX should also be updated/verified.

[DCA Check] The DCA (Data Cell Access) of the line items in module would also be affected and verified to avoid any errors and to ensure proper read/write access to those line items.

[UX Update] All the views from the module (where we intend to change the dimension) published in the dashboards will be affected. Therefore, proper pivoting should be done, along with the proper filters if needed, after the dimension modification.

[Import Actions Update] The actions that use the module (where we intend to change the dimension) as a source or target will be affected. Hence, after the change, either a brand new action should be created or existing actions should be updated with proper mapping details.

Note: There could be instances where data is loaded from the module (where we intend to change the dimension) to other models. Hence, check the data flow from this model to other respective models and update the actions accordingly.

[Documents Update] In most cases, users are provided with a user guide to navigate and use the Anaplan UI screen. Hence, based on the modification, all the user guide screenshots and points should be updated to avoid confusion.

Changing the name of a line item/ Deleting a line item

[Import Actions Update] The import actions that use this line item as a source or target will be affected. Hence, all the import actions using this line item should be updated/verified after the name change.

[Documents Update] In most cases, users are provided with a user guide to navigate and use the Anaplan UI screen. Hence, based on the modification, all the user guide screenshots and points should be updated to avoid confusion."

Nishiket

Good to see many best practices from different members of Anaplan community.

Here are few best practices that I have seen or practiced.

Working mostly in Scaled Agile framework (SAFe), one thing is pretty much clear that development teams need clear guidelines to implement new work or changes so that the process is lean and up to the set standards of delivery.

Considering a complex scenario where Anaplan is not the only system of planning and relates to upstream and downstream systems, any changes should go through a pre-defined Impact assessment and effort estimates to plan the activities.

The impact assessment is usually done in tandem with other teams as well which includes IT/Planning and integration team of the source systems (Upstream) and IT/Planning and integration team of the target system (Downstream). It is not a very frequent case as most of the time the changes are limited to Anaplan however in a big transformation project it is good to keep such templates/practice handy so that impact assessment should include communications with other systems as well.

At the same time, it is also important to review the changes required in Anaplan Sticking to all the standard practices stated by Anaplan including references, imports, exports, filters, DCA , impact in the UX, Workspace size , performance etc. and communicate internally to all the builders and teams who are involved.

Another important practice should be version management within Anaplan using ALM. A record/Document of which changes are part of which release and using an appropriate naming convention and description for the Revision tags.

Changes should usually be started once agreed and approved from the concerned stakeholders. As a model builder one may or may not be aware of all the above stated processes but it’s good to have such an understanding at the ground level.

The last bit is testing the changes. It is good to have a testing environment where teams can test the changes and approve the changes to be released in the production environment.

TristanS

As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

Can't beat or not regurgitate what's already been mentioned above. so the perspective I would be providing is the methodology that I apply to balance what ideally should be performed vs what can pragmatically be performed given cost and time constraints that primarily drive the amount of effort which can be expended on any change. As a general rule, I apply a relevance based assessment on what needs to be performed and a risk based assessment on the level of rigor that needs to be applied. If there were 100 steps available to ensure changes didn't have adverse effects, I would only take the appropriate number of steps pragmatically feasible depending on the type of change being implemented.

Relevance based assessment:

Using some of the example's mentioned above, if I was only performing a line item name change I would only check if it was being used as a source in an action as this type of change can break imports. I would not be checking any impacts to DCA or filters as it would not be relevant. @Misbah has provided some very good relevance based steps

Risk based assessment:

This type of assessment is more subjective but have 2 main levers:

• Level of complexity -
  • e.g. does the data require multiple transformation steps within Anaplan before it can be consumed or is it just a single formula update requiring a single LOOKUP or SUM function
  • e.g. are we changing 1 line item vs several line items across multiple modules
  • e.g. does the model carry a high or low level of technical debt (revolves around current stability of the models design … is the underlying foundation of the model built with sticks, straws or bricks)
• Business impact -
  • e.g. the change will affect financial postings to the accounting ledger vs the forecast calculation will affect part 5% of information used for business planning vs the change will affect the filters used in the UX by admin users

A visual representation of Risk Based Assessment is provided below. It's a slight variation to @JaredDolich 2x2 impact effort matrix. I have deliberately marked some blocks grey as they are in reality subjective grey areas. If you had a low complexity but high business impact change, do you apply a high amount of rigor steps because it has a high business impact or low amount of steps given it is a low complexity change or would you apply a medium amount of rigor. The easy ones is where the intersection of complexity and business impact is the same. At a conceptual level, the amount of rigor expended on ensuring the quality of work is proportional to the level of risk introduced by the change

Examples of some of the steps I've taken using Risk Based Assessment are as follows:

• High level complexity and High business impact:
  • Example - We had a model which calculated financial accruals that was posted to the client's general ledger. Requirement changed the way accruals was calculated and needed updates to several modules
  • Steps taken:
    • We had 2 copies of the same model in a dedicated Test Workspace: one that had the most recent changes and another model before the change was made. We would execute parallel runs of both models with the same input and compare changes in the output to ensure the change yielded desired results without any adverse side effects
    • Execution would run all the processes that generated all financial accruals not just the specific action related to change made
    • Design documentation update
    • Comprehensive test planning and scenario documentation prepared
    • Code peer review
• Low level complexity and Low level business impact
  • Examples
    • Add a new line item to a module that is informational data to be displayed in a UX page. Formula used is a single Lookup function.
    • Update the dimension used in a module from using a full list to a list subset. The list is a standard list (not a numbered list)
  • Steps taken - Unit Test only
• Medium level complexity and Medium level business impact
  • Example - Current system enables a user to create a marketing campaign for a product for "any" customer. The requirement is to filter products that can be viewed/selected for a campaign based on whether the customer selected for the campaign has a pricing condition against the product. Requires addition of new and updates to existing modules. Creation of new processes/actions
  • Steps taken -
    • Perform a "copy and archive" of the model prior to the change
    • Design documentation update
    • Light weight test planning and scenario documentation

AlejandroGomez

As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

Lets start with 5 premises:

1. Anaplan stands out for being an extremely flexible and collaborative platform
2. Changes are the only constant in a VUCA world.
3. Anaplan models are aimed at replicating, explaining and predicting small portions of the world where companies operate
4. Therefore, changes in the Anaplan models are constant, to keep plans relevant and close to the execution layer and reality
5. Changes must be documented, so the Model can be properly maintained (performance data and calculations wise) and users trust their numbers in the model (adoption)
   1. the Anaplan environment, users and model builders alike.

With this premisses in mind, makes perfect sense to strive for a methodology that satisfies 2 purposes:

a) allows the avoidance of unexpected behaviours in our models (unexpected changes in performance, size, appearance and outcome)

b) and, at the same time, is a nimble and transparent methodology! Anaplan and the Anaplan way follow an agile methodology. We cannot implement Anaplan in an agile way and then get bog down with a small change!

When adding a new requirement (and therefore adding / modifying lists, modules, actions and pages) the unexpected behaviours from the user perspective can stem from four different parts:

1. Calculations: downstream line items referring to the changed/new line items
2. Filters: either the filter function is changed or the modules being filtered
3. Actions: imports taking as source/target some of the changed/new line items
4. User Permissions: if we are adding new lists and modules, be sure to update the users permissions so they can read/write the new elements. This includes DCA.

At the moment, in order to understand the model and anticipate the impact of new requirements (especially when the extension of the impact is considerable), I craft / update my own Directed Acyclic Model Diagram in Mural, Visio or similar by looking at the available information in every Anaplan Model.

Calculations: Looking at the "Referenced by" field of the modules page / blueprint

Actions: looking at the "Imports" tab within the "Actions" menu

1. Permissions: usually is comes down to update the Role permissions to any new module/page being created.
2. Filters: This is usually the trickiest part and involves a lot of manual effort. No silver bullet for this
3. Pages: finally, behaviour in pages can be the result of all of the above. So I just relay on unit testing and user testing to ensure that nothing odd is going on here. Which specific pages to test? Pages where the modules identified in the first step are used.

I would like to conclude with a suggestion:

Anticipating changes, documenting models and tracking dependencies could be much easier with a more robust and detailed Anaplan Model Map. This could be the perfect tool that will enable an agile and robust methodology to do all the work described in this post and answer the question of the challenge.

There are a few ideas in idea exchange asking for including the filter dependencies, data actions dependencies, getting more insights in the model map. Please, make the model map great again

alexpavel

It is always tricky with the modifications made in a module and to check what is the impact of the change.

I think one of the answers could be: depends on what modification has been made.

It is also depending in which moment the modification is made:

It’s during the development or before UAT: the impact is much less important to evaluate.

It’s on a model “Live”: there is needed much more attention if something is changed in a live model.

Below are some of the modifications that can be made in a module and what can be followed:

Change Formulas

I presume that the main reason for the question is related to the modification of a formula in a line-item in a more consolidated moment (like after “Go-Live”).

Evaluate the impact by using the obvious tool: the “Referenced by” column of the line-item

It is also necessary to check also all the line-items from “Referenced by” if they also are input in other formulas as well (2nd, 3rd level impacts: daisy chains will exist even it is advised to avoid it).

Make a list with the line-items impacted considering also the dimensionality of the line-item. I think it’s important to consider the default behavior of the formulas when no LOOKUP or SUM (or other aggregation method) is used in target line-items.

If the modification of line-item needs to impact from now on forward, but needs to have the same formula based on some criteria, it can be managed like the following:

Create a Boolean based on the criteria ( like previous months, or previous versions)

Create a formula like: If “Flag Old Formula” then [Old Formula] else [New Formula]

Change dimensionality line-item

This could be quite a dramatic change that Anaplan handles quite well with the mention that the previous input data will not be maintained correctly and need to be fully reviewed.

If the line-item changes dimensionality (added or removed a list) it needs to be considered default formula behavior if lists are added or removed to a line-item and no method is used (like LOOKUP or SUM) :

If a list is added to a source line-item all the downstream target line-items will consider the Top Level value of the new added list in the source. If this is not the desired behavior and the new list needs to be also added in the target line-items, after the modifications are made also in target line-item, remove the Top Level element from the new list and verify if there are errors.

If a list is removed from a source : the same source value will be considered across all elements of the additional lists in the target line-items.

Rename a line-item

It seems that it’s the easiest modification that can be made to a line-item. Anaplan handles well the renaming of a line-item as all the formulas impacted will automatically change and there is no need to check any impact from the calculation point of view. There are some other impact areas to be reviewed:

If the line-item is used in as a source for an import action and the line-item is manually mapped to another line-item target, the import action needs to be changed and the mapping source-target line-item needs to be re-done. WARNING: Without any intervention the source data of the renamed line-item will not be copied into target line-item. This is quite old bug that is not (yet) solved.

Consider line-item rename impact also for exports to external systems than Anaplan and announce the downstream systems that a rename was made.

It’s more tricky to understand if a line-item is used in import action from another model or to external systems and this is where a naming convention of the saved views should play an important role.

Hope it helps

Alex

Bishalpilley

As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

The first step is to be secure. So, take a copy of the module.

Then see the line item reference, have to do a impact analysis if changing some formula.

Need to check the line item may have refer in any other module,

If there are any name changes then Action may affect some item will be unmapped and action will fail.

In case of deletion it may affect some filter.

so, these are some of the points which we need to take care before changing anything .

Thanks,

tscott

So many great responses here already so I'll provide a less practical perspective.

In my opinion I think it's important to approach changes with a fearless and pragmatic mindset. Don't be overly cautious and waste time analysing every nuance of a model before feeling ready.

You'll often simply not have the time to get 100% confident in a change, especially if it's a complicated part of the model. Personally I think trial and error is the most effective and efficient method, especially if you ensure you keep good track of what you are doing.

Keep in mind what it is your trying to achieve, and remember, you can't really break anything.

Akhtar.shahbaz

Hi All,

I think before making any changes first we need to understand the requirement, logic & its impact to the downstream. I believe if the model is designed as per best practices keeping in mind about PLANS & DISCO methodology and also below mentioned best practices then it would be very easy to change the formula as Anaplan known for its flexibility.

• Calculate once, and reference many times.
• Don’t daisy chain

• OEG Best Practice: PLANS: This is how we model :

https://community.anaplan.com/discussion/33530/oeg-best-practice-plans-this-is-how-we-model

• OEG Best Practice: Formula structure for performance

https://community.anaplan.com/t5/Knowledge/Formula-Structure-for-Performance/ta-p/33177

• OEG Best Practice: Formula optimization in Anaplan

https://community.anaplan.com/discussion/41663/oeg-best-practice-formula-optimization-in-anaplan

• OEG Best Practice: Reduce calculations for better performance

https://community.anaplan.com/discussion/33667/oeg-best-practice-reduce-calculations-for-better-performance

Note:

Any changes to logic or formula are very easy & doable in Anaplan in very less time until & unless the dimension of the module is the same but if there are any changes to the dimension then it has an impact to the downstream of the model & it will impact all reference modules.

Alessio_Pagliano

Question for the Q&A Challenge: As an Anaplan model builder, what steps do you take to ensure that changes you make to an existing module don't create unexpected results in the module you made changes to and in other modules?

Hello everyone! Just in time for my submission.

I have returned from my time off and have been busy catching up.

First and foremost, I would like to express my gratitude to everyone for their impressive contributions. It is evident that this new community content and structure has the potential to become something significant and incredibly interesting.

After skimming through the remarkable responses, I find it challenging to add anything that hasn't already been mentioned. In fact, many of the replies have already covered the content I had in mind. To begin this challenge, I had planned on starting with the classic but undeniably true statement, "it depends!" which I'm sure most, if not all of us, are familiar with.

Additionally, I had considered organizing my answer around the following topics

I then began contemplating how to express these steps, possibly offering a fresh perspective and creating something that would resonate with the entire community. How could I share my extensive collection of mistakes 🤣 wisdom in a way that would be applicable to any project environment? Could I create something valuable for individuals at all skill levels, from beginners to expert Anaplanners? Additionally, would this be beneficial for smaller projects as well as larger, fully operational projects with multiple builders ? Would it be effective for new teams, experienced consultants, teams with a Center of Excellence (CoE), and teams without a CoE?

At that moment, I believed I had a brilliant concept: to develop a template/checklist that can be used repeatedly and covers a wide range of topics. This template would include:

• An initial reference to determine the suitability of a specific topic based on simple, medium, and complex changes.
• Specific templates, references, and guidelines for each topic.
• Best practice tips.
• Links to relevant community content.

Although it required significant effort, I hope that everyone can discover valuable insights, ideas, and references from it. They can adopt, modify, and adjust it according to their specific requirements.

This is what the summary page looks like, each topic would have have its own tab with the details :

In a nutshell, you will find the most helpful tips on Tab #2, with content that has pretty much been covered in various other posts

Please find the template attached.

Anaplan Community Challenge_Alessio_SEP23_Change Template.xlsx

Thanks!

ankit_cheeni

Fascinating answers! Working with a CoE client, I often come across this kind of request and here is what I usually try to do(without repeating the best of other answers):

1. HAVE A DEDICATED INTAKE PROCESS:
   1. I cannot stress this enough! Have an intake process and train the whole team to follow that. Usually, we have model owners and process owners who come up with requests and the role of an SA is to then take it through the intake process.
      But every once in a while, someone who is not a process/model owner from the client would want something "urgent" that is "not that difficult to do in Anaplan" and there is one enthusiastic model builder who would let the request creep out of the intake process causing the ask to fall out of the workflow.
      
2. UNDERSTAND THE BUSINESS IMPACT OF THE CHANGE:
   1. Usually, the model builders get the tasks in a very technical language that deprives them of a holistic understanding of the impact the change will cause.
      The new line item is just to show the client what the last year's demand was or is the new line item going to change how we are disaggregating forecasts to a lower level?
      The better the model builder understands the WHY, and the impact of change on the business, the better they'll be able to gauge what kind of changes they should make.
      
3. TECHNICAL ASPECTS OF THE CHANGE:
   Okay, the ask came through the intake process and we do understand why we are making the change. If these two points are followed, the only thing left is the actual implementation. This is what I think @Misbah has summarized very well and I would follow that to the T. A couple of pieces of advice on top of his points:
   1. Formula Changes: If there is a formula change and adding a line item is not too size-expensive, create test line items instead of making the change directly. This gives you a chance to look at old vs. new side-by-side. Reduces the chances of wrong summary methods and daisy chaining since you are starting from scratch. Once the changes are finalized and references checked and end-to-end testing is done, do not forget to delete the test line and add the old formula in notes.
   2. Adding a new line item for Imports: Definitely update saved views to "Show" the required line items. That being said, I have come across instances where people use one saved view for multiple imports and your changes might not make sense for the other imports. Definitely check the imports tab under actions to ensure your changes don't break any other action.

I think the other answers cover all other technical aspects really well. This was a good exercise and I definitely find value in going through all the answers!

TimothyThomas

As many others have said, what incredible responses so far! In the interest of not repeating many helpful recommendations already mentioned, I will discuss my ideal way of testing these changes: having a full-cycle ALM environment, including not just a Dev model, but a "QA" model which serves as an in-between model sitting between Dev and Prod.

This sort of environment of course requires that you have the space available to have all 3 of these model types. Ideally, the Dev model does not contain the data out in Prod as it is a waste of space. This makes testing your changes difficult as once a change is implemented, you may not know how it will affect actual numbers until you push it through to Prod. However, if you have a QA model, you can keep a certain amount of real data in this model (enough to test with at least) and you can push your changes to QA before pushing to Prod.

Once you have pushed your changes through to QA, of course follow all of the best practices which have been mentioned here: formula tracing, snapshotting with variance reporting, import checking, etc. However, this is very useful as it helps you avoid the "Oh sh**" moment when you have pushed through a change to the Prod environment which has an unintended consequence!

rob_marshall

Planning? Testing? Where is the fun in that? That isn't living life to the fullest! There is nothing more fun than making changes in a model on a Friday/over the weekend/right before you go on vacation without telling anyone and without documentation and seeing what happens on Monday morning. Just push the buttons, see what happens, and hope for the best!!!

Sadly, I have seen a lot of what I just wrote and it gets people into a lot of trouble, for obvious reasons. So many great ideas and techniques described in the previous answers that I won't parrot here, but there is one thing I will add. Volume!!!

If you are creating a new process or updating a current process (in a Dev environment), try to mimic the amount of data volume this process will encounter in the Prod environment. Will your brand new Rank() or isfirstoccurence() formulas still work when you sync to Prod? What will the model/module/line item performance be like? How big will the model/module/line item be with Production data? I have seen some very elegant solutions created in a Dev model, but once it gets to Production, it sucks the life out of the model. I have seen line items in Dev around 100M cells, but in prod, it either goes over the line item cell threshold (2^31 - 1 or roughly 2.147B cells per block) or blows the module up over 10B cells.

Again, excellent answers above, but please consider the volume of data during testing as one of your levers.

Rob

matthewreed

The comments in this blog have become their own reference tool that a lot of us will refer to in future no doubt! Not sure there is much more I can add but affirming one of the tips that was given here that I also use, and that's not deleting line items immediately. Creating an 'Archived' no data line item, and moving the deprecated line items below it during module change may help as a reference until you know their dependencies have been removed and you no longer need to refer to that original item - even just for context.