Utilizing technology, ECM provides organizations with a framework to define processes associated with creating, enriching/annotating, managing and delivering content to both internal and external stakeholders. I have found that ECM has come to signify more a broad range of technologies and business needs than an actual monolithic product offering.
One of the very first challenges organizations encounter when looking at ECM is what the solution should encompass. Kyle McNabb at Forrester Research asserts that ECM encompasses document management, Web content management, document imaging, records management, and digital asset management, and is closely aligned with collaboration and business process management ("Topic Overview: Enterprise Content Management" Kyle McNabb, Forrester, March 2008). Recently, Tony Byrne of CMS Watch and several other industry analysts working on the ECM3 initiative (Enterprise Content Management Maturity Model) have offered up the notion that ECM should not cover Web content management and "related publishing-oriented disciplines." (http://www.ecm3.org/)
My bias is actually around the management of content objects for the purpose of preservation and reuse in different contexts. This includes delivery to print, Web, mobile, tablet devices as well as repackaging different content objects to create new offerings. My view of ECM consists of Web content management, digital asset management, some aspects of document management, and other multi-channel application components. Additionally, for content publishers, I believe XML server and natural language processing technologies may be closely aligned with an ECM strategy. I am not saying that records management and digital imaging cannot be part of an ECM strategy - only that my particular clients typically handle those business requirements separately from the actual needs around creating, annotating/enriching, managing and delivering content.
First Process, Then Technology
Getting started on ECM can be overwhelming as there are so many critical components - people, process, technology, budget, management buy-in, etc. What we have found is that our clients are perfectly satisfied to focus on the specific challenges they are trying to solve and not get hung up on the broad range of what ECM means to industry analysts or software vendors. For example, if a client is looking to manage records or documents, they will gather requirements and document use cases specific to that need, which may or may not include digital asset management. This does not exempt the company from trying to map their overall ECM strategy and the appropriate technologies that will support it. However, it speaks to the need for a phased approach to implementing the various domains of ECM as opposed to trying to implement it all at once.
One Size Does Not Fit All
Vendors and others in the industry may argue that to implement ECM successfully you need to stick with a single software provider's application stack. In reality, different vendors are stronger in certain areas - say document management, for instance - but weaker in areas such as digital asset management or Web content management. Given the considerable costs of implementing an ECM platform, this is another strong case for focusing on solving the business challenges that either offer up measurable productivity gains or, in the case of multi-channel publishing capabilities of ECM, new revenue models.
Start With Your Business and Functional Requirements
Try to organize those requirements into the domains of functionality that ECM appears to handle. Do NOT start from product suites, since you will get distracted by the product capabilities and potentially lose sight of your specific needs.
Companies often get caught up with trying to implement workflow in ECM initiatives, which is a worthy endeavor if workflows are well defined and adhered to. However if you have issues with existing workflows, you may re-enforce bad processes with technology, which will make matters worse. Additionally, if you do not have consensus about workflow(s), you may run into change management (user adoption) issues when you go to rollout phase. Companies often have poorly-defined workflows or too many exceptions within a workflow, and trying to capture them all in your ECM implementation will be costly and ultimately can create a very confusing set of interfaces.
Document Policies and Procedures
Another big challenge in an ECM implementation is that companies either don't document policies and procedures for document/records/content management, or don't have sufficient governance and oversight over those digital objects. This may not be as evident in ECM implementations where the assets are contracts or HR files, but it becomes a major problem when the ECM implementation is about digital assets. In those kinds of implementations, it is not unusual to find numerous duplicate files, or worse, small changes in versions that are almost imperceptible, but not documented. The challenge I have found is that people just stuff those old files into their ECM like they would old mementoes in a box in the attic, those assets will be as difficult to find as the sundry knick-knacks of yesteryear.
Understand the Data Types
One of the biggest challenges that many companies must overcome is how to manage chunks of information in different file formats. That data has to be stored in elemental form and its physical, business, and semantic properties somehow captured, either automatically or through manual data entry. While an ECM solution can seem expansive and complex, it is my opinion that companies should think small and look to the objects themselves that need to be stored. That way, even if there were missteps in the ECM implementation, at least you have protected yourself in the future by properly storing and describing the masses of content elements.
Metadata and Taxonomy
Still another area of challenge in ECM is defining, applying, and managing descriptive information about content objects. Companies are often overzealous about the information they'd like users to apply to content, and in the process create dozens of fields of metadata that need to be entered with each upload of an object. Recently, companies are looking to implement natural language processing (NLP) tools that can extract meaning out of textual content objects based on specially-prepared taxonomies that are relevant to the business.
This is a promising trend, but the technology is expensive, and I currently am not seeing that wide adoption of text mining engines. However, companies that view this as a severe problem and are investing in the research to determine their return on investment will buy these NLP solutions. As the price points go down, more systems will have NLP embedded as part of the solution, this will increase adoption.
Don't Go it Alone
It always amazes me when companies elect to implement ECM solutions by themselves. The technologies and workflows associated with document, records, and digital asset management require deep technical expertise. However, I can understand that a big issue companies have is that vendors or consultancies may send technical resources with expertise in the technology but not the subject matter expertise. This is invariably one of the biggest challenges where business and functional requirements, use cases, system architectures and integration plans fall short.
One way to get around that is to make sure that you hire a consultancy who is not only expert in the technology but has also worked within your vertical market(s) and understands the business challenges. Otherwise, the next-best thing is to get your subject matter experts (SME's) trained in the technology and hire a technically deft consulting shop to support the SME.
Take a Phased Approach
I've seen companies try to implement too many things at once, which is less an issue about ECM than about enterprise project management. It is worth repeating here that a phased approach with 30/60/90 day development and integration cycles remains the safest way to implement any kind of technology(ies). Also, when in doubt about an approach, performing proof of concept or spike tests is a good way to test technical hypotheses to determine their efficacy.
Define the Scope
On a regular basis I get called into customers at the departmental level to help that group get what they might call an "enterprise content strategy" documented. However, it becomes clear that this is an enterprise strategy for their own departmental needs, and in fact there might be other departments that already have ECM technologies and practices in place that would not be relevant to my customer. I don't have a magic answer here - I think the safest thing to do is to document the department's requirements, then go to other divisions/segments of the business to see if what they have implemented can fit the documented needs.
-J. Bachana, March 29th, 2009
(Written by Joe Bachana, March 2009) Having been involved with a number of enterprise content management (ECM) projects throughout my career, many factors can impact the success or failure of such an initiative. Oftentimes, organizations inadequately assess their business needs or prematurely select a system before defining their processes. As a result, getting ECM right can be a challenge for even the most unlimited technical and financial resources.