New to PLM – PLM Basics (Part No, Workflow/Lifecycle, Attributes)

Introduction

While I've been working on the PLM book (still quite a way to go) I've neglected the white-papers. I wanted to write a very basic paper for people starting off on PLM adventures. In this article I'll cover some key concepts and ideas needed when you are kicking off.

What is PLM

So my definition of Product Lifecycle Management (PLM) is as follows.
“Delivering the right information for people to do their job at the right time.”
I have used this definition for a long time and I still think it holds true. I don't intend to go into details in this white-paper but basically PLM allows companies to better manage product data and share it throughout their organization. For many years companies have undervalued their intellectual property (IP) and especially the design component of IP. It makes sense to manage and utilize design data as efficiently as possible and PLM facilitates this.

Main drivers for implementing PLM

There are several things that might drive you to implement PLM, but you should be clear on which are the most important to you before starting.
Some drivers are listed below
  • Time wasted looking for data
  • Cost reductions/re-use improvements
  • Forced to implement due to OEM/vendor requirements
  • CAD data management
  • Getting control over data
  • Improve quality of products/designs
  • Expanding/globally dispersed teams
  • Collaboration
All of these (and others) are good reasons to implement PLM, but try to choose one or two as the main objectives.

Get smart

Before pursuing a PLM solution it pays to learn as much as you can about the technology. I've listed a few ideas on how to do this in the next few sections – in no particular order! One caveat here – don't judge the entire space via one company (or bloggers) view – there are lots of solutions and approaches to solving the issues you have. So look at all the resources you can find and make up your own mind on what you need.

Vendor websites

Vendor websites have lots of information. I'd suggest starting with video case studies from companies who have implemented the vendor's tools. These are usually slick, but they do give some overall impressions and I think are useful. Next I'd look at the core functions that the vendor has.

User-group forums/websites

User forums are really useful. Most (if not all) vendors have user groups, these are a good source of information. Sometimes the information can be too specific, but there are likely to be introductory threads and you could always sign up and ask the experts for more help.

Meet others who already implemented

If you can track down people who have implemented PLM at their company this can be a great way to learn more and understand what mistakes not to make! You should check your own networks and also use tools such as LinkedIn to find potential mentors/teachers

PLM Blogs/Analysts

There are quite a number of bloggers and also groups who have sites for PLM; read these and see what they are saying.

Training classes

Some PLM vendors, partners and others offer training classes. These are mainly targeted at specific tools. These can be useful since you can learn some basics of the tools with hands on sessions and also you get to meet other customers who use the tools. Talking to other customers in these sessions can be useful. I'm not sure how willing vendors are at having “non customers” in their training classes!

Intelligent part numbers

When starting out on your PLM journey part numbers will play a huge part (no pun intended!).
A quick definition of an intelligent part number – a part number that is made up of several sections that mean something. For example 12345-IN might mean that the part is produced in India.
The use of part number to mean something has been with companies since the dawn of the industrial age. Try to get the discussion of part numbers over as soon as you can in your implementation. I always recommend non-intelligent sequential part numbers along with attributes – see next section.
My main reasons for recommending sequential number are
  • Maintenance of intelligence – it is not always easy to maintain these complex part numbers
  • Validation of intelligence – if you do not validate an intelligent part number an error can be costly or result in people not being able to find the part!
  • Obsolescence of intelligence – the business world changes very quickly and it it likely that the intelligence you built into parts 10 years ago now does not reflect the way the part is used now
  • You can have attributes to capture the information! See next section
If the discussion becomes too heated on intelligent parts you can position including the intelligent part number as a “legacy part no” attribute.

Part numbers v attributes

As mentioned in the previous section you need to be clear about part numbers versus attributes. All systems allow you to define attributes for your parts/assemblies/documents. You should be careful about defining only the minimum subset you can live with that make sense. There is a huge temptation to define many attributes but remember that someone will have to maintain and validate these so spend time to insure that only the most important attributes are defined for each object type
Part classification can help here too. Basically parts classification is the process of grouping standard parts (and others) by defining attributes and types so you can easily find things in the system. A quick example would be defining a length and material attribute for bolts, then you can quickly say I want a 100mm steel bolt and the system would find all of these for you, possibly with images. You can even broaden queries such as show me all the bolts between 90 and 110mm. This allows companies to make better re-use decisions and (if a preferred vendor attribute is defined) reduce costs.

How to implement

You will need to decide if you are going to “do it yourself” or have a vendor/partner/independent consultant assist you.
In early phases it is good to have someone to help. Be careful to understand what skills/experience the implementer you engage has.
I usually suggest that you decide on a project that is “low hanging fruit” and can show a good return on investment. I'll briefly cover some of those in the next section.
Try to stick to out of the box (OOTB) as much as you can, or minimal “tailoring”. Remember that after the consultant has left updating the system will either be your responsibility or you will have to pay someone to do it.
Many vendors have industry specific solutions and you should seriously consider these if they match up with your objectives. This can save a lot of time and money and they minimize the risks for you. Sometimes the rigidity of these solutions can be a challenge.
Finally in this section you should think about implementation methodologies. If a vendor or consultant is leading the process then it is best to let them use what they have been successful with in the past, but check they are planning to use one. No methodology should be a red flag that someone does not know what they are doing!

Good first steps

Insure that you control the scope of the initial phase of your implementation. Keep things simple for the early phase so you can learn what the tool is capable of.
I'll briefly touch on a couple of areas where early benefits and ROI can be demonstrated in PLM.

OOTB solutions

Several PLM companies have either industry specific solutions e.g. electronics and Aerospace and Defense - A&D or ones tailored to small or medium sized businesses (SMBs). Take a serious look at these cookie cutter options and talk to others who have used them since these can save time and expense on implementations. They also make upgrading a lot easier too.

CAD data management

Many PLM tools allow you to seamlessly (or nearly seamlessly) start vaulting CAD data in a PLM tool. This is a nice place to start since a lot of benefit can be gained from having all your CAD data in one place and easily searchable, leading to improved data re-use. Other benefits include version and revision control, check in/check out and backups. A side benefit (and one for follow-up phases) is that often CAD BOM structures are created automatically in the PLM tool when you store CAD assemblies and so when you choose to move to manage Engineering Bill of Materials you have a good starting point.

Document management

Document management is very close to CAD data management in that you are managing files. Many of the same benefits as CAD data management are applicable in document management.

Cloud or in house

I'd like touch on cloud in this article – I wrote a more detailed white-paper on cloud PLM a while back and you should take a look at that for more details.
It is very important to know what you are getting and the pros and cons of cloud before deciding. Clearly you need to check with your vendor. Some PLM solutions are only available in the cloud!

In house

For people who like control of their infrastructure in house servers are the ideal choice. Clearly this is “old school” IT and comes with some fixed costs associated with hardware and IT staff.
It is less fashionable but can be useful for larger companies and also companies in the defense industry.
The positives of in-house are
  • Complete control over the system
  • Control over security
  • Control over upgrades, updates and planned outages.
The negatives are
  • Many fixed costs e.g. staff, hardware, climate control, software licenses
  • Scalability

Cloud – hosted

I've separated cloud out into two sections. This first one covers cloud where you just buy a platform and install your own systems on it. I'm not a big fan of this approach since it really is the worst of in-house and software as a service with only small advantages.
The positives
  • Some reductions in fixed costs over in house
  • Some increased scalability
The negatives
  • Still many fixed costs like staff. Software licenses

Cloud SAAS

Could software as a service or SAAS is very liberating for IT managers. It allows you to be very agile to business needs. SAAS means you buy access to a system that is already built. The key to success in this area is having a good Service Level Agreement (SLA) with the vendor or cloud partner. You should clearly understand what you are getting in terms of up-time/disaster recovery/support.
Cloud SAAS also can be about who owns what and how much customization and tailoring the cloud partner allows you to do on the system. Sometimes the cloud vendors are quite restrictive of what you can do.
Finally check that the solution provider has a good ITIL (Information Technology Infrastructure Library) background this demonstrates their set up is well established.
Main advantages of SAAS
  • Cost management – what you see is what you get
  • Scalable up or down as needed
  • Most fixed costs are part of the payments
  • System knowledge and easy upgrades
Main disadvantages
  • Reliability is not under your control
  • Loss of control over systems
  • Integrations with the vendor can be challenging
  • Less control of upgrades etc

Training

I would suggest insuring that people are properly trained and that this is included in any plans. Users should not only be trained on the button clicks, but also on the philosophy of the PLM system. It's very likely that some people (engineering) will have to do more work than they used to and explaining why that is the case will help adoption.
As part of training I also include mentoring since the first few weeks after go live are critical for successful adoption.

Things to avoid

I am proposing avoiding some areas in an initial implementation. It may be very tempting to do a lot of things in the initial deployment, but it is better to show success and return on investment rather than doing a lot!
My suggestions on things to avoid is more that they are more challenging and not that they are impossible. Once you have experience with the PLM tools you will be able to accomplish these areas.

Customization

It is good to reduce (or eliminate if possible) any customizations in an initial implementation. There are several reasons for this
  1. Customization takes time and effort (and cost)
  2. Once the system is in place for a while you may decide to change how you operate, at this point you will most likely need to change any customizations.
  3. Custom code calls for custom training which can be expensive
  4. It is likely that custom code could be buggy and this could put end users off using the system
  5. The OOTB tools should be able to handle early phases of a PLM implementation. If they do not you might want to consider other tools!

Change Management

Change management has a lot of prerequisites. This is not a good place to start a PLM deployment. Change management needs lots of things to be in place that are not likely to be there in an initial phase. Also you might need to rethink how you conduct change management once you have seen what the PLM tool can do.

BOM Management

Again BOM management needs lots of things in place to be successful. I would always suggest getting CAD data under control before tackling BOMs.

Closing comments

This paper really only touches the surface of what you need when starting out. There is much more, but hopefully some of these pointers will help.

Comments

Sreeni said…
hi

Very good explanation..

regards
Sreeni
PDMGuru said…
Thanks Sreeni!
Theo Boudewijns (PTC UK) said…
This is good article explaining some basic concepts in PLM and what to think about.
My advise would always be to start planning against a (multi year) roadmap.
Start with CAD Data Management that forms the backbone of getting value of PLM later on, but without planning against a roadmap you run the risk of not getting any further than CAD Data Management.
You are also right about Change Management. Often the need for improved Change Management is a key driver for implementing a PLM solution but Change Management requires a well defined Engineering Bill Of materials (EBOM) to function properly.
Often what is also not understood is that an EBOM is not the same as a CAD Assembly Structure based BOM - I would call this a Design BOM.

A simplified roadmap could like this :
Phase 0 - CAD Data Management (Vaulting) - I call this phase 0 because this is a prerequisite for downstream PLM and also many companies are already doing this but are struggling to go beyond this phase.
Phase 1 - CAD to Design BOM - Connecting Product Related Documentation to the DBOM.
Phase 2 - EBOM development
Phase 2.5 - Adoption of Enterprise Change Management - I call this phase 2.5 because this can be done at the same time of the EBOM development
Phase 3+ - Downstream PLM deployment like Manufacturing BOM (MBOM) development, implementation of Manufacturing Quality Improvements like CAPA and Non-Conformance, Service BOM development etc.
Phase 3 and beyond are often very much dependent on the type of organisation that you are.
PDMGuru said…
Great comments Theo!
The roadmap suggestion is exactly one of the key points I make in the book I'm working on. It not only gives you a plan of which functions but also the dependencies you should in place so you are clear what you need as you move through the plan.
Unknown said…
This is a strong start. I like to talk about the two senses of "Product Lifecycle Management": The verb sense, and the noun sense. No matter what your company makes, you're already employing the verb sense. You're managing your product lifecycle. Maybe it's with Excel. Maybe it's on whiteboards or index cards. But you're doing it. So you start with the workflows. Then the noun sense: i.e., the technology solution. It's always best to know what problem you're trying to solve or process you're trying to automate before evaluating technology.

With respect to the SaaS/Cloud discussion, people tend to get confused by the difference between cloud, which is an architecture discussion, and SaaS, which is a discussion about rent vs. buy. There's a very good book out there called Consumption Economics which does a great job examining this.

Best of luck,

Craig Rode
PDMGuru said…
Craig
Thanks for the comments - I totally agree with the verb/noun contruct.
The Cloud/SaaS comment also is a good point regarding nomenclature. Really it's Saas versus in house versus hosting. And thanks for the reference I'll have to take a look at that!
Cheers

Paul

Popular posts from this blog

Is it worth changing PLM tools?

Phase two of PLM