|
Construction Engineering Management Document Control |
Contents
The need for a standard Statement of Requirements (for the data and process's) is due to the general lack of recognition by the document management (software) industry of the specific business process needs of the building, construction, and engineering industry, and associated professionals.
A definition of "document management" was made in 1995 by the Computer Graphics Suppliers Association Ltd. in their report entitled The Document Management Strategy Report - A guide for Users available from Cimtech Ltd., a trading company of the University of Hertfordshire, sponsored by the Department of Trade & Industry. Although this report included a list "Document Management Application" categories, it failed to identify the main areas of need including transmittal notes, and links to planning for technical documents.
By 1997, the definition had changed considerably and been presented in terms of "System Functions", and areas of "Application Focus". However the specific needs for Construction Engineering Management Document Control (CEMDC) have still not been adequately identified.
This Statement of Requirements can be seen as fulfilling the need for an adequate industry definition. It has been based on documents produced by several plant owners, contractors, project managers, and designers.
The scope of this Statement of Requirements covers all aspects of document management and control for procurement of the construction of capital projects ranging from buildings to power stations to airports. It is applicable in whole or in part to all the disciplines and parties involved from plant owners to subcontractors over the whole duration of the project.
There are two sides to the objective - those which are passive, i.e. the need to comply with ISO9001:2000, Conditions of Contract, etc. and those which are active, i.e. the need to operate industry standard business process activities.
Document Types
The document management system must be able to handle all the common business process functions, for the main types of document which are defined as follows:
| Technical Documents | Technical documents are created to define an entity such as a
building, or part, and to pass information about the entity from the
designer to others, e.g. clients, managers, other designers,
constructors. Technical documents may be revised, and re-issued prior to their use as comments may be made about them. They may require to have a status, and be issued for a reason |
|
| Transmittal Documents | Transmittal documents are those which are used to manage the movement of technical documents from one party to another. They are in fact only a report of an action which has been taken, and they form part of technical document management processes. | |
| Correspondence | Correspondence (or general) documents are created by one party to send to another to convey certain information. They may be copied to third parties. The recipients may be required to respond. | |
| Other (Work Package) Documents | This includes contemporaneous notes, daily record diary, minutes of meetings, inspection (snagging) records, planned and actual dates of events, and timesheets. |
The list of processes given below cover the whole life of the document, and may be carried out by more than one party on a project. A firm or department may only require to manage some of these processes, for example a drawing office will be principally concerned with creation and revision of drawings using CAD, and may manage the electronic repository manually: Viz, for Own Technical Documents, only the second and fourth items are relevant.
Technical Document Processes
The processes which are associated with technical documents can be split into two groups. The two groups relate to whether the document is owned or not. The processes are defined for each group as follows:
Own Documents: Those documents for which you have the authority and responsibility to create and or amend.
Other People's Documents: Those documents for which you do NOT have any authority or responsibility to create and or amend, i.e. the authority and responsibility reside elsewhere.
General Document Processes
The processes which are associated with general documents can be split into two groups. The two groups relate to whether the document is owned or not. The processes are defined as follows:
Own Documents: Those documents which you create and despatch.
Other's Documents: Those documents which you receive, and if necessary re-act to.
Miscellaneous [Work Package Management] Documents: Those records, which may be specialised documents or metric information such as time allocation sheets.
Structure
Any software must have a structure to it which creates a framework within which the document processes can be managed. It is not part of this Statement of Requirements to identify specific types of database which might be suitable, nor which types of language are suitable for creating such an application set.
The structure must cover the following:
The structure may cover such things as:
It is preferable that the software structure can be setup by the skilled user and not require configuration by experts, external to the users organisation.
Background data to enable registration activities
Technical Document Registration
The following elements and associated sub-elements have been defined as necessary to operate the basic registration transactions defined within the processes for technical documents:
Technical Document Procurement
The following additional elements are required to manage the procurement of technical documents to a predefined plan, but exclude the elements required to create and run a planning package.
General Document Registration
The following additional elements are required to manage the registration of general documents including specific document types such as Project Managers Instructions, Technical Queries, responses and the like.
Miscellaneous Document Registration
Miscellaneous Documents include the following
Custom & Practice
Any software should comply with standards and custom and practice, which might include:
Other Matters
It is also preferable that the following matters should be addressed:
It is recommended that all references are reduced to a reasonable minimum to reduce the volume of data entry. For example, if the format of a document number consists of its JobNo / PlantItem / Sequential No, then only the Sequential No should be used for data entry. Entering a longer number simpoly increases the scope for a typing mistake which might then lead to a NEW document being recorded, when in fact it should only have been a revision of an existing document. The downstream effects of that could be catastrophic.
Technical Documents
When documents are transmitted from one place or person to another, it is necessary to ensure that the documents are uniquely identified so that there can be no confusion.
It is therefore recommended that technical documents are identified as follows:
They may also be identified as follows:
For internal audit purposes, every copy of every revision of every document should be uniquely identified as follows:
General Documents
It is recommended that general documents are identified as follows:
The may also be identified as follows:
For internal audit purposes, every document should be uniquely identified as follows:
Miscellaneous [Work Package Management] Documents
These are so diverse in nature that it is not feasible to standardise them.
Items of information are required in the management of documents, for example when generating a transmittal note. It is important that all systems have the ability to hold data of the same types to enable EDI (Electronic Data Interchange). The following table defines the entities which are required: all information may be included on a transmittal note:
| Item | Size | Comment |
| Sender's name | 50 | For person & organisation |
| Communications | 15, 80 |
Telephone, Fax, E-mail address |
| Address | 30 | Up to 5 lines of address |
| Project Title | 80, 15 |
Description Reference |
| Job/Contract Title | 80, 15 |
Description Reference |
| Group Title | 80, 8 |
Description Reference |
| Transmittal Note Number | 15 | 8 is recommended |
| Recipient's Name | 50 | |
| Maker's Name | 50 | |
| Maker's Document Number | 15 | 5 is recommended |
| Document Title | 80 | |
| Revision Number | 3 | combined with document number can make file name |
| Document Type | 15 | |
| Document Size | 15 | |
| Document Material | 15 | |
| Senders Document Number | 15 | 8 recommended |
| Project Document Number | 15 | |
| Senders Change Reference | 5 | |
| Number of Copies | 3 | or "ADV" for advice. |
| Reason for Issue | 15 | |
| Senders Status or Stage | 15 | |
| Senders Comment | 80 | |
| Date of revision | 8 | in DD/MM/YY format |
It is recognised that the integration of planning and document control using the techniques accepted as common practice in the oil industry are not yet common practice within the construction industry. However similar methodologies are being developed, and are becoming more widespread.
There are two relevant methodologies which are:
Technical Documents SDRS
General Documents
For further information, please contact TDOC by email: info@TDOC.net
TDOC White Paper 2 of 7
Index of
White Papers
Visit the TDOC Web Site