The PLM Dilemma: Which Comes First, the Processes or the System?

Do processes lead system implementation, or do new systems lead process development? That’s the PLM dilemma, just like the classic chicken-and-egg paradox: “Which came first? The chicken or the egg?”

Here are a few examples to get a better understanding of this:

• If you don’t have your product development process documented, you won’t be able to implement it in your PLM system. And if your system doesn’t support your product development process, users won’t use the system to define their products digitally.
• If you don’t have an enterprise standard format for your bill of materials report, you won’t be able to implement it in your systems. If your PLM system doesn’t enable you to extract a company-compliant bill of materials report, users will be reluctant to use it to manage their BOMs.
• If you don’t have a common library of attributes for your product modules, you won’t be able to implement a classification system in your PLM systems without bothering someone. If your module attributes aren’t available in the system, users won’t be able to search, and integrations will be a mess.

In Product Lifecycle Management implementations, this is a common challenge. 

Should you first define your processes and then implement them in your system? Or should you start with some temporary definitions in the system to push the process definitions?

It’s easy to get too philosophical at this point.

The new PLM system is just the start.

Technology is just the tip of the iceberg. The new PLM system to manage your products is going to change a lot of things.

It’s going to change how people work. 

It’s going to change the way you define your products. 

And it’s going to change how people collaborate. 

The new PLM system is not just a fancy tool for managing data. If it’s implemented properly, the new PLM system will drive your business transformation.

PLM systems drive business transformation.

Introducing a new Product Lifecycle Management (PLM) system involves changing how your business is organized and operates.

Are your people ready to change the way they work? Do you have the skills required? Is your current development process capable of managing the digital definition of your products? 

The truth is that a new system will force you to define processes. 

It will force your teams to talk to each other. 

It will force you to define standards, decide if your bill of materials report is horizontal or vertical, or if drawing titles should be capitalized or not in your title blocks in CAD.

A PLM system will force you to expose your data and your way of working.

Navigating the “System-Needs-Processes” PLM Dilemma

Let’s be honest.

If your processes aren’t written down, you don’t have processes. 

If your service teams are retyping item data into your ERP system, you are duplicating product data and your enterprise collaboration engine is not working.

If you haven’t agreed on the format of your reports, you don’t have a company-wide standard.

A PLM system will only expose the problems you already have.

When they embark on a Product Lifecycle Management transformation, many companies need to take a step back to ask whether they’re doing the right things.

Some companies manage to navigate this “chicken-and-egg” dilemma by using the “system wave” to define and modernize their processes.

Others get stuck in the discussions and the definition, and the expected results fail to materialize.

5 Tips to Overcome the "System-Needs-Processes" (Chicken-and-Egg) Dilemma

#1 – Look for executive support.

You’ll soon encounter “definition challenges” when implementing your PLM system. 

You’ll probably need a budget, resources, and decision-making power to move things forward, so you should look for executive support early.

Prepare a concise, credible, and compelling presentation highlighting the challenges.

Executives are busy, so you need to get to the point quickly. You want to give them a clear and concise description of what’s happening and a proposal to move forward. 

This often means answering the following questions in a short, visual slide deck:

• What is the current situation? Service teams are recreating product data in the ERP systems. The product-to-service process is not defined, and service teams need to manually gather product data from drawings in AutoCAD.
• What is the cost of the current situation? 2 FTEs are continuously entering duplicated data into the ERP.
• What are you proposing? Define the data-service needs for the product and establish an official product-to-service process handover.
• What will it get us? We will improve data quality and save 2 FTEs and avoid human typing errors.
• What will it take? We need 4 workshops with the product; service teams to agree on the process and deliverables; a steering group to sign the new process; a consultant to help us moderate the discussions and implement the changes; and a pilot project to test the process. This will cost us $XX amount of money.

#2 – Define clear roles and responsibilities across units, regions, and product lines.

Being clear on who can “sign” decisions is gold.

Defining roles and responsibilities is very important to move change forward. If you do this soon enough, you’ll be able to define processes, standard documents, and deliverables on the go with a team of people who are entitled to decide and can sign off on changes.

Establishing strong governance and executive sponsorship at the onset of the initiative is key for success and smooth decision making.

To make it work, select only one responsible person for each process or standard. I’ve seen companies that have three product development process owners, two product compliance reporting heads, or two solution owners for document management. That doesn’t work. They will pass the ball and the decision won’t be made. 

If you want decisions to happen, choose only one name.

#3 – Start small and demonstrate success early.

As you implement your PLM system, you’ll find many processes and standards that need to be defined or updated. 

Before you take the giant leap and try to fix everything at once, prepare an Effort-Impact diagram to help you figure out where to start. 

The Effort-Impact diagram is a simple representation that helps you clarify your priorities. Draw a grid with four quadrants based on the overlap between effort and impact. Impact runs along the vertical y-axis. The higher up, the more impact. Effort runs along the bottom x-axis. The further to the right along this axis, the harder it is.

Choose a process or definition that’s low-effort, high-impact on your matrix. Something you can define easily and that will yield quick results.

Reports and standards are often easy to start with. By agreeing on a companywide format for your reports, you will enable interoperability between locations, show a cohesive company brand, and make the work easier for your enterprise systems. 

Defining the whole process at once is a huge uphill climb, and it just won’t work. Starting small and slowly getting traction is a great way to keep going and build the confidence to go bigger.

#4 – Have an official place to publish official processes and standards.

Publishing processes and standards to a signboard helps make things official. Some companies have an operating model handbook or a process library where processes and standards are stored and published. 

If you don’t have an official place to publish your processes, consider building a process library. It doesn’t need to be something fancy – a SharePoint site or a CMS will do the job and make your processes official.

#5 – Done is better than perfect — keep things going!

This last one is personal advice: if you want to move forward, you need to keep things going.  

I’ve seen many companies become paralyzed because they’re missing key definitions and don’t want to implement a “not-quite-perfect” concept in their PLM system. 

People get so worked up about what others may say that they can’t even start the work.

But done is better than perfect.

Sometimes, coming up with a definition with a small group of people and pushing it into the system will foster discussion and move things forward.

However, this is no excuse to quickly turn in sloppy work or keep things secretly handled by your IT department. You should still discuss with the relevant teams and get decisions signed off officially. 

In my experience, “done” gets results. 

You can always fix or improve definitions later on.

PLM weaves together processes and systems.

The tricky thing about PLM is just that it’s not just a stand-alone system to manage data. PLM is a common thread that weaves together many enterprise components.

A PLM system is a powerful business transformation tool to get your processes and definitions rolling. Use the system as an “excuse” to improve operational processes and to rethink how the business runs.

The original article was published at shareplm.com. Get the latest blog posts and news by joining our newsletter and following us on LinkedIn!