You are currently browsing the tag archive for the ‘Items.Parts’ tag.

In my last post, My four picks from PLMIF,  I ended with the remark that the discussion related to the Multiview BOM concept was not complete. The session presented by James Roche focused on the Aerospace & defense domain and touched the surface. There is a lot of confusion related to best practices associated with BOM-handling. Sometimes created to promote unique vendor capabilities or to hide system complexity.

Besides, we need to consider the past as, in particular, for PLM, the burden of legacy processes and data is significant. Some practices even come from the previous, paper-based century, later mixed with behavior from 3D CAD-systems.

Therefore, to understand the future, I will take you through the past to understand why certain practices were established. Next, in a few upcoming posts, I want to explain the evolution of BOM-practices. How each new technology step introduced new capabilities that enabled companies to improve their product delivery process.

I will describe the drawing approach (for PLM – the past), the item-centric approach (for PLM – the current), and the model-driven approach(for PLM – the future). How big this sequence will become is not clear at this stage.

Whenever I come close to 1200 – 1500 words, I will stop and conclude. Based on my To-do list and your remarks, I will continue in a follow-up post.  The target will be to have a vendor-neutral collection of information to help you identify your business and the next possible steps.

Working with drawings

MRP/ERP – the first IT-system

For this approach, I go back fifty years in time, when companies were starting to work with their first significant IT-system, the MRP-system. MRP stands for Material Requirements Planning. This system became the heart of the company, scheduling the production. The extension to ERP (Enterprise Resource Planning) quickly after, made it possible to schedule other resources and, essential for the management, to report financials. Now execution could be monitored by generating all kinds of reports.

Still, the MRP/ERP-system was wholly disconnected from the engineering world as the image shows below. Let us have a look at how this worked at that time.

The concept

Products have never been designed from scratch by jumping to drawings. In the concept phase, a product was analyzed, mainly on its mechanical behavior. Was there anything else at that time? Many companies thank their existence from a launching product which someone, most of the time, the founder of the company, invented in a workshop. The company than improved and enriched this product by starting from the core product, creating enhancements in various areas of applicability.

These new ideas were shared through sketches and prototypes.

The design

The detail design of a product is delivered by a technical documentation set, often a package of manufacturing drawings containing a list of parts on the drawing, assembly with instructions. Balloon numbers are used to indicate parts in an assembly or section view.  In addition, there are the related fabrication drawings. The challenge for this approach is that all definitions must be there uniquely and complete to avoid ambiguity, which could lead to manufacturing errors.

The parts list contains make-parts, supplier parts, and standard parts. The make-parts are specified again by manufacturing drawings, identified by a number that uniquely identifies the correct drawing version. A habit here: Part number = Drawing Number (+ revision)

As the part is identified by a drawing the part most of the time got an “intelligent” part number and a revision. Intelligent to support easy recognition and revisions as at the end we do not want to generate a new part number when there is an evolution of the part. Read more about this in What the FFF is happening and “Intelligent” part numbers?

The standardized parts can be either company standard parts or external standard parts. There is a difference between them.

A company standard part could be a certain bracket, a frame. Anything that the company decided to standardize on for its own products Company standard parts are treated like make parts; they have an identifier related to their manufacturing drawings.  Again, here the habit: Part Number = Drawing Number (+ revision)

The supplier part is coming from a supplier that manufactures this part based on the supplier or market specifications. You can specify this part by using the supplier’s catalog number or refer to the standard.

For example, the part that has been specified under a certain ISO/ANSI/DIN-standard. For example, a stainless-steel bolt M8 x 1,25 x 20, meaning a metric bolt with a head diameter of 8 mm, a speed of 1,25 mm, and a length of 20 mm. You specify the standard part according to the standard. Purchasing will decide where to buy this part

Manufacturing Preparation

This is the most inefficient stage when working in a traditional drawing approach. At this stage, the information provided in drawings needs to be entered into the MRP/ERP-system to start production. This is the place where information is thrown over the wall as some might say.

This means a person needs to create process steps in the ERP-system based on the drawing information. For each manufacturing step, there needs to be a reference to the right drawing. Most ERP-systems have a placeholder where you can type the drawing number(s). Later, when companies were using CAD, there could be a reference to a file.

The part number in the ERP-system might be the same as the drawing number; however, the ERP-system requires unique numbers. In the beginning, ERP-systems were the number-generator for new parts. The unique number was often 6 to 7 digits in size, because it fits in our human short-term memory.

The parts list on the drawings had to be entered in the ERP-system too. A manual operation that often required additional research from the manufacturing engineer. As the designer might have specified the SS Bolt M8 x 1,25 x 20 as such, manufacturing preparation has to search in the ERP-system for the company’s part number.

Suppliers have to be sourced for outside manufactured make-parts. In case you do not want to depend on a single supplier, you have to send drawings and specifications to the supplier before the product is released. The supplier will receive a drawing number with revision and status warning.

If everything worked well the first time, there would be no iterations between engineering and manufacturing preparation. However, this is a utopia: prototype changes, potential manufacturing issues will require changes in the drawings. These changes require updates in the drawings, which will lead to new versions. How do you keep consistency between all identifiers?


During manufacturing, orders are processed based on information from the ERP-system. The shop floor gets the drawing provided to the link in ERP. Sometimes there are issues during manufacturing. In coordination with engineering, some adaptations will be made to the manufacturing process. e.g., a changed fit or tolerance. Instead of going back to engineering to provide a new documentation set, the relevant drawings are redlined. Engineering will update these drawings whenever they touch them in the future (yeah, yeah).

Configuration Management

But will they update them? Perhaps already a new version existed due to the product’s evolution. Everything needs to be coordinated manually. Smaller companies heavily rely on people knowing things and talking together.

Larger companies cannot work in the same manner; therefore, they introduce procedures to guarantee that the information flow is consistent and accurate. Here the practices from configuration management come in.

There are many flavors of configuration management. Formal CM was first used in the 1950s to control the technical documentation for complex space and weapons systems. (Source ESA CM initiative for SME’s – © 2000) We will see it come back in future posts dealing with more complex products and the usage of computer systems.

Last year I wrote a few times about PLM and configuration management (PLM and CM – a happy marriage?) not relevant at this moment as there is no PLM yet.

Where is the BOM

As you might have noticed, there was no mentioning of a BOM so far. At this stage, there is only one Bill of Materials managed in the ERP-system. The source from the BOM comes from the various parts lists on the drawings, completed with manual additions.

Nobody talks in this stage about an EBOM or MBOM as there is only one BOM, a kind of hybrid BOM, where manufacturing steps were driving the way parts are grouped. Because the information was processed step by step, why would you like to have a multilevel BOM or a BOM tree?
Note: The image on the left was one of my first images in 2008 when I started my blog.


Working with drawings introduced “intelligent” part numbers as the documents have to be identified by manual interpretations. The intelligence of the part number was there to prevent people from making mistakes as the number already was a kind of functional identifier. Combined with a revision and versioning in the number, nothing could go wrong if handled consistently.

The disadvantage was that new employees had to master a numbering system. Next, the risk for all employees that a released drawing will not change its status. Only manual actions (retract/replace) will avoid making mistakes. And then, there are the disconnected redline drawings.

The “drawing number equals part number”  relation created a constraint that will be hard to maintain in the future.  Therefore you should worry if you still work according the above principles.


I reached the 1500 words – a long story – probably far from complete. I encourage readers to provide enhancements that might be relevant in the comments. This post might look like a post for dummies. However, to understand what is applicable to the future, we first need to understand why certain practices have been defined in the past.
I am looking forward to your comments and enhancements to make this a relevant stream of public information for all.

This week I was in South-Africa working with Aerosud, one of the prominent companies in the Aerospace industry in South Africa, working with the major OEM’s One of the topics discussed in the workshop with Aerosud was the connection between PLM and ERP. As this is a question that occurs so often, see also previous posts, I will address in this post and the upcoming posts the logical steps for an PLM – ERP integration and issues a company might face.

For some people I guess the big surprise will be that most of the difficulties and discussions are not on the technical level, but on how a company has organized their data and organizes their data in the future.

The first rule for implementation is:
The PLM system manages all product related IP (Intellectual Property) and the ERP system manages the executing in the most effective way, taking into account resources, time, material scrap etc often linked with financial transactions

Although some ERP vendors might want you to believe they offer also PLM functionality in their system, it is always a small subset of the total PLM capabilities. Linking manufacturing documents to an item is not PLM. PLM is managing all product related IP and this requires connections to all information sources during the whole product lifecycle, not only during manufacturing.

So if we agree on the above, we understand there is a need to connect PLM and ERP, as both systems have a vital task in a manufacturing company and both work around common information, the product, composed of all its physical items.

Items The Item

The physical item, is the shared and understandable entity understood through the whole company. Some companies call their items parts. In order not to confuse between an item and a part designed in the CAD system, i will talk about items, when I mean the physical representation.

Items can be a single item, a rivet, a specific metal plate or it can be a complete product or smaller component of a complete product. They have one thing in common, we all identify them with a unique number the item number.

In engineering oriented companies you might hear designers say, the item number is equal to the part number of the part or product they are designing, as often in their case what they design on the lowest level of the assemblies, becomes an item.

In general you can subdivide the items in two major groups:

  • standard purchase items
  • company or project specific items.

 Standard Purchase Item Standard purchase items

The characteristic of a standard purchase item is that it has been designed and developed by external companies and that these items can be found in catalogs produced my one or more manufacturers around the world, based on defined standard. For example a M12 Nut, a bearing with specific diameter and performance characteristics. The company that uses these standard parts creates an own definition of the part and makes references to manufacturers who provide these parts in the right quality and standard. These manufacturers appear on the Approved Manufacturer List (AML), which is an engineering task inside PLM to define this list.

In addition, based on this approved manufacturer list, the purchasing department will allocate vendors for these parts and based on vendor performance and reliability, they create a List of Approved Vendors (AVL)for these parts. This is a execution task to be defined in the ERP system.

So in day to day operation, engineering will define new standard purchase items if not available and this request will lead into an AML and then in ERP towards a AVL of the standard item. It is a combined activity where each of the disciplines has participate. For existing standard items, there is also a process triggered from ERP that influences their usage. For example a certain manufacturer might stop producing a certain item and this affects the AVL – purchasing raises a flag that the item becomes hard to acquire or even unavailable, which leads to engineering to define a new AML, which might end up in an engineering change as by changing some of the product functionality other standard items can be used to replaced the original defined item.

So for standard purchase items we see:

  • new standard items are introduced through PLM – starting from AML into ERP with the AVL.
    Both system add information to the item information
  • exiting standard item can become obsolete through PLM – as the company decides not to use them (anymore) or become phase out or obsolete based on a trigger coming from the ERP side, as the AVL has changed.
  • Standard purchase items do not have revisions


Item Items

With items here we mean the non-standard purchase items, which can be divided again in two major groups:

  • company standard items
  • project specific items

Project specific items are items defined by engineering during the definition of a product. These items need to be manufactured specifically for this product based on the specification provided by engineering. Outside the project these items are not used again anymore as they are too specific.

However companies try to standardize even their project specific items, in order to share and reuse them in other products. At this stage, the project specific item becomes a company standard item and is managed to be reused.

Both company and project specific items can have revisions as their maturity may grow. As long as the new definition complies to the Form-Fit-Function rules, the new revision of the defined item can replace previous revisions, meanwhile better support future usage.

So for items we see:

  • project specific items are introduced through PLM and on the moment of production pushed to ERP to be manufactured according the design specification with the right revision
  • company standard items are introduced through PLM and can be produced on stock (if there is a wide usage through various products) or pushed to ERP when needed to be manufactured according the design specification with the right revision
  • Items are revision managed and follow the Form-Fit-Function rules

The conclusion of the above for this post is:

  • Items have a common usage in both PLM and ERP
  • Items are initially created in PLM and at a certain time transferred to ERP to be completed with logistical information
  • Item usage can change based on availability triggers from ERP or use cases in PLM
  • an item is a hybrid entity – with a common shared identification, PLM relevant data and ERP relevant data
  • Some of the ERP data might be relevant for information to be viewed the engineer and the other way around


Once agreed on the above concept, we have the guidelines how to connect items between an PLM system and an ERP system.  In my next post I will talk more about that, also about how to connect BOMs between PLM and ERP.

Subscribe to this blog if you want to follow this sequential on how PLM and ERP connect and work together
Subscribe in a reader



  1. As a complement, even if more and more of the diversity of a product is managed at the software level…

  2. 1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…

  3. BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…

%d bloggers like this: