Practical intelligence for accountable AI programmes.
A practical South African guide to mapping real workflow behaviour, testing approvals, defining handoffs and resolving exceptions before automation.
ModelFold Editorial Team8 min read
Redesign the work before choosing how to automate it. A request that arrives by email, is captured again, gathers a signature that changes nothing, waits in several queues and returns when evidence is missing will not become sound merely because software moves it faster. Begin with the route people actually follow. Establish what every step achieves, who owns each deviation, what evidence permits the next action and where consequential judgement or required independence must remain with an authorised person.
Key takeaways
The current-state map must show how one recurring case moves from an observable trigger to an accepted outcome, without assuming a particular solution. Bound the exercise around one case type, end condition and downstream user. Solution-agnostic documentation can then expose the actors, decisions, forward-moving tasks and task detail that matter. Evidence-informed current-state analysis should precede future-state design, otherwise the team risks drawing an idealised procedure rather than the operating workflow.
Test the map against representative completed cases, walkthroughs, forms, support records, audit findings and event data. Procedures describe intended work; records reveal only what they capture, so neither should stand alone. Lean value-stream concepts distinguish cycle time from end-to-end lead time and can be adapted cautiously to service work. An event log commonly needs a case identifier, activity and timestamp, but those fields cannot establish coverage, data quality or the reason for a delay.
A deviation becomes a standard variant when it is legitimate and recurring, and its entry criteria, steps, owner, evidence and outcome are stable. Frequency by itself is not enough. BPMN can make alternate and failure paths visible through gateways, timers, errors, escalations and boundary events, but notation does not decide their business treatment. Standardised work provides an improvable baseline that must be revisited as operating conditions change.
Build an exception register from observed cases. Record the trigger, representative examples, frequency over a stated period when known, consequence, safe response, recovery owner, delegated boundary, required evidence and durable outcome. Treat high or low volumes as diagnostic signals, not verdicts: similar counts may arise from unstable inputs, hidden side channels, miscoding, a narrow normal path or genuinely variable work. Rare cases may still matter when their consequences or recovery demands are material.
An approval is worth keeping when it makes a distinct, supported decision that changes the next state. Name the possible outcomes: approve, reject, return, condition or escalate. If the person cannot alter what happens next, the step may instead be acknowledgement, consultation, notification or evidence production. Control activities should reflect objectives, assessed risks, operating complexity and data sensitivity, rather than inherited habit or the gate's position on a diagram.
Authorisation should sit with people acting within their authority, while appropriate documentation and segregation can separate authorising, processing, recording and reviewing responsibilities. Manual, partially automated and automated controls may coexist; software alone does not make a control effective, and a human presence does not make it safe. Where AI is involved, document the operating context, roles, system limits, risk tolerance, oversight duties and how people are expected to use its outputs.
A handoff is complete when a named receiving owner accepts a sufficiently complete case and can begin the expected next action. Sending an email, forwarding a folder or placing work in a queue proves only that the sender acted. BPMN distinguishes participants and message flows across organisational boundaries, but a useful operating contract must also state what acceptance means and what happens when the receiving team cannot accept the work.
Measure the wait from ready-for-transfer to accepted ownership separately from touch time. Also watch returns for incomplete information, ownership changes, ageing unaccepted work, locally defined service breaches, evidenced downstream rework and completion through side channels. A durable record makes significant events available for examination, but it cannot prove that the underlying decision was correct or that the control operated effectively. Those questions still require review of the case and its evidence.
Give every mapped element exactly one disposition: remove, standardise, clarify or retain for human review. This is an editorial synthesis of whole-flow improvement, standardised work, explicit governance, risk-based control design and human oversight; no cited authority prescribes these four labels as one method. The discipline prevents a vague automate-or-escalate choice and forces the team to state why each step, branch, decision or transfer belongs in the proposed workflow.
Do not automate an inherited diagram; redesign the decisions, evidence, exceptions and ownership that make the workflow real.
| Disposition | Use when | Illustrative application | Required caution |
|---|---|---|---|
| Remove | The element makes no distinct decision, supplies no required information, creates no necessary value and mitigates no assessed risk left unaddressed elsewhere. | Remove a status-only signature that changes no resource, authority or risk decision. | Delay is not proof that a control is unnecessary; confirm its purpose and dependencies first. |
| Standardise | Complete inputs, stable rules, permitted outcomes, low ambiguity and a consistent owner make repeatable work possible. | Standardise intake fields, duplicate checks, ordinary classification and normal routing. | A baseline supports consistency and improvement but does not mean every case belongs on it. |
| Clarify | A necessary element has ambiguous ownership, authority, evidence, criteria, completion, escalation or recovery. | Name the owner of incomplete submissions and define accepted transfer to fulfilment. | Resolve the smallest missing contract instead of routing every ambiguity to senior management. |
| Retain for human review | A consequential decision needs delegated authority, contextual judgement, expertise, independence or resolution of an unbounded case. | Keep authorised budget, specialist, independent-control or policy-exception decisions when organisational requirements call for them. | Require adequate evidence, competence, defined outcomes and a recorded rationale. |
Consider an internal request for a new third-party business service. Operations could remove a manager's status-only signature if it makes no substantive decision, standardise complete intake and normal routing, clarify exception and fulfilment ownership, and retain authorised budget or specialist review when risk and organisational requirements demand it. The appropriate preventive and detective controls depend on assessed likelihood, impact and context, not on a universal preference for either manual or automated operation.
A workflow is ready only when representative cases can pass through the proposed design with clear ownership, evidence, decisions, acceptance conditions and recovery behaviour. A documentation model may remain non-executable, while implementation needs additional formal detail; a neat current-state diagram is therefore not an implementation specification. Walk routine, incomplete, rejected, boundary, timeout, override, reworked and technical-failure cases through the design, checking them against records wherever suitable evidence exists.
Proceed conditionally, revise where a contract is incomplete and stop where material questions remain. Control design, authorisation, segregation, documentation and preventive-detective balance must respond to the organisation's objectives and assessed risks. Consult qualified and authorised legal, regulatory, financial, security, privacy, safety, procurement, human-resources, internal-control or other professional roles before changing a control or interpreting an obligation in their domain. Unresolved policy, delegation, independence, evidence, risk-acceptance or professional-judgement questions should halt implementation.
Bound one recurring case type between an observable trigger and an accepted outcome, then map the route people actually follow using representative records and walkthroughs. Record the normal path, variants, exceptions, approvals, handoffs, delays, owners and evidence. Assign each element one disposition: remove, standardise, clarify or retain for human review.
Record the observable trigger, representative cases, frequency over a stated period when known, operational or control consequence and safe response. Add the recovery owner, delegated boundary, evidence required, resolution outcome and durable record. Note whether recurrence points towards an input, rule, capacity, policy, normal-path or system problem without treating that diagnosis as proven.
Identify its distinct decision, control purpose, delegated authority, evidence, possible outcomes and downstream effect. Check whether competence, independence or separation of duties is required and whether another retained control genuinely addresses the same evidence, decision and risk. Do not remove a gate merely because it delays work or looks repetitive.
Include the case identity and state, sender, named receiver, required information, attachments and evidence that the prior step is complete. Define acceptance criteria, the expected next action and a locally appropriate service expectation. Add routes for incomplete, disputed, timed-out or misrouted work and retain a durable record of accepted ownership.
It is ready when representative normal and abnormal cases can pass through a design with named owners, bounded exceptions, purposeful approvals, accepted handoffs, preserved controls and defined recovery. Permissions, monitoring, retry behaviour, duplicate prevention, reconciliation and change ownership must suit the assessed risk. Stop when material policy, delegation, independence, evidence, risk-acceptance or professional-judgement questions remain unresolved.
This article was researched using the following sources:
We report on how AI actually lands inside a business. Our work starts from named sources, separates what we found from what we think, and uses AI assistance for research and drafting under documented editorial controls. We are not a substitute for individual expert review.
A practical field-research method for testing workflow complaints, locating recurring constraints and deciding whether AI deserves a controlled trial.
A practical, technology-neutral guide to controlling documents from secure intake and extraction through human review, acknowledged delivery and retention.
A practical South African guide to mapping tasks, testing AI assistance, tracing hidden effort and redesigning roles after a measured pilot.
