PLM Platforms

Oleg Shilovitsky posted a blog about PLM Platforms.

https://www.linkedin.com/pulse/article/20140829141304-949935-the-foundation-for-next-plm-platforms

Of course, I have to comment. In addition to the  two major foundations of the current PLM platforms, these platforms were also designed to address file proliferation and the need for collaboration. CAD tools need file management. They are single user, meaning people cannot collaborate on a design and they produce a file that contains the geometry for a single part or collection of parts. PLM platforms (or in the early days EDM and PDM) was developed to address the deficiencies of CAD: file management and assembly management.

PLM has still have not solved the problem of providing control for multiple parts in one file. PLM systems do not cross file boundaries very well.

PLM has not provided very good collaboration capabilities either. Using check-in / check-out for collaboration is very inefficient and results in disjointed, unsynchronized knowledge development.

And don’t get me started on the inability to find information in PLM or the fact that so much critical product knowledge is stored on drawings and MS word documents.

The next generation PLM platforms must be a design platform. Files must be eliminated and replaced with ways to capture and manage detailed data about products and components. Geometry is just another way to describe a product. It should not be separate from the design platform.

A couple of us at Digital Equipment Corporation (DEC) designed a multi-disciplined, collaborative CAD system back in the 1980’s. The idea was that people would design with objects consisting of geometry, schematics (for electrical), data, performance models, etc. The objects would know how to interact based on solid model interactions and other conditions. The problem was the hardware and software infrastructure didn’t exist to support our design and the project never really got off the ground. If only it had...

Is Data Engineering Needed in Product Development?

We have electrical engineering, mechanical engineering, structural, electronics, civil,etc. Each of these engineering disciplines has a specific set of formulas, principles and heuristics that govern now the engineering discipline is performed. We codify these rules to protect the general public. Would you feel safe driving over a bridge that was engineered by a person who didn't study structural engineering?

In a world where most products produce or consume data, we need to understand how to engineer the data. The impact of improperly engineered data can be just as catastrophic as that of an improperly engineered bridge. Incorrectly collecting and  analyzing data can lead to improper interpretation which can lead to decisions that turn out to cause harm. Any product that generates or consumes data should have a data engineer on the team.

A data engineer is not a programmer or a data modeler (although these skills may be useful) but a person that addresses issues in designing, building, managing, and evaluating advanced data-intensive systems and applications. The data engineer studies big data techniques, information theory, entropy (the measure of uncertainty in a random variable). A good data engineer has both the ability to manipulate data and an understanding of the analytic purposes to which the data are going to be used.

There is a danger in engineering today that each engineering discipline operates independently without thinking about the product as a system as a whole. There needs to be a person on the engineering team who can “bring it all together”. A person who knows enough about each discipline to synthesize all aspect of the product, mechanical, electrical, data.

This TED talk by Marco Annuniziata, The Chief Economist at General Electric, explains why data is so important to products and my extrapolation, why data engineering is critical to product development teams.

Is Your Organization Making Good Product Decisions

A recent engagement with a client has been keeping me very busy so I haven't posted in a while. I did have the opportunity to write a commentary on decision making in product development organizations.

The key takeways are:

• Product development is a continual process of making decisions that turn the unknown into the known
• Faulty decisions can have a huge impact on your company
• High quality knowledge is required for making good decisions
• Building knowledge that results in corporate wisdom requires stable communication channels
• A new breed of decision-support tools establishes stable communication channels

Here is a link to the document:

http://www.cimdata.com/en/resources/complimentary-reports-research/commentaries/item/377-is-your-organization-making-good-product-decisions-commentary

Dana