Helen's heating and cooling business has plenty of data, but it lacked a shared model for managing it. Business Development Manager Vera Borodulin talks about the project that set out to turn scattered data responsibilities into a defined data governance model.
Where did data governance stand before the project?
The starting point will sound familiar to many organisations. There was a lot of data, but no systematic way of managing it. Data ownership roles existed on paper, but in practice no one was sure what they involved. Data governance was treated as a systems issue rather than a business one.
"We had data ownership roles, but the actual responsibility behind them was unclear," Borodulin says. "Data governance was more about systems than part of how we steer the business."
What was it like working with Data Design?
Borodulin describes the collaboration as smooth and focused on moving forward. The project ran to plan, and the first workshops set a way of working she could trust. The most concrete value was that it got the heating and cooling business moving.
"If we had tried to push this forward on our own, progress would probably have been slower and more difficult," Borodulin says. "Working with Data Design gave us a good start. Now we have a solid foundation to build on."
What did you learn along the way?
The biggest shift was in thinking. Data governance is not a systems question but a management question, and roles and responsibilities are what hold the model together.
"Data isn't just a systems matter. It's a tool for running the business. Clear roles and responsibilities are critical. Without them the model can't work and data management can't be systematic."
Two more lessons followed from this. Governance can't be handed to IT or to a small group of data specialists; the capability has to live across the business. And data and business processes are not separate worlds. The link between them has to be modelled deliberately, not assumed.
What actually changed?
The heating and cooling business now has a defined data governance model. Roles and responsibilities are described. Data that used to be one unstructured whole is split into data groups, which lets people discuss data in business terms.
The team also has a working view of who the potential data owners and data stewards are within each group. The link between data and business processes is in place. It isn't fully built yet, but data and processes are no longer separate worlds.
"We now have a described and defined model," Borodulin says. "Specific responsibilities and roles, and a structure for how the data as a whole could be managed going forward."
What happens next?
The next step is rollout through pilots. Alongside that, the data owners and data stewards the model needs will be named and onboarded. This year's goal is to move from a defined model to active practice, and to hand ownership of the model to the line organisation.
"This year, the goal is to move from having a model to actually using it."
What kind of organisation is this kind of project for?
According to Borodulin, it creates the most value where there is a lot of data, many systems and silos, and data responsibilities are unclear enough that the confusion shows up in daily work.
"I think quite a few organisations will recognise this situation," she says.
What would you tell someone planning a similar project?
Defining the model is an important milestone, but only a milestone. Rollout is a job of its own. Who takes part matters just as much. This is not purely a business project, nor an IT project, and the right people are often spread across the organisation.
"It's worth bringing in outside sparring and expertise at the start, so it's easier to get going. Just as important is securing the business's commitment from the beginning, so the whole thing doesn't end up resting only on IT and data people."
