We know we can sell more by guiding the customers to a configurable solution from our product line. However, because configuration modelling is hard and time consuming, we have not been able to consider all stakeholders interest and therefore, not fully realized the potential revenue and margin increase.
Module System Profitability Calculations
In a modular product architecture, the products offered to the market consist of a set of module variants. When planning for changes to, or during the development of, a product architecture, 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 on products, pricing of products, cost of module variants, investments needed for introducing module variant.
There are two perspectives that need to be connected. On one hand we have product configurations with volume estimates and price. On the other hand, there are module variants that have a cost and investment needs but also a volume which is the result of the sales volume of products.
This relationship is managed in the configuration table which describes the module variants each product configuration consists of. These two connected perspectives are the foundation for a continuous, always up-to-date business case for the module system, or 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 of multiple and connected release plans. Product release plans connect to module release plans that 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 the development of a module variant there is a subsequent delay in the product release. The link between the plans and the visualization of conflicts are made though the module variants and the products in a configuration table. This 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 configuration of products something that is not just relevant for selling products. It is also extremely useful 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 modules variants are allowed, and should be, combined into sellable products.
For simple products such as a bicycle, configuration can be done manually or with some simple IF/AND/OR statements. But fore more complex products, for example a machine for producing paper, the number of rules is vast, and 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 offers several solutions to this problem
- Automatic generation of configuration logic derived from the specification of module variants and specification of commercial offerings.
- IF/AND/OR statements are not needed, instead these rules are captured in case and scenario tables which are easy to create and understand.
- A strict division between structure and content. The product structure is managed independent from the assortment of module variants. This makes it easy to maintain and update the assortment of module variants without having to update the configuration logic.
- 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 consequences from 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 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 some 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 a big burden.
Companies that rely on 150% BOM’s in traditional PLM systems will often see that there is a practical limit to how much modularity and configurability such systems can support.
A truly scalable approach to manage configurable products is by a modular BOM’s. It is another type of configurable BOM’s. Here modules are mapped to positions in a generic BOM. This disconnects the ”product structure” (the modular BOM) from the ”content” (the module variants). Unlike 150% BOM’s where variants are mapped to positions in the BOM, i.e. skipping the use of the Module.
The result is a configuration logic and BOM that is 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
Selling complex system is not an easy task. Translating the customer requirements into a technically viable product that satisfy the customer and at the same time generate minimal order engineering and internal effort is easier said than done.
Many companies maintain a sales configurator separate from a technical configurator. The sales configurator produces a sales specification or quotation that needs to be manually translated into a physical product with or without the support of a technical configurator. Simply because the full configuration logic is too complex to model and maintain.
The key to merge 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 either 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 a product architecture and the CPQ system.