Définition simple de l'Internet des Objets (IoT - Internet of Things)
Qu’est-ce qui distingue l’IoT à destination des entreprises des objets connectés visant le grand ...
.png?width=32&height=32&name=image%20(1).png "image (1)"){kind=small}
.png?width=140&height=187&name=component%20(10).png)
La division Tertiaire de SPIE Industrie &Tertiaire propose un haut niveau d’expertises dédiées à l'intelligence du bâtiment et à sa performance et intervient sur des chantiers de construction et de réhabilitation. Sur l’ensemble des chantiers, les techniciens sont interrompus au cours de leurs activités. Ces aléas freinent l’avancement de leurs actions et impactent leur productivité. SPIE ne sait comment quantifier ces aléas et mesurer leur réel impact.
Les faits : Les techniciens présents sur les chantiers sont sans cesse interrompus par des aléas dans leurs activités. Ces aléas sont dûs à des sollicitations externes qui les obligent à quitter leur poste de travail.
La donnée : Des remontées récurrentes des techniciens sur des facteurs externes qui les obligent à quitter leur poste de travail (livraison de colis, manutention) ou des points de blocage (co-activité, manque d'outillage)
Le problème : SPIE ne sait pas quantifier ces aléas et leurs conséquences sur la productivité des techniciens
L’analyse du problème : 5 aléas sont remontés par les techniciens comme causes majeures d’interruptions.
La solution : Une plateforme SaaS qui permet d'analyser le nombre d'interruptions remontées du terrain grâce à boîtier connecté.
2600 interruptions soit 1500h sur un périmètre de 6 à 9 chantiers sur une base annuelle. Cela représente 1 ETP (équivalent temps plein) d'un technicien chantier.
Je sais que les techniciens sont régulièrement interrompus dans leur activité mais je ne connais pas l'impact de ces aléas sur leur productivité - Mathieu - Chef de service chez SPIE
Sur chaque chantier qu'il supervise, Mathieu a pour objectif de mettre en place une démarche d’amélioration continue de l'organisation, afin de livrer l'ouvrage selon les termes du contrat, notamment dans le respect des délais. L'efficacité opérationnelle des techniciens sur chantier est donc une priorité pour Mathieu, dans une démarche qui vise à développer le confort et les conditions de travail des techniciens.
Mathieu a conscience d'un problème récurrent : ses coûts réels de main d'oeuvre sont quasi systématiquement supérieurs à ceux estimés. Quelque soit la complexité du chantier, quelques soient les techniciens, les prévisions de main d'oeuvre (basées sur une grille de temps d'intervention) sont toutes minorées par rapport à la réalité du chantier. Ce problème, il le partage avec d'autres chargés d'affaires (et avec l’ensemble de la profession) , eux-mêmes confrontés à cela sur leurs chantiers respectifs.
SPIE noue un partenariat avec l’IoT Valley pour, entre autres, trouver des solutions afin d’améliorer l’efficacité opérationnelle des équipes sur les chantiers. Laurent, le Directeur d’Activités, décide d’engager une démarche d’innovation collective pour développer la performance des activités de la division.
La meilleure façon de comprendre un problème métier, c'est d'aller voir sur le terrain comment il se matérialise.
Avec l'équipe des chefs de projets en innovation de l'IoT Valley, nous organisons donc un Atelier d'étonnement pour identifier et comprendre les irritants principaux dégradant l'efficacité opérationnelle sur les chantiers.
Cet Atelier d'Étonnement se structure en 3 phases :
Pendant 6 semaines, Jonas, chef de projet innovation à l'IoT Valley, va rencontrer des techniciens sur le terrain, interviewer des responsables d'affaires, observer des flux et activités sur plusieurs chantiers pour comprendre le métier, les contextes de travail ainsi que les problématiques vécues par les techniciens.
Jonas nous présente une synthèse de ses recherches, avec plusieurs axes sur des irritants à préciser.
L’Atelier sur site est divisé en 2 temps forts. La matinée consiste à une visite sur un chantier de SPIE et à la présentation des problématiques par les métiers sur le terrain. L'après-midi s’articule autour de la co-construction de solutions idéales à ces problématiques en groupes de travail mixtes (startups, IoT Valley, SPIE) dans les locaux de l’IoT Valley.
Le matin : immersion en situation de travail
Sont présents les techniciens et chargés d'affaires de SPIE, dont Mathieu bien évidemment, ainsi que nos chefs de projets et des entrepreneurs de l'IoT Valley développant des solutions pour le SmartBuilding.
Casques de chantier vissés sur la tête, nous sommes prêts à débuter la visite d'un chantier de construction d'un nouveau bâtiment pour une école d'ingénieurs. Durant le briefing, Jonas explique la règle fondamentale de la matinée :
"Nous ne parlons que de problèmes ce matin. Celui ou celle qui utilise le mot "solution" devra faire 20 pompes !"
Éclat de rire général. 20 pompes par cette matinée fraîche du mois de janvier, cela calme les ardeurs 🙂 La visite est commentée par David, le chargé d'affaires responsable du chantier pour le compte de SPIE. Dans chaque pièce, il nous commente les missions et travaux réalisés par ces équipes. Le technicien en charge du travail se signale. Et immanquablement, nous lui posons toujours la même question :
"Raconte nous ta pire journée. Quand tout va mal."
Chacun saisit l'occasion de comprendre "in vivo" le quotidien du technicien, ses points de blocage, les aléas qu'il rencontre. A la fin de la visite, carnets et cahiers noircis de notes, smartphones remplis de photos, nous nous dirigeons vers un algéco transformé en bureau pour les responsables du chantier.
David, à ce moment là , est interrompu par un collègue technicien, qui doit réceptionner une commande mais ne sait pas où se trouve le poste de livraison. Illustration flagrante d'un aléas du chantier. Fin de la visite.
Après-midi : co-construction de solutions
Retour à l'IoT Valley avec l'ensemble de l'équipe SPIE/IoT Valley pour travailler toute l'après-midi sur l'identification précise des irritants affectant l'efficacité opérationnelle sur le chantier.
Post-it Wall
Dans une 1ère phase, chacun fouille dans ses notes pour remonter les problèmes et aléas qu'il a vu, entendu, constaté le matin même, et les note sur un post-it qu'il vient accoler sur le mur.
Le sujet de chaque post-it est discuté puis regroupé avec d'autres pour former des familles.
Les problématiques clés ont été priorisées. Mais le travail commence à peine :
Le plus gros du travail quand on a trouvé un problème, c'est de le formuler.
OUI, la définition précise du problème n'est guère aisée. Nous devons répondre à 2 objectifs :
Puis découper en 3 sous problèmes. Avec cette méthodologie, nous entrons de plain pied dans le métier, dans les subtilités du quotidien.
Le problème validé
Après des échanges riches, nous avons une définition claire du problème rencontré par les techniciens de chantier chez SPIE, formulée tel quel :
"Je ne connais pas l’impact des aléas sur la productivité des techniciens"
De ce problème, 3 sous-problèmes, qui sont également des questionnements en découlent :
Un technicien subit des aléas au quotidien sur le chantier. Nous allons maintenant creuser les 3 sous-problèmes pour définir le périmètre de l'étude (et du projet pilote) que nous allons mettre en oeuvre.
Suite à cette riche après-midi, nous synthétisons le périmètre du problème. Jonas peut donc débuter l’écriture du cahier des charges.
Pour ce faire, nous détaillons les fonctionnalités d’une solution simple : un boitier connecté avec des boutons remontant des aléas relié à une plateforme SaaS. Cette plateforme enregistre le type d'aléas (#motif), la fréquence (#combien) et l'indisponibilité du technicien (#temps) et délivre des statistiques en temps réel disponibles sur un tableau de bord.
Puis, nous devons préciser avec exactitude les aléas. Donc Jonas repart sur le terrain aux côtés des techniciens, préciser leur quotidien, leurs galères, et valider les aléas qu'ils rencontrent.
Et là, Jonas a pu véritablement définir avec les techniciens 5 aléas concentrant la majorité des interruptions :
Le nom de ces 5 aléas ont été définis par les techniciens eux mêmes, acteurs en 1ère ligne de ces aléas. Ce sont leurs problèmes, ce sont eux qui vont signaler les aléas, ils doivent être totalement à l'aise avec l'usage des boutons sur le boîtier.
Maintenant que le périmètre de la solution est bien défini, nous pouvons passer à la phase de projet pilote. Habituellement, nous menons une phase de recherche de startups IoT qui développent une solution pouvant répondre au besoin exprimé par le projet pilote.
Hasard (ou non) sur ce projet, nous travaillons déjà sur un projet similaire avec une société de l'industrie aéronautique depuis quelques semaines. Et nous avons déjà réalisé la recherche de startups, qui s'est révélée infructueuse. Donc nous ne devons pas tarder pour monter le projet pilote. 2 sociétés ayant un problème non couvert par une startup existante : ce sont les signaux qui nous poussent à avancer. Dans ce cas là, nous privilégions donc la création d’un MVP (Minimum Viable Product) pour répondre rapidement à la phase pilote.
Jonas constitue une équipe dédiée au projet. Nos développeurs et designers intègrent le projet pour mettre à profit leurs compétences sur le développement du MVP de la plateforme.
Arnaud, responsable des projets d’industrialisation à l’IoT Valley, présent lors de l'Atelier, met à profit son expertise industrielle pour prendre en charge la production du boitier.
Il est vrai que le projet précédent avec la société aéronautique fait figure d'accélérateur pour ce projet. En à peine 2 mois, nous sommes prêts à passer en phase de test.
Là encore, nous définissons avec méthode le cadre de l'expérimentation avec des attendus permettant de valider/invalider la réussite du projet pilote. Sans entrer dans trop de détails, le projet pilote doit répondre à un certain nombre d’exigences dont :
Le projet pilote s’organise donc dans les conditions suivantes :
Nous décidons de découper l'expérimentation en 2 temps :
Temps 1 : réponse aux 2 sous-problèmes
Temps 2 : réponse au dernier sous-problème sur les aléas (#motif) les plus fréquents
Temps 1 : #combien #motif
C'est l'heure de vérité. Après des tests techniques concluants, les boîtiers sont livrés aux 3 techniciens sur les 3 chantiers sélectionnés pour le projet pilote. L'ergonomie et la simplicité d'usage du boitier ne requiert aucune formation, nous briefons seulement les 3 techniciens sur les situations que nous avons identifiées avec leur support.
L'attente peut paraître longue quand nous sommes en phase de test. Nous trépignons d'impatience à l'idée de recueillir et d'analyser les résultats. 2 mois s'écoulent. Nous pouvons dès à présent compiler les données brutes :
Le graphique ci-dessus est éloquent. Les livraisons et opérations de manutention/logistique concentrent près de 90% des cas d'aléas.
Le projet pilote est concluant. Il a mis en lumière la fréquence, le motif pour chaque aléas :-)
Temps 2 : #temps
Pour mesurer le temps d'indisponibilité, nous lançons, forts de ces résultats en enseignements, une deuxième expérimentation. L'expérimentation se concentre, cette fois ci, sur la mesure du temps d'indisponibilité des 2 aléas les plus fréquents : les livraisons et la manutention/logistique.
L'expérimentation prend forme par la mise à disposition des 3 mêmes techniciens chantiers de tablettes sur une durée de 2 mois pour déclarer a posteriori le temps d'interruption lié à chacun des 2 aléas avec 3 valeurs de temps :
L'adoption de la tablette est plus compliquée pour les 3 techniciens notamment par la déclaration a posteriori qui doit être systématiquement réalisée. Les données remontées sur 2 chantiers sont parcellaires, tandis que les données sur le 3ème chantier sont plus exploitables.
Il est convenu, avec SPIE, après analyse des données, de valider un temps d'indisponibilité moyen de 30 minutes concernant ces 2 types d'aléas.
L'expérimentation est terminée, riche d'enseignements et de données permettant d'estimer un ROI potentiel lié à la baisse de fréquence de ces aléas.
A partir des données brutes, Mathieu et Laurent ont maintenant la capacité d'extrapoler l'expérimentation sur la réalité de leurs chantiers :
L'expérimentation est concluante, nous avons répondu à la problématique "Je ne connais pas l’impact des aléas sur la productivité des techniciens".
Avec les équipes de SPIE, ces données factuelles vont nous permettre de chercher des solutions pour augmenter l'efficacité opérationnelle sur les chantiers et de définir les axes prioritaires.
Notre métier, c'est de faire le pont entre nos partenaires ETI et les startups de l'IoT. Et comme je l'ai évoqué plus haut, la meilleure option pour SPIE était clairement de développer la solution à l'IoT Valley. Ce projet pilote réussi avec SPIE conforte la pertinence de résoudre cette problématique, déjà observée chez un de nos partenaires industriels, et valide le MVP développé par l'IoT Valley en tant que solution appropriée. Arnaud, notre responsable industrialisation, ayant suivi et accompagné le projet avec Jonas, décide alors de quitter ses fonctions pour créer une startup qui identifie les problèmes d'efficacité opérationnelle dans les contextes de production : Declique est né.
Accéléré au Connected Camp, l'accélérateur de startups de l'IoT Valley, Declique adresse les sociétés souhaitant s'engager dans l'amélioration continue en proposant une solution IoT hardware + un plateforme SaaS pour mesurer les problèmes identifiés dans les phases de production en atelier, chantiers....
Arnaud a déménagé dans le bureau d'à côté, est devenu CEO de Declique et travaille déjà avec plusieurs clients pour développer leur amélioration continue.
Une expérimentation réussie est un pré-requis pour passer à une phase de déploiement. Avec SPIE et Declique, nous allons donc déployer un nouveau service afin de réduire l'irritant des livraisons. Une solution de boite à lettre connectée, nommée Boks, sourcée sur le marché par l'équipe IoT Valley, va être implémentée très prochainement sur un chantier.
Cette solution a pour objectif de permettre à un livreur de déposer des colis pour un chantier dans un environnement sécurisé. Les techniciens pourront, quant à eux, réceptionner les colis entre 2 travaux ou en fin de journée. Leur productivité au travail s'en verra fortement améliorée.
Fidèle à notre méthodologie basée sur la mesure des expérimentations, nous redéploierons Déclique auprès des techniciens chantiers associé à la solution Boks. Nous pourrons ainsi mesurer les écarts avec la situation initiale et valider avec SPIE un ROI réel. Vivement la suite, ce projet est une puissante source d’amélioration opérationnelle !
