Sean R. Nicholson

In the second article in this series, we’ll focus on understanding Content Management and how it differs from Document Management and Knowledge Management. If you recall from the first article in the series, Document Management is all about how we create, manage, route, retain, and destroy the container that we refer to as a document. Content Management, on the other hand, focuses primarily on the information stored inside that container and how you can effectively add/edit/delete the information in the document.

Keep in mind that while some folks use the term “document” generically to refer to Microsoft Word documents (primarily because they use the .doc extension), a document can also be an PDF file, an HTML file, a Microsoft Excel spreadsheet…really any kind of container that holds content.

Distinguishing Between Pure Content Management And Enterprise Content Management (ECM)

Note: Before we dig into the details of Content Management, we need to establish that the focus of this article is to define and discuss pure Content Management separately from Enterprise Content Management. ECM blurs the lines between Document Management, Content Management, and Knowledge Management which, when brought into the conversation,  makes it difficult to discuss each of the separate components on their own merits. So, for the duration of this article, take a step back and let’s just focus on the Content Management component, apart from ECM. In the final article in the series, I’ll bring it all back together to discuss ECM.

So What Is Content Management?

In it’s simplest term, content management is simply editing a document to add, replace, remove, or modify the content. When you open a new Microsoft Word document on your desktop and type a few lines of text, you are engaging in content management using MS Word as the content management tool. You then save the document and store it on your computer, network location, or document management system. Through this process, you have engaged in both document management (the creation and saving of the document) and content management (the adding of information inside the container). Simple, right?

Content Management becomes much more challenging for organizations when you ask many people to collaborate at the same time on the same document. Issues arise such as the following:

• How do you keep one person from overwriting the content that another has added?
• How do you keep people from corrupting documents by editing them at the same time?
• How can you control the quality of the content to ensure proper spelling and grammar?
• How do you audit when someone last edited the content?

The existence of these, and many other issues has driven the creation of tools that allow organizations to collaborate around content, aka Content Management Systems. By introducing functionality such as user accounts, authentication, check in/check out, change tracking, and rich text editors (aka “WYSIWYG”), Content Management systems have addressed many of the concerns created by mass collaboration by limiting what individual contributors are allowed to do with the content and tracking when content is being edited. By leveraging this added functionality, organizations can minimize some of the risks of mass-collaboration and can maximize of the benefits that content management tools offer.

Different Kinds Of Content Require Different Editing Tools

In their early days of distributed content management, CMS tools focused primarily on editing Web pages. These Web Content Management systems allowed non-technical users to create, edit, and publish content to corporate Web sites and Intranet portals without having to know HTML, JavaScript or any other coding languages. As a result, organizations were able to empower their business users to take ownership of the content in their Web site and Intranet portals without having to engage IT for each and every change. In addition, the use of user accounts allowed organizations to control which roles were allowed to create content, edit it, and approve for publication.

Because of the proliferation of these tools and the rapid organizational adoption of them, the term Content Management System became synonymous with Web Content Management System. But as organizations saw the value of these systems and a variety of different types of content were introduced into the enterprise, new content management tools were needed.

For instance, digital assets such as images, videos, Flash movies, and audio files presented new challenges. To maintain the quality and appropriate use of these corporate assets, Digital Asset Management Systems were created to all organizations to manage the assets in a similar fashion to managing documents, while allowing some content management functionality through plugins with popular editing software like PhotoShop and Flash.

Document Management and Content Management Come Together Through Business Process Management

As the ability to edit different types of content has grown, organizations have recognized that the content management and document management can be intertwined to improve on business processes. Business Process Management tools provide organizations with graphical workflow solutions that allow for the creation and routing of documents from one user to another. upon arrival in their workflow queue, users can edit or review the content using a content management tool and then finalize the document or route the document to another user or queue for further processing.

Business units like Accounts Payable, Human Resources, Contract Management, and Decision Support have optimized document and content management by applying automated business rules that allow the document to be management in a specific manner based on the content.For instance, in situations where an invoice has a low total amount (say under $500), an organization can auto-approve the payment of the invoice without a high level of risk. In situations where total invoice amount exceeds a threshold, the workflow can route the document appropriately for a content review to ensure proper auditing.

Bringing Content And Documents To The Users Through Knowledge Management

The process of creating documents and managing their content continues to become more difficult as the volume of information in the organization grows. Effective organizational content and document management strategies are going to have to find ways to get the right information to the right user. To do this, business process tools and content management systems are going to need to leverage knowledge management principles to evaluate content and route content appropriately.

In the next article in the series, we’ll take a look at how Knowledge Management principles can be used to ensure that content is being effectively reviewed and used in the organization.

Sean R. Nicholson

A few years ago, I was in charge of an RFP for a Fortune 500 company to select an Intranet portal application and portal content management system. Thinking about the requirements for that portal and how they would change in this age of social networking got me thinking about how the requirements would change if I were to conduct that same RFP today.

Portal Requirements in 2005

Back in the “olden days” of horizontal portal requirements (you know…a few years ago),  the top requirements for our enterprise portal were as follows:

1. Enterprise scalability, with current requirements at 25,000 end-users, but scaling to 100,000 with additional hardware and licenses.
2. Easy to use, graphical user interface that allows end users to view targeted content and easily navigate to pages within the portal using  either an organizational or functional page taxonomy.
3. Provide portal administrators with the ability to secure content to groups, organizations, and individuals.
4. Provide a WYSIWYG rich text editing interface that allows users to create and edit content, based on their permissions and group membership.
5. Provide a single search interface that allows users to search for content that is target to their account based on assigned permissions
6. Provide a workflow tool that allows content to be reviewed and approved prior to publication
7. Provide a customizable portlet or widget-based interface that allows end-users to customize their experience.
8. Provide portal administrators with a flexible design and administration interface that allows administrators to create page templates that standardize on some page elements (e.g. header, navigation, mandatory portlets).
9. Provide functionality to interface with an enterprise Identity Management Solution.
10. Provide analytical reporting that details usage activity, content quantity, and hyperlink status (e.g. number and location of broken links)
11. The ability to integrate with existing enterprise applications such as the document management system, time reporting system, and expense management system using a Services Oriented Architecture.

Like I said, these were the high level requirements that we looked at. We actually had more than 300 specific technical and functional requirements, but these hit the major functionality we were looking for.

As you can see, though, these portal requirements are based on an “information-push” concept, where a core group of individuals (maybe 50-75 for the entire corporation) create all of the content and push it out to the masses. While we did have requirements for collaborative items like forums, they were listed as optional and we weren’t quite sure whether we wanted to allow end-users to start creating content on their own in a forum environment. Pretty much typical information control tactics that are present (even today) in many large organizations.

Changes To The Portal Requirements In 2009

While many of these requirements would still hold true, an information portal in today’s culture would definitely focus more on collaboration and content management than the pushing information out to the masses. Based on my experiences with some of the popular social networking platforms, my top requirements for the same sized organization would probably look more like this:

1. Enterprise scalability, with current requirements at 25,000 end-users, but scaling to 100,000 with additional hardware and licenses.
2. Easy to use, graphical user interface that allows end users to view targeted content and easily navigate to pages within the portal using  either an organizational or functional page taxonomy.
3. Provide portal administrators with the ability to secure content to groups, organizations, and individuals.
4. Provide both a rich-text content management system that allows portal administrators to deliver content and a WIKI environment that allows end-user to create their own page content
5. Provide a single search interface that allows users to search for content that is target to their account based on assigned permissions
6. Provide content creators (both in the CMS and WIKI environments) the ability to review content additions and comments if they choose to enable the feature.
7. Provide a customizable portlet or widget-based interface that allows end-users to customize their experience.
8. Provide portal administrators with a flexible design and administration interface that allows administrators to create page templates that standardize on some page elements (e.g. header, navigation, mandatory portlets).
9. Provide functionality to interface with an enterprise Identity Management Solution.
10. Provide analytical reporting that details usage activity, content quantity, and hyperlink status (e.g. number and location of broken links)
11. Provide the ability to integrate with existing enterprise applications such as the document management system, time reporting system, and expense management system using a Services Oriented Architecture.
12. Provide end-users with the ability to create custom application and information widgets that can be shared across the enterprise.
13. Allow users to easily share updates with others on their work through personal status updates
14. Allow users to create and manage groups/networks that can collaborate through a WIKI interface or a discussion forum interface. Users should be able to store and review documents as attachments within these groups. Users should be able to collaborate and version these documents and the applications should maintain an audit trail.
15. Allow users to create custom events and invite users and groups to those events. Individual and group events should roll up to a common corporate calendar that displays events to users based on their permissions and group memberships.
16. Allow users to share digital media including photos, audio files, and video files. Users should be able to collaborate and version these files and the application should maintain an audit trail.

So What Just Happened? Those Don’t Sound Like Portal Requirements!

Basically, in the process of writing those new requirements, I changed my RFP from being one focused on a portal, to one focused on an Enterprise Content Management system. Not an ECM as we know it today (which are primarily focused on Web/Intranet content management, document management, and digital asset management), but to an ECM platform that requires the following:

• A customizable presentation layer (the portal)
• A flexible content management system (traditional WYSIWYG content management and collaborative WIKI)
• The ability for end-users to create application mashups
• A lightweight document management system
• Social networking capabilities through collaborative groups/networks
• A lightweight digital asset management system
• Enterprise search functionality

Previously, ECM players such as Stellent, Documentum, and OpenText have not offered a portal interface to their products. Instead, they focused on their ability to interface with portal such as WebCenter Interaction (formerly AquaLogic User Interaction (formerly Plumtree)), IBM WebSphere, Microsoft SharePoint, and Vignette portal.

As a result, some of those solutions are being gobbled up by the portal players in hopes of creating the true Enterprise Content Management System of the future. Some of the portal players, like Vignette and Microsoft have anticipated the merging of portal and CMS, and have opportunities to add social networking to their platforms. In the end, the days of offering a standalone portal are probably long gone and we’ll soon see the horizontal portal players roll into the ECM magic quadrant.

Thoughts or comments? I’m always open to additions and constructive criticism in you comments.

Sean R. Nicholson

Over the last few years, the term “Enterprise Content Management” (ECM) has become a term familiar to those working in the Intranet, Web, or Knowledge/Information Management sectors. The difficulty lies in the fact that, while the term is easy to toss around, the actual definition of what is expected to be encompassed by ECM continues to evolve. As a result, ECM to a Records Manager often means something very different than what ECM means to a Web Developer. In an attempt to more accurately define ECM, this article deconstructs the term into a variety of subcomponents that are commonly included in discussions about ECM.

Core Functionality for ECM

Recently, when conducting a search for an ECM solution for a Fortune 500 organization, the following core requirements were set forth as required elements to participate in the selection process. These core components provided a basis for what was expected to be included in an ECM offering:

• Document Management (DM) – Centralization of millions of documents was core to the functionality of this particular business and document management is probably the most consistent component in the definition of ECM. In this case, the DM system was required to have a browser-based folder view of the repository as well as check-in/check-out document collaboration, robust full-text searching, and the ability to secure documents at the organizational, folder, and document level. In addition, the solution required full auditing capabilities of each user and object within the repository. Finally, integration with the enterprise email system, while not required, was favorable.
• Web Content Management (WCM) – Although the goal of this particular RFP was to select a content management system (CMS) for an Intranet portal, the principles were the same as the selection of a Web Content Management System.  The solution had to include a “What You See Is What You Get” (WYSIWYG) rich text editor that allowed content creators and managers to easily edit and permission content. In addition, the solution had to offer the ability to schedule content for future publication.
• Records Management (RM) – To comply with the corporate retention schedules, the RFP required that the selected solution provide Records Management functionality that included the ability to schedule the review and destruction of items marked as corporate records. The ideal solution would allow for the creation of a variety of retention categories that allow for the movement of corporate records from real-time storage, to secondary, and eventually tertiary storage as the lifecycle of the record progressed.
• E-Discovery Tools – With E-Discovery weighing heavily on the minds of corporate attorneys everywhere, it was required that the selected solution provide the ability to locate content based on keyword searches or metadata and place those documents or records on legal hold for review. These documents, while in hold status, would be exempt from the records retention/destruction policies. In this case, the E-Discovery tools were only required to access content and not data. The distinction is that the ECM tools were focused on content stored in document and portal/Web content repositories and not in application databases such as customer relationship management (CRM) solutions or billing systems.
• Enteprise Search Integration – To provide a single search interface to users, the solution was required to provide search integration through an Application Programming Interface (API) using the Web Services Definition Language (WSDL) or other suitable messaging platform. The implication was that users should be able to search many sources of content using a search interface integrated into the corporate portal.

Just to participate in the selection process, each vendor was required to demonstrate that they offered the above functionality. That doesn’t mean, however, that these five elements completely defined ECM for that organization. Even after the solution was selected and implemented, the definition of ECM continued to evolve as users identified new content types and needs. Discussions of blogs, Wikis, and digital assets identified new potential content and required the reshaping of how content would be captured, stored, and governed. As this evolution progressed, several additional components were added to the organizational definition of ECM.

Secondary Functionality For ECM

• Transactional Content Management – Activities such as claims scanning and processing, invoice processing, and human resources employee packet processing all require that data be captured via scanning or electronic methods, and processed through a workflow until completed.
• Business Process Management - Activities that require documents or content to be passed through a workflow needed to be automated using a business process management tool. These tools allow the Business Process Owner to lay out the business process in a graphical manner and then create worflow rules that govern the routing of the document or content to various roles in the organization. The classic example is that of the content creator/editor/approver. The content creator creates the content and then routes the content item to the editor queue for editing and review. Once the content is edited, the editor forwards the content item to the approver for final review and publication.
• Digital Asset Management – In this age of digital media, the protection of electronic assets such as coporate logos, images, videos, and audio files is becoming of increasing concern to organizations. Digital Asset Management (DAM) systems focus on securing and protecting those assessts, restricting whether they can be used, duplicated, or altered by users and tracking when those activities occur.
• Knowledge Management – Knowledgebases, Wikis, blogs, microblogs, forums, and mashups are surfacing more frequently in the enterprise and the content created by their authors is key to capturing information once trapped inside each employees head. Using these tools, content authors can share their experiences and understanding of the organization. Each comes with its own challenge, however, as the content is often controlled by the creator and often has not review process.

Clearly, to this organization the definition of Enterprise Content Management went far beyond the ability to simply store a document in a centralized location and locate it when necessary. Just as in this example, organizations are continually being challenged to define what should be included in their Enterprise Content Management solution. As new types of content are identified, the need to store, secure, and locate them becomes more and more crucial to business operations. As a result, the definition of ECM will continue to evolve and the solutions offered to manage these content types will be required to either specialize in specific aspects of the content or grow to become all-incluse of the various content types.