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

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

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. 😎

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!!

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.

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

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

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!

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.

"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."

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

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

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.

Thanks!

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!