Brevet FR3020889A1 — publié le 20151113

Introduction Le développement de produits complexes est un processus social très interactif impliquant des centaines de personnes concevant des composants interconnectés et devant prendre des décisions conjointes et cohérentes [Eppinger et Salminen (réf 1)]. La conception est un processus clé du développement de produit. C'est un processus dynamique dans lequel le produit, l'organisation et les processus d'ingénierie sont couplés, et entre lesquels l'information circule [Danilovis et Browning (réf 2)] : ^ L'ingénierie Système a mission de conception, c'est à dire d'élaboration d'un cahier des charges comportant toutes les exigences utiles au produit ou au service visé ^ La conduite de projet a mission, partant du cahier des charges, de réaliser le travail de conception dans un cadre : moyens et délais fixés. L'ingénierie des systèmes et la conduite de projet sont deux disciplines, deux communautés différentes qui pourtant opérationnellement doivent impérativement s'articuler et se compléter parfaitement : les exigences sont indispensables à la programmation des objectifs de conduite et les modes de conduites conditionnent largement l'élaboration du cahier des charges, s 'agissant d'une conduite de projet classique descendante ou d'une conduite « agile ». Cela nécessite que ces deux communautés se rapprochent et rapprochent leurs fondamentaux méthodologiques : les deux démarches s'appuient chacune sur leur propre description en processus et les différences de représentations sont une gêne dans les relations qu'il faut établir entre les deux communautés. Une enquête (réf 3) conduite, aux Etats Unis, par l'INCOSE, le PMI et le CEPE (Consortium for Engineering Program Excellence) du MIT auprès de 680 responsables, soit en Ingénierie Système (IS) soit en Management de Projet (MP), met en évidence l'impact négatif sur la bonne fin des projets de la non intégration des démarches 15 et MP. L'enquête montre que cet impact est sensible sur les plus petites et les plus grandes des sociétés considérées. Les trois principales sources de tension sont : absence de planning intégré (57%), autorité mal définie (44%), pratiques conflictuelles entre IS et MP (41%). Déjà des efforts sont en cours pour unifier les deux approches (réf 4). De plus, d'autres domaines de compétences « amont » sont naturellement sollicités dans la définition du cahier des charges et dans la conduite de projet : marketing, planification, ergonomie,.., qui nécessitent aussi d'être intégrés dans une démarche globale d'unification des approches. Nous nous attachons ici à analyser les trois points durs rencontrés dans la conduite de projet (intégration, coordination, décision) et à y apporter des améliorations immédiates. Cela conduit à une proposition originale, DECWAYS, qui intègre dans le processus décisionnel de conduite toutes les spécifications, quelles que soient leurs origines et leurs natures par l'usage systématique d' « indicateurs », qui propose une structure d'organisation et de représentation particulière qui conditionne la progression du projet à la certification de critères de coordination et de décision effectifs. Ces choix permettent de créer un outil de surveillance « automatique », au sens où il délivre, à chaque « jalon » de surveillance, un « tableau de bord » comparatif entre prévisions et réalisations, permettant d'enclencher les éventuelles procédures de révision. 1. La situation actuelle La conception et le prototypage d'un système complexe s'appuient sur un substrat de connaissances issues de la pratique industrielle, selon un découpage qui part d'une idée de produit ou de service, passe par la rédaction d'un cahier des charges rassemblant toutes les attentes et fixant les objectifs de performances à atteindre, et débouche sur les étapes de conception et d'assemblage du prototype. Dans cette démarche, la rédaction du cahier des charges est essentielle : elle peut être traitée avec la volonté d'aboutir à un cahier des charges exhaustif en termes de spécifications : c'est une approche classique « descendante » ; elle peut, pour plus de rapidité et de réactivité, accepter un cahier des P-1 charges incomplet, mais fixant des objectifs intermédiaires de court terme permettant de travailler en étapes successives et finalisées : c'est une approche « agile ». Dans ces étapes initiales, de nombreuses compétences interviennent pour fixer les contours du produit visé : techniques, marketing, ergonomiques, juridiques, financières... Pour la mise en oeuvre du projet, l'important est que toutes les exigences ainsi rassemblées, se trouvent bien reprises dans les « spécifications » du projet : sur cette base, la mise ne oeuvre du projet impliquera d'autres compétences.. L'Ingénierie Système apporte alors un substrat de connaissances indispensables pour traiter la diversité et la complexité des opérations à lancer et coordonner : elle donne de manière très complète tous les acteurs, les processus, les interactions, (réf 5, 6, 7, 8). Elle laisse l'entreprise en charge de les articuler : c'est donc souvent la pratique historique, empirique, qui fixe le processus de mise en oeuvre. L'ingénierie Collaborative vient en complément définir les méthodes et les outils (SGDT, PDM, PLM, ...) facilitant le développement des produits en permettant un travail collaboratif, simultané entre les différents acteurs impliqués dans un projet. Dans cette perspective, les infrastructures informatiques permettent aujourd'hui une communication efficace qu'il convient d'implanter ou de faire évoluer en fonction des besoins. La conduite de projet doit se nourrir de ces méthodes et outils : en fait elle doit les intégrer dans une procédure de conduite ad hoc. Elle doit effectivement, selon les besoins du projet, organiser les contributions et tâches de chacun et permettre, par les échanges et les décisions de conduite, de définir une démarche globalement optimale. On remarquera qu'il n'y a pas de proposition d'un « processus générique » qui pourrait, moyennant des adaptations mineures, s'appliquer à tous les projets. La pratique actuelle de la conduite de projet dans l'entreprise s'inspire de propositions et de recommandations, notamment celles mises en avant dans le guide PMBOK (réf 9). Elles identifient parfaitement les différents domaines de compétences qui doivent être mobilisés dans la gestion de projet de conception système : compétences techniques (ingénierie des systèmes, ingénierie des métiers, ingénierie orientée innovation) et technologiques, financières (gestion de ressources) et humaines (gestion des compétences), capacités prévisionnelles (planification), connaissances de l'entreprise et des marchés, analyse des risques et décisions... En pratique, donc, les entreprises adaptent les recommandations générales du PMBOK à leurs habitudes de fonctionnement et aux processus d'ingénierie mis en oeuvre ; dans la plupart des cas, ces modes de conduite applicatifs bien outillés supposent un travail complémentaire de coordination réalisé sur la base de réunions de concertation et de gestion nombreuses et difficiles. Dans les améliorations à apporter au processus de conduite de projet, il y a la nécessité de pallier le manque d'un processus global, accepté de tous et structurant l'usage des méthodes et des outils existants, nombreux et opérationnels. Avant de tenter de proposer des améliorations, il est nécessaire de considérer le bilan concret de ces pratiques. Les résultats publiés par le Standish Group (« Chaos Manifesto 2013: Think Big, Act Small ») s'appuient sur environ 50000 références de projet en Technologie de l'Information conduits aux Etats Unis (60%), en Europe (25%) et dans le reste du monde (15%). Le tableau suivant donne ces résultats pour plusieurs années : 2004 2006 2008 2010 2012 Successful Challenged 29% 35% 18% 53% 46% Project resolution resuits from CHAOS research for years 2004 to 2012. Pour 2012, les résultats montrent un taux de succès de 39% (fini à temps, budget respecté, comportant les fonctionnalités attendues) ; 43% sont en balance sur au moins un des points et 18% sont en échec (arrêtés en cours ou livrés et jamais utilisés). L'augmentation des parts de succès est due à des améliorations sur de multiples facteurs : méthodes, compétences, optimisation, travail en équipe, ... Globalement, la conclusion qui s'impose est qu'il est plus que jamais nécessaire d'améliorer les pratiques. Dans ces démarches d'entreprise, les praticiens ont déjà parfaitement identifié les principaux mécanismes qui font obstacle au bon déroulement du projet : l'insuffisance voire l'incohérence du cahier des charges, des choix technologiques non justifiés a priori voire hasardeux, des maladresses dans les allocations de ressources, une insuffisance du partage d'informations claires, structurées et compréhensibles. Tout cela entraine des problèmes qui n'apparaissent qu'au cours du déroulement projet, problèmes auxquels il faut apporter des solutions en modifiant, aussi légèrement que possible, les conditions de gestion ou les caractéristiques techniques du produit... Nous proposons ici la mise en place d'un système fondé sur un processus générique de conduite de projet qui, s'appuyant sur les outils existants, viendrait répondre aux insuffisances identifiées de coordination et de décision. Sur la base de ce processus générique, notre proposition DECWAYS est un système de supervision qui collecte de l'information sur l'état d'avancement du projet en cours, qui établit automatiquement un tableau de bord, détecte les écarts à la programmation initiale et organise formellement la concertation entre les acteurs dans la prise des décisions correctrices de la conduite de projet. 2. DECWAYS a. Présentation générale Un projet est, en général, le résultat d'au moins quatre grandes contributions : ^ La création qui finalise sous forme d'exigences les travaux en amont sur les marchés, sur l'économie et l'analyse de la concurrence, sur l'ergonomie, sur l'innovation,... ^ Les savoir-faire qui résultent de la capitalisation des acquis antérieurs avec un volet technologique et un volet méthodologique qui conduisent la réalisation. ^ Les ressources qui fixent les moyens en matériels, personnels et investissements ainsi que les délais de réalisation... ^ La certification qui vérifie la conformité du produit ou service aux attentes qui ont présidé au lancement de projet. Ces grandes contributions interviennent tout au long du processus de développement : du cahier des charges jusqu'au prototypage et au-delà I Il est donc indispensable qu'elles soient présentes et actives tout au long du processus de conduite. Pour réaliser cette exigence, DECWAYS systématise l'usage d'indicateurs attachés aux spécifications qui en garantissent leur exacte réalisation. Reste alors à assurer la participation permanente des trois autres contributions : dans une approche classique de conduite, elles sont prises en charge par les arbitrages de la Direction de projet. DECWAYS pour enrichir les échanges et améliorer la coordination propose d'organiser la Direction de projet en associant formellement ces trois compétences sous la forme d'une direction collégiale de trois responsables aux compétences complémentaires : Ex, la mise en oeuvre ; PI, la planification des moyens ; Co, le contrôle des performances (figure 1). Ce choix stratégique implique que les trois responsables aient un terrain de compétences opérationnel parfaitement clair : DECWAYS propose de procéder à une allocation formelle du lot de spécifications de chacun d'eux. La progression du projet exige alors structurellement, à chaque étape de progression, la concertation et l'aboutissement sur une décision de consensus : si un problème grave intervient la hiérarchie arbitre I DECWAYS et le cycle vertueux de la conduite de projet Figure 1- les trois compétences complémentaires. L'ambition de DECWAYS est, dans un contexte caractérisé par l'absence de démarche unifiée, de superviser et coordonner les échanges entre tous les domaines de compétences concernés par le projet. La démarche DECWAYS intègre les contributions suivantes : ^ Intégrer dans la structure de gestion une démarche obligatoire de concertation en définissant trois lignes de compétences (Exécuter, Planifier, Contrôler) aux périmètres parfaitement définis par les exigences du cahier des charges. ^ Dégager, pour chaque domaine de compétence concerné, les spécifications et des « indicateurs » associés, caractéristiques, pour faciliter le suivi et la détection de disfonctionnements dans une tâche ou un collectif de tâches ; construire des « indicateurs agrégés » et des « tableaux de bord » donnant une capacité de supervision du processus global ; rassembler toutes ces données dans une base de données à partir de laquelle pourront se construire des aides à la décision compréhensibles et performantes. ^ Mettre en place un réseau assurant la circulation de l'information entre les acteurs du projet devant nécessairement collaborer. ^ Proposer un processus générique de haut niveau de la conduite de projet de type « superviseur », facilement appropriable par les entreprises en tous domaines, gérant l'interdisciplinarité et venant compléter les pratiques PMBOK. ^ Proposer des mécanismes de prise de décision en harmonie avec le processus générique et maximisant l'information disponible lors de la prise de décision. Au titre de ces mécanismes, nous exploitons la notion d'horizon de décision qui définit les délégations de pouvoir à divers niveaux hiérarchiques, ce qui permet de faire passer un sous-ensemble d'une phase de développement à l'autre sans perte de temps, indépendamment du stade d'avancement des autres sous-ensembles. ^ Proposer des mécanismes de détection des disfonctionnements s'appuyant notamment sur l'analyse des écarts entre prévisions et résultats courants, l'analyse des tendances et offrant donc à l'équipe-projet une aide à la décision et au suivi longitudinal de l'évolution du projet. ^ Concevoir des outils informatiques de surveillance s'appuyant sur ces notions généralisées d'indicateurs, de tableaux de bords et de bases de données pour gérer l'interdisciplinarité des détections et des décisions afférentes. DECWAYS est fondamentalement conçu comme un système de suivi, de supervision du processus de conduite qui recherche notamment : ^ La simplicité de la mise en oeuvre par la définition d'un processus générique de conduite applicable à tout niveau de décomposition du projet en sous-projets, ^ L'automatisation de la détection des dérives en comparant les données prévisionnelles, aux données courantes. La figure 2 précise la schématique de la superstructure DECWAYS. Y apparaissent des notions connues en conduite de projet comme les exigences ou les ressources. Plus novatrice est l'existence d'une base de données spécifique à la conduite de projet : les événements de la conduite y sont consignés au fur et à mesure du temps et peuvent donc être postérieurement utilement ré-analysés et réutilisés. Système de surveillance pro DECWAYS Figure 2 - Système de supervision de projet. b. Processus générique Une originalité forte de la démarche DECWAYS est de proposer un processus générique de conduite de projet (figure 3) qui unifie, à tous les niveaux du projet, la façon de mettre en place la surveillance puis de la conduire. Processus générique DECWAYS 0->e iorbertts. .,,,l,speml.strles .tca'.e d.ts e. et,. >...^,e ara ïst ze fa 1.4 art est "- àrt-n, etge.,Itetts' Lete nve nnire des spéce ;cations tt DECWAYS 1 St ucurat ion Direction du Projet DECWAYS 2: WBS Direction opération ne e Ex, Pi, Co eate.-tce, CWAYS 3: Feuillesde route Cer.Z.."1 DECWAYS 4: 'Tableaux de bord e4r. DECWAYS 5: Accords dejaton DECWAYS Fiches Tâches Da 'renient a ixon ,que repez fl a ci ni, a ton DECWAYS 7: Dossier final de validation Figure 3 - Processus générique DECWAYS Ce processus générique englobe : ^ La structuration du projet autour des trois lignes de compétences Ex, PI, Co, ^ Un réseau d'information, développé essentiellement selon une logique WBS, partagé entre les trois lignes de compétences, ^ Une feuille de route explicitant les objectifs des trois compétences, ^ Un système de supervision fournissant, à chaque jalon, des fiches de retour de l'état des tâches, ^ Un tableau de bord édité automatiquement, ^ Un accord de jalon, résultat de la concertation entre les trois compétences (Ex, PI, Co), à partir duquel sont actualisées les feuilles de routes pour l'étape suivante. Le processus procède par jalons successifs convenus entre tous les acteurs jusqu'à la validation terminale. L'ensemble du processus est enregistré et rendu accessible pour des objectifs d'analyses du projet ou le lancement de nouveaux projets. c. Les acteurs de DECWAYS Les acteurs du processus DECWAYS sont : ^ La Direction du projet, qui fixe les objectifs et arbitre les décisions. ^ La Direction opérationnelle, qui comprend les 3 responsables (Ex, PI, Co) aux périmètres précisés par une répartition-partage du cahier des charges et qui définissent les tâches, les planifient et en assurent le suivi. ^ Les responsables de tâches, qui mettent en oeuvre le programme de travail et en rendent compte à la direction opérationnelle. d. Détection des dérives et indicateurs L'objectif central de la démarche de supervision est la détection automatique des dérives, l'aide au diagnostic et à la décision. Pour ce faire, DECWAYS a ses propres exigences : il faut en premier lieu définir les indicateurs qui permettront d'élaborer tableaux de bord et de nourrir les outils de diagnostics. Dans une démarche d'harmonisation des processus de l'ingénierie système et de la gestion de projet, les indicateurs sont vus comme des éléments d'un langage commun partagé par les deux mondes : les indicateurs doivent exprimer le cahier des exigences. Ceci n'exclue évidemment pas l'existence d'indicateurs spécifiques propres à la conduite de projet et aux choix technologiques par exemple. Lors de la définition d'une tâche, les prévisions de l'ingénierie confrontées aux exigences de la gestion permettront de fixer des objectifs chiffrés pour les indicateurs communs. En cours de réalisation de la tâche, la surveillance de l'évolution de chaque indicateur et sa confrontation à l'objectif permettra de détecter automatiquement des dérives entre le programme de travail initialement établi et la réalité d'avancement du terrain. Les dérives peuvent être de tout type : des dérives de planning, des insuffisances de performances, des dérives de compréhension mutuelle du problème ou des besoins, des dérives de qualité du produit ou du service en cours, des dérives de conception au regard des besoins initiaux et des contraintes, ou encore des dérives dans le pilotage du projet même. Ces dérives peuvent avoir des origines diverses : ^ liées à une gestion du projet un peu trop lâche (attention, pas laxiste), ^ liées à la dynamique des systèmes contributeurs de cette conception dont les responsabilités ou stratégies peuvent changer en cours de route par exemple. La fonction et la nature des indicateurs sont multiples : sécuriser, car ils peuvent être indicateurs d'une exigence du cahier des charges dont il convient de conserver la trace ; spécifier, car ils peuvent être représentatifs de grandeurs non standards mais pertinentes dans des cas particuliers ; visualiser, car opérateurs standards ils apporteront une information immédiatement lisible ; faciliter, car on peut par des procédures d'agrégations caractériser l'avancement du projet de manière synthétique et lisible par tous. Opérationnellement, ces indicateurs ont plusieurs temps de vie : leurs définitions, la négociation entre les parties prenantes des valeurs objectifs et des paramètres associés (seuils, plages de validité, ...), leurs évolutions temporelles enregistrées au cours de la mise en oeuvre. e. Le système DECWAYS met à la disposition de l'entreprise, pour conduire ses projets de développement, un système de supervision, de coordination et d'aide à la décision : ^ Supervision : fonction qui va permettre de détecter et caractériser systématiquement et automatiquement, les mauvaises tendances et d'éventuelles erreurs de conception et de conduite, tout au long du développement projet. ^ Coordination : fonction qui « oblige » la direction collégiale (Ex, PI, Co) à concerter leurs points de vue complémentaires, soit pour structurer les tâches à accomplir, soit pour proposer une décision correctrice une fois un disfonctionnement ou une dérive détectée. ^ Aide à la décision : fonction qui doit permettre d'aider à faire le diagnostic de l'origine de la difficulté détectée et de formuler une démarche de correction qui anticipe les « risques » comparés des différentes solutions proposées par les trois partenaires, Nous avons donc défini, pour atteindre ces trois objectifs, une approche originale de direction de projet collégiale (Ex, PI, Co) aux compétences complémentaires et une architecture de mise en oeuvre basée sur les systèmes de surveillance, appliquée au processus habituel de conduite de projet : spécifications, conception, assemblage, vérifications et s'appuyant sur l'exploitation opérationnelle des outils existants. DECWAYS s'appuie sur une démarche experte avec ses règles applicatives indispensables à la réalisation des objectifs de supervision, coordination et aide à la décision mais aussi à la mémorisation des événements et à la mise en oeuvre du système lui-même : ^ Supervision - Nous voulons un mode automatique de détection des déviations de comportements dans la conduite de projet entre les données obtenues par simulation, à partir d'un modèle théorique de cette conduite élaboré sur un base d'analyse prédictive (faisabilité) lors de la phase de conception système et la réalité opérationnelle. Les indicateurs sont les outils utilisés pour accumuler les données mesurées au cours du projet. Règle 1 : implique que le projet, au stade de la conception, a fait l'objet d'une évaluation théorique de sa faisabilité pouvant servir de référence pour définir les étapes et les objectifs théoriques de réalisations conformes aux exigences. Idéalement, il s'agit d'un simulateur programmable pour permettre de simuler et d'évaluer différentes options de conduite. Règle 2 : implique que tous les « indicateurs de suivi DECWAYS » expriment les exigences du projet, initialement inscrites dans le cahier des charges et affectées selon les trois compétences Co, Ex, Pl. Ce sont les deux règles qui vont permettre de construire, à chaque jalon de temps, un « tableau de bord » comparant les valeurs des indicateurs de mesures courantes aux valeurs théoriques, donnant l'état d'avancement du projet et le cas échéant détectant des difficultés. ^ Coordination - Cela consiste à s'appuyer sur une répartition des charges du projet entre les trois lignes de compétences Ex, PI, Co et à s'assurer des rendez-vous de concertations rendus obligatoires. Les outils existants sur lesquels on pourra s'appuyer pour ce faire serviront à identifier toutes les exigences du projet, leur associer des indicateurs, les répartir entre les responsables, les affecter dans les cahiers de charges de chaque tâche... Les outils serviront aussi à la construction du réseau d'information, à la collecte des données et à leur mémorisation... Règle 3 : implique que toutes les exigences soit identifiées, listées et réparties entre les trois compétences. Il faut qu'à chacune soit associé un « indicateur de suivi » et une équation de tolérance qui servira au calcul du risque quand le projet sera en cours d'exécution. DECWAYS s'appuie sur une décomposition en lots et arborescence de tâches (Work Breakdown Structure (WBS)) et l'ambition de coordination fondée sur la collégialité Ex, PI, Co, doit prendre en compte cette structuration : chaque tâche doit avoir son volet de recommandations : Ex, PI, Co ; cela revient à ce que la décomposition en tâches soit concertée pour aboutir à un découpage de consensus : Règle 4 : implique que la structuration en lots (WBS) soit identique, ou quasi identique, pour les trois compétences (WBSco, WBSpI, WBSex) pour pouvoir établir et « rendre obligatoire » structurellement les rendez-vous de concertation à chacun des jalons temporels voulus par le management. Règle 5 : implique que soit défini un réseau de communication et d'information entre toutes les tâches d'un lot; le réseau doit être complet, c'est-à-dire qu'un lot spécifiant une tâche d'un autre lot doit lui être structurellement connecté. La structure de base du réseau est celle de la décomposition en arborescence (WBS) à laquelle on ajoute les connexions permettant la prise en compte des besoins d'échanges inter lots ou inter tâches ou de nouvelles spécifications obtenues au fil de l'avancement du projet. Règle 6 : implique que les échanges se fassent sur la base d' « indicateurs de suivi ». Tout indicateur, à tout niveau, doit associer 3 valeurs : la valeur théorique (exigence du cahier des charges reçue par le responsable), la valeur estimée (valeur donnée par le responsable) et la valeur réelle (valeur obtenue par remontée des valeurs mesurées lorsque l'exécution des tâches a débuté). Il est aussi possible de construire des indicateurs composites donnant une information intégrée sur l'état du système : On peut citer un indicateur de type Gestion de la Valeur Acquise (ou EVM en anglais) qui donnera une information sur l'avancement du projet liée à des considérations économiques. Sur la base de ces 6 première règles un outil de supervision peut être construit consistant, à chaque jalon, à recueillir puis échanger automatiquement les données caractérisant l'état d'avancement des travaux. La coordination va pouvoir se construire grâce à la confrontation des points de vue : Ex, PI, Co ; on constitue ainsi, à chaque incrément de temps, une base de données partagée de l'histoire du projet. ^ Aide à la décision - Sur la base des résultats du suivi par les indicateurs et des détections de disfonctionnements, il s'agit de construire des fonctions d'aide au diagnostic et aux corrections. Le mode automatique de détection est inscrit dans le choix d'une architecture de surveillance : cette détection va résulter de la mesure des écarts entre les données prédites du modèle théorique et les données courantes. Règle 7 : implique que les « tableaux de bord » soient établis à partir des données collectées sur les tâches, qu'ils rassemblent les valeurs des indicateurs convenus entre les trois compétences ; Ex, PI, Co. Et qu'ils appliquent les règles de détection automatiques. Pour la remontée aux causes, les indicateurs doivent être bâtis sur une modélisation causale explicite de manière à pouvoir aisément remonter aux spécifications amont dont on peut espérer tirer l'explication de la survenue d'erreurs et de déviances. Si ces spécifications sont (reglel) caractérisées par une équation de tolérance exprimant le danger encouru si elle n'est pas exactement réalisée, il devient possible de construire un ou des indicateurs de risque. En fonction de priorités fixées par les 3 compétences, ces indicateurs de risque vont permettre de quantifier le risque et d'aider au diagnostic de l'origine et du sens des corrections à effectuer. Cette évaluation du risque contribuera à faciliter les échanges et à construire la décision. Exceptionnellement, on pourra revenir sur la démarche de conduite grâce aux solutions alternatives conservées de l'étude de faisabilité. Règle 8: implique que l'on construise, comme outil d'aide à la décision, des « indicateurs de risque » bâtis sur les spécifications et caractérisant le danger encouru si l'on ne remplit pas exactement la spécification initiale. Pour la prise de décision, DECWAYS crée un environnement formel d'échanges des points de vue au regard du tableau et des indicateurs de risque. DECWAYS s'accommode de décisions prises par consensus mais laisse le choix du mode décisionnel à l'entreprise : désignation d'une des trois compétences responsable ultime est possible ; il est aussi toujours possible d'en référer au niveau hiérarchique supérieur pour trancher. Cet environnement formel comporte aussi la notion d'horizon de décision. Il s'agit de définir qui a droit de regard sur des décisions locales, particulières : choix d'une solution parmi plusieurs, passage d'un sous-ensemble d'une phase de développement à la suivante. Ces décisions doivent être prises à bon escient mais aussi au plus tôt : la délégation de décision ainsi instituée le permet. Cette notion d'horizon de décision est fondée sur un constat simple : une décision concernant un niveau donné de l'arborescence WBS ne mobilisera qu'un tout petit nombre de niveaux hiérarchiques immédiatement supérieurs. Règle 9 : Implique que les modes de prise de décision soient fixés par les utilisateurs et mis en oeuvre. La notion d'horizon de décision, caractérisant l'ampleur de la diffusion des résultats de corrections au sein du projet doit être prise en compte et gérée. ^ Mémorisation et réutilisation - Un intérêt opérationnel très important est la mémorisation des tableaux de bord et des corrections apportées en cours de conduite de projet, intéressant pour l'analyse des situations courantes, pour les analyses prospectives mais aussi pour guider de nouveaux programmes. Pour exploiter toutes ces possibilités, il convient d'indexer la mémorisation des données sur la base d'une ontologie de concepts référente facilitant les recherches. Cela va permettre : - la constitution d'un historique, complétement documenté de l'ensemble des choix et décisions, exploitable ultérieurement dans la préparation et la conduite de nouveaux projets. - L'analyse, en considérant la structure des concepts qui donne une image de la répartition des tâches, d'analyser le réseau d'information. Exemple : une tâche de création d'un pilote informatique associée à un concept de vérin et non reliée au concept de développement informatique amènera à questionner le réseau d'information. Ceci requiert une gestion rigoureuse de l'ontologie. Règle 10 : implique que les données du projet soient enregistrées dans une base de données, accessible, dans le respect des règles de confidentialité et permettant de reconstituer, par exemple, le fil temporel du projet ou de réutiliser telle ou telle partie des travaux. Règle 11 : implique qu'une gestion de l'ontologie des concepts soit mise en oeuvre dans le ou les projets d'une entreprise qui pourrait être utilement confiée à une « autorité » indépendante garante de sa pérennité et de la maitrise de son évolution. ^ Mise en oeuvre - DECWAYS propose une méthode (modèle de surveillance) et un cadre pour la construction d'un outil nouveau de conduite de projet : les 11 règles précédentes sont la condition de sa mise en oeuvre. Dans la mesure où elles sont vérifiées, DECWAYS s'applique ! C'est dire que, sur un grand projet, la méthode peut être appliquée identiquement sur le projet global et sur chacun de ses sous-projets. DECWAYS s'inspire fondamentalement d'une démarche classique descendante : il prévoit structurellement les relations et les échanges dans la conduite des lots et le management à trois compétences (Co, Ex, PI) de chacun d'eux. Il intègre des relations directes inter-lots : lors de l'établissement du WBS, les exigences se répartissent en suivant la logique de décomposition. Règle 12 : implique dans un projet complexe d'appliquer les règles au processus global de conduite de projet mais aussi aux processus partiels pouvant apparaître dans le découpage den tâches impliquant des relations précises inter-tâches (cluster de tâches). Dans DECWAYS la démarche classique descendante et les démarches de type « agile » peuvent parfaitement cohabiter : DECWAYS laisse libre la conduite qui la définition du mode de conduite interne de chaque tâche, de chaque cluster ou de chaque lot. C'est aux responsables de taches d'en décider 1 De manière générale, les équipes et responsables de tâches et de lots ont une large autonomie pour conduire leurs travaux : ils doivent toutefois utiliser parmi les indicateurs choisis ceux imposés par la concertation Ex, PI, Co et conduite globale du projet. Règle 13 : implique que si un sous ensemble est conduit de manière spécifique, il convient impérativement que son management utilise les indicateurs de suivi du processus global. 3. Recherche d'antériorité Nous avons procédé à une étude des brevets existants ayant un rapport avec la gestion de projet. Pour ce faire, nous avons consulté la banque de données en ligne de l'Institut National de la Propriété Industrielle (INPI). La recherche, réalisée à partir de trois équations basées sur les quatre mots clés « projet » et « supervision, management et gestion », fournit les références d'environ 380 brevets. Nous avons systématiquement considéré ces références et en avons sélectionné quinze qui nous paraissaient les plus proches de nos travaux (réf 10). On vérifie que le plus grand nombre (réf 10-1, 10-2, 10-5, 10-9, 10-10, 10-11, 10-13, 10-15) met l'accent sur la gestion des données du projet ; la plupart du temps, il est fait référence à l'existence d'un outil informatique pour la mise en oeuvre de l'idée ou de la méthode. De la même manière, on trouve assez généralement la notion d'affichage des données ou des résultats sous la forme de tableaux de bord ou de matrices. La notion de division du projet en sous-projets apparait plusieurs fois. Elle est associée soit à l'idée de scénario, soit à l'idée de planification ou elle est sous-tendue par l'exploitation de modèles (réf 10-2, 10-4, 10-6, 10-11, 10-12, 10-14). Plus ponctuellement, on trouve la notion de suivi de projet associée à celle d'évaluation du risque (réf 10-3), la notion d'évaluation de la priorité de réalisation d'un sous-ensemble (réf 10-6), la notion de correction d'un plan d'exécution d'un processus sur une base probabiliste (réf 10-7) et, enfin, la notion de gestion de flux de travail et du suivi de l'évolution des tâches. De ce bref panorama, il ressort que ce qui fait le coeur de la démarche DECWAYS, à savoir l'intégration des approches Ingénierie Système et Management de Projet à travers une structure de supervision fondée sur un réseau d'information et associant trois compétences (Exécution, Planification, Contrôle) en collaboration permanente, n'apparait pas dans les brevets consultés. REVENDICATIONS1. Revendication 1 : Système de conduite de projet fondé sur 1/ une organisation originale de la direction opérationnelle du projet entre trois compétences [la mise en oeuvre (Ex), la planification (PI) et les contrôles (Co)], dont les périmètres d'interventions sont strictement définis par une affectation concertée des exigences du cahier des charges, 2/ un réseau d'information, construit selon une logique descendante complétée de liens obtenus par recherche fondée sur une ontologie métier et dont chaque noeud est à la fois centre de décision, collecteur et créateur d'informations. Revendication 2: Selon 1, avec le fait que le suivi de conduite se fonde sur la disponibilité, au démarrage du projet, d'un cahier des charges identifiant toutes les exigences et les objectifs de réalisation. Revendication 3 : Selon 1 et 2, avec le fait que la répartition des exigences dérivées du cahier des charges du projet entre les trois compétences et le suivi de leurs évolutions au cours de l'exécution des tâches du projet conduit à définir un processus générique de conduite de projet assurant la supervision de la conduite, la coordination et l'aide à la décision. Revendication 4 : Selon 1, 2 et 3, avec le fait que le processus générique s'applique aussi bien sur un projet ne comportant qu'une tâche unique que sur un projet comportant des tâches multiples interférentes et structurées selon la concertation entre les responsables des trois compétences. Revendication 5 : Selon 1, 2, 3 et 4, avec le fait qu'à chacune des exigences est associé un indicateur matriciel caractérisant l'évolution en cours du projet, de son degré de réalisation. Revendication 6 : Selon 1, 2, 3, 4 et 5, avec le fait qu'à chaque indicateur est associée une fonction exprimant le risque de non satisfaction de l'exigence représentée.Revendication 7 : Selon 1, 2, 3, 4, 5 et 6, avec le fait que le projet est découpé en jalons successifs jusqu'à l'achèvement du projet, jalons initiés et actualisés par accords concertés entre les trois compétences. Revendication 8 : Selon 1, 2, 3, 4, 5, 6 et 7 , avec le fait que, à chaque jalon, les dérives, les erreurs ou les disfonctionnements de conduite et les risques associés sont automatiquement détectées par évaluation des écarts entre l'état courant du projet, fourni par les valeurs des indicateurs, et les objectifs initialement programmés. Revendication 9 : selon 1, 2, 3, 4, 5, 6, 7 et 8, avec le fait que le système délivre automatiquement, à chaque jalon, un tableau de bord complet rassemblant toutes les informations disponibles afin de servir de support aux décisions correctrices concertées entre les responsables des trois compétences. Revendications 10 : Selon, 1, 2, 3, 4, 5, 6, 7, 8 et 9, avec le fait que les informations sur le projet gérées par le système sont mémorisées dans une base de données, structurée par une ontologie métier, pour analyse et usage ultérieur. 5. Références 1- Eppinger S.D., Salminen V. « Pattern of product development interactions », International Conference on Engineering Design, Glasgow, 21-23 Août, 2001 2 - Danilovic M., Browning T. R. « Managing complex product development projects with design structure matrices and domain mapping matrices » International Journal of Project Management, 25, 300-314, 2007 3 - Conforto E., Rossi M., Rebentisch E., Oehmen J., et Pacenza M. « Survey report : Improving integration of program Management and Systems Engineering » MIT Consortium for Engineering Program excellence, 2013 4 - Oehmen J. et alii « The guide to lean enablers for managing engineering programs », 2012 - « ANSI/EIA standard for process for engineering a system » ANSI/EIA STD 632, pp c1-77 6 - « ISO/IEC/IEEE systems and software engineering - System life cycle processes » IEEE STD 15288-2008 p. c1-84, 2008 7 - « IEEE standard for application and management of the systems engineering process » IEEE STD 1220-1998, 1999 8 - INCOSE « INCOSE systems engineering handbook v3.2 : a « how to » guide for all engineers », 2010 9 - PMI « A guide to the project management body of knowledge : PMBOK guide », v5, 2013 - INPI - Références des brevets consultés auprès de l'INPIbrevet n° WO 2005071564 (réf 10-1); brevet n° WO 2012118906 (réf 10-2); brevet n° WO 2012071474 (réf 10-3); brevet n° EP 2608031 (réf 10-4); brevet n° EP 2375367 (réf 10-5); brevet n° EP 2133833 (réf 10-6); brevet n° EP 1376422 (réf 10-7); brevet n° EP 0950971 (réf 10-8); brevet n° WO 2013181719 (réf 10-9); brevet n° WO 2012116413 (réf 10-10) ; brevet n° WO 2011090883 (réf 1011); brevet n° WO 2010135122 (réf 10-12); brevet n° WO 2009027709 (réf 10-13); brevet n° WO 03019432 (réf 10-14); brevet n° WO 2004032530 (réf 10-15)