Jobs about Design

Today I read a paper from Arena about MBOM. This post is pretty good, and try to explain what is MBOM, compared to engineering BOM. I had nothing to tell against that post, so I strongly advise to read it.

My favorite sentences are the following:
The more accurate and complete the contents of the manufacturing bill of materials are, the better the decisions you can make about how to get the product efficiently and cost-effectively into the customer’s hand.
The accuracy and completeness of a manufacturing bill of materials allow a company to make better trade-offs and improve its ability to successfully ramp, build and introduce a new product.
The manufacturing bill of materials drives manufacturing, operations, purchasing and logistics for a product.

Where things are getting worse is when the author wants to compare EBOM and MBOM. Talking about engineering BOM for a mechanical product:
The structure of the mechanical BOM is generally derived from the mechanical CAD model. That BOM is organized according to the engineers’ design process and often contains groups of unassociated parts collected together for the engineers’ convenience in working with the model.

That’s where I do not fully agree. I feel that if we think that EBOM is driven by the design process, it might mean that designers are missing another product structure which is the digital mockup. The DM is not a BOM, it is a product structure where the focus is on the form, the fit and the function (FFF). There is no quantity in a DM, while there is in a BOM. But there are positioning information between components, which are not in the BOM. See some thoughts about that topic from my friend Hervé Menga.

The step after is then to decide on single BOM or synchronizing different BOMs, or to integrate manufacturing people in the design process, or similar project organization trends that we have seen for the 2 last decades, targeting design time reduction and efficiency of the design from a manufacturing point of view. There is no ideal solution for that question in my view, I feel that the question is more in how the decision is supported by the organization (collaboration of the teams around the same product structure), and how people are adopting the concept in their daily work.
But instead talking a lot about what is design and what it’s not, I prefer cite Steve Jobs:

Design is not just what it looks like, Design is how it works.

By the way, it should be deeply adopted by software designers!

What do you think?