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.
Publication of Deliverables
e.g. Obtaining Approvals
It should be pointed out that documents relating 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.
- Has revisions,
- Publish revision on release,
- Only unissued latest revision may be changed,
- Has revisions,
- Revisable only by the person who created it.
- Transmittal Notes
- Acknowledgement Notes
- Comments Sheets
- etc, etc
Associated process management documents must be generated from metric information stored in a database.
Once distributed, may NOT be changed
May not be changed
- Time Sheets
- Daily Record Diary
- Snagging (or Inspections)
- Minutes of Meetings incluidng Agenda and Actions
- Contemporaneous Notes & Contacts
- Event Schedule and SDRS
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 management 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.
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 department. 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.
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.
Customisable by setting parameters and categories
Limited by extent of API and embedded secondary tools
- Restrict access to view or edit
- Allow viewing but not editing
- Redline via third party tools
Amongst others Requests for Information / Technical Queries have special process needs and these are included.
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.
- distribution and actions
- response and subsequcnt actions
- Revisions, including Change Authority
- Issues including 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.
with the transmittals generated as a work flow report.
With structured data this becomes very easy indeed.
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.
- Drill Down (or Tree View) - which is very fast
- Browse of Information - fast and capable of supporting complex filtering
- Reports - with some filtering capability, but with different levels of information provided.
Due to the lack of metric information, searches for information are very limited.
- Paper
- EDI for inter-communication with other software
- HTML forms with server side processing using the internet.