Data Stewardship Council – how to get a handle on dynamic data structures

If you go into a company as an outsider, point at a system at random and ask what information is stored there, where it comes from and what it's used for, you'll initially get general answers, but with more in-depth questions you'll quickly get a shrug and, in the end, perhaps a referral to a specialist who might be able to look into it.

If you ask about certain fields in specialist systems, the question quickly arises: "Why do we actually still need that?", often followed by "I don't know what happens if you delete that field...", and so, day after day, valuable time is invested entering, checking and correcting information whose purpose is, at the very least, questionable.

Even if such information plays an important role in other processes: if the employee responsible doesn't know the context, they can neither judge the necessary level of care nor make an informed decision in cases where entries fall outside the norm or into a grey area. Over time, data quality suffers as a result.

Another scenario that's easy to picture: how many employees in your organisation, for example, know the inner workings and the data exchanged between ERP and inventory management well enough to assess interfaces from a specialist perspective or to provide the content requirements for updates and extensions? And when will that employee (experience shows it's rarely more than one person who has detailed knowledge of more than one system and the processes between them) leave the company?

Looking at the challenge from the other side: how much optimisation and innovation potential could your organisation unlock if the various business areas could benefit from one another's knowledge and information, if employees worked together to generate new knowledge and new ideas from data? If processes could benefit from information being deliberately and purposefully generated, captured and maintained for the

Next steps, with their priorities known throughout the organisation, so that work on them can be aligned by time-based and economic relevance?

As a rule, oversight of data and systems is assigned to an (external or internal) IT department, whose staff, beyond a certain size and complexity, split responsibility for the systems they look after. However, a central idea of the Data Stewardship Council is to network the information and knowledge of the specialist departments with one another. It is therefore not a technical or IT committee, even though it can make valuable contributions to any IT initiative. As Data Stewards for a Data Stewardship Council, you should select operational employees from the various departments and (in the case of complex departments with a wide range of different tasks) teams who are committed and motivated to communicate with other departments and move the organisation forward as a whole. Executives or managers tend to be less suitable for this, as the necessary distance from operational matters that comes with a management role often means the details slip out of view, and because the level of company politics frequently colours direct, open exchange. On the other hand, the position of Data Steward can often be a good career springboard, on which (similar to an assistant role) communicative and strategic leadership qualities can be acquired and deepened in a protected space. What's important in the context of a customer-centric strategic orientation is to consider, at the very least, all departments that are in direct contact with customers, as well as those that supply them with information (such as product management and creative departments). It's also a good idea to have representatives from controlling on board to support subsequent evaluation from various angles. In addition, many people working in controlling have a good instinct for generating knowledge from data. When specific systems are being discussed, it's helpful if the Data Stewardship Council has access to the relevant system administrators as technical experts, though they should be consulted selectively and thus form an additional, independent dimension for optimisation and innovation, so as not to discard ideas but to factor in aspects of technical feasibility afterwards. For the council's standing and effectiveness, it's important that a sponsor from the management level supports the Data Stewards and ensures alignment with corporate objectives. A CDO, for example, would be a good fit for this; senior staff from one of the administrative departments who are well networked with management can also be a good choice. When selecting the sponsor, it's important to avoid one-sided interests or conflicts of interest.

A Data Stewardship Council should meet regularly at a fixed date to work together on data networking. A fixed recurring schedule helps with planning and drawing a line against operational demands. Following a kick-off – in which the Council constitutes itself as a team, defines its working methods and initial priorities, and for which two to three hours should be allowed – the regular meeting should, in our experience, last between half an hour and an hour. Where there are many different business areas, specific "interim cycles" can be introduced, in which selected parts of the Council deal with defined sub-areas and tasks but they should come together at least once a month for a full session with the other Council members to present partial results and align with one another – ideally with the sponsor present. The goals and tasks of the Data Stewardship Council are primarily derived from the company's business objectives. In the initial goal-setting phase, the sponsor should support wherever possible, though over time a well-functioning team can be released into autonomous task definition. The sponsor should be aware of their role as a supporter, not as the leader of the Council. As a rule, the first steps – even with adequate system and process documentation – will tend to be exploratory in nature. Working on a virtual board, where the current status is recorded and remains available for the next meeting, is a good approach here. If a fixed room is available where results remain securely and accessibly stored, then hands-on work, for example on a Metaplan wall, is also a good option. To avoid losing track, the status quo is best captured by data clusters such as "customer data", "product data", "order data", "logistics data" etc., which can additionally be split into master, transactional and control data. Here, one can work through the various affected processes, formulating them system-independently using, for example, approaches from Domain Driven Design. The aim is to match the relevant information supply with information demand: on one side, the data steward of the area supplying data offers this data on the board, while on the other, the data steward of the area requesting data sets these requests against the supply. A user-story-like structure borrowed from the agile world is helpful here:

• As [department], I am providing you with [information/date] from [source], or.

• As [department], I need [information/date] to achieve [goal].

In this form, you quickly gain an overview of missing or (initially, for those involved) superfluous information.

The relevant information can then be prioritised within the process according to importance and time factors, enriched with meta-information (such as the system and format used) and documented. It often becomes apparent at which points structured information such as selection lists, rather than plain text, would be more suitable, in order to simplify downstream processes.

An often helpful ground rule is that the requester defines the type, form and scope of the information, while the provider, in turn, has a right of veto regarding availability and operational effort.

It is advisable to create a (data) glossary from the results, additionally recording what is meant by a given piece of information, what purposes it serves and, where such cases exist, under what alternative names the information is used in other systems or contexts. This makes it possible to quickly determine where the same information is potentially still being maintained, needed or processed elsewhere. Such a glossary is also a valuable asset for onboarding new employees.

The best time was yesterday, but today is still a day too

Setting up a Data Stewardship Council makes sense whenever information on data points needs to be gathered anyway as part of a data-driven digitalisation project, be it for a CRM, PIM, DAM, ERP or marketing automation project. Even as a preliminary project to align user experience, for example when revamping a shop frontend or setting up service portals or apps, the cross-departmental development of data will need to be discussed. Such situations can be a good opportunity to get started with data stewardship, initially limiting its scope and members to a relevant subset of business areas. When later expanding, the existing project-based Council can then contribute its experience and best practices, together with the results already developed, and quickly onboard new members.

A similar approach is also useful for preparing similarly structured projects that are on the strategic agenda in the medium term, and with well-documented baseline data, potential providers can be supported not only during implementation but already during the proposal and conception phase, defining necessary interfaces and establishing data flows.

Another good occasion is an upcoming organisational restructuring, where the focus will then tend to lie more on retaining corporate knowledge and securing information availability.

But even where none of these occasions specifically applies – maintaining, reviewing and expanding business knowledge is in the strategic interest of every organisation and secures its ability to function.

It is no coincidence that we live in the so-called information age. The availability of data shapes everyday life, and the sheer volume of data points often obscures the bigger picture. A fixed body that develops and maintains this overview can not only support and optimise business processes, it can also be a driver of innovation, since it can assess where information can be brought together, whether all the data needed for a new service already exists or, if not, what is missing and who could most efficiently provide it.

At the same time, such an institution solves two central problems for the organisation: the formation of bottlenecks around key individuals who are constantly burdened by enquiries only they can answer, and the problem of lost business knowledge when one of these knowledge holders leaves or is unavailable.

Setting up a Data Stewardship Council promotes transparency within the organisation and, through the continuous maintenance and expansion of business knowledge, supports not only future readiness. The exchange between the various represented areas also fosters collaboration and creativity at the operational level. Its members can be groomed for leadership tasks, and they contribute to the organisation's organic growth through increased satisfaction, value-creating new tasks, the elimination of inefficiencies and a developing team culture.