Wiki or Document Management / ECM?

22 05 2009

Yesterday I was asked if a company has both a Wiki solution and a document management repository, how does that organisation decide which is used for what? It’s a good question, as there are some areas of overlapping, but I feel once you define what the actual content is, its accessibility needs and above all security requirements, you should be able to decide where it goes.

For the Wiki…

Ok, so what content would I place in a Wiki. Well first off, let’s remember that typically a wiki is open to everyone (within that organisation) and as such, any one member can update it. Wiki’s are very “loose” though often are somewhat limited to what content medium you can store in them and access easily. One of the selling points of a wiki is the fact that anyone can contribute to its upkeep, ensuring that the information is kept up to date and correct. Typically a wiki stores electronic content as web pages or displays stored content as web pages.

So what would I place in my organisations wiki?

Firstly, content that is always changing and that I don’t need to version control.

Secondly, content that is not to be released outside of the organisation.

So what examples do we have to make this a “real world” and “useful” blog post. (I do hate it when all you get is examples that just don’t work in the real world!). Ok, well the obvious one is a glossary. But I want to build on this. Think of your glossary as not just a glossary of terms or definitions, rather than a glossary of everything that is going on within your organisation or is useful to staff members. When you think like this, a glossary could consist of case studies, internal updates, information on particular departments, certain process guidelines, good practices, information on certain places to eat your lunch, staff events, suppliers used, reviews etc. etc.

Would I place “physical documents” in a wiki, electronic or other….The simple answer is no. Only place content in a wiki, if that makes sense, not the actual document from which it came from. Once you place physical documents in a wiki you loose that fluid nature in which a wiki is used by users, and you will find it hard to locate that document in the wiki.

Always remember security of your content. If that content needs to be managed or restricted, then it should not be in the wiki, simple as that. If it requires to meet some compliancy guidelines, then again, it has no place in the wiki.

For the document management repository…

Ahh, well with a document management repository or ECM solution, you have a platform geared to supporting a wider range of content types. You also have far greater control over accessibility, delivery, versioning and retention periods. All access and activity can be recorded, but each user has to be identified, either via dedicate security within the document management solution, or integrated windows security for example. This means access and privileges are always governed by a member of staffs individual security access rights, so not everyone can view or update this content.

So what am I to place in my repository?

Firstly, any public facing or external documents need to be controlled and the original versions kept. This applies to both electronic documents and scanned images. You must must must always keep the original and have quick access to these.

Secondly, content that requires a version trail. If it is going to be updated and or has a lifecycle (by this I mean it goes through iterations of drafts, releases, publications etc.) then again, you need this in your document management repository. Ideally you will be able to access any version of a particular piece of content (document in this case) and have the ability to “roll back” to that version.

Thirdly, you require some form of classification of particular types of documents. Typically this is to help identify and find those documents based on particular types of meta-data and actual meta-data value. You can also still retrieve certain files based on their content, however for scanned images etc. this sometimes can be tricky and require a deeper level of document capture and retrieval sophistication. For me, you should always be able to find your files based on meta-data value, if not, something isn’t quite right…

Fourthly, your files have a retention period. This could be based on the type of content you are storing, so in some cases you may require to keep a content / document for several years, after which it must be deleted.

In short…

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…..

Advertisements

Actions

Information

8 responses

22 05 2009
djbressler

Very nicely put.

Imagine if you could tie the content in the two systems together, and capture the process for which the content is used, along with “social interaction” around the business so that people could collaborate better. Content owners could provide knowledge that is captured in the form of forums or conversations around the content, documents or processes.

David

26 05 2009
Andrew Smith @onedegree

Hi David, thanks for your thoughts. I think you make a great point, that brining the two different repositories together can make life easier for a user and promote knowledge sharing at a greater level. No doubt aiding collaboration and reducing business process cycles…

I see this type of funtionality you describe not provided by a wiki, or even the DM solution. I see this being provided by a VAR of your DM system as a seperate deliverable or via a software provider given access to the wiki and dm api.

I am a firm believer in bringing everything together as much as possible, especially if it removes the need for staff visiting different applications / sites for different content. A single desktop user expereince should always be aimed for, though not always practicle I know….

29 05 2009
Column 2 : ECM vs. wiki

[…] 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 […]

1 06 2009
Andrew Smith @onedegree

Sandy Kemsley offers a slightly different default position in her own blog…you can read it here…

http://www.column2.com/2009/05/ecm-vs-wiki/comment-page-1/#comment-11301

3 06 2009
ECM functionality, let’s expand… « Andrew One Degree’s Blog

[…] of discussions with Sandy Kemsley (http://twitter.com/skemsley) about Wikis and ECM (see my post https://andrewonedegree.wordpress.com/2009/05/22/wiki-or-document-management-ecm/) For me, Wikis are an obvious feature to include into an ECM platform, after all they deal with […]

3 04 2010
iManage

Excellent topic to discuss really great help to think this.

30 12 2013
cloud based document management

The modified and upgraded features are its unique selling point.
This is the nature of collaboration, to take a document and
tweak it or revise it to make it better. Imagine the hours
saved if an employee can retrieve a document
in a few simple clicks, and send it to many individuals in a matter of seconds.

19 02 2014
ged gerenciamento eletrónico de documentos

In any type of business or organization, loads of information are normally created depending
on the niche. In other words, these systems have advanced features of history tracking with the help of which the user can access the documents saved in history versions for re-using the information in prior versions for research and auditing.
A document management system can be used to gather and organize all of these documents into electronic documents.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: