Evidence-Based Operating Model Diagnosis Prompt

Produce an evidence-based operating model diagnosis for the following assignment.

Diagnosis inputs
- Diagnosis objective: [Diagnosis objective]
- Operating context and scope: [Operating context and scope]
- Evidence pack: [Evidence pack]
- Constraints and decision rights: [Constraints and decision rights]
- Success measures and time horizon: [Success measures and time horizon]

Input requirements
The minimum inputs are a defined business outcome or problem, the in-scope value stream or organizational boundary, at least one description of the current workflow, and any known authority constraints. Reliable conclusions normally also require process maps or procedures, demand and workload data, service levels, cycle-time or backlog records, quality and rework data, organization charts, role descriptions, decision logs, control requirements, system boundaries, customer feedback, and stakeholder observations.

Treat interview statements and notes as stakeholder evidence, not automatically as verified fact. Use only material actually available in the conversation or attachments. Claude may analyze supplied content and formulate recommendations, but it must not imply access to internal systems, live dashboards, employees, meetings, or records that were not provided.

If the objective, scope, unit of analysis, or available evidence is too ambiguous to support a meaningful diagnosis, ask no more than five consolidated blocking questions before proceeding. If gaps are non-blocking, continue with a bounded preliminary diagnosis, state the limits, and record the missing evidence. Preserve conflicting accounts instead of silently choosing one. Do not invent process steps, measurements, owners, approvals, or causal explanations.

Diagnostic method
1. Define the diagnostic boundary. State the business outcome, customers or beneficiaries, in-scope value streams, start and end events, organizational units, geographies, channels, products, systems, time period, and explicit exclusions. Identify whether the analysis concerns the formal operating model, actual practice, or both.
2. Build an evidence ledger. For every consequential conclusion, identify the supporting source and classify it as supplied fact, direct observation recorded in the materials, stakeholder assertion, calculated result, assumption, hypothesis, conflict, or unknown. Note the source date, scope, reliability limitation, and whether corroboration exists. Never manufacture a baseline from absent data.
3. Reconstruct the current operating model. Map demand triggers, work units, major activities, queues, handoffs, decision points, approvals, controls, exception paths, escalation routes, enabling systems, data dependencies, roles, and accountable owners. Distinguish documented workflow from reported actual practice. Show where work or information crosses team, vendor, system, or jurisdictional boundaries.
4. Analyze flow performance using only available evidence. Examine demand volume and variability, capacity, work in progress, backlog age, throughput, end-to-end lead time, processing time, waiting time, first-pass yield, defects, rework, abandonment, service-level attainment, escalation frequency, and failure demand where relevant. Report the metric definition, period, population, calculation, and limitations. If measurements are unavailable, specify the observation or data collection needed rather than estimating values.
5. Analyze accountability and decision effectiveness. Identify unclear ownership, duplicate accountability, decision-right mismatches, excessive approval layers, unowned exceptions, overloaded roles, separation-of-duties concerns, and gaps between responsibility and authority. Use an appropriate responsibility or decision-right model, such as RACI or RAPID, only when the supplied evidence can support it. Do not infer individual performance or intent from structural evidence.
6. Identify constraints and root-cause hypotheses. Separate symptoms from plausible causes across process design, policy, governance, incentives, skills, capacity, technology, data quality, control design, and external dependencies. For each hypothesis, provide supporting and contradicting evidence, confidence, and the test needed to confirm or reject it. Avoid claiming causation from correlation or isolated stakeholder reports.
7. Prioritize diagnosed issues. Score each issue on outcome impact, frequency, affected volume, control or compliance exposure, customer impact, implementation effort, reversibility, dependency load, and evidence confidence. Explain the scoring basis. Do not use false numerical precision when inputs are qualitative.
8. Design improvement options. For each priority issue, compare at least two credible responses when alternatives exist, including process simplification, policy clarification, decision-right changes, role or capacity changes, control redesign, automation, system integration, or measurement changes. Explain expected benefits, trade-offs, displaced workload, new failure modes, prerequisites, and why an option may be unsuitable.
9. Define the recommended future state. Describe changed workflow steps, handoffs, ownership, decision rights, controls, exception handling, information requirements, system implications, and governance cadence. Identify what remains unchanged. Separate no-regret actions from structural changes requiring executive, functional, legal, compliance, security, finance, HR, works-council, customer, or vendor approval.
10. Build a controlled implementation roadmap. Sequence validation, design, pilot, review, rollout, and stabilization. Assign a proposed accountable owner and required approver by role, not by invented name. Include dependencies, resources, communications, training, migration or cutover needs, operational continuity controls, rollback triggers, and recovery steps. Prefer a reversible pilot where uncertainty or operational impact is material.
11. Define verification and acceptance. For every recommendation, specify the baseline, target, metric owner, data source, measurement frequency, comparison period, expected observation, acceptance threshold, guardrail metric, and decision rule. Include reconciliation checks for workload moved between teams, hidden queues, exceptions, customer outcomes, control performance, and unintended consequences. Mark baselines and targets as unavailable when they were not supplied.

Authority and safeguards
- This is diagnosis and planning, not authorization to reorganize teams, change employment terms, modify production systems, alter controls, commit spending, contact stakeholders, publish findings, or implement recommendations.
- Do not expose unnecessary personal, customer, commercially sensitive, security, or regulated data. Recommend aggregation or redaction when individual-level detail is not essential.
- Do not make legal, regulatory, audit, safety, or employee-performance determinations. Flag those matters for qualified human review.
- Stop and request direction if the requested recommendation would bypass a mandatory control, create an unmanaged service interruption, rely on materially conflicting evidence, expose sensitive data, or exceed stated decision rights.
- Recommendations affecting critical operations must include approval, continuity, monitoring, rollback, and post-change review controls.

Required deliverable
A. Diagnostic scope and confidence
- Objective, business outcome, scope, exclusions, time horizon, units of analysis, constraints, and overall confidence
- Blocking gaps and material limitations

B. Evidence ledger
A table with: evidence ID; source and date; relevant scope; evidence classification; claim supported; corroboration or conflict; reliability limitation.

C. Current-state operating model
- Concise value-stream narrative
- Workflow and handoff table with: stage; trigger/input; activity; output; performing role; accountable role; decision or control; system/data dependency; queue or exception; evidence ID
- Documented-versus-observed differences

D. Performance and flow analysis
A table with: metric or indicator; definition; period and population; baseline; actual observation; data source; interpretation; limitation. State explicitly where no measurement is available.

E. Accountability and decision-right analysis
A table with: decision or outcome; current participants; current accountable owner; authority required; observed delay or ambiguity; control implication; evidence; proposed clarification.

F. Diagnosis register
A table with: issue ID; symptom; root-cause hypothesis; supporting evidence; contradicting evidence; affected outcome; impact and frequency; confidence; validation test; consequence if left unresolved.

G. Options and recommendations
A table with: issue ID; options considered; recommended option; rationale; expected benefit; trade-offs; displaced workload; dependencies; new risks; proposed owner; required approval.

H. Future-state design
Describe the revised flow, handoffs, decision rights, controls, exception routes, governance, systems, data, and capabilities. Clearly label assumptions and unresolved design choices.

I. Implementation and control roadmap
A table with: phase; action; deliverable; proposed owner; approver; dependency; pilot or rollout boundary; continuity safeguard; rollback trigger; completion evidence; status as proposed, blocked, or ready for human decision.

J. Measurement and acceptance plan
A table with: recommendation; baseline; target; metric definition; data source; metric owner; frequency; expected observation; actual observation if supplied; guardrail; acceptance rule; unresolved state.

K. Decision brief
List decisions required now, decisions deferred pending evidence, the smallest safe next action, and the evidence or approval needed to take it.

Claim discipline
Keep proposed, approved, executed, measured, verified, blocked, and unavailable states distinct. Do not say a workflow was changed, a stakeholder agreed, a control passed, a metric improved, or a recommendation was implemented unless the supplied material contains direct evidence of that event. If no execution evidence is available, present all changes and expected results as proposals.