Users who either fail to use a system or use it incorrectly present the biggest challenges to Enterprise Content Management (ECM) system deployment.
Ironically, one of the core value propositions of an ECM system is the easily configurable, highly granular control of permissions – who can do what and when to each piece of content – and it is this feature that leads to the greatest misuse in my experience.
Some ECM installations exist solely to manage critical corporate records alone, and these typically have tightly controlled, rules and governance for the management of content, including the correct application of permissions.
There are specific business processes that require such controls. And they can be further extended based on retention and archiving requirements (Records Management = RM). Regulatory demands make ECM essential for many enterprises.
But most ECM systems serve the needs of several groups or departments, typically for a range of different purposes. Often some of these purposes do not require most permission options – in fact I would argue they often don’t need any! This is especially true when the main aim is to share and collaborate with content.
Easily configured permission actions play to most people’s natural tendency to be secretive, especially at work. Watch a user set up a location in an ECM systems to ‘share’ content with colleagues. Often the first thing they will do is to decide who they think should have permission to access the content, and their thinking is usually very narrow:
Who needs to see this?
- Thinking about only current staff and current needs as they know them
- Typically forgetting someone who has a legitimate right or even need to see the content
- No thought about future needs of current or future staff, or the wider range of content that might subsequently be added
If a user can see this content, what rights should they have to do anything to it beyond seeing it?
- Mature ECM systems have 8 or more permission levels such as: See, See Contents, Modify, Edit Attributes, Reserve, Delete Versions, Delete, Edit Permissions; each of which can be set down to the level of an individual user level
- Further restrict rights to make any changes to a small subset of the people who can even see the content
- Think of current not future needs
The conjunction of ‘2.0’ to terms like ‘Web’, ‘Enterprise’, etc. is overused, but it has established certain patterns and expectations.
If something is ‘2.0’ it often includes new technology, but more importantly includes new, typically simpler ways of doing things.
Many 1.0 tools have failed in deployment because they were just too hard – people needed training that they often did not take, or quickly forgot.
Unfortunately traditional ECM tools often face this challenge.
It is a characteristic of 2.0 tools to be much simpler – often to the extent that no training is required – users find them intuitively obvious because they follow established UI models and the options are obvious.
Typically new collaborative tools have very limited permissioning options: permissions are restricted to granting users ‘membership’ in a community, and sometimes other predefined roles to which permissions have been preset. This is easy for people to understand and mostly keeps them out of trouble (Aside: It does tend to lead to community proliferation).
While this approach improves usability and through it user adoption, it does not support more rigorous, records-oriented needs where a full ECM permission model is essential.
As a result, we see 2.0-style collaborative tools adopted in many parts of less regulated organizations, but being summarily rejected where tighter controls are actually required.
We see the establishment of yet more unconnected systems.
If we don’t recognize this trend and address it effectively, there will be yet another round of content repository proliferation; some people will enthusiastically adopt the newer collaborative tools, using them to share content, while some cannot, even within the same organization.
There is a certain irony that 2.0-style approaches to collaboration that preach information transparency, will actually lead to less transparency across an enterprise!
What I think is emerging is a model that supports the consolidated management of organizational content, which absolutely requires the rigorous, permission management characteristics of ECM systems, coupled with collaborative tools that are easy to use and apply situational-specific, simple permissions.
In some way there is nothing new to some of this – in the past email was the easy-to-use, collaborative vehicle where initial permissions were simply set through the act of addressing the email to specific recipients. The issue was that there was typically no coupling between the ECM system and the email system and no lifecycle consideration. The newer collaborative tools seek to replace e-mail as the system of choice, but by default are not coupled to ECM systems; therein lays the danger.
As new collaborative modes emerge to replace or extend email, there is a need to insure the appropriate connection to an underlying ECM system is designed in from the outset! And appropriate permission management will be a key element to ensure appropriate, enterprise-wide and longitudinal transparency.