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.