Metric, cause and action: designing a management dashboard

The decision in two paragraphs

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 “users cannot see where a number came from”, and the decision boundary concerns master data and classifications.

The practical focus is data lineage, quality, accountability and management use. 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 marts and semantic models.

Applied analysis: Metric, cause and action: designing a management dashboard

“Metric, cause and action: designing a management dashboard” becomes manageable once one end-to-end scenario is selected. It starts with master data and classifications, passes through an accountable decision and ends with evidence for data marts and semantic models.

The working scenario starts with the signal “users cannot see where a number came from”. The team checks it against an agreed sample, performs “frame the problem” and observes the change in sources and transformations.

The acceptance record connects the baseline sample to data marts and semantic models. It states the expected change, actual outcome, interpretation owner and decision for the next cycle.

• Working object: Master data and classifications.
• Diagnostic signal: Users cannot see where a number came from.
• Response action: Frame the problem.
• Controlled risk: Self-service without a metric catalogue.

Starting situation and evidence

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

Review the signal “a dashboard does not lead to action” 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.

• Management signal 1: One measure has multiple values. Use condition: a link to an actual example and to measures and thresholds.
• Diagnosis records “users cannot see where a number came from”, its recurrence and its impact on errors, corrections and the quality log.
• Observation 3: Master data changes without an owner. Required fields: frequency, source and consequence for master data and classifications.

What belongs in scope

The subject model starts with two reference objects: master data and classifications and sources and transformations. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “assemble data and constraints”.

The primary boundary is master data and classifications. 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.

• Subject area 1: Master data and classifications. Verification basis: system of record, owner authority and the signal “a dashboard does not lead to action”.
• Record 2. Object: Sources and transformations. Required details: identifier, lineage, quality rule and update event. Signal: Errors are corrected only manually.
• Control record 3. Object: Data marts and semantic models. Observable signal: One measure has multiple values. Accountability: semantic owner and quality owner.

The decision point to resolve

State the decision before compiling requirements. It identifies data marts and semantic models, 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 “users cannot see where a number came from” and the risk “self-service without a metric catalogue” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “frame the problem” connects them in a testable scenario.

• Decision 1: object — master data and classifications; signal — one measure has multiple values; action — frame the problem.
• Decision 2: object — sources and transformations; signal — users cannot see where a number came from; action — identify the management object.
• Decision 3: object — data marts and semantic models; signal — master data changes without an owner; action — assemble data and constraints.

A practical decision model

The method is a sequence of decisions rather than a universal checklist. For sources and transformations, 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 master data and classifications, 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 “frame the problem”.

• At position 1, the action is “frame the problem”; its result is measures and thresholds.
• Stage 2: identify the management object. The working artefact describes errors, corrections and the quality log.
• Stage gate 3 connects the action “assemble data and constraints” with the result “master data and classifications”.
• 4. Action: assign roles and actions; verifiable result: sources and transformations.

Record lineage

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 sources and transformations.

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 “users cannot see where a number came from”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Object 5: Errors, corrections and the quality log. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Master data changes without an owner.
• Boundary 4. Object: Measures and thresholds. Define the source, frequency, permitted transformations and response to “users cannot see where a number came from”.
• Control record 3. Object: Data marts and semantic models. Observable signal: One measure has multiple values. Accountability: semantic owner and quality owner.

Process and data owners

Build the authority matrix around decisions concerning data marts and semantic models. 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 “frame the problem” concerning data marts and semantic models 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.

• Role: Business owner. Decision object: measures and thresholds; verified step: verify the outcome.
• Architect decides within errors, corrections and the quality log; the basis is prepared through “frame the problem”.
• For master data and classifications, the assigned role is Data owner; its control duty is to identify the management object.
• Project manager: authority is linked to sources and transformations, and participation is tied to “assemble data and constraints”.

Baseline and actual outcome

Verification of data marts and semantic models 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 “users cannot see where a number came from” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for master data and classifications.

• Control record 1: Master data and classifications; data version, calculation rule, expected change and actual outcome. Signal: One measure has multiple values.
• Criterion 2 uses sources and transformations; the result is compared with the baseline using one method. Signal: Users cannot see where a number came from.
• Criterion 3: Data marts and semantic models; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Master data changes without an owner.
• Criterion 4. Object: Measures and thresholds. Test fields: baseline, target change, source and owner. Signal: A dashboard does not lead to action.

Assumptions, stop signals and rollback

The risk map starts with two conditions: “self-service without a metric catalogue” and “a data owner without authority”. 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 “a data owner without authority” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• For the risk “one data mart without shared meaning”, assign the action “assign roles and actions” and evidence “master data and classifications” in advance.
• Risk review starts with the condition “measuring quality without a correction process”. The decision uses the action “verify the outcome” and data about sources and transformations.
• Risk record 3. Condition: Self-service without a metric catalogue. Control action: Frame the problem. Evidence source: Data marts and semantic models.
• Risk: Treating an anomaly as a proven fact. Control: identify the management object. Evidence: measures and thresholds.

Initial working cycle

The first session examines one real case involving master data and classifications. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “users cannot see where a number came from”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “frame the problem”; assign an additional test or stop condition to the risk “a data owner without authority”.

• At position 1, the action is “frame the problem”; its result is measures and thresholds.
• Stage 2: identify the management object. The working artefact describes errors, corrections and the quality log.
• Criterion 4. Object: Measures and thresholds. Test fields: baseline, target change, source and owner. Signal: A dashboard does not lead to action.
• 5. Acceptance object: errors, corrections and the quality log; compare the baseline sample, expected change and confirmed actuals. Test signal: Errors are corrected only manually.