As different systems roll out to use different data sets, a trend is emerging – that trend is using data in ways we never thought possible, in seeing trends across data sets and between solutions – things that we never imagined having relationships suddenly start to show relationships.
Sounds like a dream come true – our hard-fought battles with SQL Server, data storage, data management and providing real information from the data is beginning to become a reality. This is all good news.
You know, of course, there is a “but…” coming –
What happens with your data agreements and transparency documents (privacy, data use, even those that are “data processor” and “data consumer” style agreements) when you start to use information in new and different ways? Are you still covered and “allowed” to do this?
In one case, this resulted in reporting being provided to the customer’s customer – they created new reports that provided additional and new insights to the users of the information and it tripped review. We needed to see how information was controlled and used *down the line* from the people generating the analysis that didn’t used to exist. We had to make sure we had both permission to use it, or at the very least transparency on that use, and the functionality to protect that information at the leaf-node user. Messy… at best.
The initial thought is to make the data agreements so broad that you’re covered “we’ll use it as we see fit” was sort of a mantra. But it doesn’t really work that well when you’re honestly trying to be transparent and clear about how information will be used. At the same time, it’s unreasonable to be able to foresee all of the uses of the that information, particularly when you are able to combine information bits over time and gain greater knowledge on the whole.
So what do you do?
In talking with people whose data was at the heart of all of this (the data owners) we found that providing a general summary of the information gathering goals, then a listing of the data collected, we offered transparency and completeness of information. Of course, this can get really overwhelming if you’re collecting transactional- (or even iOT-) type data, but even then, it seemed better to show more, not less.
So, we erred on the side of generalization in the document and online agreements, then provided ways for the data owners to go in and see how information was used and what information had been gathered. This seems to work well and calm the worries of most data owners.
We’re still left with the downstream management of information. For example, if you’re combining a sales database for use in co-marketing with a partner, how do you control or account for that use of information by that partner? It’s not a matter of just dumping a bunch of stuff on them that you shouldn’t it can be called out, explained, etc. But you have no control over their use, really, and certainly not if they were using it internally for additional report and such.
This was a much more difficult issue to account for transparency-wise. The more the data is deployed, the more it’s difficult to control.
We settled a bit on anonymizing information the further out from the source the data went. So perhaps you’re co-marketing, but you can each mail to your independent lists using a bonded mail-house sharing only bits that can tie the accounts together, or even just an indicator that the customer originates in this co-marketing effort.
It impairs the reporting at a detail level, but still allows for pulling information into SQL Server, analyzing sources and uses and then figuring out what’s working and what’s not for your business.
The key thing is to make sure your transparency agreements support this up and down-stream and that you are thinking through all of the different elements you’re faced with managing. And if you’re not managing them, who is, how and whether that impacts you and the data owners.