C1. Process Model
The process model in five phases: Assess, Strategize, Pilot, Scale, and Operate, with decision gates and anti-patterns.
Adopting AI is not a one-time project but a long-term transformation process.
What this chapter delivers: the end-to-end process model in five phases (Assess, Strategize, Pilot, Scale, Operate) with clear decision gates between phases, each phase with activities, deliverables, participants, and the most common mistake. It answers how to proceed; the concrete, prioritized implementation plan follows in chapter C2, the critical transition into regular operations in chapter C3.
The five phases at a glance
Each phase has a clear goal and defined activities. The phases build on one another and are connected via the decision gates in the next section. Different business units can be in different phases at the same time.
| Phase | Goal | Key activities |
|---|---|---|
| 1. Assess | Know the starting point | Determine maturity per dimension (see chapter A3), survey the data landscape, get an initial read on opportunities and risks |
| 2. Strategize | Set strategic guardrails | Anchor the AI strategy with management, set up a governance structure, classify data sources, formulate the target picture (see chapter B1) |
| 3. Pilot | Prove value, build the learning curve | Implement prioritized use cases in individual areas, establish FinOps mechanisms from the start, create initial reusable building blocks (feature store, prompt library) |
| 4. Scale | Broad implementation | Integrate AI into core systems, standardize development and operating processes (MLOps/LLMOps), introduce enterprise-wide metrics |
| 5. Operate | Continuous operation and optimization | AI as an integral part of processes and products, fully established governance, focus shifts from projects to ongoing improvement |
The phases in detail
Each phase is described with the same six fields. The durations are experience-based values for mid-sized organizations; they scale with company size and ambition level.
Phase 1: Assess
| Field | Description |
|---|---|
| Goal | An honest picture of the starting point: maturity, data situation, initial opportunities and risks |
| Core activities | Run the maturity assessment in five steps, survey the data landscape and systems (see chapter B4), inventory ongoing and failed AI initiatives (incl. shadow AI, see chapter A1), collect initial use-case ideas without evaluating them yet |
| Deliverables | Maturity profile per dimension with named gaps, data source inventory, inventory of existing initiatives, unfiltered idea list |
| Typical duration | 4 to 8 weeks; longer is usually a sign of too much detail in the wrong place |
| Lead | AI program lead or external support; executive management and IT leadership actively contribute (see chapter B7) |
| Most common mistake | The analysis becomes an end in itself: months of data gathering instead of entering strategy work with a solid 80 % picture |
Handling shadow AI that is found: the inventory almost always surfaces unapproved tools (see chapter A1). Each finding is assessed and assigned one of three consequences instead of merely being noted:
| Finding | Consequence | Approach |
|---|---|---|
| Meets a real need, acceptable risk | Legalize | Move it onto the official path: provide an approved variant, add it to the register and governance |
| Real need, but unacceptable risk (data leakage, compliance) | Replace | Provide a safe alternative and support the switch before closing the old path |
| No real need or not defensible | Shut down | Block access, communicate the reason and, where possible, an alternative |
The most common mistake is simply banning it without an alternative: that only pushes usage further underground.
Phase 2: Strategize
| Field | Description |
|---|---|
| Goal | An adopted strategy with governance, a prioritized portfolio, and a target picture |
| Core activities | Define vision and ambition level (see chapter B1), systematically collect and prioritize use cases (see chapter B2), clarify the build-buy-partner principle per field (see chapter B3), set up the operating model and roles (see chapters B6 and B7), define the regulatory frame and ethics guardrails (see chapters B8 and B10), create the roadmap |
| Deliverables | Adopted AI strategy with budget, prioritized portfolio, roadmap with a first wave, workable governance (AI register, release process), named roles |
| Typical duration | 2 to 4 months; in parallel, first low-risk tools can already be tried out |
| Lead | Chief AI Officer / CIO with AI mandate; adoption by executive management or the board with the executive AI sponsor |
| Most common mistake | The strategy remains a paper: no budget decision, no named people, no first wave with dates. How to recognize it: three months after adoption, no use case has started |
Phase 3: Pilot
| Field | Description |
|---|---|
| Goal | Proven value on real use cases and a growing learning curve for the organization |
| Core activities | Implement 2 to 4 prioritized use cases (no more, see anti-patterns below), define success criteria and a baseline per pilot up front (see chapter D1), work with production data, carry FinOps mechanisms along from the start (see chapter D2), run the security and ethics review per pilot (see chapters B9 and B10), build reusable building blocks (model access, prompt library, evaluation suite) |
| Deliverables | Pilots with a measured result against the baseline, completed go/no-go checklists, first platform building blocks, documented lessons learned |
| Typical duration | 3 to 6 months per pilot; pilots without an end date are not pilots but permanent stopgaps |
| Lead | AI product owner per use case; the AI program lead coordinates across pilots |
| Most common mistake | The pilot is built as a demo instead of a precursor of production: curated data, no integration, no cost measurement. The consequence is failure at the transition (in detail in chapter C3) |
Phase 4: Scale
| Field | Description |
|---|---|
| Goal | Successful pilots become broadly embedded solutions integrated into core systems |
| Core activities | Rollout following a defined strategy (staged by unit or user group), integration into core systems and processes (see chapter B5), standardization of development and operations (MLOps/LLMOps), enablement at scale (see chapter B11), enterprise-wide metric and cost reporting (see chapter D4) |
| Deliverables | Production solutions with a service owner and support, a standardized delivery pipeline, reporting to management and boards, a growing share of reused building blocks |
| Typical duration | 6 to 18 months depending on integration depth and footprint |
| Lead | Service owner per solution, platform engineering for the shared building blocks, the Portfolio Board steers the sequence |
| Most common mistake | Scaling by copying: the pilot is simply cranked up instead of being transferred onto the production-ready platform. Technical debt from the pilot phase grows with it |
Phase 5: Operate
| Field | Description |
|---|---|
| Goal | AI is regular operations: reliable, economical, continuously improved |
| Core activities | Ongoing monitoring of quality, drift, costs, and fairness (see chapters D1 and B10), regular re-evaluation against the success criteria, lifecycle management (model changes, decommissioning), continuous intake of new use cases via the established process, annual effectiveness review of governance (see chapter B7) |
| Deliverables | Stable service targets, reliable cost-benefit reporting, a maintained AI register, planned modernization instead of firefighting |
| Typical duration | Ongoing; the effort shifts from project work to product care |
| Lead | Service owners and the operations organization; the Portfolio Board for the overall portfolio |
| Most common mistake | Operations become a blind spot: after the rollout, nobody looks at quality and costs anymore until an incident or an invoice forces it |
Decision gates between phases
Every phase ends with an explicit gate. The point of a gate: it forces a deliberate decision before more money and capacity are committed. Without the criteria being met, the organization does not move to the next phase but improves the current one instead.
| Gate | Central question | Why this question decides | If no |
|---|---|---|---|
| Assess → Strategize | Is the maturity level known per dimension, and are the biggest gaps named? | Without knowing the starting point, the strategy gets planned past the real bottlenecks. | Deepen the maturity assessment before committing resources |
| Strategize → Pilot | Are governance, a data foundation, and prioritized use cases with a business case in place? | Pilots without a frame create exactly the shadow-AI and PoC problems from chapter A1. | Continue strategy work; don’t start pilots without a frame |
| Pilot → Scale | Does the pilot meet the predefined scaling criteria (see chapter C3)? | Scaling is the most expensive step; a weak pilot doesn’t get better through scaling, only more expensive. | Refine the pilot or deliberately end it, rather than extending it unreflectively |
| Scale → Operate | Are operations, governance, and metrics standardized enough that new use cases can be onboarded without special effort? | Otherwise every new solution remains a one-off project and the organization never scales. | Deepen standardization before expanding further |
Gate governance: how a gate decision works
Gates only work if they are run seriously. Four determinations make the difference between a real gate and gate theater:
| Determination | Recommendation |
|---|---|
| Who decides | The Portfolio Board (see chapter B7); in small organizations, executive management. Never the team with an interest in the initiative continuing |
| On what basis | Predefined criteria with evidence (for Pilot → Scale: the go/no-go checklist), no slide prose. The documents are available before the meeting |
| Which outcomes are possible | Four outcomes, all legitimate: go (proceed), go with conditions (proceed, deliver named items by a deadline), rework (repeat the gate within a defined period), stop (end the initiative, secure the lessons learned) |
| What a stop means | A well-justified stop is a success of steering, not a failure of the team. If this is not culturally anchored, teams smuggle weak initiatives past the gates |
Not strictly linear: loops and parallel tracks
The model reads sequentially but is not lived that way. Three clarifications:
- Units progress at different paces. Customer service can be scaling while production is still piloting and a newly opened field is in Assess. Steering happens per unit or per use case, not wholesale for the entire company.
- Loops are by design. A failed gate leads back into the previous phase; a model change in operation can trigger a new pilot run; a substantial strategy change (acquisition, new regulation) can send individual use cases back to Strategize. Stepping back is a legitimate option, not a failure.
- Two tracks run permanently in parallel. Alongside the use-case track (which passes through the phases) there is the enablement track: platform building blocks, data governance, the training program, and governance processes grow continuously and independently of phases. The roadmap plans both tracks together (see chapter C2).
Alignment with the maturity model
Process phases and maturity belong together: the phases describe the planned steps, the maturity model (see chapter A3) shows how far they are actually embedded. This work deliberately uses a single maturity model with the five stages exploration, piloting, partial integration, broad embedding, and continuous optimization. The phases map onto it as follows:
| Process phase | Corresponds to maturity stage |
|---|---|
| Assess | Stage 1 (exploration) |
| Strategize | Stages 1 to 2 (exploration → piloting) |
| Pilot | Stages 2 to 3 (piloting → partial integration) |
| Scale | Stages 3 to 4 (partial integration → broad embedding) |
| Operate | Stages 4 to 5 (broad embedding → continuous optimization) |
The maturity model thus serves as a diagnostic and monitoring tool, to recognize whether the organization is on track and when the transition to the next phase becomes possible.
Typical anti-patterns
The five most common failure modes of the process, each with the signal by which to recognize it:
| Anti-pattern | How to recognize it | Remedy |
|---|---|---|
| Analysis paralysis | The assessment (Assess phase) drags well beyond the intended four to eight weeks; ever new surveys emerge instead of a decision | Set a time box; move into the next phase (Strategize) with the 80 % picture |
| Strategy without execution | An adopted paper, but no started use case three months later | Only adopt the strategy together with the first roadmap wave and budget |
| Pilot sprawl | More than the recommended two to four parallel pilots, none reaches production | The Portfolio Board caps active pilots; run the gates consistently |
| Platform-first trap | Years of platform building without a productive use case | Grow the platform only in the enablement track, in parallel with real use cases |
| Gate theater | Gates exist formally, but there has never been a rework or a stop | Set up gate governance seriously (section Gate governance); watch the stop rate: zero stops over years is not proof of quality |
Checklist: process model anchored
The checklist verifies that the process model is anchored in the organization rather than merely described:
- Current phase determined per business unit (units often progress at different paces)
- Gate criteria for the next transition defined and known
- Owner for each gate decision named; four outcome options established
- Deliverables and lead per phase clarified (tables above)
- Enablement track (platform, data, training) planned in parallel with the use-case track
- Regular alignment of phase vs. actual maturity planned
- Stepping back or repeating a phase accepted as a legitimate option, not treated as failure
- Anti-pattern signals known and watched in the portfolio review