Where should your organization use AI?

Who should be involved in AI opportunity discovery?

Discovery needs people who can describe the actual work and people who can challenge the proposed change. A sponsor sets the outcome, but should not substitute their assumptions for frontline evidence. Keep the group small enough to act while bringing specialists into the decisions they own.

• Process owner and practitioners

  The owner defines boundaries and accountability. Practitioners explain workarounds, exceptions, handoffs, and what happens outside the systems of record. Include downstream recipients of the output.

• Technology, data, and delivery

  Architecture and delivery teams check access, integrations, data quality, operational support, and dependencies. A demonstration does not establish production feasibility.

• Finance, risk, and the sponsor

  Finance challenges assumptions and distinguishes capacity released from cash savings. Security, legal, and compliance review exposure. The sponsor decides whether the evidence justifies investment.

Four questions turn an idea into an investable opportunity

• Find: What work needs to change?

  Look for a repeated problem linked to a measurable objective, not a broad aspiration such as 'AI for operations.' The discovery output is a problem record with an owner, boundary, baseline, and evidence gaps.

• Evaluate: What intervention is justified?

  Validate the current process, choose a plausible intervention, and test its weakest assumption. The output is an assessment that explains value, technical feasibility, risks, and alternatives, including doing nothing.

• Prioritize: What deserves attention next?

  Compare evidence on a common basis, identify prerequisites and resource conflicts, and select the next commitment. The output is a reasoned sequence, not a promise that every ranked idea will be funded.

• Portfolio: How will the organization keep learning?

  Track discovery, assessment, experiments, delivery, and realized outcomes as distinct states. Maintain a single opportunity identity so a benefit is not counted again when multiple departments describe the same process.

AI is one possible intervention, not the starting assumption

Use AI when the task genuinely requires interpretation, prediction, or generation and its errors can be evaluated and controlled. Use deterministic automation when rules and data are stable. Use process redesign when the waste comes from unnecessary steps, conflicting ownership, or a policy that technology cannot fix. Retain the current process when expected improvement does not justify cost or exposure.

• Illustrative comparison: a delayed approval

  If requests wait because no one owns the queue, assign ownership first. If routing rules are clear, workflow automation may be sufficient. If requests contain varied documents, IDP may help extract fields. AI might assist interpretation of ambiguous text, but a human may still need to make the approval. This is a hypothetical comparison, not a customer result.

• Keep the problem stable while comparing solutions

  Write the desired outcome independently of the tool: 'reduce time spent resolving incomplete requests without increasing incorrect approvals.' Compare candidate interventions against that same outcome and the same baseline.

What belongs in an opportunity record?

Record the objective, department, process boundary, owner, affected people, current problem, and proposed outcome. Attach representative evidence: process observations, operational records, example inputs, and a description of exceptions. Separate measured facts, estimates, assumptions, and unknowns so reviewers can see what would change the recommendation.

• Value and acceptance

  Record volume, handling effort, waiting time, rework, and the quality or service target that matters. Explain whether benefits are capacity, cost, revenue, or risk reduction. Define how the result will be measured before building.

• Feasibility and control

  Record systems, permissions, data availability, integration dependencies, review requirements, and recovery paths. Name the assumption that would invalidate the opportunity and the smallest useful test.

• Decision and follow-through

  Keep the rubric version, rationale, decision owner, next action, investment stage, and review date. Link related opportunities so shared dependencies and overlapping benefits are visible.

How does discovery scale beyond workshops and spreadsheets?

A workshop can surface a starting set of problems; it cannot keep an enterprise pipeline current by itself. Use a standing intake channel, a common interview structure, and a shared evidence record. Assign a reviewer to turn each submission into a bounded problem or return it with a specific missing question.

Review new submissions regularly, revisit assessments when systems or assumptions change, and compare delivered outcomes with the original baseline. Feed failures and successful interventions back into future interviews. A spreadsheet may be enough for a small pilot; move to shared structured records when ownership, versioning, duplicate detection, and review history become difficult to maintain.

Do not measure discovery success by the number of AI ideas collected. Track whether candidates have owners and evidence, whether decisions resolve uncertainty, and whether implemented changes improve the intended outcome. A decision not to automate can be a valid result.

Common discovery mistakes

• Starting with a tool demonstration

  A convincing demo can bias the problem definition. Interview practitioners and establish the baseline before evaluating a vendor or model.

• Treating a score as investment approval

  A score standardizes comparison; it does not establish budget, accountability, or risk acceptance. Record those decisions explicitly.

• Ignoring delivery and adoption

  Include training, exception handling, integration, monitoring, and support in the assessment. A technically possible solution can still be operationally unsuitable.