We know we can sell more, at better margins, by guiding our customers to a solution through a configurator that minimizing engineer-to-order products. However, because configuration modeling is challenging and time-consuming, we have not considered all stakeholders' interests and have not fully realized the potential revenue and margin increases available to the business.

Module System Profitability Calculations

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. PALMA Product Portfolio Planning 1

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?

Configuration: A Powerful Tool in Product Planning

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.PALMA Product Portfolio Planning 2

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.


Simplifying the Creation and Management of Configuration Logic


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.

The Configuration of Highly Modular Products

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).PALMA Product Architecture Realization 1

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.



Bridging the Gap between a Product Architecture and a CPQ System

Even with good product architecture, it is not a trivial task to translate a customer's requirements into a specific technically viable and logistically available product that satisfies all the customer needs while generating minimal order-driven engineering and internal effort. This is because combinations can make the potential solution space prohibitively vast, even for relatively simple products, such as common types of industrial equipment.

Numerous CPQ system providers offer sales configurators specialized in finding good configurations in a given solution space. But these configurators need configuration rules, which are typically provided in manually created configurator-specific code containing a large number of logic statements. These then need to be continuously updated as the product offering evolves.

Maintaining these rule sets is usually challenging enough without capturing all the necessary technical parameters needed to produce a particular product. The result is that the output from the sales configurator, a sales specification or a quotation, needs to be manually translated into a physical product, with or without the support of a separate technical configurator, once the order is placed.

The key to merging the sales view with the technical view is to document and structure the product architecture and use powerful but easy-to-use tools to create a "modular" configuration logic. It means creating smaller but interconnected "chunks" of logic that can be maintained by sales, product managers, supply chain, or R&D, depending on what area expertise is needed.

Maintaining the product architecture and the configuration logic in one system and then executing the configuration logic in a sales configurator (CPQ system) makes it possible to bridge the gap between product architecture and the CPQ system.

Master a Configurable Offering with PALMA