Innovate at Scale with Enterprise Configuration

Product models deal with features, and once you have defined the features, you can then start breaking that into more technical aspects, such as Bill of Material (BOM) definitions. These aspects sit outside of the product model and typically live in a PLM system where they are managed and evolve, and where engineers work with the parts and the BOM’s. However, the variability of the product is defined in the product model.

When we talk about modeling, we are referring to the features of a product. On top of these features are a number of rules. Rules control the relationship between the features and define the variability that we would offer. Some features will be highly technical, others will be much more market oriented, but they all go inside the same product model.

From this perspective, you might say that the modeling is a fairly simple thing. You may think you could create these product models in Notepad. From that perspective, it doesn’t require a lot, and there are many tools on the market that can do this. But what happens the moment you go from having a single person defining these models to a much larger enterprise where you have to have collaboration between different parts of the organization, different engineering teams, and sales and marketing teams, and start to really roll this into a large organization?

Below we have identified five key capabilities that ensure your modeling environments are set-up to support the needs of a digitally focused enterprise:

1. Versioning of product models

How can we version and work with different versions of these models? If your configuration system cannot deal with different versions, you are already set-up for trouble.

The ability to version is a standard function that exists in many different forms. It can be done one way in PLM and ERP systems, which we call local versioning, where each data item goes through its own life cycle. In software there is another concept of versioning, called a global versioning, where you work with branches and a collection of data items that all have to be in alignment. These collections of data items in configuration management are called work items.

Global Versioning

The master branch represents the current, single source of truth. Whenever you have to modify the data in the master branch, you create a work item. You don’t version each individual rule, you version everything in the database as a separate entity in isolation from everyone else working on the data. Once you have completed the work, you test it thoroughly and promote it back in the master branch and the changes that have been done in the work item are carried over in the data that sits in the master. We believe this type of versioning is far superior to the traditional versioning model found in ERP and PLM Systems.

Working in this manner supports collaboration because you can have many teams working simultaneously on different work items. In this master branch sketch, work items (green, red and purple arrows) are being created from this version of the Master. As each one gets promoted, the Master is updated with the combined effect of the two. At any point in time, you can update what’s in the work item (illustrated by the arrows from Master to the red arrow). Data gets updated in the red and brought in but are still in isolation, so you can test that the changes in the red work item are still is okay even though the green and the purple are being promoted/brought in. And of course, what can happen is that you might have two work items that modify the same dataset, and in that case, there will be a conflict when you merge them together, and that conflict will have to be resolved with tools to support that.

An Example – Traceability

The ability to have strong versioning software allows you to trace very efficiently. In this example, a problem in manufacturing is discovered, which would be very late in the process to discover. In the car there is a sunroof, but no switch to operate it.

The first step is to identify the configuration and the version of the product model that lead to the invalid BOM (“version 42” in this example). Given this information, we can go back and inspect the full history of all changes that lead to the invalid configuration.

You will be able to see what work item was introduced in that particular version, and that information will allow you to trace all the way back to the work item with the information of who, what, why, and when the change was introduced. And could also contain linking all the way back to the change process in the PLM System.

Because you can open up this work item, you can look at the rules as they were at the point in time, you can analyze the problem, you can fix the problem, and you can bring the change forward to the current date to release it out if it’s still present in the current ruleset. This type of traceability is also essential if you want to service or upgrade a machine that was manufactured several years ago.

2. Effectivity Throughout the Product Lifecycle

Closely related to versioning is effectivity. This is a well-known concept in automotive, but less so in other manufacturing verticals.

When we talk about effectivity, we typically mean date effectivity. There are other types of effectivity, but date effectivity allows you to specify time intervals where features, options, rules, etc are valid.

This mechanism allows you to specify information that comes out in the future in the configuration system. This is a very efficient and effective way to work with the model data. It also allows you to support continuous evolutions of these models, because you don’t have to have this year’s model to create a copy of for next year’s model. You can have one model where changes are continuously being introduced over time.

Effectivity versus Versioning

Some may say that effectivity is also a way to do versioning. But these two concepts are actually orthogonal to each other, and it can be illustrated this way:

Version 1 is that in the United States, a reverse camera on a car is required, and that rule has effectivity so that it doesn’t apply until a certain point in time.

You can then modify Version 1, which will give you a new version, Version 2. Only change is the effectivity, basically pushing the time where this rule starts to take effect. Pushing that out in time gives you Version 2.

The rule could also be changed with unchanged effectivity, and that would create a third version. The point here is that versioning and effectivity are two separate concepts that go hand-in-hand. They are both essential to manage changes over time.

3. Engineering vs. Marketing Views

Engineering rules are technical rules that typically talk about the technical aspect of the product, and they are put in place to ensure the product will work correctly and be ‘legal’ in all regions it is sold.

On top of the technical rules is a separate set of marketing rules. These marketing rules deal with how the product is being positioned in different geographic regions, adding more commercial aspects and customer requirements and needs, linking them to the technical aspects of the product.

The way you analyze rules are different in these two domains. You want to be able to understand the consequences of a change, whether it’s going to affect only the marketing rules, or whether it’s also going to affect the engineering rules. There will also be different editors, as seen in the screenshot from our Ace application of how a commercial perspective looks. The rule editor is structured much more vigorously as a way for marketing to specify the offering in a particular market at a particular point of time including what features are standard, which ones are optional, etc.

4. Validation and Analysis Environment

Imagine that you have to test a change across 100 markets. There is no way you can test that manually by selecting the market to see if the configurator behaves correctly. You have to have tools that help modelers understand the consequence of a change by automatically running through a sequence of automated tests every time a change is made. This ensures that nothing has been broken by the change that was introduced.

Analysis based on the Solution Space

Conducting analyses of new features is critical to understand potential consequences. For example, this steering wheel has 96 variations of switches. With analysis, you can see that by adding another feature to this particular part of the vehicle, the number of variations could quickly grow to a much bigger number, and you might have to introduce another 40 or 80 parts just because of the one new feature introduced. The number of new parts required when introducing new features can be reduced by adding additional rules, for example, requiring the Lane Assist feature when selecting Adaptive Cruise Control. This shows the value of performing the type of analysis that goes hand-in-hand in the validation.

5. Fine-grained Security With Roles and Permissions

Last but not least, you need to make sure that the data that is being put into a configuration modeling system is secure. You need to know who is authorized to access and edit these models, particularly because they go downstream and effect websites and ordering portals. This also applies to approving and releasing changes to downstream systems.

Each of these require different roles and different permissions, and you have to be able to control all of this.

For more information, you can watch our webinar on this topic by clicking here.