Operating-Model Maturity and Evolution

COMPEL Specialization — AITM-OMR: AI Operating Model Associate Article 9 of 10

An operating-model maturity model makes two things possible that a static design cannot. It lets the specialist communicate the organization’s current position honestly — not just “where we are” but “where we are on each of the ten dimensions”. And it lets the specialist sketch a planned evolution that the organization can execute rather than a target that exists only in aspiration. This article introduces the five-level maturity progression that COMPEL uses across its curriculum, shows how it applies to each of the ten operating-model dimensions, names the common evolution sequences and anti-patterns, and teaches the change-capacity discipline that separates executable plans from wishlists.

The five levels

COMPEL uses a five-level maturity model inherited from the broader transformation framework and used consistently across its twenty-domain maturity work. The five levels apply to each operating-model dimension independently.

Nascent is the starting state. The dimension exists in inchoate form — perhaps an initial central AI team, a first capability map, a draft decision-rights matrix, a provisional funding arrangement — but the structures have not yet been tested in practice. Nascent is honest rather than pejorative; every organization begins there on every dimension.

Emerging is the state where the dimension has been designed, documented, and piloted in a limited scope. The CoE has been stood up and has delivered its first platform services; the capability map has informed at least one operating-model decision; the decision-rights matrix has been used for at least one high-risk decision. The dimension is functioning but not yet consistently across the organization.

Scaling is the state where the dimension has been deployed broadly and is producing consistent results. The CoE’s service catalogue is in active use across business units; the capability map is refreshed on cadence and feeds portfolio decisions; the decision-rights matrix governs all classified AI decisions. Issues have surfaced and been resolved. The dimension is no longer novel; it is operational.

Mature is the state where the dimension is optimized, measured, and self-correcting. The CoE’s value metrics are tracked quarterly and drive service-catalogue changes; the capability map is maintained by the enterprise-architecture function with AI input; the decision-rights matrix is audited and refined. The dimension is durable enough to survive staff turnover and leadership changes.

Transformational is the state where the dimension is producing strategic advantage beyond the organization’s prior performance. The CoE is an identifiable source of competitive advantage (often through platform capabilities peers cannot replicate); the capability map informs acquisition and divestment decisions; the decision-rights architecture survives external scrutiny (regulatory, M&A due diligence, public incident) without fault. Transformational-level maturity is rare and usually takes many years to build.

The levels are descriptive rather than prescriptive. Organizations do not all aim for transformational on every dimension; the right level for each dimension depends on the organization’s strategic use of AI. A regulated financial institution may reasonably target transformational on governance-related dimensions and mature on operational ones; a fast-moving product company may target transformational on platform and scaling on everything else. The maturity model is the common vocabulary; the target on each dimension is a strategy choice.

[DIAGRAM: Scoreboard — maturity-scorecard-ten-dimensions — two-column table with rows Archetype, Capability Map, CoE Design, Decision Rights, Funding, Talent, Platform, Integration, Maturity, Cadence; column 1 shows current level (nascent/emerging/scaling/mature/transformational) with sample values; column 2 shows target level with sample values; primitive makes the full ten-dimension maturity picture visible with current-vs-target contrast]

Common evolution sequences

Four sequences recur across enterprises that publish their operating-model evolution. Recognizing the sequences lets the specialist anticipate what the next stage probably looks like.

The centralize-then-distribute sequence starts with a centralized archetype to build capability, standards, and first platform, then distributes to hybrid or federated as the spokes mature. Gartner’s longitudinal AI maturity research, published in multiple 2024 research notes, documents the sequence as the most common evolution path for enterprises that began AI work in the 2019-2022 window and reached meaningful scale by 2024.¹ The BBVA digital transformation, described in multiple Harvard Business Review cases between 2019 and 2023, follows a version of this pattern from initial centralized digital capability to a more distributed AI-and-digital structure at maturity.²

The platform-after-use-case sequence starts with a few successful use cases built on custom infrastructure, then invests in platform infrastructure once the pattern is clear, then scales more use cases on the platform. The sequence avoids the early-investment trap of building a platform before anyone has used AI, but it requires discipline at the pivot point — teams that built custom infrastructure for their first use cases must migrate to the platform, and migration resistance is predictable.

The decision-rights-after-incident sequence is the reactive pattern. The organization’s decision-rights architecture matures most rapidly after an incident (a model that shipped without adequate review, a regulator inquiry, a public AI failure) that makes the gaps visible. Mature specialists try to lead the decision-rights work rather than react to incidents, but the reactive pattern is so common that the specialist should expect it and use the moment of attention an incident creates to accelerate the design work that was overdue.

The funding-model-after-cost-surprise sequence is another reactive pattern. The funding model matures most rapidly when the organization’s AI spend surprises the CFO. The specialist who has designed a showback or cost-to-serve capability in advance has the instrument ready when the CFO asks; the one who has not scrambles to build it under pressure, and the design decisions made under pressure are usually inferior to the ones made in advance.

Anti-patterns

Three evolution anti-patterns appear often enough to name and design against.

Plateau at emerging. Some organizations settle at emerging on most dimensions for years — the structures exist, the documents are written, but the dimensions never scale into consistent operation. The plateau is usually produced by weak sponsorship, misaligned incentives, or a funding model that does not support the continuous investment scaling requires. The corrective is usually outside the operating-model layer: the sponsor must invest political capital, the incentives must change, or the funding must be adjusted. A specialist who proposes more operating-model design work to fix a plateau has misdiagnosed the problem.

Overshoot to transformational. Some organizations aim for transformational on dimensions where the organizational strategy does not justify it — building a transformational-level platform capability when the organization’s AI ambition is limited, or targeting transformational governance when the regulatory exposure does not require it. The overshoot consumes resources that should have gone to dimensions that matter more. The discipline is to target each dimension at the level the strategy actually needs, not at the highest available level on principle.

Uneven evolution. Some organizations advance one or two dimensions rapidly while leaving others at nascent or emerging. The unevenness produces friction — a mature CoE with a nascent decision-rights framework cannot use its maturity because decisions are not being made in the structures the CoE was built to serve. The operating model advances most reliably when the dimensions advance together, even if at different rates; an evolution plan that targets mature on three dimensions and nascent on seven is a gap factory.

Change-capacity discipline

Every evolution plan must clear a change-capacity test. Organizations have finite absorption: a plan that exceeds the organization’s realistic change capacity produces transformation fatigue, visible resistance, and ultimately plan abandonment. The specialist’s discipline is to size the evolution to what the organization can actually absorb, not to what the strategy paper says is needed.

Three inputs size change capacity. Active-initiative count measures how many concurrent transformation initiatives the organization is already running. An organization with twenty active initiatives cannot usefully absorb the fifteen changes a full operating-model evolution would require. The specialist either stages the evolution across multiple years or negotiates with the sponsor to retire some active initiatives before the new ones start. Historical absorption rate measures how many major changes the organization has successfully delivered per year in recent history. Organizations that deliver two to three major operating-model changes per year cannot usually scale to six without new capability. Sponsor attention budget measures how much of the sponsor’s time is available for the evolution, not in hours but in focus-days. An evolution that requires weekly sponsor attention for fifty-two weeks will collide with the sponsor’s other priorities and stall.

A well-sized evolution plan fits inside the change capacity and leaves margin for the unexpected. An evolution plan that fills the capacity entirely leaves no room for the unforeseen problem that every transformation encounters.

[DIAGRAM: Timeline — operating-model-evolution-horizon — horizontal timeline spanning 0-36 months with three phase blocks (Phase 1 Foundation 0-12, Phase 2 Scaling 12-24, Phase 3 Maturity 24-36); within each phase block, named deliverables on each of the ten dimensions are placed; colour-coded bars indicate dimension advancement from nascent through mature; primitive shows the multi-year evolution shape and the cross-dimension coordination]

Sequencing the first twelve months

For operating models at the nascent or emerging stage, the first twelve months have a reliable shape. The specialist who proposes a different sequence should have a specific reason.

Months one through three focus on the foundation: confirming archetype, building the capability map, drafting the CoE charter, publishing the initial decision-rights matrix, and announcing the funding model. The first-quarter deliverables establish the operating-model existence; without them nothing else in the evolution is grounded.

Months four through six focus on deployment: standing up the CoE’s first services, piloting decision-rights in a small number of real cases, establishing the funding flows, hiring the first wave of internal talent. The second-quarter deliverables turn the documented structure into an operating one.

Months seven through nine focus on scaling the first wave of use cases through the new operating model. The operating model is tested by real decisions on real initiatives. Gaps surface. The specialist’s work in this period is primarily to resolve the gaps surfaced by real-world use rather than to design new structures.

Months ten through twelve focus on the first measurement cycle: the CoE’s value metrics produce their first real numbers, the decision-rights architecture produces its first auditability evidence, the funding model produces its first reconciled accounts. The fourth-quarter deliverables close the first year and set the baseline for year two.

The sequence is not universal but it is defensible. Specialists who propose something substantially different should have a named reason — a regulatory deadline, a specific transformation window, an incident response that accelerates particular dimensions. An unexamined deviation from the reliable sequence usually produces a twelve-month cycle with dimensions that never consolidate.

Measuring maturity credibly

Maturity scores are easy to game. A specialist who wants to report progress can shade a dimension from emerging to scaling without clear evidence; an organization that wants to look good to its board can do the same. The defence against gaming is evidence discipline — every maturity rating carries specific evidence that defends it, and the evidence is reviewable by someone outside the rating specialist.

Three evidence types appear consistently across rigorous maturity assessments. Artifact evidence is the documented artifacts the dimension produces — a published CoE charter, a complete accountability matrix, a funding reconciliation for a full fiscal year. Artifact evidence is the easiest to check and the hardest to fake, because the artifacts either exist with the characteristics described or they do not. Operational evidence is the observed operation of the dimension — a quarter of monthly operations reviews that occurred as scheduled, a year of decision-register entries that show the decision-rights framework in use, a period of CoE service consumption across the promised business units. Operational evidence requires sustained observation rather than a single check. Outcome evidence is the downstream outcomes the dimension produces — time-to-deployment for new use cases, incident rates for governed systems, retention rates for specialist talent, net-promoter scores from CoE consumers. Outcome evidence is the most persuasive and the hardest to gather because it requires the outcomes to have occurred over meaningful time windows.

A well-defended maturity rating cites at least two of the three evidence types. A rating that cites only self-report evidence is weak; a rating that cites artifact and operational evidence is usable; a rating that cites all three is defensible under external scrutiny.

The learn-forward evolution

One particular evolution pattern deserves specific naming because it departs from the linear nascent-to-transformational progression most maturity models assume. The learn-forward evolution is the deliberate choice to operate at a lower maturity on specific dimensions for a specific period in order to learn what the organization actually needs from those dimensions before investing in the full design.

The pattern fits early-stage operating models where the organization does not yet have enough AI practice to know what its mature CoE, funding model, or talent model should look like. Investing in mature design in year one produces artifacts that have to be rebuilt in year three when the organization’s actual needs become clear. Operating with deliberately lighter structures in year one, learning from the operation, and then building the mature design in year two or three produces designs that fit the organization’s actual needs rather than its theoretical needs.

The learn-forward pattern is not an excuse for weak design. It is a deliberate choice, documented in the Blueprint, with specific learning objectives and a defined point at which the organization commits to the full design. A specialist who recommends learn-forward must name what specifically the organization is learning, how the learning will be captured, and when the mature design will replace the interim one. Without the naming, learn-forward becomes an indefinite deferral and the organization never matures at all.

Summary

The maturity model gives the specialist and the organization a common vocabulary for describing where each of the ten dimensions sits today and where it needs to be. Four evolution sequences recur often enough to recognize. Three anti-patterns — plateau, overshoot, uneven evolution — are common enough to design against. Change capacity is the discipline that separates executable plans from wishlists. The first twelve months of operating-model evolution have a reliable sequence that the specialist should follow absent specific reason to deviate. Article 10 assembles the full ten-dimension design into the Operating Model Blueprint — the executive-grade artifact the credential certifies the specialist to produce.

Cross-references to the COMPEL Core Stream:

• EATL-Level-4/M4.4-Art01-Anatomy-of-the-AI-Native-Operating-Model.md — leader-level anatomy of the mature operating model, including the maturity-progression view
• EATE-Level-3/M3.1-Art06-AI-Operating-Model-Design.md — expert-depth treatment of operating-model design, including evolution

Q-RUBRIC self-score: 89/100

© FlowRidge.io — COMPEL AI Transformation Methodology. All rights reserved.