Pouvez-vous me dire si vous travaillez actuellement en mode build ou en mode run?
SI ce n'est pas évident pour vous, restez ici, je vais vous expliquer les principales différences entre le mode build d'un côté et le mode run de l'autre.
Quelle est la différence entre le mode build et le mode run?
Le mode build est un ensemble d'activités et de tâches réalisées par une équipe réunie pour l'occasion afin de construire un produit ou un service.
Le mode build dispose souvent d'un caractère d'innovation, cherche à résoudre un problème ou exploiter une opportunité. Le mode build est unique et temporaire, avec une date de début et de fin précise.
Le mode run, quant à lui, est une activité récurrente qui est axée sur l'efficacité, la performance et l'optimisation des processus de l'organisation. Les opérations sont ainsi exécutées de manière régulière pour répondre aux besoins courants de l'entreprise.
Voici un tableau récapitulatif des principales différences entre le mode build et le mode run :
Thèmes | Mode Build | Mode Run |
|---|---|---|
Description | Ensemble de tâches à réaliser pour atteindre un objectif défini, dans les délais et le budget imparti. | Activités récurrentes maîtrisées et répétées, assurant la stabilité financière de l'entreprise. |
Objectif | Créer de nouvelles opportunités, de nouveaux produits, services, marchés ou manières de travailler. | Assurer la pérennité de l'entreprise, et répondre aux besoins de ses clients. |
Environnement | Inconnu, innovant, complexe et incertain par nature. | Répétitif, stable et maîtrisé. |
Processus de décision | Décisions rapides sur la base d'informations non complètes. Processus historique et décisions irréversibles. | Décisions réfléchies basées sur les faits. Processus récurrent et décisions réversibles. |
Degré d'incertitude | Élevé. Il peut exister de nombreux flous sur un projet. | Faible. Les actions sont encadrées pour les opérations. |
Caractère d'innovation | Oui. Les projets ouvrent des opportunités pour l'entreprise. | Non. Le fonctionnement est encadré par des procédures, et l'efficacité est de mise. |
Cash-flow | Nécessite un investissement financier, en espérant avoir un retour sur investissement positif une fois le projet terminé. | Dégage des bénéfices directs pour l'entreprise. Cash-flow positif. |
Difficulté | Complexe. Nécessite de faire un saut dans l'inconnu. | Simple à Modérée. Nécessité d'intervenir rapidement en cas de blocage. |
Respect des processus de l'entreprise | Pas nécessairement. Ils peuvent être contournés s'ils sont nuisibles pour le projet. | Oui, les processus sont respectés et optimisés quand c'est possible. |
Constitution de l'équipe | Équipe pluri-disciplinaire, constituée en fonction des compétences et des profils nécessaires au projet. | Équipe hiérarchique, apparaissant dans l'organigramme de l'entreprise. |
Organisation | Organisation temporaire, montée le temps du projet. | Organisation pérenne dans le temps, collant au fonctionnement de l'entreprise. |
Type de management | Management transversal. | Management hiérarchique classique. |
Comme vous pouvez le voir, ces deux activités se recoupent mais sont bien différentes.
Voyons maintenant ensemble ces différences plus en détails.
Matrice de transition des activités du Build vers le Run. Vu sur Forbes
1 ) Des objectifs différents
Le mode run correspond à la majorité des activités de l'entreprise et est permanent, se répète dans le temps, et produit des livrables répétitifs. Les opérations sont ainsi axées sur l'efficacité et l'optimisation des processus de l'organisation pour satisfaire les clients tout en réduisant les coûts.
En revanche, le mode build est unique, temporaire, et répond à un besoin ou une problématique précise de l'entreprise. On parle également parfois de mode projet. Les projets ont un caractère d'innovation et peuvent créer de nouvelles opportunités pour garder un avantage compétitif face à la concurrence.
2 ) Des équipes et compétences différentes
Les équipes internes de l'entreprise mènent les opérations en mode Run sous la conduite du manager opérationnel, tandis que les équipes temporaires et inter-disciplinaires mènent les projets en mode Build sous la conduite d'un chef de projet.
Les équipes projet peuvent disposer de leurs propres règles et agir en marge des processus de l'organisation, contrairement aux équipes de Run qui définissent, respectent et font évoluer les processus.
Les équipes build doivent également prendre des décisions rapides, sans forcément avoir toutes les informations à disposition à un instant t.
3 ) Une approche et une organisation à l'opposé
Le mode run suit le schéma classique et traditionnel de l'entreprise, en management hiérarchique, alors que les projets ont une approche et une organisation à l'opposé de la structure de l'entreprise.
Les budgets et les événements sont généralement planifiés de manière annuelle pour les opérations, contrairement aux projets qui ont des budgets définis et réfléchis au lancement.
Quels sont les enjeux de la transition Build vers Run ?
Les enjeux principaux de la transition Build vers Run s'expriment en terme d'image, de qualité de service, de satisfaction client et en terme financier.
Par exemple, l"un des derniers projets que j'ai mené consistait à migrer le système d'information (les serveurs informatiques) d'un client dans un datacenter.
Une fois l'ensemble des équipements migrés et leur bon fonctionnement validé par le client, le projet touchait à sa fin.
Il me restait alors à m'assurer que mon équipe projet transmette les bonnes informations aux équipes en charge de la gestion et la maintenance de ces équipements pour les 48 prochains mois, tels qu'indiqué sur le contrat.
L'enjeu était donc de s'assurer que la qualité de service n'allait pas dégringoler dans le temps, et que les équipes soient en capacité de gérer les problématiques et les évolutions de cette infrastructure.
Si les équipes Run n'avaient pas été au rendez-vous, le client aurait pu appliquer des pénalités financières pour non-respect des engagements, voire même casser le contrat dans le cas le plus extrême.
Comment assurer la transition entre le Build et le Run ?
Pour réussir la transition entre la phase de Build et la phase de Run, il est nécessaire de respecter plusieurs éléments que voici :
- Impliquer les équipes run dès le démarrage du projet.
Plutôt que de tout leur déballer à la fin du projet et les laisser se débrouiller avec, procédez de manière plus intelligente. Invitez les équipes de Run à s'impliquer et à participer au projet dès son lancement, et traitez-les comme des parties prenantes de votre projet. - Documenter tous les aspects du projet côté Build.
Toutes les opérations qui devront être assurées en pahse d'exploitation de la solution doivent être identifiées et proprement documentées par l'équipe Build en mode projet. Idéalement, assurez-vous que cette documentation correspond aux attentes et exigences de qualité de l'équipe Run. - Normaliser et standardiser le plus possible les opérations.
Si la même opération est spécifique à chaque client et qu'elle s'effectue de 50 manières différentes, ce n'est pas maintenable et il y aura tôt ou tard des erreurs. Pour éviter cela, le maintien en condition opérationnelle doit être pensé lors du design projet. - Planifier une réunion de passation officielle.
Votre projet arrive sur la fin ? C'est maintenant le moment de procéder au passage du témoin relais officiel à l'équipe Run, qui va assurer la gestion et le maintien en condition opérationnelle lors de la phase d'exploitation de la solution. - Faire valider un procès-verbal de passation.
En tant que chef de projet, demandez aux équipes Run de valider et signer un procès-verbal de passation Build vers Run. S'ils ont des réserves, celles-ci doivent absolument apparaître pour que l'équipe Build corrige le tir. A partir du moment où ce PV est validé, le projet est officiellement clos. - Maintenir les équipes build en support du run pendant la phase de transition.
Je vous recommande toutefois de mettre en place des périodes probatoires, où les membres de l'équipe Build reste en support des équipes de Run afin de les aider à régler les problématiques ou répondre à leurs questions. L'idée est de les faire monter en compétences sur une période allant de quelques jours à quelques semaines.
Je peux vous garantir que si vous faites l'impasse sur l'un de ces éléments, c'est la catastrophe assurée !
Je l'ai vécu de trop nombreuses fois dans mes précédentes expériences, et à chaque fois que c'est parti en sucette, c'était parce qu'un de ces éléments manquait.
Le développement produit, c'est du Build ou du Run ?
En gestion de projet classique, le développement du produit correspond à la phase de Build, alors que le maintien en condition opérationnelle et les opérations courantes correspondent à la phase de Run.
En mode agile, une équipe réalise les deux en même temps !
Lorsqu'une équipe de développement agile développe un nouveau produit, le build et le run se confondent.
En effet, l'équipe agile doit prendre en compte dès la conception comment le produit va devoir être produit, maintenu et opéré par la suite.
Il est donc nécessaire d'impliquer dès le démarrage du projet agile les équipes Run en tant que parties prenantes.
Build & Run en mode agile : Comment ça marche ?
Les méthodes agiles mettent en avant les notions de Build et de Run pour la production et l’exploitation des applications informatiques et des produits physiques ou digitaux.
En mode agile, les deux phases sont interdépendantes et s'influencent mutuellement.
En effet, l'objectif de la phase de Build est de développer une solution qui peut être exploitée de manière efficace en production, ce qui nécessite une coordination étroite avec la phase de Run.
Les retours d’expérience en phase de Run permettent d’identifier des axes d'amélioration et de proposer des solutions pour améliorer le produit.
Le Build et le Run en mode agile impliquent également une organisation et des pratiques de travail spécifiques.
Dans la phase de Build, l’équipe travaille en sprints, avec des itérations courtes et des démonstrations régulières pour valider les fonctionnalités développées.
L'objectif est de fournir des solutions rapidement, afin de pouvoir les tester et les valider par le client et les utilisateurs finaux. La communication et la collaboration entre les membres de l’équipe sont essentielles pour garantir la qualité et la performance de la solution.
En phase de Run, l'objectif est de fournir un service de qualité aux utilisateurs finaux. Pour cela, l’équipe doit mettre en place des pratiques de gestion de la qualité, telles que l'automatisation des tests, la surveillance de la solution et le suivi des incidents.
Il est également important d'assurer une veille technologique pour être en mesure d'anticiper les évolutions futures et les besoins des utilisateurs.
