PDM, Part Numbers and the Future of Identification

With data managed by PDM/PLM systems with a database back end there's no *technical* reason for “magic” part numbers; everything could just as well be identified by generic sequential numbers. All the information that people cram into part numbers could be (and often is) stored in metadata. However, the lure of being able to talk about a “150″ number vs a “250″ number, or whatever the local conventions are, and have people understand what sort of parts you're talking about is very strong. I've seen people insist that no one should use magic part numbers because they're totally unnecessary now… and then 5 minutes later explain why they need a magic part number pattern for their own data.

Regards,

Scott

You've opened Pandora's Box and a sore point with me. Oh how easy Part Numbering is from a manufacturer's point of view – thus the reasons why technology designed for manufacturing doesn't work in sustainment (in-service engineering & maintenance) – specifically aviation MRO.

So, you have three slot on an aircraft that has two authorized configurations of a pitot tube – one part from Thales and one part form Honeywell. Then Air France flight AF447 crashes and EASA and the FAA issue an Airworthiness Directive that says change the pitot tubes on certain aircraft.

You can A) change them all from the Thales part to the Honeywell part or B) change the number 1 and 3 positions, within a certain period of operations time and change position 2 whenever it requires replacing – BUT – if you opt for the lower cost option B then there is a software change in the ANI system avionics (also a part number / dash number item with a position on the aircraft which also changes the dasy number of the avionics). And, of course all of this changes the IPC/IPB, AMM and ANI CMM manuals and the maintenance program.

And, of course, if certain functional conditions or fault codes come up in the on board Central Maintenance Computer (CMC), then that triggers certain maintenance inspections and tests according to which new configuration combination you implement.

And, of course, you have A330 and A340s to do this AD on but you also have A320s that this AD does not apply to, so the Thales pitot tubes aren't obsolete to the company and can't be purged from inventory since they are perfectly acceptable for other fleet type configurations.

And, of course, certain parts have life limits, condition limits and other controls on their lifecycle use.

I will say that I personally prefer the configuration scheme used by Airbus over Boeing and many other commercial OEMs because it uses a CAD/CAM – PDM/PLM approach to Configuration Management using a unique Functional Identification Number for positions and cross position logic rules versus the traditional ATA Chapter & Verse system number system used for decades in the aviation industry. So for an Airbus aircraft, every position has a unique FIN which itself can role and authorized systems, assemblies, appliances, components and parts for each FIN and supports logic rules between FINs and other FINs as well as components and other components.

In aviation we say, the only time a “part is a part” is when you receive it from the manufacturer. Once used, it is unique.

Michael, thanks for such a great industry example. In my view, Identification is a core of a successful solution in product development and product data management. The identification of serialized configurable products (i.e. Aircraft is a typical example) is probably the most complicated task. I just referenced B747 example in my cloud plm and Amazon S3 post (http://beyondplm.com/2011/07/2…. The amount of data to manage in configured serialized assemblies is huge. Best,Oleg

Scott, Yes, technically there is no need to use “magic” numbers if you completely move to a data-driven PDM/PLM back-end environment. However, “humans” have hard time to understand simple numbers. I think you captured this point very well. So, some semantics needs to be applied to help people reference right things in a right way. Just my opinion. Best, Oleg

Thanks Oleg. I started on a Matrix One solution implementation to go
to a multisite Dassault solutions implementation and now I'm working, since 3 years, on analysis, test and evaluation of the main solutions into the market to make a choice in my Corporate.
I tested PTC, Dassault and Siemens solutions.

Depending on the product line, the placeholder for numbers within the part number can identify sizing, expansion, portability etc. You see a part number and at a glance you know how many expansion ports, how many broadband ports or whatever lies behind that numbering scheme. When the instructions to assign part numbers becomes its own piece of documentation, you know that you've gone too far.

I think that going through your example is the best way to illustrate why one company SHOULD NOT adopt speaking numbers in product development.

First of all, this coding needs a manual of a couple of pages to be interpreted. No-one outside the team of developers can read that code, unless explicitly instructed to. And of course, this code will be unique for the class of product (a microcontroller will not have the same classification as a ADC converter) and for the company manufacturing this.

Which means,
1) if the manufacturer wants to hire anyone, they have to teach them a code for every class of products they work on.
2) if a company wants to purchase that kind of product, let's say to design and manufacture a hi-tech consumer product, the designers and the purchasing department need to learn dozens or hundreds of such codes: one for each class of product for each supplier of componentry. They will make costly mistakes, and finally they will decide to classify the component with their own scheme – which will make this coding totally useless.
But going to the content of the coding (assuming a company has a PLM system to store information about that part)
 
First, let's see it from the point of view of the user of the component
MSP = Mixed Signal Processor – it is a classification, helpful to search on the part name with string “MSP*” - other searches (based on parameters) are not possible.
430 = member of the 430 MCU platform: this is also a classification, and implies many more parameters (voltage, shape, tolerances, ….) which one may infer, but they need to know the platform values for this to be useful.
F = memory type: classification parameter
G= end equipment optimized: this is even information that restricts the re-use of this part – right out damaging. If it works really well on Meters (E), you would never know!
4 = 4th generation: is it relevant? Just to search whether there is a newer product on the same family…
6 = series or similar function: right out confusing – what that is supposed to mean?
19 = Family (memory size and peripherals config) : is this a subset of the platform? that helps with providing classification information in the same way – you need to know the family characteristics first.
I = temperature range: classification parameter. restrictive (min and max temps would be more useful)
QZW = package: classification information on packaging – need to understand the meaning of QWZ
R = optional (tape & reel): classification information on packaging – the last two attributes are only related to manufacturing information – the designer should not be concerned, but the mfg engineer should be.

All in all, from the users point of view an internal classification mechanism is much more powerful, flexible and efficient.

From the point of view of the developer of the device, all this information needs to be already known in the specifications, so that he can create this number when he starts creating the item. So, it 's redundant in the detailed design phase, and it's not available in the concept phase when some of these choices may not have been finalized yet. Which will force a re-numbering operation and potential loss of valuable information.

So, IF you have a PLM system available, this is not really an optimal solution. But of course, it gives you the opportunity to learn a lot from the number itself, when you DO NOT have a PLM System available. If you are a designer reading a schematic, or a user of a paper catalogue of parts, or a guy diagnosing and repairing a device for which you don' t have detailed specs available, this is essential information, but you need to know a lot in advance.

My take on this subject is that this compact piece of complex information is needed at many different points of the product life, but it should not be the unique identifier. It can be an attiditional attribute (Nomenclature, or something similar); it can be generated automatically in a very easy way, and stamped on drawings, on catalogues etc.

Hi Oleg- great topic!  and a spirited discussion. I read an article regarding GM, which as everyone can imagine has many part numbers. They hired a very smart person to study if they should use ” intelligent” part numbers. He spent a year studying the real world issues, collaboration, manufacturing, supply chain, global, language, etc etc- The conclusion was- smart part numbers added no real value, and his recommendation was to use sequential numbers for parts. Now, this seems to be more like a religious debate, than a practical one inside of companies, and I tend to chuckle when the topic is brought up in the conf room with people at the company all sitting around, getting red in the face while discussing the topic- It is sometimes more entertaining than a good comedy show!
Steve

it is even more complex: not to speak about renumbering MPN by resellers, different use and business rules of the same MPN in the organization (which makes the identification by MPN+CAGE not unique enough), different manufacturers using the same MPN, several enterprise identifications (CAGE is only one of them).

As MRO companie we use as well an meaningless internal database number and the number provided by the OEM and if necessary the PN provided by the supplier. In some solutions you are able to choose which number apears as default in the screens.

ps: why did you bring FIN to the table as this is a different identifier and not a partnumber?