My name is IJsbrand Schipperus. I am a PLM consultant at TechniaTranscat. Data management has always played a big role in my career. In the beginning I used data as an artist and as a designer. I later decided to learn more about data and it turns out that there is always another interesting topic to learn about. This is definitely the case for data.
I would like to introduce you to Configuration Management. I want to show you what it is, how it works and especially what it can do for you. The pitfalls of implementation will also be discussed.
Configuration Management is the management of the configurations. In this context, a configuration is a set of data that corresponds with a certain life phase of a product. An example makes it easier to understand the concept.
An often-used configuration is “As Required”. This configuration includes all documents and data that are necessary to describe a product, such as the Requirements Specification.
Another often-used configuration is “As Designed”. This configuration includes all documents that are necessary to specify the product as it was designed. This is where you will often find (3D) CAD data, electric and hydraulic diagrams and software.
The use of configurations gives rise to the need to manage these configurations. Someone has to be responsible for all configurations, since each employee is working with a single configuration. The person that manages all configurations is called the Product Owner. Every product or article has its own Product Owner.
We are constantly gathering and saving more data regarding our products. It has become standard to save 3D CAD data to get an overall image of the product and to simulate it. There is, furthermore, the working drawing that allows our product to be produced. The trend is to combine all product data, which requires a PDM/PLM system. Product data includes, for example, the software that is delivered with a product, such as multidisciplinary CAD data with electric or hydraulic drawings, but also requirements, manuals, folders and product renderings.
This creates PLM articles with embedded data. It is useful to have everything in the same place, but is it really necessary to review the entire Article when we add a new rendering? Do we have to check every document once more when we want to correct a spelling mistake in the manual and, therefore, review the Article, before the new version can be released? How do we check the modification without having to review the rest of the documentation?
When using configurations, product data is divided into logical sections. At most companies a specific department is responsible for a specific configuration. The Sales department, for example, is responsible for the “As Required” configuration and the Engineering department for the “As Designed” configuration. Every configuration has its own life cycle. A released configuration is called a Baseline.
The Baselines are used as a starting point when we want to produce an Article. A product is the last Baseline of a configuration and the approved Changes combined.
An approved change is immediately added, even when a different configuration of the Article is in use further along in the process. The configurations are independent of each other, making it possible to change each one independently. Changes can also influence multiple configurations.
Revision / version
We are going to digress and talk about Revision / Version. Based on the above, explaining the difference between a Revision and a Version is easy:
A Revision is a change in an Article / Product based on the same Requirements.
A Version is a change in the Article / Product based on new Requirements.
As stated above, one of the advantages is the use of a clear structure to store the product documents. Another advantage is that the department or group of people that is actually responsible for the documentation can be made responsible for the configuration.
There is, however, another advantage. Configurations each have their own life cycle, which means they can be adapted independently. All configurations van be reviewed or updated at the same time. This means that Manufacturing can produce the first version or revision of a product, while Engineering is working on the next revision and Marketing is adjusting the requirements for the next version of the product.
The fact that all departments can work on their own configuration at the same time, allows for a significantly shorter Time-To-Market. Modifications can also be implemented faster, allowing us to launch new versions of the product on the market sooner.
One last advantage is the management of delivered configurations. Having configurations such as “As Delivered” or even “As Serviced” you always know what has been delivered to the customer and even which parts have been replaced during service or maintenance work. This allows you to quickly find out which parts are in use and thus, where the part to be replaced is located if and when it is to be replaced based on a new revision.
Setting up new configurations requires additional care. When something is changed in a configuration because of which it no longer is the same as previously similar configurations, the changes have to be implemented in the other configurations as well. However, if a change does nog require additional changes elsewhere it should not lead to additional work. For example, if the requirements change and the designs no longer meet the requirements, the delivered product would not meet the requirements. Measures to avoid this should be taken.
This is why it is important that the Change Management is in order when starting to process documentation in a Configuration Management system. At some point in time during the implementation of the change the responsible party should check whether the change also influences other configurations. This is often only an option after the change has been implemented, because that is when you know what the change implies. For some changes it is clear from the start that the impact will reach further than the configuration itself or in other cases, the production of the preceding revision / version should be stopped immediately to prevent issues.
Change Management is an essential part of Configuration Management!
Configuration Management itself has pitfalls as well. The strengths of Configuration Management can, when wrongly implemented, create major problems causing the system to produce a negative instead of a positive effect on the process.
The configurations should fit in with the processes within the company. Finding a person or group of people who can be made responsible for a configuration is impossible if the configurations are not based on internal processes. When the defined configuration is too broad, too many people would have to work simultaneously on the configuration and too many would be responsible for this configuration. The strength of the system is that groups of people have their ‘own’ configuration.
The interrelation of the configurations and the structure of the system of configurations must be well-thought out. Who determines what? If the wrong data is managed in the wrong configuration the people who are responsible for this configuration are clearly not the right people for this task. It is important to assign data to every configuration at the start. If the structure is not clear enough, you will need to determine the business process and implement changes in said process if necessary.
Please contact us should you require more information!