A Product Platform is not designed as a single product or a few specimens. For Product Platform, the variability to be considered radically changes the landscape.
It is not only a matter of making a product that meets customer needs for optimum cost and quality, but also to design a product line that covers customer needs for optimum quality and overall cost.
Quality and manufacturability must be guaranteed for all configuration proposed. The investments are to be analyzed globally. It is necessary to foresee everything, but to foresee, is not to do neither everything nor right away. It is possible to:
- plan changes to the platform over time,
- detail the design when orders are requested it,
- identify for certain modules policies of Just In Time Engineering or controlled tailor-made.
The cost must be analyzed as a whole, regardless of whether the margin is low or high for certain configurations, provided that the expected margin is reached over the whole expected sales. For this analysis, several factors must be considered:
- external variability from the customer’s point of view,
- number of expected orders and their distribution in the set of combinations proposed,
- internal variability of the solutions implemented to cover the future combinations ordered.
These differences in design objectives lead to a review and adjust processes, design tools and organization, to cover all stages of the design of a Product Platform.
Acuity Solutions has successfully supported its customers in this process for many years by acting simultaneously on these 3 directions (processes, tools, organization) as outlined below.
Process for Product Platform development
Note: These steps should not be perceived as sequential to be executed once in a fixed but iterative order because it goes without saying that a platform must be scalable and that what is true today can change tomorrow. It is necessary to apply the principles of continuous improvement that sustain investments over the long term.
1/ Define the targeted functional scope
The design of Platform cannot be optimal without a good view of the variability of demand.
This requires an in-depth study of customers’ requirements, and their transformation into technical requirements without presaging technical solutions at first. These studies should lead to the vision of:
- the variability requested (proposed criteria, interdependence of choices in the form of implication or restriction)
- the expected sales volumes and probability of choices
- the roadmap for platform evolution
These elements are essential for an optimum development of the design solutions. For example, it is possible to estimate the volumes of parts that will be used by future orders and consequently to make informed choices in terms of tooling, purchase contracts or design strategy. In the latter case, having this information is a prerequisite for the decision to standardize or diversify: build a single oversized solution in some cases or more or less segment the solutions according to uses. (See our Post Design 4 Variability)
On this simple example we can see the difference between designing a Product Platform and designing a single product. In the case of a single product, the forecast purchase volume of a part is simply equal to the forecast sales volume multiplied by the unit quantity of the part in the finished product.
In the case of a Product Platform it is also a function of the probability of the case of use of the part. This probability is linked to the probability of the choices that will be made by the customer but must also consider the constraints between these choices.
This diversity framework must be accessible to all stakeholders in the same way as the other product requirements. It must clarify what is expected, or not, in terms of options currently proposed and planned addition to the offer. This is to avoid looking for solutions for unrequested cases or making decisions that neglect the long term.
2/ Building the architecture of the Product Platform
The purpose of the Product Architecture is to build the arrangement of the elementary components building up the product, and to define the interfaces between these components. In the context of a platform, this step is even more essential as it will more or less compartmentalize the impacts of the variability of the platform.
A poorly constructed architecture will lead to a non-standardization of solutions compared to the diversity of the platform as each option variation will impact the entire product. On the contrary, an architecture thought in diversity, will limit the domino effect of variability to the subset of entities really involved by the option.
The technical solutions of generic modules should, as far as possible, be transparently substituted for other modules. Of course, the reality is much more complex because we face physical and economic constraints where not everything can be interchangeable in all cases. Problems arise particularly in terms of layout in space: available volume, cable routing, electromagnetic compatibility, heat dispersion, assembly, repair, dismantling, … The architecture of the platform must take into account the variability as defined in step 1 to build the architecture of the modules, their layout, their interfaces. This architecture can, itself, be variable depending on the variability of the product by identifying major criteria that will move from one architecture to another.
This definition of architecture must also make it possible to define for each module its design strategy: Single, multiple, configurable or tailor-made solution (see our Post Design 4 Variability).
3/ Optimize the design as a whole
Once the scope of variability has been described and the main axes of the design have been defined, the design of the module solutions can be initiated. It must take into account all the company’s business lines in a holistic vision of the product. Information about the probability of each configuration must be taken into account in order to optimize the platform as a whole.
Acuity recommends for this step to adopt the “Cocoon Optimization” approach (Concurrent, Cooperative and On Going Optimization) (see our Post on this subject), it is in our opinion the way to take into account all the problems for a real global optimization.
Optimization as part of the platform may require complex research around variability:
- Search for the maximum consumption requested according to the options chosen
- Calculate the envelope volume of a module regardless of configurations
- Optimize the positioning of components according to combinatorics
The complexity of these problems is sometimes exponential depending on the number of variability criteria and the constraints that connect them. For this research it is often necessary to use specific tools using AI techniques (combinatorial research, constraint propagation, genetic algorithm … ).
4/ Validate the design of the platform
How to validate the design of the platform as a whole? How do we ensure that the configuration rules are complete and consistent?
Exhaustive validation:
The first idea would be to validate one by one each of the possible configurations. This strategy quickly runs up against the wall of combinatorics of the proposed choices. Indeed, imagine a platform with 20 configuration criteria having three possible choices each, the combinatorics is 3^20 or about 3 billion, by testing each these combinations at the rate of 100 per second, it will take you about 1 year to validate them all: be patient ….
Modular validation:
According to the principle dear to Descartes it would be enough to divide the validation into sub-problems to validate the whole. We can imagine a module-by-module validation that would validate the entire platform.
This method also has its limits, interface problems and overall behavior are neglected. However, the integration of components is often the heart of the problem, no matter how much Descartes likes it.
Validation by sampling:
Validation is done in the traditional way on a few complete products as would be done in the case of the development of a single product. This makes it possible to validate the product requirements in their entirety. The limit of this approach comes from the choice of samples tested. How are they chosen? Should we test them? Are they significant?
The choice of these samples must consider several factors: technical relevance (testing the most constrained cases), the probability of configuration (testing the most frequent cases), irregularities (testing suspected cases), testing novelties.
The identification of these cases can be:
- entrusted to technical experts, who, through their experience, will be able to identify these cases,
- randomly submitted for a part
- proposed by algorithms based on specific heuristics
Mixed validation:
In practice in the case of a platform, validation consists of minimising the risks and all these methods (semi- exhaustive, modular, sampling) must be combined to reduce the risk to an acceptable level by optimizing the tests.
5/ Opportunistic design, step by step
The design and validation steps of the entire platform can represent a cost and a delay incompatible with the sales volume and the expected time to market.
What is the point of studying all combinatorics when we only sell a few a year? Even if the design of the platform is modular, why study in detail each of the configurations of the modules?
When delivery times allow it, it can be interesting to make the detailed design of certain configurations only when a customer needs them. This approach makes it possible to limit initial investments, however it must be applied within a strict framework respecting the following rules:
- the architectural study must guarantee the feasibility of the design within an overall time compatible with the delivery time (study time + supply + manufacturing less than the customer delivery time)
- the detailed study triggered by the sales order must be done in the context of the platform and not only in the customer context. The requirements to be considered are the platform’s one and not only that of the configuration requested by the customer
- the finalized study must be integrated into the platform as a generic non-customer typed deliverable in order to be reused by a subsequent order.
6/ Predict the evolution of the platform
The platform should not be seen as a fixed object but that will evolve over time to integrate new options, remove constraints, improve its solutions, modify its architecture, integrate feedback and customer achievement.
All these small and large modifications must be planned over time and carried out in parallel. This planning and their impact must be visible and understandable to the design teams. This is fundamental information to manage priorities, design in a sustainable and scalable way, identify impacts and benefit in future developments from changes planned in previous stages.
Tools
As we have seen before, the central point of the design of a platform is the control of variability:
- Variability demanded by the market
- Variability generated by architecture and achieved via design solutions
PLM tools perfectly manage design deliverables (lifecycle, maturity, dependencies, classification, confidentiality, …) but are very limited in their ability to manage configuration rules and associated issues as presented above.
The precursors in this field have long been car manufacturers who developed their own in-house tools from the 70s. The advent of PDM and PLM solutions from the 90s onwards has most often led to mixed solutions combining a “homemade” tool for the configuration of variability, with a PLM tool on the market for the management of deliverables.
“In-house” tools cover well the historical needs of variability management but are often technologically outdated and struggle to cover new needs (eco-design, electronics, software, integration of suppliers in design in variability, co-development, …).
It is these limitations that led Acuity to create PLEiADE as a Product Line management tool capable of interacting with PLM deliverable management tools. The idea is not to simply “manage” this data but to make it available to all, make it intelligible, use it to give it meaning, make predictions, monitor progress, analyze its quality.
The challenge is to make complex information accessible by keeping its meaning so that it can be consulted and updated by businesses without an intermediary.
Organization
The management of the Plateform Produit requires an organization and a specific budget to build and make it live. It is important to separate the activities related to the Plateform Produit from those related to a project/sales order. It is indeed a way to keep a balance between:
- the overall objectives related to the platform that must be long-term with notions of long-term investment
- the short-term quality and time objectives related to a sales order
Without this two-headed organization, there is a risk that all the focus will be on the realization of customer orders one after the other without building a platform allowing, in the long term, to pool the design and anticipate changes.
On the project/sales order side, the studies carried out during a sales order, in an opportunistic design approach as described above, must be carried out under the platform in the “plural” context related to the diversity targeted by the platform and not only in the context of the current order. The case of use of the solution to be designed must encompass all the cases provided for. The platform team is responsible for validating the design within this broader framework.
On the other hand, studies specific to a sales order and not intended to integrate the platform remain within the scope of the project/order teams. The platform team will only analyze the causes of these discrepancies and possibly decide to evolve the platform accordingly.
Conclusion
As explained above, the design of a Product Platform requires the evolution of method, tools, and organization. This may seem complex to implement but two points must be considered: the importance of the stakes and the maturity of the solutions facilitating this implementation.
Outcomes
- Improving the Product Offer
A Product Platform makes it possible to expand the offer, to make tailor-made “Premium” for a cost close to the standard, to improve the added value of the customer, to have a global Product image.
- Operational Excellence
It also makes it possible to shorten the time to market of novelties throughout the offer, to decouple the design effort from the number of cases to be processed, to improve profitability and competitiveness through the effects of the standardization of modules.
- Globalization of the service
A less disparate offer makes it possible to optimize quality, support, repairability and reduce warranty costs.
Few initiatives make it possible to act on all these points at the same time. The stakes are therefore very high.
Solutions
The solutions to be implemented exist, however, it must be recognized that they are not yet widely disseminated among general practitioners, but at Acuity Solutions we have been practicing them successfully for many years. Acting simultaneously on the 3 directions: methodology, organization and tools, is essential.
As Jigoro Kano, the judo coach, said, “The longer the climb, the harder the climb, the greater the satisfaction will be and the more magnificent the view will be once at the top.”
I would add that the Acuiteam will be happy to guide you and assist you on this path.