Beaucoup de personne sont persuadée que le fait d’avoir un prototype qui commence à donner des résultats équivaut à avoir un produit fini à 80%…
Je vous le dis tout de suite : Il n’en est rien !
Les «Non Informaticiens/Vendeurs/Manager/Casse couille » [ Biffer la(les) mention(s) inutile(s) ] ont tendances à croire que le boulot est terminé par ce qu’ils ont entre leurs mains un prototype qui réponds aux besoins principaux et ce, de façon toute relative. (Oui, il y a encore quelques bugs,… Mais 90% du boulot est fait…)
Pour la plupart, ils ne comprennent pas (ou tendent à l’oublier) la démarche initiale d’un POC : Celui-ci vise à réduire les risques, à valider certains choix technologiques ou fonctionnelles plutôt que d’autre… Bon nombre de vendeur prenne cela pour argent comptant et en profite pour vendre votre « bidouillage cérébrale » comme étant LA nouvelle 7èm merveille du monde… (Oui, il y a encore quelques bugs,… Mais 95% du boulot est déjà fait…)
Quand on en vient à annoncer qu’il faut passer du temps pour transformer ce prototype en véritable produit, il ne réalise pas l’effort qu’il reste à fournir pour arriver à ce but. Cette phase est nécessaire pour réduire les risques liés à la phase d’industrialisation. En effet, produire quelques exemplaires d’un système embarqué, ou en produire des centaines de milliers d’exemplaires, ce n’est pas tout à fait la même chose : une série de nouveaux facteurs liées à la production de masse doivent entrer en ligne de compte. ( Oui,il a encore quelques bugs,… Mais 95% (1.500.000 pièces ) ont déjà été livré à travers le monde 8-/ )
Bien définir les spécifications et réaliser un mode d’emploi permet dans un premier temps de mettre en évidence certaines failles dans le produit : on peut, par exemple, le comparer à ce qui existe déjà sur le marché et prendre des dispositions si sur le papier il est déjà obsolète par rapport à la concurrence. Il ne faut pas oublier qu’a ce stade, ce produit doit encore être développé et produit, ce qui peut prendre plusieurs mois. On peut aussi confronter “la réalité techniques” à la demande initiale voulue par le client. Bon nombre de projet ont dû être arrêté avant la fin du développement pour cause de problème lié à des éléments techniques qui n’ont pas été pris en compte dès le départ.
L’exemple qui me vient en tête étant la création d’un système audio embarqué qui à nécessité le travaille d’une équipe d’une dizaine d’ingénieur durant 8 mois, qui a dû être arrêté pour un problème d’autonomie. Sur le papier, le système devrait permettre d’enregistrer de la voix durant 8 heures. Au final, le système réalisé tenait à peine 1 heure… (Oui, il a encore quelques bugs,… )
La phase d’industrialisation nécessite de prendre pas mal de précaution, et de prévoir tous les cas d’utilisation du produit final. Les outils de test intégré ou pas au firmware ne doivent pas être sous estimé, ainsi que les outils de configurations, les procédures de test,… En effet, programmer et configurer 10 unités ou protos, ne demande pas la même infrastructure que de gérer un flux de plusieurs centaines d’unité par jour. Des outils spécialisés doivent être développés afin d’automatiser cette phase. La gestion des retours, le support sont autant de point qui doivent être étudié avec soin. Et nécessite le cas échéant des ressources non négligeables (Rédaction de doc, Support téléphonique, Formation de personnelle (ouvrier/ingénieurs), Gestion de forum, Mise à jours correctif de firmware,… )
Quelques autres points intéressants à aborder lors d’un prochain articles :
Quid de la sécurité au niveau de nos cher petite machine ? As-t-on sécuriser l’accès à l’upgrade du firmware, les données exportées sont elles critiques ? Nécessite-t-elle d’être cryptée ?
Quid de l’abonnement pour des système nécessitant la connexion à un réseau GSM ? La bande passante est assez large/ bien la calculer avant…
Transition from Prototype to Industrial Product in IoT
Many people are convinced that having a prototype that starts yielding results is equivalent to having a finished product at 80%…
Let me tell you right away: That’s not the case!
“Non-IT Professionals/Salespeople/Managers/Pain in the neck” [Cross out irrelevant mention(s)] tend to believe that the job is done because they have a prototype in their hands that meets the main requirements, albeit to some extent. (Yes, there are still a few bugs,… But 90% of the work is done…)
For the most part, they don’t understand (or tend to forget) the initial purpose of a Proof of Concept (POC): It aims to reduce risks, validate certain technological or functional choices over others… Many salespeople take this at face value and seize the opportunity to sell your “brainchild hack” as the new 7th wonder of the world… (Yes, there are still a few bugs,… But 95% of the work is already done…)
When it comes to announcing that time is needed to transform this prototype into a real product, they fail to grasp the effort still required to achieve this goal. This phase is necessary to mitigate risks associated with the industrialization phase. Indeed, producing a few units of an embedded system versus producing hundreds of thousands of units is not quite the same: a series of new factors related to mass production must be taken into account. (Yes, there are still a few bugs,… But 95% (1,500,000 units) have already been delivered worldwide 8-/)
Clearly defining specifications and creating an instruction manual initially highlights some flaws in the product: for instance, it can be compared to what already exists in the market, and adjustments can be made if it’s already outdated on paper compared to the competition. It’s important to remember that at this stage, the product still needs to be developed and manufactured, which can take several months. The “technical reality” can also be compared to the initial client requirements. Many projects have had to be stopped before development was completed due to technical elements not considered from the outset.
An example that comes to mind is the development of an embedded audio system that required the work of a team of about ten engineers for 8 months, only to be halted due to battery life issues. On paper, the system was supposed to record voice for 8 hours. In the end, the implemented system barely lasted 1 hour… (Yes, there are still a few bugs,…)
The industrialization phase requires taking many precautions and anticipating all use cases of the final product. Integrated or standalone firmware testing tools should not be underestimated, nor should configuration tools, testing procedures, etc. After all, programming and configuring 10 units or prototypes doesn’t require the same infrastructure as managing a flow of several hundred units per day. Specialized tools need to be developed to automate this phase. Handling returns, providing support, and addressing these points with care are essential. It might require significant resources if necessary (Documentation writing, Telephone support, Personnel training [workers/engineers], Forum management, Firmware patch updates,…)
A few other interesting points to address in a future article:
What about security at the level of our dear little devices? Have we secured firmware upgrade access? Are the exported data critical? Do they need encryption?
What about subscriptions for systems requiring GSM network connectivity? Is the bandwidth sufficient? Calculate it carefully beforehand…