Halfway through an automation project, our team needed a simple comparison for a report: how long the manual process took and how long the new system took. We could measure the system. No one had ever produced the manual baseline.
Documentation was not the problem. Years of reports described the delays, the workload, and the people involved. Requirements stated the intended outcome. Process tables named phases and assigned roles. None of those records broke the work into units that could be counted, timed, or compared.
That gap changed the project. Before we could defend the automation, we had to define the work itself.
The distinction matters because process documentation can describe what should happen without showing how the work actually moves from one decision to the next. Business process automation requires that second view. A team must be able to identify each task, the person or system responsible for it, the evidence needed to complete it, and the condition that allows the work to move forward.
Why a documented process can still be undefined
A requirement gives a team a destination. A phase diagram gives the destination a rough route. Neither necessarily captures the actions and judgments that make the process run.
In this project, two authoritative documents described the same workflow at different points in time. An earlier design assigned one step to the people submitting the data. Current operating rules prohibited those people from performing that step because of a stated risk. Each document made sense within its own context. The contradiction appeared only when we placed the work in sequence and assigned an owner to every step.
This is why documentation volume is a poor proxy for process definition. A library can be complete at the document level and still leave critical operating questions unanswered:
- What is the smallest unit of work that can be assigned or measured?
- Which steps apply rules, and which require human judgment?
- Who owns each decision and its exceptions?
- What evidence allows the next step to begin?
- Which inputs are supported, and why are others out of scope?
The Business Process Model and Notation specification provides a standard way to represent activities, events, decisions, and participants. That representation is useful because it makes the workflow inspectable. It does not, by itself, prove that the team captured the real work or measured it correctly. Practitioners still have to expose the decisions they make in practice, including the ones that never reached a formal document.
The IEEE Task Force on Process Mining describes process mining as a way to discover and monitor processes from event logs. Logs can reveal the paths that people and systems actually recorded, rather than only the path prescribed by a process diagram. That evidence still has limits: it cannot recover a judgment, exception, or handoff that was never recorded. Event data and practitioner knowledge therefore provide complementary views of the process.
Define the work at the level AI must execute
We found three missing layers.
The first was work units. The existing documents described broad phases such as review. A phase cannot be assigned cleanly to a model, a system, or a person until the team separates it into observable actions.
The second was the judgment practitioners applied while doing the work. Experienced operators knew which values to distrust, what they checked first, when they asked a colleague, and which exception stopped the process. That knowledge lived with the people doing the work and varied slightly across the team.
The third was measurement. Nobody could write the expression that represented the cost of the manual work. The missing artifact was not the final number. It was the set of variables, units, and owners required to calculate it.
Defining those layers changed the design. Automated output became a draft until a person confirmed the judgment that mattered. Unresolved cases stopped instead of flowing downstream. Supported and unsupported input types were separated with explicit reasons. The team placed decisions that had been scattered across the workflow into one ordered review sequence and gave each one a named owner.
The table below turns those lessons into a definition check.
| Definition element | Question to answer | Evidence to retain | Failure if missing |
|---|---|---|---|
| Work unit | What observable action changes the state of the case? | Input, output, completion condition, and time unit | A broad phase is assigned to AI without a testable boundary |
| Decision rule | Which cases follow a rule, and which require judgment? | Rule, exception, escalation point, and approval condition | The system treats an exception as routine work |
| Owner | Who confirms the result or accepts the risk? | Named role and handoff record | Decisions move forward without accountable review |
| Input boundary | Which input types are supported, and why? | Typology, inclusion rule, and exclusion reason | Unsupported cases are processed as if they were valid |
| Measurement | Which variables describe time, cost, quality, or risk? | Formula, unit, source, and observation window | Savings or performance claims cannot be reproduced |
This checklist also reflects ISO’s public guidance on the process approach in ISO 9001:2015. The guidance asks organizations to define process inputs and outputs, sequence and interactions, ownership, controls, and measurement. It is not an AI-readiness test, but it reinforces the need for operating evidence beyond a stated objective.
Write the formula before estimating the return
Once the work units existed, we could write a simple measurement structure:
total time = number of tables × table-review time + number of items × item-processing time + number of tables × verification time
The expression is illustrative. Its terms came from one project, and the coefficients were still unknown when we first wrote it. That was the point. A formula exposes exactly what must be measured and who can provide each value.
The practitioners owned the manual baseline because they performed the existing work. The system team owned the new measurements because it could observe the automated path. A defensible comparison required both. Agreement was not a general approval of a workflow diagram. It meant that each group understood which part of the evidence it owned and stood behind that evidence.
This approach also prevents a common measurement error. A metric describes a particular implementation. If a component, decision rule, input boundary, or human handoff changes, the metric may no longer describe the process. The team must define the measurement again when the work changes shape.
The NIST AI Risk Management Framework Playbook also places context, assigned roles, measurement, and review within the same risk-management process. It does not prescribe this formula. Its relevance here is narrower: AI systems should be evaluated for their intended context, with responsibilities and measurement defined in advance.
Automation and transformation are different projects
A before-and-after formula helps distinguish automation from transformation.
Automation keeps the expression and reduces one or more coefficients. The same work units remain, the same decisions exist, and ownership stays largely intact. A system performs a step faster or with less manual effort.
Transformation changes the expression. Some terms disappear because the old step is no longer needed. Some decisions move from execution to confirmation. New work appears, such as reviewing an unfamiliar input type, maintaining a typology, or recalibrating a metric after an implementation change. A task that was impractical for people may become a new system stage.
Neither category is inherently better. The distinction matters because the scope, risk, evidence, and expected return are different. Calling both projects automation can hide new human work and leave owners unprepared. Calling a coefficient reduction transformation can overstate what actually changed.
The practical test is straightforward: put the old and new expressions side by side. If the terms stay the same and only their coefficients shrink, the team automated the process. If terms disappear, change owners, or appear for the first time, the team changed the work itself.
- Review
- Process
- Verify
- Review
- Process
- Verify
- Review
- Process
- Confirm new owner
- Exception work
AI-ready data depends on the work you define
Teams often assess whether data is clean, complete, labeled, or documented before an AI project. Those checks matter, but they cannot answer whether the data is ready for an undefined task.
Readiness is evaluated against a target. The team needs to know what the system must do, which input types it will accept, what result counts as usable, who reviews exceptions, and under which operating conditions the result will be trusted. If the work changes during transformation, the readiness test must change with it.
This is also the boundary between process definition and data qualification. Process owners define the work and its acceptance conditions. Data and AI teams can then test whether a specific data state supports those conditions. One activity cannot substitute for the other.
Use a Proof Run only after the target is clear
For this decision, a Syntitan Proof Run becomes relevant after the team can name the task and its success metric. Its current Proof Run workflow uses a selected model task and target metric to compare raw and AI-ready data states. That comparison can answer a bounded question: did the changed data state improve the result under the stated test conditions?
It cannot define the business process, produce a missing manual baseline, assign human ownership, or prove that the organization completed a transformation. Those decisions remain with the people who own the work.
The sequence matters. Define the task, decisions, boundaries, and measurement first. Then test whether the data state can support them. Otherwise, the team may produce a technically valid comparison for a process it still cannot explain.
Run the formula test before the demo
Before selecting a model or presenting an automation business case, ask the process owner for the formula. Do not ask for a rough savings estimate. Ask for the variables, units, and owner of each term.
Then check whether the team can:
- break the process into observable work units;
- identify the rules, judgments, and escalation points;
- assign an accountable owner to each decision;
- define supported inputs and explicit exclusions;
- show where each baseline and system measurement comes from; and
- explain whether the proposed design reduces coefficients or changes the expression.
If the team can answer those questions, it has a process that can be scoped, tested, and measured. If it cannot, the first milestone is not a model. It is a definition of the work.
With the work and success metric defined, the next step is to test whether the data is ready for the task. See how Syntitan compares raw and AI-ready data under controlled Proof Run conditions.
