For those Doculabs clients who find themselves with a multitude of different content repositories, many are asking, “James, what’s the best approach to consolidating our content? We’d like to simplify our environment and reduce the complexity associated with integrating applications to a multitude of different content stores.”
Let me touch on a couple common themes: 1) how these clients got into this situation in the first place, and 2) and how to resolve it (to the extent it can be resolved).
How did we get here?
About 10 to 15 years ago, when many of these content repositories were created, not all content was treated or managed the same way. Images were considered large in terms of file size and required specialized storage subsystems, caching, and annotations. Print and system output were exceptionally high volume and were optimally stored without form overlays (versus the fully composed PDFs we often see today). Electronic office documents needed collaborative tools such as version control. Email correspondence required simple, inexpensive archiving.
And business units and departments seeking to leverage content management capabilities generally created a system to meet their specific needs, based on the type of content they were managing and the process the system automated. Then, based on the type of content the business units/departments intended to manage, there were different vendors that had strengths in managing the various forms of content. Why not buy the best for your purposes?
Finally, seldom was funding available to consider larger enterprise requirements. And so you spent only enough to implement “your” business unit/department’s system.
Little did we know how big these systems would become and how critical to business processes. Over a period of 10 years, with content volumes growing at 30 percent annually, a system that started in 2004 with 500,000 objects is now filled with 5.3 million pieces of content.
There are some very good reasons to consolidate repositories. Here are three of them:
- Customer servicing: One of the critical benefits of consolidating content repositories is to provide a common view of the client relationship. The ability to search and view bills, forms, scanned images, etc., is important to answering client questions efficiently – and promptly.
- Records management: In many instances, the time and energy to records-enable a repository can be considerable. Doing so 10 or 20 times for a variety of different repositories (and likely built on different technologies) is cost-prohibitive.
- Simplification: The last reason to consolidate (and in my opinion, the least justifiable) is the reduction of IT costs that result from a simplified hardware / software / infrastructure environment. To reduce these costs means a system needs to be entirely sunset, which in many cases can take years.
So what are your options?
At Doculabs, we’ve done a number of engagements analyzing the options for clients, and the recommendations that result follow some common themes:
- Stop digging. The first step is to prevent any new repositories from being created. This includes additional “instances” (new collections of documents within a repository). One client has instituted a fairly significant IT expenses / chargeback associated with standing up a new repository or instance. In fact, the cost is 15 times the actual expense to ensure there is a significant need and justification.
- Declare the target: In order to stop creating new variant repositories, the organization needs to declare the standard, and this environment needs to be operational, available, and – ideally – inexpensive to adopt. Often, organizations will subsidize these costs in some manner to encourage adoption.
- Decide which systems will (eventually) be sunset: Also declare those systems that will be sunset, and set some timeframe in which these systems will be configured as “read-only,” with no new documents being added.
- Identify low-hanging fruit: Some systems may be out of support, extremely low volume, a pain in the butt to support, or have poor functionality. Ideally, you can migrate a subset of the historical content from these systems – say the last 5 years – but often there is no easy means to segregate needed and unneeded content, so everything must be moved.
- Migrate opportunistically: For the remaining systems that are deemed “sunset” candidates, but are meeting their users’ needs, look for trigger events to time the migration of content and decommissioning the system. For example, if a system requires a major version upgrade and consuming applications must be rewritten, that might be the optimal time to migrate and decommission – “when the patient is open”. Additionally, the vendors themselves often set off trigger events, e.g. by imposing major jumps in licensing costs upon term renewals.
Following these guidelines, an organization can take a pragmatic approach to consolidating its content repositories over time.