How to achieve results from digital implementation

Answer for management practice

For “How to achieve results from digital implementation”, define the outcome as a change in management practice. The central object is the release or pilot scope; it needs an agreed source, decision owner and observable state after the action “deliver the agreed scope”.

The first evidence is not a solution presentation but a reproducible example of “acceptance based only on an interface demonstration”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

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 “How to achieve results from digital implementation”.

Here the outcome is tied to the release or pilot scope. The control chain includes the action “stabilise critical scenarios”, 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.

Where the problem becomes visible

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

Review the signal “change without a durable owner” 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.

• Signal: Different business and IT expectations. Evidence includes an example, frequency and consequence for the outcome of the end-to-end scenario.
• Event to test: requirements disconnected from a decision. Evidence shows timing, frequency and consequence for the baseline process and its exceptions.
• Indicator: Acceptance based only on an interface demonstration. Analysis needs an actual example and the resulting change in decisions and role authority.

Release, stabilisation and handover

The method is a sequence of decisions rather than a universal checklist. For the release or pilot scope, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For decisions and role authority, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “deliver the agreed scope”.

• Step 1. Prepare process and data. Output: the outcome of the end-to-end scenario.
• Deliver the agreed scope is the action at stage 2. The output documents the baseline process and its exceptions.
• At position 3, the action is “run end-to-end tests”; its result is decisions and role authority.
• Stage 4: stabilise critical scenarios. The working artefact describes the release or pilot scope.

Subject model and boundaries

The subject model starts with two reference objects: decisions and role authority and the release or pilot scope. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “stabilise critical scenarios”.

The primary boundary is decisions and role authority. 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.

• Control record 1. Object: The baseline process and its exceptions. Observable signal: Change without a durable owner. Accountability: semantic owner and quality owner.
• Boundary 2. Object: Decisions and role authority. Define the source, frequency, permitted transformations and response to “different business and IT expectations”.
• Object 3: The release or pilot scope. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Requirements disconnected from a decision.

Management question

The article addresses “How to achieve results from digital implementation”. The adjacent management issue is decisions and role authority. 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 “change without a durable owner”, the material risk is “accepting a feature instead of an outcome”, and the testable action is “stabilise critical scenarios”. This chain turns a broad term into a concrete decision.

• Decision 1: object — the baseline process and its exceptions; signal — requirements disconnected from a decision; action — deliver the agreed scope.
• Decision 2: object — decisions and role authority; signal — acceptance based only on an interface demonstration; action — run end-to-end tests.
• Decision 3: object — the release or pilot scope; signal — unprepared data and roles; action — stabilise critical scenarios.

End-to-end scenario data

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 release or pilot scope.

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 “acceptance based only on an interface demonstration”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Record 5. Object: The outcome of the end-to-end scenario. Required details: identifier, lineage, quality rule and update event. Signal: Unprepared data and roles.
• Subject area 4: User-readiness criteria. Verification basis: system of record, owner authority and the signal “acceptance based only on an interface demonstration”.
• Object 3: The release or pilot scope. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Requirements disconnected from a decision.

Evidence that the solution works

The acceptance criterion for user-readiness criteria 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 “change without a durable owner”, passes through an authorised decision and “stabilise critical scenarios”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1: The baseline process and its exceptions; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Requirements disconnected from a decision.
• Criterion 2. Object: Decisions and role authority. Test fields: baseline, target change, source and owner. Signal: Acceptance based only on an interface demonstration.
• 3. Acceptance object: the release or pilot scope; compare the baseline sample, expected change and confirmed actuals. Test signal: Unprepared data and roles.
• Evidence item 4 describes user-readiness criteria, comparable test conditions and the person accountable for interpretation. Signal: Change without a durable owner.

Decision-rights matrix

Build the authority matrix around decisions concerning user-readiness criteria. 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 “deliver the agreed scope” concerning user-readiness criteria 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: decision area — the outcome of the end-to-end scenario; control action — prepare process and data.
• Architect is accountable for the baseline process and its exceptions and confirms the action “deliver the agreed scope”.
• Role: Data owner. Decision object: decisions and role authority; verified step: run end-to-end tests.
• Project manager decides within the release or pilot scope; the basis is prepared through “stabilise critical scenarios”.

Controlling critical dependencies

For the risk “accepting a feature instead of an outcome”, 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 release or pilot scope 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: Scope growth without schedule review. Control: transfer knowledge and accountability. Evidence: decisions and role authority.
• Risk condition 2: Formal training without a process change. Response: Prepare process and data. Testable evidence: The release or pilot scope.
• The risk scenario “a pilot using unrepresentative data” is addressed through “deliver the agreed scope” and confirmed using user-readiness criteria.
• Controlled constraint: accepting a feature instead of an outcome. The owner performs “run end-to-end tests” and provides the outcome of the end-to-end scenario.

Materials for starting work

The first working session on decisions and role authority uses real material: a transaction example, report or plan, systems diagram, role list and the variance “acceptance based only on an interface demonstration”. Participants select one scenario, identify data gaps and perform the action “deliver the agreed scope”.

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

• Step 1. Prepare process and data. Output: the outcome of the end-to-end scenario.
• Deliver the agreed scope is the action at stage 2. The output documents the baseline process and its exceptions.
• Evidence item 4 describes user-readiness criteria, comparable test conditions and the person accountable for interpretation. Signal: Change without a durable owner.
• Test 5 concerns the outcome of the end-to-end scenario. The method, interpretation owner and outcome source are documented. Signal: Different business and IT expectations.