eDMS Roshambo Part 2: Wikis vs eDMS

Continuing our discussion from eDMS Roshambo Part 1 | Reviving PnP Workflow and eDMS Online Content Management with Analyzer, Electronic Document Management Systems (eDMS) has a large presence in enterprise server software. Companies which rely on Policy and Procedure (PnP) compliance must handle and update internal documentation to comply with Federal, State and industry standards.

All of that costs money. These eDMS servers are not cheap. There are also SaaS models that keep it affordable, but the monthly cost is still fairly high. Most are direct enterprise models with onsite installation and maintenance. Integration of these eDMS systems is, as you might imagine, somewhat intensive.

Wikis versus eDMS / DMS – (Electronic) Document Management System

The power of wikis in a corporation is hotly debated, however the concepts of wiki collaboration are widely accepted. The question becomes how to get there.

Currently the position on Wiki collaboration has been carefully pushed back and forth – see How Wikipedia Works (Or Doesn’t) | Can Corporations Use Wikis? where the Stanford Business School sources put forth their objections to Corporate Wiki use.

Update Jan 21: My thoughts on Wikis in Corporations are disputed by none less than Stewart Mader!

Stewart’s book, Wikipatterns, is attractive and is first on my soon-to-read list. I actually stood in Barnes & Noble less than a month ago and my mom held it up and asked me if I wanted it. I couldn’t since I was unfortunately buried in research. Check out Stewart Mader’s well-worded rebuttal of my comments.

Now that Stewart has mentioned my site I’m holding out to buy an autographed version of Wikipatterns.

Let’s look at the eDMS collaboration workflow first.

From Wikipedia on Workflow within a DMS:

Workflow is a complex problem and some document management systems have a built in workflow module. There are different types of workflow. Usage depends on the environment the EDMS is applied to.

Manual workflow requires a user to view the document and decide who to send it to.

Rules-based workflow allows an administrator to create a rule that dictates the flow of the document through an organization: for instance, an invoice passes through an approval process and then is routed to the accounts payable department.

Dynamic rules allow for branches to be created in a workflow process. A simple example would be to enter an invoice amount and if the amount is lower than a certain set amount, it follows different routes through the organization.

From Wikipedia on Collaboration within a DMS:

Collaboration should be inherent in a EDMS. Documents should be capable of being retrieved by an authorized user and worked on. Access should be blocked to other users while work is being performed on the document.

This brings its own challenges, particularly if the document is large in scope, right? Which is where things tend to fall apart. Bringing all these different parts of a ‘document’ together, with the right styles in both appearance and verbage is where docs managers and info architects usually have job security.

It also happens to be where MadCap is targeting the usate of their improved MadPak with the Analyzer.

Rock Paper Scissors (RoShamBo): Wiki beats separate desktop tools & an eDMS

So here’s one blogger’s recent take on why to use a Wiki to do collaboration.

From Blog on Wiki Patterns: Why using a wiki instead of email or documents will multiply your collaboration effectiveness:

Because of its complex structure, the EDMS tends to compartmentalize content instead of letting relationships emerge, so it becomes a veritable black hole.

The wiki does a much better job because it allows emergent organization of content – people don’t have to decide which folder or section to put it in, they can tag it so it appears alongside other similar content. Also in a wiki, the fact that you put content directly on a page instead of uploading a file means it requires less effort for someone else to find it.

If it’s on a page, I can:

1. see it immediately, and
2. add to or edit it immediately.

The fact that I can see it immediately means I’m less likely to get distracted by the mechanics associated with downloading, opening, etc., so I’m more likely to remember something I might want to add. Then, the fact that I can edit it so easily means I’m more likely to make my contribution.

That’s the real power of the wiki.

I’ve already talked in a previous post about the disadvantages of PDF or other ‘black hole’ technologies with information.

Wikis provide a similar advantage to a help authoring workflow I was using five years ago with RoboEngine / RoboHelp and currently use MadCap Flare to author. So that’s nothing new, as long as that content can be repurposed and isn’t siloed the end user is helped quicker and it’s easier to update and distribute.

My Personal History Lessons in eDMS Pain

I remember my position at a San Diego based defense contractor once required setting up an intranet. As all the interests were voiced, one was insistent upon using SharePoint, a then-two year old technology from Microsoft.

Having been directly from eHelp for this position, I was more than familiar with RoboHelp X4 (they were soon to launch X5) and since we had a copy of this plus the RoboEngine, I was not exactly thrilled at the concept of managing yet another dedicated IIS server technology. Not to mention the two month long tedious install, testing, and configuration of the 2003 SharePoint Portal Server (SPPS).

The end result was, after assurances that the champion of the SharePoint concept was going to manage it, we ended up piloting the SPPS. Maintaining it was a nightmare, and unfortunately fell to me to implement. That version was tedious to update, to say the least.

Maintaining the SPPS files was a pain also, and unfortunately the hard pusher behind the adoption of the SPPS technology rather inconveniently found other work to do once SPPS was up and running. I can still hear him saying, “Oh, I’ll maintain it…”

A few years after I had left, I found out from employees who had recently departed that people preferred not the RoboEngine, not the SharePoint, but simple usage of the RoboHelp-generated company intranet which I’d whipped up in an afternoon.

This intranet was mainly designed to support HR document location and new employee introduction. Linked files within this format were easily searchable (I used index words within the topics and descriptive filenames) and it outlived the remnants of both the RoboEngine, which was plagued with restarts and failures and the SharePoint implementation.

eDMS Lesson learned

Intranets need to follow the KISS rule and be kept simple, or they will fail under their own weight.

eDMS Pains Summarized

The problems are that you stick all your docs in here, and maybe someone will find them, but we may/may not give you a search method, and indexing for search… well, let’s just say changes to those docs might show up tomorrow or next week.

Not to mention you don’t know who’s looking at what and without usage statistics you’re really not targeting your information properly for updating.

And last but not least, without a method to gain active feedback such as a blog has with Comments, improvements have to be emailed in, stored, reviewed, collated, etc. and they fall through the cracks or take a long time to accomplish.