- SAP Managed Tags:
I was recently exchanging thoughts and ideas on Governance, Risk, and Compliance (GRC) topics with one of my previous colleagues from SAP GRC Solution Management and a good friend – Jan Gardiner, when she mentioned a terminology that I wasn’t familiar with: “Data Debt”. But I am familiar with the concept – like most of you I am sure.
In essence, data debt is a form of technical debt that is usually driven by short term focus, and it consists in the additional effort required by leveraging an easier trade-off (i.e.: “quick fix”) compared to a potentially more complex one that would initially have taken more effort or resources.
If you have been part of an initiative to automate any business process, then chances are that you have been confronted to this issue!
How Does This Apply to Governance, Risk and Compliance?
Instead of starting fresh and to invest time in creating a new set of sound data – clean and accurate, it is tempting to re-use previous data that has been used for quite some time as a kick-starter.
For instance, you are tooling your previously manual risk management process and have 2 options:
Option 1. Start from the risk management framework and progressively have each unit in, scope document their risks from the risk categories, and perform an assessment – which can be quite time consuming and require that you explain and assist in the creation of the risks instances;
OR
Option 2. Upload the legacy Excel sheet with all the previous risks instances and their assessments. From there, you can ask units to review the documentation and adapt if necessary.
Option 2 might sound like the most appealing one since it’s always easier to start from a base than from a white page and it would also mean the project would be live much quicker.
But there are downsides: how certain are you that the data input over the years is accurate and reliable? One of the major issues of Office tools is that data may have been altered over time, hence impacting its credibility.
If you are spearheading such initiative, wouldn’t you want to trust the information in the brand new system – especially if it is then used for decision making or for compliance reporting?
How to Avoid This Pitfall?
Unfortunately, and contrarily to more typical forms of “debts”, you can’t simply put paying it off. Even in instalments.
Nevertheless, if the company has decided to investigate the usage of a software tool for its GRC process, then there is already a high likelihood that it is sensitized to the notion of “technology debt” and that, instead of adding more columns or macros to its Excel file, it decided for a more sustainable solution.
If so, then one of the final objectives of the initiative must be to enable executives to get access to information – not just data. Hence meaningful contexts that meets data quality standards and can be trusted. Especially in our area of Intelligent Enterprises – companies that apply advanced technologies and best practices within agile, integrated business processes to run at their best.
As a result, one of the options when creating the business case for a new GRC solutions could be to include a provision with 2 scenarios:
- Scenario 1: estimate of effort required to collect, review (ie: clean) and import legacy data - which includes liaising with the owners of this data to ensure it's applicability
- Scenario 2: estimate of effort required to start from fresh - which also includes reaching to stakeholders, but this time to ensure that their scope is represented in the new framework
An Additional Benefit: It Will Prevent Hidden Data Repository
In case the facts that data debt results in increased efforts in manually managing increasingly complex files and creates blind spots for the organization sometimes leading to hazardous decisions is not enough, there are also the occasional hidden data repositories created here and there that you can add to the “cons” side of the balance.
Because they can’t access the data in the fashion they need – or because they want to add/modify some of it to their liking, many people decide to create their own data repositories by downloading an extract and putting it on a shared drive.
These repositories are then no longer correlated to the original data source and have a life of their own with most often outdated and no longer reliable data. This adds to the data debt of course. And imagine these “hidden data repositories” then start being used by executives to steer the business?
By creating trustworthy sources and better controlling the outputs, companies can reduce the risk of these siloed repositories and restore confidence in the integrity and reliability of the information…. Provided they also implement a data management process to ensure data quality over time so as not to be confronted by the same issue in the future!
As you can read, this could apply to any process of course. But I have to admit that I have seen it very prevalent in GRC. Maybe because many companies are still using Office tools for this purpose?
What about you, how does your company manage its GRC data debt? I look forward to reading your thoughts and comments either on this blog or on Twitter @TFrenehard
