Those of us who work in Product Lifecycle Management tend to forget the time before we understood PLM or what it’s for.  So when we get asked this type of question it can be a struggle to come up with a user-friendly answer that is not full of jargon.  There are plenty of opaque examples on the Web.

I am as guilty as anyone.

So in this first blog I have set myself the challenge of retelling the PLM story for people who are new to PLM.  This includes managers who delegate anything PLM because they don’t “get it” enough to make informed decisions.

Why was PLM invented?

Products need to be designed and then made.  Engineers and Designers conceive and design the best product they can, they record it using models, drawings and documents and then they hand it over to the people who have to manufacture that product so that the organisation can make the most money.

Then they change their minds.

In the middle of the last century, a designer or engineer wanting to make a change would have to go the Drawing Office (“D.O.”) and beg for the original drawing back so it could be modified.  Forms would be filled in, maybe a change note signed and only then would the custodian release the drawing to allow changes to be made.

But when CAD came along, it allowed the designer to make changes pretty much all the time – the master data was just a file on the designer’s PC and there was no custodian.  The result was errors and confusion because the information that manufacturing was using didn’t always match what the designers considered their latest design.  You couldn’t go back to using the DO because they had all been fired as part of the justification for investing in CAD.

Enter PLM (but called various other things at the time).

What’s inside PLM?

PLM has a thing called a Vault that allows designers to deposit files, each file having its own entry in a database.  Each of these database entries has a status field that represents the approval or release level of the corresponding file in the Vault.  If the release level is low (such as “In Work”) then the database allows the originator to retrieve the file and make changes to it.  If the database entry has a high status level (such as “Released”) this means that too many people downstream are depending on this information so it is more difficult to get the file back.  To make a change, the file has to be copied and given a new identity so as not to disrupt what is already going on downstream.  If the re-identified design proves worthwhile, there are some forms to fill and, if everyone agrees, then the new version can be used.

But wait!  This means that someone has to specify what all the possible status levels are; it would be daft to make them different for every product so best to figure out a standard sequence.  That sequence of status levels represents the Lifecycle of the things in the Vault.  You have to progress from one Lifecycle state to the next and this may involve lots of other people and disciplines to check and approve the move.  In the D.O. days, this was likely done with paper forms.  But our PLM has a database so why not let all the people that need to contribute to each form just login and do it directly in the system?  A Workflow allows people to review material in the system, add information and go/no-go for the next stage in the process.  The fact that all these people may be able to view this original material as it evolves from level to level is in effect a basic form of cross-functional Collaboration.

 

Most products aren’t defined by just single drawings or CAD models.  Maybe there are complex assemblies or a merging of separate mechanical, electronic and cabling models.  Some way is needed to relate these different things together so they don’t get lost or confused.  This is the role of the Part and its relationships.  In PLM, the Part, a term already common in Manufacturing, is a database entity used to hold properties, to control its file in the Vault and to link to other Parts.

The concept of a Part doesn’t come easily to those used to dealing primarily with drawings and this will be the focus of a future post.

I.T. is no good unless you can get information out of it.  A lot of very valuable information is locked up in the Parts, in the relationships, in the Vault, in the Lifecycle states and in the progress of Workflows.  Reports can be constructed that summarise this information and that makes management more efficient.  Similarly, an ERP Integration can take the product information from PLM and transfer or update a separate manufacturing system so as to avoid someone re-keying everything.

If you store in Part to Part relationships the position and orientation in a 3D co-ordinate space then you can use a Visualisation tool to show and manipulate 3D representations of the Parts together.  In effect this is a virtual mock-up of the evolving product and is a way to see models from different tools to check that everything fits together.

The final element of PLM to deal with in this post is Administration.  The whole system depends on defining users, roles, teams, projects, authority levels, types of Parts, etc. etc.  This can be a complex task with many interrelated factors and getting this right is one of the keys to success.

What about…?

I can hear some readers shouting at the screen: “But what about…” then saying one or more of Configuration Management, As-Built, Service Parts, Parts Catalogues, EBOM to MBOM, Process Breakdown, Functional Breakdown, Embedded Software, Analytics, Security, Programme Management, Dashboards, Augmented Reality, Digital Twin, PLM benefits, adoption and so on.

Well I just mentioned them there.

But any detail now on such topics is not going to help anyone unfamiliar with PLM and is more likely to confuse.

So I am drawing stumps at the basics and leaving the rest to future blog posts.

 

COMING SOON: What a Part is and what it means to be Part Centric.