How can we make our Product Line Configurable?

In a modular system, the products offered to the market consist of a set of module variants. When planning for changes to, or during the development of, a modular system, understanding the future profitability and what impacts it is critical.

To work continuously with profitability projections, not just as discrete business cases whenever a change is proposed, profitability must be an integrated part of the module system.

In essence, it means managing sales forecasts for products, pricing of products, the cost of the module variants comprising those products, and the investments needed to introduce new module variants.

Two perspectives need to be connected. On one hand, we have product configurations with volume estimates and prices. On the other hand, module variants have costs, investment needs, and varying volumes resulting from the product sales and their mix.

This relationship is managed in the configuration table, which describes the module variants of each product configuration. These two connected perspectives are the foundation for a continuous, always up-to-date business case for the module system, or the Active Business Case™. How does PALMA support your Product Profitability Calculation?

Managing and planning a product architecture means handling multiple and connected release plans. Product release plans connect to module and module variant release plans that, in turn, connect to technology and feature roadmaps.
The interplay between the plans can be more easily managed if there is a configuration logic in place. Product configurations consist of module variants. That means that the planning of product releases is dependent on the development plans of module variants. The variants simply need to be available before a product can be released.

This can create conflicts between product release plans and module release plans. If there is a delay in developing a module variant, there is a subsequent delay in the product release. The link between plans and the visualization of conflicts is made through module variants and products in a configuration table. The table can be populated manually for simple small products, but for more complex products, the relationship between module variants and product configuration is maintained through a configuration logic.

That makes the configuration of products something that is not just relevant for selling products. It is also advantageous when making release plans for the product architecture.

Configuration logic is the rule set for how sub-assemblies or module variants are allowed and should be combined into sellable products.

For simple products, such as bicycles, the configuration can be done manually or with simple IF/AND/OR statements. But for more complex products, for example, a machine for producing paper, the number of rules is vast, and the rules are complex.

Creating a configuration model typically requires special skills closer to software developers than product managers. To make configuration an integrated part of the product architecture planning and governance, it must be simplified, intuitive, and easy to quality assure.

PALMA solves this problem by:

1.  Automatic generation of configuration logic derived from the specification of module variants and specification of commercial offerings.
   
2. Providing case and scenario tables that are easy to create and understand, which replace complex and numerous logic rules such as IF/AND/OR statements.
   
3. A strict division between structure and content. The product structure is managed independently from the assortment of module variants. This makes it easy to maintain and update the assortment of module variants without updating the configuration logic.
   
4. Providing an instant test environment for the configuration logic. PALMA has a built-in user interface for the configurator where the user can get instant feedback on the consequences of a changed rule.
   
   Read more about how PALMA can help with your Product Configuration Logic.

A modular product architecture is desirable for several reasons.

• • It can give a good economy of scale in production and sourcing while still enabling customized solutions to be offered.
  • It enables incremental development of the product range through continuous launches of module variants.

However, going from a product-centric company to a modular company will put strains on the business processes and tools. Without solid methods and tools for managing a configurable product range with millions of possible product configurations, the increased variability offered to the customer can become an enormous burden.

Companies that rely on 150% BOMs in traditional PLM systems will often see a practical limit to how much modularity and configurability such systems can support.

In conventional 150%, BOM's module variants are mapped directly to positions in the BOM, skipping the use of the module itself, which results in a complex proliferation of the BOM any time a new configuration is created for any purpose. A truly scalable approach to manage configurable products is by dynamic modular BOMs. Here modules are mapped to positions in a generic BOM. This method disconnects the" product structure" (the modular BOM) from the" content" (the module variants).

The result is a configuration logic and BOMs that are simpler and more efficient to manage and maintain even in a highly configurable module system with frequent phase-in & out of module variants.