|
Construction Engineering Management Document Control |
Contents
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:
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.
| Place | Design or Drawing Office | Project Management Office |
| Tasks | Creation 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.
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 Varieties | Comments | |
Own Technical
|
Other's Technical
|
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
|
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
|
Other's General
|
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
|
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. | |
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:
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.
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.
Comparison
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.
| CEMDC (Application) | EDM (Tool) | |
| Process | In 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 Period | Months if not reducing to weeks | Years if not extending to decades |
| File Management | Uses the Operating System to:
|
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 Profile | The 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. |
| Documents | Each 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 History | This includes:
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 History | The history of the document includes not only the revisions, but
also its complete movement history internally and externally. The
movement history includes:
|
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 Distribution | Distribution 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 Process | For 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's | Supplier 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 Documents | Within an application, there are generally three ways of finding
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. |
| Communications |
CEMDC applications enable communication with any project
participant and generally have the following capability:
Some CEMDC applications include full "email client" capability. |
Due to restrictions in the API most incoming document data must be rekeyed. |
| Scalability | CEMDC 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. |
| Training | Training is minimal as process's are standard. | User's must be trained to use the specific implementation. |
| Support | Support is minimal for a mature product. | Support is heavy as every implementation is different. |
| A Question of Differentiation | If 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. |
For further information, please contact TDOC by email: info@TDOC.net
TDOC White Paper 5 of 7
Index of
White Papers
Visit the TDOC Web Site