• component (10)

    Blog de l'IoT Valley

    Articles populaires

    Tous nos articles:

    Comment SPIE a identifié + de 1 500h de temps d’interruptions en phase chantier grâce à une solution connectée

    Découvrez comment la société SPIE a pu identifier et quantifier des temps d'interruptions pour optimiser sa productivité grâce à Declique
    Christelle Marestang
    Directrice des partenariats
    Spie division Tertiaire

    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.

    La synthèse

    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é.

    Les résultats

    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.

     

    La Direction d'Activité Tertiaire et Logements Sud-Ouest

    SPIE Tertiaire

    La problématique

    DSC_2756Je 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.

    Mathieu, en homme de terrain, échange avec ses équipes, qui lui remontent des interruptions régulières dans leurs tâches quotidiennes, liées à des facteurs externes, un imprévu.... Chez SPIE, ces interruptions sont nommées les aléas.

    Et les aléas coûtent vraisemblablement cher à SPIE et créent un inconfort de travail pour les techniciens en poste. Mathieu a conscience du problème mais ne sait comment en faire une analyse fiable pour appliquer des correctifs.

    Il y a un sujet qui cristallise la frustration de Mathieu depuis quelques temps : les livraisons sur chantier. Elles sont nombreuses, fréquentes et mobilisent du temps des techniciens qui doivent réceptionner, valider chaque colis. Mathieu sait que cet aléas est bien réel et qu’il fait perdre du temps à ses équipes d’techniciens. Mais il n’a pas de données concrètes pour confirmer son ressenti. Et ainsi pouvoir quantifier l’impact réel de cet aléa. Frustration.


    Compréhension du problème

    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.

    L'atelier d'étonnement, la bascule

    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 :

    1. Préparer le terrain : l‘investigation
    2. L’atelier sur site
    3. Le cahier des charges de la solution

    1. Préparer le terrain : l’investigation auprès des acteurs métiers, pré-identification des irritants


    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.

    2. Atelier sur site : l'étape électrochoc pour les parties prenantes


    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.

    image4

    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 :

    • sur le fond : formuler le problème afin qu’il réponde précisément à l’irritant le plus bloquant
    • sur la forme : synthétiser le problème dans sa plus simple expression.

    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 :

    • Je ne sais pas mesurer leur fréquence #combien
    • Je ne sais pas mesurer l’indisponibilité du technicien #temps
    • Je ne sais pas lesquels sont les plus importants à résoudre #motif

    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.


    3. Le cahier des charges de la solution


    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 :

    1. Livraison : interruption pour cause de livraison
    2. Points bloquants TCE : blocages de tous les corps d'état sur un périmètre du chantier
    3. Manutention/logistique : interruption pour acheminer du matériel, aider un collègue sur un autre poste de travail
    4. Coactivité : présence d'une autre personne (autre corps de métier sur le chantier) sur le poste de travail, rendant impossible le travail du technicien
    5. Manque outillage/consommable : interruption du travail par manque d'outillage ou de consommables, interruptions parfois longues selon la nature du manque.

    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.


    Le projet pilote, la preuve de concept de la solution


    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.


    C'est quoi un test réussi ?

    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 :

    • La solution est-elle adoptée par les techniciens (ergonomie du terminal, robustesse, facilité d’utilisation) ?
      • Taux de satisfaction des techniciens (>= 70%)
      • Taux d’utilisation de la solution (>= 90%)

    • Les informations à disposition sur la plateforme me permettent-elles de répondre à l’objectif du pilote ?
      • OUI/NON
    • Est-ce que la méthode de mesurer le temps d’indisponibilité est satisfaisante ?
      • OUI/NON

     

    Réalisation du projet pilote avec 3 techniciens

    Le projet pilote s’organise donc dans les conditions suivantes :

    • Durée de pilote : 3 mois
    • Périmètre : 3 techniciens sur 3 chantiers différents

    Nous décidons de découper l'expérimentation en 2 temps :

    Temps 1 : réponse aux 2 sous-problèmes

    • Je ne sais pas mesurer leur fréquence #combien
    • Je ne sais pas lesquels sont les plus importants à résoudre #motif

    Temps 2 : réponse au dernier sous-problème sur les aléas (#motif) les plus fréquents

    • Je ne sais pas mesurer l’indisponibilité de l’technicien #temps

    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.

    Boitier connecté TRS

    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 :

    • Total de 212 appuis sur le boîtier
    • 2 aléas majoritairement rencontrées par les techniciens chantiers (185 appuis)

    image1

    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 :

    • 15 min
    • 30 min
    • 60 min

    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.


    Le ROI estimé ou comment transformer des interruptions en économie potentielle de coûts 

    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 :

    • les 185 appuis de 30 minutes en moyenne représentent 92,5h d’interruptions des techniciens sur les 3 chantiers
    • Sur le périmètre des chantiers de Mathieu (il en suit entre 6 et 9 par an), cela représente environ 2600 interruptions soit 1500h. 1500h c'est 1 d'un ETP (équivalent temps plein) d'un techniciens chantier.

    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.

     

    Declique, une création de startup dédiée aux enjeux de l'amélioration continue

    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.

    Ce n'est pas la fin de l'histoire

    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 !

    Un projet d'innovation en cours ?

    Découvrez notre accompagnement