In an integrated world between Product Development & Engineering (PD&E) and Supply Chain, the main interface is the BOM, the Bill of Materials. Now is it, as Robin Saitz points out, a bomb?
Actually, we first have to define what BOM we are talking about, as there is the e-BOM, or engineering BOM, typically maintained in the PLM environment and describing how the product is developed. Second we have the m-BOM, also known as the manufacturing bill of materials, mainly focused on the components or ingredients. The m-BOM is maintained in the ERP system and is a critical part of Master Data Management. Third we have the s-BOM, focused on support of the product in the field. All three contain a common base, but each has specific information related to the functions performed.
The question is obviously which of the three is the master. Well as long as the product is not released, this should not be an issue. It obviously makes sense the e-BOM leads the way. But what happens after NPI (New Product Introduction)? At NPI, the other two BOM's are updated. From that point onwards they should stay synchronized.
However, here we come to another question. When an engineering change is initiated, is this done by PD&E, or is there a separate team within production that takes care of the engineering of products, once they are in production. Obviously, if the change is initiated by PD&E, the e-BOM will be updated and this information should cascade again to the m-BOM and the s-BOM. In the second scenario things are trickier. Indeed, will the engineers allow those production people to access their PLM environment, or do they want to keep that to themselves? In that case, the engineering changes will be entered in the m-BOM and s-BOM directly, but that builds discrepancies between the three BOM's.
The closer the BOM's can be, the easier it is to maintain consistency. Design for Manufacturability (DfM)/Design for Supply Chain (DfSC) and Design for Serviceability (DfS) allow the teams to work together in the development and roll-out of the new product, do not only foster relationships between engineering, manufacturing and services, but often result in higher quality products that can be manufactured and serviced at a lower cost, as Tom Shoemaker points out in a blog entry titled BOMs and better development.
DfS is probably the most obscure of the above acronyms. And my "google meter" shows there is not a lot written on the subject. It's all about thinking, during product design, at how the product will be maintained once in operations. You may ask yourself why this is important. Well, facilitating the work of service engineers reduces the cost of warranty and improves customer service. There is another reason these days, and it has to do with the increased trend for "pay per use". The other day I ran into an aerospace company telling me they have started selling (or renting might be a better term) their motors per flying hour. Now, every hour the motor is kept on the ground reduces revenues. The manufacturing company is now responsible for keeping the motor flying and suddenly serviceability becomes a hot topic. The electronics industry has been looking at this for a while, hence the reason they approached us to understand what we do in that space.
Joe Barkai from IDC-Manufacturing Insight points out that the small upfront investment of thinking about serviceability while designing the product is largely off-set by cost reductions in the field. This has been our experience too. But he also makes the point that design engineers neglect long-term, life-cycle costs. Measurement and reward systems may have to be adapted to ensure the appropriate behavior gets engrained in the engineering culture.
DfM/DfSC is already gotten somewhat more in the culture, as we have been at it for quite a while now. I remember hearing about it in the late 80's. However, there are still companies with a large gap between engineering and manufacturing. Demonstrating the importance of the synchronization between the e-BOM and the m-BOM can surely help bridge the gap. People, processes and systems are not three independent components of the organization. They interact extensively and by improving one, we may hope that the other ones improve also. Your thoughts on the subject?
