The most important task in product development is to create value for the customer and fulfill their needs. However, often not all customers want the same thing. This leads to multiple variants. But variants also have disadvantages. The complexity and development effort increase significantly. Product maintenance also becomes more complicated. Reason enough to address the topic of variants.
Why are there variants?
The application of a product can vary greatly. Especially in medical technology, there are different user groups and therefore different usage scenarios. What is a very important feature for one user group may be unimportant for another. In this case, it may make sense to configure the product specifically for the customer, for example, to be able to offer it more cost-effectively.
Another reason for variations can be legal requirements for different countries or markets. There is no uniform global standard for medical devices, so you have to deal with all the country-specific requirements.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
Variants can also arise when a product is technically developed further and, for example, new components are used.
Development approach
The first step is always to question the variant. If a variant can be avoided, that is the best solution! After all, variants increase development and testing effort, increase complexity, and usually also increase manufacturing costs. Therefore, you should be sure whether a variant is really necessary, or whether it can be omitted or implemented differently.
If omitting a variant isn't an option, then it's worth considering whether a variant can be limited to software. Software variants also require work, but are nowhere near as complex as variants involving hardware and mechanics. Where possible, the variants should be implemented using software variants or configurations.
The architecture must be designed in such a modular way that the basic architecture remains the same for all variants. Ideally, components are then only replaced, added, or simply omitted one-to-one to create variants.
Variants must be documented in the system architecture. Variants can be modeled using SysML. I highly recommend the book "Systems Engineering with SysML/UML" by Tim Weilkiens for this. However, if you have no experience with SysML, I advise against it as a first step. A simple way to get an overview of the variants using a mind map is shown in the figure below. I use the tool XMind for this.
From the base unit, variants are further broken down until all variants are visible. These are clearly named so that the variants can be distinguished. In the example, variant A3 is one of seven existing variants. After we have identified and named all variants, we can begin to document the distinguishing features of the variants from the base unit. The following template is recommended here:
- What is the purpose of this variant?
- How does the variant differ from the basic device?
- Does this variant have any implications for risk management?
It is important to ensure that the system architecture is suitable for all variants! If necessary, a chapter in the system architecture specification can be used to consider the variants. Variant-specific parts of the system can be highlighted graphically.
Requirements and tests for variants
Tools are necessary for managing requirements and tests. If you use variants, you can definitely forget about Word and Excel. This is because variants mean that the requirements and tests can differ for the various variants. For example, the battery life of a mobile device depends on what is installed. Variants can also contribute to different EMC behavior. The testing effort can increase considerably with the variants. However, it is neither necessary nor sensible to test everything with every variant. With a good requirements tool, you can assign variants as attributes to the requirements and tests. This makes it easy to derive the requirements and tests for each variant. As part of an impact analysis, you must evaluate which tests should be performed for which variants.
Dealing with variants can be very complex, and the approach must be tailored to your current situation and what benefits you. There are companies that already have a lot of experience with this, and others for whom it's still quite new.
I'm very happy to receive feedback and engage with you. Feel free to comment on the article. If you know someone who might also be interested in the blog, I'd also be very happy if you would recommend it.
Best regards
Goran Madzar