Système de Management intégré

Les principes d’un Système de Management intégré

Pour une organisation, il est important de conduire ses activités métiers de manière responsable en assurant la qualité des produits et des services fournis et la conformité avec les réglementations applicables liées à la qualité et la sécurité des pays où elle opère.

Pour atteindre cet objectif, un système de management intégré des processus couvrant les aspects Qualité, Sécurité et Gouvernance de l’organisation peuvent être mis en place pour :

• S’assurer de la conformité avec les réglementations applicables,
• Fournir un référentiel conforme avec les exigences de ses clients,
• Attribuer des rôles et des responsabilités clairs à toutes les parties prenantes,
• Identifier, analyser et gérer tous les risques liés aux activités,
• Fournir des outils de travail, des technologies appropriées et des procédures permettant la performance au service des clients,
• Gérer et améliorer de manière continue le système de Management et sa performance, ceci incluant la réduction des impacts négatifs au travers d’une revue constante des objectifs, des cibles, des mesures, découlant sur la mise en œuvre d’action préventives et correctives.

Ces principes guident pour la réalisation des procédures opérationnelles pragmatiques et des accords commerciaux. Cette politique est applicable à tous les projets, opérations, contrats de sous-traitance, organisations et collaborateurs.

ISO 9001 la base du système de Management

Le système de Management des processus qui est embarqué dans toutes les normes ISO traitant de ce sujet est issu de la célèbre norme internationale qualité ISO 9001, voici une courte présentation qui vous explique les grands principes d’un SMQ ou Système de Management de la Qualité :

Cas pratique d’un modèle de processus générique

Un exemple, pour lequel j’ai géré la définition et le déploiement complet, concerne un système de gestion intégré de la qualité, en anglais c’est un QMS (Quality Management System) construit en s’inspirant des bonnes pratiques du référentiel international ISO 9001.

L’organisation à mis en œuvre ce QMS détaillé et très large pour la gestion de ses produits et services client : les bonnes pratiques d’ITIL / ISO 20000 pour la gestion des Services IT et Métiers, celles du référentiel CMMI pour la gestion des projets et le développement des solutions logicielles. Les aspects plus spécialisés de la gestion de la sécurité sont repris de la norme ISO 27001, sans oublier les processus d’amélioration continue.

Armé d’une longue expérience acquise dans ces domaines, les pratiques les mieux adaptées à ces opérations et les plus pragmatiques ont été intégrées dans un modèle de maturité des processus CpMM (Common process Maturity Model) qui s’adaptait parfaitement aux besoins de l’organisation. L’objectif étant de standardiser les pratiques sans uniformiser.

La cartographie complète de ce modèle est présentée ci-dessous :

Ce qui donne en détails :

Cliquez sur l’image pour agrandir

La mise en place et le déploiement de ce modèle et des processus opérationnels déclinés pour une DSI internationale a été complété par une organisation dont voici le modèle :

Cliquez sur l’image pour agrandir

Services de consulting

Si vous souhaitez développer un système de management de processus intégré dans votre organisation ou évaluer son déploiement, nous pouvons vous apporter conseils et expériences pour formaliser votre projet en utilisant par exemple le modèle CpMM ou les référentiels standards. Pour cela voici quelques exemples de services :

• Définir et mettre en place un système intégré de Management couvrant tous les domaines opérationnels de l’organisation, déclinaisons des bonnes pratiques en processus opérationnels.
• Mise en place d’une gouvernance des processus et du système d’amélioration continue, définir les objectifs, les méthodes de suivi et de reporting.
• Définir les objectifs du plan de Démarche de Progrès en fonction des objectifs stratégiques.
• Identifier les sources potentielles de progrès  en terme de qualité, coût, délai.
• Déployer les pratiques d’amélioration continue, organiser l’audit interne, préparer aux méthodes d’audit et d’amélioration type Kaizen.

MPP Management Par Projet

Cet article vous présente les définitions principales et le référentiel d’un système de gouvernance de projet au sein d’une DSI en charge du développement d’applications logiciel et de la mise en production des Systèmes d’Information résultants. Ce référentiel complet, dont j’ai coordonné le développement et le déploiement avec le soutien de ACDE Conseil, a été évalué et reconnu CMMI niveau 2.

Définitions

Le Management Par Projet est un ensemble de processus destiné à assurer que les projets sont entrepris en adéquation maximale avec les objectifs stratégiques de la société et que les risques encourus sont identifiés et contrôlés.

Un projet se caractérise par une existence limitée dans le temps, un début, une fin et un objet parfaitement identifiés.

Lui est affecté un chef de projet ou Project Manager, responsable de la coordination de la production de l’ensemble des livrables, de l’organisation et de la bonne exécution de l’ensemble des tâches et intervenants concourant à la réalisation du projet, depuis son initialisation jusqu’à sa clôture.

Implicitement cela signifie qu’un projet inclue non seulement des travaux ayant trait au développement de logiciels, pour le cas qui nous intéresse, mais aussi toutes les activités de communication, de documentation et d’industrialisation du système d’information se tenant en amont ou en aval de la production du logiciel.

La décomposition en phases conclues par un jalon ou milestone permet d’évaluer les avantages potentiels et le niveau de risque des projets, de définir des responsabilités claires, de segmenter et d’organiser le travail à effectuer, d’impliquer avec pertinence l’intégralité des acteurs concernés, de maîtriser les engagements de ressources, de valider les travaux accomplis, de prononcer les arbitrages attendus, de décider de poursuivre, de stopper, de différer ou de recadrer certains projets.

Le franchissement du jalon marquant la fin de chaque phase est conditionné à l’approbation par la direction, ou par des instances agissant par délégation, d’un certain nombre de documents de gestions et livrables attestant que le travail convenu a été réalisé conformément aux objectifs fixés, dans les règles de l’art en terme de qualité, dans les limites de temps, de budget ou de charge convenus.

Remarque : Le processus global de management par projet se nourrit d’autres processus tels que les processus d’assurance qualité ou les processus d’ingénierie et de support.

Présentation du processus

Le processus global de Management Par Projet (MPP) se décompose en sept phases essentielles. Chaque phase se conclut par une réunion de revue évaluant la performance du projet en regard de ses objectifs et statuant sur sa continuation. Cette revue est marquée par le franchissement d’un jalon traduisant l’état de maturité du projet.

Le franchissement de chaque jalon est conditionné à :

• La production de certains livrables ou documents de gestion,
• L’approbation d’une autorité prédéterminée (GO/NOGO).

Tous deux dépendant des caractéristiques du projet : produit, maîtrise d’ouvrage, catégorie, criticité.

Les phases d’un projet classique sont les suivantes :

1 – INITIALISATION

Cette phase a pour objet de préciser les raisons prévalant à l’engagement potentiel du projet. Elle se conclut par le jalon « Business Review » marquant l’accord sur la pertinence économique du projet.

2 – ÉVALUATION

Cette phase a pour objet d’apprécier la faisabilité du projet en regard des orientations stratégiques de l’organisation, de ses capacités et du retour sur investissement envisageable. Elle se conclut par le jalon « Faisibility Review » marquant l’accord sur la faisabilité du projet.

3 – SPÉCIFICATION ou  DÉFINITION

Cette phase a pour objet de définir le contenu précis et d’arrêter les choix techniques du projet, elle est l’occasion de développer les exigences avec le client ou la maîtrise d’ouvrage. Elle se conclut par le jalon « Definition Review » marquant l’accord sur la définition du projet.

4 – RÉALISATION ou CONSTRUCTION

Cette phase recouvre la plupart des opérations de réalisation des composants (logiciels et non logiciels) du projet. Elle se conclut par le jalon « Realisation Review » marquant l’accord sur la réalisation du projet.

5 – PRÉPARATION ou VALIDATION

Cette phase recouvre l’ensemble des opérations intermédiaires séparant la production d’un code testé de sa mise à disposition des clients sous forme d’un produit fonctionnel, maintenable, documenté et supporté. Elle inclut les dernières étapes de documentation et la plupart des étapes de recette, d’industrialisation, de production, de mise en exploitation, de mise à disposition à des clients-tests (partenaires de développement, beta-tests), de transferts de connaissance et de responsabilité envers les divisions opérationnelles. Elle se conclut par le jalon « Validation Review » marquant l’accord sur la validation du projet et sur le fait que l’organisation dans son ensemble est prête pour la commercialisation et le support de la version.

6 – LANCEMENT ou PRODUCTION

Cette phase recouvre l’ensemble des opérations marketing, commerciales et de relation client entourant la mise sur le marché d’un nouveau produit ou d’une nouvelle version : actions presse, conférences, formation des utilisateurs. Elle se conclut par le jalon « Launch Review » marquant l’accord sur le fait que les opérations de lancement sont terminées et que la version est maintenant pleinement en exploitation.

7 – CLÔTURE ou BILAN

L’objet de cette phase est d’effectuer un bilan technique et organisationnel du projet afin principalement de recenser les difficultés rencontrées et de suggérer des axes d’évolution ou d’amélioration pour de futurs projets. Elle se conclut par le jalon « Final Project Review » marquant l’accord sur la fin du projet.

Le cycle de vie projet

Ce cycle d’enchaînement de phases et de jalons se nomme Cycle de Vie Projet, il a été synthétisé dans un poster que chaque membre de l’équipe projet peut afficher comme aide mémoire pragmatique pour les prises de décision et les livrables attendus. Dans cette version du poster la définition et le nommage des phases du projet ont été adaptés à un cycle de vie de développement logiciel (SDLC).

Afficher ce document sur Scribd

Une autre représentation de ce cycle de vie peut être faite à l’aide du référentiel générique et intégré CpMM, les différents processus à mettre en place se répartissent tout au long du cycle Phases/Jalons sur une disposition classique en « V » entièrement couvert par le processus PM :

Cliquez sur l’image pour agrandir

Le déploiement pratique de cette cartographie de processus en procédures opérationnelles standards peut être représenté comme suit :

Cliquez sur l’image pour agrandir

Organisation

Le choix a été fait de mettre en place une structure matricielle ou structure par projet, c’est une structure temporaire limitée à la durée d’un projet.

Son principe est le suivant : les services permanents, organisés par fonctions techniques (les ex silos), affectent leur personnel dans des équipes projet en fonctions de besoins. Quand le projet est achevé, chacun rejoint son service d’origine en attente d’une nouvelle affectation. Une ressource peut être affectée à plusieurs projets selon sa charge.

Dans une structure matricielle, la fonction de management n’est plus dans les mains d’une seule personne, mais d’au moins deux. Il est ainsi primordial que le partage des responsabilités, mais aussi et surtout de l’autorité, entre les managers soit clair et précis.

Les avantages de la structure matricielle par projet sont de:

• permettre une grande flexibilité dans la gestion des ressources humaines et le management,
• développer l’innovation par l’émulation des idées entre des profils différents,
• favoriser la collaboration,
• ouvrir des nouveaux champs de communication entre les fonctions.

Bref, elle est bien adaptée à un monde économique complexe qui exige adaptation, innovation, réactivité des entreprises.

Le référentiel MPP

Vous trouverez ci-dessous la documentation en anglais du référentiel de Management Par Projet tel qu’il a été utilisé pour l’évaluation CMMI, en particulier vous y découvrirez les instances de pilotage et de direction à mettre en place, ainsi que les rôles et responsabilités de tous les acteurs du projet. Enfin l’ensemble des processus et des livrables pour réaliser le projet est décrit.

Afficher ce document sur Scribd

Comment standardiser sans uniformiser ?

J’ai contribué au Club PMO animé par ACDE Conseil en faisant un retour de mon expérience de standardisation pragmatique de processus au sein d’une organisation de services spécialisée en développement et hébergement de logiciels pour le monde de la santé.

Cegedim a souhaité définir un référentiel commun de bonnes pratiques, propre à l’entreprise, construit à partir de plusieurs méthodologies et référentiels : CMMI, Prince 2, ITIL, ISO 2701, ISO 9001, etc.

Cette approche de rationalisation interne des référentiels sert également à montrer aux clients de l’organisation comment sont gérés les projets et les services, cette standardisation aide à vendre la démarche de définition des processus internes aux Managers opérationnels.

Un point de vigilance qu’il ne faut pas négliger dans ce type de projet, c’est de rechercher et trouver le bon niveau de détails dans la définition des processus sans nuire à l’innovation.

Vous pouvez retrouver cette présentation sur le site du Club PMO ou directement en la téléchargeant ici.