Diagnose and Redesign a Business Process

{"category":"operations","description":"Use when a consultant or operations owner must improve one bounded workflow suffering from long lead time, rework, excessive handoffs, or quality problems. Move from measured current state to a feasible redesigned process and test plan. Do not use for broad organization transformation or process documentation without an improvement objective.","inputSchema":{"additionalProperties":false,"properties":{"constraints":{"description":"Regulatory, staffing, tooling, service, or change-management limits.","items":{"type":"string"},"type":"array"},"improvementObjective":{"description":"Outcome to improve, e.g. cycle time, quality, cost or throughput.","minLength":1,"type":"string"},"processEvidence":{"description":"Process samples, timestamps, SOPs, interviews, cases, and systems available.","items":{"type":"string"},"type":"array"},"processName":{"description":"The specific process and its start/end boundary.","minLength":1,"type":"string"}},"required":["processName","improvementObjective"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Process boundary, user/job, KPI definitions and sample plan.","kind":"process-scope"}],"id":"O70Y","instructions":"Identify customer/user, trigger, start and end events, throughput volume, variants, actors and governing constraints. Select a representative transaction or case type rather than mapping every process simultaneously. Establish existing business metric definitions and source reliability. Speak to frontline doers and accountable owners when available, capturing hidden workarounds and exceptions. Gate: an independent observer can tell which cases belong in the study and what improved performance would mean.\n\nV2 practical protocol:\nMeasurement plan: define unique case ID, start/end events, working calendar, population/cohort, observation period, variant and exclusions. A cycle time is elapsed time per case from first event to completed event; report distribution and sample size instead of relying only on a mean. Touch time is active work time and Waiting time = cycle time − touch time only when measurements cover the same cases and time basis. Rework rate = cases returned/repeated ÷ eligible cases, clearly defining whether multiple loops on one case count once or repeatedly. Baseline outcomes should include quality or error guardrails so speed does not silently sacrifice service.","resourceHints":[],"title":"Bound the process and confirm the unit of analysis"},{"expectedOutputs":[{"description":"As-Is process, stage owners, waiting and rework inventory.","kind":"current-state-map"}],"id":"M1L7","instructions":"Reconstruct the actual stages, owners, systems, queues, decisions, rework loops and handoff delays using documents, samples and interviews. Capture at least approximate processing and waiting time by stage, clearly labeled measured or estimated. If process-mapper is installed and its input format fits available data, use its mapping and cycle-time tools; otherwise produce a simple swimlane and table yourself. Validate with a frontline participant and document exceptions. Gate: the map agrees with observed work and distinguishes touch time from elapsed time.\n\nV2 practical protocol:\nMapping standard: draw steps as actor × activity × system × input/output × decision × queue, and annotate observed processing time, waiting time, rework loops and exceptions for each relevant stage. Check at least one completed fast case and one slow case against the map. If using process-mapper, provide sanitized suitable data and verify diagrams against raw transactions; its outputs are aids, not ground truth. For insufficient timestamps, use estimates labeled as such and design a lightweight data-capture plan rather than pretending precise cycle times. Gate evidence should include validation by actual process participants.","resourceHints":[{"kind":"skill","ref":"github:alirezarezvani/claude-skills","selector":"business-operations/skills/process-mapper"}],"title":"Build an evidence-grounded current-state map"},{"expectedOutputs":[{"description":"Ranked bottleneck hypotheses, uncertainty and potential effect sizes.","kind":"constraint-analysis"}],"id":"MAIJ","instructions":"Analyze stage distribution, cycle-time percentiles where data permits, work-in-progress, rework rate, capacity mismatch and error/exception types. Avoid adding stage P90 values as though they were necessarily an observed end-to-end P90; note any approximations. Rank candidate constraints by impact on throughput or quality, and test against cases that moved quickly. For scarce data, use a structured hypothesis and specify which timestamps to collect next. Gate: the proposed bottleneck has evidence and an alternative explanation has been considered.\n\nV2 practical protocol:\nDiagnostic calculation: cycle-time median, p75/p90 and share of cases breaching the desired service level when sample size supports it; calculate percentiles from end-to-end case durations, never by summing stage percentiles. Examine stage-level queue aging and work-in-progress, arrival rate versus completion rate, error/rework and segment mix. Little's Law (WIP ≈ throughput × lead time) is a sanity check only for approximately stable systems with consistent units, not a substitute for observation. Identify the constraint that materially affects customer throughput; test whether delays arise upstream from input quality rather than blaming the longest visible queue.","resourceHints":[],"title":"Quantify the binding constraint and failure modes"},{"expectedOutputs":[{"description":"To-Be alternatives, rationale, risks and estimated impact.","kind":"future-state-options"}],"id":"1KSL","instructions":"Generate at least two options such as eliminating approvals, clarifying decision rights, reducing batches, automating repetitive checks or improving input quality. Show changed process flow, ownership, exceptions, required system changes, compliance consequences and potential new failure modes. Estimate effect and cost with transparent assumptions, identifying trade-offs and local optimizations that do not relieve the overall constraint. Gate: options can be compared on value, feasibility, risk and adoption burden.\n\nV2 practical protocol:\nTo-Be comparison table: changed steps and approvals, actor/ownership changes, required data and permission, automation or policy changes, expected effect on cycle time/quality, implementation effort, recurring costs, exception handling and risk. Compare at least status quo, a no-code/process-only intervention and a tool-supported intervention when relevant. Estimate time released from affected case volume × reasonable reduction per case with adoption and realization adjustments; do not promise cash savings without cost reduction. Challenge whether the change moves the queue downstream or creates hidden risk.","resourceHints":[],"title":"Design feasible alternative workflows"},{"expectedOutputs":[{"description":"Future-state process, intervention ranking and measurable pilot plan.","kind":"redesign-proposal"}],"id":"1NYL","instructions":"Prioritize a reversible intervention against the constraint and specify a pilot cohort, baseline, duration, owners, leading indicators, quality guardrails and explicit rollback/stop rules. Review design with process owner and affected staff; document actual approval status. Do not claim cycle-time improvements until measured after change. Deliver the validated future-state process and testable rollout recommendation, with no mandatory generic handoff ritual. Gate: the business owner can approve a bounded pilot or request targeted additional evidence.\n\nV2 practical protocol:\nPilot specification: choose a representative cohort and observation window, predefine baseline, expected improvement threshold, error/quality guardrails and rollback criteria. Track implementation owner, approval requirements, training burden, systems change and a before/after measurement plan using matched process definitions. Decide Scale / Iterate / Stop based on observed impact and its limitations, not a workshop consensus alone. Deliver a concise To-Be map plus an executable pilot, not a mandatory generic handoff package.","resourceHints":[],"title":"Choose a pilot and an operating change"}],"title":"Diagnose and Redesign a Business Process"}