Every planning platform is sold with a golden go-live story, and most of them are true. What the stories omit is year two: the backlog of change requests nobody triages, the one person who understands the model leaving, the workarounds spreading because the official route is slow. None of this is a tooling failure. It is the absence of an operating model - which is what a Center of Excellence is, stripped of the grand name.
The four jobs of a planning CoE
- Demand management. A single intake for change requests, triaged weekly against a visible roadmap. The point is not bureaucracy; it is that the loudest requester stops being the de facto prioritisation mechanism.
- Model stewardship. Someone owns each model’s architecture: its dimensional design, its performance budget, its documentation. Changes that bend the architecture get flagged before they are built, not discovered in a performance crisis two years later.
- Release discipline. Structural changes flow dev → test → production on a cadence the business can plan around. In Anaplan terms, real ALM practice; in Pigment terms, disciplined use of environments and versioned restructures. Hotfix paths exist and are rare by design.
- Capability building. The CoE trains and certifies the federated power-users, maintains the pattern library (how we model allocations, how we handle FX, how we name things), and runs the community that keeps knowledge from concentrating in one head.
Sizing: smaller than vendors say, more senior than clients plan
For a one-to-three-model estate, the steady state is typically two to four people: a lead who owns the roadmap and stakeholder relationships, one or two model builders, and a fractional data engineer shared with the data team. What the team must be is senior. A CoE staffed with juniors becomes a ticket queue; a CoE with one genuinely senior practitioner becomes the place where the platform strategy actually lives.
Federated, central, or hybrid
Pure central CoEs create bottlenecks and resentment; pure federation creates twelve incompatible models. The pattern that survives is hub-and-spoke: the CoE owns architecture, standards, releases and the shared data foundation; embedded power-users in each business unit own their views, their reports and small structural changes within published guardrails. The guardrails document is two pages, not forty - what spokes may change freely, what needs review, what is off-limits.
Measuring whether it works
- Cycle time on change requests - median days from intake to production, trending down.
- Forecast process health - on-time submission rates, number of off-platform workarounds (count the spreadsheets; they are the truth).
- Bus factor - every model has at least two people who can safely change it.
- Adoption depth - active planners as a share of licensed seats, scenario runs per cycle.
We usually stand up a CoE alongside the second half of an implementation, transfer ownership progressively over two to three months, and stay on a thin retainer for the architecture reviews. The goal is explicit: our own exit. A platform that needs its integrator forever is not a capability - it is a dependency with a logo.
