A company makes data work when people can use trusted, appropriately governed evidence to improve a recurring decision. The objective is not to centralize every record or buy a fashionable platform. It is to connect business meaning, source ownership, quality, access, analysis and action in a service that survives change. Scope one valuable decision, prove the operating model and architecture, then expand reusable capabilities from evidence.
Use the data implementation checklist to manage delivery and the data FAQ to resolve common operating questions. The data and AI services guide explains how the foundation supports advanced use. This article focuses on scope, cost, risk and a staged plan that business, data and technology owners can jointly accept.
Start with a decision and measurable outcome
Write a decision statement: who decides what, how often, using which evidence and what action follows. A request for a customer 360 is too broad. A service agent deciding whether to escalate a delayed order within two minutes is testable. Record the current cycle time, error, loss, rework and user experience. Identify affected customers and staff. A data product is successful only when the decision or workflow improves within agreed guardrails.
Map the present path from source event to action. Find manual reconciliation, inaccessible definitions, duplicate extracts, delayed approvals and missing outcomes. Some problems need process repair, not a new warehouse. Prioritize uses by value, feasibility, consequence and reuse. Fund foundational work through the first few decisions that need it, while protecting shared capabilities from becoming one-off project code. An executive sponsor owns the outcome; a data leader cannot substitute for business authority.
| Scope element | Minimum evidence | Warning sign |
|---|---|---|
| Decision | Owner, frequency, action and baseline | A dashboard with no changed action |
| Data | Sources, meaning, rights and quality thresholds | Available fields chosen before the question |
| Users | Roles, access and observed workflow | Generic persona or assumed adoption |
| Controls | Purpose, retention, security and challenge route | Governance deferred until scale |
| Value | Outcome, guardrail and evidence window | Benefits expressed only as data volume |
Create shared meaning and ownership
Define core entities, measures, dimensions, grain, units and effective dates. Revenue may mean booked, billed, recognized or collected value; customer may mean account, household, user or legal party. Publish definitions with an accountable business owner and examples. Link each analytical field to the source and transformation that produces it. Semantic consistency is a product that needs versioning, consultation and change notice, not a glossary exercise completed once.
Assign source owners, data product owners, stewards and consumers distinct responsibilities. Source owners protect capture and operational meaning. Product owners meet consumer service objectives. Stewards coordinate definitions and quality resolution. Consumers use data within approved purposes and report defects with context. The DCAM framework frames mature data management as strategy, operating model, architecture, quality, control and measurable evidence; use such capability models to diagnose gaps, not to launch every capability simultaneously.
Make data quality fit for the decision
Quality is contextual. The ISO/IEC 25012 model supplies characteristics such as accuracy, completeness, consistency, credibility and currentness. Translate relevant characteristics into tests at the decision's grain. An inventory decision may require quantity freshness within minutes and exact location identity, while a quarterly trend may tolerate delay but require historical comparability. Publish thresholds, observed results and what the product does when a threshold fails.
Place controls near creation and transformation. Validate identifiers and allowed values, reconcile totals, detect schema drift, quarantine suspect batches and expose freshness. Sample semantic accuracy against source evidence because syntactic tests cannot detect a plausible wrong value. Record defect impact, root cause, owner and recurrence. ISO's current data quality overview describes a path to quality; operationally, that means a continuing process, not a cleanup campaign before migration.
| Quality dimension | Example rule | Failure behavior |
|---|---|---|
| Completeness | Every shipped order has item, location and timestamp | Exclude affected period and alert owner |
| Accuracy | Sample quantities reconcile to system of record | Pause automated decision and investigate |
| Consistency | Currency and customer identity agree across sources | Route conflict to defined authority |
| Currentness | Feed lag remains below decision threshold | Show stale state and use fallback |
| Lineage | Output resolves to source snapshot and transformation | Withhold certification until trace restored |
Build a product-oriented data architecture
Separate systems of record, ingestion, governed storage, transformation, semantic access and decision interfaces. Use batch, streaming or replication according to latency and source constraints, not fashion. Define contracts for schema, meaning, freshness, quality, access and change. Central platforms should provide identity, policy, lineage, observability and cost controls. Domain products should publish useful, owned datasets or services without duplicating foundational infrastructure.
Preserve provenance from source snapshot through transformations to outputs. W3C's PROV-O provides interoperable concepts for entities, activities and agents that can inform a practical lineage model. Material reports and automated decisions should resolve to code, data and definition versions. Keep the implementation proportional: begin with table, pipeline and owner lineage for critical products, then deepen column or record detail where impact and investigation needs justify it.
Govern access, privacy and lifecycle
Inventory personal, confidential, regulated and licensed data. Record purpose, lawful or contractual basis, allowed users, regions, retention, downstream sharing and deletion. Minimize collection and derived attributes. The NIST Privacy Framework treats privacy as risk arising from data processing across a lifecycle, helping teams connect data use to consequences for people. Security protects data, but a secure use can still exceed an appropriate purpose.
Federate access through roles and attributes, approve high-risk uses, log material access and review privileges. Use masked or synthetic data for development where it meets the need. Apply retention and deletion through downstream copies, exports and model inputs, not only the source. Establish a request, correction and challenge route where appropriate. Governance should provide fast standard paths and explicit exceptions; opaque committees encourage uncontrolled extracts rather than responsible use.
Model the real cost and delivery risk
Cost includes source integration, platform consumption, licenses, networking, storage, transformation, catalog and quality tools, security, migration, training, support and business participation. Model cost drivers such as source count, data volume, change rate, retention, query demand and service objective. Include transition overlap and decommissioning. Estimate unit cost for a useful product or decision, not only infrastructure. A low storage price can hide expensive reconciliation and specialized support.
Major risks include unclear value, inconsistent meaning, poor source quality, privacy overreach, fragile pipelines, uncontrolled self-service, vendor lock-in and weak adoption. Treat each as a testable assumption with an owner. Preserve raw or authoritative evidence, use open export formats, version transformations and test recovery. Pilot with representative data and users. Stop or narrow when outcome evidence is weak; continuing because the platform has already been purchased compounds sunk cost.
Use a staged data delivery plan
In discovery, select the decision, baseline it, classify risk and profile sources. During foundation, establish identity, environments, contracts, lineage and minimum governance. Build one vertical product from source through user action. Validate quality, performance, accessibility, privacy, support and outcome with a bounded cohort. Scale reusable patterns only after the team can operate them. At each stage, define entry evidence, exit evidence, budget and a decision to proceed, revise or stop.
Adoption work belongs inside delivery. Observe whether users understand measures, trust freshness, challenge errors and change behavior. Provide definitions and quality state in the interface, not in a distant catalog alone. Track decision cycle, manual reconciliation, defect recurrence, eligible use, outcome and guardrails. Review products quarterly for ownership, demand, cost and continued purpose. Retire unused reports, pipelines and permissions so the data estate becomes clearer as it matures.
Practical example: improving order promise decisions
A distributor wants customer-service staff to give more reliable delivery promises. The team defines a decision made during a call: choose a date using current stock, allocated orders, supplier confirmations, carrier schedules and destination. Baseline measures include promise accuracy, call duration, manual checks and repeat contacts. Data owners agree on order, inventory and shipment identity, distinguish confirmed from estimated dates, and set freshness thresholds for each source.
A vertical product ingests the required records, reconciles inventory with operational totals, publishes lineage and exposes a service that returns the proposed date with source freshness and uncertainty. When the supplier feed is stale, the interface shows a bounded range and fallback procedure rather than an exact-looking answer. Access is limited by role and customer relationship. Call recordings and personal data follow approved purpose and retention, while outcome dates return without exposing unnecessary customer attributes.
The pilot covers representatives, locations and order exceptions rather than only normal stock. After six weeks, the company compares promise accuracy, call time, repeat contact, overrides, stale-feed incidents and cost per decision. One carrier mapping causes recurring errors, so the source contract and validation are repaired. Only then does the team generalize identity, quality and lineage patterns for other decisions. Shared capability grows from proven reuse, while the original service remains owned and measurable.
Key takeaways
- Anchor the program in one owned, measurable decision.
- Treat definitions, ownership and quality thresholds as product contracts.
- Preserve lineage across sources, transformations and outputs.
- Govern purpose, access, privacy, retention and correction across copies.
- Model people and operating effort alongside technology cost.
- Scale from outcome evidence and retire data products that no longer earn support.
Frequently asked questions
Should a company choose a data platform before use cases?
Usually no. Establish representative decisions and nonfunctional needs first, then evaluate architecture and products against them. Some foundational procurement may precede delivery, but it should remain bounded by evidence rather than an assumed enterprise end state.
Who owns enterprise data?
Ownership is distributed. Business authorities own meaning and acceptable use, source teams own capture, data product teams own service quality, and security or privacy functions set relevant controls. A named executive owns the overall outcome and conflicts need an escalation path.
Conclusion
A company makes data work by connecting a valuable decision to trusted meaning, observable quality and accountable use. Deliver one end-to-end product, learn from users and outcomes, and invest in reusable controls where they remove recurring friction. The result is not more data. It is a dependable capability to decide, act and improve with evidence.