When to use
- Internal users, field teams, branches, or departments need a shared way of working.
- Approvals, ownership, exceptions, or offline work shape the experience.
When not to use
- The request is a small bounded change with no process uncertainty.
- The main unknown is system integration or data lineage.
Start with
- Map the current process, roles, handoffs, pain points, and exception paths.
- Define the future-state workflow with owners, approvals, controls, and support needs.
- Validate the workflow with representative users before fixing scope.
Choose the operational shape.
Workflow redesign
The team needs to improve a recurring internal process, approval flow, exception path, or role handoff.
Current and future process mapRole ownershipException handlingAdoption impact
Program or field rollout
The solution must work across branches, field teams, departments, or repeated operating locations.
Field realityTraining and supportRollout sequencingFeedback loop
Operating model change
The work changes accountability, governance, reporting, performance expectations, or cross-team coordination.
Decision rightsGovernanceService ownershipChange management
Work through the transformation one step at a time.
Frame the transformation mandate
Translate the enterprise request into a governed problem statement, validate the real current state, and confirm non-negotiable constraints before future-state design.
O.1Playbook stepEnterprise Intake and Strategic Framing
Turn a broad enterprise request into a clear boundary, a C-suite outcome, and a shared problem statement.
Key output: C-suite business problem validated.
Enterprise Intake and Strategic Framing
Turn a broad enterprise request into a clear boundary, a C-suite outcome, and a shared problem statement.
Key output: C-suite business problem validated.
O.2Playbook stepCurrent-State Landscape and Shadow IT Discovery
Understand the fragmented reality of how departments, branches, and field teams actually operate today.
Key output: Current-state process maps validated by both HQ and field teams.
Current-State Landscape and Shadow IT Discovery
Understand the fragmented reality of how departments, branches, and field teams actually operate today.
Key output: Current-state process maps validated by both HQ and field teams.
O.3Playbook stepExternal Validation, Policy, and Compliance Assessment
Confirm the initiative fits internal policy, external regulation, and enterprise-architecture standards before future-state design continues.
Key output: Policy and compliance register completed.
External Validation, Policy, and Compliance Assessment
Confirm the initiative fits internal policy, external regulation, and enterprise-architecture standards before future-state design continues.
Key output: Policy and compliance register completed.
Define the enterprise operating model
Standardize capabilities, data ownership, governance, and dependency logic before locking delivery structure or architecture choices.
O.4Playbook stepEnterprise Capability and Outcome Mapping
Map the enterprise capabilities that matter and define the master-data domains they depend on.
Key output: Enterprise capability gaps identified.
Enterprise Capability and Outcome Mapping
Map the enterprise capabilities that matter and define the master-data domains they depend on.
Key output: Enterprise capability gaps identified.
O.5Playbook stepStakeholder, Governance, and Operating Model Discovery
Define who governs the transformation, how decisions are made, and what can be configured globally or locally after launch.
Key output: Steering Committee and Design Authority established.
Stakeholder, Governance, and Operating Model Discovery
Define who governs the transformation, how decisions are made, and what can be configured globally or locally after launch.
Key output: Steering Committee and Design Authority established.
O.6Playbook stepInitiative Decomposition and Legacy Dependency Discovery
Break the transformation into manageable workstreams and map the legacy cutover constraints that will shape delivery.
Key output: Workstreams defined across data, process, technology, and change management.
Initiative Decomposition and Legacy Dependency Discovery
Break the transformation into manageable workstreams and map the legacy cutover constraints that will shape delivery.
Key output: Workstreams defined across data, process, technology, and change management.
Prepare rollout and executive approval
Turn the future-state design into a governed operating model, a phased rollout, and a decision-ready leadership package.
O.7Playbook stepFuture-State Design and Target Operating Model
Design the standardized enterprise workflows and the organizational change strategy that will make them stick.
Key output: Standardized future-state processes validated by the Design Authority.
Future-State Design and Target Operating Model
Design the standardized enterprise workflows and the organizational change strategy that will make them stick.
Key output: Standardized future-state processes validated by the Design Authority.
O.8Playbook stepRoadmap, Phasing, and Executive Recommendation
Turn the discovery into a phased roadmap and the executive decision package needed for funding and launch approval.
Key output: Phased enterprise roadmap completed.
Roadmap, Phasing, and Executive Recommendation
Turn the discovery into a phased roadmap and the executive decision package needed for funding and launch approval.
Key output: Phased enterprise roadmap completed.
Use this route for governed internal transformation.
Operational Discovery is the route for enterprise-scale internal transformation. Work through O.1 to O.8 in order before future-state solution design hardens.
Who uses it
Senior BAs, Enterprise Architects, Program Leads, Operations leaders, and C-suite sponsors working on organization-wide change.
When to use
When the initiative crosses department lines, changes the operating model, replaces core legacy systems, or requires enterprise-wide policy alignment.
What it produces
Capability maps, master-data ownership, governance models, policy alignment, future-state TOM, phased rollout plans, and executive decision packages.
How to use
Follow the steps in order. Do not skip policy, governance, master-data, or target-operating-model work before solution design.
How this playbook should be used
Do not skip steps. Do not jump into future-state software design before the enterprise capability, policy, and master-data work is complete. Move forward only when the step outputs are validated by the right sponsor, business owner, or governance body.
At a glance
Operational Discovery combines field reality with enterprise governance. It is the route for massive internal transformation where both day-to-day workflows and enterprise controls must be understood together.
Playbook outcomes
By the end of O.8, the team should have a decision-ready executive recommendation pack that can support funding, phase approval, policy enforcement, and transformation launch.
The final outcome is a leadership-ready Target Operating Model, a clear master-data architecture, and a phased rollout plan that can navigate legacy sunset, policy control, and organizational change together.
People, artifacts, escalation
Minimum participants
Product or BA ownerProcess ownerOperationsRepresentative usersSupport or training owner
Minimum artifacts
- Current-state process map
- Future-state workflow
- Role and responsibility matrix
- Exception and approval rules
- Rollout notes
Escalate if
- The process depends on multiple systems or reconciliation.
- External users, public trust, or financial transactions are affected.
- The same solution must become reusable across many teams or clients.
Check the evidence before moving forward.
What decision will this discovery evidence support?
What user, process, data, system, or model evidence would change the decision?
Which risk remains unresolved, and who accepts it if the team proceeds?
What artifact proves the team is ready for build, pilot, rollout, or scale?
Continuous Discovery
Cadence
- Weekly or biweekly signal review for live behavior, support issues, and adoption friction.
- Monthly user or stakeholder touchpoints for deeper problem discovery.
- Quarterly roadmap and outcome review using evidence, not only delivery volume.
Activities
- Track behavior, funnel, support, operational, and trust signals after launch.
- Keep a discovery backlog of assumptions, unresolved risks, and improvement hypotheses.
- Run lightweight interviews, usability checks, experiment reviews, or data validation as new evidence appears.
- Feed validated learning into roadmap, backlog, support readiness, and deprecation decisions.
Outputs
Discovery backlogLearning logExperiment or validation planOutcome dashboardRoadmap recommendation