On being our own worst enemy

Sometimes you know you need something different and you ask for it. Then when you get it, you ask why it isn't like what you expected – based on your experience with what you already had…

I'm seeing this in new enterprise content management (ECM) products, especially around social media applied to Enterprise 2.0 concepts.

While ECM now covers a wide range of technologies, at its core many of the concepts come from document management. Those concepts are mature and consequently well-embedded.

Many, but not all ECM systems follow a 'folder' paradigm – Livelink is one such ECM system – and of course Windows and Mac OS has used folders for many years. Most people just expect folders.

In the case of Livelink, as collaborative tools like Forums, Blogs, Wikis, etc. were added it was 'logical' that these be offered in the context of folders (and other Livelink folder-like container types like Workspaces and Communities). In Livelink you can add a Blog to any Folder for example, if you have the appropriate rights.

This approach works well when the collaborative discussion is centered on related content.

For example, a set of product specification documents are reasonably grouped with a product discussion in a Project workspace.

In fact traditional knowledge management (KM) approaches emphasised the importance of providing context to documents – grouping the documents and the related discussions about them while they are used and when they are subsequently archived achieves this.

While Livelink collaborative objects must be placed in Folders, tools are also provided to find them irrespective of location. You can list all Blogs, Communities, etc. on one page, but in my experience almost no one uses these features – the expectation and habit of navigation to a folder location is just too strong! And when you give users a range of different approaches, they generally only follow one well worn path.

Social media comes at the problem very differently – it is people-centered
document-centered. You listen to what people are saying, and then create a social network based on who you want to listen to and the discussion topics you want to hear about. So users and topics become the organizing elements instead of folders. Topics are often multi-faceted and un-predictable, so are quite different from the parent-child taxonomy type of classic folders.

Sure you can add documents to the discussion, and you can link to other documents, but fundamentally you are saying, "I'm talking about this document," irrespective of its location. In fact a document is still best managed according to a document management paradigm in a repository.

Very shortly Open Text will be releasing Open Text Social Media – a solution designed to support social networks in an enterprise, both internally in the social workplace, as well as externally in the social marketplace of a company's partners and customers. The user interface is simplified in a 2.0 style, and focuses on what a user needs to network socially. It does not have the full set of document-centric options – and therein lays the rub.

Most people who have seen Open Text Social Media love it! It's easy to learn and easy to use. The key to that ease is simplicity – that means there can't be too many options and the ones that there are revolve around social network activities.

So it's interesting to watch people start asking for folders/hierarchical classification and a whole raft of document management features – they love the new stuff, but want the familiar as well. If we gave them what they asked for, then they'd loose the initial benefits.

But we haven't forgotten the document management world. Open Text Social Media allows you to talk about documents in other repositories like Livelink, while they remain where they are in an organized hierarchy, with appropriate permissions, lifecycle controls, metadata, records management, etc.

In the real world of the business or government enterprise, it's necessary to balance the what you want of 'candy' with the what's good for you of 'aspirin' (see video below).

Two paradigms. Two approaches. Designed co-existence!


Is there a Permissions 2.0 future for ECM?

ECM permissions

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
Then you give them additional control granularity, leading them to decide:

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
So, fundamentally ECM permissions provide options to restrict the useful sharing of information, and most users habitually overuse them when there is no need.

Collaborative transparency

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.

Interim conclusion

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.