It has been a few years since engineering.com has discussed product line engineering (PLE). To those unfamiliar with the topic, it’s an engineering workflow architecture that was first created in the 1990s as a method to streamline the lifecycle of whole product families.
Recently, this concept received a boost in the engineering world thanks to the release of ISO/IEC 26580, Software and systems engineering — methods and tools for the feature-based approach to software and systems product line engineering.
So, engineering.com sat down with Charles Krueger, CEO BigLever Software. He is also the editor of the new ISO/IEC standard that will help bring PLE to countless organizations around the world.
Krueger said, “most organizations use engineering techniques that are suitable for one variant of a product. You have a team of people. They're building a thing. They're trying to get that out the door. And yet, what the organization needs to do is focus on the family. So, product line engineering is all about how you deal with the issues of family.”
This article will delve deeper into how the PLE concept differs from building a single product variant at a time. For more on the PLE ISO/IEC standard itself, log in to engineering.com and stay tuned to the PLM section.
What is Product Line Engineering and What is its Value?
The best way to discuss the concept of PLE is by example. And the example that immediately comes to mind is the design, development, purchase and production of new cars.
From a consumer perspective, you don’t just pick a company, year and model and drive a car off the lot. You also choose between the base, mid-level and premium versions of the car. Each version will have its list of features that come standard. Then, there are a few features you can choose to add on top of the model version. For instance, say you don’t want the mid-level version, but you do want to splurge by adding heated seats to the base model? Then on top of all this, you got more choices from tinted windows to paint color.
To a consumer, these choices represent the car you expect to drive off the lot. To the company producing the car, it represents a Bill of Features (BOF), which is analogous to a Bill of Materials (BOM). And each potential BOF in the product line could represent a car variant that could require different:
- Constraints
- Designs
- Parts
- Functions
- Materials
- Documents
But, keep in mind, there will also be a lot of overlap between these variants. These overlaps represent areas where a company risks reworking a solved problem.
Meanwhile, each difference between the variants your company is unable to account for represents a BOF that is incompatible with your product family’s design, production and development. To your consumers, this represents a potential version of a car they can never drive off the lot.
“It turns out that the managing of the variation (building slightly different things one at a time), under conventional techniques consumes about 2/3 of the time and energy of an engineering organization,” said Krueger. “It's very expensive and a lot of overhead. The value comes from finding ways to eliminate that effort that adds nothing to the value of the product or the business. It's just, sort of, unpleasant engineering work that has to happen.”
What Does a Successful PLE System Look Like? The Assembly Factory Metaphor
To implement a PLE system, the whole company needs to break away from product-centric thinking. Instead, the company must focus on product family thinking.
“Typically, as we go into organizations, they're what we call product-centric,” said Krueger. “Their teams, delivery schedules, communication is organized around the individual products within the product family. They understand we've got a particular thing we need to get out the door, on a particular date, to serve an individual customer or an individual market. So, there's a team-oriented around that product.”
Krueger explained that the key to shifting a company’s focus to the product family is by utilizing a metaphor. Namely, PLE software can be seen as a digital assembly factory.
Assembly factories take all the parts of a product and consolidate them into the final product. The most advanced assembly factories can produce various versions of a product in a single factory setup. Back to the car example, imagine a single assembly that can produce the basic, mid-class and premium versions of a car’s make and model. The equipment just needs to be fed the right parts, paint and instructions to produce the correct car with the correct BOF.
A PLE software works much the same way. Instead of individual stations of the factories producing the correct part for the correct BOF, engineering teams will make the correct digital asset, say a CAD model, for a given design’s BOF. Then that engineering team will work on all the other CAD models for each variation of the product family. Meanwhile, other engineering teams will perform the same process for the different electrical setups for each given BOF.
Once someone at the factory pushes a button at the assembly plant to produce a version of the product, with a specific BOF, it grabs all the right pieces for that variation and puts them in the right spot. Similarly, when someone using PLE software calls up to see the digital data of a version of a product with a specific BOF, the PLE software will bring up all the digital assets that pertain to that variant and assemble them into one spot.
“So, there's this consolidation that happens,” clarified Krueger. “From a very siloed development for each product into a more shared asset view of the world, a lot more automation and the ability to scale up. You know the product production that comes out the end of the factories is going to be much higher due to the high degrees of automation.”
The Benefits of PLE
The most obvious benefit of PLE is that it eliminates rework. That engineering team working on CAD has worked on the models of all the BOF variants. As a result, they are better able to assess when they can reuse assets they have already produced. Why make a new dashboard CAD model for a variant if the part designed for a previous variant would work in this case? Just link that CAD model to be associated with both variants. However, if a different CAD team worked on each BOF variant, they will inevitably redesign the wheel—so to speak—due to the lack of communication.
By reducing this rework and better organizing how teams work on BOF variants, your organization has the time to design more variants that your consumers might want.
But the benefits do not end at the design phase. PLE also has benefits later in the product lifecycle.
“Say someone found a bug over here and then other people try to fix that,” explained Krueger. “Well, the context of that fix in the different products may be slightly different because of the variations. Then, they make mistakes.”
These mistakes can lead to recalls, loss of property and even human life. By organizing data by variation, these mistakes can be mitigated.
Now, say despite your best efforts, there is a recall.
Krueger said, “the business is asking: ‘Why did that happen? Why did you let that happen?’ Trying to communicate the complexity of all this manual duplication, merging and coordination work is very difficult without PLE.” With PLE you are better equipped to determine the cause of the error and all BOF variants affected by it.
On a happier note, maybe a customer has a great suggestion on how to improve a specific BOF variant.
“Before the customers would go to the place where they got their product. Now there's sort of a centralized, change control authority,” says Krueger.
Engineers can track these suggestions, find all the BOF variants affected by them. And determine how that effect might change based on each BOF variant.
Regardless of if there are suggestions or recalls, the PLE system can output the 20 BOF variants affected, where they were built, designed and purchased. Your team is then well-positioned to react in a timely, efficient and thoughtful manner.
So, How is PLE Different from PLM?
Now some might still be a little confused about the difference between PLM and PLE software. After all, they both claim to be a single source of truth. Additionally, Krueger explains that PLM tools have a way to deal with variation.
His reply to them is: “Say you have an electrical engineering system that does the same thing. If they're not related, the way that PLM does variation is unlikely to be the exact same way that's happening over on the electrical design system.”
This variation disconnect is compounded by any other tool used by the company that talks to the variation of product families. Solving this issue takes a lot of tedious, error-prone and hard-to-understand mapping exercises. And the more variation in your product family, the harder it is to properly describe and track each BOF in the system.
Krueger said, “what we do with product line engineering is we say there's going to be a single authoritative source of truth about the things that vary within the product family. And now, we're going to integrate that with a PLM tool so they can use that single source of truth. We'll also integrate that with an electrical engineering tool, and they'll use exactly the same ‘single source of truth’ that the PLM people are using. Now the engineering organization can communicate around a single common understanding about what variations they need to support within a product family.”
In other words, PLE is an interdisciplinary concept. In fact, when it’s optimally implemented, it will transcend the whole company- from sales to production and engineering.
Now that you have a good understanding of the basics and importance of PLE, you might be interested to find out more about the ISO/IEC standard. To do so, log in to engineering.com and stay tuned to the PLM section for our next part of this series.