The process map is usually fiction

A process document says: "When the invoice arrives by email, capture the details in the ERP and pay on the due date."

The person doing the work knows what that sentence hides. Invoices arrive from dozens of senders in different formats. The useful information may be in the email body, a PDF, a phone photo or a forwarded thread. Some attachments are duplicates and some are old versions. A trusted supplier is handled differently from an unknown one. One customer needs a special approval. The spreadsheet that tracks it all has stale tabs. The core system is unavailable at month end. And a senior employee recognises exceptions from experience that nobody else has.

An AI solution built from the formal process will work in the demonstration and fail in daily operations. That is not a model problem. It is a discovery problem, and it is the first thing a forward deployed team has to get right.

What the document left out

Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative.

Part 1 introduced Sandveld Foods, the Paarl fruit and vegetable processor whose first AI invoice product never got past the demo, and Ironbark Digital, the software company whose forward deployed pod took on the problem second time round.

Sandveld's accounts payable procedure was three steps long. The pod's forward deployed lead and its engineer spent most of the first two weeks sitting with the clerks rather than in meeting rooms, with the AP manager's agreement and the clerks' consent. They watched invoices being handled, asked clerks to talk through what they were doing and why, and pulled six weeks of invoice data from the ERP and the shared mailbox.

What they found:

• About 30% of invoices arrived as phone photos, mostly from small growers, some forwarded on WhatsApp by Sandveld's own buyers. The procedure assumed email.
• Experienced clerks accepted price variances of up to 2% on fresh-produce lines. A grower invoices the weight it loaded; the plant records the weight it received; the two rarely match exactly. The rule was applied hundreds of times a month, by judgement, and was written nowhere.
• The ERP locked posting for the last two working days of each month. Clerks quietly held invoices and posted them in a rush afterwards.
• Plant managers approved some exceptions informally on WhatsApp. The approval was real; the evidence lived on a phone.
• One senior clerk recognised "duplicates by another route": the same invoice sent once as a PDF and again as a photo, often with the invoice number written differently. Nobody else reliably caught them.

None of this was in the process map. All of it would have broken an AI system built from the process map.

Discovery must observe work

Interviews are necessary, but people compress complex work when they explain it. They describe the normal path, forget the rare exceptions, and leave out decisions that feel too obvious to mention. The senior clerk at Sandveld did not mention duplicates in their interview. They mentioned them while handling one.

Use several kinds of evidence, because each has a blind spot:

Shadowing needs particular care. Invoices carry supplier banking details and personal information about sole-trader growers. Sandveld is the responsible party for that information under POPIA, and Ironbark, processing it during discovery, is an operator acting on Sandveld's behalf. That relationship needs a written agreement before anyone looks at real invoices, not after.

The aim is not a beautiful process diagram. It is an operating map accurate enough to design and evaluate the new system.

The operating map

For each step, record:

• the trigger and entry criteria;
• the person or system doing the work;
• inputs and their formats;
• the decision or judgement involved;
• the business rule or policy behind it;
• systems read and updated;
• data classification and permissions;
• the normal output;
• known exceptions;
• escalation and approval;
• volume, frequency and peak periods;
• time spent, waiting time and rework;
• the consequence of delay or error;
• the evidence retained today.

The shape that matters most is simple: a trigger, variable inputs, a decision, a normal action and a human resolution path, both of which end in the system of record. Most automation projects design the normal action in detail and leave the human resolution path as a box labelled "exception".

Ask for stories, not only requirements

Questions that surface reality:

1. Show me the last three cases you completed.
2. Show me one that went wrong.
3. What makes you stop and ask someone else?
4. Which fields do you not trust?
5. What do experienced people know that a new starter does not?
6. Which step takes little effort but creates a long wait?
7. What do you copy, download, rename or re-enter?
8. Which approval is formal and which is informal?
9. What changes at month end, during an outage, or for an important client?
10. What evidence do auditors, managers or customers ask for later?

"Show me" beats "tell me", because it anchors the answer in a real case. Question 8 is how the WhatsApp approvals surfaced at Sandveld. Question 5 is how the weight tolerance did.

Capture variants before designing automation

The six-week sample covered about 13,000 invoices. Splitting it by variant changed the design conversation.

A prototype designed around the 78% would still create value. The operating design has to decide what happens to the other 22%, and the smallest rows carry the most risk: a missed duplicate is a double payment, and a fraudulent bank-detail change is a payment to a criminal.

The exact percentages must come from evidence. Where no data exists, label the estimate as an estimate and use discovery to improve it. Sandveld's numbers came from its own systems, and the clerks recognised them, which mattered as much as the numbers did.

Find the workflow worth changing

High volume alone is not enough. Assess a candidate workflow across:

• business value;
• user pain and time lost;
• quality or risk exposure;
• data readiness;
• technical feasibility;
• process stability;
• appetite for change;
• ability to measure the outcome;
• reuse across teams or clients.

A low-volume, high-risk approval may deserve support before a high-volume task with little value. A workflow that changes every week may need stabilising before AI goes anywhere near it. Accounts payable exceptions scored well at Sandveld on value, pain, data readiness and measurability, and the pod could see that the work was stable enough to automate once the unwritten rules were written.

The discovery canvas

The pod kept one living document through discovery. A version of it:

business:
  outcome: "Fewer AP exceptions handled by hand; no duplicate payments"
  owner: "AP manager"
  users: [ap_clerks, plant_managers, buyers]
  baseline: { invoices_per_month: 9000, exception_rate: "about 1 in 5" }
  value_hypothesis: "Clerk time moves from re-keying to real exceptions"

workflow:
  trigger: "Invoice received by mailbox, photo or WhatsApp"
  normal_path: [extract, three_way_match, post]
  exceptions: [weight_variance, missing_grn, price_variance, duplicate, supplier_change]
  decisions: [accept_variance, request_grn, approve_exception]
  human_accountability: [payment_release, supplier_change_verification]

technology:
  systems_of_record: [erp]
  integrations: [erp_read_api, nightly_import_file, shared_mailbox]
  data_classes: [supplier_banking, personal_information_sole_traders]
  identity: "Workbench users via Sandveld directory"
  region_constraints: ["Agree processing location with Sandveld privacy owner"]

ai_design:
  ai_steps: [document_extraction, exception_explanation]
  deterministic_steps: [three_way_match, weight_tolerance, duplicate_rules]
  human_steps: [exception_decision, payment_release]
  permitted_actions: [draft_recommendation, queue_clean_posting]
  prohibited_actions: [change_supplier_bank_details, release_payment]

evidence:
  evaluation_set: "Golden set built from the six-week sample"
  release_thresholds: []
  telemetry: [trace_per_invoice, cost_per_invoice]
  cost_model: ""
  outcome_measure: "Exceptions resolved per clerk-hour; duplicates caught"

operations:
  service_owner: ""
  support_model: ""
  recovery: ""
  change_process: ""
  handover: ""

The empty fields at the bottom were deliberate. They were the questions discovery had not yet answered, and they stayed visible until it had.

Discovery deliverables

A credible discovery, or "AI opportunity sprint", should produce:

1. a current-state operating map;
2. an exception and decision catalogue;
3. a systems, data and integration map;
4. pain-point evidence and baseline measures;
5. candidate future-state workflows;
6. a responsibility map: AI, automation and people;
7. a prioritised opportunity portfolio;
8. initial architecture and security constraints;
9. evaluation and value hypotheses;
10. a delivery roadmap with assumptions and decision gates.

Part 6 covers how to sell this as a paid deliverable, and why the client should keep its value even if implementation never goes ahead.

Red flags

Watch for these in any forward deployed engagement, from either side of the table:

• The FDE has no access to practitioners.
• The client wants implementation before discovery.
• The engagement has no named business owner.
• The solution depends on replacing core systems without a transition case.
• "Human in the loop" has no defined reviewer capacity or authority.
• Evaluation is a few hand-picked prompts.
• Costs exclude integration, review, support and change.
• Production ownership is deferred until go-live.
• Every client receives unique code with no product feedback path.
• The role is measured on prototypes rather than outcomes.
• Compensation or value claims are repeated without evidence.

The short version

Documented and performed work differ. Build from the performed one.

Observe, do not only interview. "Show me" finds what "tell me" leaves out.

Split by variant before automating. The small rows carry the risk.

Write the unwritten rules down. A tolerance applied hundreds of times a month is a requirement, whether or not anyone documented it.

The process map is a hypothesis until practitioners and evidence show that it matches the work.

Previous: Part 1, the FDE is an operating model. Next: Part 3, where should intelligence live? See every part on the series page.

How CloudNala can help

We run discovery that observes the work rather than only interviewing about it: shadowing practitioners with the right consent and data agreements in place, pulling real volumes and variants from your systems, writing down the rules experienced staff apply by judgement, and turning the result into an operating map, an exception catalogue and a prioritised set of opportunities you keep whether or not you build anything next.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Opportunity Sprint or write to us at consult@cloudnala.co.za