2e opus de notre série consacrée aux Organisations Collaboratives en Réseau (OCR). Aujourd’hui, Gabriel S. Serapiao Leal nous présente les différentes manières de cadrer, gouverner et modéliser les processus collaboratifs d’une OCR. Organisations Collaboratives en Réseau.
Les organisations collaboratives en réseau (OCR) sont des organisations qui travaillent ensemble pour attendre un objectif en commun. En effet, les OCR sont créées pour faire face à une grande diversité de défis, parmi lesquels les crises financières, sanitaires, mais aussi la compétition et l’innovation continue. Dans ce mode d’organisation, la collaboration est le carburant pour atteindre efficacement les objectifs prédéfinis. Dans cet article, nous jetons la lumière sur le cadrage des processus collaboratifs dans les OCR.
Dans l’article Organisations collaboratives : l’avenir des entreprises, nous avons analysé le phénomène des OCR plus en détail. Nous avons ainsi pu apprécier quelles étaient les principales caractéristiques d’une OCR et les différents types des relations existantes entres les membres d’un tel réseau. Dans la suite de cet article, vous découvrirez les différentes manières de cadrer, de gouverner et de modéliser les processus collaboratifs d’une OCR.
Une organisation complexe
Effectivement, les collaborations peuvent être complexes car les équipes des OCR sont composées de différents membres qui ont parfois des objectifs individuels, des points de vue différents, etc. Les organisations collaboratives sont également complexes car elles rassemblent des personnes d’horizons et de cultures différentes (en considérant à la fois les aspects personnels et professionnels). En outre, cette organisation complexe demande à ses membres de collaborer de manière efficace afin d’atteindre les objectifs de l’organisation.
Cependant, les objectifs de la collaboration ne sont pas toujours clairs pour tout le monde, tout comme le fait de savoir comment interagir avec d’autres membres issus d’autres domaines (par exemple, marketing, ingénierie, finance, recherche et développement, ventes, etc.). La complexité de la collaboration augmente lorsque les équipes proviennent d’entreprises distinctes. Les questions juridiques et propriété intellectuelle entre autres doivent alors être prises en compte dans un tel cas.
Notez que les organisations de collaboration sont formées pour poursuivre des objectifs communs qui peuvent être atteints par les parties prenantes impliquées.
Afin d’éviter les conflits et de désaligner les parties prenantes, il est prudent de définir un cadre de collaboration partagé. Il est donc dans l’intérêt des équipes de lister tous les objectifs qui sont en commun ainsi que ceux qui peuvent générer des conflits en cours de route.
Autre point important : le processus de collaboration doit être défini, documenté et partagé entre les parties prenantes. Un processus collaboratif est en effet un ensemble d’activités ordonnées qui doivent être exécutées par des rôles spécifiques afin d’atteindre l’objectif global en fournissant des produits et / ou des services.
C’est pourquoi, face à tant de complexité, je vous présente dans les trois sections suivantes un cadre pour la définition d’un processus collaboratif, une vision de la gouvernance utile aux projets collaboratifs, ainsi qu’un exemple illustratif d’une OCR et un de ses processus.
Définir un processus collaboratif
Lors de la définition du processus collaboratif d’une OCR, le(s) responsable(s) du processus doit commencer par définir « pourquoi » le projet est important et les besoins commerciaux auxquels il est lié. Expliquer pourquoi le projet a une valeur ajoutée pour les parties prenantes potentielles est essentiel pour établir une compréhension commune et solide, ainsi que pour favoriser l’engagement.
Ensuite, les rôles, les livrables et les activités doivent être définis. De quoi s’agit-il ? Les livrables sont la traduction du « pourquoi », les rôles quant à eux sont occupés par les responsables qui auront la tâche de transformer le « pourquoi » en livrables à travers des activités définies.
Les activités et les livrables
Une fois le pourquoi bien défini, deux autres éléments devraient être pris en compte. Premièrement : il faut décider de savoir en « quoi » le « pourquoi » devrait être traduit (c’est-à-dire les livrables). Ensuite, il importe de définir les activités donnant le ton du « comment » à la conception et à la production des livrables.
- Les livrables sont tous les extrants et les résultats du processus de collaboration, tels que les rapports d’évaluation, les produits, les services, etc. Les activités représentent les actions réalisées par les personnes qualifiées utilisant leurs ressources pour transformer les entrées en sorties.
- Une activité est une étape de processus qui peut être atomique (tâches) ou décomposable (sous-processus), et est exécutée soit par un système (automatisé), soit par des humains (manuel). Toutes les activités partagent des attributs et des comportements communs tels que des états et transitions d’état.
Les rôles
L’étape suivante consiste à intégrer les personnes chargées de piloter et d’exécuter le projet. En effet, ce sont elles, avec leurs compétences spécifiques, qui transformeront le « pourquoi » en un état plus précieux et réel. Pour ce faire, il faut réfléchir, et rédiger les compétences techniques et générales nécessaires pour donner vie au projet collaboratif.
Ce projet devrait préciser les rôles que les personnes assumeront. Autrement dit, il doit définir la responsabilité, les droits et l’autorité que chaque rôle englobera. Les relations et les interactions doivent être explicites. Cette ébauche sera revue au fur et à mesure que les projets évoluent, que d’autres activités sont incorporées et que davantage de personnes sont engagées.
Lors de la discussion au sujet des rôles des membres, le processus de prise de décision doit être clair et accepté par toutes les équipes. Il est important d’établir ce point à l’avance pour éviter les conflits par la suite. Par exemple, si un membre de l’équipe A doit rendre compte à un autre membre de l’équipe B, cela doit être clair, afin d’éviter que le membre de l’équipe X refuse de parler au membre de l’équipe B sans l’approbation de ses responsables.
Les ressources
En outre, les ressources « non humaines » pour soutenir l’ensemble du processus de collaboration devraient également être discutées et envisagées. Ces ressources font référence à toutes les ressources tangibles et immatérielles (ex : machines, logiciels, argent, etc.) nécessaires pour soutenir le processus collaboratif et ses activités.
Parmi les ressources, les canaux de communication sont critiques. Ils doivent être accessibles à toutes les personnes impliquées. En effet, la communication doit être entretenue entre les membres de l’équipe. La communication favorise la transparence et renforce la confiance entre les membres, ce qui entraîne moins de frictions, de conflits et finalement des équipes plus efficaces et efficientes.
Par exemple, des outils collaboratifs peuvent être utilisés pour partager les mises à jour du projet et améliorer la communication. Un tableau de bord est toujours une bonne idée pour vérifier les progrès et l’humeur des équipes. D’autres outils tels que les référentiels partagés ou les applications de chat constituent également de bonnes pratiques pour connecter les membres de l’équipe.
La modélisation
Les modèles sont des représentations abstraites d’une réalité connue. Adoptant une approche systémique, ils décrivent les structures et les relations entre les systèmes ainsi qu’entre leurs éléments.
Un modèle est un outil puissant pour visualiser et tracer l’état actuel et souhaité d’un process. Il nous sert aussi à identifier et à clarifier des activités et des responsabilités. Ainsi, la modélisation nous permet de décrire et de visualiser les différentes parties d’un processus collaboratif.
Le modèle ci-dessous présente un processus collaboratif fictif. Dans le modèle, nous pouvons observer les différents rôles et ses interactions. La séquence des activités est aussi explicitée, ainsi que les ressources nécessaires pour certaines activités.
Dans cet exemple, le langage BPMN (Business Process Model Notation) est utilisé. BPMN est un des langages les plus répandus pour la modélisation des processus. Néanmoins, il existe une vaste gamme de langages et de notations à disposition3.
La gouvernance et la gestion des processus collaboratifs
La gestion des organisations collaboratives nécessite une grande rigueur afin de ne pas perdre de vue l’objectif principal de la collaboration. De même, un tel projet nécessite également un sens aigu de la confiance et une communication active (partage d’informations pertinentes, écoute des préoccupations du personnel, etc.).
En fonction du style de gestion choisi, l’OCR peut avoir un chef de projet ou une équipe de direction. Dans ce dernier, l’équipe peut être composée des chefs d’équipe et des animateurs. Compte tenu du premier, le chef de projet peut être le directeur d’un département, le PDG, un PMO dédié.
En effet, il peut s’inscrire dans une gestion plate ou hiérarchisée. Quel que soit le style choisi, il doit correspondre à la stratégie définie pour atteindre l’objectif commun. Il devrait également être capable d’instaurer une bonne adéquation entre les parties prenantes pour éviter tout type de conflit au cours du projet.
Outre le style de gestion, une méthodologie de travail doit aussi être définie et partagée. De nos jours, pléthore de méthodologies existent dans différents secteurs. Nous pouvons trouver ainsi trois types de méthodologies générales : Traditionnelle, Agile et Hybride.
- Traditionnelle : c’est une pratique que suit un déroulement séquentiel. Les phases correspondent à des ensembles de tâches prédéfinies dans un planning de réalisation précis. Les méthodologies plus connues sont le Cycle en V et Cascade.
- Agile : cette pratique favorise l’itération continue du développement et des tests tout au long du cycle de vie de développement du projet. Les méthodologies plus connues sont le SCRUM, Kanban et Extreme Programming.
- Hybride : c’est un mélange entre des méthodologies traditionnelles et classiques, souvent observé dans la cadre de projets professionnels. Par exemple, dans un département où deux systèmes d’information doivent interopérer. Si une équipe suit SCRUM et l’autre Cascade, soit une des deux équipes adopte la méthodologie de l’autre (rarement), soit un compromis est trouvé, notamment concernant les dates et le rythme de développement.
En effet, les organisations ne pratiquent pas toujours une adoption pure des méthodologies agiles. Au contraire, nous trouvons plus souvent l’application des méthodologies dites classiques ou un mélange.
Vous pouvez consulter ici une comparaison entre la méthode agile et la méthode : Agile vs cycle en V : le combat du pilotage de projet.
Illustration d’un processus collaboratif
Prenons un exemple d’une OCR présenté dans l’article Organisations collaboratives : l’avenir des entreprises ? L’OCR en question a pour objectif de développer un stimulateur cardiaque (pacemaker) commandé par une intelligence artificielle. Elle est composée de deux grandes organisations : l’hôpital Saint-Paul (France) et la HighTechAI Inc. (USA). Les équipes MedC et Meca ont été retenues par l’hôpital, alors que l’équipe Analytics a été identifiée du côté de HighTechAI.
Le « pourquoi » du processus collaboratif choisi est la construction d’un PoC (Proof of Concept – Preuve de Concept) du stimulateur cardiaque intelligent. À partir de ce « pourquoi », les livrables, activités et rôles peuvent être définis.
Dans cet exemple, le livrable final est le PoC testé et validé. En revanche, plusieurs livrables sont attendus au cours du processus :
- Module d’intelligence artificielle
- Jeu de données pour entraîner le module d’intelligence artificielle
- Module d’intelligence artificielle entraîné
- Prototype physique du pacemaker
- PoC du pacemaker avec module d’intelligence artificielle intégré
Afin de produire les livrables, certaines activités doivent être réalisées. De même, des ressources devront être consommées et transformées en livrables lors des activités.
Dans notre exemple, les activités, les entrées et les rôles responsables sont les suivantes :
| Activités | Entrées | Sorties (livrables) |
| Conception mécanique du pacemaker | – Exigences technico-fonctionnelles du produit | – Schématiques de la conception |
| Développent mécanique du pacemaker | – Matière première – Composants électroniques – Schématiques de la conception | – Prototype physique du pacemaker |
| Test de performance du pacemaker | – Schématiques de la conception – Infrastructure de simulation | – Résultats des simulations – Rapport de validation |
| Préparer le jeu de données cardiaques pour entraîner le module d’intelligence artificielle | – Données (images, descriptions et autres informations) par rapport aux anomalies cardiaques | – Jeu de données pour entraîner le module d’intelligence artificielle |
| Développer le module d’intelligence artificielle | – Exigences technico-fonctionnelles du produit – Infrastructure de développement | – Module d’intelligence artificielle |
| Qualifier le module d’intelligence artificielle | – Infrastructure de qualification – Jeu de données de qualification | – Résultats des simulations – Rapport de validation |
| Entraîner le module d’intelligence artificielle | – Jeu de données final | – Module d’intelligence artificielle entraîné |
| Intégration du module d’intelligence artificielle dans le pacemaker | – Module d’intelligence artificielle entraîné – Prototype physique du pacemaker – Infrastructure d’implémentation | – PoC du pacemaker avec module d’intelligence artificielle intégré |
| Qualification finale | – PoC du pacemaker avec module d’intelligence artificielle intégré | – PoC du pacemaker avec module d’intelligence artificielle intégré – Rapport de validation |
Une fois les activités définies, les responsables d’exécution, de gestion et de validation doivent aussi être définis et partagés entre les différentes partie prenantes. Les rôles doivent être décrits avec un bon niveau de détail afin de permettre l’identification des points de contact entre les équipes, et les responsables pour les livrables.
Le tableau ci-dessous identifie les rôles pour les activités de notre exemple :
| Activités | Rôles |
| Conception mécanique du pacemaker | – Ingénieur système – Ingénieur mécanique – Ingénieur électronique |
| Développement mécanique du pacemaker | – Ingénieur mécanique – Ingénieur électronique |
| Test de performance du pacemaker | – Ingénieur système – Ingénieur mécanique – Ingénieur électronique – Experts cardiologues |
| Préparer le jeu de données cardiaques pour entraîner le module d’intelligence artificielle | – Experts cardiologues |
| Concevoir le module d’intelligence artificielle | – Ingénieur des systèmes d’information – Expert en intelligence matricielle – Développeurs |
| Développer le module d’intelligence artificielle | – Ingénieur des systèmes d’information – Expert en intelligence artificielle – Développeurs |
| Qualifier le module d’intelligence artificielle | – Ingénieur des systèmes d’information – Expert en intelligence artificielle – Experts cardiologues |
| Entraîner le module d’intelligence artificielle | – Expert en intelligence artificielle |
| Intégrer le module d’intelligence artificielle dans le pacemaker | – Ingénieur des systèmes d’information – Expert en intelligence artificielle – Développeurs – Ingénieur mécanique – Ingénieur électronique |
| Qualification finale | – Ingénieur des systèmes d’information – Experts cardiologues – Ingénieur système |
Finalement, avec les informations identifiées précédemment, le processus collaboratif peut avoir une première version de son modèle. La modélisation est aussi évolutive, en fonction de l’avancement du projet. D’autres activités et ressources peuvent être ajoutées si besoin. Enfin, d’autres rôles peuvent également intervenir afin d’avoir une deuxième couche de validation, etc. L’image suivante nous présente le processus collaboratif de notre exemple.
Concernant la gouvernance et le management, nous pouvons imaginer que l’équipe Analytics de HighTechAI développe le module d’intelligence artificielle dans un cadre agile. Ils ont besoin de l’agilité et de l’adaptabilité des différentes itérations pour aboutir à un produit de qualité. L’agilité leur permet de tester et de valider rapidement leur module en se basant sur les demandes et les besoins des experts cardiologues.
L’équipe Meca de l’hôpital suit plutôt une approche en V. Étant donné que les ressources sont limitées et que les exigences techniques ne changent pas à un rythme élevé, cette approche plus traditionnelle permet aux ingénieurs de bien spécifier le prototype et de simuler son comportement avant de le construire.
Les experts cardiologues interviennent au début du projet pour affiner les besoins et les exigences. Ensuite, ils participent aux différentes phases de test et de validation d’un produit. Ils peuvent intervenir également à la demande des équipes pour une mission de support.
Pour gérer le projet global, un chef de projet peut adopter une approche hybride afin de concilier l’état d’avancement des deux équipes Analytics et Meca, en y associant la participation des experts cardiologues de l’équipe MedC.
Conclusion
Dans cet article, nous avons proposé une approche de cadrage des processus collaboratifs d’une Organisation Collaborative en Réseau. Nous avons ainsi pu apprécier quelles étaient les principaux composants d’un processus collaboratif et ses interactions. La modélisation s’avère un outil essentiel pour la visualisation et la compréhension du processus.
De même, nous avons pu analyser les différentes façons de gouverner et de gérer ce type de processus. Il est important de définir, de partager et de valider ensemble l’approche de cadrage et le suivi des processus collaboratifs. En effet, un processus collaboratif bien défini et partagé favorisera le développement des services et des produits, menant ainsi l’Organisation Collaborative en Réseau à ses objectifs souhaités.
Sources
- Organisations collaboratives : l’avenir des entreprises ?, Gabriel Leal, 2021
- Business Process Model and Notation – Object Management Group, 2010
- Les perspectives de modélisation, outils de représentation d’entreprise, Gabriel Leal, 2020
- Agile vs cycle en V : le combat du pilotage de projet, Christophe Jamin, 2017
Pas encore de commentaires