ENGINEERING DOCUMENT CODING

Here's the problem I always run into with that type system: What do you do when a document is a combination of two or more "codes"?
Leave the document naming simple, and use a database (or document management system) for classification.

My company policy is to have a unique code for each type of document to extinguish the document type from the document number or document file name.

If you are serious - instead just making something up on the spot - go to your local library. Ask the librarian for a book about their classification system. It has the advantage, that it works and expandable.

This may prove to be a real challenge. I have been involved in several such efforts. On the whole the following is true... In order to succeed, you need to get everyone involved to agree to the naming convention that is put in place. You need to get all of the stake holders, in your organization, together and hammer it out on how the standard is to be written. That has always been one of the first things achieved when the overall attempt was a success. When this crucial step was never accomplished, failure would soon happen afterwards.

I want to agree with this, and add:

There are many document types, and I suppose it would be useful to know all the possibilities but, in the end, you'll end up with a system (or document types) that are suited to your company specifically. The best is to work out a system, define what document types you want to use in the organisation, and publish a typical product data structure* that all can work to. In the absence of such a template, you'll get a never-ending string of requests for new document types. That being said, I'm not suggesting that your systems should be uncompromising/inflexible, just that it should evolve around a well-considered framework.

*This could change depending on what phase of a project/product development cycle you are in.

HTH

This problem is simple and should be solved in house with consultation with all involved in use of the documents. Different companies follow different systems for coding.

The truth is in between Simple and Very Complicated task, with possibility to conflict with other coded components as mentioned above.

Your idea of letters is in most cases OK. Try three Capital Letters (remember - Search Engines that would ignore capitalization!). Number of combinations is huge. It is important you like it!

Inside document I recommend numbering system e.g. 1 - 1.1- 1.1.23 etc. so addressing to the Chapter (1, 2, etc.) and Paragraph (1.1 - 1.2 - etc.), to detailed content will be straight forward. Avoid Roman/Latin numbers I,V,X,C so popular in US legals.

Projects may use full words (as in Agencies) e.g. "Winter", "carrots" as an additional "military code", easy to address in Voice Mails.

Got them approved? It is the question. In my experience to get approved my concept I was stuck with ability to do real work -= continue my documentation/designing tasks. Waiting...waiting for final decision - so if must - go directly to The Highest Boss. (S)he will do the final approval anyway.

Got them approved? It is the question. In my experience to get approved my concept I was stuck with ability to do real work -= continue my documentation/designing tasks. Waiting...waiting for final decision - so if must - go directly to The Highest Boss. (S)he will do the final approval anyway.

You should motivate the speedy approval and implementation of your proposed system/procedure based on the value of the preservation of intellectual property to yhe organisation. Try to get it adopted as organisational policy- preservation of (accurate) product configuration data ensures that it can be replicated in the future, and that valuable IP is retained long after the engineers have moved on.

jt's pennyworth:

1. Leave room for additions:
Inevitably one needs to add "something" later - which can
make a mess of what would have been a straightforward system.

If there are e.g, 14 types of documents, define for 20.
marking the unused ones e.g. "unallocated" "other" whatever.

and:

2. Avoid using confusing symbols:
As in, 1 (one) l ("letter L) and the obvious 0 (nought) and O, etc.
Full stops also have problems, although used on legal papers.

and:

3. Build-in a cross reference:
Make the system such that there is more than one way of sourcing
a document. It can occur that the normal means cannot be applied.
Alternative search routes are a God send for e.g. torn edges, miss typed
entries, etc. A form of cross referencing is essential. (in my opinion.)

Hope this helps.

jt.

Have a free web page - on http://www.mfnb.at

Good points

3. Build-in a cross reference: Make the system such that there is more than one way of sourcing a document. It can occur that the normal means cannot be applied. Alternative search routes are a God send for e.g. torn edges, miss typed entries, etc. A form of cross referencing is essential. (in my opinion.)

Some more:

1. Put the document name/number on each page.
2. Make the document type part of the title e.g:
1. Generator control panel parts list
2. Generator chassis assembly drawing
3. Generator final assembly test procedure
   

in one of our projects we use the following numbering system...ven you can use it if you like

year-project name in shortform- client contract number- A-XXX-YY

A represents document...it could be replaced by B if it is drawing...similarly C , if its some Code..

XXX should be replaced by DTS for datsheets..spc for Specification...and similarly

YY-- reprents the revision..First revision-00...2nd revision-01

for example,

2008-KFGH-23546-A-DTS-00

this might be of some help,

best regards,

Prashant..

It is good to have some legible meaning in the numbering system, and it helps implementation as you will have some degree of difficulty having such a system accepted.

Some part legible, Some part incremental is a good start.

Keep it simple to avoid mistakes and to ease acceptance.

Any part of a code needs to add value (meaning), too much makes it unlivable.

Get buy-in from management and staff, as this requires effort and resources. (I have a saying that ISO creates employment...).

I have experienced a badly mounted system that did not get complete acceptance by staff and management. Since it was implemented a year after the company startup, many kept their own little system. The result was 5 incompatible systems in a 50 person company. Sales, Finances, Marketing, R&D, Engineering all have different prerogatives in such a system.

Excellent Question, and one that I will soon have to address as well. I manage documentation for engineering and quality control, and have inherited a mess stretching back 5 years or more. I consulted a professional engineer last year regarding naming conventions for our solidworks part, assembly, and drawing files. Of course it ties in with the material inventory system but I will not have the opportunity to rename the parts in inventory, and as such, will have to create an amalgamation of names.

It will be most useful for us to have "Part" drawings, and models named after the inventory part number. The PE that I consulted showed me their system and it was a multi-term naming convention. the basic structure was

PRODUCT GROUP-ASSEMBLY-COMPONENT-SEQUENTIAL NUMBER.FILETYPE

eg

PRODUCT GROUP = HYDRAULIC DRILL PIPE HANDLER = "DPH"

ASSEMBLY = FLUID PUMPING UNIT = "HPU"

COMPONENT = PUMP MOUNT FOR PUMP TYPE XYZ = "PMT"

SEQUENTIAL = "0001"

FILE TYPE = ".SLDDRW"

Document name = DPH-HPU-PMT-0001.SLDDRW

This way, all the documents for this component group were listed together.

eg:

DPH-HPU-PMT-0001.SLDDRW

DPH-HPU-PMT-0001.SLDPRT

DPH-HPU-PMT-0001.SLDASM

DPH-HPU-PMT-0001.XLS (BOM)

DPH-HPU-PMT-0001.DOC (ASSEMBLY INSTRUCTIONS, ETC)

DPH-HPU-PMT-0001.JPG (PHOTO OF UNIT)

this system also makes it fairly easy to read and understand, and to generate new part numbers and drawing names.

Variation of this them can be used to create documentation for any document in the organization, I believe, and also make it possible to create software to manage the documentation, if required, and the term of the name are relatively easy to set up with radio buttons, or pick from a list. Our naming convention for our inventory system is more mnemonic, and can not be easily computerized.

Last year I also took a run at making software (VB and a pdf activeX) to do exactly this, where a given document of questionable name could be selected, and then radio buttons etc would be selected, and a new file name generated, and subsequently a new file name created. My basic premise was that all the "Published documents would be PDF, while authoring documents would be all other formats. I was going to rename all the published documents in a format that would include their current revision. (see image)

Dear sirs,

Many thanks for your nice explanation about This matter, its very useful to me.

You may want to read up on the discipline of Configuration Management or Acquisition Management. It is a bit of a broader subject than the thread addresses. However, some of the comments and questions posed here indicate that consideration of the bigger picture would be well-advised.

At the risk of sounding pedantic, if your problem statement is "We need a standardised numbering system", you will get limited buy-in from Management (why change [read "spend money on"] something that apparently works?). If you say "We need to protect/preserve our Intellectual Property to ensure Consistent Product Quality and minimise time-wasting", they are more likely to start paying attention.

My company uses a coporate database system (TIS), however, every dept and every company has their own ideas about how things should be done; language differences create many problems, especially in the area of training; implementation stategies were poorly thought out (at least initially) so that a mired mess ensued; reliance on classification of component attributes makes it virtually impossible for manufacturing to be flexible and lean at the same time; and the list goes on.

So the best efforts of our "standards" dept is wasted because they create more variation than is really necessary and the result is something that approaches structured chaos borderline insanity. (we speculate about how long it will take before this massive database will collapse under its own weight).

Whatever you decide on keep it simple, keep it flexible, and most importantly, enforce the rules.