Document Management Tools

["Engstrom, Douglas D." <EngstromDD -at- PHIBRED -dot- COM>]

Tammy:

This is written in response to:

******************
Some of you may remember my query to the list last year about document
management. My company never did come up with a system, and as we
continue to grow we're realizing we can't hold off much longer.
******************
That's probably good.  There is a certain amount of unavoidable pain
involved in implementing a document management system, and it doesn't
hurt to let the problem develop before you try to solve it.

You asked for advice; here it comes....

First, do not underestimate the difficulty of this project, and do not
overestimate what the tool alone will accomplish for you.  There is a
tendency to think of a document management system as one of two things
that it isn't.  Some organizations view it as a spiffy little utility
that can be flung on to user desktops, and then ignored from the
organizational support standpoint.  In reality, it is a small
client-server development project, and needs to be treated accordingly.
Some organizations view it as a "technical fix" for what is really a
cultural and organizational problem.  The old saying applies: if you
automate a mess, you just get a bigger, faster mess.

There are three layers to an automated document management system,
listed here in descending order of importance:

1) Corporate culture
2) Document management procedures
3) The automated system

If your corporate culture is anti-recordkeeping and anti-standardization
(sometimes called "entrepreneurial" in recruiting literature), if the
cry of "Where's the current version of the source code?" is met with a
mass search through local hard drives, desk drawers and filing cabinets,
if use of the word "methodology" is met with a blank, uncomprehending
stare and nobody can answer the question "How do we know when a project
starts?", you've got your work cut out for you.  Under those conditions,
I would not undertake this project without sponsorship from someone with
a very deep pocket, a big stick, and a very strong commitment to
document management as a business activity.  Lots of big things need to
change, and they aren't going to change just on your say-so.  Besides,
you don't want the full costs of migrating to a more rational culture to
show up in your expense lines alone.

If your culture is reasonably supportive, the next thing to look at is
your existing document management procedures.  If your procedures are
fairly tight, you're in great shape.  Your users will be used to looking
at documents from a "life cycle" perspective, "control" will not be an
alien and scary concept, and there will be some awareness of a search
algorithm that is more sophisticated than "Ask Bob what he did with
it...."  In this situation, all you will need to do is tweak the
existing procedures a bit to accommodate the new tool, or take advantage
of the tool's capabilities.

If your existing document management procedures are lax, but the culture
is supportive, it's a bit more work, but doable.  First, establish what
you're trying to accomplish by managing your documents.  Are you seeking
some sort of formal certification? (ISO 9000, FDA, etc.) Are you trying
to move procedural knowledge out of individual heads and make it a
corporate resource? (It's no longer a matter of "Bob knows where it is
and if it's ready" but rather, "Anyone can look it up here.") Are you
seeking some sort of general efficiency goals? If so, what are they?

Once you know your goals, let them drive the logical design of the
system.  All systems will result in some sort of categorization of the
documents, and you will need to establish what categories and
combinations of categories are most useful to the people working with
the documents.  This is exactly like the "user requirements" phase of a
software development project.  Blow this portion, and your tool
selection is irrelevant--your system will stink no matter what.

Once that is done, think about tool selection in light of your
requirements. If you've done a good job of analysis, selection should be
a relatively straightforward exercise in selecting systems that claim to
do what you want to do, and then verifying those claims. Also give some
thought to how much time administering the system will take.  And of
course, the usual criteria of vendor stability, migration path,
flexibility and compatibility with your technical infrastructure all
apply here.

We use DOCS Open, but I wouldn't say it's the be-all and end-all in
document management.  In fact, if I'm involved, I want to look at tools
again before going enterprise-wide.

Once you've got your tool selected, design your project.  Include time,
dollars and resources for installation, testing, user training,
documentation--everything.  Remember, this is a small client-server app,
and CS apps tend to fail during the rollout phase.  If your management
is locked into the idea that "this is no different from an MS Word
upgrade" you've got a serious uphill fight on your hands.  Pay special
attention to the documentation.  Your customization will probably render
the vendor-furnished documents and help files nearly useless to
end-users.  If users are not properly trained and supported, you will
lose most of the system's advantages.

******************
I've looked at PC Docs Open, OPTIX, and the developer CM tool called
SourceSafe. OPTIX is not at all what we need, and PC Docs Open (what a
weird name!)
******************
Actually, the name of the company is PC Docs, after their original
product.  The product is called "DOCS Open", which stands for Document
Organization and Control System.  The "open" portion of the name refers
to the product's ability to run on a wide variety of networks, clients
and databases.

Feel free to write if you have more questions,


Doug Engstrom                           "It's hard not to rock the boat when you're
engstromdd -at- phibred -dot- com           sailing against the undertow."
                                                                --- The Indigo Girls

#######################################################################
My opinions only, not those of Pioneer Hi-Bred International, Inc.
#######################################################################

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html