We recently posted an article to help our audience better understand the differences between document management and records management. In sharing this article, we were fortunate enough to chat with John Barton, the Principal Consultant at Infocloud Consulting. John provided us with some valuable insight into the world of Document Control, and how it differs from the world of records and document management.
Document Control is the function applied through the lifecycle of engineering and construction projects. Unlike record and/or document management, document control is primarily concerned with what happens to documents and drawings themselves, instead of the file content.
To simplify, let’s say that the primary focus is on technical, deliverable documents and drawings produced by design houses, contracts, and vendors. These documents will go through multiple:
- Revisions (not versions)
- 3rd party transactions (with contractual turnaround times)
- Interface controls
AND be linked to:
- Other documents
- Planning work packages
- Asset hierarchies
AND reporting formats used to:
- Monitor progress
- Expedite and manage the supply chain for schedule, quality, compliance
- Classify and process project phases such as Design, Construction, Commissioning, Handover, and Close-out
There are proven best practices for numbering, coding, planning, managing distribution, etc. and require a software system designed specifically to support the myriad of variables that accompany these processes. When discussing large scale projects and programs, there may be tens of thousands of drawings and documents being transacted weekly. These documents must be registered, processed, and tracked accurately, and involves the management of large amounts of critical metadata. In order to achieve this, systems must be designed around a set of fundamental conditions that are comprehensively configurable and can be automated as much as possible.
So how does one find a system that can handle these intense document control needs? John’s asserts that you must thoroughly define the technical, functional, and security related requirements of a software system based on the essential business processes and principals that must be applied. Only once you have done this can you realize a profit from said process.