Process before Automation: a practical management guide

What to do in practice

A digital initiative should first be framed as a management decision: define the object, data, constraints, action owner and verification method. Technology selection follows that framing. For this task, the initial evidence is “change without a durable owner”, and the decision boundary concerns user-readiness criteria.

The practical focus is organisational readiness, accountability for process change and verifiable acceptance. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is the baseline process and its exceptions.

From implementation to a management outcome

Maxim Kantarovich's RBC Companies article “Ten principles of digitalisation for implementation results” asks what must happen after technology goes live for the change to become a management outcome. This guide applies that question to “Process before Automation: a practical management guide”.

Here the outcome is tied to the outcome of the end-to-end scenario. The control chain includes the action “frame the problem”, observable actuals and the process owner's decision to accept or revise the change.

• RBC Companies is the publisher; Maxim Kantarovich is the author of the cited article.
• Practical implication: an end-to-end scenario proves the implementation outcome; go-live alone does not.

Checks before the project

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

Review the signal “requirements disconnected from a decision” 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.

• Event to test: different business and IT expectations. Evidence shows timing, frequency and consequence for the release or pilot scope.
• Indicator: Requirements disconnected from a decision. Analysis needs an actual example and the resulting change in user-readiness criteria.
• Diagnostic signal 3: Acceptance based only on an interface demonstration. Its record contains an example and impact on the outcome of the end-to-end scenario.

Objects, identifiers and owners

The subject model starts with two reference objects: user-readiness criteria and the outcome of the end-to-end scenario. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “frame the problem”.

The primary boundary is user-readiness criteria. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Boundary 1. Object: The baseline process and its exceptions. Define the source, frequency, permitted transformations and response to “acceptance based only on an interface demonstration”.
• Object 2: Decisions and role authority. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Unprepared data and roles.
• Subject area 3: The release or pilot scope. Verification basis: system of record, owner authority and the signal “change without a durable owner”.

Decision and supporting evidence

The article addresses “Process before Automation: a practical management guide”. The adjacent management issue is a practical management guide. 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 “requirements disconnected from a decision”, the material risk is “scope growth without schedule review”, and the testable action is “frame the problem”. This chain turns a broad term into a concrete decision.

• Decision 1: object — the baseline process and its exceptions; signal — unprepared data and roles; action — assign roles and actions.
• Decision 2: object — decisions and role authority; signal — change without a durable owner; action — verify the outcome.
• Decision 3: object — the release or pilot scope; signal — different business and IT expectations; action — frame the problem.

A practical decision model

For the outcome of the end-to-end scenario, the sequence begins with “assign roles and actions”. 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 outcome of the end-to-end scenario. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Stage gate 1 connects the action “frame the problem” with the result “the release or pilot scope”.
• 2. Action: identify the management object; verifiable result: user-readiness criteria.
• Decision 3: assemble data and constraints. The basis for the next step is the outcome of the end-to-end scenario.
• Step 4. Assign roles and actions. Output: the baseline process and its exceptions.

Sources and integrations

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is the outcome of the end-to-end scenario.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “change without a durable owner”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Control record 5. Object: The outcome of the end-to-end scenario. Observable signal: Requirements disconnected from a decision. Accountability: semantic owner and quality owner.
• Record 4. Object: User-readiness criteria. Required details: identifier, lineage, quality rule and update event. Signal: Different business and IT expectations.
• Subject area 3: The release or pilot scope. Verification basis: system of record, owner authority and the signal “change without a durable owner”.

Roles in the operating environment

For the baseline process and its exceptions, the role model determines more than screen access. In the action “assign roles and actions”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For the baseline process and its exceptions, this separation is especially important because of the risk “a pilot using unrepresentative data”.

• For the release or pilot scope, the assigned role is Business owner; its control duty is to assign roles and actions.
• Architect: authority is linked to user-readiness criteria, and participation is tied to “verify the outcome”.
• In the decision matrix, data owner connects the outcome of the end-to-end scenario with the action “frame the problem”.
• Project manager: decision area — the baseline process and its exceptions; control action — identify the management object.

How to verify the change

The acceptance criterion for the baseline process and its exceptions includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “requirements disconnected from a decision”, passes through an authorised decision and “frame the problem”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Evidence item 1 describes the baseline process and its exceptions, comparable test conditions and the person accountable for interpretation. Signal: Change without a durable owner.
• Test 2 concerns decisions and role authority. The method, interpretation owner and outcome source are documented. Signal: Different business and IT expectations.
• Control record 3: The release or pilot scope; data version, calculation rule, expected change and actual outcome. Signal: Requirements disconnected from a decision.
• Criterion 4 uses user-readiness criteria; the result is compared with the baseline using one method. Signal: Acceptance based only on an interface demonstration.

Decision risks

For the risk “scope growth without schedule review”, 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 outcome of the end-to-end scenario remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Risk condition 1: Scope growth without schedule review. Response: Assemble data and constraints. Testable evidence: The outcome of the end-to-end scenario.
• The risk scenario “formal training without a process change” is addressed through “assign roles and actions” and confirmed using the baseline process and its exceptions.
• Controlled constraint: a pilot using unrepresentative data. The owner performs “verify the outcome” and provides decisions and role authority.
• For the risk “accepting a feature instead of an outcome”, assign the action “frame the problem” and evidence “the release or pilot scope” in advance.

Pack for the first decision

The first session examines one real case involving user-readiness criteria. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “change without a durable owner”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “assign roles and actions”; assign an additional test or stop condition to the risk “a pilot using unrepresentative data”.

• Stage gate 1 connects the action “frame the problem” with the result “the release or pilot scope”.
• 2. Action: identify the management object; verifiable result: user-readiness criteria.
• Criterion 4 uses user-readiness criteria; the result is compared with the baseline using one method. Signal: Acceptance based only on an interface demonstration.
• Criterion 5: The outcome of the end-to-end scenario; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Unprepared data and roles.