Industrialisation: product lifecycle management?

You have industrialised your product. You have reached the end of this phase and you have been able to see your product go to market. Congratulations!

But now, what happens to your product?

The idea is not to let it live without monitoring and observation.

What happens if a component becomes obsolete? What happens if you find that you are receiving more and more products in after-sales service?

These are all points to keep an eye on once production has stabilised and the product has been put on the market.

In this article, we explain what the different topics of serial life are and how to deal with them.

Let’s get started!

What is serial life?

Serial life is what happens once the production has stabilised.

It can be managed by the service provider who accompanies the project leader on the subject of industrialisation but it can also be managed by the project leader themself.

A reminder of the industrialisation process

Industrialisation is a decisive phase for the marketing of your product. It should be anticipated and integrated as early as possible. Why should you do this?

To allow you to anticipate the schedule of your product and integrate all the costs and investments necessary for the completion of your project.

Moreover, at Rtone, we apply industrialisation as a common thread. This means that it is broken down and that it occurs at each phase of product development.

> To explore this topic in more detail, you can read this article.

What is serial life?

Serial life is the process of ensuring that :

• The product corresponds to the expected quality described in the final production files;
• that it functions as intended;
• that its quality does not decrease over time;
• that partial obsolescence of the product (component, etc.) can be dealt with;
• that the end of life of the product has been managed or can be managed.

The serial life intervenes mainly on the mechanical, hardware and software parts of the product.

Here are the different aspects of serial life:

Monitoring production quality

Serial life begins with the establishment of indicators. In order to be able to identify and avoid certain… the indicators will enable alerts to be raised if necessary.

Managing non-conformities

Non-conformities can occur in two cases:

• In production, because of an approximate assembly, for instance
• Due to design errors

It is therefore necessary to be able to manage and correct these failures. In most cases, this means :

• Identifying the problem
• Correcting the problem
• This may result in a redesign of the board to fix the problem.

Improving production

Continuous improvement in production requires incorporating customer feedback.

This can be through setting up an after-sales service that needs to be trained and can train other members to join the team. In short, the more documented, the better!

Quality monitoring will also enable you to identify design or manufacturing problems.

Follow the evolution of production and manage equivalences and obsolescence

Throughout the production process, various changes may occur. It is necessary to be able to prepare for these changes:

• Managing material equivalence (breakage, extension of deadlines, etc.)
• Managing the obsolescence of a component, which can often mean having to replace it by redesigning the board
• Managing a change of supplier, for a scale-up (increase in production)
• Deciding to repatriate or relocate production (for volume or cost reasons)

Managing end-of-life and end-of-production

At some point, a decision will have to be made as to when to stop manufacturing the product.

We can advise the client on this strategy. There can be several options:

• Do we stock up to produce as long as possible?
• Do we plan the end of production (due to the obsolescence of components,…)?

The example of serial life management with Lunii

The Rtone teams accompanied Lunii on the electronic and software study of the serial life of their product Ma Fabrique à Histoires, i.e. they proposed the redesign and the associated software evolutions, according to the various optimisations to be carried out. Management and production of the serial life were operated by their French EMS BMS Circuits.

Rtone and Lunii worked on 3 axes of the serial life:

Improving the reliability of their product 

With a view to limiting the failure rate and increasing the reliability of the product, certain actions have been taken by the teams:

• Mechanical actions to make the product robust: for example, using stronger bolts and a jack connector, reinforcing the shell, etc.
• Electronic actions to rework the board to deal with problems such as power surges
• Changes were even made to make the product more reliable which went against the idea of optimising costs

From design to cost 

In order to reduce costs:

• Changes in references allowed optimisations to be made on the board,
• compromises had to be made,
• functional simplifications were applied.

Managing the current shortage of components 

To deal with the current shortage of components, solutions had to be found:

• 4 assembly variants were proposed according to the available stocks of components that Lunii had managed to supply and to manage the extended supply times.
• Optimisations of the audio amplifier, the battery charger and the tester could be made to cope with the shortage and to offer alternatives in production in the face of supply difficulties.

The Rtone teams managed the upstream phases up to the functional test bench, the end of the manufacturing of the boards.

BMS Circuits also managed the replacement of identical components in order to continue production in several cases.

My Story Factory by Lunii

Serial life also applies to the Cloud

The same principles also apply to the Cloud. We will talk about maintenance of the product or platform.

Whether the product is stabilised or continues to evolve, there is always a development team that knows the product and will follow up on bugs and updates.

And even if test cycles have been previously completed, there may still be :

• Browser-related obsolescence
• Security updates that need to be done, which are called edge effect
• Updates to existing libraries and code
• Functionality bugs
• Other bugs, which are of lower priority because they are considered minor or aesthetic rather than functional

As a general rule, a Cloud service is constantly evolving.

It is often the development team that works on the evolutions because they are the ones that know the product best and will be able to correct it quickly.

For software that does not evolve, however, there comes a time when bugs become increasingly rare and eventually disappear.

The importance of the test book

To respect a quality process in the various developments, it is essential to have a test book.

This is a procedure that describes all the functionalities and situations to be tested each time the software is put into production. Even the most basic ones. So as not to forget any of them:

• Connection tests
• Password reset

Because each addition of functionalities leads to recurrent bug loops.

How do you go into production?

First, there is a development phase, during which we look for bugs and correct them as we go along, in the following sprints.

Then there is an initial production phase. Non-expert users will start using the platform and often their work depends on it. Two things are essential:

• The quality of service;
• its availability. 

Then comes the natural cycle of evolution of the service.

The evolution cycle 

Different versions are used to follow a development process that integrates updates, bug fixes and new features while trying to limit risks.

The “dev” version is one that will evolve every day, with all the additions made by developers. This version is only tested by a small specific group: the project manager at the client’s, for example.

Then we build a staging version. This is a pre-production version, which is very similar to the production version. We will use real data as much as possible, with the same performance, under the same conditions.

Then it is finally the production version that is used. We are talking about a fixed version, a versioned version. We know which version of the source code is deployed.

There are 2 versions:

• A version reserved for patches and small bugs
• Another version under development which allows the addition of new features (planned or decided on the basis of user feedback)

Then the strategy for updating with or without service interruption will come into play. Two servers can be used in parallel to ensure a continuous 24/7 service and avoid any interruption of service, or decide on a connection time to restart the service.


3 tips to remember for maintenance

1. You cannot plan to stop maintaining your service, especially if you want to keep a certain level of quality.
2. Documentation is the key to maintenance. You have to keep in mind that the first development team is the one that will know the product best. If in the future, a switch or repatriation is envisaged, the documentation will be invaluable and a co-development phase with the future team will enable it to take over the maintenance of the service in the best conditions.
3. The test book is an essential part of the service quality process and will allow all possible scenarios to be reproduced and bugs to be avoided.

The subject of serial life allows you to accompany your product or service throughout its life. It is what will enable you to ensure the level of quality of your product that you have set yourself.

Integrating this subject as early as possible will enable you to anticipate and manage obsolescence, time extensions, problems in after-sales service, etc.

And to foresee its end of life. 

In short, whether it is a product or a service, you have the keys to continue to satisfy your customers and to apprehend the challenges that you will face.