Many companies, encouraged by magazine articles about document management and knowledge management, feel that all documents should be managed by the same tools, and potentially be kept in the same enterprise repository.
There are really three types of records that any business needs to keep:
the business, products, procedures, operations, and all the information about what the business is and the constantly changing way it is operated.
record of each event that occurs in a relationship. For many companies, the events are customer documents, so for simplicity they will just be called "customer records," but it could be a record of any kind of event - the tax or electric bill, a shipping notice, or a court order.
the current state of the relationship, as a result of all the preceding transactions and procedures. Our on-line computer systems provide this "current state."
|What information||How Stored|
Documents that originated with the customer often arrive as paper or fax documents. At best, the electronic storage of these documents is an image, since we do not have the original electronic data (if it ever existed). Other documents, received on behalf of the customer (rather than from the customer), are also kept "in the customer file." The company response to the customer is also part of the customer file.
The common thread of all these documents is that they represent an event that occurred at a point in time, and we need to keep a record of that event. The customer sent some information (or a request or order or...). Or a credit report was received for this customer. Even if the information is changed (the order was cancelled, the credit report was corrected), the customer document file keeps the history of what happened.
In contrast, the database systems (that run the company) reflect the current state - they are constantly updated (the cancelled order is removed, the corrected credit report replaces the incorrect information). In contrast the customer file keeps the record of each step along the way. It may be used to explain why the customer was considered a bad credit risk for a few days until the corrected report arrived. The database system may have the conclusion that this is a good customer, while the customer file has numerous bad credit reports, and numerous letters to straighten out the errors.
Every company has documents that describe their products and and services, and how they are made and sold. These administrative documents are constantly updated to reflect changing products and improved procedures. There are many versions and renderings of each of these documents - Archived documents that describe the products and procedures in effect at any time in the past, plus the current "official" documents, plus numerous drafts of documents, approved and unapproved, for future products and procedures.
Numerous magazine articles have been written about document repositories, and the potential advantages of consolidated enterprise document repositories. Unfortunately the credentials of many of these authors is only that they write technical articles for numerous magazines - they rarely seem to have real business experience. The irrefutable logic presented in these articles has led companies to make plans and issue requests for proposals for integrated software systems. The products put forth are often crude combinations of multiple products.
Why is there such a problem? The characteristics of the data and the requirements of the systems are quite different for these documents.
|Factor||Administrative Documents||Customer Documents|
|Changes||Frequent Changes||Never Change (Correcting the index, such as the customer number, of a document is sometimes considered a change, but there is actually no change to the document itself - only to the database for locating the document. One of the few routine document changes is document split and combine. For example, if two documents are received in a single fax, and are thus accidentally stored as a single document, the user may need to split the original 5 page fax into a 3 page and a 2 page document, stored separately, perhaps even associated with different products or customers.)|
|Versions||Many - the Currently approved version is the default, but an archive is normally kept of the documents that were official at each date in the past, plus drafts of future versions in various states of development and approval||One. If documents are changed (as above), the original unchanged version is normally retained as part of the audit trail, but is not routinely included "in the file."|
|Drafts||Often several (future versions)||None|
|Renderings||Several renderings of the same document are stored by many document management systems. For example, this may include as an editable format (such as WORD) a format for uneditable presentation such as PDF, a format for web presentation (HTML), and a format for quick search (ASCII Text)||One; when special rendering is required (such as to deliver a copy of a document over the web), it is normally generated dynamically.|
|Typical active use||1 year||3 days|
|Typical Retention||3-5 years||7 years or more|
|Audit trail||Informal if any||Unalterable legal record of when the document was received and how it was processed|
|Concurrent users||Numerous readers, multiple editors/authors with controls to prevent conflicting updates||Normally one, but must support concurrent read-only users.|
|Storage Format||Various, including editable formats (that are convenient, but may need to be converted for new versions of programs)||Non-proprietary formats that are unlikely to become obsolete over the life of the document. This is sometimes called a "durable" format.|
|Conversion||Periodically required to migrate to new versions of viewing and editing tools.||Impractical due to high volume of rarely used documents. Therefore storage should be restricted to "durable" formats that are unlikely to need to be converted.|
|Products||Document management systems such as PC Docs, Documentum||Numerous Image (input) and COLD (output) products. Attempts to use document management tools for these documents have failed.|
|Volumes||Low (but it could still be tens or hundreds of thousands of documents)||High (it could be millions or even hundreds of millions of documents)|
|Size of each document||Many are in editable form, which is relatively efficient - typically about 4 kilobytes per page, and can be compressed (if desired) to about 1 kilobyte per page.||Many are in image form, which typically starts at 500 kilobytes per page, and is always compressed, typically to about 50 kilobytes per page.|
|Storage Requirements||Nominal - normal network devices||Very high (large number of documents, large size of each document), normally requires storage hierarchy (e.g. both magnetic and optical discs).|
|Metadata - information about the contents of the document||Key word or full text indexing, to encourage sharing of information and reuse of previous work. (Generally this is called knowledge management.)||Most companies can only afford to identify customer/contract, type of document, date received, etc., since this information is typically entered manually. Someday it may be practical to do more extensive indexing.|
|Legal Status||Submit these documents as evidence as a business record. For example, it might be documentation of standard operating procedures required to establish credibility.||The underlying systems are designed to support evidence either under business records rules, or in the case of images, under the "microfilm" rules.|
|Regulatory requirements for storage||none||Some. For example, equity based products are subject to SEC requirements for write-once storage media before paper can be destroyed.|
|Primary creators||Management and staff||Operations (mail room, computer output, electronic input from fax, web, telephone)|
|Primary Users||Everyone!||Operations (telephone service representatives, etc.)|
Since the requirements and usage are different in almost every respect, there are strong arguments for making these separate systems, rather than trying to force them together, and making substantial compromises for everyone.
Back to the home page
Send e-mail comments to
©2001 by Charles A. Plesums, Austin, Texas USA. ALL RIGHTS RESERVED. You may license additional copies of this document through a nominal royalty payment as specified on www.plesums.com.