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?

Co-authoring and Versionning: we need both!

Today I read here that google docs on Android was enhanced by co-authoring, allowing several people to collaborate in real time on the same document. It reminds me a tentative of the same nature in the dead google wave application. Wave was seen as a very promising platform. Most people where enthusiast about a new social media app, but as a PLM specialist I remember having seen more deep interest in the platform for two aspects:

  • Co-authoring in general, and especially for CAD
  • The timeline

Co-authoring for Engineering disciplines
CAD was in the past a discipline like coding, where your work needed time to be done before it can be shown to someone else for review. But improvement brought last years has decrease the time to design using CAD tools, allowing now design sessions. The point is that in parallel, the design teams have been split geographically, so there is a need for online CAD sessions. Wave was in my view a new platform for such real time collaboration.
Product definition history
The timeline in Wave was apparently simple. As people were using the application, every single action was recorded, and the full history could be simply played again, like you look at a movie. No need to manually capture some specific instants in order to track them for future use, everything was available for future use. I feel you see where I go. In our PLM applications, we implement versioning and revisioning mechanisms, in order to keep track of the current state.
Some years ago, I had a presentation of SharePoint 2010 at Microsoft, were we experienced real time co-authoring capability on the same excel file. And the presenter said at the end: “do we need versioning if we have co-authoring?”. Whao, what a question, I thought!
The google wave answer was: No, but what about the PLM answer? Do we still need version numbers for PLM objects if we have their full history, their full lifecycle, available?
For sure there is an answer from the IT infrastructure guy, requesting huge storage capabilities. But science will solve this issue with atom based storage in the future.
But the product manager answer should be that he doesn’t care about the full history. What he would like is to have instant access to the product configuration at the time of a specific milestone or date of the product lifecycle. And Wave will not help for that.
It’s a pity, as it is not so easy to anticipate which version or status will be useful in the future. That’s the reason why, often, there exist corporate rules to define a version in the context of a specific milestone which has been defined in the milestone set from the standard program framework of the company.

So my answer is today that we should benefit from co-authoring for engineering discipline to face now a global distribution of design team, bit we still need classical versioning mechanism to track product maturity at given dates or milestones.

And you what do you think?

Quick pick: look at inteview of John Alpine on


I had chance to read the interview of John Alpine, VP of R&D at Spatial. He is telling interesting things about collaboration in CAD domain.