- Who is this for?
- Executives, operations leaders and transport transformation managers
- Question addressed
- Select a realistic first transport automation scope before starting a project.
Key takeaways
- A day of observation reveals the searches, checks and rework hidden behind a task label.
- High volume never offsets unstable rules, poor sources or a risk that cannot be controlled.
- Prepare, execute and keep human are design choices, not mandatory maturity levels.
- Every first scope needs a measurable hypothesis, a business owner and a stop condition.
Observe a working day before choosing a tool
Start at the workstation on a day that represents the activity you want to understand. The goal is not to time people. It is to follow files: what event starts the work, which information is retrieved, what decision is made, which action follows, and how the outcome is checked.
Break down labels that are too broad. “Process an order” may include reading an email, identifying the customer, finding a reference, checking a slot, entering data in the TMS and reading it back. These steps do not have the same stability or risk, so they may warrant different treatments.
| Record for each occurrence | Question to ask | Useful evidence |
|---|---|---|
| Trigger | What causes processing to begin? | Email, portal event, document, alert or internal request. |
| Sources consulted | Where does the team find information and rules? | System, screen, file, attachment, conversation or procedure. |
| Decision | What choice is made and when does the team hesitate? | Rule applied, exception and person consulted. |
| Action | What must be created, changed, sent or checked? | Target system, affected fields and permission used. |
| Outcome | How does the team know the file has actually moved forward? | Read-back state, confirmation, reconciliation or approval. |
| Rework | Why does the case return to the team? | Missing data, ambiguity, absent rule, error or unavailable access. |
Assess volume, stability, risk and source quality
Use a simple 1-to-3 scale to compare tasks with one another. The scores are not industry benchmarks: they express what the team observed in its own scope. For risk, a high score means a more automation-friendly case—limited impact, detectable failure and a defined recovery path.
| Criterion | 1 · Unfavorable | 2 · Needs scoping | 3 · Favorable |
|---|---|---|---|
| Volume and frequency | Rare or highly irregular cases. | Recurring but variable workload. | Frequent flow representing an observable workload. |
| Stability | Largely implicit or changing decision. | Known rules with several exceptions. | Explicit, repeatable and testable steps and rules. |
| Source quality | Information is often missing, ambiguous or inaccessible. | Sources are known, but checks or mappings need strengthening. | Accessible sources, reliable identifiers and controllable data. |
| Controllable risk | Sensitive, hard-to-reverse or hard-to-detect failure. | Impact can be contained by an approval or additional check. | Limited, verifiable action with a safe recovery path. |
Adding the scores can help order the investigation, but it must not conceal a blocking issue. A frequent task remains a poor first candidate if the target file cannot be identified reliably or the result cannot be read back. Record vetoes separately: missing permission, unauthorized source, unformalized decision or unacceptable impact.
Classify each task: prepare, execute or keep human
An audit should not force every task towards automated execution. It should choose the right division of work for every step. A single chain may use all three categories: context is prepared, a standard update is executed, and a commercial exception remains a human decision.
| Classification | When to use it | Expected outcome | Essential control |
|---|---|---|---|
| Prepare | Sources can be assembled, but the decision still needs approval or has many exceptions. | Structured file, explicit proposal and missing items flagged. | The person can see the sources, proposed rule and exact decision required. |
| Execute | The rule, scope, permissions and expected outcome are explicit and testable. | Limited action in the authorized system. | Compare the resulting state with the expected state and stop on any mismatch. |
| Keep human | The decision is sensitive, rare, negotiated or cannot be formalized reliably. | Decision remains with the appropriate business role. | Preserve context and, where useful, automate only the upstream preparation. |
Use the matrix to select a first scope
Create one row for each task actually observed, not for each imagined project. Score the four dimensions with the team that performs the work, document blockers and choose the target mode. The “evidence of completion” column prevents the selection of an action that could not subsequently be confirmed.
| Observed task | Volume 1–3 | Stability 1–3 | Sources 1–3 | Risk 1–3 | Target mode | Veto or condition | Evidence of completion |
|---|---|---|---|---|---|---|---|
| [Precise task name] | [ ] | [ ] | [ ] | [ ] | [Prepare / Execute / Human] | [Permission, rule, source, impact…] | [State to read back or expected evidence] |
| [Second task] | [ ] | [ ] | [ ] | [ ] | [Prepare / Execute / Human] | [Condition to resolve] | [Observable check] |
| [Third task] | [ ] | [ ] | [ ] | [ ] | [Prepare / Execute / Human] | [Condition to resolve] | [Observable check] |
Prefer a short but complete loop: an identifiable trigger, a file to locate, a bounded decision, a useful action or preparation, and a verifiable outcome. Temporarily set aside candidates whose score looks good but depends on an unvalidated rule. They can return after clarification; the point of the audit is to make these dependencies visible.
Complete a reusable scoping sheet
The matrix chooses the subject; the sheet below turns that choice into a working hypothesis. It should be reviewable by the business owner, the person responsible for access and the team that will handle stopped cases. If one row remains vague, the scope is not ready to be tested.
| Scoping field | What to enter |
|---|---|
| Name and objective | Precise task, observed problem and desired business outcome. |
| Included scope | File types, customers, channels, systems, periods and sites covered. |
| Out of scope | Exceptions, sensitive decisions and situations explicitly excluded. |
| Trigger and final state | Starting event, expected state and evidence that confirms completion. |
| Sources and quality | Origin of each data item, identifiers, known gaps and freshness check. |
| Rules and permissions | Validated rules, version, permitted actions, accounts and required access. |
| Treatment mode | Prepare, execute or keep human for each step. |
| Stops and recovery | Stop reasons, context handed over, recipient and recovery procedure. |
| Measurable hypothesis | Expected change, indicator, baseline and comparison method. |
| Responsibilities | Business owner, technical owner, approver and monitoring owner. |
State the hypothesis without promising the outcome: “within this scope, automatically preparing complete files should reduce manual searches without increasing corrections after approval.” The next phase must measure coverage, errors, stops and remaining work separately. That is a pilot protocol; this audit has only established where to start.
Frequently asked questions
Direct answers
Should we start with the task that takes the most time?
Not necessarily. Visible effort matters, but a first scope also needs stable rules, usable sources, controllable risk and a verifiable outcome. A smaller task may provide a stronger first loop.
Is one day of observation enough?
It is enough to build a first map if its limitations are recorded. Extend it when peaks, period-end work, incidents or absent file categories could change the priority.
What is the difference between the audit and the pilot?
The audit compares tasks and frames the one to test. The pilot then uses real files to measure reliability, exclusions and remaining work before the scope is extended.
Sources and methodology
This resource describes Axonovia's product approach based on transport workflows. The examples are illustrative and do not constitute a performance commitment or a universally applicable contractual rule.
Product review: Axonovia team · next review recommended before 31 August 2027 or following a material change in scope.