About Process's

Within engineering there are two fundamental types of process. Not only the documentation but also the contractual arrangements, design development, and procurement, are all handled rather differently:

  • Construction of a One Off
  • Manufacture of Product

The manufacture process lends itself to shared model development with a relativeley few organisations involved in the assembly of the lower sub-elements, which are then further assembled into the next level, until an airplane or televison is produced. The manufacturing process will involve the development of "prototypes", and "first off's", etc.

Somewhat differently, a Hospital or a Sports Stadium for example has an over riding "get it right first time" requirement as each one is built only once.

The Construction Process has therefore rather different needs. These needs have become encapsulated into well defined process's through the use of standard types of contract defining responsibility for prpvision of design and construction information amongst other things. This has allowed the development of software to meet these well defined process's - much as software for accounting has evolved.

At the same time, the distinction between a Tool (for carrying out a task) and an Application (for carrying out a process) has become more clearly defined. The providers of Tools (incluing Microsoft) have extended their market place by the provision of "API's" and secondary embedded tools such as "Configurable WorkFlow" to allow the tool itself to become configured into what might be termed an application. Applications on the other hand (especially on the desktop) can make use of Tools in much simpler and more open manner, often without restricting the Application to a particular tool.

An example is launching aViewer. The Application asks the operating system to "View" a particular document. The Operating System then launches the appropriate viewer depending on the preferences set by the user of the desktop. Linking an application to a specific tool has also become easier through operating system developments such as "com objects".

Another view is that there are two distinct process's relating to Teachnical Documents, and that each is normally handled separately.

PlaceDesign or Drawing OfficeProject Management Office
TasksCreation and Revision of Deliverables

Publication of Deliverables
Project Management of Deliverables

e.g. Obtaining Approvals

It should be pointed out that documents realting to specific functions such as incoming invoices within an accounting system, should be handled by the appropriate (e.g. accounting) application.

Return to Contents 

About Document Properties

The following table describes the five fundamental varieties of document which have to be generated and handled within a construction environment. The comments made begin to discriminate between the two types of solution discussed in this paper - EDM and CEMDC.

Basic Document VarietiesComments

Own Technical

  • Has revisions
  • Publish revision on release
  • Only unissued latest revision may be changed

Other's Technical

  • Has revisions
  • Revisable only by Others
One's own technical documents (or deliverables) are generally created and revised in products such as CAD or Word Processors. The repository within which the documents are stored may be managed by an EDM package. When a revision is ready for release, it should be published.

Process Management requires
  • Transmittal Notes
  • Acknowledgement Notes
  • Comments Sheets
  • etc, etc
It is STRONGLY suggested that ALL Deliverables are published in PDF or similar format which allows Redlining but not Revision.

Associated process management documents must be generated from metric information stored in a database.

Own General

  • Once distributed, may NOT be changed

Other's General

  • May not be changed
One's own general documents may be generated from information (including the content) stored within a database.
There is no need for a separte doicument creation function.

Other people documents may be scanned in, OCR'd, and attached to a database.

Own Miscellaneous

  • Time Sheets
  • Daily Record Diary
  • Snagging (or Inspections)
  • Minutes of Meetings incluidng Agenda and Actions
  • Contemporaneous Notes & Contacts
  • Event Schedule and SDRS
ALL these documents contain metric information such as associated actions, and action dates. As such the information from which the document is created is best stored in a database.

Return to Contents

About CEMDC Applications

They are a vertical market application for project management document control in an engineering or construction environment. Like an accounting application, they are based on a structured database in which metric information is stored. In general terms applications work "out of the box", with changes in behaviour being made by settable parameters in conjunction with user definable categories.

The database structure normally includes "background information" such as lists of people, jobs, work packages, correspondence subjects, etc. They also usually include an embedded report generator such as ReportPro or Crystal Reports which have a "designer" allowing the user to configure the look and content of reports.

The feedback and experience from their many users (often over many years on the same major project) is encapsulated in the next version. This ensures that as new managament methodologies arise and exiting ones are improved they are incorporated into the software and released to everyone.

In addition, the latest concepts and technology to emerge are continuously adopted. An example is the general document, where the history is as follows:

  • Generated by a word processor, distributed on paper, and registered in a database
    • Highest Clerical Effort
  • Instead of being on only on paper, the electronic copy could be emailed
    • Reduction in distribution effort
  • Instead of being generated by word processor generated as an Email, printed and registered as before
    • Further reduction in clerical effort - no word processor required
  • Generated directly from the registration information (including content), printed to PDF and emailed, or on paper
    • Minimal clerical and distribution effort
  • Generated with EDI and HTML, thus allowing:
    • automated registration by recipients with a conformable application,
    • electronic response by respondents with no systems.

They generally include methodologies which are too complex to be configured in and EDM system due to the limited nature of the API and WorkFlow structure, combined with limitations to the structure of the database.

An example of a process which cannot be handled is Event Scheduling, and Suuplier Document Requirement Scheduling (SDRS) which monitors the provision of technical documents to a delivery schedule the dates for which are taken from the Event Schedule.

Additionally, CEMDC applications may draw information from CAD Management tools either by direct SQL connection to the database or through a COM Object layer. Information may also be issued such as a change in status of a revision to make it non-revisable.

The extent of direct management of documents is shown green in the table above entitled Document Properties.

Return to Contents 

About EDM Tools

EDM was developed initially to enable "the paperless office" - they are thus a horizontal market tool for "document management". A typical use is for processing cheques in a banks' clearing departmnent. However, the specific demands of the Design Office with revisable documents requiring revision control soon emerged, giving birth to the "CAD Management" tool.

Thus the structure of the database is principally concerned with control of access to documents - including their initial generation and subsequent revision. Very few EDM systems come with anything except for a very basic configuration. The configuration process is not unlike developing an in-house application: see also the white paper entitled "In House Solution", which describes the attendant risks.

In any event it is not feasible to attempt to configure the workflow to handle tasks such as expediting and SDRS due to the constraints in database, API, and workflow.

Although general documents can be generated, due to the unstructured distribution nature of these, in effect they must then be handled "manually" within the system.

In summary, the extent of creating and revising deliverables (or Own Documents) is shown blue in the table above entitled Document Properties.

Return to Contents 

Comparison of Systems

The following table summarises the fundamental differences. It is based on a detailed knowledge of TDOC as a CEMDC application, and two common EDM tools used in Engineering Drawing Offices.

Item CEMDC (Application)EDM (Tool)
ProcessIn built industry standard process's
Customisable by setting parameters and categories
Must be configured by an expert leading to extra costs
Limited by extent of API and embedded secondary tools
Payback PeriodMonths if not reducing to weeks Years if not extending to decades
File ManagementUses the Operating System to:
  • Restrict access to view or edit
  • Allow viewing but not editing
  • Redline via third party tools
Does not make use of the Operating System, but instead has a substantial file management capability, handling local copies as well as duplicate master copies through the replication process.
Document ProfileThe document profile "grows" as the document continues to be processed - Revised, Issued, Returned, & Stage or Status allocated. Groups and Keywords provide further unlimited "transactional" profiling.The structure of the profile must be predefined, and the details must be entered on initial registration.
DocumentsEach variety of document is treated differently according to its specific characteristics. Own General and Miscellaneous documents are stored as data not documents. They may be generated as documents as needed.

Amongst others Requests for Information / Technical Queries have special process needs and these are included.
In general terms, all documentsare generically treated in the same manner regarding profiling, generation, and storage.

For Technical Documents, special treatment rules must be set up to handle the revisions. However it is difficult to set up such rules for very complex behaviour such as Requests for Information / Technical Queries, which are generally considered as just another document type.
General Document HistoryThis includes:
  • distribution and actions
  • response and subsequcnt actions

in addition to the profiling information

Some EDM Tools store such information as who accessed the document, and for how long. Others will keep a track of the number of keystrokes. This is importanmt information in someenvironments such as a law office.
Technical Document HistoryThe history of the document includes not only the revisions, but also its complete movement history internally and externally. The movement history includes:
  • Revisions, including Change Authority
  • Issues incluiding reason for issue and status at time of issue
  • Returns including status and comments
  • Status (at revision level), including changes of status to the same revision.
History in an EDM environment usualy means just of the Revisions made. Status is gernerally maintained at document level. To elucidate movement history normally means unearthing all the transmittal notes (which are kept as separate documents).
Document DistributionDistribution is fast and semi automatic.Rules are used to select people and documents to create a matrix, which is then saved to enable its reuse (known as a session). Transmittal documents include not only the transmittal notes, but also acknowledgement notes and comment sheets, etc.In general terms documents and recipients are manually selected
with the transmittals generated as a work flow report.
Extent of Project Management ProcessFor proper project management both the complete cycle of communication must be managed as well as tasks such as expediting of replies and approvals etc.

With structured data this becomes very easy indeed.
Due to the constraints in the database structure and workflow configuration, as much of the necessary information is NOT document related, it is just not possible.
Advanced Process'sSupplier Document Requirement Scheduling forms the link between Document Control and Project Planning. In many Project Management firms Document Control falls under the Planning Department.

This enables production of deliverables to be monitored against a project plan.

Within a Planning Tool, progress is measured against a "Base Line". When rescheduling takes place, the Base Line is updated. TDOC's Key Event schedule retains the history of Planned, Expected and Completed dates.
See the comment above. It is just not possible.
Finding Information and DocumentsWithin an application, there are generally three ways of finding information:
  • Drill Down (or Tree View) - which is very fast
  • Browse of Information - fast and capable of supporting complex filtering
  • Reports - withe same filtering capability, but with differenting levels of information provided.
The filtering may be based not only on the document profiles but also on the associated metric information.
Documents may generally be located only by reviewing the profile information, which can be quite slow. When the contemts of the documents is to be usedm then each document must be opened and searched, which further slows the process.

Due to the lack of metric information, searches for information are very limited.
CEMDC applications enable communication with any project participant and generally have the following capability:
  • Paper
  • EDI for inter-communication with other software
  • HTML forms with server side processing using the www.

Some CEMDC applications include full "email client" capability.

Due to restrictions in the API most incoming document data must be rekeyed.
ScalabilityCEMDC is best run using a client server engine, but for certain applications (e.g. several small projects run from a laptop) can do without.EDM generally must have a client server engine, and is thus not scalable.
TrainingTraining is minimal as process's are standard.User's must be trained to use the specific implementation.
SupportSupport is minimal for a mature product.Support is heavy as every implementation is different.
A Question of DifferentiationIf CEMDC is a discrete business process such as accounting, which it is then it an application will provide the Best of Breedanswer.If an EDM tool was used for running accounts, then it could not be said that the answer was Best of Breed.

Return to Contents