Okhp3 Future State Change Strategy

okhp3-future-state-change-strategy

BP-SKILL: Business Process Agent Skill Suite · part of 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. MIT License.