-
How I Built It: AdHoc Hub Framework
Author: Saurabh Kapoor is a Certified Master Anaplanner and a Technical Lead at HCLTech.
Hello Anaplan Community!
Thank you for checking out my 'How I Built It' tutorial. In this video, I demonstrate how I built an AdHoc Hub, a self-service integration framework that enables planners to execute data load processes on demand while reducing dependency on support teams and manual intervention.
This solution combines Anaplan UX, CloudWorks, AWS S3, Anaplan Connect, and batch automation to create a seamless end-to-end process. Planners can select a planning activity, generate a trigger from Anaplan, and automatically execute the corresponding data load process through a centralized hub.
A great example is Demand Planning and Supply Planning, where planners regularly need to upload forecast, inventory, capacity, or override data as part of their planning cycle. Instead of relying on scheduled integrations or technical resources, planners can trigger these processes directly from the AdHoc HUB and monitor execution status in real time.
This approach is especially useful for organizations that require flexible, user-driven integrations while maintaining governance, auditability, and process standardization.
Key features:
* Planner-driven self-service execution
* CloudWorks integration with AWS S3
* Trigger-based automation framework
* Dynamic action execution using metadata-driven design
* Automated timestamp logging and execution tracking
* Scalable architecture for multiple planning processes
* Centralized monitoring and audit visibility
Key planning use cases demonstrated:
* Upload Sales Forecast
* Upload Demand Override
* Upload Inventory Position
* Upload Production Capacity
The same framework can be extended to support Financial Planning, Workforce Planning, Sales Planning, and other business processes requiring on-demand data integration.
‘How I Built It’ tutorial
https://play.vidyard.com/ifXRGLYpRriqBHm3RY6JvQ.html?
Drop a comment if you have any questions!
-
The Decision Contract, Part 2: Translating better decisions into better Anaplan design
Steven Barry is a Certified Master Anaplanner and Connected Planning Sales Lead at Kearney.
In Part 1 of the series, I introduced the decision contract as a way to clarify what decision a planning process must produce before the team begins designing the Anaplan solution. The contract defines the decision, owner, timing, required evidence, guardrails, and downstream commitment.
The real benefit appears when the contract begins to shape the solution. A decision-centered design focuses the model on the right business intersection, routes work based on materiality, and connects each decision to its broader impact.
The following principles can help translate a decision contract into practical Anaplan design choices.
* Model the decision at the correct level.
The dimensionality of the solution should reflect the level at which the decision is made.
A regional revenue commitment may exist by region, period, and scenario. A demand override may exist by product, location, and week. A hiring decision may exist at the individual position or requisition level.
This does not mean every supporting calculation must use the same dimensionality. It means the final decision, its owner, its status, and its rationale should be identifiable at the appropriate business intersection.
When the decision level is unclear, models often become larger and user experiences become more complicated than necessary.
* Calculate before asking the user.
Users should not be asked to manually provide information that the platform can calculate or derive.
Anaplan should establish a credible starting point using available actuals, assumptions, statistical outputs, prior decisions, and business rules. The user should then apply judgment where judgment is valuable.
This changes the role of the planner. Instead of rebuilding a forecast from the beginning, the planner reviews the baseline, evaluates exceptions, and makes targeted adjustments.
It also creates a measurable comparison between the system recommendation and the final human decision.
* Escalate based on materiality.
Many approval processes are designed around organizational hierarchy. Every submission moves from one level to the next, regardless of its value, risk, or complexity.
A decision contract allows the solution to route work based on materiality.
A routine adjustment within tolerance may not require additional approval. A large override, a change affecting a strategic customer, or a decision that creates a capacity constraint may require further review.
This reduces unnecessary work for leaders and gives them more time to focus on the decisions that could materially affect the business.
* Capture the reason, not just the number.
A numeric adjustment without context is difficult to review and even harder to learn from.
The solution should capture why a decision was made. Structured reason codes can identify common drivers such as pricing, timing, customer behavior, supply constraints, hiring delays, or changes in demand. Commentary can provide additional detail when it is needed.
Structured rationale also creates information that can be analyzed. Over time, the business can determine which assumptions are most frequently wrong, which risks are recurring, and which types of overrides tend to improve the outcome.
* Make the downstream impact visible.
Decision-makers should be able to see what their decision changes.
A demand increase may improve projected revenue while creating an inventory or production constraint. A delayed hiring decision may reduce near-term cost while putting a strategic initiative at risk. A sales forecast adjustment may affect workforce capacity, cash expectations, or delivery commitments.
Anaplan is particularly valuable when it connects these consequences across functions. The decision page should provide enough visibility for the owner to understand the broader impact before committing.
* Close the loop when actuals become available.
Most planning processes move quickly from one cycle to the next. Teams spend significant time producing a plan but much less time evaluating the quality of the decisions made during the prior cycle.
The decision contract creates a structure for that evaluation.
Once actual results are available, the business can compare the baseline, the human adjustment, the approved decision, and the final outcome. This helps determine whether overrides improved accuracy, whether guardrails were appropriate, and whether additional review created value.
The purpose is not to penalize decision-makers when circumstances change. The purpose is to make the planning process smarter over time.
Measure decisions, not just task completion
Many Anaplan implementations measure whether users logged in, completed their inputs, submitted their plans, or received approval.
These metrics are useful for administering a process, but they do not prove that the process is working well.
A decision-centered process should also measure how long it takes to move from a business signal to a committed decision, how many decisions require manual review, how often submissions are returned for rework, and how frequently approved decisions change before execution.
Where possible, organizations should also evaluate whether human overrides improved the baseline and whether the agreed downstream action was completed.
Not every metric needs to be automated immediately. Tracking a small number of these measures for one planning cycle can reveal where the real bottlenecks exist.
A high submission rate may hide a large amount of rework. A fast approval process may hide unclear accountability. A highly accurate forecast may still arrive too late to influence the business.
A better conversation at the start of an implementation
The decision contract changes the questions asked during requirements gathering.
Instead of beginning with, “What spreadsheet do you use today?” the team can ask, “What decision does this spreadsheet support?”
Instead of asking, “Who approves this input?” the team can ask, “Who has the authority to make the final commitment?”
Instead of asking, “What fields should be mandatory?” the team can ask, “What evidence is necessary to make this decision responsibly?”
Instead of asking, “Which dashboard should we build?” the team can ask, “What information and actions does the decision owner need at the moment of decision?”
The answers provide a stronger foundation for user stories, solution architecture, workflow design, and adoption planning.
Conclusion
A well-built Anaplan model can make an existing process faster, more controlled, and easier to maintain. That is valuable, but it should not be the limit of the ambition.
The greater opportunity is to improve how the organization makes decisions.
Before beginning the next use case, take one critical planning decision and write its decision contract. Define the decision, owner, timing, evidence, guardrails, and downstream commitment. If the stakeholders cannot agree on those points, the process is probably not ready to be built. If they can agree, many of the model and user experience design choices become much clearer.
What is the most important decision supported by your Anaplan solution, and what changes in the business once that decision is made?
-
The Decision Contract, Part 1: A better starting point for Anaplan design
Steven Barry is a Certified Master Anaplanner and Connected Planning Sales Lead at Kearney.
This is the first article in a two-part series on using a decision contract to improve Anaplan solution design. Part 1 introduces the concept and explains how it can help teams clarify the business outcome before they begin building. Part 2 focuses on translating the contract into model architecture, workflow, user experience, and success measures.
One of the easiest mistakes to make during an Anaplan implementation is to begin with the current process and assume the goal is to reproduce it. The team maps the spreadsheets, documents every handoff, rebuilds the existing approval chain, and creates a page for each person involved.
The result may be technically sound, but it may also leave the business with the same slow and complicated planning process, only in a better tool.
Anaplan creates more value when it is used to improve how decisions are made. That requires a different starting point. Before defining modules, pages, workflows, integrations, or user stories, the project team should define the decision the process is expected to produce.
I refer to this as the decision contract.
What is a decision contract?
A decision contract is a simple design framework that establishes what decision must be made, who owns it, what information is required, and what happens after the decision is made.
It is not intended to add another layer of project documentation. In most cases, it should fit on a single page. Its purpose is to create enough clarity that the business process and the Anaplan solution can be designed around the same outcome.
A complete decision contract should answer six questions.
* What decision is being made?
This should describe an actual business decision, not an activity. “Submit the forecast” is an activity. “Commit to the regional revenue outlook for the quarter” is a decision. “Enter hiring requests” is an activity. “Authorize the positions that the business can afford and recruit” is a decision.
The distinction matters because activities can be completed without creating business value. Decisions create commitments, establish priorities, and change what the organization does next.
* Who owns the decision?
Many planning processes involve several contributors, reviewers, and subject matter experts. That does not mean they all own the final decision.
The decision contract should identify one accountable owner or a clearly defined decision-making group. Contributors can provide information and recommendations, but accountability should not become unclear simply because the process is collaborative.
When ownership is not defined, the Anaplan design often compensates with additional approval steps. This makes the process longer without necessarily making the decision better.
* When must the decision be made?
A due date is useful, but it is not always enough. The contract should also identify the event or business signal that triggers the decision.
A demand forecast may be reviewed on a monthly schedule. A hiring decision may be triggered when a position becomes vacant. A sales forecast may require an additional review when a material opportunity slips. A supply decision may be triggered when projected inventory falls below an agreed threshold.
Defining the trigger helps separate decisions that belong in a recurring planning cycle from decisions that should be managed by exception.
* What evidence is required?
The decision owner should have enough information to make a responsible decision, but more information is not always better.
The contract should identify the minimum evidence required. This may include a system-calculated baseline, historical performance, assumptions, known risks, operational constraints, or recommendations from other teams.
This is where Anaplan can provide significant value. The platform can bring the relevant information together at the point of decision instead of requiring users to assemble it through spreadsheets, emails, and offline conversations.
* What guardrails apply?
Guardrails define the boundaries within which a decision can be made without further escalation.
They may include financial tolerances, approval limits, capacity constraints, service-level expectations, risk thresholds, or requirements for additional commentary. They should be specific enough to guide behavior without forcing every decision through the same review path.
A good guardrail allows the majority of routine decisions to move quickly while ensuring that material or unusual decisions receive the appropriate attention.
* What changes after the decision is made?
This may be the most important question in the contract.
A decision should create a clear downstream commitment. An approved forecast may become the baseline used by Finance. An authorized position may flow into recruiting and workforce cost projections. An approved demand override may change production, procurement, and inventory requirements.
If nothing changes after a decision is made, the process may be collecting information rather than managing the business.
Applying the decision contract to sales forecasting
Consider a common sales forecasting process.
Every seller updates every opportunity. Sales managers review each submission. Regional leaders adjust the total. Finance compares the result to the target. The process concludes with an executive forecast call.
It is tempting to reproduce this entire sequence in Anaplan. Each role receives an input or review page. Status fields are added. Approval actions are configured. Management reporting is built around submission completion.
The process may become more controlled, but the core business decision can still remain unclear.
The actual decision is not whether every opportunity was updated. The decision is whether the organization is prepared to commit to a revenue outlook and act on the resulting risks and opportunities.
A decision contract for the regional forecast could establish that the regional leader owns the committed outlook by the fifth business day of the month. The required evidence could include open pipeline, renewals, historical conversion, seller overrides, and identified risks. Forecast changes outside an agreed tolerance could require an explanation. Only material exceptions would escalate to the next level. Once approved, the forecast would become the baseline consumed by Finance, workforce planning, and delivery capacity planning.
That contract leads to a different Anaplan design.
The platform can calculate an initial forecast using the available pipeline and historical assumptions. Sellers can focus on opportunities where their judgment is likely to improve the result. Managers can review material overrides instead of every record. Regional leaders can see the forecast, the gap to target, the largest risks, and the actions available to address the gap in one place.
The process becomes less focused on collecting updates and more focused on making a defensible decision.
Conclusion
A well-built Anaplan model can make an existing process faster, more controlled, and easier to maintain. That is valuable, but it should not be the limit of the ambition.
The greater opportunity is to improve how the organization makes decisions. The decision contract provides a practical way to align the business and implementation team on that outcome before development begins.
Part 2 of this series covers how to translate the decision contract into Anaplan design choices, including dimensionality, system-generated baselines, exception-based workflow, decision rationale, connected impacts, and outcome measurement.
-
Connecting Amazon S3 to an Orchestration Platform
Author: Bhanu Chalotra is a Certified Master Anaplanner and Senior Consultant at Technology Modernization.
In most real-world data environments, data doesn't originate in the platform where it's ultimately analyzed or consumed. Instead, it usually lands somewhere first, and more often than not, that "somewhere" is Amazon S3.
An upstream application exports a file, a vendor drops a report, or a scheduled process generates data and places it in a bucket. From there, the orchestration layer picks it up and moves it through the rest of the pipeline.
Because of that, integrating S3 with orchestration tools is one of the most common tasks data engineers run into.
Why S3 is usually the starting point
S3 has become the default landing zone for a few good reasons.
First, it keeps systems loosely coupled. The upstream system only needs to deliver a file to a bucket. It doesn't need awareness of whatever orchestration or analytics platform comes next.
Second, it's inexpensive and highly reliable. Teams can store large volumes of data without worrying too much about cost, while still benefiting from S3's durability.
And finally, it fits naturally with batch-based processes. Vendor feeds, nightly exports, and periodic snapshots are all file-based by nature, making object storage an easy choice.
Getting the connection in place
The setup itself is usually straightforward.
Start by creating an IAM user or role with only the permissions the orchestration platform needs. In most cases, read access to a specific bucket location is enough.
Next, configure the connection inside the orchestration tool. You'll typically provide the AWS credentials, region, and bucket details.
If the bucket contains multiple datasets, avoid granting access to the entire thing. Restrict the integration to a specific prefix or folder whenever possible. Besides improving security, it also makes troubleshooting much easier later.
Once the connection is established, define which files should be ingested, the expected format, and how frequently the platform should look for new content.
The decision that has the biggest impact
The connection itself is rarely the difficult part. The bigger question is how new data should be loaded.
A full refresh is often the easiest option. Every run simply reloads the entire dataset from scratch. It works well in the beginning but tends to become expensive and slow as data volumes increase.
Append-only loading is another common pattern. New data gets added while existing records remain untouched. This works particularly well for logs, events, and audit data where history matters.
For larger datasets, incremental loading is usually the preferred approach. Instead of reprocessing everything, the pipeline only handles records that have changed since the previous run. The tradeoff is complexity. You need reliable keys and timestamps, and many source systems don't always provide those cleanly.
A surprising number of pipeline issues can be traced back to choosing the wrong load strategy early on.
A few things that tend to cause problems
One of the biggest surprises for new teams is data typing.
Files arriving from S3, especially CSVs, often contain everything as text. Dates, numbers, percentages, and booleans may all show up as strings. Relying on automatic type detection usually creates problems somewhere downstream, so it's better to handle casting explicitly.
Column names are another common source of trouble. Extra spaces, special characters, and inconsistent naming conventions can break mappings without generating obvious errors. A little discipline on the source side can save a lot of debugging time later.
Then there's schema drift.
At some point, an upstream team will add a column, rename one, or remove something entirely. It happens everywhere. Pipelines built with rigid assumptions tend to break when this occurs. The best defense is usually a centralized raw layer where source data lands first, with downstream transformations isolated from direct schema changes.
Timing issues are also worth considering. If your pipeline runs every morning at 6 a.m. but the source system occasionally delivers files at 6:15, you'll eventually ingest incomplete data.
Don't treat security as an afterthought
S3 integrations are often powered by access to keys and secrets, which means credential management of matters.
Keep permissions as narrow as possible. Use separate credentials for different integrations instead of sharing one account across multiple workflows. Rotate keys regularly, and whenever your platform supports it, use temporary or role-based access rather than long-lived credentials.
A little effort here significantly reduces operational risk down the road.
Write back capability
Previously, the integration was primarily used to bring data from Amazon S3 into ADO for processing and analysis. With the introduction of the write-back capability, the same integration can now be used to send data from ADO back to Amazon S3.
Teams can use S3 as both a source and destination within their data processes, making it easier to share updated datasets with downstream applications, reporting tools, and other consumers.
The capability also supports the creation of automated data pipelines, ensuring that the latest data is consistently available in the designated S3 location. Whether the requirement is to archive processed data, provide data for reporting purposes, or make information available to other systems, the write-back functionality helps simplify and standardize the process.
Steps to write data back from ADO to Amazon S3
* Create a Saved View in Anaplan containing the data that needs to be exported.
* In Azure Data Factory (ADF/ADO), create a Dataset using the Anaplan model connection and select the Saved View created in the Anaplan model.
* Create a Pipeline in ADF and configure the connection between Anaplan and Amazon S3 by using the Anaplan Dataset as the source and specifying the target file path in the S3 bucket.
* To execute the process on an ad hoc basis, you can create a Workflow Template to trigger the pipeline when required.
Note: Each time the pipeline is refreshed, the existing records in the target S3 location will be overwritten and replaced with the latest data available in the Saved View.
Conclusion
Connecting S3 to an orchestration platform is usually the easy part. Building something that stays reliable six months from now is where the real work begins.
Most production issues aren't caused by the connection itself. They're caused by poor loading strategies, unexpected schema changes, data type inconsistencies, or timing mismatches between systems.
-
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.
.png){kind=icon}
