Okhp3 Future State Change Strategy

---
name: okhp3-future-state-change-strategy
description: "Design a target-state process and a structured change strategy from a gap analysis. Use this skill when the user wants to redesign a process after gaps have been identified; when they ask \\\"what should the process look like\\\", \\\"how do we fix this\\\", \\\"design the to-be process\\\", or \\\"build a change plan\\\". This is a recommended extension skill — use after okhp3-process-gap-exception-analysis has produced a gap analysis. Do not use it to document only the current state — that is okhp3-as-is-process-capture; this skill designs what should change, not what exists today. Scope firewall applies: never include employer-proprietary constraints without explicit user authorisation. Produces a future-state process artifact and a change strategy document."
license: "MIT"
compatibility: "Prioritising gaps and drafting the change strategy need no special runtime. scripts/generate-future-state.mjs needs a JavaScript runtime that executes ES modules (Node.js); no minimum version is pinned in this repository. If it cannot run, scaffold the future-state YAML by hand from the gap analysis using references/change-strategy-framework.md and say so in your output rather than presenting the result as machine-generated."
metadata:
  bp_skill_version: "0.3.0"
  status: "recommended-extension"
  version: "0.2.0"
  author: "OverKill Hill P³"
  project: "BP-SKILL: Business Process Agent Skill Suite"
  category: "process-improvement"
  origin: "OKHP3/mermaid-diagram-bpmn"
  author-github: "https://github.com/OKHP3"
  in_scope: "Future-state process design and change strategy grounded in an as-is process and documented gap analysis."
  out_of_scope: "Current-state documentation only, unapproved implementation, unsupported organizational claims, or autonomous change execution."
  standards_refs: "BPM CBOK v4 §7 (Process Transformation); BABOK v3 §7.5 (Recommend Actions to Increase Solution Value); Kotter 8-Step Change Model; ADKAR Change Management Model"
  produces: "future-state.yaml, change-strategy.md"
  consumes: "gap-analysis.yaml"
  depends_on: "okhp3-process-gap-exception-analysis"
  tags: "future-state, to-be-process, change-strategy, process-redesign, transformation, ADKAR, Kotter, BPM-CBOK"
  triggers: "design the future state; to-be process; change plan; redesign the process; improvement strategy; fix the gaps; target state; change management"
  homepage: "https://github.com/OKHP3/mermaid-diagram-bpmn/tree/main/skills/okhp3-future-state-change-strategy"
  repository: "https://github.com/OKHP3/mermaid-diagram-bpmn"
---

# okhp3-future-state-change-strategy

**BP-SKILL: Business Process Agent Skill Suite** · part of [mermaid-diagram-bpmn](https://github.com/OKHP3/mermaid-diagram-bpmn) · OverKill Hill P³

---

## Purpose

Design the target-state (to-be) process and a structured change strategy based on gap analysis findings. The future-state artifact documents the intended process design; the change strategy documents how to get there.

---

## When to use this skill

- `gap-analysis.yaml` exists with at least one `critical` or `major` gap
- User wants to redesign a process based on identified gaps
- User needs a change management plan to accompany process redesign
- Preparing the target-state PNS input for `okhp3-process-narrative-authoring`

## When NOT to use this skill

- No gap analysis exists: run `okhp3-process-gap-exception-analysis` first
- User wants to document only the current state: use `okhp3-as-is-process-capture`
- Scope firewall: do not include confidential employer constraints, proprietary system names, or commercially sensitive process details without explicit user instruction

---

## Scope Firewall

This skill operates on process abstractions. Before authoring the future state:
- Confirm all described gaps are based on user-provided information
- Do not infer proprietary business rules from industry knowledge without flagging them as assumptions
- Flag all assumed constraints with `confidence: assumed` in the future-state YAML
- Do not include employer-identifying details in any generated artifact

---

## Future-State Design Workflow

### Step 1: Prioritise gaps

Rank gaps from `gap-analysis.yaml` by severity: `critical → major → minor → observation`.

Focus the future-state design on resolving all critical and major gaps.

### Step 2: Design to-be steps

For each resolved gap, define the replacement or new step:
- State the intended action in a single imperative statement
- Assign a named role (not a person)
- Define entry and exit criteria
- Specify any system or tool involved

### Step 3: Validate completeness

Check the future-state design covers:
- All structural gaps (missing steps, unowned activities)
- All exception gaps (undefined handling, missing escalation)
- All compliance gaps (absent controls, missing segregation)

### Step 4: Define change approach

For each major change, define:
- `change_type`: add | remove | modify | automate | transfer
- `effort`: low | medium | high
- `risk`: low | medium | high
- `dependencies[]`: other changes that must happen first
- `owner_role`: who is responsible for implementing this change

### Step 5: Draft change strategy

Structure the change strategy document with:
1. **Change summary**: what is changing and why
2. **Stakeholder impact**: who is affected, how significantly
3. **Transition plan**: sequence and timeline for changes
4. **Risk register**: what could go wrong during transition
5. **Communication plan**: how and when to inform each stakeholder group
6. **Success criteria**: how to know the change has landed

---

## Output Schema

`future-state.yaml` contains:
- `process_id`: matches PIR `process_id`
- `future_state_version`: "0.1-draft" initially
- `design_date`, `designed_by_role`
- `resolved_gaps[]`: each gap from `gap-analysis.yaml` with its resolution
- `to_be_steps[]`: `id`, `description`, `actor_role_id`, `systems[]`, `confidence`
- `open_assumptions[]`: assumed constraints flagged for user confirmation
- `change_items[]`: each with `change_type`, `effort`, `risk`, `dependencies[]`, `owner_role`

---

## Handoff Instruction

Pass `future-state.yaml` to `okhp3-process-intake-and-scope` or `okhp3-process-narrative-authoring` to create the target-state PNS. The future-state steps map directly to `activity_sequence.activities[]` in the new PNS.

---

## Execution contract

Apply this contract on every run so the artifact is trustworthy and reusable:

1. State the input evidence, assumptions, and unresolved questions before drafting. Never invent missing process facts, owners, controls, dates, or approvals.
2. Preserve stable identifiers and source traceability. When transforming an upstream artifact, retain its IDs and cite the source field or section for each derived decision.
3. Produce the declared artifact exactly, including required fields and valid values. Keep unsupported, uncertain, or not-applicable items explicit instead of silently omitting them.
4. Validate the result with the bundled script or fixture when available. Report validation status, warnings, and any manual review still required.
5. Stop and request the missing input when a boundary, approval authority, or safety-critical rule cannot be inferred. A partial artifact with clearly marked open questions is safer than a confident fabrication.

If `scripts/generate-future-state.mjs` cannot run, scaffold the YAML by hand from `gap-analysis.yaml` using `references/change-strategy-framework.md`, and state in the output that automated scaffolding was not run.

## References

Load on demand:
- `references/change-strategy-framework.md`: change type taxonomy, effort/risk classification, ADKAR and Kotter alignment, and scope firewall rules

## Scripts

- `scripts/generate-future-state.mjs`: scaffolds future-state YAML from gap-analysis input

## Assets

- `assets/fixtures/future-state-example.yaml`: canonical future-state design for purchase-approval process

## Evaluation and release status

No `evals/evals.json` exists for this skill yet, and none of the five root-level `evals/` categories cover future-state output directly. The only current check is the maintainer-facing `tests/validate-skill.test.mjs` against `assets/fixtures/future-state-example.yaml`. Evidence status: `not-run` for task quality and skill uplift.

Version 0.2.0 (this pass) added the `compatibility` declaration, the script fallback instruction, and a sharper discovery-time boundary against `okhp3-as-is-process-capture`. Classified minor per the versioning table, not patch. No regression suite exists to run before this bump; that limitation is disclosed, not implied away.

---

## About

Part of the **BP-SKILL: Business Process Agent Skill Suite**, published in [overkillhill/mermaid-diagram-bpmn](https://github.com/OKHP3/mermaid-diagram-bpmn). MIT License.