Enterprise Content Management
"ECM" -- Don't buy it
by Jim Howard
26-Mar-2003
In a recent assessment by Jupiter, 27% of the content management system owners surveyed were so unhappy with their implementation that they were considering custom development to replace the system. That's a very disturbing figure, when excellent products can be found within each of the various segments of the content management market. A good package should always result in a better, more fully featured, more maintainable application than custom development.
I firmly believe that the problem content management buyers are experiencing is driven by vendor misinformation and a penchant for over-generalization. There are many examples of generic labels creating confusion and vendors pushing products regardless of suitability; however, the label "Enterprise Content Management (ECM)" is especially guilty in propagating confusion.
This line of thinking may seem strange coming from the head of a company that markets its services as "Enterprise-Level Content Management." By "enterprise-level" we mean high-end features, flexibility, and scalability to manage large and complex web publishing projects. However, our offering isn't perfect for every content management project. No product is.
The wide variety of products that call themselves Enterprise Content Management -- and the overlaps between those products -- is the main problem. For example, consider the business goals for Document Management implementations and contrast them against those for Web Publishing. Vendors from imaging, workflow, document management, change management, knowledge management, records management, portal management, and web publishing all label themselves ECM. They do it because "ECM is hot."
In fact, it seems to be getting just hot enough that we are all getting burned.
The ECM Concept Makes Sense on the Surface
Conceptually, ECM makes sense on three levels.
- Sharing content across an organization or via an Intranet is surely a good thing.
- Moving content from "silos" into a master repository or merged repositories can provide benefits for the enterprise as a whole.
- Embracing standards across all content management projects within an enterprise makes sense based on the benefits of those standards: training, licensing, compatibility, and so on.
Unfortunately, there are flaws in those seemingly simple statements.
First of all, making content available internally across an organization might seem attractive, but making all content available to everybody across an enterprise is phenomenally expensive -- and with what results? There are a bewildering number of content types for a fantastic number of purposes. The truth is that the larger the organization, the more specialized people's jobs become, and the less likely it is that any one element of content is going to be useful.
In fact, the more content available, the more important the content discrimination process across the organization becomes. The law of diminishing returns can be applied with prejudice. Prioritizing and promoting important, relevant, current content is the true objective. Enabling everybody to become a publisher invites mass confusion.
On the surface, merging content from silos into larger, merged content repositories makes sense. Data warehousing, expert system, and Business Intelligence projects have been of great value to corporate customers. In Knowledge Management systems, the very purpose of the project is to merge sets of content for search, reporting, and visibility.
However, most content sets within a company are specific to distinct groups - with unique management, categorization and display characteristics that make that content valuable. Since the workflow and process associated with the creation and management of content is distinct to individual workgroups, they will want (and need) separate, customized management interfaces.
For the enterprise, the great danger here is that vendors love big projects -- the bigger the better for more licenses and more professional services. Resisting the urge to combine seemingly similar projects can be difficult. But -- counter to common wisdom -- it can be the only way to prevent prohibitively complex projects and sub-optimal workflows and interfaces.
Standardization Delivers Efficiency - Right?
Of course, IT standards are critical. Nevertheless, companies tend to confuse the adoption of industry standards with the procurement of a single vendor's product suite for use broadly across heterogeneous departments or to address diverse functional needs (like asset management, document management, knowledge management, etc.)
Is there one product that can solve all of an organization's varied needs for content creation, conversion, integration, management, and display? The answer may be "yes," but is the product that specializes in web publishing going to be a good document management tool (and vice-versa)? Is the product that specializes in workgroup collaboration going to be an effective content syndication tool? Not likely. In fact, products designed to do all things for all people will generally not do any of those things very well.
In the real world, though, workgroups do indeed need specialized tools. Various groups of content managers within an enterprise have diverging requirements for the content creation and management process and content display. For example, a brand manager who needs to update content on a small, brand-specific web site has an entirely different mandate from the IT manager tasked with the development of a document workflow system for invoice processing.
Also, because isolated workgroups typically create and manage content for different purposes, unified automation and training programs often don't provide a benefit. Look at the largest companies out there who have standardized on a single application -- they rarely have a single team who implements and manages the various instances of that application across the enterprise. It turns out that training IT staff to implement a specific solution across the organization is good in concept, but can be very challenging to execute - especially in a geographically diverse organization.
Unfortunately for many organizations, standardizing on a single product for efficiency has had the opposite effect. Attempting to use the "enterprise" product selected by the IT standards committee for a smaller, workgroup-specific project is too frequently a waste of time and money. Even worse, many "enterprise" projects never get started because their sheer size exceeds budget or staff constraints.
But what about industry standards? Clearly there are benefits to rallying around technical standards. Standardization on enterprise technologies in areas like operating systems, application servers, and development languages can be a good thing. But when the standards are too new to really be stable -- or the choice of language prevents selection of the best package for the job - technical standardization can outweigh any benefits to the enterprise.
ECM in the Real World
At a recent ECM conference, I went to a set of presentations billed as "ECM Case Studies." The first case was primarily the replacement of a Notes system with a new intranet. Very little of the company's content was represented in that intranet. In a second presentation, a different vendor described implementing a publishing system for a large corporate web site -- far from what I would term an enterprise initiative in a firm with over 40 public web sites. In a third, we saw a sophisticated, mission-critical document workflow system for a financial services vendor. The only conclusion I can draw is that even the ECM vendors aren't attempting ECM.
I also called some IT managers from big organizations to ask about their ECM initiatives. The first was a large entertainment firm that has been involved in a nine-month process to standardize on a single ECM vendor. In the manager's opinion, all of the best Web CMS products have been eliminated from contention, and the remaining three ECM suites are too expensive and bulky for his relatively simple website publishing requirements. He has resigned himself to custom development.
Then I spoke with an IT manager with a major automotive firm who standardized on an ECM vendor about three years ago. Today, they have four completely separate projects ongoing (all primarily web publishing systems); each with its own dedicated team, semi-permanent expert contractors, and vendor professional services staff. Each system has been heavily customized, and three separate versions of the software are being used, each in its own environment. He was relatively happy with the product, but admitted that there was little-to-no benefit coming from product standardization.
What Can You Believe In?
OK, after telling you what doesn't make sense, here are 10 things I do believe in:
- Content Management should be built around the workgroup. Pick a solution
to meet the needs of the group who is managing and publishing. Content silos
can be a good thing! Merging content into a single repository should be done
only if there is a business need to have the content types working together.
For example, merging HR forms and sales proposals into a single repository
probably isn't worthwhile.
- Shared document repositories are highly valuable. In some types of companies
-- like law firms and consulting firms -- document knowledge management should
be a primary mission of IT. Segmented repositories and small steps are the
way to get these programs working. Simple implementations typically work
best - especially at first.
- Enterprises should concentrate on making intranets into content visibility
tools -- enable easy publishing for the workgroups who have valuable content
to share, but don't enable publishing for every employee unless you want a
big mess.
- Workspaces, where groups can share and collaborate on documents and other
assets are a great idea. They should be very simple to set-up and self-manage.
- There is great value in sharing corporate brand assets and this function
should be centralized. The larger the company, the more valuable this becomes.
Simple, web-based asset repositories can enable the most commonly used brand
assets to be kept up-to-date and available to everybody.
- IT groups should standardize on technical platforms - J2EE, ASP, .Net, Linux/PHP,
etc. Attempting to standardize on a single product can be a bad idea. Different
interfaces for different workgroups is a good thing.
- Professional services costs and complexity are what make a CMS fail. If
it costs $200k to get something working, then how much will it cost to own
it? How much will it cost to change that system when you want to change your
site? How long will it take? Low implementation costs = low management costs.
- Trying to accomplish too much is one of the biggest hazards in the CM world.
Keeping the project goals simple - "knocking 'em down one at a time"
- is a winner. Attempting to solve the enterprise problem is simply not realistic
in most cases.
- Personalized content is difficult to set-up, difficult to manage, and almost
always costs much more money than it's worth. Amazon, Yahoo, and a few other
portals merit personalized content. 99.999% of sites just require intelligent
and well-marked navigation, categorization, and search (and these are hard
enough to execute well anyway).
- Content management systems are often selected on the basis of project requirements that are unnecessary. Solve the big issues. Concentrate on speed and ease of implementation and management. Do not let the vendors set your selection criteria.
Content Management Isn't the Same as Other IT Functions
The common wisdom that standardization, sharing, and consolidation are good things when it comes to content management makes ECM a very compelling message. Especially when speaking to an IT audience, this message works - for the simple reason that it's true in many other software segments such as desktop applications, call center management systems, accounting systems, and so forth. The largest vendors in the market benefit greatly from these common beliefs. The standardization mantra can convert a single customer into a 100-license sale plus a lucrative professional services annuity. No wonder the ECM agenda has been promoted so aggressively.
That's not to say that the products of the ECM vendors are "bad." Quite the opposite. They are typically the most complete products on the market. However, it's simply not possible -- or smart to try -- to manage all of an enterprise's content via a single application.