Planning · 2021

Quick Facts

• Industry: Global retail Fortune 1 / FMCG
• Role: OneStream Analyst — Planning
• Timeline: ~7 months across one full annual plan and the first re-forecast
• Team: Solo build on the OneStream side, with an FP&A lead validating each rule against the offline planner models and a senior architect reviewing the rule design before anything landed in production
• Impact: GL Planning module live in-platform, rule-based price-elasticity + volume simulation replacing offline analyst spreadsheets, workforce-planning data flowing straight into the financial plan with zero manual re-entry

---

Overview

The brief was planning that doesn't need a spreadsheet sidecar. The client — a Fortune 1 global retailer with an FMCG planning footprint — ran a respectable OneStream stack for consolidation and reporting, but the planning side was a constellation of input forms, review forms, offline analyst models, and a workforce-planning template that lived in a separate cube and got hand-keyed back into the GL plan every cycle. We built a real GL Planning module: input and review forms with allocation, driver-based, and variance rules baked into the calculation layer; a rule-based price-elasticity and volume simulator pulling its weights from historical patterns inside the platform; and an integration bridge that let the workforce cube post directly into the planning cube without an analyst opening Excel. The result wasn't a single dramatic number — it was the disappearance of an entire shadow workflow.

The Problem

Planning at the client ran across four surfaces and none of them talked to each other cleanly.

• Input forms in OneStream. Planners entered base numbers — volumes, prices, COGS assumptions — through forms that did data capture honestly but pushed almost all of the interesting math (allocations, driver-based derivations, variance comparisons) out to downstream spreadsheets. The forms were a typing surface, not a planning surface.
• Review forms in OneStream. Aggregated views existed, but the rule logic that would let a reviewer challenge a number on the spot wasn't on the form. Reviewers exported to Excel, did the math there, and posted comments back into the platform if they remembered to.
• Offline analyst models for price elasticity. The most consequential planning assumption — how volume responds to price changes by category, region, and channel — lived in a workbook on one analyst's laptop. Years of pattern work, opaque to anyone else; re-running it for a what-if was a half-day job.
• Workforce planning in its own cube. Headcount, comp bands, merit cycles, and benefits load were planned in a separate workforce cube. The numbers it produced were correct; the way they made it into the GL plan was a planner exporting them, opening the planning cube, and typing them in by hand. Every cycle. Every re-forecast.

The downstream effects compounded. Variance analysis was always late, because the rule logic wasn't on the forms — variance work happened after the cycle closed, so insights informed the cycle after next at best. Price-elasticity assumptions weren't auditable; the FP&A lead couldn't point at a number in the plan and trace it back to a rule, and "trust me, it's right" stops being a viable governance posture once the plan is reviewed by people who weren't in the room. Workforce re-entry was the slowest single step in the cycle, and manual transcription is the easiest step to get wrong — corrections had a habit of showing up in the late review pass where they were most disruptive.

The brief: build the GL Planning module with real rules on the forms, bring the price-elasticity logic into the platform without standing up an external ML stack, and wire the workforce cube into the planning cube so the re-entry hop went away.

Process

Phase 1 — Build the GL Planning module

The first phase was the longest: a proper GL Planning module on top of OneStream's planning framework, with rule logic on the forms themselves. The input forms got three classes of rule.

Allocation rules covered top-down allocations (corporate to region to store cluster to category) and bottom-up reconciliations, both driven by configurable allocation bases stored as members rather than hard-coded — planners could change the base by editing a member, not by raising a ticket. Driver-based calcs handled volume × price × mix for revenue lines, headcount × loaded-rate for the comp lines that didn't yet have the workforce bridge wired in, and square-foot × productivity-per-foot for occupancy-driven lines, each driver a named member with a clear owner. Variance analysis ran prior-period and prior-plan comparisons on the form, deltas surfaced inline — the planner saw their proposed number, the prior plan, the actual, and the variance against both, computed live as they typed.

The review forms re-used the same rule library, so planner view and reviewer view were guaranteed to match. Each rule was small, named, and individually testable. The FP&A lead validated each one against the offline planner model output before promotion; the senior architect reviewed rule design for naming, scope, and side-effect discipline. By the time we shipped, the FP&A team trusted the in-platform math enough to stop running the offline model in parallel.

Phase 2 — Build the rule-based price-elasticity + volume simulator

The price-elasticity work needed a framing conversation up front. The client had — reasonably — heard "machine learning" and wondered whether we'd be standing up a Python stack alongside OneStream. The answer was no. The offline model wasn't doing anything fundamentally ML-shaped — it was a thoughtful weighted-rule system an experienced planner had built up over years — and the governance bar for a black-box model inside a financial plan would have been very high. The right move was to bring the analyst's logic into the platform as explicit, auditable rules and let the platform compute it natively.

The simulator was rule-based and lived entirely inside OneStream. A set of rules looked back across the actuals already in the cube and computed, per category × region × channel, the observed volume response to historical price moves — a member-level elasticity coefficient per slice, refreshed on a cadence the FP&A team controlled. A second rule took a planner's proposed price and applied the coefficient to derive implied volume, with guardrails: extrapolating beyond the historical range was flagged, not silently extrapolated. Planners could override the simulated volume, but the override was tagged and the variance against the rule-derived value surfaced on the review form. Reviewers could see at a glance which lines were rule-driven and which were judgment calls — which is what good governance on this kind of model actually looks like.

It is not deep learning. It does not need to be. What it is, is in-platform, auditable, refreshable on a known cadence, and trusted by the FP&A lead because she validated each coefficient against the offline workbook before we flipped the switch.

Phase 3 — Workforce ↔ planning-cube bridge

The third phase was the smallest amount of code and the largest amount of avoided pain. The workforce cube already produced clean headcount, comp, benefits-load, and merit-cycle numbers. The planning cube already had the lines those numbers needed to land on. The only thing between them was a planner with a spreadsheet.

The bridge was a rule set that ran on a scheduled cadence (and on demand from a dashboard button for re-forecasts) and posted the workforce cube's outputs into the planning cube against the correct accounts, entities, and time periods. The mapping was config-driven — a member-level translation table the FP&A team owned, so adding a new comp component or benefits line was a config change, not a rule change. The post happened in a single transaction with a reconciliation check at the end: if planning-side totals didn't match workforce-side totals, the bridge rolled back and surfaced a discrepancy report. After it went live, the workforce-to-planning re-entry step disappeared from the cycle calendar.

Solution

Four components, all in-platform:

1. GL Planning input and review forms with custom rules

A purpose-built planning module on top of OneStream's planning framework. Input forms capture base numbers and run allocation, driver-based, and variance rules live as the planner types. Review forms re-use the same rule library so reviewer and planner see identical math.

2. Allocation / driver / variance rule library

A small, named, individually testable rule library backing both forms. Allocation bases, driver definitions, and variance comparators are stored as members rather than hard-coded, so FP&A can change behaviour without a developer in the loop.

3. Rule-based price-elasticity + volume simulator

A historical-pattern-driven elasticity model living entirely inside OneStream. Coefficients are derived from actuals already in the cube, refreshed on an FP&A-controlled cadence, applied as transparent rules at planning time, and overridable with the override tagged for review. No external ML tooling, no Python sidecar, no black box — the simulator is auditable down to the rule that produced any given number.

4. Workforce ↔ planning-cube bridge

A scheduled-plus-on-demand rule set that posts workforce-cube outputs directly into the planning cube against a config-driven mapping table, with a transactional reconciliation check at the end of every post. Manual re-entry of headcount and comp numbers is gone.

Results

| Metric | Before | After | Change | |---|---|---|---| | Planning-cycle re-entry hops (workforce → GL) | Many (per cycle, per re-forecast) | 0 | manual step eliminated | | Price-elasticity model location | Offline analyst workbook | In-platform rule library | auditable, refreshable | | Variance analysis timing | Post-cycle, in spreadsheets | In-cycle, on the form | insight available before the next iteration | | Headcount + comp re-entry effort | Manual typing every cycle | Automatic via bridge | full automation | | Math shown on input vs review forms | Separate (drift risk) | Single rule library | guaranteed to match |

Soft outcomes:

• The shadow spreadsheets retired. The parallel workbooks the planners had built up as workarounds — variance decks, allocation calculators, the elasticity model — stopped getting opened. The cycle was wholly platform-driven within two re-forecasts of go-live.
• Reviewers asked better questions. Once the rule logic was on the form, review conversations shifted from "what is this number" to "is this driver right" — which is the conversation FP&A actually wanted to be having.
• The "trust me" governance posture went away. Every plan number became traceable to a rule, a driver, or an explicitly tagged override. That mattered more than any individual speedup.

Learnings

What worked. Framing the price-elasticity work as "bring the analyst's logic into the platform as explicit rules" rather than "build an ML model" was the single most important call on the project. It set the right expectations with the client, kept the governance bar achievable, and gave us a system the FP&A lead could actually defend in a review. Predictive-style analytics don't have to be opaque — and inside a financial plan, they really shouldn't be.

What I'd do differently. Build the workforce bridge in phase one, not phase three. The re-entry step was the easiest piece of pain to remove and the one planners felt most acutely day-to-day; shipping it early would have bought trust faster and made the longer rule-library work feel less abstract while it was in flight. Ship the visible win first when you can.

Skill developed. Designing rule libraries for FP&A ownership rather than developer ownership. The trick is to push every parameter an FP&A team might want to tune — allocation bases, driver definitions, elasticity refresh cadence, mapping tables — out of the rule body and into members or config tables they own. The rules get smaller, the FP&A team gets faster, and the developer stops being a bottleneck for changes that were never developer-shaped in the first place. That pattern has shown up in every planning engagement I've taken on since.