How to Build a Data Strategy That Your Teams Will Use

Finance presents the quarter’s revenue. Sales presents a different figure. Both teams can explain their calculations, but nobody can agree on which number the AI pilot should use. The meeting ends with another reconciliation exercise rather than a decision.

A useful data strategy resolves that kind of friction. It connects business decisions with usable data and gives people the authority, skills and rules to act on it. The starting point isn’t a new platform. It’s deciding whose judgment needs to improve and what would help them make it.

The Five Parts of a Data Strategy at a Glance

A data strategy links the decisions a business needs to make with the data, platforms, people and rules required to make those decisions reliably. It’s an operating model, not just an architecture document.

The practical test is whether a team knows what evidence to use, who can resolve disagreements and what happens when that evidence isn’t reliable.

The five parts of a data strategy

These parts connect executive intent to everyday work. A vision without priorities won’t direct investment. A platform without ownership leaves engineers trying to settle business disagreements through technical choices.

The national context matters too. The Singapore Digital Economy Report recorded digital-economy value added of S$144.1 billion in 2025, equivalent to 19.3% of Singapore’s GDP. Leaders should treat dependable data as a business capability supporting growth and resilience, rather than a housekeeping item within IT.

The order matters. Set the vision, choose the use cases, establish platform requirements and agree on accountability. Build the roadmap last because it schedules decisions already made.

A working strategy should mean fewer reconciliation meetings, less duplicated spending and a credible route from pilot to production. The familiar failure is a platform-first budget with nobody accountable for changing the business outcome.

Start With a Vision Tied to Decisions, Not Technology

Becoming data-driven sounds reasonable in a board presentation. It doesn’t tell a department head what to stop doing, what to fund or which decision should change.

A useful business data strategy names the work. Credit approvals, claims handling, pricing, staffing and regulatory reporting are better starting points than an ambition to centralise everything.

Write the vision around operating decisions

1. List the decisions leaders make repeatedly: Start with five to seven important choices, especially those delayed by conflicting evidence or manual reconciliation. Keep the discussion about decisions, not desired dashboards.

2. Describe the missing evidence: For each decision, record who makes it, how often it happens and what information is missing, disputed or late. This separates a data problem from an unclear approval process.

3. Name the intended improvement: Write a short vision linking those decisions to decision time, error rate or cost to serve. Establish the baseline before promising a target.

Cross-functional usability deserves particular attention. Singapore findings published by SAP found that 58% of surveyed organisations lacked confidence in integrating and sharing data across business functions, while data-readiness problems were particularly acute in legal departments (80%), finance (73%) and HR (66%).

Consider a regional insurer where claims and underwriting define an active policy differently. Claims staff check eligibility manually because the underwriting extract includes policies awaiting payment confirmation. Moving both datasets into the same repository won’t settle that disagreement.

A useful vision would commit the insurer to reducing claims cycle time by giving assessors an agreed, current view of policy eligibility. The business owners would approve the definition, including how pending payments and reinstatements are handled.

Vision test: Can a department head repeat the vision and name a decision it changes?

A single source of truth can support that work, but it’s a poor end state by itself. Teams still need to know what the information means, when it’s reliable enough and who resolves exceptions.

Keep the vision short enough to use in prioritisation meetings. If it can justify every proposed investment equally well, it isn’t giving leaders enough direction.

How to Prioritise Use Cases by Value and Readiness

The most exciting idea in an executive meeting isn’t necessarily the best place to start. A high-value proposal can still be a poor immediate investment if the required data is inaccessible, unsuitable or nobody’s responsibility.

Readiness also differs across organisations. IMDA’s enterprise adoption figures show that AI adoption among Singapore SMEs rose from 14.5% in 2024 to 23.4% in 2025, while large local enterprises reached 70.4% adoption in 2025. Adoption alone, however, doesn’t establish whether a particular workflow is ready.

Assess the evidence before funding delivery

1. Inventory priority data domains and owners: Identify the customer, transaction, product or operational data each candidate needs. Give each domain a business owner who can settle questions about meaning and permitted use.

2. Profile the actual datasets: Check completeness, duplication, freshness, lineage and access controls. Inspect representative records rather than accepting a statement that the data exists.

3. Classify the data: Establish applicable privacy and regulatory requirements before designing the workflow. Resolve whether the intended use is permitted, including any third-party processing.

4. Rank value, risk and readiness together: Estimate the business benefit and record the assumptions behind it. Separate delivery effort from uncertainty about whether the evidence is usable.

5. Fund a route to live operation: Require an accountable owner, a measurable benefit and an agreed production operating model. A demonstration without support, monitoring or business adoption isn’t a complete proposal.

Don’t let a strong overall score conceal an unresolved permission issue. Treat lawful use and accountable ownership as entry conditions, then compare the eligible candidates.

Choose the deliverable, not just the idea

Say a bank proposes a fraud-alert model with substantial potential value, but its historical transactions lack reliable fraud labels. A collections forecast based on clean repayment records may offer a more credible first delivery. The fraud proposal stays on the backlog with explicit data-preparation work rather than an unrealistic launch promise.

For help framing the analytical problem, the practical distinction in data analytics consulting is between producing an insight and enabling someone to act on it.

Finish with a steering-group-approved scorecard. Record the chosen use case, rejected alternatives, unresolved assumptions and conditions for reconsideration. That gives delivery teams a decision they can execute rather than another list to interpret.

Choosing a Platform Without Overbuying

Platforms get overbought because they’re visible, demonstrable and easy to put into a budget line. Operating changes are harder to price, so leadership teams can end up buying infrastructure before agreeing what it must support.

Choose after prioritising use cases. Those use cases establish the data types, volumes, processing speed and access patterns you need. A daily management report and an operational decision requiring immediate updates shouldn’t automatically receive the same architecture.

Common data platform patterns compared

Data mesh is an ownership approach, not a storage product. It can use warehouse or lakehouse technology underneath. Don’t choose it because decentralisation sounds attractive if business domains aren’t prepared to maintain dependable data products.

The data lake versus data warehouse comparison helps frame storage choices, but the buying decision should include operational effort, not just feature coverage.

Singapore adds a practical infrastructure check. According to the Ministry of Digital Development and Information, data centres consumed approximately 6.5 terawatt-hours of electricity in 2024, slightly more than 10% of Singapore’s total electricity consumption. Include hosting location, available capacity, energy efficiency, resilience and compliance alongside cost.

Ask before signing

• Immediate need: Which prioritised use cases require this platform during the first year?

• Exit route: How would you export data, definitions and processing logic if you moved?

• Operational ownership: Which internal team will run it after the implementation partner leaves?

Request evidence using a representative workload. Include ingestion, quality checks, access restrictions and recovery from a failed pipeline. A polished demonstration of the reporting interface won’t show whether your team can operate the whole service.

Building Ownership, Skills and Governance That Hold

At Ekipa, we believe the technology is the easy part of AI adoption. Getting an organisation to work differently is harder, particularly when sharing data means changing established decision rights.

A governance policy won’t solve that by itself. People need practical responsibilities, usable controls and enough time to learn the new routines.

Build accountability into daily work

1. Name a business data owner for each priority domain: Choose someone with authority to decide permitted uses and resolve competing requirements. Don’t give the title to an engineer who can maintain the database but can’t settle a business dispute.

2. Appoint data stewards close to the work: Stewards maintain shared definitions and agree quality thresholds with users. For example, they should specify which missing fields prevent a claims record from being used, rather than labelling the entire dataset poor quality.

3. Keep the central data office focused: Use it for common standards, reusable controls and enabling tools. If it must approve every routine request, teams will either queue indefinitely or create workarounds.

4. Make AI-use rules practical: Specify approved data classes, permitted tools, human review, logging and escalation. Provide an exception route so a reasonable experiment doesn’t require an informal workaround.

5. Teach people through their actual tasks: Managers need to question evidence and recognise limitations. Analysts and product owners need hands-on practice checking datasets, interpreting outputs and handling exceptions.

The MAS consultation paper on AI risk management proposes applying existing data-management standards to AI data, with additional safeguards where necessary, including data ownership, access controls and intellectual-property rights. It also proposes basic AI-use policies for financial institutions calibrated to their adoption level. Treat this as a proposed framework, not a blanket statement of binding requirements.

Make the approved route usable

For a practical starting structure, guidance on choosing a practical data governance framework can support the discussion about responsibilities and controls. Translate the resulting framework into request forms, approval rules and escalation routes that staff can use.

Make the safe route easier to follow than the unofficial one.

Don’t assume employees will avoid unapproved AI because a policy prohibits it. Give them an accessible approved environment, examples of acceptable use and a clear answer when they’re unsure.

Measure learning through applied work. Ask a manager to challenge an unreliable output or an analyst to trace a disputed metric. Course attendance alone won’t tell you whether either can do the job.

Turning the Strategy Into a 90-Day Roadmap

An approved plan isn’t a running team. Roadmaps stall when nobody decides what happens at the start: who gets access, who supplies the source records and who can resolve a disagreement.

The roadmap should therefore schedule deliverables and acceptance decisions, not just activities. Governance and benefits reviews belong inside the delivery windows rather than at the end.

The Singapore Business Federation’s 2025 survey found that 43% of businesses cited data privacy and security as a technology-adoption concern, and 32% cited data quality and accuracy. Address those concerns before people rely on the output.

Set milestones with pass checks

Mobilise with a usable charter. Document the decision being improved, intended users, source systems, quality expectations and accountable business and technical owners. Record the existing service or financial baseline so later claims of improvement can be checked.

At the initial review, confirm scope and permissions. If access remains unresolved, change the plan rather than recording delivery as on track.

Build only what the pilot needs

During the build window, implement the minimum dependable pipeline and its controls. Capture metadata, enforce retention and access rules, and preserve lineage so someone can trace an output to its source.

Test analytics or model outputs against agreed quality criteria and, where relevant, fairness criteria. Include missing records, stale inputs and unusual cases, not just normal examples. A structured data-readiness assessment can help expose these gaps before release.

Release with a named operator. In the delivery window, run a monitored pilot with trained users, incident ownership and a fallback process. Review realised benefits against the baseline at the scheduled gates, distinguishing measured outcomes from forecasts.

A successful review asks whether trusted datasets are in production, controls are followed, and business teams use the output. It also checks verified financial or service results. Dashboard counts and proofs of concept don’t answer those questions.

Frequently Asked Questions About Data Strategy

How is a data strategy different from a data governance policy?

A data strategy connects business decisions to the data, platforms, people and rules needed to make them. Governance is part of that strategy, covering ownership, definitions and controls. A governance policy alone won’t establish which business opportunities deserve investment.

Who should own the data strategy?

An executive sponsor sets direction and resolves cross-functional conflicts. Business owners hold decision rights over their domains, while the head of data and technology leads platform delivery. Avoid giving everyone joint accountability without naming who makes the final call.

How long does it take to build one?

A focused first version can be drafted in a few weeks when decision-makers and source information are available. Treat that as a planning expectation, not a guaranteed delivery time. The strategy only proves useful when a team applies it to live work and operates the result.

Do smaller companies need a full data strategy?

They need clear choices, not a large document. Start with a one-page version tied to two or three important decisions, named owners and a bounded pilot. Add detail when coordination, risk or operational complexity requires it.

Where should a team start if its data is messy?

Start with the decision that matters most, then inspect the data it requires. Correct the defects that prevent that decision from being made safely. An organisation-wide clean-up can consume the budget before users receive anything useful.

Choose Your First Use Case This Quarter

Over the next two weeks, take the highest-scoring eligible use case and test whether someone can start it without another strategy meeting. Bring the business owner and delivery lead together around the actual records and workflow.

Use these checks:

• Chosen use case: Can the team explain why this candidate outranks the alternatives?

• Accountable owner: Has someone accepted responsibility for the data and the business outcome?

• Usable evidence: Is the required data current, traceable and permitted for the intended use?

• Changed decision: Can the intended user explain what they’ll do differently with the result?

If an answer is missing, that gap is the starting point. Buying a platform won’t establish a missing decision right or resolve an undefined business benefit.

Leadership teams can find this difficult because the same people maintaining daily operations must also redesign them. Protect time for those decisions and make the unresolved issues visible rather than leaving delivery teams to negotiate them informally.

Ekipa’s AI Use-Case Discovery Workshop helps teams identify and prioritise where AI is worth pursuing. Our approach pairs coaches who change how teams work with embedded experts who build AI and data alongside them, then hands both over so the client’s teams can run them independently.

Bring a draft scorecard to a conversation with the team. It doesn’t need to be polished, just specific enough to discuss the decision, evidence and obstacles.

The strategy is finished when a team can make a different decision next week.

Ekipa helps connect data readiness, governance and delivery with the way your teams work. Visit Ekipa to talk through your use-case scorecard and identify a practical starting point for your data strategy.