Industrialisation : manager la qualité des projets

Industrialisation : manager la qualité des projets
Support de formation INDUSTRIALISATION INDUS5-ManagerQualitéProjets-v2.0 Mars 2007

Objectifs de la session
Présenter les différentes composantes concourrant au management industriel et de la qualité des projets, avec les outillages associés (QW2 et Pack1) - organisationde la maîtrise des procédés - plan Qualité Projet / Plan de Production Projet - revues de fin de phase - revues par les pairs - boucle d’amélioration. Cette session : est destinée aux Chefs de Projet / Responsables qualité / Responsables d'équipe et/ou "transverses" ne remplace pas la session de formation « Ecole Qualité » (2 jours). Atos Origin System Integration a lancé un vaste plan d'industrialisation. Il s'agit bien de ne pas réinventer la roue à chaque projet, mais de capitaliser et d'exploiter des solutions standards. Ces solutions standards et le retour d'expérience constituent un patrimoine de ressources mis en commun et mis à diposition de tous dans le SMP. Cette session est un point de passage majeur dans le cadre de ce plan. Il va vous permettre de comprendre l'agencement des réponses industrielles apportées aux besoins de la production afin de vous permettre, avec d'autres formations suivants le cas, de mettre en œuvre les solutions apportées. NB : l'illustration représente la boucle PDCA en japonais (Plan Do Ceck Action)

Les 5 référentiels majeurs d'un projet
CONTRAT Vision externe 1 Référentiel des exigences Référentiel des processus du projet PQP 3 Référentiel Atos Origin PROJET Référentiel des tests PPP Vision interne 4 2 Référentiel de composants (g. de conf.) A titre de rappel Au niveau conceptuel, ce schéma fait apparaître les différents référentiels entre lesquels un projet évolue : bien sûr d'abord le contrat : il fixe avec le client les caractéristiques du projet (attention la cardinalité contrat/projet n'est pas toujours 1 pour 1) le référentiel des processus mis en œuvre par le projet. Il s'appuie sur le référentiel SIROCO du site, « instancié » pour le projet à travers : le PQP en général visible, voire approuvé, par le client le PPP interne, qui positionne les processus du projet par rapport aux standards applicables (mais sans reformuler ces standards) le référentiel des exigences qui matérialise les attendus précis de la solution convenue avec le client (domaine gestion des exigences) le référentiel des tests qui matérialise les contrôles de la solution et est donc couplé avec le précédent référentiel le référentiel des composants qui matérialise la solution elle-même (domaine gestion de configuration) Le dossier électronique du projet (également appelé dossier d'affaire) qui stocke les autres données du projet. Dossier électronique du projet 5

Les procédés Industriels : focus sur QW2 et Pack 1
Délocalisations MANAGEMENT Bureau d’études Pilotage des avant-vente Pilotage contrat et projet Maîtrise des risques Gestion des partenaires des procédés du métier Gestion et amélioration Pack 1 QW3 REALISATION Maîtrise des estimations Maîtrise des exigences Maîtrise des changements Réalisation et Tests unitaires Maintenance Intégration et Validation interne QW6 QW5 QW4 Pack 1 SUPPORT Gestion de configuration Toutes les pratiques projet sont adressées par le vaste programe d’amélioration de l’Industrialisation de la Production du logiciel. Les procédés industriels passent par une totale maîtrise du métier et de la technologie, d'où le rôle du Bureau d'Etudes dans la gestion et l'amélioration des solutions Les process opérationnels sont aidés par des process de management et de support. Dans le cadre du programme d’Industrialisation, il y a 6 QW (Qwick Wins) + D2I/J2EE. Et 3 Packs qui accompagnent les QW en étant moins prioritaires et/ou plus complexes à déployer : Pack1 = Revue par les Pairs, Chiffrage-Productivité, Outils de Réalisation J2EE Pack2 = Outil Portail projets, Offres SOA / EAI / SAP / portail Pack3 = PGI intégré, Offre ECM Un zoom est fait ici sur les procédés contribuant à manager la qualité des projets soit : l'organisation Bureau d'Etude (boucles d'amélioration) la qualité les revues (revues par les pairs mais aussi revues de phase) Métrologie Revue par les pairs Gestion de la documentation Formation Infrastructure et sécurité QW2 Qualité

Table des matières Manager la Qualité des projets (QW2) Organisation de l’industrialisation Les fondements de la qualité projet Plan Qualité Projet et Plan Production Projet Revues de fin de phase Revues par les pairs (Pack1) Boucle d’amélioration

L’organisation DTO type
Winning 2008 RQD Risk Management Direction Technique Déploiement industrialisation Bureau d’Etudes Une organisation type a été définie pour la Direction Technique et Opérations de chaque Division DTO = Direction Technique et Opérations RQD = Responsable Qualité Division Ces organisations ont été déclinées localement dans chaque Division

Le Directeur Technique et des Opérations
Fonction « Bureau d’Étude » du DTO DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD Il est le garant de l’usage par les CP des bons modèles, pratiques et outillage de production distribuée des projets et TMA, et ce dès la phase l’avant-vente Il coordonne la réponse technique, s’engage et la signe A cette fin, il met en place et dirige le Bureau d’Etudes de la division, composé de champions (procédés et outils) et d’experts. Le BE s'approprie le contenu des packages d’industrialisation mis à disposition par la DTO de la Branche et réalise les instanciations spécifiques locales et/ou projets de ces packages selon des critères définis Il revoit et valide les modèles et outillages de production des Business Solutions verticales de la division Il fixe des objectifs de déploiement des packages et outils aux CP et en assure le suivi (sur projets nouveaux et récurrents après gap analysis) Il fixe des objectifs de délocalisation et d’ingénierie distribuée aux CP et s’assure de l’exécution du plan de délocalisation par les CP Établissement du plan (business plan + pilotes + plan opérationnel) Animation et pilotage Identification des ressources impactées Lien privilégié avec les CDS Il fixe les objectifs d’amélioration de la productivité globale de la division et en assure le suivi avec les CP Garant des best practices (modèles, outillage, production en CdS ou Off-shore, …) des CP/DP Coordonne les réponses techniques, s’engage et les signe Fixe et assure le suivi de l’amélioration de la productivité Fixe les objectifs de délocalisation CDS (et Off-shore) et assure le suivi de l’exécution du plan

Fonction « Opérations » du DTO DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD Il s’assure de la mise en œuvre par les CP des dispositions de gestion des risques de la division Il participe aux RMA des projets Il s’assure de la non-dérive des projets Il intervient ou fait intervenir les experts autant que de besoin en préventif afin d’éviter que les dérives se produisent et en curatif afin de rétablir l’équilibre des projets et TMA Il s’assure de la mise en place les revues de conception et les revues par les pairs Si nécessaire, il peut prendre la main sur la direction de programme en lieu et place d’un CP Il doit se prononcer sur la qualité de l’équipe projet (DP, architecte) et peut opposer son veto Il supporte les CP dans la recherche d’avenants en frontal client et en back-office Il organise avec les Compétence Managers le plan de formation des équipes projets (DP, architectes,…) S’assure de la mise en place de la gestion de risque sur les projets Participe aux RMA projets et réunions de suivi de production avec les Engagement managers S’assure de la non-dérive des projets Supporte les CP/DP dans les négociations d’avenants Organise les plans de formation des équipes projets

Key Performance (indicateurs spécifiques) DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD Operating Margin Division Gains de productivité Taux de délocalisation des projets & TMA Déploiement des procédés & des outils Instances & Gouvernance Le DTO est membre Codiv et du SIRIUS Il est membre du Comité de déploiement mensuel de la Branche (chair P. Cogoluègnes) Il est membre du Comité Opérationnel mensuel de la Branche (COMOP) (Chair C. Aulagnon) Les objectifs fixés au DTO permettent de bien comprendre son rôle majeur dans l'organisation : la marge de la Division les gains de productivité la maîtrise des délocalisations conformément au plan le déploiement des solutions procédés et outils

Déploiement industrialisation
La mission du RQD L'assistance au DTO en matière de qualité Le déploiement des processus La coordination des RQ des unités opérationnelles auprès de sa Division La participation à la surveillance des processus par le reporting mensuel à DAQ des indicateurs qualité, en particulier des indicateurs Rainbow (ROV) La participation au management des risques par la remontée des alertes en temps réel et l’établissement du rapport mensuel de Suivi des Risques Majeurs (SRM) La surveillance de la validité des instanciations locales et des nouveaux chantiers d’amélioration réalisés par le BE au regard des certifications de la branche L’assistance aux opérationnels dans le traitement des réclamations, le recueil des félicitations client ainsi qu’en matière de formation et de supervision des projets DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD La connaissance de l'approche qualité des marchés de la division L'accompagnement des projets lors des audits client Le conseil pour l'affectation des IQ sur les avant ventes et les projets de la Division Les formations/information qualité des collaborateurs La validation préliminaire des compléments de référentiel de la Division L'animation de l'équipe des RQ et IQ de la Division Le Responsable Qualité Division conserve son rôle "traditionnel", mais avec quelques points nouveaux ou renforcés : suivi des chantiers d'amélioration suivi des instanciations locales validation des compléments de référentiel de la Division

Direction Technique & Risk Management
Apporte son expérience sur les solutions dès l’avant-vente et s’assure des revues nécessaires Participe à la détection et au traitement des risques Intervient directement sur les projets si besoin est Escalade des Clients Partners sur situations difficiles Participe au pilotage des chantiers d'amélioration Assiste le staffing coordinator sur l’identification des ressources clés technologiques Peut être responsable du bureau d’études DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD C'est donc à la fois en avant-vente et en production que s'exerce la responsabilité de la Direction technique et des risques Il représente dans la Division, la plus haute aurorité sur ces deux domaines

Ce rôle comprend : Le déploiement des procédés Le suivi des indicateurs (dont la productivité) Le déploiement de la délocalisation La constitution des retours d’expérience & des bilans des projets DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD Déploiement industrialisation La notion de déploiement industrialisation s'explique par la nécessité de déployer rapidement un volume importants d'acquis du programme SIROCO. Il faut donc bien distinguer : le gros effort initial de déploiement de la maintenance future, moins intense mais couvrant cependant des activités de soutien des activités correctives des évolutions plus ou moins importantes

Bureau d’Études Composé de champions (procédés et outils) et d’experts. Le BE s'approprie le contenu des packages d’industrialisation mis à disposition par la DTO nationale et réalise les instanciations spécifiques locales et/ou projets de ces packages selon des critères définis par le DT Rappel rôle du champion : Est le « référent » du site pour le procédé considéré Support et formateur local du procédé Participe activement à la communauté nationale de pairs du procédé considéré et à la boucle d’amélioration locale Participe si nécessaire à la réalisation de ces packages Définit et met en place des outils Définit, diffuse et améliore les abaques, UO et tableaux de bord Est impliqué dans les avant-ventes DTO Risk Management Dir. Technique Déploiement industrialisation Bureau d’études RQD Son responsable est le responsable local des procédés : Responsable local de l'usage des procédés et du support associé Gère le référentiel local Responsable de la boucle d’amélioration locale en liaison avec l’ensemble des champions du site Participe activement à la boucle d'amélioration nationale Le responsable du BE est le responsable local des procédés de fabrication : méthodologie, méthodes, outillages, guides… Il s'appuie sur des champions par procédé qui peuvent être : soit des personnes du BE soit des opérationnels partageant leur temps entre leur(s) projet(s) et l'activité de champion Par rapport au concept et à la terminologie du modèle CMMI, le BE est la matérialisation dans notre organisation de l'EPG (Engineering Process Group : groupe d'ingénierie des processus)

Responsable d’un procédé
Rôles nationaux Responsable d’un procédé Est le référent national pour le procédé considéré Est responsable de la boucle d’amélioration d’un procédé en liaison avec l’ensemble des champions du procédé considéré Anime la communauté de pairs du procédé considéré Participe à la définition du budget annuel associé DTO National Est responsable de tous les procédés & de leur stratégie de maintenance Est responsable du procédé d’amélioration en liaison avec les responsables des procédés et les responsables locaux des procédés Réalise des visites de sites régulières Élabore & gère le budget annuel des procédés Un responsable national de procédé est le véritable "propiétaire" du procédé considéré et des ressources associées publiées dans le référentiel SMP. Il a autorité sur le procédé. Il est au cœur de la boucle d'amélioration nationale et anime la communauté des champions du procédé La fonction de DTO national est en cours de mise en place.

Responsabilités nationales
Procédé (ou domaine) Responsable Back-up Pilotage de contrat T. Cagnin Pilotage de projet M. Doss Estimation de projet H. Quentrec Exigences & traçabilité F. Magliozzi Tests et recette V. Santy M. Grandouiller Gestion de la configuration & de la documentation G. Mitaut Métrologie & reporting C. Yazigi Maîtrise des partenaires T. Lallemand D. Moulin Manager la qualité des projets MJ. Martin Procédé (ou domaine) Responsable Back-up Manager la boucle d’amélioration T. Cagnin Ingénierie & cycle de vie d’un projet M. Doss Complément d’ingénierie TMA T. Lallemand Complément d’ingénierie TRA M. Bédouani Complément d’ingénierie D2I JL. Clément Complément d’ingénierie SAP C. Lehmann Complément d’ingénierie EAI/BMP Complément d’ingénierie Portail Complément d’ingénierie SOA La mise en place de ces responsables nationaux est effective, mais doit encore trouver ses marques définitives (c'est un mode de fonctionnement nouveau qui n'existait pas sous cette forme dans le SMP). Sans être une révolution, cette évolution n'est pas forcément naturelle auprès d'équipes ou de sites qui avaient une forte tenadance à solutionner par eux-mêmes leurs besoins, multipliant ainsi les solutuions différentes. La réactivité des responsable nationaux est un enjeu majeur pour jouer pleinement leur rôle

Relations locales & nationales
DTO Nationale Profils opérationnels Responsabilités centrales Responsable procédé X Site Y DTO Profils opérationnels On voit ici les différents rôles introduits avec la démarche d'industrialisation. Ils s'ajoutent aux rôles déjà existants dans l'organisation Le niveau national de Direction SIROCO s'est d'abord matérialisé par un Directeur de Projet d'amélioration SIROCO. Son évolution l'amène à devenir une structure permanente dans le cadre de l'industrialisation. D'autres projets d'amélioration pourront nécessiter que soit mis en place de façon temporaire un ou des Directeurs de Projet d'amélioration Pour chaque procédé, un responsable de niveau national est nommé qui fait autorité sur le procédé considéré Le niveau local -en complément du rôle qualité déjà en place- s'organise avec : un responsable local des procédés (qui est le responsable du BE) : c'est lui qui porte la responsabilité de la gestion, de l'usage et de l'amélioration des processus à l'échelle de son périmètre des champions qui sont spécialisés par procédé, donc en relation avec le responsable national correspondant Remarque : il ne faut pas confondre rôle et individu : un individu peut tenir plusieurs rôles (un rôle n'est pas forcément un temps plein). Responsabilités locales Champion Procédé X Responsable Assurance Qualité Responsable BE

Manager la qualité des projets
Le Responsible Qualité du projet a une visibilité permanente sur les dispositions prises sur la qualité du projet. 1 + 2 = au début du projet. 3 + 4 = pendant le projet jusqu’à la fin. 5 = en permanence.

Principes de pilotage : domaines d’activité projet
GERER LA RELATION CLIENT gestion contractuelle reporting CONDUIRE LE PROJET maîtrise : TECHNIQUE Activités de conception Activités de réalisation Tests et essais Livraison installation Méthodes de travail Gestion de configuration Gestion de la documentation Accompagnement au changement PROCESSUS Phases Organisation Planification Suivi d’avancement Suivi des coûts Suivi des fournisseurs Gestion des modifications Projections et prévisions Reporting QUALITÉ Définition des exigences Plan Qualité Projet Plan Production Projet Actions qualité Actions correctives Actions préventives ANTICIPATION ET GESTION DES RISQUES Identification Estimation Impacts Plans d’action Contrôle Le CP doit piloter le projet, c’est à dire les aspects suivants : La Technique Les Processus du projet La Qualité. La Gestion des risques Il pilote mais ne produit pas ! Pour maîtriser la Qualité, il s’appuie sur l’ingénieur Qualité. Il existe des exigences sur les processus : Plans Qualité (PQP et PPP) et Revues (de phase et par les pairs). Exigences et Risques sont des thèmes abordés dans d’autres modules.

Principes de pilotage RÉFÉRENTIEL RÉSULTATS PRÉPARER EXÉCUTER
CONTRÔLER contrôler : - les résultats - les écarts prendre les dispositions correctives définir : - l’ouvrage - l’œuvre - l’organisation les méthodes le mode de pilotage avec les partenaires et les clients - les dispositions d’assurance qualité et de gestion des risques coordonner : - les actions - les acteurs suivre la production Le référentiel = Système de Management Atos Origin Integration instancié sur la Division où se trouve le projet et le référentiel projet PREPARER Définir l’ouvrage = le « quoi » L’œuvre = le « comment »  PQP, PPP, tableau de suivi des revues Valider l’organisation et les ressources Définir le planning CONTRÔLER Quand il y a des écarts, mettre en place des plans d’action et les suivre  PAMPA, RADAR Compte tenu de ce schéma, l'ingénieur qualité est là pour : aider à la préparation (PQP et PPP) soutenir la mise en place vérifier le respect des dispositions prévues (en particulier en participant à certaines revues)

Audits et revues : les 6 familles
Mon collègue n'a-t-il pas fait (sur le fond) des Revue par les pairs (peer reviews) 1 erreurs visibles par un simple examen ? La production est-elle conforme à ce qu'on en Revue de fin de phase 2 attend à ce stade ? Revue Mensuelle d'Avancement (RMA) Fait-on le maximum pour la réussite 3 du projet (risque, planification, finance…) ? Est-on conforme aux plans préalablement Revue/audit d'assurance qualité 4 établis, notamment en matière de contrôles ? La façon de faire est-elle efficace (au sens le Permettre de bien comprendre les différents types de revues et d'audits, tel est le but de la question mise en regard de chaque type de revue ou audit Une revue par les pairs est une revue de CONTENU. Une revue d’Assurance Qualité est conforme au SMP et inclut le POINT QUALITE. Revue de processus 5 plus large du terme) ? Etapes de validation dans le processus avant- Revue de proposition (RAINBOW) 6 vente (pursuit, strategy, solution, offer, contract)

Audits et revues : Liste
Couvert par la formation INDUS5 Fixé par SMP et note d'organisation de l'entité On indique ici les différents types de revue et l'orogine des règles qui s'y appliquent Fixé par le SMP INDUS5 (boucle d’amélioration) RAINBOW + compléments éventuels

Principes de pilotage : points de contrôle
Revue(s) de proposition Spécification Conception Réalisation Intégration & validation interne Recette client Mise en exploitation Lancement Clôture Revue(s) d’exigences Revue(s) de conception Revue(s) de plans de tests Revues(s) de code Revue(s) de gestion de configuration Revues(s) de documents Check-list de fin de phase de conception Check-list de lancement de projet Check-list de planning Revue de fin de phase Check-list de fin de phase d’intégration Le positionnement des revues est illustré sur un modèle en « cascade ». Il peut se transposer sur un modèle de cycle en « V », un cycle « itératif », ou un cycle « incrémental ». L’objectif est de fournir au client des produits sans défaut. On ne s’intéresse pas ici aux charges et aux jalons. Dans le cas type : Il y a 4 types de revues de fin de phase. Il y a 7 types de revues par les pairs. Chacune s’accompagne de Check-List pour aider. Elles doivent être prévues … et planifiées. On verra plus loin lesquelles sont obligatoires La gestion de configuration, dont les revues peuvent intervenir à partir de la phase réalisation, concerne non seulement le logiciel mais aussi la documentation.

Positions du PPP et du PQP
SMP (incluant toutes les extensions SIROCO) Complé- ment local Référentiel Client Les standards C H O I X / D E C I S I O N ACTEURS INTERNES Modèle de PPP PPP du projet Accord Le processus général d'élaboration du PQP et du PPP est illustré avec : les standards applicables (niveaux général+SIROCO+local) des choix et décisions projets réfléchis et argumentés (liés au contrat, au client, à la technologie utilisée….) un PPP (dérivé d'un modèle) qui formalise ces choix et décisions relatifs aux processus et procédés que va appliquer le projet un PQP (dérivé d'un modèle) qui de façon beaucoup plus rédigée, décrit les processus eux-mêmes, du moins avec un niveau suffisant pour permettre une bonne communication avec le client. PQP : document qui va chez le client. Le PQP est vérifié et approuvé en interne selon les règles fixées dans le SMP. PPP : document qui reste interne. Le PPP -dans tous les cas- n'est soumis qu'à un circuit interne de validation et a été conçu pour être disponible beaucoup plus tôt que le PQP. Modèle de PQP PQP du projet CLIENT Accord

Le Plan Qualité Projet (PQP)
Les plans utilisés sont : Le Plan Qualité Projet, le Plan de Production Projet Le plan de gestion de configuration Le plan de tests Le cas échéant complété par un Plan de Développement, un plan de gestion des exigences, un plan de gestion documentaire… Un plan qualité cela contient : Qui ? L’Organisation, les instances de pilotage et différentes responsabilités Quoi ? Les exigences qualités, le périmètre et les résultats à produire Comment ? Le découpage du projet, les méthodes, processus et outils, les contrôles des produits et les dispositions d’AQ Quand ? Le planning des étapes Où ? Les lieux d’exécution Voir surtout la partie « Suivi de l’application du PQP », $12 dans le modèle PQP. Il aborde les sujets Contrôles, Audits et Indicateurs. Attention : les indicateurs sont obsolètes.

Visite du Plan Qualité Projet standard
dispositions Visite de MD SM-6-A2-PQP

Rôle du PQP vis à vis du client
Le PQP constitue, en cohérence avec le PPP, le référentiel des processus/procédés du projet, pour besoins internes mais avec visibilité du client Dans la relation client, différents cas de figure : Demande client d'élaboration d'un projet de PQP dès la phase avant-vente (parfois modèle imposé par le client); PQP considéré comme un livrable au titre du contrat, et devant recevoir l'approbation formelle du client; PQP non considéré comme un livrable, mais présentant un intérêt pour le client qui l'examine et, le cas échéant, y fait apporter des retouches afin d'aboutir à son acceptation. PQP n'intéressant pas le client. Position de Atos Origin : Accepter la "vision" client; Réaliser dans tous les cas un PQP (sauf si la taille du projet est trop faible) qui, le cas échéant, restera un document interne; Réaliser ce PQP sur la base des standards Atos Origin. Le PQP contient la description validée des dispositions suivies par le projet en matière de processus et d'assurance qualité. Le rôle du client dans ce processus d'élaboration puis de suivi du PQP dépend du contrat et/ou de la volonté client. Atos Origin accepte de fonctionner dans le mode qui convient au client, du désintérêt total du client, au cas où le client impose le plan -et largement le contenu- du plan qualité du projet. En résumé, PQP = autonome, rédigé, orienté client

Plan de Production Projet (1/2)
Le PPP : une solution simple et adaptée par projet . Est le point d'entrée dans le projet pour l'aspect processus . Tient sur quelques pages . Réalisation très rapide dès début projet . Tire profit de la notion de standard . Constitue l'instanciation des standards . Pointe vers documents spécifiques si nécessaire . Vertu pédagogique : pour chaque point il rappelle le standard . Permet justification brève des choix du projet Le Plan de Production Projet (PPP) est un document interne court -quelques pages- établi en tout début de projet. Il a pour but de fixer et de justifier les choix et décisions du projet par rapport à l'organisation, aux processus, procédés, outils… qui vont être appliqués par le projet. La démarche d'industrialisation impose que chaque projet applique les processus de l'organisation. Mais un processus peut avoir des variantes (suivant la typologie ou la taille du projet par exemple), peut ne pas être totalement applicable en raison de telle ou telle attente client, peut nécessiter des adaptations… L'image qu'on pourrait prendre est que pour préparer le projet on ne part pas d'une feuille blanche mais d'une feuille avec les solutions de la maison. Mais bien sûr il faut instancier et éventuellement adapter ces solutions au contexte du projet et aux exigences du client. Et il ne faut pas inventer une solution projet pour le simple plaisir, mais il faut justifier les adaptations. D'où le PPP qui rappelle les solutions standard, et invite à formuler les solutions retenues par le projet et à justifier les adaptations.

Plan de Production Projet (2/2)
Fixe cadre du projet catégorie, acteurs et rôles, livrables, calendrier,… Fixe les processus adoptés standards appliqués ou particularités justifiées Fait les choix projet (instanciation des standards) taux de relecture, revues pratiquées, cadence des réunions, phases couvertes,… Pointe vers documents spécifiques nécessaires document client, note technique, CR de réunion, plan de gestion de configuration du projet,… Le concept du PPP -et en ce sens il se différencie fortement du PQP- est de ne pas reformuler les standards. Ils sont écrits, on peut s'y référer, mais cela n'apporte rien de les reformuler. Dans le PQP à l'inverse, le besoin pour le client d'avoir un document autoporteur impose la re-description au moins partielle du standard. D'où le volume important des PQP qui mixent des description standards et des spécificités du projet. Voir en particulier la partie qui traite du « Management de la Qualité ». Attention : les revues par les pairs sont cités dans les items concernés. Réponse à la question de la redondance entre PQP et PPP : Oui, il y a redondance mais : le PQP va chez le client donc subit des contraintes : de transparence (qui ne peut être totale) de rédaction complète et autoporteuse et in fine de d'élai d'élaboration et de validation le PPP est interne : pas de contrainte de transparence non rédigé car fait la référence au standard production peut être très rapide

Une idée concrète du PPP
Les # rubriques à renseigner (ordre de 120) Justification écrite si hors standard Le standard est rappelé (intérêt pédagogique) On précise si c'est : . le standard . la demande client . le choix du projet Visite du PPP (MD-3-01-SM-1187-A-PPP) La justification des choix du projet dans le PPP est décrite par : une indication globale de la raison du choix : on applique tout simplement le standard, on prend en compte la demande client, ou on a fait un choix projet justifié une justification en cas de choix projet. Il s'agit d'une justification brève qui doit logiquement tenir en quelques mots ou une ou deux phrases. Le but est : de garantir qu'on s'est posé la question du choix par rapport au standard de conserver la trace de la justification du choix particulier ou de la variante adoptée. Pour faciliter l'utilisation, et pour des raisons pédagogiques évidentes, pour chacune des rubriques, le choix standard est brièvement rappelé dans une colonne du PPP.

Contenu du PPP QW6 QW3 QW4 QW1 QW5 QW2
Il y a environ un dizaine de thèmes qui adressent 120 rubriques à renseigner. QW2

Revue(s) de proposition Spécification Conception Réalisation Intégration & validation interne Recette client Mise en exploitation Lancement Clôture Revue(s) d’exigences Revue(s) de conception Revue(s) de plans de tests Revues(s) de code Revue(s) de gestion de configuration Revues(s) de documents Check-list de fin de phase de conception Check-list de lancement de projet Check-list de planning Revue de fin de phase Check-list de fin de phase d’intégration Les revues de fin de phase sont internes. Mais dans certains cas, elles peuvent être -en tout ou partie- partagées avec le Client Dans ce cas, il peut aussi prendre une part de responsabilité pour le passage à la phase suivante. En particulier, le Clent peut avoir des exigences lors de la livraison : revue de fin de phase de validation qui peut par exemple prendre la forme d'une réunion de livraison Contrôles internes sur le processus

Contrôles internes de fin de phase
Les revues de fin de phase ne portent pas sur le contenu du produit vérifient qu'au stade atteint, processus et production de la phase sont conformes à ce qui était prévu permettent de prendre les dispositions correctives et préventives adaptées (paln d'action RADAR) Une revue peut utiliser une check-list d'auto-contrôle. Une revue laisse une trace (CR, check-list, …) Un revue n’impose pas systématiquement une réunion. La revue est prévue dans le PQP ( $ Contrôles sur le Processus et le PPP (cycle de vie et Management de la Qualité). Pour les revues de phase, conformément aux objectifs rappelés, le SMP met à disposition une check-list générique NB : SIROCO n'a pas produit de valeur ajoutée sur ce point Une évolution –ou un complément- avec des check-list propres aux attendus de chaque phase est prévisible (pas d'échéance fixée à ce jour)

Objectifs de la revue de fin de phase
Dresser l'état de la situation du projet et du produit (=livrables production) en fin de phase, et par rapport à ce qui était prévu Examiner si les éléments essentiels pour démarrer la phase suivante sont disponibles. Qualifier les éléments clés permettant de décider le passage en phase suivante. Donner une préconisation pour la décision de GO/No GO et définir le plan d'action permettant d'atteindre les objectifs définis. Autre formulation simple L'objectif de la revue de fin de phase est de : s'assurer qu'on été validés les productions techniques, définir le plan d'action sur les questions non résolues  PAMPA, RADAR Chaque phase peut donner lieu à une revue de fin de phase, conformément à ce qui est prévu au PQP/PPP La revue fait l'objet d'un compte rendu (ou d'une autre forme de trace comme une check-list renseignée)

Liste de questions génériques (1/2)
Extrait de la Check-List SMP

Liste de questions génériques (2/2)
Extrait de la Check-List SMP

Qu'est-ce qu'une revues par les pairs ?
Définition Une recherche des défauts dans la production d'un projet (conception, document, code,…) Menée par une ou plusieurs personnes techniques qualifiées et impartiales En coopération avec l’équipe projet Où au moins un des vérificateurs n’a aucun lien hiérarchique avec l’auteur du produit Principales Solutions Check-lists Relectures de documents Relecture de code Objectif : découvrir au plus tôt des défauts dans ce qui a été produit Moyen : examen par personne(s) capable de comprendre le fond (d'où la notion de "pair" c'est-à-dire collègue). Membre équipe projet ou non Organisation : formalisme minimum doit donner visibilité des défauts trouvés Important : c’est le produit qui est analysé … pas l’auteur …qui est jugé Les "pairs" sont des personnes ayant une compétence équivalente à l'auteur du produit pour évaluer le fond Un pair devrait être sans lien hiérarchique avec l’auteur puisqu’il est son pair. Néanmoins, dans une petite structure de projet, il est possible qu’un acteur joue plusieurs rôles dont l’un soit équivalent à celui de l’auteur et l’autre le place dans une situation de dépendance hiérarchique (dans un sens ou dans l’autre) vis à vis de l’auteur.

Revue(s) de proposition Check-list de lancement de projet Check-list de planning Revue de fin de phase Lancement Revue(s) d’exigences Revue de fin de phase Spécification Revue(s) de conception Check-list de fin de phase de conception Revue de fin de phase Conception Revues(s) de code Revue de fin de phase Réalisation Revue(s) de plans de tests Check-list de fin de phase d’intégration Intégration & validation interne Revues(s) de documents Les revues par les pairs portent sur différents thèmes et produits/livrables selon la phase du projet. (Pour un projet particulier, il peut y avoir des revues de migration par exemple.) Elles permettent de mettre en évidence des défauts et donc de les corriger au plus tôt Elles sont purement internes à Atos Origin (mais des cas particuliers peuvent parfois exister suivant les contrats) Recette client Revue(s) de gestion de configuration Mise en exploitation Contrôles internes sur le produit Clôture

Les revues sont efficaces dans la recherche d’erreurs
Importance des revues ? Les revues sont efficaces dans la recherche d’erreurs Exemples de faits constatés: Une heure de revue pour trouver un défaut majeur, contre 15h à 20h en tests d’intégration pour trouver le même défaut. 62 % des défauts trouvés en revue, après déploiement du procédé, contre 10% en début de déploiement. Réduction de 50 % des coûts totaux : pour un coût de revue représentant 0,4 % du temps total du projet. Le coût investi en revues est récupéré sur les coûts de réalisation et de maintenance. Le temps économisé en ne faisant pas de revue d’exigences ou spécification et de conception va coûter 3 à 4 fois plus en fin de développement. Le temps nécessaire pour trouver un défaut après livraison est beaucoup plus important que s’il était trouvé (en revue) là où le défaut a été introduit.

Thèmes et outils NB : la revue de livraison ne figure pas dans la liste du fait qu'il s'agit d'une revue de fin de phase : vérification de ce que processus et les contrôles ont été respectés

Les revues par les pairs : ressources
Outils pour la relecture de code Outils pour la revue de document Ressources Standard Le procédé de revue par les pairs Guide Guide de revue de document Guide de revue de code Présentation Support de formation revue par les pairs Modèle FRD (Fiche de Revue de Document) FRC (Fiche de Revue de Code) Check-list d'aide à la revue de proposition Check-list d'aide à la revue des exigences / spécification Check-list d'aide à la revue de conception Check-list d'aide à la revue de plan de tests Check-list d'aide à la revue de gestion de configuration Tableau de suvi des revues par les pairs Visiter le Tableau_de_Suivi_des_Revues_Par_Les_Pairs_-_MD SM-0401 (les autres ressources seront présentées dans la suite au fil de l'eau) Plan d’actions Sert aussi de CR

Pilotage des revues par les pairs
Les revues par les pairs font partie intégrante du pilotage et des contrôles du projet. Elles participent à sa maitrise technique et économique. Planning du projet Ce sont des tâches intégrées au planning du projet et gérées en tant que telles Plan qualité projet Les revues par les pairs sont prévues dans le PQP et le PPP 4 Activités Planifier les revues En type et nombre à l’initialisation du projet En dates, au fur et à mesure du projet Préparer les revues Désigner le responsable de la revue Sélectionner les produits revus et initialiser l’outil Conduire la revue Effectuer la revue et synthétiser les résultats La réunion de revue Clôturer la revue Mettre à jour les produits revus Gérer les actions Consolider les statistiques Planning : cela signifie que les tâches de revues par les pairs doivent être gérées comme les autres PQP : ATTENTION les revues par les pairs ne sont pas mentionnées explicitement dans le PQP type (mais elles le sont dans le PPP)

-1- Revue de proposition
Objectifs Vérifier si les engagements proposés sont adaptés et réalisables Quand En cours de rédaction de la proposition Revue RAINBOW – Avant vente Les revues Rainbow sont des revues de décision : ce ne sont pas des revues de contenu comme celles qui nous occupent ici. En revaénche la revue par les pairs de proposition vérifie bien le contenu en terme de description de la solution : architecture, maîtrise en particulier. Elle peut se faire au niveau des étapes 3 et 4 du processus Rainbow. Visiter CR_de_Revue_de_Proposition_-_MD SM-0402 Voulons-nous faire une offre ? Avons-nous une bonne stratégie pour faire une offre gagnante ? Notre solution, dans ces conditions financières, est-elle gagnante? Avons-nous une offre gagnante ? Le contrat esy-il acceptable ?

- 2 - Revue d’exigences ou spécification
Objectifs Vérifier la conformité de la couverture des exigences contractuelles et de la traçabilité associée Quand De la spécification à la validation Documents Client Traçabilité de couverture Exigences client Traçabilité des exigences client Tests de validation Documents de tests de validation Spécifications Exigences de référence Traçabilité des exigences allouées aux composants Rappel : les exigences sont la formulation des attendus de la solution informatique (fonctionnels et non fonctionnels), explicitement convenus entre le demandeur et le fournisseur. Le plus souvent elles se matérialisent par des spécifications soumises à approbation du client La revue des exigences ou spécifications permet de s'assurer –en général avant remise au client- que les exigences qui ont été déclinées finement à partir des documents d'entrée (cahiers des charges, CCTP ou autres) ne comportent pas de défaut décelable. Elles sont cohérentes, complètes, claires, … et permettent d'aborder dans de bonnes conditions la phase suivante Cette revue peut avoir lieu au-delà de la fin de la phase de spécification. Dans ce cas, il n’y a pas de revue formelle. Visiter CR_de_Revue_Exigences_et_Specifications_-_MD SM-0403 Documents de tests unitaires Exigences de conceptionComposants Conception Traçabilité de couverture Tests unitaires Traçabilité de couverture CodeRéalisation

- 3- Revue de conception Objectifs
Vérifier la qualité de la conception produite (architecture) Vérifier l’aptitude à satisfaire les exigences fonctionnelles et techniques Quand Après la conception de la solution technique et fonctionnelle La revue de conception est une revue majeure dans la mesure où elle vérifie les choix d'architecture et de conception qui sont déterminants pour le projet. C'est pourquoi elle est obligatoire pour les nouveaux projets. Pour les maintenances et pour les versions N+1 d'une application existante la question est ouverte. Une revue de conception peut être nécessaire en cas d'évolutions majeures. Elle peut être inutile en cas de regroupements d'évolutions plus mineures. C'est au niveau du PPP que le choix de faire une revue de conception ou de ne pas en faire doit être fait. Et il faut alors s'y tenir. Visiter : Guide_de_Revue_de_Conception_-_GU SM-3 CR_de_Revue_de_Conception_-_MD SM-0404

-4- Revue de plan de tests
Objectifs Vérifier que la stratégie, l’ensemble des outils, les jeux de test prévus et les moyens pour les phases d'intégration et de recette permettent bien de vérifier la satisfaction des exigences fonctionnelles et techniques. Quand Lorsque ces tests sont suffisamment définis Visiter CR_de_Revue_de_Plan_de_Tests_-_MD SM-0405

-5- Revue de document et FRD
Objectifs Vérifier le contenu d'un document (fond) Quand En principe lorsque le document est complet (forme et fond) Dans la pratique, peut porter sur des sous-ensembles avec cohérence et complétude suffisante Si la rédaction d'un document important est longue, une lecture à mi-parcours peut éviter l'effet "tunnel" et bien recadrer les objectifs du document Objectifs : Il s’agit bien de vérifier le contenu du document revu en termes : d'adaptation au besoin auquel il répond de couverture du périmètre attendu de qualités intrinsèques (cohérence, complétude, clarté, etc.) La FRD = Fiche de Revue de Document est le support prévu. S'agissant de document, on peut d'ailleurs parler de relecture (la revue se ramène de fait à une relecture) Visiter : la FRD Fiche_de_Revue_de_Document_-_FRD_-_MD SM-0406 ATTENTION : tout document soumis à revue doit avoir un niveau de qualité suffisant sur les aspects de forme (pour ne pas émousser l'attention du lecteur qui doit travailler sur le fond)

Pourquoi relire les documents ?
L'objectif des relectures de documents (autres que les relectures personnelles de l'auteur) est de mettre en évidence, afin de les corriger, des DEFAUTS qui, s'ils n'étaient corrigés à ce stade, auraient toute chance d'avoir des conséquences négatives plus lourdes ultérieurement. Le relecteur doit comprendre le fond (revue par les pairs) Traces demandées pour les défauts significatifs Visiter le guide Guide_de_Revue_de_Document_-_GU SM-0412 Pas de traces individuelles demandées pour les imperfections mineures (orthographe, présentation, style,…)

Les 7 péchés capitaux … d'un document Bruit - bavardage inutile sans apport d’information. Silence - sous spécification. Sur spécification - spécification d’une même exigence à plusieurs endroits du document. Contradiction / Incohérence - La rédaction comporte des contradictions et/ou manque de cohérence sur le fond. Incompatibilité : ce qui est dit n'est pas compatible avec d'autres éléments du projet. Ambiguïté - La formulation n'est pas suffisamment soignée et pourra être interprétée différemment par différents lecteurs. Référence avant - utilisation d’un concept pas encore défini à ce niveau du document Vœux pieux - souhait irréaliste non mesurable et/ou exigences potentiellement impossibles à implémenter.

… et les autres écueils à éviter
lors de la rédaction d'un document … et les autres écueils à éviter Couverture incomplète - Le périmètre attendu n'est pas totalement couvert Inadaptation technique - Problème de faisabilité, ou qui produirait un défaut/problème ultérieurement Ne répond pas aux attentes - Ne fournit pas l'information attendue (ce qui posera problème dans la suite) Détails - L'absence d'éléments plus détaillé posera problème à l'utilisation du document ou au contraire le niveau détail atteint n'est pas nécessaire à ce document Confus - Le lecteur a besoin de faire un gros effort pour comprendre (et on n'est pas sûr de ce qui aura été compris) Schéma - Défaut important en matière de schéma : manque un schéma, schéma incorrect… Hors sujet - Développement qui n'a pas sa place dans ce document Forme/Présentation - Excès de défauts de présentation et de forme (qui perturbent le travail du relecteur) : orthographe, renvois, table des matières, présentation, etc. Style rédaction - Style de rédaction mal adapté (phrases longues, lisibilité réduite, formulation trop complexe,…) Normes - Les règles de nommage, rédaction, informations obligatoires, etc… ne sont pas respectées. Autre erreur de fond - Défaut important n'entrant pas dans une des catégories précédentes

-6- Revue de code (FRC) Objectifs Quand
Détecter au plus tôt les problèmes de fond Vérifier la conformité Effectuer des échantillonnages d’estimation de la qualité du code Quand L'objet est cohérent, complet, compilable Les documents associés sont disponibles (spec., architecture, interfaces, conception détaillée) Sur sollicitation d'un collègue - pour un avis préalable Selon les contextes, on peut envisager une revue de code avant les tests unitaires La FRC = Fiche de Revue de Code est le support prévu pour tracer les défauts décelés lors des relectures Visiter Fiche_de_Revue_de_Code_-_FRC_-_MD SM-0407 ATTENTION : Tout code soumis à revue doit avoir un niveau de qualité suffisant

Pourquoi relire le code ?
L'objectif des relectures de code (autres que les relectures personnelles de l'auteur) est de mettre en évidence, afin de les corriger, des DEFAUTS qui, s'ils n'étaient corrigés à ce stade, où s'ils étaient répétitifs dans d'autres programmes auraient toute chance d'avoir des conséquences négatives plus lourdes ultérieurement. Le relecteur doit comprendre le fond (revue par les pairs) Visiter Guide_de_Revue_de_Code_-_GU SM-0413 Travail par échantillon dans notre métier

A propos du code à relire
Recommandations sur le pourcentage de code relu 5 à 10% : valeur à considérer comme un minimum 10 à 20% : valeur à considérer comme statistiquement bien adaptée aux projets de gestion ou de TMA 30 à 50% : taux de revue important Plus de 50% : taux de revue très important justifié par des conditions particulières (profil de l'équipe, fiabilité logicielle particulièrement forte attendue…) Recommandations sur la sélection du code à relire le code à risque (critique, complexe, déterminant pour performances) le code produit par les débutants le code produit par les nouveaux entrants sur le projet des échantillons pris au hasard Faut-il relire tout le code ? Réponse : dépend du projet (criticité, risques, moyens…) à fixer donc en début de projet (PPP), par exemple sous forme de pourcentage Sélection du code à relire : c'est du simple bon sens

Deux types de relectures de code
1 Décidé (organisé) par le Chef de Projet sous le nom de revue par les pairs . dans le cadre plan de développement du projet (fixé dans PPP) . échantillons choisis selon critères comme : . code de complexité importante . production de développeurs peu expérimentés . code critique pour la solution… . traces attendues (FRC) pour voir résultat et piloter processus (et en mesurer le retour sur investissement) 2 Décidé par le développeur lui-même au fil de l'eau, en demandant au collègue sans formalisme ou trace demandé typiquement pour : vérifier qu'une solution tient la route lever un doute recueillir des idées d'amélioration voir ce qu'en pense le collégue qui a déjà fait un truc analogue… Usez et abusez, comme complément aux tests unitaires, pour garantir la qualité du code produit …. Les relectures de code sont vivement encouragées dans tous les cas. C'est un moyen de progrès important pour les collaborateurs, en plus bien sûr d'un moyen efficace de déceler des défauts ou imperfections. C'est pourquoi à la revue de code formelle (revue par les pairs) s'ajoutent les relectures plus directes entre collègues.

-7- Revue de configuration
Objectifs Vérifier l’adéquation de la démarche de gestion de configuration définie dans le plan de gestion de configuration Vérifier le bon fonctionnement de l’application des dispositions prévues dans le plan de gestion de configuration Quand De l’initialisation du projet à la fin de la garantie Lorsque les risques (d'incohérence, de perte de composants, de difficulté de maitrise des livraisons…) justifient quelques heures/journées de contrôle Visiter CR_de_Revue_de_Configuration_-_MD SM-0408

Quelles revues faut-il faire ?
TOUS les contrôles sont fortement recommandés quand le projet a une criticité importante. La revue de conception est obligatoire pour les nouveaux projets. La revue d’un document livré au Client est fortement recommandée. Un ‘nouvel arrivant’ est source de risques qui impose des revues de code. Et fixer les revues à tenir à l'avance (PPP) et s'y tenir. La politique de mise en œuvre des revues doit être guidée par l'efficacité (retour sur investissement) Aucune revue, et c'est l'assurance de trouver tardivement des problèmes et bugs sévères, coûteux à corriger, et difficiles à encaisser par le planning Des revues systématiques et par exemple des revues de tout le code produit, suivant le contexte, ce peut être trop coûteux NOS CP DOIVENT SE SENTIR RESPONSABLES de trouver le bon compromis pour chaque projet

Résumé sur la revue par les pairs
Titre : Revue par les pairs Responsable du procédé : M.J. Martin Directive Le procédé de revue par les pairs doit être appliqué sur tous les projets, quelle que soit leur typologie : projet de développement, d’évolution, d’intégration ou de maintenance, et quelle que soit leur taille. Rôles : Le directeur de projet Le responsable de la revue Les vérificateurs Les intervenants projet Le chef de projet L’ingénieur qualité Finalité Détection la plus précoce possible de défauts éventuels. Échange et capitalisation des bonnes pratiques. Indicateurs : Nombre de défauts critiques / temps total passé Éléments d'entrée Planification des revues. Produits sélectionnés qui feront l’objet de la revue. Outils utilisés : Les comptes-rendus et fiches Le tableau de suivi des revues Eléments de sortie Liste de défauts trouvés lors de la revue Actions pour résoudre les défauts détectés. Activités Planifier les revues Préparer les revues Conduire la revue Clôturer la revue

Démarche de maîtrise des procédés industriels
Un patrimoine vivant de ressources opérationnelles (dont les standards) Des acteurs avec des rôles et des ressources Appropriation Des activités de déploiement (mise en œuvre) Adapt. locales Publication Formation Mise en œuvre Soutien Contrôle Un soutien fort de la Direction (moyens, communication) Une boucle de maintenance (correctif, évolutif) 1 2 3 5 6 4 Des chantiers d'amélioration Ce schéma général illustre les concepts fondamentaux d'une démarche industrielle mature. Avec ce schéma en filigrane, on peut aborder la certification ISO 9001 et les évaluations CMMI dans une grande cohérence d'approche et de moyens. Dit autrement, non seulement il n'existe pas de contradiction entre les exigences de l'ISO 9001 et celles de notre industrialisation basée sur le modèle CMMI, mais elles s'emboîtent parfaitement avec une grande cohérence et complémentarité. La vue métier permet de présenter aux utilisateurs un référentiel unique très cohérent et conforme aux exigences des deux modèles.

Les différentes boucles d'amélioration
Champion B Champion A Responsable Procédé A Responsable Procédé B DTO National Responsable Local des Procédés Directeur du Centre Site 1 Site 2 National B1 B2 B3 Responsable référentiel central B4 Coordination des chantiers d’amélioration Quatre boucles d'amélioration distinctes sont utilisées pour faire fonctionner la machine "processus" d'Atos Origin System Integration. On entend par boucle d'amélioration, l'ensemble des mécanismes, solutions, documents… contribuant à faire vivre le patrimoine processus/procédés de l'entreprise notamment matérialisé par les référentiels. Faire vivre doit être compris au sens le plus large du terme : création initiale, déploiement (formation, migration, soutien), usage, maintenance corrective et évolutive (améliorations). B1 : localement, sur chaque site, le Responsable Local des Procédés(BE), en s'appuyant sur ses champions : fait appliquer les procédés et processus prévus anime les activités de maintenance locale B2 : chaque Responsable de Procédé, "propriétaire" du patrimoine correspondant, est chargé de sa maintenance B3 : la Direction nationale de l'industrialisation fixe et applique la stratégie de maintenance en liaison directe avec les responsables de procédés B4 : le référentiel central est maintenu (correctif, évolutif) par son responsable DAQ, en liaison avec les différentes unités organisationnelles concernées, et en particulier avec les responsables de procédé. Ce référentiel est complété dans chaque Centre par les élémetns d'instanciation et les compléments de chaque Centre

Les sources d'amélioration
Retour de mise en œuvre à l'occasion élaboration PPP et PQP en cours de projet à l'occasion des actions de soutien aux projets Autres remontées de pratiques locales (spontanées, sollicitées) Bonnes pratiques à généraliser Points qualité et audits projets Revues de procédés Analyse des CR de revues et des défauts Analyse des indicateurs et reporting (PAMPA, RADAR…) Exploitation des bilans de projets et de maintenances Retours de formation Production de groupes de travail dédiés, idées nouvelles, veille méthodologique et technologique (outil) Fixation d'objectifs de progrès (origine Direction ou client) etc. Faites connaître : toutes les difficultés rencontrées, les besoins d'amélioration, les bonnes pratiques, les adaptations que vous avez du réaliser, etc. La forme importe peu (le mail convient) Les opportunités d'améliorer les pratiques sont nombreuses. Elles doivent être saisies pour améliorer sans cesse et faire progresser le capital des processus, pratiques, méthodes et outils utilisés. Il est fondamental que chaque collaborateur participe à son niveau à cette amélioration continue. C'est pourquoi il faut faire remonter les difficultés de mise en œuvre rencontrées, les réponses mal adaptées, ou autres besoins d'évolutions, vers les responsables. C'est la condition nécessaire à un progrès réel sur le terrain. Trop souvent on rencontre des attitudes négatives consistant à ne pas faire connaître les difficultés ("leur truc ne marche pas, je me suis débrouillé dans mon coin"). Il faut constamment encourager les collaborateurs à faire connaître les difficultés rencontrées mais aussi les bonnes pratiques qui méritent d'être étendues. Et il faut bien sûr que la cellule processus soit suffisamment réactive pour prendre en compte (sinon on démotive très vite les émetteurs).

Revues de procédé : les principes
Existants SMP applicables (points qualité, audits…) Besoin d'un complément au SMP au bénéfice des procédés et processus de production Une revue de procédé permet : d'examiner si la solution prévue est comprise et appropriée par les projets, et efficace d'analyser les observations et indicateurs du procédé afin de définir des actions d'amélioration de déceler et corriger des imperfections du patrimoine (procédé, outil…) de capitaliser l'expérience de recueillir des idées et bonnes pratiques améliorées et donc de faire progresser nos solutions (standards, outils, guides,…) L'assurance qualité -avec les vérifications et revues qui vont avec- s'applique au produit (ce qui est "fabriqué") mais aussi aux processus (les procédés de fabrication). Le SMP prévoit des revues de processus sur les processus définis dans la cartographie. Cependant pour les processus "métier", c'est à dire du domaine 11 (11.02 à 11.04), il est nécessaire que ces processus soient décomposés en activités appelées procédés, et que ces activités fassent l'objet de revues équivalentes. Il faut en effet considérer que les procédés sont des ressources à part entière, orthogonales aux projets, et qu'elles doivent avoir leurs propres vérifications et opportunités d'amélioration à travers des revues de procédé. Il faut donc distinguer un point projet (au sens SMP) dont le "focus" est le projet et qui potentiellement peut engendrer des mesures correctives et préventives relatives au projet, d'une revue de processus dont le "focus" est un procédé ou processus, et qui potentiellement peut engendrer des mesures correctives, préventives et évolutives relatives aux ressources ou conditions d'utilisation du procédé considéré. Ex. type : revue du procédé de gestion des exigences ou de gestion de configuration sur un périmètre donné (site, plan national…) Il ne s'agit pas de focaliser sur un projet mais sur un procédé

Historique des révisions
Nom Fonction Date Auteur Bernard THEPAULT (BTT) Consultant Telecom Rennes Vérificateur(s) Georges MITAUT (GMT) Directeur du BE Telecom Rennes Approbateur(s) Jean-Charles COEURU (JCC) Directeur du Bureau d’Etudes Telecom Ile de France Révision Date Modification Origine Auteur 2.0 Mar. 2007 Création pour le cycle de formation industrialisation de Telecom Ile de France (et pour la formation dans les autres divisions), par adaptation des supports standard SIROCO et des instanciations faites par les sites SIROCO B. Thepault

Pour plus d’informations, contacter : Bernard THEPAULT t (0) m (0) Atos Origin Rennes Cesson-Sévigné

Industrialisation : manager la qualité des projets

Présentations similaires

Présentation au sujet: "Industrialisation : manager la qualité des projets"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Industrialisation : manager la qualité des projets

Présentations similaires

Présentation au sujet: "Industrialisation : manager la qualité des projets"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back