Have you ever taken a design for a physical product through to production? If you have then you’ll appreciate the need for a solid and useable Bill of Materials. Have you ever tried to develop a maintenance program for a physical product or system? If so, then you’ll know how pivotal the Bill of Materials [BoM] was in helping you define the modularity and level of spares inventory required. I believe there is an underlying assumption made by businesses struggling with the transition of a new product into production and deployment – that the development BoM is automagically transferable without rework and review.

© dotshock / 123RF Stock Photo

© dotshock / 123RF Stock Photo

The key problem that I have seen emerge is caused by a disconnect between development thinking and assembly thinking. Good design normally follows a pathway that decomposes the problem space, assigns functionality to blocks within this space and then re-assembles these blocks into a solution architecture. This process naturally creates a hierarchy that is built around functionality. On the other hand, the manufacturing and assembly process is not focused on product functionality rather it is necessarily concerned with the sequence in which components and sub-assemblies are integrated. Sure, there is some overlap from the perspective of in-process testing but, in the main, there is minimal utility in manufacture for a functionally hierarchical BoM. What is needed is a dedicated BoM that allows the constituent parts to be procured and assembled in the most efficient manner.

There are two key parts to the solution. The first is to include manufacturing representatives in the development process. This idea, known as ‘concurrent engineering’ helps ensure that any new product is able to be manufactured and, as a natural consequence, is likely to be easier to maintain. In terms of human-centered design it recognizes that the customer segments for the new product include the manufacturing and assembly team. As a side-note, the concept should be extended to include the product support team and end-user maintainers as well. The second part of the solution is to design a transition into the process and not assume that a simple hand-off will be sufficient. Design of the manufacturing sequence, tools and equipment must evolve alongside the product and influence its final form. As part of this process there must be a translation of the BoM into something that supports manufacture rather than hinders it.

There are several benefits arising from adopting this approach. Inventory is reduced because the procurement and assembly modularity become easier to define and hence supply logistics can be sequenced more effectively. Delivery of inventory to the shop floor is simplified because the batches are closely related to the receiving cells and their assembly processes. Additionally, there will be a consequential simplification of any impact analysis arising from changes to the either the parts or the assembly process. As a final note, spares analysis will also become more straightforward as statistics can be more easily built around coherent repairable/replaceable units identifiable within the BoM hierarchy. I can testify, from experience, that this is especially important if your end-user is planning to adopt a proactive Reliability Centered Maintenance [RCM] model.

So, the bottom line is that I suggest that you to examine the information you are developing (or already using) and review whether it truly supports the end game or could do with a little tweaking from another perspective. Like many things, this is easier to do up-front but, nevertheless, it retains value downstream as well.

Development BoM | Manufacturing BoM | They’re Different


“Begin with the end in mind.” – Stephen R. Covey

Want some personalised insights? Click here to get started...
AuthorTrevor Lindars