An EPM implementation does not become a durable enterprise capability on the day it goes live. It becomes durable when the organization knows who owns the model, how changes are approved, which metrics define success, and how the solution will evolve without breaking the discipline that made it valuable in the first place. Many programs deliver a solid first release and then drift because enhancement requests pile up, knowledge remains concentrated in a few people, support is reactive, and improvement work is driven by the loudest request rather than by enterprise value. The operating model is what prevents that drift. It gives Finance, business leaders, and IT a practical structure for running EPM as an ongoing product rather than a completed project. This chapter focuses on the design of that operating model and the continuous-improvement discipline that sustains it. It covers the structure of an EPM center of excellence, the way model changes should be governed, how performance should be measured after go-live, and how the roadmap should be managed so that the environment evolves in a controlled and value-focused way.
17.1 EPM Center of Excellence Design
An EPM center of excellence is one of the clearest indicators that the organization intends to manage its performance platform as a strategic capability rather than as a one-time implementation. Without a defined support and ownership structure, the system quickly falls into one of two unhealthy patterns. Either it becomes dependent on a small number of technical specialists who understand how it works but do not own the business process, or it becomes fragmented as Finance teams make local adjustments outside a controlled model because nobody is clearly responsible for governing the whole environment. A center of excellence exists to prevent both outcomes.
Center of excellence: the permanent cross-functional team responsible for governing, supporting, enhancing, and protecting the EPM environment after implementation. This does not always require a large standalone department. In some organizations, it is a formal team. In others, it is a virtual structure made up of named roles from Finance, IT, data management, and reporting. What matters is not whether the structure is centralized in one org chart. What matters is whether ownership is clear, skills are sufficient, and decision rights are durable.
The first design decision is scope. The center of excellence should not be defined only as a technical support unit. If it is, the organization will treat EPM issues as configuration problems even when they are actually process, governance, or data problems. A more effective scope usually includes five responsibilities. Platform stewardship: administration, release management, access control, and issue coordination. Functional ownership support: working with FP&A, controllership, and reporting teams to preserve process integrity. Data and model governance: ownership of dimensions, hierarchies, mappings, assumptions, and standards. Enhancement delivery: intake, prioritization, design coordination, testing, and controlled deployment of changes. Adoption and capability support: user guidance, training refresh, super-user coordination, and support for new business areas coming into the model.
Role design within the center of excellence should reflect this broader mission. Most mature EPM operating models include a product owner: the senior Finance leader or delegate responsible for business priorities, model direction, and value realization. There is often a platform lead: the person accountable for administration, release coordination, and technical support quality. A functional lead or leads: often from FP&A, controllership, or management reporting, define the business logic and evaluate enhancement requests against process objectives. A data or metadata steward: manages hierarchies, mappings, structural changes, and data-quality coordination. In larger environments, reporting specialists, integration specialists, and training coordinators may also sit within the team or operate in close partnership with it.
The center of excellence should also define its service catalog. This sounds operational, but it is strategically important because it establishes what the organization can expect from the team and what must be handled elsewhere. A practical service catalog often includes recurring cycle support, master-data maintenance, security administration, report updates, minor model enhancements, defect management, release testing coordination, training support, and improvement analysis. It should also clarify what is out of scope, such as policy decisions reserved for Finance leadership, enterprise master data decisions controlled elsewhere, or major transformation initiatives that require project funding.
Funding and capacity models are often underestimated. Some organizations expect the center of excellence to absorb every new request with no added capacity, which leads quickly to backlog growth and uncontrolled local workarounds. Others overstaff the team with technical resources but underinvest in Finance ownership, which weakens business relevance. The operating model should therefore make visible how demand is funded, how project work differs from run support, and how capacity will scale as new functions, regions, or scenarios are added.
Engagement with the business is another critical design point. The center of excellence should not become a remote gatekeeper that users experience only when something fails. Strong models establish named super-users or process champions in major business units and functions. These people act as the first line of support for common questions, reinforce process discipline, and translate local business needs into structured requests. This reduces noise into the central team and keeps business ownership alive.
Governance forums should connect directly to the center of excellence. A typical structure includes a monthly or biweekly operations review for incidents, release readiness, and demand intake; a design or standards authority for structural decisions and major exceptions; and periodic business-priority reviews with Finance leadership to align enhancements to enterprise value. This rhythm keeps the team from becoming purely reactive.
The final design question is whether the center of excellence is judged mainly on system uptime or on business effectiveness. The answer should be the latter. Availability and support responsiveness matter, but the true purpose of the team is to protect the quality of planning, close, reporting, and decision support. A center of excellence is working when the business sees it not as the people who “run the tool,” but as the group that keeps enterprise performance management reliable, coherent, and continuously improving.
17.2 Model Change Management
Every EPM environment starts to change almost immediately after go-live. New products are introduced. Business structures are reorganized. Management wants a different KPI view. Acquisition entities need to be added. Forecast rules need refinement. Users ask for more detailed planning in one area and less detail in another. Some of these changes create real value. Others threaten the integrity of the model. Model change management is the discipline that separates the two.
Model change management: the structured process for requesting, assessing, approving, designing, testing, deploying, and documenting changes to the EPM environment. This includes not only configuration changes, but also adjustments to hierarchies, mappings, workflows, reports, driver logic, security, calculations, and supporting processes. In a mature operating model, no material change enters production simply because a senior user asks for it by email.
The first principle is that every requested change should be traceable to a business problem or an operational need. A useful intake process therefore asks for more than a desired feature. It asks what issue is being solved, which users are affected, how frequently it occurs, what process it touches, what risk it carries if left unresolved, and what business value the change is expected to create. This prevents enhancement backlogs from filling with low-value preferences dressed up as urgent requirements.
Changes should be categorized because not all of them deserve the same governance path. A common structure includes break-fix changes: corrections to defects or control issues that prevent the process from functioning as designed. Regulatory or mandatory changes: updates required by accounting, legal, tax, or audit obligations. Operational changes: hierarchy updates, new entities, role changes, or cycle-specific structural maintenance needed to keep the process current. Enhancement changes: improvements to usability, reporting, model logic, or process scope intended to increase value. Transformational changes: large additions such as new planning domains, major reporting redesign, or new regions entering the template. Each category should follow an approval and release path proportionate to its risk and significance.
Prioritization is where many operating models weaken. The loudest stakeholder often receives attention first, even when the enterprise value is low. A better approach uses a small set of prioritization criteria. Business impact: how much the change improves decision quality, control, efficiency, or risk management. User reach: whether the issue affects one team or many. Urgency: whether the change is tied to a calendar deadline or a live control gap. Complexity: how much design, data, and testing effort the change will require. Standardization effect: whether the change strengthens the template or introduces fragmentation. This discipline helps the center of excellence explain why some requests are fast-tracked and others are deferred.
Design review must be built into the process. Too many organizations let developers or administrators implement requested changes before Finance has agreed on the policy or business logic behind them. That is how inconsistent calculations and shadow exceptions accumulate. Material changes should therefore pass through functional review and, where necessary, design-authority review before build begins. The review should answer simple but essential questions: does the requested change align with the enterprise model; does it create a local exception; does it duplicate logic already available elsewhere; and will it affect reports, controls, or reconciliations beyond the immediate request?
Release management then turns approved change into controlled deployment. The EPM environment should have clearly separated development, test, and production environments, with promotion steps that require documented approval. Changes should be bundled where practical into scheduled releases so testing can be coordinated and users understand when to expect updates. Emergency changes will still occur, especially around close or major forecast cycles, but they should remain the exception and should be reviewed retrospectively.
Testing obligations should scale with impact. A label change on a noncritical report does not need the same regression effort as a revised allocation rule or a new hierarchy that affects consolidated reporting. The change-management process should therefore define risk tiers and associated testing expectations. High-impact model changes typically require functional testing, reconciliation review, and user sign-off before promotion. Lower-risk changes may require lighter validation, but they should still be logged and documented.
Documentation is often the first thing teams skip when pressure rises, which is precisely when it matters most. Model change management should create a durable record of what changed, why it changed, when it changed, who approved it, which objects were affected, and whether supporting documentation or training was updated. This reduces key-person dependency and makes future troubleshooting much easier.
Another important element is to change communication. Users do not need a long technical note for every update, but they do need to know when a workflow changes, when a report definition changes, when a hierarchy has moved, or when a prior workaround is no longer valid. Good change communication is brief, role-based, and tied to the business cycle. It tells users what changed, what it means for them, and what action, if any, they must take.
Model change management is mature when users trust that the environment can evolve without becoming unstable. They know how to request changes, they understand why some are approved and others are not, and they believe that when an update reaches production it has been tested, documented, and aligned to the broader operating model. That trust is one of the most important assets an EPM team can build after implementation.
17.3 Performance Measurement
Continuous improvement cannot be sustained on intuition alone. Finance leaders need a factual view of whether the EPM environment is delivering the outcomes it was meant to deliver and where further improvement work will create the most value. That requires measurement. Many organizations track only technical support metrics after go-live, such as ticket volumes or system availability. Those indicators matter, but they are not enough. The environment should be measured as a performance-management capability, not just as an application.
Performance measurement: the structured tracking of business, process, adoption, and support metrics that indicate whether EPM is improving planning, forecasting, close, reporting, and decision quality. The right measures should reflect the original business case while also capturing operational health in a steady state.
The most useful metrics usually sit in four groups. Process efficiency: planning cycle time, forecast turnaround time, close duration, board-pack preparation time, and time spent on reconciliation or commentary collection. Process quality: forecast variance against agreed measures, number of material post-close adjustments, on-time submission rates, validation failure rates, and report correction frequency. Adoption and behavior: percentage of users completing cycles through workflow, volume of reopen requests, use of shadow spreadsheets in critical processes, training completion, and quality of commentary or forecast explanations. Run effectiveness: incident volume, issue resolution time, release success rate, and backlog aging.
Metrics should be tied to purpose. Planning-cycle reduction matters because the business needs more time to act. Forecast-accuracy improvement matters because management needs earlier warning and better response quality. Reduced spreadsheet use matters because the enterprise wants traceability and consistency. If the team measures only activity without linking it to purpose, the metrics become administrative rather than strategic.
Baseline and target discipline are essential. The organization should preserve the pre-implementation baseline where possible and compare current performance against it over time. This prevents the common post-go-live problem in which everyone feels the process is “better” but nobody can show where it improved or where it remains weak. Targets should also reflect maturity. A first-year target may focus on cycle reliability and adoption, while later years focus more on forecasting quality, broader use cases, and reduction of manual work.
Performance measures should be reviewed in a structured cadence. The center of excellence and Finance leadership should use monthly operational reviews for support and cycle indicators, quarterly reviews for benefits and adoption trends, and annual reviews for larger roadmap choices. What matters is that the measures influence decisions. If on-time forecast submission is deteriorating, something in calendar discipline or model usability needs attention. If report corrections remain high, either the data and control framework or the report-design standard is still weak. Measurement should trigger action, not simply produce dashboards.
Qualitative evidence still matters. Finance leaders should supplement metrics with user feedback, super-user input, post-cycle reviews, and targeted assessments of areas where the numbers alone do not explain behavior. For example, a stable cycle time may hide a growing burden of local offline analysis that has not yet appeared in incident metrics. A reasonable forecast-accuracy number may still mask bias in one region or function. Continuous improvement works best when hard metrics and grounded qualitative insight are used together.
The final discipline is benefit realization. The organization should continue to track whether the original business case is being realized and whether new waves of value are emerging. That may include less manual effort, more frequent scenario use, improved workforce planning discipline, faster management review preparation, or tighter alignment between close and board reporting. EPM should be managed as a source of business performance improvement, not merely as a cost center for maintaining finance technology.
17.4 Roadmap Management
No EPM environment should remain static after the first release, but neither should it expand without discipline. Roadmap management is the process that ensures the platform evolves in the right sequence, at the right pace, and for the right reasons. Without a roadmap, improvement becomes reactive. The team spends its time responding to local requests and urgent defects while larger sources of enterprise value are delayed or lost. With a roadmap, enhancement work is connected to strategic priorities, operational reality, and the capacity of the organization to absorb change.
Roadmap management: the ongoing process of defining, sequencing, funding, and reviewing future capabilities and improvements for the EPM environment. A sound roadmap balances short-term fixes, medium-term functional expansion, and longer-term strategic development. It should be owned jointly by Finance leadership and the EPM operating model, not by IT or a vendor alone.
The roadmap should usually begin with stabilization priorities. After go-live, the most urgent value often comes from improving usability, strengthening controls, simplifying workflows, and addressing recurring cycle pain points. These actions may look modest compared with new functional modules, but they often generate the fastest improvement in trust and adoption. Skipping them in favor of immediately adding advanced features is a common mistake.
Once the core model is stable, the roadmap can move into capability expansion. Typical areas include integrated workforce planning, enhanced cash forecasting, profitability analysis, automation of management packs, wider scenario modeling, regional rollout, or closer linkage between planning and consolidation. The sequence should be intentional. Capabilities that depend on weak master data, uncertain ownership, or unstable core processes should not be prioritized simply because they sound advanced.
Roadmap governance should make tradeoffs visible. Not every good idea belongs in the next release. Finance leadership should review roadmap items against enterprise value, dependencies, change capacity, and alignment to the target operating model. A useful roadmap conversation is not “what else can the platform do?” but “which next capability will materially improve how we manage performance?” That distinction keeps the roadmap focused on business outcomes rather than on accumulating features.
Funding logic also matters. Some roadmap items belong in the run budget because they are small enhancements or support essential operations. Others require project-style funding because they change process scope materially, introduce new business areas, or require significant design, integration, and training effort. The roadmap should make this distinction explicit so that improvement work does not become trapped between operations and capital funding models.
Capacity and change absorption should influence sequencing. Even a high-value enhancement can fail if the business is already absorbing a new close rhythm, major organization change, or another finance transformation. Strong roadmap management therefore considers not just whether the team can build the change, but whether Finance and the business can adopt it without weakening current discipline. Sometimes the right decision is to delay a valuable capability until the operating model is ready.
A mature roadmap also contains architectural and control work, not only user-facing features. Master-data improvements, security refinement, reconciliation automation, archive and retention design, performance tuning, and technical debt reduction may not excite business stakeholders, but they can be essential enablers of later value. The roadmap should therefore balance visible benefits with foundational improvements that keep the platform healthy.
Review cadence is important because roadmaps should be living documents, not annual presentations forgotten after budget season. Quarterly review is common and usually effective. It allows the organization to assess benefit realization, incorporate new business priorities, evaluate whether earlier releases landed successfully, and adjust sequencing without losing strategic continuity. The roadmap should change thoughtfully, not drift constantly.
The best roadmaps also preserve a point of view about the future state. They show how the enterprise expects EPM to develop over several horizons. Near-term horizon: stabilization, usability, cycle reliability, and reduction of manual work. Medium-term horizon: broader planning domains, better scenario coverage, stronger management reporting, and additional rollout waves. Long-term horizon: deeper strategic integration, predictive capabilities where justified, and tighter connection between financial and operational performance management. This structure helps leadership avoid both short-termism and unrealistic overreach.
Roadmap management is working when the organization can explain why each upcoming investment matters, what must be true before it is delivered, and how it strengthens the overall performance-management model. At that point, EPM is no longer just being maintained. It is being developed deliberately as a long-term enterprise capability.
