It's a key outcome of any system inventory, data map, system map, etc.: who owns a particular system or information store? Let me start by saying it's rarely IT - they provision, support, maintain, upgrade, update, and eventually decommission systems. But they don't own them - rather, they are custodians for them on behalf of the organization generally and the business process the system supports.
In other words, it's generally the business process owner that owns a given system. Sales owns the sales forecasting system. Marketing owns the marketing automation system. IT *does* own the help desk ticket system. For systems that are generally enterprise-wide, like email, an argument can be made that IT should be considered their owners, but I believe that in this case the owner is either the CIO or another member of executive management - perhaps even the CEO.
But organizations change. Systems get consolidated across multiple departments. Business units and work processes get reorganized, and merged, and split apart. This can lead to systems, and the information they hold, being orphaned, without a defined owner. If the result of the reorganization is that a system is decommissioned, and its data dealt with appropriately according to existing information and data governance policies, this isn't an issue. However, it's quite common when doing an inventory to find folders, applications, and entire systems where no owner can be identified. So what is to be done with them?
There are a couple of ways to track down the ownership of an ostensibly orphaned or abandoned information store.
Ask someone. It's pretty unusual for a system, and the information it stores, to be completely unknown to anyone in the organization. If the system isn't decades out of date, you may still have someone on staff who remembers the system and its purpose. Then you can assign ownership to whoever owns that function today. If the function has been completely done away with (not just renamed), you may need to go to legal to explain the circumstances and figure out the right way to proceed.
Ask IT, records management, and legal. IT should know about all the systems that are or were on their network or that they supported. Records management should have a records and information management inventory that identifies systems that could potentially generate or store records. Legal may have a data map from previous litigation. All of these could provide valuable clues about a particular system or information store, especially if any of these groups keeps previous versions.
Examine the system. Databases have database definitions, and data dictionaries, and can probably be queried by a competent database analyst to determine what data they hold. For unstructured systems, such as abandoned network file shares and folders, someone with appropriate access rights can review the contents of those information stores to at least get a sense of what they deal with. For an abandoned email inbox, it may be as simple as drafting a new email and seeing what comes up in the signature block. Again, if the function persists, the system can be assigned to that function; if not, check with legal.
Run a report. Most repositories and databases have audit logs that track things like date last accessed and who accessed them. There are dozens of tools that can do this for networked file shares as well. These can provide valuable insight into potential ownership. And if nobody has accessed that data or that system for 5, 7, 10+ years? Great point to make to legal.
Do some research. This approach assumes that, not only can you not find an owner, but you can't even determine what the system is - think legacy, deprecated applications, old databases, or unknown file formats. Do your due diligence - there are tools online that can potentially identify unknown file formats by their extensions. But if you can't even access the information on the system to figure out what it is, it clearly has no business value, and you're at even greater risk in the event of litigation or an audit. Document your work and take it to legal.
Turn it off. This one I recommend as a last resort and at your own career risk. If you truly can't figure out who owns a particular system - nobody will claim it, nobody wants it, several groups point fingers at each other asserting *their* responsibility for it - this will get you a response one way or another.
Turn off access to the system.
Whoever screams about it first, or loudest, is the new owner! And if nobody screams about it for a week, a month, three months, etc., that's a pretty good indicator that the system and the information it contains no longer has current business value. The fact that you turned off access 90 days ago and nobody complained is a pretty powerful data point to be able to take to legal.
Before you act....
In every instance, before you do something that cannot be reversed, it's important to talk to your legal team (and probably risk management and compliance as well, if you have them). Ordinarily I'd include the records team in this as well, but absent ownership of a system or the ability to determine its use, there's not going to be much for records management to do here.
No comments:
Post a Comment