You can’t do records management in SharePoint (part 2) — but you’re probably not doing it anyway
In the last post, I called it like I seen it: SharePoint out of the box can’t do records management. 2007, 2010, 2013—none of ‘em left to their own devices are worth much when it comes to automating the retention and (more importantly) disposition of your records according to the retention schedule.
But as if that weren’t provocative enough, I also argued that, regardless of system (SharePoint, IBM FileNet/P8/CMOD, EMC Documentum, OpenText, Hyland OnBase, whatever), and regardless of the capabilities of that system, pretty much no one is actually doing real records management on their electronic content.
Check out the last post to see my reasoning for this being true (and let me know what you think of it). In this post, however, let’s turn to what might be driving the fact that almost no one is doing electronic records management (whether in SharePoint or any other enterprise content management system).
If only technology were the problem
I find myself saying this a lot in my day-to-day travels as a strategy consultant focused on ECM, but it’s especially true of automated records management. Here’s why.
Imagine you’re a Fortune 500 bank. One of your record types will be some flavor of account holder documentation, which in the U.S. will likely have an event-based retention trigger along the lines of death of the account holder plus three years. So far so good, except your ECM system has no idea when an account holder dies, which means it won’t be able to automate the retention and disposition of account holder documentation—at least not easily.
One option is to pull a list of all deceased account holders from your customer relationship management (CRM)system into your ECM system and then use that to drive the trigger. Except that at most organizations, simply getting an account holder’s correct phone number or email requires a database administrator to write a custom query, let alone something as exotic as the date they died.
Another option, and this is the most common, is to simply take the account opening date and add 100 years, because this should reasonably cover the lifespan of 99.999% of your account holders. The downside is that you’re keeping account holder documentation 97 years too long, which is akin to not disposing of it at all.
Let’s leave aside the issue of joint account holders (because you’ll need to check for them every time you’re getting ready to dispose three years after the death of a primary account holder), and just assume that you’re able to find accurate and timely death dates for all account holders in your CRM and pull them into your ECM system to automate the disposition of account holder documentation. Give yourself a pat on the back, but don’t celebrate too long: all that work only solved your problem for a single record type—now get cracking on the other few hundred you likely have kicking around.
Ok, some of you might be saying, “But what you’ve described is a technology problem—if only the system could manage to know when an account holder dies, we could do RM!” And there’s a measure of truth in this, but that’s sort of like saying technology problems are what mainly prevent us from colonizing Venus. Yes, if we had the technology, we could do it, but really it’s the practical constraints on colonization (temperature, atmosphere, etc.) that are the problem.
Electronic records management offers analogous challenges: the way most organizations approach records management as well as the way regulators have framed the requirements for corporate record keeping are primarily what make electronic records management difficult/impossible, not weaknesses in technology (although these don’t help).
The final word
We’ve gotten away from the intentionally provocative start to this series of posts (SharePoint can’t do records management) and have reached the people/process heart of the matter: organizations need to reframe how they approach records management if they hope to manage electronic records in an automated way. Hopefully I got past sensationalism to offer insights you found valuable and maybe inspired you to think about how you could better address electronic records at your organization, whether or not you use SharePoint.