operations-transformation git:20261001.e0a4016A

Immutable. This exact content never changes and is served at /api/v1/blob/eb4705bd92ab002b.

---
name: operations-transformation
sheetId: "3.10"
description: "Three-stage operations transformation pipeline — process discovery (SIPOC), digital transformation assessment, then automation-ready process redesign — to turn pain points into builder-ready blueprints."
category: operations
project: operations-transformation
platform: claude
status: Done
author: Peter Tu
input: "A client-described inefficient or unclear business process, ideally with prior discovery context from consult-discovery"
process: "Stage 1 SIPOC mapping → Stage 2 automation suitability diagnosis (four-quadrant + ROI) → Stage 3 sub-task / system-layer / MVP-stack redesign"
output: "SIPOC table, diagnostic table with tech recommendations and ROI, and a builder-ready redesign blueprint with MVP stack"
synergy:
  - "operations-flow-optimization"
type: agent
skills: ["operations-process-discovery", "operations-automation-validation", "operations-process-redesign"]
house-style: bound

---

# Operations Transformation

```bash
npx skills add https://github.com/peter-tu-zynkr/zynkr-skill-builder --skill operations-transformation
```

Turn an inefficient business process into a builder-ready automation blueprint through three sequential stages. Use this skill after `consult-discovery` (or whenever you already have a clear pain point) and you want to design the operational fix end-to-end before handing to an engineer.

**Every process step this skill shows uses the shared process step card** (`references/process-step-card.md`): a number, its Input · Process · Output, and — once the step touches a system — its layer and the stores it Reads and Writes (`none` when it touches none). The point is that a reader never has to cross-reference a SIPOC table against a separate architecture table to learn whether a step needs the database. Stage 1 numbers the steps; every later stage keeps those numbers, and sub-tasks number beneath them (step 3 → 3.1, 3.2).

---

## Step 1 — Collect inputs

Ask the user for:
1. **Pain-point description** — the inefficient or unclear process to redesign
2. (Optional) `STAGE1_SUMMARY` / `STAGE2_SUMMARY` from `consult-discovery` if available
3. The business outcome they want from the transformation (cost / speed / quality / scale)

Store as `PROCESS_BRIEF`.

---

## Step 2 — Stage 1: Process Discovery / SIPOC mapping (subagent)

Display:

```
---------------------------------------------
Stage 1: Process Mining — build the SIPOC map
---------------------------------------------
```

Launch the `operations-process-discovery` agent (`./agents/operations-process-discovery.md`) using the Agent tool, passing `PROCESS_BRIEF` and the absolute path of this skill's `references/process-step-card.md` (every agent launch below passes the same path; each agent also carries the rules it needs inline, so a run still works if the file cannot be read).

The agent walks through:
1. End-to-end process mapping (main stages, owners, where each step happens today) — steps numbered 1, 2, 3…
2. Supplier and Customer per step (one question at a time)
3. Agent-generated Input/Output assumptions, and Systems today where the client did not say (marked `(assumed)`)

Store the final numbered SIPOC table (`| # | Supplier | Input | Process | Output | Customer | Systems today |` — the as-is form of the step card) as `SIPOC_TABLE`.

Ask:
```
Does this SIPOC map look right? (Yes / Adjust)
```

> **Optional Stage 1.5 — quick lean pass on a tangled as-is.** If `SIPOC_TABLE` is too messy to diagnose (duplicated steps, unclear loops), you may invoke `operations-flow-optimization` here for a quick cleanup before Stage 2. Its cleaned, renumbered SIPOC (Supplier · Customer · Systems today carried through) **replaces** `SIPOC_TABLE`, and its numbers are the step ids from then on. The canonical ordering pass, however, runs AFTER Stage 3 — see Stage 3.5 below (course Ch5 §5.5.2: assess first, redesign, then optimize the ordering of the re-chained flow).

---

## Step 3 — Stage 2: Digital Transformation Assessment (subagent)

Display:

```
---------------------------------------------
Stage 2: Diagnose automation suitability
---------------------------------------------
```

Launch the `operations-automation-validation` agent (`./agents/operations-automation-validation.md`), passing `SIPOC_TABLE`.

The agent will produce:
- **Diagnostic table** per step, keyed by the Stage 1 step number — Classification (four quadrants), Tech suggestion (LLM / State Machine / Rule-based / Human) with the layer it becomes (Backend · AI / Backend · rules / Backend · human), ROI, Rationale
- **Recommendation summary** — which steps to transform now, which to defer
- A hand-off prompt to Stage 3

Store as `DIAGNOSTIC_RESULT`.

Ask the user which steps to redesign. Default: all steps marked ROI=High or ROI=Medium.

---

## Step 4 — Stage 3: Process Redesign (subagent)

Display:

```
---------------------------------------------
Stage 3: Redesign — sub-tasks, layers, MVP stack
---------------------------------------------
```

For each selected step from `DIAGNOSTIC_RESULT`, launch the `operations-process-redesign` agent (`./agents/operations-process-redesign.md`) one step at a time.

Per step, the agent produces:
- Step title, with its Stage 1 number
- **Sub-task cards** — one per sub-task, numbered under the step (3.1, 3.2…): trigger · layer (Front end / Backend · human / Backend · rules / Backend · AI), Input · Process · Output, Reads and Writes (`none` when the sub-task touches no store), Knowledge (AI sub-tasks), suggested Tool
- Stores touched — each store the cards name, `(new)` or `(exists)`, with the sub-tasks that write and read it
- Flow type (Sequential / Decision Tree / Loop / Human-in-the-loop)
- MVP stack recommendation
- 1–3 sentence summary

After each step, ask:
```
Would you like to redesign the next diagnosed step? (Yes / Skip / Stop)
```

> **Optional Stage 3.5 — streamline the redesigned flow (course Ch5 §5.5.2).** Once Stage 3 has re-chained the steps, run the lean ordering pass on the redesigned flow before building anything: validate I→P→O on every step, map dependencies, eliminate friction (duplicative / looping / missing steps), and re-sequence only where it buys less rework, lower risk, or higher throughput. Invoke `operations-flow-optimization` on the **whole to-be flow** — the Stage 3 sub-task cards plus the steps kept as is (Step 5 item 3), in flow order — so it renumbers one flow (keeping parent numbers) rather than a fragment that would collide with the untouched steps; its spine is the final "ideal flow" for the MVP build. The principle: **eliminate before you automate** — don't build steps a lean pass would have deleted.

---

## Step 5 — Final blueprint

Compile all step redesigns into a single deliverable:
1. Numbered SIPOC map with Systems today (Stage 1) — the as-is
2. Diagnostic table, same step numbers (Stage 2)
3. **The redesigned flow** — every step in flow order as a step card, so each one shows its Input · Process · Output and its layer · Reads · Writes in one place. Do not re-split it into a separate layer table.
   - Redesigned steps: their sub-task cards from Stage 3 — or, if Stage 3.5 ran, the cards of the `operations-flow-optimization` spine, with **its** numbers (the last pass that renumbered wins; carry its `old → new` map).
   - Steps not chosen for redesign: a card marked `kept as is` — Input · Process · Output from Stage 1, `Layer: kept as is (manual today)`, and Reads / Writes taken from its Systems today — so the flow has no gaps and the store directory counts the systems those steps still touch (`references/process-step-card.md` §5).
4. **Store directory** — every store any card names, once: `(new)` / `(exists)`, what it holds, written by · read by (step numbers), join key, and columns for new stores — merged from the agent's "Stores touched" lists (`references/process-step-card.md` §4). A store nothing writes, or nothing reads, is a finding: say so
5. Consolidated MVP stack (deduped across steps)

These step numbers are the ids `workflow-design` puts on the Lucid nodes, so the chart and this blueprint can be read side by side.

Ask:
```
Next steps:
1. Hand off blueprint to engineering team
2. Iterate on a specific step
3. Schedule a build session with <your-company-contact-email>
```

> **`<your-company-contact-email>` is a company fact — read it from Atlas** (`get_knowledge`, key `company.contact-email`, on the `zynkr-atlas` MCP server; the value is the `value:` line). If Atlas cannot be reached, the key is missing, or there is no `value:` line, ask for it; never run with the blank still in it.

---

## Rules

- Stage 1 may ask discovery questions, but Stage 2 and Stage 3 must trust prior agent output — no re-diagnosing
- Always one question at a time during Stage 1
- Diagnostic table classifications are advisory; flag low-ROI steps but do not auto-skip them
- Never recommend LLM-only solutions for rule-based, low-frequency steps (cost mismatch)
- Every step shown carries its number and Input · Process · Output; every redesigned (to-be) step also carries its layer and Reads / Writes, with `none` written out rather than left blank (`references/process-step-card.md`)
- Keep the step numbers stable across all stages; if a step is added, merged or dropped, renumber under the same parent and give the `old → new` map in one line (`references/process-step-card.md` §1)

## House style

Writing style is **not owned by this file**. The house voice lives in two Google Docs under
`[@] 寫作指南` (`12DBdFz3SK22ie9im_ThFMI7IBRXsTZsV`), read at runtime:

- 《[2.0] Zynkr 通用風格指南 House Voice》 `10bOIQwRm9Pxwgct4hlwCwK_B4Pipai1HqBPZKzyRHSE` —
  the universal core, plus the addendum for this surface
- 《[3.2] 禁用詞清單 Forbidden Words》 `1N5sHLP4qzmmhpCGsi6KElxi1z0MFe4QZ0Q_35T10Uyg`

Read both before producing client- or reader-facing text, and scan the draft against 《[3.2]》
before handing it over. If Drive is unreachable, say so in the output rather than proceeding
unchecked. Never re-implement either list inside this file.