Products that can be customized change organically over time as new features and technologies come into play and as regulations and consumer demands shift. Managing these changes requires product models to be maintained over time. But what is the best way to manage these changes efficiently and effectively?
We’ll show how two important approaches, effectivity and versioning, enable modelers to control the evolution of configuration models over time. These concepts are helping businesses achieve higher-quality products, faster new product introduction, and more efficient product development processes.
Issues with Complex Configurable Products
The main components of a product model are a set of features (such as size and color) and the rules that make up the product model.
Let’s use a toaster as the product in question. Imagine you’re shopping online for a toaster. You find multiple options. You find a plastic toaster that’s green. You also find a metal toaster, but you cannot get it in green.
When it comes to more highly configurable products, the models are enormous. They have countless rules and features, and they evolve with time. Understandably, this makes them much harder to manage.
So, how can you effectively manage data of that nature?
Versioning for Traceability
The most straightforward method for dealing with change is the concept of a version. This method is commonplace and is currently used with parts in product lifecycle management (PLM) systems, documents, computer-aided design (CAD) drawings, and software.
So then, versioning’s fundamental idea is not new. Having a version allows you to manage how change occurs over time. You can essentially have traceability. It enables you to understand earlier iterations. You can revisit a product’s timeline to see who changed something and what it was.
It’s also a means of collaboration. It’s quite challenging to have numerous individuals working on the same data at once if you don’t have a concept of versions.
In essence, a version number is given and increased with each update of the information. Version numbers may take on several forms. Many PLM systems, for instance, separate the version identifier into a revision and an iteration, such as B.3, which stands for revision B, third iteration.
When numerous aspects of a product are related, and each one has a version, this method of versioning becomes difficult. For instance, if object A refers to and depends on object B, should the version of A be altered if B gets updated?
The method of versioning in software development, when an application is made up of thousands of files, has progressed from a basic local technique with a version identifier for each file to sophisticated distributed and graph-based approaches likeGit.
Manufacturers can manage changes to configuration parameters and rules by using versioning in a manner similar to how contemporary version control systems handle software. The “master branch” is the term for the sole source of truth for modeling data. The user creates a work item if they want to change any data in the master. Then, all modifications are made independently of the date in the master and any other work items.
This enables modelers to modify data and test the changes without being concerned about interfering with other people’s work or downstream systems that use data from the master. The changes are only incorporated into the master when the work item is promoted.
This method of versioning modeling data enables controlled concurrent updates to the model. The data in the master changes every time a work item is promoted. This versioning method has a global approach. With the version identifier for the data in the master, it is possible to identify the work items that produced the specified version.
Effectivity for Validity
Versioning is a crucial strategy for handling immediate changes. However, consider the possibility that a modification shouldn’t take effect immediately, but rather, sometime in the future. Perhaps you want to specify the new features for the model next year. Waiting a year before making the change is one option. Another is to define the model for the following year in a separate configuration model. Yet, when there are several future changes to track and they take place at various times, both strategies rapidly become impracticable.
Effectivity is what determines the validity of information, such as the features on a configuration model or the configuration rules. Although some organizations rely solely on effectivity to manage changes, versioning and effectivity actually work best together to manage changes over time.
Consider the law that all vehicles in Germany must have a reverse camera beginning on January 1, 2025. The configuration model initially includes a rule stating that the reverse camera must be chosen if the market is Germany. Then effectivity indicates that the rule is effective as of January 1, 2025, and beyond.
Now, what if the deadline is changed so that it is June 1 rather than January 1? The rule is updated by altering the effectivity to the new date, which results in a new version of the rule — even if its logic remains the same. Manufacturers should employ effectivity on all data objects, including configuration settings and rules to control when the object takes effect, to accommodate changes over time.
Managing Changes Over Time
Creating configuration models with parameters and rules is a complex task. Yet once that’s done, the real work starts after the initial model is complete because the capabilities of products change over time.
Manufacturers would do well to heed best practices and implement a versioning strategy that modern software developers use and combine it with effectiveness to have a unique set of capabilities at their disposal to manage changes to configuration models over time. This combination is helping companies produce higher-quality goods, launch new items more quickly, and use more efficient processes for product development by reusing models.
