The Universal Facts About How Data Responsibilities Work, In All Organisations – Part 4 of 5
In Part 3, I introduced the concepts of Process Owners, Data Producers and Data Consumers; and explained how all these roles build on the same basic foundations of data responsibilities. In part 4, I explain why data ownership is still needed once these other roles are in place and how Data Owners depend on the other roles to be really effective in fulfilling their obligations.
Please read my Disclaimer by clicking here.
As a result, one of the critical things that most data management initiatives tackle is cross-system and cross-process alignment, consistency and harmonisation. Whilst good data management practices are absolutely critical at an individual system and individual process level too, the most common need for "data ownership" is found in the need for common data rules and data governance across multiple systems.
As such, a "Data Owner" is usually established to address this point.
Depending on the data management model that you are following, there are two types of “Data Owner”.
The first type of Data Owner is the owner of a particular “data set”. This owner is accountable for the content in a data set, for example the official master records of a set of customers, held in a master data source. The responsibilities of this type of Data Owner very clearly follows the responsibilities described in previous posts; however, their responsibilities can be enhanced in relation to governance of the use of their data, with powers to both establish “data sharing agreements” before any data consumers can access the data that they own, and with enforcement powers to remove access and escalate where they find that their data is being mis-used.
In some organisations, the owner of a data set may also be the owner of the system that contains the data and the processes that capture and use the data. Following the lines of responsibilities lined out in this series of posts, it is usually quite straightforward to work out who this person is and it is usually this person who will most care about the way in which the data is handled, because they are often responsible for both the value driven in the use of the data and the consequences if something were to go wrong with it.
The second type of Data Owner is often referred to as a “Data Domain Owner”, and is responsible for setting the common rules that are followed for a particular set of data that they are responsible for, and for running the governance arrangements that oversee conformance to those rules.
For example, a Data Domain Owner may be appointed for the "Customer" data domain, with responsibility for setting the rules for how Customer data is captured and processed; and then for engaging with the relevant Business System Owners, Process Owners and organisational leaders to ensure that data is only captured and processed in accordance with the standard rules.
As a result, a "Data Domain Owner" can only be directly responsible for data that is created by them or their teams; so in most cases, a "Data Domain Owner" is reliant on other individuals in roles across the organisations to fulfil their obligations, which further explains the importance of establishing the other data responsibilities and system ownership roles.
In some cases, where an authoritative, master source of data has been established, the “Data Set Owner” for the data in the master source may also be appointed as the “Data Domain Owner” for that data as it exists across the organisation, which can significantly increase the empowerment of the individual to drive consistent data management practices for the data that they “own”. For example, the Customer data managed in a Master Data Management platform may be assigned to someone as both Data Set Owner and Data Domain Owner for Customer data. This means that they are both able to directly control the data within the platform (within the bounds of the data responsibilities explained in previous parts of this series of posts) and may also set the wider rules and governance for Customer data as it is captured, stored and processed elsewhere across their organisation.
At this point, you will see why it's easy for data management responsibilities to appear to be quite jargon-heaving and complicated, but it really isn't. If you keep going back to the basic concepts of responsibilities that were introduced in the first few posts of this series, the same principles apply. No matter what role you are fulfilling, you can be responsible for data when it's in your possession but not when it's not. You can be responsible for governance of data that others use, but your empowerment will be dependent on other roles and structures in your organisation to enable you to discharge your governance responsibilities effectively.
Please read my Disclaimer by clicking here.
Why do you need data ownership, when you've established all these other responsibilities and things?
Whilst everything I've explained in the past 3 posts is useful and important to manage data effectively, in most organisations, especially large ones, the problems encountered with data are not found at an individual system or process level. Instead, they manifest themselves in inconsistencies across multiple systems; or in the misuse of data in scenarios that the data was not originally captured for. For example, if the same data in three systems, is captured in different ways (for example using different formats and structures), when they feed into a central system, they will clash and cause all kinds of operational and analytical issues. Likewise, if data is captured for one purpose and then used for something totally different, it could not only result in the wrong outcomes but could also be directly breaking several laws and regulations at the same time!As a result, one of the critical things that most data management initiatives tackle is cross-system and cross-process alignment, consistency and harmonisation. Whilst good data management practices are absolutely critical at an individual system and individual process level too, the most common need for "data ownership" is found in the need for common data rules and data governance across multiple systems.
As such, a "Data Owner" is usually established to address this point.
Depending on the data management model that you are following, there are two types of “Data Owner”.
The first type of Data Owner is the owner of a particular “data set”. This owner is accountable for the content in a data set, for example the official master records of a set of customers, held in a master data source. The responsibilities of this type of Data Owner very clearly follows the responsibilities described in previous posts; however, their responsibilities can be enhanced in relation to governance of the use of their data, with powers to both establish “data sharing agreements” before any data consumers can access the data that they own, and with enforcement powers to remove access and escalate where they find that their data is being mis-used.
In some organisations, the owner of a data set may also be the owner of the system that contains the data and the processes that capture and use the data. Following the lines of responsibilities lined out in this series of posts, it is usually quite straightforward to work out who this person is and it is usually this person who will most care about the way in which the data is handled, because they are often responsible for both the value driven in the use of the data and the consequences if something were to go wrong with it.
The second type of Data Owner is often referred to as a “Data Domain Owner”, and is responsible for setting the common rules that are followed for a particular set of data that they are responsible for, and for running the governance arrangements that oversee conformance to those rules.
For example, a Data Domain Owner may be appointed for the "Customer" data domain, with responsibility for setting the rules for how Customer data is captured and processed; and then for engaging with the relevant Business System Owners, Process Owners and organisational leaders to ensure that data is only captured and processed in accordance with the standard rules.
As a result, a "Data Domain Owner" can only be directly responsible for data that is created by them or their teams; so in most cases, a "Data Domain Owner" is reliant on other individuals in roles across the organisations to fulfil their obligations, which further explains the importance of establishing the other data responsibilities and system ownership roles.
In some cases, where an authoritative, master source of data has been established, the “Data Set Owner” for the data in the master source may also be appointed as the “Data Domain Owner” for that data as it exists across the organisation, which can significantly increase the empowerment of the individual to drive consistent data management practices for the data that they “own”. For example, the Customer data managed in a Master Data Management platform may be assigned to someone as both Data Set Owner and Data Domain Owner for Customer data. This means that they are both able to directly control the data within the platform (within the bounds of the data responsibilities explained in previous parts of this series of posts) and may also set the wider rules and governance for Customer data as it is captured, stored and processed elsewhere across their organisation.
At this point, you will see why it's easy for data management responsibilities to appear to be quite jargon-heaving and complicated, but it really isn't. If you keep going back to the basic concepts of responsibilities that were introduced in the first few posts of this series, the same principles apply. No matter what role you are fulfilling, you can be responsible for data when it's in your possession but not when it's not. You can be responsible for governance of data that others use, but your empowerment will be dependent on other roles and structures in your organisation to enable you to discharge your governance responsibilities effectively.
Comments
Post a Comment