8 simple rules for submitting your vendor documents

8 Simple Rules

for

Submitting your Vendor Documents

by Brad Bowyer, DocBoss

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.

What is this all about… and what does it mean to you?

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.

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…

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.

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.

2 – Start Separate… Stay Separate

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.

3 – Metadata Linkage

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.

4 – Document Numbering

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.

5 – System to System Linkage

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.

6 – Don’t make your Customer rename your Files

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.

7 - Reporting

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.

8 – Cross-References

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 non-

standard.

Here’s a few examples of this type of content in some RFPs you see…

Now the Ridiculous…

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.

Now…. let’s talk about some of the more Frivolous Requirements

The following describes some specific examples…

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.

1 - Document Cover Pages

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.

2 - Compilations (when detailed formatting is required)

1. The data is required. Customers should define the required data, and then give suppliers an option.

2. You can provide the required metadata according to ANY XML schema (programmatically), OR use their specific layout / forms and fill in the data manually.

3. 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.

3 - Specific layouts for transmittals and cover pages

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.

4 - Providing Metadata… (which should be available in your customer’s system)

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!

That’s our Pitch…. NOW… Everybody Change!