Think of enterprise content management (ECM) software as a grab bag of features. As part of an ECM system deployment, one of the most important tasks for an organization – namely, the ECM project team and governance committee – is to decide what features to use and how they should be used.
Some of the available features are the reason why the organization is moving to adopt ECM technology and are absolutely necessary to the smooth functioning of the ECM system and the business as a whole. Others will provide business value but add deployment time and implementation costs that might outweigh their benefits. And then there are features that some business users get excited about but that pose potential risks to the organization.
A sample breakdown of ECM features into those three categories might look like this:
Necessary to ECM
- Document versioning
- Document persistence
- Taxonomy creation
- Search capabilities
- Metadata management
- Content auditing
Add value but not necessary
- Records management
- e-Discovery and legal hold capabilities
- End-user dashboards
- Support for user-generated “folksonomies”
Exciting but risky
- Personal pages/profiles
- Instant messaging
- Shared documents
When it comes to software features, most organizations believe that if they have it, they need to use it. But because it’s end users who most often cause an ECM implementation to fail, not the technology itself, that kind of thinking could have costly consequences. Use too many features and best case you confuse users and slow the adoption of the ECM system – worst case you needlessly increase deployment costs and expose your company to compliance issues, legal risks and other problems.
To avoid such outcomes, an ECM governance committee should undertake an exercise similar to the one detailed above, breaking down the feature set of an ECM system into different categories of value and risk and then deciding whether the various features will be turned on. It’s safe to say that all necessary ECM features should be implemented in phase one of a project. The features in the second category could perhaps be tabled until later phases as you consider their pros and cons; the best approach is to assume that they won’t be used and force the governance committee and project team to build a case for why they should be.
Exciting but risky features should be weighed on their ability to help with user adoption vs. their potential negative aspects. Very often, the features in this category are what drive end users to accept ECM technology: the ability to comment on documents, say, or to establish a personal set of keywords for documents stored in the system. They can be a powerful tool in the governance committee’s effort to convince users to do the right thing within the ECM system. On the other hand, people can write anything in a comment box associated with a document, thus increasing the chances of personnel and legal issues.
Governing the use of ECM features: technology or policy?
Whatever the final makeup of an ECM system’s features is, understanding how they fit into your ECM governance framework is critical. Is a particular feature something you can control with technology or something that should be governed via a documented corporate policy? “Necessary to ECM” features are automatically governed in most systems, while “Exciting but risky” features are usually governed by written policies.
What’s great about technology-based governance is that it’s black and white: “Do it the right way or it won’t work.” But just because a feature can be governed within a system – for example, by not allowing a document to be uploaded without all metadata being entered – doesn’t mean it should be governed that way. Many users might take such restrictions to mean “Don’t do it at all.” The more entry barriers you put on your users, the greater the frustration with the ECM system – and the lower the adoption rate.
But there’s a balance that needs to be struck: Impose too few checks on user behavior within the system and you’re likely to live the “garbage in, garbage out” phenomenon. As a result, most organizations choose a combination of technology- and policy-based enforcement of usage rules for their ECM systems.
Keep in mind that a policy without teeth is useless and will be ignored by users. Before any policies are written and disseminated, it should be clear what the consequences of breaking them are and who is responsible for enforcing them. Unfortunately, it sometimes takes examples of what happens when you do the wrong thing before the right thing starts happening on a regular basis. In addition, enforcement of ECM usage rules should always be backed up by regular and detailed content audits to ensure that technology-based restrictions are working correctly and that governance policies are being followed.
A wise organization bases its choice of what ECM features to use on two key factors: whether the available functionality will provide needed capabilities to end users and help the company meet its business objectives. That reduces the risk of stumbling into an overly complex implementation and, along with proper governance procedures, offers everyone in the organization a solid understanding of what the ECM system can do – and how it’s supposed to be used.
ABOUT THE AUTHOR
Chris Riley is the founder of LivingAnalytics Inc. and senior ECM and document capture architect at ShareSquared Inc., a consulting firm in Pasadena, Calif. Riley has more than 12 years of experience in the ECM and document-recognition technology fields, and he holds AIIM’s ECM Practitioner and Information Organization & Access Practitioner certifications.
This was first published in July 2011