Part and Document Management: Why is it Complex?

by Oleg on March 8, 2014 · 4 comments


Parts and Documents are two different objects in engineering, product development and manufacturing. While “part” usually represents physical object, “document” usually represents specification, drawing or 3D model of part. Even it it sounds obvious, Document and Part management is not an easy and simple task.

In my post – How to manage Document versions, revisions and Part numbers, I’ve been mostly speaking about the need to have separate numbers for documents and parts. I also mentioned that bad practice to use the same numbers for both document and part, can lead to significant complexity and mistakes. At the same to implement a system or multiple system to manage Documents and Parts is complicated. Below I described potential three typical configurations you may find in companies related to document and parts management.


Even PDM is not very new technology, you can still see many companies that not using PDM. If this is a case, you have a good chance to see documents (CAD and non-CAD) spread out in the network and shared drives. Without centralized document management system, a company is creating numbering convention how to provide document numbers. A good chance that you will see lots of Excel spreadsheets to be used for Parts and BOM management. Very often, a company will be using similar number convention for parts and mix it together with usage of OEM and supplier part numbers. You can also see homegrown system to manage Part Numbers in a separate database.


This is very typical situation where engineering and manufacturing are splitting responsibilities into silos. Engineering department is using PDM system (very often from the same vendor as CAD system) and manufacturing (as well as rest of the company) is using ERP system. Within this schema, PDM system is taking control of documents. Document numbers usually generated by PDM system according to predefined naming convention. Item masters and parts are managed by ERP. The complexity of this model is to link between documents in PDM system and parts/BOMs in ERP system. In most of the cases, the integration between them is manual or using batch import/ export procedures. Optionally, PDM system can manage parts (typically engineering parts).


It is not unusual to see both PDM and PLM systems co-exit in the same company. Similar configuration can be achieved by combination of PLM and ERP system. In the last case, PDM module is part of broader PLM offering. The specific characteristic of this type of environment is management of parts and engineering BOMs in PLM system. Sometimes, you can see PLM systems is responsible also for manufacturing BOM management. This configuration provides the most consistent way to interlink between Documents and Parts. Both numbers are available in PLM system which can use them. The weak part of this configuration is complexity of integration between PDM/PLM and ERP. Synchronization of Part Numbers and Document Numbers among all systems is a challenge that may potentially lead to data inconsistency.

What is my conclusion? The information about documents and parts is located across organizational departments and systems. At the same time, to manage them in a consistent way is very important. Regardless on the number of systems and the way to manage Document Numbers and Part Numbers to keep them separate and maintain linkage between them is the first priority. Just my thoughts…

Best, Oleg

  • Michael Wm. Denis

    @Oleg – I read both of your recent beyondplm blogs on P/N vs. Document number and found them interesting.

    My comments fall into two categories – 1) its even more complicated once we move from the OEM “Product” view of life into Operator/Maintainer’s “Service” view of life and 2) at least in the A&D/aviation/shipping/rail/defense automotive industries – the ASD SX0001 family of standards and the S1000D document (really component content) standard has addressed this complexity.

    So we’ve had this conversation before, that there is a significant difference between OEM PLM and the Ops/Mtc SLM. In the SLM world, we not only deal with P/N information, we also deal with S/N and B/N (batch) information since P/N don’t degrade or fail, S/N and B/N do. We operate and maintain specific Physical configurations in accordance with the allowable Logical configurations (both Logical Structural and Logical Functional).

    While I’ll concede that even in the A&D and aviation ecosystems, most diagnostics, prognostics, trouble shooting / fault isolation, servicing, maintenance, repair and overhaul (MRO is three different engineering activities) … content within documents start with a P/N and P/N-dash number approach.

    However, as soon as we have an “instance” of a Logical Structural = Physical Structural, that instance inherits or carries with it its designed Logical Functional configuration. In S1000D parlance this is the difference between Applicability (Logical) and Effectivity (Physical instance specific).

    In the SLM world we operate, track, maintain, … specific Physical instances and gather all sorts of performance data against specific Physical instances = Physical Functional configuration data. Part of the soon to be published S5000F addresses the Physical Functional data sets “Feedback” to the OEM PLM world.

    So where the less complicated OEM PLM world has complexity around the P/N to document conundrum – the Ops/Mtc SLM world parses (inaccurate term) operating, trouble shooting, maintenance, … documents into component content fragments (electronic or printed task cards, sub-procedures of task cards (work cards), quick reaction handbook procedures, …) specific to – not only – a P/N (component) but also appliances, systems, retables, and whole up assets (engine, aircraft, …).

    I agree – it’s complicated.

    Luckily we’ve been working on this SLM complexity for the past 40 years – the result is approaching the “document” challenge by managing “component content” with applicability, effectivity, context specific process, configuration specific illustrations, context & format specific illustrations (say CMG for PCs and SVG for tablets), … built into data modules defined by an XML schema that physically reside in a Common Source Data Base (can be RDBMS or more often than not a NXD).

    So, when an OEM rolls a P/N and triggers a process in their PDM/PLM system that triggers a process in a Component Content Management System (CCMS) to update certain data modules. When said OEM “publishes” (that has multiple meanings) a revision (this may differ from your other blog on versions, revisions, releases, …) – what gets distributed to an operator or maintainer is / can be just the P/N or B/Ns data modules that changed with the entire applicable content.
    Operators / Maintainers then “reconcile” the applicable content data module for their physical effective instances AND any content modifications they made remotely (unknown to the OEM). For instance, an operator using an approved alternative P/N from an approved alternative vendor or fabricated / manufactured by the operator themselves with Parts Manufacturing Authority (PMA) in the A&D/Aviation world.
    What an actual viewer of the content “consumes” or views (a pilot executing a quick reaction or a maintainer executing a repair) is specific to the exact Physical Structural configuration and its Physical Functional parameters. This is what we term “human consumption” of content.
    Additionally, there is the “technology consumption” of content – the process of updating ERP / SCM / MRO / HR … IT systems with material management data or warehouse inventory data or maintenance scheduling data or human capital data (licenses or certifications to operate or maintain) said instance.

  • Michael Wm. Denis

    In other industries, the DITA / ISO 26531 standard accomplishes much of the same as S1000D. ISO 10303 STEP:PLCS appears to be covering other aspects of the ASD SX000i family of standards.
    In some cases, this is creating a challenge – for instance the S5000F standard was developed using ISO 10303 AP 239 and ISO 13374 by ASD / AIA without ATA and operator input – so a lot of valuable content and knowledge that resides in the SLM systems are not going to be pushed into the OEM PLM side.

  • Michael Wm. Denis

    And while we’re on the subject of P/N and dash numbers – the “additive manufacturing process” is adding (pun intended) complexity to the configuration management challenges of the aerospace and aviation industry.

    In the AvSLM group of LinkedIn we’ve been discussing the legal / regulatory requirements under 14 CFR Part 25 and Parts 135, 121 & 145 where Parts Manufacturing Authority (PMA) reside.

    We all know engineering 101 – roll a P/N when form, fit or function changes. Under PMA it is common to create a new P/N with two way (or possibly one way) configuration rules (controlled via the S1000D BREX or MRO IT Configuration Module).

    Theoretically, a part could be additively manufactured where form fit and function do not change BUT the Part 25 certified manufacturing and testing process are different. Additionally, this alternative part could have different “data” for operation, servicing, maintenance, repair and/or overhaul procedures – or it may not if the FAA or Designated Engineering Representative (DER) determines, approves and certifies in writing an “identicality finding”.
    The “data” changes includes all document content covered by Instructions for Continued Airworthiness (ICA) – which, unfortunately, the FAA has not full specified. At this point, I’ll refrain from this legal discussion and the source of multiple lawsuits between repair stations and OEMs. But the issue is, there can be multiple “data” sets (manuals such as the FOM, FCOM, QRH, AMM, CMM, IPC, FRM/FIM, TSM, SRM, …).

    The FAA delegates the approval of “data” changes to DERs and DARs (Designated Airworthiness Representatives) depending upon the circumstances of a minor/major repair or minor/major alteration (modification) or alternative method of compliance (AMOC).
    When a part is PMA’d and lets say the only engineering specification difference is the additive manufacturing process – then it is most common to create an alternative P/N, not because it is per se required – just its most convenient and common practice for the PMA holder.
    Here’s the rub, when an OEM uses an additive manufacturing process and first article testing and certification result in no engineering specification difference – do they roll the P/N or add a dash number or not?
    How does that affect content? documents?
    Complexity just got more complex if OEMs are not using component content management.

  • beyondplm

    Michael, thanks for such a great insight and detailed story. Really appreciate that. I completely agree – to take it towards SLM is another vector of complexity. My post was mostly focused on OEM/Engineering company type environment, which is by itself quite complicated. Your stories take it to the next level :) . Again and again, my conclusion that successful solution is combined from flexible data management and process implementation. What you explain (including standards and specific industry requirements) are clearly part of what I call “process implementation”. What is important is a foundation that will enable you to do so. Just my thoughts… Sorry, it is much shorter than your comment :) . However, it looks like we finally need to find an opportunity to meet and talk. Best, oleg

Previous post:

Next post: