I recently ran up against the question of when to use a content/document management system and when to use a wiki for content inside an organization. I had some thoughts of my own on the subject, my customer had some other thoughts, I went out the Twitterverse for advice, and had an interesting dinner discussion at home to see what others had to say. The results were interesting.
I ended up having a phone call with David Bressler, and thanks to Theo Priestley I shared some tweets with Chris Bennetts-Cash and Andrew Smith, after which Andrew wrote a blog post that summed it up as follows:
Use a wiki for pure content that requires no level of security and maximum levels of accessibility. Use a document management / ECM system for everything else.
Although I come from a more traditional ECM environment, I tend towards a definition coming from the other direction, although likely with a similar effect: use wikis for all internal content by default, unless specific factors dictate the use of ECM. If you think about it, much internal content follows some basic patterns:
- It’s created by more than one author
- It must be accessible to a wide audience inside the company, but is not required outside the company
- It requires frequent updating, but doesn’t need approval or versioning for editing
There’s a ton of content sitting out there right now on companies’ shared network drives that follow exactly that pattern: documents and spreadsheets that are regularly updated by multiple authors for things such as project status, departmental administration, meeting agendas and even collaborative design documents. Some of that content needs to have the edit permissions restricted to a smaller group, but still follows the same general characteristics, such as procedures and support documents.
There are, of course, many types of content that does need the more industrial-strength management capabilities of an ECM system, and here’s the list that I came up with:
- It originates with or is sent to external parties, since I’m considering only internal enterprise wikis here
- It only exists logically as a “document”, e.g., in PDF form (this is usually something that originates external to the organization, so would be covered by the previous point anyway)
- It’s in a format other than plain text where the wiki can’t easily support the creation of that sort of content, e.g., drawings or spreadsheets
- It requires a precisely-formatted print-ready version
- It requires versioning, particularly where milestone versions of documents are created for approval
- It requires fine-grained security control.
- It requires records management and/or retention management, typically for audit or governance purposes
I fully expect some of this second list to start to emerge as wiki functionality over the near term, and although it’s not clear that ECM and wikis will ever merge as a concept (much less within a single product platform), there’s going to start to be a lot more overlap. There’s also hybrid concepts, such as having a wiki page link to a document in an ECM system so that collaborative discussion can take place on the wiki, then changes made through the strict ECM environment; or situations where content starts collaboratively in a wiki, then needs to be converted to a document and stored in ECM when it reaches a certain point where ECM functionality is required. Lots of grey areas, in any case.
If you’re using both ECM and wikis internally, I suggest that you start with the default position of everything going into wikis, then work back from there using the second checklist to figure out what needs to go into ECM instead. Just please don’t leave it out there on the shared drives, because unless you have enterprise search, no one is ever going to find those documents when they need them.
Maybe thinking like this is good, ECM and wiki does share a lot of traits and I can see a future where ECM solutions deliver wiki as an additional module
This has got me thinking. Our own product, workFile delivers an ECM solution as well as a complete BPM platform (though the later is still at a beta relelase). There is no reason why we couldnt open this up further to deliver a wiki envionment.
This type of solution would work perfectly, as it delivers a single end user experience that accesses all modules, wiki, ECM and BPM…
Glad that I could be an inspiration!
Thanks for the article. As a startup, we are entering that decision point right now and this has led to a lot of discussion internally. We have a ton of Power Points and Visio diagrams which represent "finished products" of much collaboration and design. We feel that those documents should be versioned and put in ECM. All of the work and discussions leading up to those finished products are perfect for the wiki.
What are your thoughts about business users versus IT users. I tend to think that most business users (non-tech savvy) will only use wikis to search (read-only). I don’t see them collaborating via wikis. What do you think?
Check http://www.xwiki.com/
starts as a wiki, ends as an ECM and more. I’m pretty ure they are not alone on this market
(disclaimer : I have no interest whatsoever with this company)
Some pros and cons for wikis.
http://plmtwine.com/2009/04/27/5-reasons-why-wiki-fails-for-plm-collaboration/
Mike: In my own experience business users like to gather information rather than contribute, by that I mean, they search for the information / documents etc they need to use for a reason relating to their current task. They dont then want to update anything. This is where BPM with ECM solutions really help business processes and greatly increase staff efficiency….
I myself do to take a different stance on wiki vs ECM than Sandy.
http://andrewonedegree.wordpress.com/2009/05/22/wiki-or-document-management-ecm/
All your discussions and decision making could well go into a wiki, however any versions (however rough or draft) should be in your ECM solution. My own feeling now is that this type of wiki information (the discussion on how you came to a decision) should be stored with the ECM content, therefore a single user experience for both wiki and ECM for both IT and business users….But for me, starting point has to be ECM, not wiki
Mike: I agree with that most business users will not update a wiki. For that matter, most Wikipedia users don’t update it either – that doesn’t mean that it’s unsuccessful. In general, if you can get 2-5% author participation in an enterprise wiki, consider it a success. In every business community, however, there are those who are a bit more tech-savvy (or more interested in learning) who are willing to try it out. I’ve recommended wikis to insurance clients, for example, for their underwriters to keep a collaborative discussion area for how to handle unusual situations that aren’t covered in the procedures manuals. In time, I could see the procedures manuals taking on a more wiki-like form, although there would likely be some restrictions on who is allowed to author certain content.
Even if most of the readers don’t contribute (or possibly don’t even have author permissions), using a wiki allows the authors to do quick updates more easily and without any additional publication steps.
I agree with Andrew that the project artifacts should go into the ECM: they would fall into one or more of the categories that I mentioned for determining if something should be in ECM. The wiki provides a good place to discuss them, or even to start collaborating on the content before it becomes a “document” project artifact.
François, I think that the problem that wiki vendors will have moving into the ECM space is that enterprises tend to still be suspicious of wikis, and might not see a wiki platform as a suitable place for storing their documents. I have many conservative clients that still think of wikis (and mashups, and other social media-inspired technology) as toys, and wouldn’t consider them as suitable technology for storing any “important” information. These attitudes will change, of course, but I suspect that we will need to see the success of some of the large ECM vendors at introducing wikis in order to validate the market for the rest of the players.
I agree with Sandy re. enterprises being suspicious of wikis. I think it will be really hard to have a wiki move into an ECM environment.
On the other hand, I can see it being very very easy for ECM vendors to deliver wikis, and as such, bring along credability and appeal to enterprises…..
Sandy – I was interested in reading, “it’s not clear that ECM and wikis will ever merge as a concept (much less within a single product platform).” Interesting to note that this is already out there, or at least in a nascent fashion. I work with MS SharePoint every day, and while no-one would claim that it’s a mature ECM platform (or, for that matter, a particularly ‘mature’ wiki ;), one of the important concepts in it that I like is that it treats a wiki page as a properly content-managed entity from the perspective of describing, versioning, managing its lifecycle, etc. I like to say to my customers that the value of SharePoint is as an end-to-end information management platform that can help them manage documents, data, etc. through their entire lifecycle, from creative inception to records management to archiving.
I realize it’s still a somewhat incomplete story, but it’s worth looking at.
Hi Carsten, good point about SharePoint. I suspect that’s functionality that was added in 2007, so that will require that a lot of companies get off 2003 sometimes soon!