Digitalisation before implementation: five management decisions

The core decision

Implementation produces a durable outcome through one coherent sequence: prepare process and data, deliver the agreed scope, run end-to-end tests, stabilise operations and transfer accountability. For this task, the initial evidence is “competing initiatives without shared criteria”, and the decision boundary concerns goals and management decisions.

The practical focus is the connection between strategy, decisions, the change portfolio and target architecture. 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 data and measures.

Maxim Kantarovich's source argument

In his RBC Companies article “Ten principles of digitalisation before implementation”, Maxim Kantarovich focuses on the decisions an organisation should make before selecting and configuring technology. This guide develops that authorial framing for “Digitalisation before implementation: five management decisions”.

For the present question, the starting object is goals and management decisions, and the first observable signal is “competing initiatives without shared criteria”. The management decision is documented before technology selection: name the owner, process boundary and baseline verification method.

• Maxim Kantarovich is the author of the cited RBC Companies article.
• Practical implication: agree the outcome owner, baseline data and acceptance criterion before the project starts.

Diagnosis before solution selection

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

Review the signal “measures without decision owners” 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: recurring gaps between strategy and projects. Evidence shows timing, frequency and consequence for goals and management decisions.
• Indicator: Competing initiatives without shared criteria. Analysis needs an actual example and the resulting change in capabilities and processes.
• Diagnostic signal 3: Inconsistent system maps. Its record contains an example and impact on data and measures.

Release, stabilisation and handover

For capabilities and processes, the sequence begins with “prepare process and data”. 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 capabilities and processes. 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 “prepare process and data” with the result “goals and management decisions”.
• 2. Action: deliver the agreed scope; verifiable result: capabilities and processes.
• Decision 3: run end-to-end tests. The basis for the next step is data and measures.
• Step 4. Stabilise critical scenarios. Output: systems and integrations.

Objects under management

Describe the boundary through object records rather than system names. For goals and management decisions, record meaning, identifier, source, quality owner and update event; for capabilities and processes, also document the relationship rule.

Test the link between goals and management decisions and capabilities and processes using an end-to-end example. The team performs “run end-to-end tests”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Object 1: Goals and management decisions. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Recurring gaps between strategy and projects.
• Subject area 2: Capabilities and processes. Verification basis: system of record, owner authority and the signal “competing initiatives without shared criteria”.
• Record 3. Object: Data and measures. Required details: identifier, lineage, quality rule and update event. Signal: Inconsistent system maps.

From signal to decision

The article addresses “Digitalisation before implementation: five management decisions”. The adjacent management issue is five management decisions. 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 “measures without decision owners”, the material risk is “disconnecting business goals from data”, and the testable action is “run end-to-end tests”. This chain turns a broad term into a concrete decision.

• Decision 1: object — goals and management decisions; signal — recurring gaps between strategy and projects; action — prepare process and data.
• Decision 2: object — capabilities and processes; signal — competing initiatives without shared criteria; action — deliver the agreed scope.
• Decision 3: object — data and measures; signal — inconsistent system maps; action — run end-to-end tests.

Integration contract

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 capabilities and processes.

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 “competing initiatives without shared criteria”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Boundary 5. Object: Initiatives, dependencies and resources. Define the source, frequency, permitted transformations and response to “investment without a target state”.
• Control record 4. Object: Systems and integrations. Observable signal: Measures without decision owners. Accountability: semantic owner and quality owner.
• Record 3. Object: Data and measures. Required details: identifier, lineage, quality rule and update event. Signal: Inconsistent system maps.

End-to-end outcome test

The acceptance criterion for data and measures 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 “measures without decision owners”, passes through an authorised decision and “run end-to-end tests”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Evidence item 1 describes goals and management decisions, comparable test conditions and the person accountable for interpretation. Signal: Inconsistent system maps.
• Test 2 concerns capabilities and processes. The method, interpretation owner and outcome source are documented. Signal: Measures without decision owners.
• Control record 3: Data and measures; data version, calculation rule, expected change and actual outcome. Signal: Investment without a target state.
• Criterion 4 uses systems and integrations; the result is compared with the baseline using one method. Signal: Recurring gaps between strategy and projects.

Authority and escalation

For data and measures, the role model determines more than screen access. In the action “prepare process and data”, 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 data and measures, this separation is especially important because of the risk “being unable to verify completion of the transition”.

• For goals and management decisions, the assigned role is Business owner; its control duty is to deliver the agreed scope.
• Architect: authority is linked to capabilities and processes, and participation is tied to “run end-to-end tests”.
• In the decision matrix, data owner connects data and measures with the action “stabilise critical scenarios”.
• Project manager: decision area — systems and integrations; control action — transfer knowledge and accountability.

Constraints and risk control

The risk map starts with two conditions: “disconnecting business goals from data” and “being unable to verify completion of the transition”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “being unable to verify completion of the transition” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Risk condition 1: Replacing architecture with a product list. Response: Prepare process and data. Testable evidence: Data and measures.
• The risk scenario “planning projects without dependencies” is addressed through “deliver the agreed scope” and confirmed using systems and integrations.
• Controlled constraint: disconnecting business goals from data. The owner performs “run end-to-end tests” and provides initiatives, dependencies and resources.
• For the risk “having no owner for the target model”, assign the action “stabilise critical scenarios” and evidence “goals and management decisions” in advance.

First working session

The first session examines one real case involving goals and management decisions. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “competing initiatives without shared criteria”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “prepare process and data”; assign an additional test or stop condition to the risk “being unable to verify completion of the transition”.

• Stage gate 1 connects the action “prepare process and data” with the result “goals and management decisions”.
• 2. Action: deliver the agreed scope; verifiable result: capabilities and processes.
• Criterion 4 uses systems and integrations; the result is compared with the baseline using one method. Signal: Recurring gaps between strategy and projects.
• Criterion 5: Initiatives, dependencies and resources; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Competing initiatives without shared criteria.