-
The Sales Crediting Journal: From concept to implementation
Author: Dhruv Sabharwal, Certified Master Anaplanner and Solution Architect at Alpha FMC.
During Sales Performance Management implementations, I've noticed that teams often spend significant time discussing quotas, territories, and incentive compensation plans, but very little time discussing sales crediting. Yet when questions arise about who should receive credit for a deal, the conversation quickly becomes much more complicated than expected.
This is where a Sales Crediting Journal becomes valuable.
Simply put, a Sales Crediting Journal is a structured record of how sales credit is assigned across participants involved in a transaction. While incentive compensation determines how people are paid, the crediting journal establishes who receives recognition for the sale. In my experience, separating these two concepts leads to a more flexible and maintainable solution.
Consider a common enterprise sales scenario. A deal may involve an account executive, a solution consultant, a partner manager, and an overlay specialist. Each role may be eligible for a different type of credit. Some organizations assign 100% credit to the account owner, while others split credit across multiple participants. As sales organizations grow, these rules become increasingly difficult to manage directly within compensation calculations.
A dedicated crediting journal helps address this challenge by creating a single source of truth for credit assignments. Instead of embedding crediting logic throughout multiple calculations and reports, organizations can centralize the process and maintain a clear record of how every allocation was determined.
Capturing this information creates a reliable foundation for reporting, auditing, and incentive compensation. From a design perspective, I find it useful to think about the solution in four layers. Transaction data is first received from source systems such as CRM platforms. Business rules are then applied through a crediting engine that evaluates ownership structures, territory assignments, overlays, and other sales policies. The resulting allocations are stored in the crediting journal, which then becomes the primary source for compensation calculations and performance reporting.
One of the most overlooked benefits of a crediting journal is audit-ability. Territory changes, organizational restructures, and compensation plan updates occur regularly. Without a historical record of credit assignments, it can be difficult to explain why a particular individual received credit months after the original transaction occurred. A well-designed journal provides that traceability.
When implementing this capability in Anaplan, I have found that flexibility is often more important than complexity. Business rules will change. New sales roles will be introduced. Compensation plans will evolve. Designing a configurable framework from the start typically delivers more long-term value than building highly customized logic for a specific use case.
The Sales Crediting Journal may not be the most visible component of an SPM solution, but it often serves as the foundation for trust in the overall process. When stakeholders can clearly understand how credit was assigned and why, discussions become more productive, disputes are reduced, and compensation calculations become easier to support.
Below is a sample of a simple sales crediting journal highlighting different types of crediting entries:
In many ways, successful incentive compensation starts with successful crediting. The Sales Crediting Journal is the mechanism that connects the two.
In Anaplan, I typically build the Sales Crediting Journal as a dedicated transaction-level module, with line items capturing the credit recipient, role, credit type, credit percentage, credited amount, effective date, and the business rule that determined the allocation. This level of detail provides a complete audit trail while supporting scenarios such as split credits, overlays, retroactive adjustments, and manual overrides.
A key design principle is to separate the crediting engine from the crediting journal. The crediting engine evaluates configurable business rules, while the journal simply records the outcome. This makes the solution easier to maintain, as changes to territories, sales hierarchies, or compensation policies can often be handled through rule updates rather than redesigning the model.
Anaplan's multidimensional modeling and calculation engine make this approach particularly effective. By leveraging dimensions such as Opportunities, Credit Recipients, Credit Types, and Time, the journal can scale efficiently while supporting flexible reporting and drill-down capabilities. Combined with role-based security and a transparent audit trail, the Sales Crediting Journal becomes a trusted source for downstream compensation, reporting, and dispute resolution.
Questions? Leave a comment!
-
Improving planning adoption beyond technology
Author: Pradip Kakade is a Certified Master Anaplanner and Sr. Principal Consultant of Enterprise Solutions at Genpact.
Every planning implementation begins with excitement. The business has invested in a new planning platform, requirements are complete, the project team is aligned and go-live is circled on the calendar. Then comes the moment every implementation team waits for: "Congratulations! The solution is live." For a while, everything feels like success. A few weeks later, however, another conversation often begins: "The model looks great, but many planners are still maintaining their own spreadsheets." I've heard this more than once during my career, and it taught me an important lesson. Technology can enable planning, but it doesn't guarantee adoption.
Looking back at different planning implementations, I don't remember the projects because of complex formulas or sophisticated model designs. I remember them because of the people involved, the conversations we had, and the small decisions that helped users trust the solution. Those experiences changed the way I approach every implementation.
Start by understanding people, not the platform
One of the first questions I ask during discovery workshops is simple: "Walk me through how you plan today." Not because I want to recreate the existing process, but because I want to understand where people struggle. Where do approvals get delayed? Which reports are manually prepared every month? Which numbers are questioned every planning cycle? These conversations reveal much more than a requirements document ever can. Technology should improve the planning process, not simply digitize it.
Don't wait until UAT to involve users
I've seen projects where business users first experience the solution during User Acceptance Testing. By then, it already feels like someone else's system. Instead, I prefer involving users throughout the journey. We discuss wireframes before dashboards are built, review prototypes instead of waiting for finished functionality, and collect feedback early and often. One of my favorite observations is this: People rarely resist change; they resist being excluded from it. When users contribute to the solution, they naturally become its advocates.
Every demo should build confidence
A demo isn't just about showing new functionality; it's about answering one question: "Is this solution going to make my work easier?" If users leave a session feeling more confident than when they arrived, the project is moving in the right direction. Small improvements delivered consistently often create more excitement than waiting months for a perfect release. Early success builds momentum, and momentum builds adoption.
Training should feel familiar
One mistake I've made earlier in my career was focusing too much on explaining features. Users were polite and they listened carefully, but afterwards they still asked, "Can you show me how I complete my monthly forecast?" That question changed how I think about training. Executives need business insights, planners need practical examples, and administrators need confidence to support the solution. Everyone learns differently because everyone uses the platform differently. Training becomes much more effective when it reflects real business scenarios.
Trust is built one number at a time
The first question after go-live is rarely about calculations. More often it's, "Why doesn't this match my source report?" If users don't trust the numbers, they won't trust the platform. That's why validation, reconciliation, and transparent assumptions are just as important as dashboards and visualizations. Trust takes time to build, but it takes only one unexplained variance to lose.
Go-live is not the finish line
One phrase has stayed with me throughout my career: "Go-live is the beginning of the relationship, not the end of the project." Some of the most valuable improvements happen after deployment. A planner suggests a simpler workflow, a finance manager requests a better variance view, or a sales leader identifies a report that saves hours every month. Continuous improvement keeps the solution relevant as the business evolves. I've come to believe that people don't adopt planning platforms because they are powerful. They adopt them because they make every day planning easier.
Create champions, not just users
Every successful implementation I've been part of had a handful of business users who genuinely believed in the solution. They answered questions before the project team could, encouraged colleagues to try new processes, shared ideas for future enhancements, and became trusted voices within their own teams. Those champions often had a bigger impact on adoption than any formal training session.
A lesson I'll continue to carry forward
When I first started working on planning implementations, I believed success depended mainly on delivering the right solution. Today, I see it differently. Success comes from helping people feel confident enough to leave old habits behind. The platform matters, the model matters, and performance matters. But lasting adoption comes from listening, collaborating, building trust, and improving continuously.
The next time someone tells me, "The implementation is complete," I'll probably smile and ask one more question: "How are the users feeling about it?" Because, in the end, the success of a planning transformation isn't measured by the sophistication of the model. It's measured by the confidence people have in using it to make better decisions every day.
-
Multi-level bill of materials explosion or breakdown
Author: Alexandru Pavel is a Certified Master Anaplanner and Solution Architect at Keyrus.
In manufacturing, supply chain planning, and production management, it is often necessary to determine the quantities of raw materials required to produce a finished good.
This process, commonly referred to as BOM (Bill of Materials) Explosion or BOM Break-down, transforms a multi-level product structure into a clear view of the base materials needed for production.
Because a finished good may contain several levels of intermediate products, sub-assemblies, and components, the BOM structure can become deeply hierarchical, making it difficult to calculate material requirements.
Anaplan provides an effective way to solve the BOM Explosion challenge by leveraging its calculation engine, multidimensional model structure, and dynamic lists.
Instead of using recursive database queries or external processing tools, the BOM break-down can be performed directly within the Anaplan model.
1. BOM breakdown: general considerations
The purpose of the BOM (bill of materials) "explosion"(break down) is to determine the required quantities of base components (base materials) needed to produce a finished good (SKU – stock keeping unit). This process accounts for the fact that a finished good's recipe may include sub-products, which themselves may have recipes containing base components or additional sub-sub-products, and so forth.
As a result, a finished good can have multiple levels of break-down depending on the number of sub-products involved in the recipe.
The challenge lies in the fact that the number of levels is not known in advance.
Therefore, it is necessary to remove the sub-products from all levels, leaving only the base components in the finished goods recipe and to recalculate the quantities of the base elements from the sub-products recipes across different levels.
The Base Materials/Base Components refer to the fundamental raw materials or primary components used in the manufacturing or assembly of a product. These materials serve as the foundation for creating sub-assemblies, parts, or the final product (finished goods). In terms of hierarchy, they are the elements that do not have any children.
The following solution defines a method to dynamically generate elements in a list for each level.
The solution starts with the definition of a maximum number of levels. These should be sufficient to cover all recipes for all finished goods.
However, if another additional level is necessary, the solution allows to add this level by simply pushing a button to generate the additional elements in the break down structure and to make small adjustments to the formula to consider this new level. Namely:
* Add a new line-item for the additional BOM level (Usage LV1, Usage LV2, Usage LVx)
* Change the final formula for the demand to consider the new line-item (Usage Final)
The final result of the BOM Explosion can be seen in the below table, where all the Levels are “siblings” under the same Finished Goods code.
2. BOM file structure
A BOM file could have the following parent-child structure.
The primary key of the file is the combination of Material and Component columns.
The columns are:
* UoM Mat: Unit of Measure for the Parent related to the column “Base Quantity”. This can be a Finished Goods (FG) or a Sub-Products (SUBP)
* Material: the Parent Code ( FG or SUBP)
* Component: the Child Code. It can be base Materials (MAT) or Sub-Products (SUBP)
* Base quantity: is the quantity the result for the Parent
* Quantity: is the quantity of the Child (Component) to generate Base Quantity of the Parent.
* UoM comp: is the Unit of Measure of Component (Child) related to the Quantity.
BOM levels explained:
* Level1 (L1): Contains all the Components (Base Materials and Sub-Products) that are part of a Finished Goods Code (FG01).* Example: The FG01 has components Base Materials MAT01, MAT02, MAT03…MAT12 and Sub-Product SUBP01.
* Level2 (L2): Contains all the Components (Base Materials and Sub-Products) that are part of a Sub-Products present in Level1 for a Finished Goods (SUBP01).* Example: The SUBP01 has components Base Materials MAT02, MAT13, MAT04, MAT14 and Sub-Product SUBP02.
* Level3 (L3): Contains all the Components (Base Materials and Sub-Products) that are part of a Sub-Products present in Level2 for a Finished Goods.* Example: The SUBP02 has components like Base Materials MAT15, MAT01, MAT14. I
* Level4 (L4): Contains all the Components (Base Materials and Sub-Products) that are part of a Sub-Products present in Level3 for a Finished Goods.
And so on. The levels can continue under a Finished Goods until the most detailed level of the Sub-Products that contain only Base Materials is broken down.
In the above example, the Finished Goods FG01 has only 3 Levels of BOM Explosion as SUBP02 contains only Base Materials. However, potentially SUBP02 can contain any number of other Sub-products and other Base Materials.
3. Main lists
* #BOM Upload Data: numbered list where the BOM file is uploaded. Follows exactly the BOM file structure.
* PR2 - SKU Finished Goods: indicates what are the Finished goods (SKUs) that can have Sales and for which we need the “explode” the recipes until the Base materials. This list could have multiple levels. The list could have a parent list like “PR1 - SKU Product Category”. The codes of this list can be found in BOM file in the column Material (Parent).
* MAT2 - Base Materials: indicates what are the Base Materials that are used in recipes of Finished Goods and Sub-products. This list could have a parent list “MAT1 - Base Materials Group”.
* PR3a - FG SKU-Material: Combination List that concatenate Finished Goods (FG) and Base Materials (MAT) resulted from the full explosion of all BOM levels. It has as parent list “PR2 - SKU Finished Goods”. It will be used to aggregate data from the BOM ALL levels Explosion considering only the Base Materials from all the intermediary levels.
* #PR3b - BOMX ALL Levels: Combination lists where are “exploded” all levels of BOM file for every Finished Goods (SKU). It has as parent list “PR2 - SKU Finished Goods”. The population of this list is the main goal of the BOM explosion.
* BOM ALL Mat+Components: a Flat List to gather ALL codes received from BOM file in both columns “Material” (Parent) and Components (Child). It will contain all the Finished Goods, Base Materials and Sub-Products.
* BC1 BOM Upper Level Flat: technical list updated (step-by-step) with all the sub-products of the next level explosion. In combination with #BOM Upload Data will be used as main tool to generate the next level
4. Main system modules
4.1. SYS01 PR2 - SKU
Generic Finished Goods system module:
4.2. SYS02 PR3 - FG SKU-Material
Combi SKU Finished Goods – Base Materials, containing all the Base Materials from ALL BOM levels explosion, excluding the Sub-Products.
4.3. SYS03 MAT2 Materials
Base Materials system module with their properties:
4.4. SYS20 BOM ALL Mat+Components
All Codes present in BOM file: Finished Goods, Sub-Products, Base Materials.
Condition to be Sub-Product: in Code present in BOM file in both Parent (Material) and Child (Component) columns.
4.5. SYS23 Conversion UoM
Conversion factors between different UoM’s
Used to convert the quantities, if different UoM is used for the same Component in different BOM Levels.
5. BOM explosion modules
5.1. BM00 BOM DataLoad
* Based on the list “#BOM Upload Data”
* Contains the BOM File information
* Used as source for quantities for ALL the levels
* Source to update the list BOM ALL Mat+Components
* Used to create the Level1 (L1) explosion for the Finished goods, what are their 1st level recipe
5.2. BM01 BC1 BOM Upper Level Flat
* Based on the list “BC1 BOM Upper Level Flat”
* Technical module that contains the latest Sub-Products (upper level) elements.
* The list is deleted and updated with the next level Sub-Products
In the below example are present the L2 Sub-Products as base to generate the Next Level explosion (L3):
5.3. BM02 Create BOMX2 for UpperLevels
* Based on the lists #BOM Upload Data, BC1 BOM Upper Level Flat
* Technical module used to create the Next Level Explosion level in the target list #PR3b - BOMX ALL Levels
Example: for all the Level2 Subproducts, it will be generated from BOM file the L3 (exploded the recipes of the sub-products).
5.4. BM03 PR3b BOM Explosion ALL Levels
* Based on the list #PR3b - BOMX ALL Levels
* It contains all the BOM explosion level.
* Main calculation model: the main purpose of the BOM explosion solution
* It is generated from the module “BM02 Create BOMX2 for UpperLevels”
* For each intermediary level, the corresponding "parent" element (the sub-product) is specified in a line item (AN Upper PR3b BOMX).
* Every Usage LVx uses the result of the previous level (ex: Usage LV7 uses in the formula Usage LV6) using the LOOKUP of the “parent” element of the previous level(AN Upper PR3b BOMX). This is why if an additional level is needed, it is needed to add a new line-item Usage LV8 in the module with its formula.
* “Usage Final” is the line-item that contains the quantities from all the levels considering only the Base Materials from all the BOM levels for a final product (finished good). It is the sum of all Usage LVx, without considering the intermediary levels (the Sub-Products). When a new level is needed (ex. Usage LV8), it is necessary to change the formula in “Usage Final” to add the new line-item.
5.5. DEM02 FG SKU-Material
* Based on the list PR3a - FG SKU-Material
* Contains unique combinations of the Finished Goods with Base Materials• Aggregates the Usage Final of every Based material for a Finished Good from the module
* The demand for each material under a finished good is calculated by multiplying the Usage Final by the Finished Goods quantities (Production Volumes).
6. BOM explosion mechanism
The BOM Explosion mechanism has these main steps:
* Upload the BOM File and populate the module BM00 BOM Datatload
* Populate the Level1 BOM explosion elements in the list #PR3b - BOMX ALL Levels
* Identify the max Level explosion in the list #PR3b - BOMX ALL Levels and what are the Sub-Products that need Next Level explosion
* Delete all elements in the list BC1 BOM Upper Level Flat
* Populate the list BC1 BOM Upper Level Flat with the Sub-Products from the Step 3.
* Populate the list #PR3b - BOMX ALL Levels with the next level explosion by filtering data from the module “BM02 Create BOMX2 for UpperLevels”
Repeat Steps 4 to 6 until no elements will be available in Step 6.
In Anaplan, there is no built-in command for creating iterations with an unknown number of steps (such as DO…WHILE loops). This is why the steps 4 to 6 can be grouped in a process and the users can manually push the button to generate additional levels until all the sub-products are “exploded” to the base-material components.
Other options to simulate automatic loops, but with known number of iterations:
* Use CloudWorks to schedule the same process periodically multiple times.
* Create different actions for every steps with exactly the same filters, but using different saved view names to duplicate the Step 4 to 6 and add them in the same process.
7. Conclusion
The BOM Explosion solution provides a scalable and flexible approach for transforming multi-level product recipes into a complete list of base materials required for finished goods production. By recursively breaking down all sub-products and consolidating the resulting base components, the model ensures accurate calculation of material requirements regardless of the complexity of the product structure.
A key advantage of this approach is its ability to handle an unknown number of BOM levels through a dynamic design. The predefined level structure can be easily extended whenever additional hierarchy levels are encountered, requiring only the creation of a new usage line item and a small adjustment to the final demand calculation. This minimizes maintenance effort while preserving the integrity of the explosion logic.
Ultimately, the solution delivers a flattened BOM structure in which all required base materials are represented directly under the finished good, with quantities correctly aggregated across all levels of the hierarchy. This enables more accurate demand planning, procurement, inventory management, and production planning by providing full visibility into the true component requirements of each finished product.
-
How AI found my Polaris model's breaking point in an hour — a job that would have taken 60
Author: Vamshidhar Reddy Peesari is an Anaplan Solution Architect in the BI Planning Center of Excellence, specializing in large-scale Polaris models and model governance.
If you build on Polaris, you live with the number 64. The Dimension Index Total — the sum of the index scores of every dimension on a line item — is the engine's one hard ceiling. Cross it and Anaplan simply blocks the change: line item is too large.
Checking one line item against the Anapedia table takes five minutes. My problem was a consolidation model with 671 modules and about 6,600 line items, and a question no one could answer: which line items are sitting close to the ceiling, and which growing list pushes them over first?
Nobody audits that by hand. So I didn't. I gave the problem to Claude, and I want to share how it went — including the part where I told it the results were wrong.
The setup
I never gave the AI access to my model. Three standard blueprint exports were enough: Modules (Applies To, Time Scale, Versions), General Lists (item counts, parent hierarchies, top levels, subsets), and the full Line Items blueprint.
One thing I'd insist on if you try this: before any math, make the AI state the scoring rules and cite its source. Claude pulled the current Anapedia page and confirmed the details that are easiest to botch — composite hierarchies count the list plus all parents plus the top-level item, Time's member count includes summary periods, and Time and Versions score like any other dimension. Audit the method before you audit the output.
From there it parsed every Applies To string, resolved the hierarchy chains, handled the export quirk where a dash on a line item means "inherit the module's dimensionality," skipped the 737 No Data line items that hold no cells, and produced a DIT for all 5,917 real line items — each one broken down dimension by dimension.
The part where I said "that's wrong"
The first pass flagged a bunch of line items over 64. My reaction was probably yours right now: impossible — the model runs.
Here's the thing: we were both right. Subset member counts don't exist anywhere in a General Lists export — only the subset names do. So every ss. dimension had been scored at the full parent list size, clearly labelled as an upper bound. A working model sitting "above" that bound isn't a contradiction; it's a measurement. It tells you exactly how many index points your subsets must be saving.
And the pattern confirmed it: every single flagged line item had at least one subset dimension. Not one line item built purely on full lists was over the limit. That's exactly what a healthy Polaris model should look like, because subsets are the standard trick for staying under 64.
That exchange was the most valuable part of the whole exercise. The AI didn't fold when challenged, and it didn't bluff. It explained precisely which missing input caused the gap — and then turned that input into something I could supply.
The deliverable that outlives the chat
I didn't ask for a report. I asked for a live Excel workbook, and that made all the difference.
Sheet one: every line item with its dimensions side by side, each dimension's index score, and the total DIT with a status flag. Sheet two: every subset used as a dimension, with a yellow column where I type the real item counts from the model. Each entry instantly recalculates every affected DIT — no AI in the loop anymore, just VLOOKUPs and ROUNDUP(LOG(n,2)). Calendar length and version count are input cells too.
That last part earned its keep immediately. When I corrected my assumptions to our real settings — a 7-year calendar and 10 native versions — the picture refreshed in seconds. Fun fact I hadn't internalized before: going from 3 versions to 10 quietly adds two index points to every versioned line item in the model. Small setting, real DIT.
A final filtered version kept only line items above 60 — Anaplan's own "start paying attention" line — which shrank the remaining manual work to entering counts for 33 subsets. That's the entire cost of an exact, model-wide DIT audit.
The math on time
Since someone will ask: my hands-on effort was about an hour, spread across roughly three hours end to end. That includes exporting the three blueprints, the back-and-forth where I challenged the results, correcting the calendar and version assumptions, and requesting the filtered final file — the gap between the two numbers was mostly me reading outputs and sanity-checking figures against the model.
The honest manual estimate is uglier than people think. It's not just scoring 5,917 line items — it's parsing every Applies To string against 200+ lists and 97 subsets, resolving parent chains and top levels for every composite hierarchy, and tracking which line items override module dimensionality. Even if you built yourself a helper spreadsheet first (a solid day of work on its own) and then averaged a brisk 30 seconds per line item, you're looking at 50–60 hours — a week and a half of doing nothing else. And that's one pass, with no recalculation when the calendar extends or a version gets added.
Which is the real punchline: at that price, the analysis simply doesn't happen. The realistic comparison isn't three hours versus sixty — it's three hours versus never.
What I'd tell other model builders
The AI multiplied my Anaplan knowledge; it didn't replace it. I still had to know what a DIT is, which exports hold what, that subsets would be the blind spot, and what a dash in Applies To means. What I got in return was consistency across thousands of rows and a tool instead of a snapshot.
Argue with the numbers. An analysis you've pushed back on is worth ten you've merely received.
Make every assumption an editable cell, not a footnote. That one design choice turned an afternoon's analysis into a governance asset we'll still be using next planning cycle.
If you're on Polaris — or sizing up a migration from Classic — this kind of audit tells you your true headroom before a growing list tells you the hard way. It used to be the analysis nobody had time for. It cost me an hour of real work — sixty if I'd done it the old way, and let's be honest, I never would have.
……………
Community manager note: Click here to learn about how Anaplan's AI features, including CoModeler, can accelerate your day-to-day modeling productivity.
-
One model, many countries: The template and the reality
Author: Daniel Badura is a Certified Master Anaplanner and Solution Architect at Dr. Oetker.
A consistent, transparent planning approach offers many benefits, but applying it across an international organization is no small task. Markets differ in priorities and business practices: customer preferences and buying habits, product ranges, available channels, and the role of promotions and partnerships. Some focus on rapid growth, while others prioritize margins and market share.
Establishing a baseline
Rolling out a single integrated Anaplan model to an ever increasing number of country organizations requires balancing local needs with collective standards. Anaplan is highly flexible, but that flexibility can lead to scope creep. Model architecture can become very complex when designed to accommodate every request. Yet mature business processes often already contain enough rules and exceptions at the lowest common denominator. Depending on local autonomy and differences in day-to-day operations, even selecting a few representative countries as a starting point can be difficult. In many cases, the headquarters country becomes the initial baseline.
Expansion and compromises
Once a “standard” process has been identified, implemented in Anaplan, and come into contact with the real world, the next step is to onboard additional local organizations. This usually happens in waves, potentially over several years.
With each new country, change management comes first. Before any Anaplan configuration begins, central process owners should run workshops with the local teams. The central team presents the standard planning process, while the local team provides feedback on where the template does not fit its business practices. If their planning approach is already aligned with the international standard, onboarding can happen quickly and without much friction. If their way of working is very different, the search for common ground and compromises begins.
This typically leads to several iterations to determine how the local team can adapt to the central structure, and where the central structure itself needs to be adapted. The key questions are which requirements are essential, how they can be covered with existing capabilities, and which workarounds are feasible.
Considerations
When discussions turn to adding new functionality to existing Anaplan models, costs and benefits must be assessed carefully. What would happen if the template were not adapted? How many other organizations would benefit from the additional functionality? How much would complexity and maintenance effort increase?
In complex models, flexibility often comes at the expense of stability and maintainability. A calculation rule added for one country could produce incorrect results in another. Many IT organizations also define guidelines for international architectures, for example about supporting or not supporting automated interfaces to local software solutions.
Dedicated self-service options can increase flexibility without adding unnecessary complexity. AnaplanXL, for example, can allow savvy users to transform, combine, and analyze data according to their own needs. Connectors to tools such as Power BI can serve a similar purpose. Anaplan Analyst may also help close some gaps by querying data that is not directly available in the UX.
Conclusion
It is impossible to satisfy every requirement, but finding the right balance between local needs and collective standards is an important task, and one that is never finished. The two main challenges are defining a standard process and extending it where justified. There is no one-size-fits-all solution, but by focusing on essentials and following best practices, the flexibility of Anaplan can be leveraged where it matters most.
-
Making the most of Anaplan Data Orchestrator
Author: Sanja Boll is a Certified Master Anaplanner and Sr. Solution Architect at GlobalFoundries.
Anaplan’s Data Orchestrator (ADO) is very effective tool to import, transform, and load data into your Anaplan models. When used correctly, it can cut your data integration and transformation efforts by 50%, however maximizing its benefits does require a bit of experience. Below are the lessons I have learned while leveraging ADO at GlobalFoundries:
Multiple transformation views are better than one
* You will often see better performance and improve the auditability of your data transformations when you create multiple transformation views with your dataset, rather than combing all steps into one view.
* Additionally, ADO will process data transformations in a default order within a transformation view, not the order you apply it in. The order is:* Join
* Calculate columns
* Detail filters
* Aggregations
* Aggregation filters
* Union
* Remove duplicate rows
* This means that if you want to adjust your source data to remove duplicate rows and then create a UID based on logic, you need to create 2 transformation views. The first view will remove the duplicate views. The second view will create the UID.
Establish consistent naming conventions
* As shared in my above bullet, you may need to create multiple transformation views to accomplish your desired data output. To make it clear to the rest of your team what each transformation view is doing, make sure to set naming convention expectations early. While you can always use the “Map” feature to view the progression of your data from source to transformation to model link, it is more time consuming to analyze the data map than it is to scroll through your transformation views. Here’s an example of a helpful transformation view naming convention:* Dataset Name_ Transformation View # _ What the transformation view is doing
* An example would be “Purchase Orders_TV2_Filter Current Period”. This tells your Center of Excellence (CoE) team that this is the second transformation view of your PO dataset and you are filtering to the desired data period. If I were a model builder who needed to tweak the transformations of this dataset, having the transformation views labeled this way makes it easy for me to identify exactly where I need to make the change.
Be careful when you delete a transformation view
* Like anything in Anaplan, you are allowed to hit the delete button if you no longer need an item in your build. Unlike an Anaplan model, however, you cannot revert ADO. This means that if you delete a transformation view and then realize you actually needed it, you can’t undo the deletion. You will need to rebuild it. Some other implications to keep in mind when deleting a transformation view are that you can break downstream transformations that rely on the view you deleted. If the downstream transformation views are broken, your model link will be broken too. You won’t be able to run the model link until you add a new source.
Leverage dataspaces for sensitive datasets
* ADO allows you to create separate dataspaces with access controls. This is a great way to leverage ADO for sensitive data, such as Workday data for your workforce planning use case, without allowing all of your integration admins the ability to view the data. Access to dataspaces is granted to integration admins by the tenant admin in the “Administration” section of Anaplan.
Keep an eye out for new connectors
* There are three ways to get data into ADO:* External source systems with connectors
* Your Anaplan models
* Local files
* I find that the most benefit comes from connecting to external source systems as you get to shorten the turnaround time of your integrations. Currently, there are 13 external connectors available to systems such as Amazon S3, Google BigQuery, Salesforce, and SAP, however Anaplan is actively working on adding more options. Redshift, for example, is currently available with basic authentication. Eventually it’ll be available with SSO, which I personally am quite excited about.
ALM-ing in ADO requires cloning
* When you push your integration build to Production, ADO will not automatically update your model links to your Production model. To connect your link to the proper model, you will need to go to ADO > Links and find the desired link you wish to remap. Then, click the three dots to the right of the link and select “Clone to ALM Models”.
Hopefully these tips help you to save time and get a quicker ROI on your ADO investment. Happy planning!
-
Case Study: Anaplan model performance and size optimization
Author: Pranjal Agrawal is a Certified Master Anaplanner and a Senior Anaplan Consultant at Hinduja Global Solutions Limited (HGS).
The challenge
I was working for a client who at the start of their fiscal year introduced some new functionalities in Anaplan. They initially estimated that the additional data flowing in for the new functionalities would be below the maximum standard model size limit permitted by Anaplan, but the model started to reach close to that limit and there were still four more months to go. Simultaneously, as the data started to grow period by period, the model actions became cumbersome and started taking more time with each additional period. They approached me for a solution.
The techniques I used to fix the problem
I first asked the client about their license. As the client was on Enterprise License, Anaplan provides a free MAPS Report to its Enterprise License customers, so I asked them to get that report. MAPS Report is a highly efficient report to understand model’s deviation from Anaplan Best Practices and can be highly leveraged in any optimization scenario in question. The MAPS report provided a detailed break-up of the line items and modules that can be optimized, and what should be optimized in it. But it should just be used as a reference guide to identify the line items and not to be taken as a concrete optimization methodology as many of the details mentioned in it might not be suitable with the client’s requirements.
Like at many places it suggested to remove the summary settings as that line item is not referenced anywhere. But those were used in the Dashboards for reporting at hierarchy levels, so it was not feasible to remove the summary settings from them.
I first categorized all the line items mentioned in the MAPS Report separately and started investigating each of them one by one categorically to understand whether that line item can be optimized or not keeping the client’s requirements intact.
Once I had identified the line items that can be easily optimized, here is the main technique I followed for a fast-paced optimization:
I prioritized the optimizations based on efforts required vs outcome on a 4D matrix
Based on the set priorities I started working on Low Effort – High Impact optimizations first to get quick results. These were use cases like:
* Split the formula for line items that are using Sum-Lookup together: This is easy to split into an intermediary line item to hold the sum values and then update the target line item to just have lookup on the added intermediary line item. It although adds to the size of the model but helps save lot of processing time.
* Performing text concatenations in thin modules:
There were instances where we had to create TRIDs, and the TRID concatenations were taking place in the module with all the dimensions. For Example, there was a case where we were creating an Employee & Customer TRID in a module with dimensions – Employee, and Customer, where we had 3,000 employees and 1,000,000 Customers. Existing Formula:
Employee|Customer TRID: Employee Code & ”|” & Customer Code
I optimized it by shifting the code concatenation for 1st part into the Employee system module and the final output looked like:
Module 1: Employee System Module
Dimension: Employee
Line item: Code to Use
Formula: Employee Code & “|”
Module 2: Employee Customer TRID Creation
Dimension: Employee, Customer
Line Item: Employee|Customer TRID
Formula: ‘Employee System Module’.’Code to Use’ & Customer Code
This optimization helped reduce the model calculation efforts for TRID calculation where earlier each individual concatenation had to run 3000*1000000 times therefore 2 concatenations = 3000*10000002 = 6,000,000,000 calculations
After optimization it got reduced to 3000 (concatenations in Employee Module) + 3000*1000000 (Concatenations in TRID Creation Module) = 3,000,003,000 calculations.
* Remove additional dimensions if not required: There were places where a dimension is used although was not required, so I removed the dimensions from those line items and where possible placed it into its own separate module to avoid subsidiary views. Like, a line item named Employees was only used to filter the contents at the front end, the module and so the line item had 5 different dimensions including Employee. Here only the Employee dimension was relevant, so I removed the rest resulting in massive size savings. Initially the line item had 500 million populated cells, which post optimization dropped to just 3000 cells.
* Leverage Calculation Efforts column in model blueprint view:
There is a Calculation Efforts column in the Model Blueprint view initially a native feature of Polaris but recently added by Anaplan to the classic engine as well. This column tells us about the % time the line items took to process in last 10 minutes. To use it at its best, close the model from the Model Management Tab – Tasks section, and then once closed, re-open the model from home tab to get accurate details of the line items that takes the most time to process during initial model load. The higher the percentage, more the time that line-item took to process. These will be your key line items that you should look to optimize to help reduce model load times.
* Perform calculations in the low dimension modules and refer it in highly dense modules:
I identified some line items which were calculating sum in high density modules for the line items present in low density modules. For Example:
Module 1: Sales & Quota Data by Customer
Dimensions: Customer and Time
Line Items: Sales, Quota, Sales Representative
Module 2: Sales & Quota Data by Sales Rep and Customer
Dimension: Customer, Sales Representative, Time
Only Line Item: Sales & Quota
Formula: Module 1.Sales[SUM: Module 1.Sales Representative] + Module 1.Quota[SUM: Module 1.Sales Representative]
Here both the Sales and Quota values are present and referred from Module 1 only, still the calculation was performed in Module 2.
To optimize this, I added a new line-item Sales & Quota in Module 1 and performed the calculation in it (Sales + Quota) and then updated the formula in Module 2 as:
Sales & Quota: Module 1.’Sales & Quota’[SUM: Module 1.Sales Representative]
This saved the model calculations from earlier 300 million to now just 3000 calculations.
* Look at opportunities to optimize the actions taking most of the time to process:
I took an export of the Actions Tab of the client’s model. I sorted it by the processing time to identify which actions are taking most of the time to process. This helped me identify and act first on the actions that are time consuming, lowering the performance efficiency of the processes. Things to consider for actions optimization:* Filter source data: There were actions in which a lot of data use to be imported from the source out of which most of it is irrelevant as already imported in the prior periods. So, I worked on filtering the source content to limit it to just the current period and removing other periods where it was feasible to limit the data from 12 billion cells earlier, scattered across multiple line items, to now just 1/12th of it viz. 1 billion cells.
* Keep single filter in the source saved view: During investigations I also found that some source saved views had multi-level filters applied, causing it to slow down as the engine had to filter data one-by-one for each of the applied filter first before getting the final view for the data import. I created a new BOOLEAN formatted line item inside the source module and merged all the filter conditions together in it and then used this newly created line item as the single filter on the saved views saving action load times.
* Optimize module calculations for list population actions: I noticed that there was an action that is used to populate the subsets and was taking exceptional amount of time to process. I checked that there were 3 different modules on which one of those subsets was applied, and there are some large nested if-else formulas used in those modules which calculate right after the subset population. The action was taking longer than expected times as the model starts calculating these specific formulas after the subset load which is also counted towards the action processing time. I looked for opportunities to optimize those calculations, and it resulted in savings in the action processing time.
* Replace the List and Text comparisons with BOOLEANs where possible:
There were instances where in some large IF-ELSE statements, lot of list-vs-list comparisons were present. For Example, Formula:
IF Module 1.P = List M.A THEN XXX ELSE IF Module 1.P = List M.B THEN YYY ELSE ZZZ
This had the model to compare the same line item to every list member multiple time in a highly dense module of 3 billion cells. As List M contained only 20 members, the IF-ELSE condition had 20 nested conditions, one for each member.
To optimize this, I replaced these IF ELSE conditions with BOOLEAN formatted line items.
Step 1: Create a system module with dimension List M – Module 2
Step 2: Create 20 separate line items one each for every list member as BOOLEAN formatted
Step 3: For Example: line item name: List Item = A. Formula: ITEM(List M) = List M.A or you can also make it BOOLEAN formatted to avoid hardcoding and keeping the options open for future updates directly in the production environment without having a need to push a change via development using revision tag.
Step 4: In the dense module, I updated the formula as:
Before:
IF Module 1.P = List M.A THEN XXX ELSE
IF Module 1.P = List M.B THEN YYY ELSE ZZZ
After:
IF Module 2.’List Item = A’[LOOKUP: Module 1.P] THEN XXX ELSE
IF Module 2.’List Item = B’[LOOKUP: Module 1.P] THEN YYY ELSE ZZZ
This helped reduce the list-item vs list-item calculations from 5 billion*20 list members to just 20*20 list members. As this module is using subsets, the change had major impact on the processing time of the actions attached.
The action to populate subsets which earlier took 90 minutes to process, got drastically reduced to just 15 minutes post optimization. It helped save action processing time by 75 mins making the action 80% faster than before.
* Use subsets in the final reporting modules:
There were three high density reporting modules that had full lists applied to it and had multiple dimensions. Due to this every single one of the modules had size of about 5 GB each. I checked to find that 80% of these modules were sparse data and only 20% cells were populated. I identified the source modules and leveraged them to create subsets for each of those dimensions to include only those list items that do have data associated with them instead of taking all the list items. These subsets were used to replace the existing dimensions. This helped me save 15 GB in model size for the three biggest reporting modules.
The outcome
Post these optimizations mentioned above, we asked for another Anaplan MAPS Report for an apples-to-apples comparison. And here are the results:
* Model size reduced by up to 35%, from 105 GB to 70 GB.
* Model actions processing time reduced by up to 80%, from 42 hours to 8 hours, if all the actions are processed simultaneously.
* Model availability increased for the end users as the daily process, which runs twice a day, earlier took 90 minutes per run, later got reduced to 30 minutes per run, thereby adding 480 hours of additional productivity for the client in a year. (About 2 hours a day in a 5 days’ work week.)
* Earlier, the daily load used to lock-out the end users from the model while the actions take place, this also got optimized and now the end users can access the model with minimal delay, even during the daily loads without getting locked-out from Anaplan.
* Some ad-hoc data load which used to take 90 minutes to process got reduced to 15 minutes. 90% productive efficiency achieved.
* It also helped with huge cost savings for the client, as earlier due to un-optimized model, the client was planning to either move to the Anaplan Hyperblock engine with model capacity of 720 GB or moving out of Anaplan to some other planning tool which will be less costly to maintain for a large model size. But now, as the size got reduced to just 70 GB, they still got 60 GB buffer left for additional data and new functionalities to be developed in the future.
Questions? Leave a comment!
-
How I Built It: Classic vs. Polaris — a dimensions-first approach to module design
Author: Valeria Sicuro is a Certified Master Anaplanner and Professional Service Consultant at Bedford Consulting.
In this ‘How I Built It’ video, I demonstrate how dimensionality decisions impact model design in Anaplan, and how the same business requirement can lead to different implementations depending on whether you are working in Classic or Polaris.
Starting from a practical use case, I walk through the reasoning behind dimension selection and show how data structures, calculations, and module design evolve across the two engines. Rather than focusing on theory alone, the video highlights the design choices that model builders face when balancing flexibility, performance, and scalability.
The main advantage of understanding dimensionality at this level is the ability to build more efficient and sustainable models. By selecting the appropriate dimensions from the start and leveraging the strengths of each engine, model builders can create solutions that are easier to maintain, perform better at scale, and align more closely with business requirements.
https://play.vidyard.com/bcorgQpkEun6YQibutgNVG.html?
Questions? Leave a comment!
.png){kind=icon}
