--- 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 ``` > **`` 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.