Data as a management asset: ownership, quality and value

Working answer

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 “unprepared data and roles”, and the decision boundary concerns the release or pilot scope.

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 outcome of the end-to-end scenario.

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 “Data as a management asset: ownership, quality and value”.

Here the outcome is tied to user-readiness criteria. The control chain includes the action “verify the outcome”, 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.

Signals in the starting situation

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: unprepared data and roles. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “different business and IT expectations”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Diagnostic signal 1: Different business and IT expectations. Its record contains an example and impact on decisions and role authority.
• Management signal 2: Requirements disconnected from a decision. Use condition: a link to an actual example and to the release or pilot scope.
• Diagnosis records “acceptance based only on an interface demonstration”, its recurrence and its impact on user-readiness criteria.

Process and data boundary

The subject model starts with two reference objects: the release or pilot scope and user-readiness criteria. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “verify the outcome”.

The primary boundary is the release or pilot scope. 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.

• Record 1. Object: The baseline process and its exceptions. Required details: identifier, lineage, quality rule and update event. Signal: Requirements disconnected from a decision.
• Control record 2. Object: Decisions and role authority. Observable signal: Acceptance based only on an interface demonstration. Accountability: semantic owner and quality owner.
• Boundary 3. Object: The release or pilot scope. Define the source, frequency, permitted transformations and response to “unprepared data and roles”.

Accountability boundary

State the decision before compiling requirements. It identifies the outcome of the end-to-end scenario, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “unprepared data and roles” and the risk “scaling before stabilisation” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “assemble data and constraints” connects them in a testable scenario.

• Decision 1: object — the baseline process and its exceptions; signal — acceptance based only on an interface demonstration; action — assemble data and constraints.
• Decision 2: object — decisions and role authority; signal — unprepared data and roles; action — assign roles and actions.
• Decision 3: object — the release or pilot scope; signal — change without a durable owner; action — verify the outcome.

A practical decision model

For user-readiness criteria, the sequence begins with “assemble data and constraints”. 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 user-readiness criteria. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• 1. Action: frame the problem; verifiable result: decisions and role authority.
• Decision 2: identify the management object. The basis for the next step is the release or pilot scope.
• Step 3. Assemble data and constraints. Output: user-readiness criteria.
• Assign roles and actions is the action at stage 4. The output documents the outcome of the end-to-end scenario.

Events, data and exchange

Describe data exchange as a contract between owners. For user-readiness criteria, 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 “unprepared data and roles” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Subject area 5: The outcome of the end-to-end scenario. Verification basis: system of record, owner authority and the signal “different business and IT expectations”.
• Object 4: User-readiness criteria. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Change without a durable owner.
• Boundary 3. Object: The release or pilot scope. Define the source, frequency, permitted transformations and response to “unprepared data and roles”.

Who makes the decision

For the outcome of the end-to-end scenario, the role model determines more than screen access. In the action “assemble data and constraints”, 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 outcome of the end-to-end scenario, this separation is especially important because of the risk “formal training without a process change”.

• Business owner: authority is linked to decisions and role authority, and participation is tied to “assemble data and constraints”.
• In the decision matrix, architect connects the release or pilot scope with the action “assign roles and actions”.
• Data owner: decision area — user-readiness criteria; control action — verify the outcome.
• Project manager is accountable for the outcome of the end-to-end scenario and confirms the action “frame the problem”.

Acceptance criteria

The acceptance criterion for the outcome of the end-to-end scenario 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 “different business and IT expectations”, passes through an authorised decision and “verify the outcome”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• 1. Acceptance object: the baseline process and its exceptions; compare the baseline sample, expected change and confirmed actuals. Test signal: Unprepared data and roles.
• Evidence item 2 describes decisions and role authority, comparable test conditions and the person accountable for interpretation. Signal: Change without a durable owner.
• Test 3 concerns the release or pilot scope. The method, interpretation owner and outcome source are documented. Signal: Different business and IT expectations.
• Control record 4: User-readiness criteria; data version, calculation rule, expected change and actual outcome. Signal: Requirements disconnected from a decision.

What can distort the outcome

For the risk “scaling before stabilisation”, 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 user-readiness criteria 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: scope growth without schedule review. The owner performs “identify the management object” and provides user-readiness criteria.
• For the risk “formal training without a process change”, assign the action “assemble data and constraints” and evidence “the outcome of the end-to-end scenario” in advance.
• Risk review starts with the condition “a pilot using unrepresentative data”. The decision uses the action “assign roles and actions” and data about the baseline process and its exceptions.
• Risk record 4. Condition: Accepting a feature instead of an outcome. Control action: Verify the outcome. Evidence source: Decisions and role authority.

Where to begin

The first working session on the release or pilot scope uses real material: a transaction example, report or plan, systems diagram, role list and the variance “unprepared data and roles”. Participants select one scenario, identify data gaps and perform the action “assemble data and constraints”.

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

• 1. Action: frame the problem; verifiable result: decisions and role authority.
• Decision 2: identify the management object. The basis for the next step is the release or pilot scope.
• Control record 4: User-readiness criteria; data version, calculation rule, expected change and actual outcome. Signal: Requirements disconnected from a decision.
• Criterion 5 uses the outcome of the end-to-end scenario; the result is compared with the baseline using one method. Signal: Acceptance based only on an interface demonstration.