Data Strategy

There is almost always enough data. Little of it gets used. Each department builds its own analyses, there are several platforms with no visible common line, and AI projects stay experiments. A new data warehouse or an AI assistant does not fix that if the foundations are missing.

A data strategy creates those foundations. We develop it with the business teams from business goals and concrete use cases. What you end up with is not a thick concept paper but a target state and a prioritized roadmap that can be turned into projects.

Every data strategy comes down to five questions. What do we need data for? Which data, in what quality and how current? How do we provide it? Who is responsible for what? And in what order do we proceed? A strategy does not have to answer more than that, but it has to answer all five. The operational side, meaning rules, quality checks and the data catalog, belongs to data governance and is worked out there. Here the subject is direction and sequence.

Look honestly first

The starting point is the current state: systems and their data flows, existing reports and who uses them, platforms and the people who work with them. The conversations with the business teams matter at least as much. Where does data cost time, where is it missing, where do people not trust the numbers?

The assessment yields a maturity level across dimensions such as data foundation, technology, organization, skills and usage. The overall score is less interesting than the comparison between dimensions. A modern platform helps little if nobody is responsible, and clear ownership helps little without a usable data foundation.

From business goal to sequence

We do not derive the target state from technology trends. The question is which decisions should be made better or faster in two to three years. That produces use cases such as unified revenue reporting, a sales forecast or automatic document processing, each with a short description of value, required data, people involved and prerequisites.

The roadmap puts these use cases in order. What counts is how strongly a case supports a business goal, whether the data exists and how much preparation it needs, and which foundations, such as a shared data model, benefit several initiatives at once. A roadmap with twenty equally ranked initiatives means none of them gets finished. A few clearly prioritized steps work better, including something visible early on. A first dashboard on verified numbers builds more support than a plan that only pays off after years.

Who looks after the data

Technology alone does not solve data problems. Someone has to stand behind a data domain from the business side, such as customer or finance data, and decide on definitions and access. That is the data owner. Day to day, a data steward looks after quality, descriptions and master data and answers questions. A central data team runs the platform and sets standards, and the business teams contribute their knowledge of what the data means. Roles that exist only on paper change nothing: a data owner without time and mandate moves little, and responsibility has to show up in tasks and targets.

Whether things lean central or decentralized depends on size and culture. In smaller companies, a central team with clearly named contacts in the business teams is often enough. In large organizations, business units can provide their data as data products, meaning datasets with a description, quality commitments and a responsible person. Data mesh extends that idea to the whole organization. We see it as an option, not a dogma, and take from it what fits the company.

Platform, skills and the basis for AI

The platform follows the target state, not the other way round. Companies that buy a platform first and look for use cases afterwards often end up with it unused. The choice depends on existing systems, data volume, data protection and hosting requirements, team skills and cost. Details of setup and operation belong in separate topics such as data warehouse or cloud data platform. In the strategy, the point is to justify the choice transparently and to accept dependencies on individual vendors knowingly.

Skills are at least as important. Who maintains the data model, who builds reports, who understands the business side? The strategy spells out what is built internally, what is bought in and what needs training.

Assistants, forecasts or document processing need data that is findable, clearly described, of sufficient quality and available with clear access rights. This is called AI-ready data. Where that basis is missing, AI projects stay experiments. Which use cases make sense for AI in the first place is for AI consulting to assess. The data strategy clarifies whether the foundation is there.

The EU Data Act as a framework

The EU Data Act has applied since September 12, 2025. Among other things, it regulates access to data generated by connected products and makes it easier to switch between cloud services. Whether and to what extent it affects a company depends on its role, for example as manufacturer, user or cloud customer. Obligations on the design of new connected products apply since September 2026, with further stages to follow. A Commission proposal, the Digital Omnibus, would change some rules but has not been adopted yet. The legal assessment is for legal counsel, and we help plan the technical and organizational implementation.

So the strategy does not end up in a drawer

A paper that describes technology but improves no decision will not be implemented. Neither does a strategy that is never adjusted: we recommend a fixed review, for example once a year. And without backing from management, data topics stay an IT matter.