What is Electronic Document Management? And is that like KM or CRM?
Electronic Document Management has many names Imaging, Knowledge Management and Customer
Relationship Management. They all share one common element though, the electronic
management of documents whether paper or electronic through a common indexing database.
So what are the key differences?
- EDM – A system that concentrates on storage of electronic and scanned documents
- KM – A system that concentrates on storage of electronic and scanned documents through
a knowledge based index and data mining.
- CRM – A system that concentrates on storage of electronic and scanned documents as
well as customer interactions through a customer focused index.
Do you have to pick just one?
No. The titles above have been developed over time to better describe some of the
heavily focused areas of EDM but almost all of them contain the same elements or
modules.
Elements of EDM
An EDM solution is NOT just scan to file, but the storage and retrieval of the images.
- Input - Images from a scanner, electronic data from a mainframe or electronic documents.
- Storage - Electronic repository with index.
- Retrieval - Accessing the files and images utilizing a viewer, a third party software
interface and / or an e-mail interface for workflow.
Input
Input is relatively straight forward with three major options to input documents:
Scanning, COLD and application documents.
Scanning: This is the most frequently thought of action when discussing EDM and usually
the least time or budget consuming aspect of the entire process. Scanning entail
simply acquiring a scanner that can accomplish the expected volume at the quality
required. Scanners vary in speed from HP ScanJet at 2-3 Impressions Per Minute to
a BancTec scanner at over 2,000 IPM. Some important features to keep in mind however
are: scan speed and at what resolution, Document feeder, maximum original, minimum
original, duplex capability and color or B&W. Additionally, many of the newer digital
copiers can also be used to scan with additional hardware in some cases. The only
issue with adapting a copier is that in some cases the additional hardware can cost
2 – 3 times as much as a good stand alone scanner. Additional items to consider are
interface cards and software. These items allow the images to be viewed at a computer
and automatically clean up the images.
COLD: COLD stands for Computer Output to Laser Disc, however technically it does
not go directly to disk and not everyone still uses laser discs for storage. It is
however, the direct output from a computer, typically a report. This type of input
is particularly useful for organizations that are used to printing out reports for
distribution and storage.
- Outputting “greenbar” reports directly to electronic files.
- An additional feature of COLD is data mining or the extraction of data from several
reports. This requires either extensive indexing or usage of advanced languages such
as XML (Extensive Mark-up Language).
- This is a extremely useful feature for companies that are not using an ERP (electronic
resource planning) program such as SAP.
Application Files: EDM systems can be used to store electronic documents that were
never paper.
- Because of the storage method for files within an EDM, many organizations utilize
a feature to store application files. The files will be stored along with all revisions
and versions in the repository. Additionally the files will be indexed.
- The systems will store the file and make it available through the system for all
users within the security rights.
- The system will not act as a work around for program files, i.e. if a Microsoft Project
file is stored within the system the end user must have Microsoft Project to open
it.
Indexing
The easy part of EDM is the scanning and storage of an document. Many off the shelf
programs contain these two elements and you can even get them for your copier. The
difficult part is the indexing. Indexing is the process of creating a database that
contains customized field(s) of information concerning the document. These fields
are used in order to retrieve the documents. To illustrate how important this function
is, let us look at the situation where there is no index. Company A produces approximately
one 4 drawer file cabinet (approximately 20,000 documents) of paper per month and
is using a scanning package that came with their copier to electronically input the
paper and a desktop computer to store them. They are managing to eliminate the cost
of space by scanning the documents but they have no way to retrieve any given document
other than by naming the file in such a way as to help them find what they are looking
for. In this example let us assume that they needed to retrieve an invoice for a
computer that needs to be returned under warranty. No one is quite sure when exactly
it was purchased but it was probably somewhere between a year and two years ago.
Because this company has been using a date based file structure, that would require
some one going through approximately 240,000 documents in order to find the invoice.
Without an index, you are going through the electronic version of taking those files
and dumping them into one large pile.
Indexing itself however is still no guarantee. This element requires some careful
planning in order to ensure it’s success. The two key areas that need some severe
planning are:
- Indexing File Structure: This is either the largest success or the largest time bomb.
The file structure dictates how the indexing gets stored and in what database. If
done correctly this information can interface with a myriad of outside systems such
as accounting packages, sales automation software and ERP packages (SAP, PeopleSoft
etc.). If done incorrectly the issues can be massive. From the annoying such as interfacing
with no other programs to the fatal such as database crashing or proprietary database
issues. Database crashing is relatively uncommon however all databases are not made
to handle unlimited amounts of information. Careful attention needs to be paid to
what limits exist to prevent the database from hitting it’s functional wall. Proprietary
databases cause another issue, namely transitioning. All programs have a life that
requires either upgrading or transitioning to a new platform. Proprietary databases
halt that progression by making it extremely difficult and expensive to transition.
As a rule of thumb, in order to transition from a proprietary database to an open
database plan on spending roughly one to two and half times the original cost of
the software and implementation. These costs can easily run into the millions of
dollars and frequently cause clients to simply print everything out and ditch EDM
all together.
- Indexing Field Planning: Indexing fields are the information that gets captured from
a document in order to aid in the retrieval process. For example, a law firm may
index the client number, case matter, name of the person and one or two salient details
from a deposition in order to ensure that the can pull back up the information. Think
of this function as programming a search engine. If you want to pull a document back
up you need to make sure that you have put the information that you need into the
search engine in the first place. For our Company A example, they might have indexed
the invoice by date, vendor, equipment classification, and / or serial number of
the equipment. The two dangers in indexing come from either not putting enough information
in or putting in too much. If you do not put enough information in a search might
pull up too many documents. Going back again to the Company A example, if they only
entered a date as an indexing field they would be no better of than they were in
the no indexing situation. Equally dangerous is the situation where too much information
is entered. Too much indexing causes two issues. The first is that unless you are
using OCR (Optical Character Recognition) indexing requires somebody to enter the
information and even if you are using OCR you are going to want to have someone double
check the computer. This labor piece of EDM can get rather expensive if you are indexing
too much. Additionally, the more you index the more you are storing in your database.
This piece drives the database sizing where as the interfaces with outside programs
drive the database or third party interface type. Even though you may be inputting
very few documents if you are indexing every word you would need a massive database.
Storage
Storage is broken into two major areas, the repository and the database.
Repository
The repository is the physical storage device for the images and files. Although
this device could be a simple hard drive most system use one or all of the myriad
of mass storage devices here are just a few:
- RAID Drives - Redundant Array of Inexpensive Disks - A series of hard drives that
act as one large hard drive with varying levels of redundancy. Virtually unlimited
storage capacity with a good RAID system.
- Laser Disks - Good for permanent storage of information. Require expensive Jukeboxes
for the organization of the disks.
- Tape Drives - Inexpensive method for storage, long retrieval times.
The key differences between these storage devices is level of permanency, speed of
retrieval and of course cost. RAID drives offer the fastest retrieval time but the
least level of permanency. Whereas the tape and laser disks offer better permanency
but slower retrieval times. The keys to designing these storage systems lie within
a clients document needs for archiving and actual retrial figures. In most cases
not all data needs to be kept live permanently so usually a mix of two or three storage
types is best. Additional considerations needs to be paid for legal requirements.
If there are legal documents within the system level of permanency will take precedent
over retrieval speed.
Database File
A great deal about this function was discussed above in indexing however there are
a few more thing to keep in mind. The Database file is the roadmap to the files contained
within any EDM, KM or CRM system. Without it there is almost no way to retrieve documents
and information. However, even if you have a database file there could be serious
problems when it is time to transition to a new software or have this system talk
with other pieces of software. First, any database needs to be ODBC or open database
compliant. That basically means that it can communicate with other databases. This
does not always mean that it will not need a third-party software to do so but at
least there is a method to let it communicate. In the early days of EDM very few
databases were ODBC. This lead to massive communication and transitioning costs.
Second, you need to determine what systems you want your EDM to work with BEFORE
you select a vendor. Not all systems ODBC or not play well with all programs. Some
were designed to work better with certain pieces of software than others and a considerable
amount of time needs to be spent in this area.
Retrieval
Retrieval is the process by which the documents, the data (in the case of COLD) or
the index gets retrieved by either the end user or a third-party piece of software.
The one common theme throughout this process is that at any level most advanced programs
will allow a system administrator to set security levels for the interfaces by end
user. What that really means is that you can let an end user have access to the whole
system but not to all information contained within a document or database. For example
if a hospital wanted to implement a EDM system to organize all patient records they
would face the issue of non authorized personnel looking at the patient name and
SSN. These advanced systems would allow the administrator to mask these field within
an image or file so that only authorized personnel would be allowed to look at them,
thus gaining compliance with the new HIPPA laws, while streamlining their paper processes.
Retrieval has been broken into four parts for our review.
Viewer
The viewer is simply the interface that allows the end-user to search through the
system to find a document or file. Most manufacturers use a simple web-browser to
do this, however some use a proprietary viewer to do so. This is the only place where
we will tell you that proprietary will really make no impact. If the software that
fits your needs uses a proprietary viewer it really will only impact the roll-out
of the program.
Workflow
Workflow is the use of an EDM system to replace a paper process. Typically most systems
do this through a pre-defined system for paper and e-mail notification. To illustrate
this let us look at our Company A. If Company A had workflow in place at the time
of placing their computer order, the original PO would have been stored and the system
would have prompted shipping to scan in the shipping manifest, the end user to enter
the serial number and scan in the original warranty and accounting to scan in and
pay the invoice as well as the check number. These documents would have been grouped
all together for the IT manager whose is trying to process the warranty return. Workflow
is very popular with organization who have defined paper processes as part of their
core competency. The systems allow for organizations to track paper flows and department
efficiencies. Imagine the end of, “well my department didn’t receive that”. Now you
would be able to see that the department did receive a notification that their process
was ready on the 15th and that on average that department takes a week from notification
to get to a process.
Outside Software Applications
Outside Software Application can gain access to an EDM program to help eliminate
the need to create two databases or open both systems to simplify the processes.
For example, if the computer issue at Company A originated in Accounting, an end-user
could find the original PO in the accounting system, press an interlink button within
the program and immediately pull up all document relating to the PO.
ERP Programs
In all examples above we have been using the EDM system as the hub of information
bridging the gap between sales automation systems and accounting or patient billing
and patient records areas. In the case of ERP programs such as SAP or PeopleSoft
the opposite is true. These ERP systems will act as the hub and the EDM system will
act as a spoke. The only difficult part is that ERP systems use special databases
that the EDM systems cannot share. So, in order to get every thing to work together
you need to use a third party software to get the two databases to synchronize. The
only issue is that not all EDM’s work with all third party synchronization pieces.
If you are running an ERP, plan on a lot of extra time to get an EDM to work with
it.