How to select processes for RPA

Management challenge

Robots can process requests, reconcile records, transfer data between systems, send notifications and perform first-line controls, but RPA should not conceal a poorly designed process.

When the problem becomes visible

• Operators copy data between systems
• There are many repetitive reconciliations
• Manual entry causes recurring errors

How to design the solution

This approach keeps the discussion focused on management control rather than only on system functions.

• Choose a stable process
• Describe exception rules
• Keep an action log
• Assign a robot owner

Common mistakes

The most common mistakes appear when a team trades architecture quality for launch speed.

These mistakes may be hidden during a demonstration but become visible in production operation.

• Automate an unstable process
• Ignore exceptions
• Leave robots without monitoring

Key takeaways

• RPA suits repeatable rules.
• Stabilise the process before robotisation.
• Exceptions matter more than the happy path.
• Every robot needs an owner and monitoring.

What to do in practice

For “How to select processes for RPA”, define the outcome as a change in management practice. The central object is the escalation rule; it needs an agreed source, decision owner and observable state after the action “separate gating criteria from preferences”.

The first evidence is not a solution presentation but a reproducible example of “errors can be labelled and verified”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

RPA: process, exceptions and robot lifecycle

RPA is suited to a stable, repeatable and formalised process with digital inputs, clear rules and sufficient volume. Before development, define exceptions, access rights, control totals, logging and a safe hand-off to a person.

After go-live, a robot becomes an operational object with an owner, version, schedule, dependencies, monitoring, change procedure and fallback scenario. A centre of excellence governs the robot portfolio and reusable components.

Checks before the project

Diagnosis examines a concrete episode involving training and control data. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “results can be compared with a control sample” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Diagnostic signal 1: Many repeated data-driven decisions. Its record contains an example and impact on the escalation rule.
• Management signal 2: A manual operation follows a stable rule. Use condition: a link to an actual example and to errors and false positives.
• Diagnosis records “errors can be labelled and verified”, its recurrence and its impact on post-release monitoring.

Gating criteria and verification

For the escalation rule, the sequence begins with “separate gating criteria from preferences”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for the escalation rule. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• 1. Action: describe mandatory scenarios; verifiable result: the escalation rule.
• Decision 2: separate gating criteria from preferences. The basis for the next step is errors and false positives.
• Step 3. Prepare one shared demonstration dataset. Output: post-release monitoring.
• Assess integrations and operations is the action at stage 4. The output documents the user decision or operation.

Decision and supporting evidence

The article addresses “How to select processes for RPA”. The adjacent management issue is training and control data. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “results can be compared with a control sample”, the material risk is “robotising an unstable process”, and the testable action is “assess integrations and operations”. This chain turns a broad term into a concrete decision.

• Decision 1: object — the user decision or operation; signal — a manual operation follows a stable rule; action — separate gating criteria from preferences.
• Decision 2: object — training and control data; signal — errors can be labelled and verified; action — prepare one shared demonstration dataset.
• Decision 3: object — the escalation rule; signal — there is an owner for the next action; action — assess integrations and operations.

Objects, identifiers and owners

Describe the boundary through object records rather than system names. For training and control data, record meaning, identifier, source, quality owner and update event; for the escalation rule, also document the relationship rule.

Test the link between training and control data and the escalation rule using an end-to-end example. The team performs “assess integrations and operations”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Boundary 1. Object: The user decision or operation. Define the source, frequency, permitted transformations and response to “errors can be labelled and verified”.
• Object 2: Training and control data. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: There is an owner for the next action.
• Subject area 3: The escalation rule. Verification basis: system of record, owner authority and the signal “results can be compared with a control sample”.

Sources and integrations

Describe data exchange as a contract between owners. For the escalation rule, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “errors can be labelled and verified” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Control record 5. Object: Post-release monitoring. Observable signal: A manual operation follows a stable rule. Accountability: semantic owner and quality owner.
• Record 4. Object: Errors and false positives. Required details: identifier, lineage, quality rule and update event. Signal: Many repeated data-driven decisions.
• Subject area 3: The escalation rule. Verification basis: system of record, owner authority and the signal “results can be compared with a control sample”.

How to verify the change

Verification of errors and false positives starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “errors can be labelled and verified” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for training and control data.

• 1. Acceptance object: the user decision or operation; compare the baseline sample, expected change and confirmed actuals. Test signal: Results can be compared with a control sample.
• Evidence item 2 describes training and control data, comparable test conditions and the person accountable for interpretation. Signal: Many repeated data-driven decisions.
• Test 3 concerns the escalation rule. The method, interpretation owner and outcome source are documented. Signal: A manual operation follows a stable rule.
• Control record 4: Errors and false positives; data version, calculation rule, expected change and actual outcome. Signal: Errors can be labelled and verified.

Roles in the operating environment

Build the authority matrix around decisions concerning errors and false positives. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “separate gating criteria from preferences” concerning errors and false positives in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Business owner: authority is linked to the escalation rule, and participation is tied to “assess integrations and operations”.
• In the decision matrix, architect connects errors and false positives with the action “record the decision and assumptions”.
• Data owner: decision area — post-release monitoring; control action — describe mandatory scenarios.
• Project manager is accountable for the user decision or operation and confirms the action “separate gating criteria from preferences”.

Decision risks

For the risk “robotising an unstable process”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning the escalation rule remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Controlled constraint: a model without a business decision owner. The owner performs “prepare one shared demonstration dataset” and provides post-release monitoring.
• For the risk “training on incomplete data”, assign the action “assess integrations and operations” and evidence “the user decision or operation” in advance.
• Risk review starts with the condition “automated action without a safe stop”. The decision uses the action “record the decision and assumptions” and data about training and control data.
• Risk record 4. Condition: Robotising an unstable process. Control action: Describe mandatory scenarios. Evidence source: The escalation rule.

Pack for the first decision

The first working session on training and control data uses real material: a transaction example, report or plan, systems diagram, role list and the variance “errors can be labelled and verified”. Participants select one scenario, identify data gaps and perform the action “separate gating criteria from preferences”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “robotising an unstable process” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• 1. Action: describe mandatory scenarios; verifiable result: the escalation rule.
• Decision 2: separate gating criteria from preferences. The basis for the next step is errors and false positives.
• Control record 4: Errors and false positives; data version, calculation rule, expected change and actual outcome. Signal: Errors can be labelled and verified.
• Criterion 5 uses post-release monitoring; the result is compared with the baseline using one method. Signal: There is an owner for the next action.