Two cases are possible for creation:
• Customers asking for similar things resulting in an opportunity to create a product line;
• Marketing/Strategy conducts a business case identifying the implementation of a product line strategy. Market research can encompass several levels of products and services. It is also necessary to take into account the recurrence of requests and the scalability of the product (linked to legal, technological factors, etc.). The architect must have this input data to build his range of products over time.
Within the framework of an internal project (not the development of a product for a customer), it is a question of defining the typical architecture by using all the techniques of the architect plus the techniques of control of the variability.
Properly defining a range of products starts with clearly delimiting the perimeter of the market to which one seeks to address and collecting all the needs that it must cover as well as the level of maturity expected by this market. This must be done in collaboration between the people who represent the customers and those who carry the technique (including manufacturing, logistics, etc.). Mastering this scope is a key element of the success of a product range: there is a tendency to expand it out of opportunism or to reduce it out of a desire for local optimization. The way to approach this scope (at the right level of grain, in the right time frame, etc.) is also a success factor. The implementation of a range of products necessarily induces a change of paradigm to be taken into account.
Among the main pitfalls:
- No governance from the creation of the product range.
- Recurring trap vis-à-vis customer requests: create a product line solely on project opportunities without implementing a strategy based on market research (even very light or by collecting information from sales representatives/after-sales service tickets, etc.), related governance or off-cycle process requiring non-project investment.
- Temporal phasing: development not in line with the needs of the project.
- Failure to take into account the level of recurrence and scalability (product, market in the broad sense, etc.) in the strategy for setting up a line and a perimeter.
- Change management: the rationalization of costs by setting up a product line can create fears within the teams. Support for change can represent a significant cost for the implementation of a range of products.
Here are some good practices to consider:
- Give yourself a target vision of the product at 150% but develop it (depending on the opportunities) step by step in order to allow yourself freedom in the roadmap, which allows you to be more efficient for the adequacy with the customer need.
- Set up two feature models: a black box feature model that captures all the possibilities offered by the product line as seen by the customer and a white box feature model that connects the necessary components depending on the options chosen.
- Do not neglect the aspects of communication between projects and product lines (via governance). Projects should understand that a global optimum is sought at the enterprise level. The line of products must integrate the needs of the projects so as not to be above ground.
- The production tool must be associated with the reflections of the product line.
- Awareness of the strategic choices made around the product line.
- Encourage projects to reuse.
- Clearly define the boundaries of the product line, i.e. the type of systems it will not cover.
- Make the link between the documentary architecture (from the specification to the tests) on the architecture of the product line in order to promote the capitalization of projects and configuration management.
- On very complex products, do not hesitate to develop the line of products at the level of the subsystems (subject to having thought globally of the modular approach).
- Put in place an increase in the skills of employees on the principles of the product lines.
- Decouple the external interfaces from the basic functionalities in order to make them more easily integrable (and not having to re-design the basic functions as soon as the external interfaces change).
We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:
“ We have implemented a “bricks & modules” type strategy, that is to say that we have adopted a vision of target modular architecture by working on our existing diversity and we are developing the technological bricks of this architecture step by step.
“ We are starting to consider each element of our systems as a reusable lego brick and include them in a more global approach of “platforming” up to the highest layers of our systems.
“ We have synchronized a calculator product line approach with a software product line and thus the software/calculator interfaces are stabilized.
“ We have set up our line of products on the software in order to better control the ramp-up of developments.
Your comments will be considered by the members of the Cercle at the next monthly meeting.