Faced with increasingly complex document and information management needs, many organizations are exploring socalled enterprise content management (ECM) suites. The idea of ECM is simple: have one place where people can collaborate, solve problems, access reference materials, manage works in progress, develop learning curriculum, manage website content, organize records, manage email and engage in numerous other online knowledge and information management tasks and processes. However appealing the ECM seems to organizations, its selection and implementation is complex and fraught with challenges.
Before delving into the dos and don'ts, it's important to understand that ECM is more of a concept than it is an application or applications suite. Because underlying content processes are so complex and varied in any organization, it is unrealistic to expect that any single system will meet all requirements. There are vendors who sell a wide range of applications that are presented as an integrated suite; however, the reality is that these are typically applications that were developed by different organizations (or certainly groups within organizations) and may be less tightly integrated than one would desire or expect.
These "suites" are sometimes loosely bundled tools that have been assembled through business acquisitions by a vendor over time. Tight integration of newly acquired systems can take years. A vendor will claim to have a well-integrated suite, but even installation (let alone customization and application development) can become extremely complex.
According to Alan Pelz-Sharpe, principal at CMS Watch and author of The ECM Suites Report, "Almost all suite offerings are the product of multiple acquisitions — and integrating a company and its product is a massive job, you have different and often clashing cultures, let alone different code stacks and architectures. If a product was acquired in the last two years, it is almost certainly not fully integrated into the 'suite' offering — we know of products acquired 10 years ago that still stand alone."
The lesson is that ECM can be considered more of a class of technology comprised of various types of tools. Therefore, it is important to think in terms of specific functionality in support of business processes rather than acquiring the "Über application" that will be all things to all people. Think in terms of specific capabilities that users need for a particular business function. Those capabilities need to drive selection of software rather than the grand vision of a complete suite that can meet everyone's needs
The classes of tools that people consider as part of these suites include the following: web content management systems, intranet content management systems, document management, records management, digital asset management, email management, learning management systems and learning content management systems and collaboration (see "Classes of ECM Tools" sidebar). These systems can be used across a particular function and integrated into specific processes. For example, a web content management system could pull from a DAM, an LCMS and a DM tool. Other functionality that may be part of these systems to one degree or another includes rights management (both licensing of rights and controlling asset usage) and workflow or business process management (for integrating content into various business processes or managing content with respect to a process).
Based on the wide range of purpose and function that these technologies offer, it is important to focus on business needs and not on tool functions. Though this sounds and is obvious, it is very easy to fall into the feature/function trap. Why is this? Because organizations approach these projects as big-ticket infrastructure acquisitions. Therefore, people in the selection process try to abstract functionality to meet the broadest set of needs.
A better approach is to start with a specific business problem to solve with measurable/observable outcomes. List things you need to fix today: Sales people can't find sales proposals; customer service can't locate answers in support systems; designers are recreating graphic assets in the marketing department; marketing cannot control branding on websites; product managers cannot post up-to-date product information on the e-commerce site; general counsel cannot produce documents during litigation; regulatory affairs cannot demonstrate compliance due to labeling inconsistency; sales organization loses customers due to poor site usability; etc.
In each case, identify who is hurt by the problem. Who owns the issue? This is not an information technology problem but a business problem. Who are the business users and owners?
Very often we see information services (IS) or information technology (IT) leading the project — they get the production processes and the technology and understand metadata and info architecture; however, they don't necessarily feel the business pain.
Business users (marketing or sales, for example) can appreciate business impact (e.g., customer retention, increased revenue, brand management) but don't usually know what technology can do to solve the problem or understand how they might solve the problem. They are also usually less versed with what it takes to make things work — to operationalize the solution.
Though it does take more effort to align and achieve a common vision, it is very important to work collaboratively on a solution. It is important for IT to see the business side and for the business side to at least understand their role in technology deployment.
Read the magazine-exclusive sidebars, "Classes of ECM Tools" and "The Executives' Answers" >>
Read Part 2 of this article >>
Seth Earley [www.earley.com] is the founder and president of Earley & Associates, Inc., an information management (IM) consulting company. He has been implementing content management and knowledge management projects for over 12 years and has been in the technology field for over 20 years.
Paul Wlodarczyk is a director of solutions counsulting for Early & Associates.
