This is our take on how the world of Document Submission should work... not all requirements in a Customer's RFP must be viewed as RIGID. Here is why we think there are exceptions.
2. What is this all about… and what does it mean to you?
We’d like to talk candidly about things we hope you already
know when you deal with your customers and their RFPs.
Sometimes a customer’s requirements can drive you up the
wall… and you often try to comply to these requirements,
making your life even more difficult. Frustrating... isn’t it?
Let’s step back for a moment and consider which of a
customer’s requirements should be RIGID as well as those
that border on the Ridiculous.
3. In a nutshell, here’s how we think the world should work…
• You should submit only one copy a document and have it
live its life as an independent document with its own
number.
• This number should link the document to other ‘things’ to
which it should be linked and that number should be also
used whenever the document is referenced.
• Each document (a file) should include metadata ensuring
its uniqueness.
• You need to keep a history of every submission, version
and status… and make this info available to your customer.
• Your customer can now provide a cross-reference report
on anything they generate…. and you can do the same to
validate the customer’s information.
4. As a Supplier, trying hard to comply with all of the
Submission Requirements from various Engineering
Companies, let’s look at those requirements that
should always be rigid and identify some of them
that border on the Ridiculous.
The real scoop on this follows…
5. 1 – Submit one Copy
1.
If you send the same information more than once, a mistake being
made.
2.
For documents that relate to various items, you should be
adding/updating metadata to the document to identify all possible
connections.
3.
The Customer data system should be designed to cross-reference
one document to multiple pieces equipment – at least within one
project.
6. 2 – Start Separate… Stay Separate
1.
You should be able to access all versions and detailed metadata for
every document.
2.
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.
3.
Your customer should demand that you submit individual files.
7. 3 – Metadata Linkage
1.
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.
2.
With the correct ID, you should be able to pull up all of the
information about the particular document.
8. 4 – Document Numbering
1.
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.
9. 5 – System to System Linkage
1.
This generally takes the form of Document Numbers being assigned
in both your system and that of your customer.
2.
If your customer gives you a Document Number, you MUST store it
with your document.
3.
Likewise – if your sub-supplier provides a Document Number, you
must also record that for electronic document exchange.
10. 6 – Don’t make your Customer rename your Files
1.
This can be done by including the document, revision and
submission numbers.
2.
These identifiers could be embedded in the meta data.
3.
More simply – the meta data can be put in the file name.
4.
This simplifies the uploading of the information, identifies
duplication, and flags when there is new information.
11. 7 - Reporting
1.
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.
12. 8 – Cross-References
1.
If your customer can show you a cross-reference report they
generated, this is an indication that they have done the work.
2.
You should be able to provide cross-reference reports to validate the
customer’s information.
13. Now the Ridiculous…
We do not imply that your customers provide you with ridiculous or
frivolous requirements but, perhaps due to incomplete or outdated
practices, some Requests for Proposal you may have seen are a bit nonstandard.
Here’s a few examples of this type of content in some RFPs you see…
14. Now…. let’s talk about some of the more Frivolous Requirements
Cover Pages are simply human readable metadata. They are a requirement … if
the submission is not “perfect”… like when someone doesn’t link document
numbers to the customer’s requirements and the purchased equipment.
Compilations (when detailed formatting is needed) are fine if they can be created
from existing metadata but if a rigid and customer-specific format is a
requirement, then this is best done by the customer. You should charge the
customer for any work done related to Record Books.
Specific Layouts for transmittals and Cover Pages require data which the
customer can provide. You can use their templates.
Metadata should come from your customer’s system such as whether a file is a
Drawing (DWG) or a Document (DOC) and the page size of each.
The following describes some specific examples…
15. 1 - Document Cover Pages
1.
Cover pages are just human readable metadata. If you don’t make
mistakes with metadata, Cover Pages should be abolished.
2.
We understand requirement for a Cover page when the supplier’s
submission is not perfect and know that bad metadata can ruin the
integrity of the document systems.
3.
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 currently remain a requirement.
16. 2 - Compilations
(when detailed formatting is required)
1.
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.
2.
They have all of the required metadata and all of the required
documents. Any rejection for formatting (especially if the metadata
exists with the customer), is 100% wasted time.
3.
You should be charging your customers for all work related to Record
Books, including interest on unpaid bills.
17. 3 - Specific layouts for transmittals and cover pages
1.
2.
3.
The data is required. Customers should define the required data, and
then give suppliers an option.
You can provide the required metadata according to ANY XML
schema (programmatically), OR use their specific layout / forms and
fill in the data manually.
We 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.
18. 4 - Providing Metadata…
(which should be available in your customer’s system)
1.
Typical examples we’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.
19. Have we learned anything?
• Ensure you understand the customer’s
requirements and get clarification if needed
• Don’t make assumptions as these will most
likely lead to the dreaded “Re-Work”.
• Don’t ignore “Frivolous” requirements… but
do provide your submissions in a way your
customer can understand.
• You CAN do it… and make your customer
happy!
