12.2 — Business Process Understanding and AI Feasibility Assessment

1. What is it?

This chapter covers two closely related skills: business process understanding — mapping how a customer's actual workflow operates today, in enough detail to know exactly where and how AI could fit — and feasibility assessment — honestly evaluating whether AI is actually capable of doing what's being proposed, at an acceptable accuracy/cost/risk level, before committing to build it.

2. Why does it exist?

Part 12.1 taught discovering what problem a customer wants solved. This chapter exists because knowing the problem isn't the same as knowing whether AI can actually solve it well, or exactly where in an existing business process it should be inserted. A common, costly failure mode in real AI engagements is technically successful software that doesn't actually fit how work really happens, or that attempts something current AI capability genuinely can't do reliably — both failures that a rigorous process-mapping and feasibility assessment step prevents before any code is written.

3. What problem does it solve?

Business process understanding solves "where, precisely, in this customer's actual workflow does an AI intervention belong, and what does it need to hand off to and receive from the humans and systems around it." Feasibility assessment solves "is what's being proposed actually achievable with current AI capability at an acceptable reliability, or are we setting up a project to fail against an unrealistic expectation."

4. How does it work internally?

Process mapping — making the implicit workflow explicit

Most business processes exist as tacit knowledge in employees' heads, not as a written specification — the actual discovery work is surfacing this into something concrete enough to design against:

CUSTOMER (initial description): "Our underwriters review loan applications
and approve or deny them."

FDE probing questions:
  "Walk me through what an underwriter actually looks at, in order,
   for a typical application."
  "What information sources do they check — is it all in one system,
   or do they cross-reference several?"
  "What makes an application 'complicated' versus 'routine' in practice —
   what specifically triggers deeper scrutiny?"
  "When they're unsure, what do they do — escalate to whom, based on what?"
  "How long does a typical review take, and where does most of that
   time actually go?"

Mapped process (the artifact this produces):
  1. Pull application + credit report (2 systems, ~5 min)
  2. Check against 12-point underwriting checklist (mostly routine, ~10 min)
  3. IF any checklist item is borderline → escalate to senior underwriter
     (roughly 15% of applications, adds 1-2 days)
  4. Document decision with justification (required for audit, ~5 min)

This mapped process — not the customer's one-sentence original description — is what actually reveals where AI fits: perhaps steps 1 and 2 (data-gathering and routine-checklist evaluation) are strong automation candidates (Part 3.2/3.3's structured extraction and tool-calling), while step 3's escalation judgment is exactly the kind of nuanced, accountability-bearing decision that should remain human-driven, with AI providing supporting information rather than a decision (Part 5.4/9.2's calibrated human-in-the-loop, chosen here based on actual process understanding, not a generic caution).

Feasibility assessment — honestly evaluating what's achievable

Feasibility isn't a single yes/no — it's a spectrum, evaluated against specific criteria this book has built throughout:

Feasibility checklist:
  - Does this require precise, exact-match correctness (feasibility: use
    tool-calling/SQL, Part 3.3/1.4, not open-ended generation) or does it
    tolerate the natural variability of generated output?
  - Is there enough existing data/documentation to ground the system
    (Part 3.5), or would this require building a knowledge base from
    scratch first (a much larger, distinct project, Part 10.2)?
  - Does current model capability actually perform this task reliably
    (verified via a quick prototype/evaluation, Part 13, not assumed)?
  - What's the cost of an error, and does achievable accuracy meet that
    bar (Part 8.1's evaluation discipline, applied prospectively here)?
  - Is the actual bottleneck even AI capability, or is it a data/process/
    organizational problem that AI wouldn't fix regardless of how well
    it's built (Part 10.2's frequent real root cause)?

The last question is the one most often skipped, and it's frequently the most important: many "AI projects" fail because the actual underlying problem was disorganized data or an unclear business process (Part 10.2/12.1) — and no amount of AI sophistication fixes a problem that was never actually about intelligence in the first place.

5. Simple mental model

Business process mapping is like watching a skilled craftsperson work before redesigning their workshop — you don't redesign a process you don't understand in enough concrete detail, because the parts that look inefficient or automatable from the outside are often exactly the parts where real judgment, exception-handling, or accountability matters most, and the parts that look simple are sometimes hiding complexity a quick glance misses. Feasibility assessment is like a structural engineer evaluating whether a specific design is buildable with available materials and methods before an architect's exciting concept sketch becomes a construction commitment — enthusiasm for an idea and its actual technical achievability are two different, both-necessary things to evaluate honestly.

6. Real-world example

A customer wanted AI to "automatically categorize and prioritize all incoming customer emails" — on the surface, a clean classification task (Part 3.1/3.7's routing pattern) with clear feasibility. Deeper process mapping (section 4) revealed that "priority" in practice depended heavily on tacit knowledge about specific ongoing customer relationships and unwritten business context ("this customer's CEO just complained on social media last week, so anything from their domain is now high-priority regardless of content") that existed nowhere in any system the AI could access — a feasibility-limiting discovery that fundamentally changed the recommended approach: rather than fully automating prioritization (infeasible given this hidden context dependency), the system was redesigned to handle the objectively-classifiable majority of routine emails automatically while surfacing a small, genuinely ambiguous subset to a human with the AI's classification as a suggestion, not a final decision — directly informed by understanding the actual process, not the customer's initial, simplified description of it.

7. Architecture diagram

This chapter's "diagram" is the process-mapping artifact itself (section 4's mapped-process example) — it precedes and directly determines where any subsequent technical architecture (Part 11's system designs) actually inserts into the customer's real workflow.

8. Production considerations

• Map the actual process in concrete, step-by-step detail before designing anything — a customer's summary description ("underwriters review applications") is never detailed enough to design against directly.
• Explicitly evaluate whether the actual bottleneck is AI capability or something else (data quality, process clarity, organizational context, section 4's last checklist item) — this single question prevents a large fraction of doomed-from-the-start AI projects.
• Validate feasibility with a quick, cheap check before committing to a full build (Part 13's rapid-prototyping chapter builds directly on this) — a prototype answering "can the model actually do this reliably" is far cheaper than discovering the answer is no after a full production build.
• Identify tacit-knowledge dependencies explicitly (section 6) — information that exists only in employees' heads is a real, common feasibility limiter that a surface-level process description won't reveal.

9. Common mistakes

• Designing against a customer's simplified summary of their process instead of the actual, detailed, step-by-step reality — missing exactly the nuances (an escalation trigger, a tacit-knowledge dependency) that determine where AI genuinely fits.
• Assuming feasibility rather than testing it — committing to a full build before a cheap prototype has verified the model can actually perform the task reliably enough.
• Treating every part of a mapped process as equally automatable, rather than identifying which specific steps carry accountability/judgment requirements warranting human ownership (Part 5.4/9.2).
• Not asking whether the real bottleneck is even AI-capability-related, missing an underlying data/process problem that no amount of AI sophistication would fix.

10. Security considerations

Process mapping often surfaces where sensitive decisions and data actually flow (section 6's example touches customer-relationship-sensitive context) — feeding directly into Part 9.6/10.4/10.5's access-control and compliance design, grounded in the actual process rather than a generic assumption.

11. Performance considerations

Understanding where most of a process's actual time goes (section 4's mapped-process timing) reveals where AI intervention would produce the largest measurable time savings — directly informing Part 15's ROI calculation with concrete, process-grounded numbers rather than a vague productivity claim.

12. Cost considerations

Feasibility assessment should include a rough cost estimate (Part 7.10/3.11) against the realistically-achievable automation scope — a project's viability depends on whether the achievable automation's value (Part 15) exceeds its build and operating cost, not just on technical feasibility alone.

13. When to use it

Before committing to build any AI system intended to integrate into an existing business process — essentially every real enterprise engagement, since standalone, process-independent AI tools (a general research assistant with no specific workflow integration) are comparatively rare in enterprise FDE work.

14. When NOT to over-apply it

A well-understood, previously-mapped process being extended incrementally doesn't need the full mapping exercise repeated from scratch — proportional rigor (Part 3.12) applies here as everywhere else in this book.

15. Alternatives and trade-offs

The "alternative" to rigorous process mapping and feasibility assessment is building against assumptions and discovering gaps during or after deployment — section 6 shows the real cost of skipping this: a redesign after the fact, versus the comparatively small upfront cost of getting the process and feasibility understanding right first.

16. Practical Python/code example

A process-mapping and feasibility-assessment template, extending Part 12.1's discovery-findings structure with process and feasibility specifics:

from dataclasses import dataclass, field


@dataclass
class ProcessStep:
    """One step in a mapped business process, with its automation feasibility assessed."""
    description: str
    typical_duration: str
    requires_tacit_knowledge: bool
    requires_accountability_judgment: bool
    automation_feasibility: str  # "high", "partial", "not_recommended"


@dataclass
class FeasibilityAssessment:
    """A structured feasibility assessment for a proposed AI intervention."""
    process_steps: list[ProcessStep] = field(default_factory=list)
    actual_bottleneck: str = ""  # "ai_capability", "data_quality", "process_clarity", "organizational"

    def recommended_automation_steps(self) -> list[ProcessStep]:
        """Returns only the steps genuinely suited to automation, given this assessment."""
        return [
            step for step in self.process_steps
            if step.automation_feasibility == "high"
            and not step.requires_tacit_knowledge
            and not step.requires_accountability_judgment
        ]

17. Production-quality example

A quick feasibility-validation script — a minimal, cheap prototype check (Part 13) run before committing to a full build, directly implementing section 8's "validate before building" recommendation:

import logging

logger = logging.getLogger("feasibility_check")


async def run_feasibility_probe(client, task_description: str, sample_cases: list[dict], accuracy_threshold: float = 0.8) -> dict:
    """
    Runs a quick, cheap probe against a small sample of real cases to validate
    feasibility before committing to a full build.

    Args:
        client: An async LLM client.
        task_description (str): What the AI is being asked to do.
        sample_cases (list[dict]): A small set of real, representative cases with
            known correct outcomes, gathered during process mapping.
        accuracy_threshold (float): Minimum accuracy to consider this feasible
            enough to proceed to a full build.

    Returns:
        dict: {"feasible": bool, "accuracy": float, "failures": list[dict]}
    """
    correct = 0
    failures = []
    for case in sample_cases:
        response = await client.messages.create(
            model="claude-sonnet-4-5", max_tokens=200,
            system=task_description,
            messages=[{"role": "user", "content": case["input"]}],
        )
        result = response.content[0].text.strip()
        if result == case["expected_output"]:
            correct += 1
        else:
            failures.append({"input": case["input"], "expected": case["expected_output"], "got": result})

    accuracy = correct / len(sample_cases)
    logger.info("feasibility probe: accuracy=%.2f (threshold=%.2f)", accuracy, accuracy_threshold)
    return {"feasible": accuracy >= accuracy_threshold, "accuracy": accuracy, "failures": failures}

18. Short exercise

A customer wants AI to "review legal contracts and flag risky clauses." Using this chapter's process-mapping approach, write three specific questions you'd ask a legal reviewer about how they actually do this today, and identify which parts of their answer would most likely reveal a tacit-knowledge dependency limiting full automation feasibility.

19. Interview questions

• Explain why mapping a customer's actual process in concrete detail matters more than their summary description of it, with a concrete example of what detail-level mapping reveals that a summary misses.
• What's the difference between assuming feasibility and validating it, and why does this distinction matter for project risk?
• Describe a real or hypothetical AI project failure that traces back to the actual bottleneck being a data/process problem rather than AI capability.

20. FDE/customer scenario

CUSTOMER: "We're confident AI can fully automate our loan approval process end-to-end."

The FDE-correct response doesn't simply agree or disagree — it proposes mapping the actual process together first (section 4), specifically probing for tacit-knowledge dependencies and accountability-bearing judgment steps (section 6's exact discovery pattern), and running a quick feasibility probe (section 17) on a sample of real cases before committing to full automation as the goal — very often revealing, as in section 6's example, that the right design is automating the objectively-decidable majority while keeping genuinely judgment-dependent cases with a human, rather than either extreme (full automation or no automation at all).

---

Key takeaways

• Business process mapping in concrete, step-by-step detail — not a customer's summary description — is what reveals where AI genuinely fits and where tacit knowledge or accountability requirements mean it shouldn't.
• Feasibility should be validated with a cheap, quick probe against real cases before committing to a full build, not assumed based on how the task sounds in the abstract.
• Many "AI projects" fail because the actual bottleneck was a data or process problem, not AI capability — this question should be asked explicitly, every time.

Things you should be able to explain

• Why a customer's summary description of their process is insufficient for design, and what detailed mapping reveals that it misses.
• How to distinguish assumed feasibility from validated feasibility.

Things you should be able to build

• A process-mapping and feasibility-assessment template, and a quick feasibility-probe script validating task performance against real sample cases.

Common mistakes

• Designing against a simplified process summary instead of detailed, mapped reality.
• Assuming feasibility instead of validating it with a cheap prototype check.
• Not asking whether the real bottleneck is even AI-capability-related.

Recommended next chapter

03-solution-architecture-communication.md