PART 1. Records Management Policies – a vital part of ECM – benefits of having them and risks of ignoring them.
PART 3. HOW and WHEN to implement Records Management Policies
Records Management Policies – rules of moving content through all stages of its life cycle until it is discarded (or kept forever).
It usually includes:
– What content you are moving
– When you are moving it
– How you are moving it
Records Management Policies, Document Retention Policies, Records Retention Policies, Archiving solutions, Archiving strategies, Content Management Policies
The article is for: IT professionals and corporate leaders, companies of all sizes who have a substantial amount different data coming into ECM platform
This article is mostly for cases where you have an ECM platform on-premises or going with the hybrid solution, but some of the statements and ideas can be applicable for a cloud as well.
In the first article, I mentioned several money-keeping benefits of proper Record Management Policies for ECM software. You can review them (See part 1 above)
So what can go wrong if you don’t have the RM Policies in place:
Not to go into too many details but here how the hell breaks loose: You go with an ECM enterprise application solution – for example, SharePoint. A lot of electronic data comes into this application: different doc files: .doc .xsl .pdf, graphics, lists of records, sites are created, etc. BUT… nothing ever comes out – the company would not set up simple rules such as: how long the records or documents can stay in this active place until they become outdated and need to be moved away and then archived, OR what is the list limit after which the group will move to a new list. Next – the library becomes overblown and software begin giving a performance problems (the best case is the site just hangs, or the and a lot of employees are sitting and watching the spinning wheel until the DB coughs through, or the user’s changes are lost, or if there are enough entries to make DB totally choke that can spice things up. And for extra fun – your finance department on that DB and is affected by this issue and it’s the quarter close time! Next thing you know your IT personnel is dumping a lot of time on support calls troubleshooting the issues and you are hiring additional expensive resource or a consulting company to help you with the problem most likely to perform a “convoluted IT surgery” on production servers during production hours. In addition, you are stuck with an unexpected urgent migration. But when you are trying to migrate a lot of data there can be different impacts, where most likely you’ll have to move this data in chunks and arrange for batch deletion which is usually a script that is run on the production server, so you need to test it first. The whole venture will turn into a big time and money consuming project which you can avoid with proper record management policies.
And there are many more unpleasant money draining projects that are avoidable by timely set RM policies.
Lots of fun!
The software has its limits. To simply put it: too many records/docs will make your application hose.
Yes, if you move the content to the cloud some issues might never come up, but I’ve seen companies who will never consider cloud for proprietary or highly confidential material. This part will be always on the servers that the company fully owns and manages. And even your documents are on the cloud you need to make sure that they are properly managed. Otherwise, you probably will be dumping a lot of money into unnecessary storage on Tier 1 🙂
Yes, the DBs can hold millions of records, but there are catches to it. And besides, if there is an opportunity would you rather store the older records on a lower tier – a cheaper alternative, cutting your expenses? I am sure you would.
So stick with proper app governance and product’s technical recommendations and design good policies to manage the content.
Once again: Your company should spend the time and resources on growing and not be patching the holes.
Read the next article (Part 3 ) on how and when to set Record Management Policies