As suppliers try to comply with all of the submission requirements from various engineering companies, I’d like to take a step back and consider the level to which the requirements SHOULD be rigid, and where they border on the ridiculous.
There are core principles of information management which should be rigidly applied. Beyond that, we move into frivolous requirements, based on poor information design.
Here are the rules which should ALWAYS be required:
1) Only one copy of any document should be submitted (per project)
If you find yourself sending in the same information more than one time, there is a mistake being made. If a document relates to various items, you should be adding/updating metadata to the document, to identify all possible connections. The Customer data system should be designed to cross reference one document to multiple pieces equipment – at least within one project.
2) If a document starts as an independent file, it should stay as an independent file
You should be able to access all versions, and detailed metadata, for every document. When you want to submit compilations, it should be POSSIBLE (not necessarily prudent) to create them through an entirely automated process, using nothing but the structure and the individual document metadata. Your customer should demand that you submit individual files.
3) Every document must have a unique number
Whether you use sequence, or sheet numbers, there should be a unique ID for every document which links it to some data system in your office. With the correct ID, you should be able to pull up all of the information about the document.
4) Upfront, or on initial submission, you must provide the relationship between your document number, the customers requirements, and the purchased equipment
In vendor documentation, this correlates to a document code (provided by your customer), and the tag number of the equipment. Both must be linked to the document you are providing.
5) Once a link has been established between two document systems, it must be recorded, and included on every subsequent exchange
This generally takes the form of document numbers being assigned in both your and the customers systems. If your customer gives you a document number, you MUST store it with your document. Likewise – if your sub-supplier provides a document number, you must also record that for electronic document exchange.
6) Every submitted file should include meta data ensuring it is unique
This can be done by including the document, revision and submission numbers. Could be embedded in the meta data. More simply – it can be put in the file name. This simplifies the uploading of the information, identifies duplication, and flags when there is new information.
7) Reporting
You must maintain a complete history of every submission, version, and status. This should be available for your customer, in case there is ever a discrepancy.
8) Cross references
As long as your customer can show you a cross reference report they have generated, (so you know they have done the work), you should be able to provide cross reference reports to validate the customers information.
The FRIVOLOUS
1) Document cover pages
Cover pages are just human readable metadata. If you don’t make mistakes with meta data, they should be abolished. I understand their requirement when the supplier is not perfect in their submission. Bad meta data can ruin the integrity of the document systems. Once you execute step 4 (above), as long as your document always carries the same unique number, cover pages are ridiculous. NOTE: DocBoss automates cover pages – so even though I think they are ridiculous, they remain a requirement.
2) Compilations (when detailed formatting is required)
Creating compilations is a typical deliverable. I think its fine, as long as it can be created from the existing metadata, in a supplier defined format. If a rigid, specifically formatted compilation is required for a specific project, the work should fall to your customer. They have all of the required metadata, and all of the required documents. Any rejection for formatting (especially if the meta data exists with the customer), is 100% wasted time. You should be charging your customers for all work related to record books, including interest on unpaid bills.
3) Specific layouts for transmittals and cover pages
The data is required. Customers should define the required data, and then give suppliers an option. Provide the required metadata according to ANY XML schema (programatically), OR use their specific layout / forms and fill in the data manually.
I do see some value in providing reports (document indexes, cross references) in a specific format, as long as they are used to validate and coordinate the progress of the project.
4) Providing meta data which should be available in your customers system.
Typical examples I’ve seen include:
a) Providing an indication about whether a file is a document or a drawing (i.e. text entry of “DWG” or “DOC”). This should be known by the customer based on the doc code.
b) Providing page sizes when submitting documents.
That my pitch. Now, everybody change!