Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Introduction à ITIL et à MOF

Dans la théorie, il n’y a aucune différence entre la théorie et la pratique. Dans la pratique il y en a une.
(Yogi Berra)

Qu’est-ce qu’ITIL ?

Le référentiel ITIL offre une approche structurée pour la fourniture de services IT de qualité. ITIL fut initialement développé dans les années 80-90 par le CCTA (Central Computer and Telecommunications Agency, aujourd’hui l’Office of Government Commerce, OGC), sous contrat avec le gouvernement britannique. Depuis lors, ITIL a fourni non seulement un cadre de référence fondé  sur des bonnes pratiques, mais également une approche et une philosophie partagées par tous ceux qui l’appliquent au quotidien.

Structure principale : Le cycle de vie des services

ITIL Version 3 offre une approche de gestion des services fondée sur le principe du cycle de vie. Ce modèle d’organisation fournit des clefs sur la gestion des services et la manière dont les divers composants sont liés entre eux et au cycle de vie dans son ensemble.

Le cycle de vie des services se décompose en cinq phases. Chacun des volumes ITIL V3 décrit l’une de ces phases :

• Stratégie de services
• Conception de services
• Transition de services
• Exploitation de services
• Amélioration continue des services

Schéma 1 : Le cycle de vie des services ITIL V3.

La stratégie constitue l’axe central du cycle de vie des services ; c’est la phase de l’élaboration de la politique et des objectifs, qui conditionne toutes les autres. Les phases Conception de services, Transition de services et Exploitation de services implémentent la stratégie avec pour constantes l’ajustement et le changement. La phase continuelle d’Amélioration des services est synonyme de capitalisation de savoir et d’amélioration, et s’applique à toutes les autres phases du cycle. Elle initie des programmes et des projets d’amélioration, et leur attribue des priorités selon les objectifs stratégiques de l’organisation.

Composants principaux

Chaque phase est sous-tendue par un système de processus, d’activités et de fonctions, qui décrivent comment les choses devraient être réalisées. Les sous-systèmes des cinq phases entretiennent des relations de dépendances réciproques, et la plupart des processus sont à cheval sur plusieurs phases.

Qu’est-ce que MOF ?

Publié initialement en 1999, le Microsoft Operations Framework (MOF) constitue l’approche structurée de Microsoft pour aider ses clients à atteindre l’excellence opérationnelle, au travers du cycle de vie complet des services IT. MOF a été créé à l’origine pour apporter aux professionnels de l’IT les compétences et les processus utiles à l’alignement de leur activité de gestion des plates-formes Microsoft, en vue d’atteindre des niveaux élevés de fiabilité et de sécurité, de façon rentable.

La nouvelle version, MOF 4.0, a été créée pour relever les nouveaux défis IT : démontrer la valeur business de l’informatique, répondre aux conditions de normalisation, et améliorer la capacité organisationnelle. MOF intègre également les meilleures pratiques issues du Microsoft Solutions Framework (MSF).
MOF offre des conseils pratiques pour la gestion des tâches et des activités quotidiennes; enfin, le corpus de connaissances peut être exploité gratuitement, y compris dans le cadre d’une réutilisation sous licence Creative Commons Attribution.

Structure principale : le cycle de vie des services IT

Le cycle de vie des services IT décrit l’évolution d’un service :

1. Planification, optimisation et alignement avec la stratégie business.
2. Conception et livraison au respect des exigences du client.
3. Suivi d’exploitation et support auprès de la communauté des utilisateurs.

Le Cycle de vie des services IT exploite et définit :

• la gouvernance IT,
• la gestion des risques,
• la conformité,
• les rôles et responsabilités,
• l’organisation des équipes,
• la gestion des changements.

Le cycle de vie des services IT de MOF se décompose en trois phases itératives et inclut également une couche de gestion active tout au long du cycle de vie :

• Phase de planification : Planifier et optimiser une stratégie de services IT afin de soutenir les objectifs et la stratégie du business.
• Phase de livraison : s’assurer que les services IT sont développés efficacement, déployés avec succès, et prêts pour l’exploitation.
• Phase d’exploitation : s’assurer que des services sont exploités, maintenus, et soutenus conformément aux attentes et aux exigences du business.

Couche de gestion :

• A la base du cycle de vie des services IT.
• Gouvernance IT.
• Gestion des risques, de la conformité, des changements et des configurations.
• Fournit des indications sur les rôles et les responsabilités.
• Les processus dans cette couche s’appliquent à toutes les phases du cycle de vie.

Schéma 2 : MOF 4.0 – Cycle de vie de services IT.

Composants principaux

Chaque phase du cycle de vie des services IT intègre des fonctions de gestion de services (Services Management Functions, SMF) qui définissent et structurent les processus, les personnes, et les activités nécessaires à l’alignement des services IT sur la stratégie business. Les fonctions de gestion de services sont regroupées en phases qui reflètent le cycle de vie des services IT. Chaque fonction de gestion de services est ancrée dans une phase du cycle de vie, et contient un ensemble unique de buts et de résultats soutenant les objectifs de cette phase.

Chaque fonction de gestion de services comporte de trois à six processus clefs, chaque processus étant composé de une à six activités clefs.

Lors de chaque phase du cycle de vie, des revues de gestion (Management Revues, MR) sont mises à profit pour déterminer le statut des services IT et décider du passage à la phase suivante. Les revues de gestion sont des contrôles internes visant à s’assurer que les buts sont atteints d’une façon appropriée, et que l’intérêt business est pris en compte tout au long du cycle de vie de services.

Alignement d’ITIL et de MOF

Les gens n’ont jamais assez de temps pour effectuer le travail correctement, mais ils ont toujours assez de temps pour le recommencer.
(Patrick O’Beirne)
En termes d’approches, les deux référentiels emploient une structure basée sur le principe de cycle de vie. Si tous deux exploitent des processus et des fonctions, ils le font dans des proportions très différentes  : ITIL décrit beaucoup de composants en termes de processus et d’activités, et intègre seulement quelques fonctions, alors que MOF est presque entièrement basé sur des fonctions de gestion de service. Cette différence n’est pas aussi évidente qu’il pourrait y paraître, ITIL employant le terme « processus » pour beaucoup de composants qui peuvent être assimilés à des fonctions.

ITIL suit une approche par étapes dans le cycle de vie, et la plupart des composants décrits dans une phase s’appliquent également, dans une plus ou moins large mesure, aux phases connexes. Le contrôle du cycle de vie dans MOF est beaucoup plus sélectif, et utilise des jalons spécifiques qui marquent le progrès au travers les diverses étapes du cycle de vie. Les composants de MOF qui s’appliquent à plus d’une seule des phases du cycle de vie sont extraites et décrites dans la couche de gestion.

Les deux référentiels sont décrits comme des « cadres de pratique » plus que comme des « cadres de processus. » La différence principale étant qu’ITIL se concentre plus spécifiquement sur le « quoi », alors que MOF couvre à la fois le « quoi » et le « comment. »

Les techniques de modélisation d’ITIL et de MOF ne diffèrent pas significativement à première vue : les deux référentiels employant des descriptions textuelles détaillées, soutenues par des organigrammes et des diagrammes de flux. ITIL documente ses meilleures pratiques en présentant des processus, des activités, et des fonctions pour chaque phase du cycle de vie. Les composants de MOF présentent quant à eux une structure plus rigide : chaque fonction de gestion de services comporte des processus clefs, chaque processus des activités clefs, et la documentation des fonctions de gestion de services et des revues de gestion est structurée dans un format très concis, couvrant les données d’entrée et de sortie, les questions clé, et les meilleures pratiques pour chaque composant. Cette structure rigide soutient l’uniformité globale du référentiel, et assiste le praticien dans le choix des composants de MOF les mieux adaptés aux problématiques les plus sensibles dans son périmètre.

L’activation et l’implémentation d’ITIL et de MOF n’appartiennent pas en plein à la documentation des référentiels. Sur ce point, ITIL préconise l’approche « adopter et adapter ». Les structures de support telles que les rôles et les qualifications organisationnelles sont décrits pour chaque phase, mais les recommandations de mise en œuvre effective ne sont pas documentées. MOF, à l’instar d’ITIL, fournit un ensemble de recommandations et de meilleures pratiques qui peuvent être suivies en intégralité ou en partie seulement, pour  la prise en compte de problèmes locaux. Les deux référentiels se contentent donc de fournir des conseils et du guidage, et relèguent au praticien la responsabilité des choix de mise en œuvre dans son contexte spécifique.

Les structures de support dans ITIL ne participent pas de la documentation de référence : bien qu’une gamme pléthorique de produits et de solutions se revendiquent aujourd’hui d’une compatibilité avec ITIL, (et l’existence anecdotique de quelques systèmes officieux d’accréditation), le corpus ITIL reste très en retrait en ce qui concerne les produits, les solutions commerciales et leur certification, au profit d’une attitude de neutralité. Tout au contraire, la compatibilité de MOF est clairement établie. Microsoft assure l’alignement constant d’un vaste ensemble d’outils de sa plate-forme avec le référentiel MOF. Et bien que MOF ne s’applique pas strictement aux seuls produits de gestion Microsoft, la documentation accessible en ligne sur le site Web Microsoft TechNet fournit des informations détaillées sur l’utilisation de produits spécifiques issus de la gamme Microsoft.

Différences

Bien qu’ITIL et MOF partagent beaucoup de points en commun, les deux référentiels présentent également quelques différences notables :

• Coût : le corpus ITIL est accessible au sein d’une documentation de référence composée de cinq livres distribués par divers canaux, lors même que le référentiel MOF est disponible gratuitement sur l’Internet. Là où le copyright d’ITIL restreint significativement les droits à l’exploitation du référentiel, Microsoft a fait le choix de distribuer le référenrtiel MOF sous licence Creative Commons Attribution, ce qui en permet une libre réutilisation commerciale.

• Développement : la phase de conception de services d’ITIL se concentre sur les principes de conception, là où la phase de livraison dans MOF se concentre sur le développement réel des services. L’approche retenue dans MOF est résolument basée sur des principes issus du mode gestion de projet qui caractérise cette phase du cycle de vie.

• Reporting : ITIL intègre une entité spécifique qui décrit la façon de rendre compte dans la phase d’amélioration continue des services, tandis que MOF a intégré le reporting comme une activité standard dans les fonctions de gestion de services.

• Gestion des demandes : alors qu’ITIL V2 proposait une gestion combinée des incidents et des demandes de service au sein d’un même processus, ITIL V3 a nettement dissocié la résolution des incidents et la prise en compte des demandes de service en deux pratiques traitées séparément. MOF reste beaucoup plus proche de la méthode telle que préconisée dans ITIL V2, en regroupant toutes les demandes du client au sein d’un flux unique de traitement, qu’il s’agisse de : demandes de résolution suite à incident, demandes d’information, demandes de modification de services existants ou création de nouveaux services. Dans ce dernier cas, et si la demande implique la création d’un nouveau service ou d’un service non-standard, un processus de changement séparé peut être déclenché.

• Construction du cycle de vie : ITIL utilise cinq phases pour son cycle de vie : la stratégie, la conception, la transition, l’exploitation, et l’amélioration continue, délivrées conformément aux principes du modèle PDCA (Plan/Do/Check/Act). Le cycle de vie de MOF comporte quant à lui seulement trois phases : la planification, la livraison et l’exploitation, avec de plus une couche transverse couvrant les composants applicables à toutes les phases du cycle de vie. Par conséquent, un certain nombre de pratiques appliquées tout au long du cycle de vie de MOF ne sont en revanche décrites principalement que dans une ou quelques phases seulement du cycle de vie ITIL. Par exemple, la gestion des risques appartient à la couche de gestion dans MOF, alors que dans ITIL elle est principalement limitée à la stratégie et à l’amélioration continue des services. Il en va de même pour la gestion des changements et des configurations applicable tout au long du cycle de vie de MOF, alors que dans ITIL elle se retrouve concentrée dans la phase de transition.

• Organisation : ITIL décrit des rôles et des structures d’organisation pour chaque phase du cycle de vie. MOF soutient les meilleures pratiques pour les structures organisationnelles en appliquant l’approche Microsoft Solutions Framework : tout au long du cycle de vie de MOF, les responsabilités sont documentées et clairement explicitées, et des règles générales sont assignées à la couche de gestion sous-jacente.

• Gouvernance : Les deux cadres illustrent clairement la différence entre gouvernance et gestion. ITIL décrit la théorie et la pratique en matière de gouvernance dans les phases de stratégie et d’amélioration continue des services de son cycle de vie, et se réfère aux impératifs de gouvernance dans la plupart des autres phases. MOF documente explicitement les responsabilités dans toutes les phases du cycle de vie et dans la couche de gestion, identifiant des décideurs et des dépositaires, et intégrant l’évaluation des performances. MOF intègre spécifiquement la gestion des risques et de la conformité au sein de la couche de gestion, soutenant la gouvernance tout au long du cycle de vie. Des revues explicites de gestion sont employées dans le référentiel MOF comme mécanismes de contrôle.

Positionnement

Cette section développe les principaux paradigmes propres à chaque référentiel et évoqués plus haut.

Cycle de vie

Dans l’ensemble, les cycles de vie d’ITIL et de MOF présentent un aspect plutôt similaire, bien que les phases en tant que telles ne puissent être comparées sur une base linéaire.

Schéma 3 : Comparaison des cycles de vie.

Il existe quelques différences majeures entre les cycles de vie d’ITIL et de MOF :

• Les phases du cycle de vie d’ITIL comportent des processus, des activités, et des fonctions étalées sur plusieurs phases. Dans MOF, les fonctions de gestion de services qui s’appliquent à plus d’une phase ont été extraites et regroupées au sein de la couche de gestion, soutenant le cycle de vie entier de MOF.

• Les transitions de phase à l’intérieur du cycle de vie de MOF sont contrôlées par plusieurs revues de gestion. Ces revues sont employées pour déterminer le statut des services et ainsi décider du passage à la phase suivante. ITIL emploie également un certain nombre de tests d’aptitude pour évaluer le progrès dans les phases du cycle de vie, mais de façon moins explicite et formalisée.

Les personnes – les processus – la technologie (PPT)

Quatre-vingt pour cent des périodes d’indisponibilité non-planifiées sont provoqués par des problèmes de processus et de personnes, telles que des pratiques de gestion des changements inadaptées, alors que le reste est provoqué par des défaillances et des pannes techniques.

(Donna Scott, Gartner, Inc., 2003)

ITIL et MOF sont foncièrement focalisés sur les processus. Les deux référentiels documentent les activités devant être réalisées pour faire face aux problèmes et aux tâches quotidiens, au sein des organisations de service. Les deux référentiels emploient également la même définition formelle du concept de « processus », basée sur les normes reconnues de l’ISO.

Cependant et dans les deux cas, la documentation de référence apparaît en grande partie comme un mélange de processus, de personnes, et de technologies, et donc sous forme de procédures, d’instructions de travail, et de fonctions. Il en est ainsi car il s’agit de refléter fidèlement la perception réelle des usagers dans leur pratique quotidienne.

Les lecteurs recherchant « des descriptions de processus pures » ou des « modèles » de processus ne trouveront donc ces derniers ni dans ITIL ni dans MOF. Et bien qu’ITIL emploie fréquemment le terme « processus » pour nombre de ses composants, la plupart de ces derniers sont en réalité des fonctions. MOF emploie le terme de fonction de gestion de services tout au long du référentiel pour les désigner..

Les structures d’organisation diffèrent singulièrement dans les deux référentiels. Si certains rôles spécifiques d’ITIL et ceux de MOF peuvent se confondre, les deux cadres contiennent malgré tout une liste importante de rôles distinctifs. Ceci s’explique en grande partie sur une différence de point de vue : ITIL s’appuie sur ses pratiques au travers du spectre détaillé des rôles, alors que MOF repose sur des responsabilités de base : support, exploitation, service, conformité, architecture, solutions, et gestion. MOF applique le référentiel MSF comme système de référence pour ces structures d’organisation pour le soutien des performances. Dans de plus grandes organisations, les rôles de MOF peuvent être enrichis, même si dans la plupart des cas les rôles génériques s’avèrent suffisants. L’équipe SMF de MOF est explicitement concentrée sur la gestion du personnel informatique.

La technologie est seulement couverte à un niveau abstrait dans ITIL : le référentiel reste éloigné des outils commerciaux, et décrit seulement quelques prérequis de base. MOF au contraire est profondément impliqué au plus proche des technologies et des solutions. Bien que MOF ait été défini de telle manière qu’il ne repose pas exclusivement sur une seule technologie, la plate-forme de technologie de Microsoft est fortement alignée sur les pratiques telles que documentées dans MOF. Le site Web de MOF est ainsi inclus dans la documentation TechNet sur les produits Microsoft.

Répartition des phases, des processus et des activités

• Les niveaux stratégiques sont couverts dans les deux référentiels. ITIL documente ses meilleures pratiques sur des décisions à long terme dans la phase de stratégie. MOF en fait de même dans la phase de planification, et en assure le support à travers la couche de gestion.

• Les niveaux tactiques sont couverts de façon similaire dans les deux référentiels : ITIL concentre ces derniers dans les phases de conception de services et d’amélioration continue des services, tandisque MOF décline ses conseils tactiques dans la phase de livraison, la couche de gestion et dans la phase d’exploitation (gestion de problèmes).

• Les niveaux opérationnels sont presque exclusivement concentrés dans la seule phase d’exploitation de services, dans les deux référentiels.

Les phases du cycle de vie d’ITIL sont principalement située dans le domaine de gestion de la technologie, soulignant qu’ITIL soutient explicitement les organismes qui fournissent des services. Les activités qui se rapportent aux spécifications des exigences de service et à la gestion des architectures de données d’entreprise peuvent typiquement être trouvées dans la colonne moyenne de la matrice 3×3 SAME.

Schéma 4 : Positionnement d’ITIL V3 dans la matrice 3×3 SAME.

Ceci s’applique également à MOF. La phase de planification (PLANIFIER) de MOF est en grande partie positionnée au niveau de la stratégie et se concentre sur le domaine de gestion de la technologie. La phase de livraison (FOURNIR) est positionnée à l’identique, mais également aux niveaux tactiques et opérationnels. La phase d’exploitation  (EXPLOITER) se situe clairement au niveau opérationnel du domaine de gestion de la technologie, excepté la gestion (très tactique) des problèmes.

La couche de gestion (GERER) dans MOF implique chacun des trois niveaux et concerne également sur le domaine de gestion de la technologie.

Schéma 5 : Positionnement de MOF dans la matrice 3×3 SAME.

Planier-Faire-Vérifier-Agir

ITIL suit explicitement le modèle d’amélioration continue de la qualité de Demings PDCA pour l’amélioration continue des services, des processus, et des fonctions tout au long du cycle de vie des services.
MOF ne mentionne pas explicitement PDCA en tant que mécanisme, mais suit malgré tout ses principes tout au long du cycle de vie, et dans toutes les fonctions de gestion de services. Planifier-faire-vérifier est un basique lors de l’implémentation des fonctions de gestion de services, et plusieurs instances de vérification peuvent être consultées lors des revues de gestion tout au long du cyle de vie.

Schéma 6 : la roue de Deming.

The Microsoft Operations Framework 4.0 is provided with permission from Microsoft Corporation

Article extrait du site ITIL.FR – Le portail communautaire francophone des Meilleures Pratiques.

Diffusé avec l’autorisation de notre site partenaire : http://www.jexcom.fr – Société de Conseil, Formation et Maintenance informatique spécialisée PME / TPE en Ile-de-France

Introduction

La racine commune des référentiels Lean et Six Sigma remonte à l’époque où de fortes pressions sur la qualité et la performance ont commencé à peser sur le secteur industriel. Lean et Six Sigma se sont alors imposés respectivement comme méthode d’optimisation de la fabrication automobile, et démarche qualité d’excellence pour l’éliminiation des défauts, par la réduction des variations au coeur des processus de l’industrie des semi-conducteurs. Il n’est d’ailleurs pas surprenant de constater que les tout premiers adeptes de la méthode Lean Six Sigma soient pour la plupart issus des unités de soutien des services de grands groupes industriels tels que GECapital, Caterpillar Finance, ou Lockheed Martin.

Lean Six Sigma pour les services est une méthodologie d’amélioration des affaires qui maximise la valeur pour les actionnaires en réalisant les meilleurs taux d’amélioration de la satisfaction client, de coût, de qualité, de rapidité des processus, et de  retour sur capital investi. La fusion des méthodes d’amélioration Lean et Six Sigma décuple les performances de chacune et permet de dépasser leurs limitations intrinsèques :

• Lean ne peut pas mettre un processus sous contrôle statistique.
• Six Sigma seule ne peut améliorer considérablement la vitesse de traitement ou réduire le capital investi.
• Tous deux permettent la réduction du coût lié à la complexité.

Ironiquement, Six Sigma et Lean ont souvent été considérées comme des initiatives rivales. Les amateurs de Lean arguant que Six Sigma accorde peu d’attention à tout ce qui concerne la vitesse et le débit, tandis que les partisans de Six Sigma soulignaient quant à eux le fait que Lean ne tient pas compte de concepts clés tels que les besoins des clients et la variation. .

Toutesfois, ces arguments, le plus souvent utilisés pour défendre un choix un sur l’autre, ne doivent pas faire perdre de vue que si chaque méthode à ses avantages et ses inconvénients, elles demeurent avant tout éminemment complémentaires.

Six Sigma

Six Sigma est une technique de gestion qui vise à développer et fournir des produits et des services proches de la perfection. Le parti pris selon lequel Six Sigma est seulement utile pour les problèmes qui sont «difficiles à trouver, mais faciles à corriger” a fréquemment été soutenu, par opposition à l’approche radicale de restructuration (reengineering), dont les partisans se concentrent sur des problèmes qui sont “faciles à trouver, mais difficiles à corriger.”

Le terme « Six Sigma » fait référence à des constructions statistiques qui mesurent jusqu’à quel point un processus donné s’écarte de la perfection. Six Sigma est un processus de même qu’une discipline qui mesure le nombre de défauts existant au sein d’un processus d’affaires, puis détermine de façon systématique comment les supprimer. Six Sigma peut être utilisé pour un éventail très large d’activités d’amélioration des processus, et s’applique à de nombreux types de processus, dont la nature des attributs mesurés peut varier considérablement.

Les principes de qualité appliqués lors de l’implémentation de Six Sigma sont presque toujours définis en termes de vision de l’entreprise et de sa stratégie. Les processus sont développés à partir du point de vue du client, et activés par un engagement de l’organisation à raisonner en termes de processus.

Les impératifs de performance, fiabilité, prix, respect des délais de livraison, service et précision définissent les objectifs. L’orientation client initie la connaissance du marché, qui peut à son tour éclairer la nécessité de changement de processus, dans les domaines où l’entreprise peut ajouter de la valeur, ou implémenter des améliorations sollicitées par les clients eux-mêmes.

Les partisans de Six Sigma partent du principe que les clients ont intérêt à comparer, non pas la performance moyenne des entreprises, mais plutôt les performances relatives des processus utilisés pour la fourniture des biens ou des services.

Méthode rigoureuse, Six Sigma exige qu’un processus ne produisent pas plus de 3,4 défauts par million d’occurrences dudit, bien que son objectif principal reste l’amélioration continue. En faitt très peu d’organisations  peuvent prétendre avoir jamais atteint l’objectif Six Sigma de 3,4 défauts par million.

Les principes de Six Sigma s’appliquent non seulement à l’industrie, mais également à la prestation de services.

Six Sigma repose sur seulement quelques concepts clefs :

• Facteurs clés de succès (Critical to quality) : Attributs ayant le plus de valeur pour le client.
• Défaut (Defect) : Défaut de fourniture.
• Capacité du processus (Process capability) : Ce qu’un processus peut fournir.
• Variation (Variation) : Ce que le client voit et ressent.
• Stabilité des opérations (Stable operations) : Garantir des processus cohérents et prévisibles pour améliorer la perception et le ressenti du client.

Lean

Les origines de la méthode Lean remontent bien avant le XXe siècle, bien que la dénomination en tant que telle ne soit apparue que bien plus tard. Le terme Lean provient du travail de recherche d’un étudiant au MIT, dans le cadre d’une étude sur les différences  ayant existé entre certains constructeurs automobiles japonais et nord-américains.

Les processus clés de Lean ont tous pour objet l’identification des « déchets » et / ou « des activités sans valeur ajoutée » du point de vue du client, puis de déterminer comment les élminier selon la « bonne » méthode. Par « déchets » il faut entendre l’activité ou les activités que le client ne veux pas payer et / ou qui n’ajoutent aucune valeur au produit ou service du point de vue du client.

Au cœur du Lean repose la détermination de la valeur. La valeur est définie comme un élément ou une caractéristique pour lesquels un client est prêt à payer. Tous les autres aspects du processus sont considérés comme des déchets. Le référentiel Lean est utilisé comme un outil pour concentrer les ressources et les énergies sur la production des caractéristiques à valeur ajoutée, tout en identifiant et en éliminant les activités sans valeur ajoutée.

Lean Six Sigma

Lean Six Sigma est une méthodologie rigoureuse qui s’applique sur les processus (et non pas sur les problèmes) dans le but de :

• Améliorer la satisfaction des clients.
• Améliorer la performance financière de l’entreprise.
• Répondre aux objectifs stratégiques définis par la Direction Générale.

La focalisation sur les processus stratégiques permet de :

• Se concentrer sur les valeurs définies par le client (voice of customer).
• Se concentrer sur les attentes des actionnaires (voice of buisiness).
• Simplifier les processus : flux d’informations, de production.
• Supprimer les dysfonctionnements.
• Accélérer les processus en gérant et optimisant les ressources.
• Réduire la dispersion des processus organisationnels.
• Améliorer les performances opérationnelles et les garantir (capacité des processus).
• Identifier et agir sur les facteurs influents du processus.
• Améliorer les conditions de travail, réduire le stress.
• Faire travailler ensemble le personnel issu de différents services.
• Donner aux « opérationnels » les moyens et outils d’amélioration.

Les facteurs de réussite du déploiement du Lean six sigma reposent sur quatre fondamentaux :

L’application rigoureuse de la méthodologie Lean Six Sigma – Lean Six Sigma est une méthodologie rigoureuse, structurée qui doit être respectée à la lettre. Les candidats Green Belt et Black Belt doivent se soumettre à une sélection attentive suivant des critères précis. Les processus à améliorer doivent également faire l’objet d’une sélection sur des critères relatifs aux objectifs stratégiques de l’entreprise. Le projet global d’implémentation et du déploiement du Lean Six Sigma doit être structuré, en particulier par la mise en place de Champions et par un comité de pilotage du projet.

L’approche « gestion de projet » – Lean Six Sigma est une démarche d’amélioration continue qui se déploie au travers de projets Black Belt (gains importants, durée du projet : 6 à 8 mois) ou Green Belt (gains intéressants, projets plus courts). L’approche du management par projet est un pré requis pour lancer et réaliser des chantiers Lean Six Sigma.

• La conduite du changement – La mise en œuvre du Lean Six Sigma est un facteur de changement dans les pratiques et mises en œuvre quotidiennes des processus. Un accompagnement à la conduite du changement doit être pris en compte au niveau :

• des modifications des tâches, des pratiques individuelles et collectives du travail,
• des modes de fonctionnement : type de management, approche processus, structure organisationnelle,
• des changements culturels demandés et des résistances éventuelles,
• de la gestion des polyvalences et poly compétences du personnel,
• un mode de communication et d’information interne.
• Le management par les processus

• Lean Six sigma a pour objectifs essentiels d’améliorer la performance des processus, il ne s’agit pas de résoudre des problèmes : les méthodologies de résolution de problèmes sont un bon complément : PDCA, G8D, MRP.

Complémentarité

Six Sigma

• Insiste sur la nécessité d’identifier les opportunités d’amélioration et élimine les défauts tels que définis par les clients.
• Reconnaît que la variation entrave la capacité à fournir de manière fiable des services de haute qualité.
• Requiert des décisions orientées sur les données et intègre un ensemble complet d’outils de qualité au sein d’un cadre puissant pour une résolution efficace des problèmes.
• Fournit une infrastructure culturelle efficace, efficiente et très normative pour l’obtention de résultats durables.

Lean

• Maximise la vitesse des processus.
• Fournit des outils pour analyser les flux de processus et les détais de traitement pour chaque activité au sein d’un processus.
• Distingue les activités à valeur ajoutée des activités sans valeur ajoutée, et exploite des outils pour réaliser son objectif d’élimination des causes profondes de l’absence de valeur ajoutée de certaines activités et des coûts consécutifs.
• Fournit un moyen de quantifier et d’éliminer le coût de la complexité.

Les 8 types de déchets / activités sans valeur ajoutée :

• Le gaspillage des compétences humaines – Les dommages aux personnes.
• Les défauts – Tout ce qui fonctionne mal et doit être corrigé.
• L’inventorisation – Tout ce qui est en attente d’un traitement.
• La surproduction – Tout ce qui est en trop / ou trop en avance.
• Les Temps d’attente – Tout ce qui tarde à arriver / à se produire engendre de l’inactivité.
• Les mouvements – Déplacements humains injustifiés.
• Les transports – Déplacements de personnel et de matériel.
• Le traitement des déchets – Tout ce qui doit être fait et qui n’ajoute pas de valeur au produit ou au service.

Les deux méthodes interagissent et se renforcent mutuellement, de sorte que les gains en pourcentage de rendement du capital investi (Return On Invested Capital, ROIC), sont beaucoup plus rapides si Lean et Six Sigma sont mises en oeuvre ensemble.

En bref, ce qui caractérise Lean Six Sigma, en dehors de ses composantes propres, c’est avant tout la prise en compte mutualisée des aspetcs qualité et vitesse au profit d’un processus équilibré, lequel permettra à l’organisation de se concentrer sur l’amélioration de la qualité du service tel que définie par le client, au respect des délais convenus.

DMAIC (Define-Mesure-Analyse-Improve-Control)

« définir, mesurer, analyser, innover/améliorer et contrôler »

Utiliser DMAIC pour améliorer les processus de service

Tous les modèles sont faux, mais certains sont utiles. (Box)

Quelques soient les modalités de déploiement des équipes d’amélioration au sein de l’organisation, toutes doivent être informées avec précision de leurs objectifs. C’est ici qu’interviennent les modèles d’amélioration standard tels que DMAIC. Le modèle DMAIC en tant qu’approche structurée et rigoureuse d’amélioration des processus est composé de cinq phases, chaucune étant liée de façon logique aux phases attenantes.

Il existe de nombreuses ressources en ligne décrivant le processus DMAIC. Aussi nous concentrerons-nous ici  sur les considérations particulières à l’utilisation du processus DMAIC du Lean Six Sigma dans un environnement de services, y compris les méthodes et les outils les plus pertinents, ainsi que des conseils sur la façon de modéliser les aspects humains de chaque phase.

• Définir (Define)
• Mesurer (Mesure)
• Analyser (Analyse)
• Améliorer (Improve)
• Contrôler (Control)

Définir (Define)

Au cours de cette première phase, l’équipe et ses sponsors se mettent d’accord sur le projet et ses objectifs. En supposant qu’une ébauche de la charte de projet soit déjà en place, la principale tâche de l’équipe projet durant la phase Définir consistera à réaliser une analyse de ce que le projet devrait accomplir, et d’en confirmer la compréhension avec le(s) sponsor(s). Ils doivent s’entendre sur le problème qui impacte les clients, et sur comment le processus en cours ou les résultats produits ne répondent plus aux besoins , en s’appuyant sur l’avis du client, ou les attentes mesurables du client (Critical To Quality, CTQ).

Les résultats de la phase Définir sont les suivants :

• Un énoncé clair de l’amélioration prévue (charte de projet).
• Une carte de haut niveau des processus (SIPOC).
• Une liste de ce qui est important pour le client (CTQ).
• Un meilleur alignement du projet à la stratégie d’entreprise.
• Une contribution significative et mesurable au ROIC.

Les outils les plus couramment utilisés au cours de la phase de Définir sont :

• La charte de projet
• L’analyse des intervenants.
• Le schéma FIPEC (schématisation des Fournisseurs, Intrants, Processus, Extrants et Clients d’un processus) (aussi appelé SIPOC en anglais)
• L’avis du client.
• Le diagramme des affinités.
• Le modèle de Kano.
• L’arbre CTQ (Critical To Quality, représentation des facteurs clés de succès).

Les sections suivantes fournissent une brève description de ces outils et techniques.

Charte de projet

La charte est un contrat entre la Direction Générale de l’organisation et l’équipe du projet, créé à l’initialisation de ce dernier. Son objectif est de:

• Clarifier ce qui est attendu de l’équipe.
• Garder l’équipe concentrée sur les objectifs.
• Garder le projet et l’équipe alignés sur les priorités organisationnelles.

Analyse des intervenants

Un projet DMAIC exigera un changement fondamental dans les processus. Dans un effort pour atténuer la résistance au changement lorsque l’amélioration est mise en oeuvre, il est crucial d’identifier les parties prenantes dès le démarrage, et d’élaborer un plan de communication pour chacun d’eux. Les intervenants typiques comprennent notamment les managers, le personnel employé dans le processus à l’étude; en amont et en aval : les départements, les clients, les fournisseurs et les finances. Une communication régulière permet d’identifier de meilleures solutions et ainsi d’éviter les pièges.

Schéma SIPOC

Un schéma SIPOC est une carte de processus de haut niveau qui comprend les fournisseurs, les intrants, les processus, les extrants, et les clients. La qualité est évaluée en fonction de la sortie du processus. Elle est améliorée par l’analyse des données d’entrée et des variables de processus. Un exemple de schéma SIPOC est fourni ci-dessous.

Figure 1: Exemple de schéma SIPOC

L’avis du client

L’avis du client est un processus utilisé pour consigner les exigences et les retours du client (interne ou externe) afin d’y répondre par la meilleure qualité possible en termes de service ou de produit. Ce processus est totalement tourné vers la réactivité et l’innovation permanente, afin de s’adapter à l’évolution constante des besoins des clients au fil du temps.

L’avis du client est le terme utilisé pour décrire les besoins exprimés et non-exprimés du client, ainsi que ses exigences. L’avis du client peut être obtenu par différentes pratiques dont notamment : la discussion directe, les entretiens, les enquêtes, les groupes de discussion, les spécifications du client, l’observation, les données de garantie, les rapports de terrain, les cahiers de doléances, etc.

Ces données sont utilisées pour identifier les attributs de qualité indispensables à la fourniture d’un composant ou d’un matériel à intégrer dans le processus ou le produit. L’avis du client est vital à l’organisation pour :

• Décider quels produits et services offrir.
• Identifier les caractéristiques essentielles et les spécifications de ces produits et services.
• Décider où concentrer les efforts d’amélioration.
• Obtenir une mesure de référence de la satisfaction de la clientèle en rapport de laquelle l’amélioration sera mesurée.
• Identifier les facteurs clés de la satisfaction client.

Liste de produits typiques issus de l’avis du client :

• Liste des clients et des segments de clientèle.
• Identification des sources réactives et proactives de données pertinentes.
• Données verbales ou numériques qui identifient les besoins des clients.
• Définit les facteurs clés de succès (Critical To Quality, CTQ).
• Spécifications pour chaque exigence CTQ.

Diagramme des affinités

Un diagramme des affinités (parfois dénommé un “KJ”, d’après les initiales du créateur de cette technique, Kawakita Jiro), est un type particulier d’outil de remue-méninges (brainstorming). Un diagramme des affinités peut être utilisé pour :

• Rassembler un grand nombre d’idées, des opinions ou des problématiques et regrouper entre eux les éléments qui sont naturellement liés.
• Identifier, pour chaque groupe, un concept unique et commun à toutes ses composantes.

Figure 2: Exemple de diagramme des affinités

Un diagramme des affinités est particulièrement utile lorsque:

• Le chaos domine.
• L’équipe se noie dans un grand volume d’idées.
• Il faut créer de nouveaux paradigmes ou systèmes d’analyse.
• Des problématiques ou des thèmes généraux doivent être identifiés.

La construction d’un diagramme des affinités est un processus plus créatif que logique qui encourage la participation de tous, chacun étant encouragé à soumettre ses propres idées qui seront toutes prises en compte.

Modèle de Kano

Développé dans les années 1980 par le professeur Noriaki Kano, le modèle de Kano se fonde sur les concepts de qualité des clients et fournit un système de classement simple qui distingue les attributs essentiels et ceux de différenciation. Le modèle de Kano est un puissant outil de visualisation des caractéristiques du produit et de stimulation du débat au sein de l’équipe de conception. Kano a également produit une méthodologie rigoureuse pour la cartographie des réponses des consommateurs dans le modèle. Les caractéristiques des produits peuvent être classées comme suit:

• Seuils / Attributs de base

Les attributs qui doivent être présents pour que le produit soit efficace, et puisse être considéré comme un prix d’entrée. Toutefois, le client restera neutre à l’égard du produit, même avec une meilleure exécution de ces seuils et attributs de base.

• Attributs unidimensionnels (performance / linéaire)

Ces caractéristiques sont directement liées à la satisfaction du client. Fonctionnalités accrues et qualité de l’exécution se traduiront par une hausse de la satisfaction. Inversement, une diminution des fonctionnalités aura pour résultante une hausse de l’insatisfaction. Le prix des produits est souvent liée à ces attributs.

• Attributs avantageux (incentifs)

Les clients retirent une satisfaction importante d’une fonctionnalité et sont prêts à payer un supplément de prix. Cependant, la satisfaction ne diminuera pas si le produit ne possède pas la fonctionnalité. Ces caractéristiques sont souvent non-attendues par les clients et peuvent être difficiles à établir en fonction des besoins lors de la conception initiale. Elles sont parfois appelés besoins inconnus ou latents.

Un exemple de modèle de Kano est fourni ci-dessous.

Figure 3: Exemple de modèle de Kano

Arbre CTQ (Représentation des facteurs clés de succès)

Le but de la représentation des facteurs clés de succès est de convertir les besoins / les attentes des clients en exigences mesurables à implémenter.

Exemple : Un commerce de détail recevait un nombre important de plaintes de clients et relatives à la politique de garantie. En analysant les données de l’enquête conduite auprès de la clientèle et le développement de l’arbre CTQ, l’entreprise a été en mesure d’identifier les besoins essentiels à la satisfaction. Ces exigences sont devenues de facto la cible d’amélioration de la satisfaction du client. L’entreprise a ainsi éliminé les visites de garantie obligatoires, dès lors optionnelles. Cette décision a permis de restaurer la statisfaction des clients qui déploraient un nombre trop important de visites, tandis que l’ajout d’une visite optionnelle a donné satisfaction à ceux qui avaient une perception contraire. Porter de deux semaines à trois mois le délai pour la planification des visites de garantie a également permis d’éliminer les désagréments causés aux clients à faible disponibilité de temps.

L’entreprise est partie d’un besoin générique et difficile à mesurer (améliorer la satisfaction des client durant le cycle de garantie) et a pu développer des exigences spécifiques et mesurables, pour renforcer et améliorer la satisfaction client.

Figure 4: Exemple d’arbre CTQ (Représentation des facteurs clés de succès)

Mesurer (Mesure)

Un des principaux avantages de Six Sigma repose sur l’exigence d’une approche analytique factuelle et pilotée par les données. La plupart des autres méthodes d’amélioration, y compris Lean, ont tendance à aborder l’amélioration des processus sans avoir collecté suffisamment de données pour comprendre les causes profondes des problèmes. Il en résulte souvent des projets avortés, avec des résultats à court terme ou décevants. Combiner les données avec les connaissances et l’expérience est ce qui distingue fondamentalement l’amélioration véritable du simple bricolage de processus. L’un des objectifs de la phase de mesure est de repérer le lieu ou la source d’un problème aussi précisément que possible par la construction d’une connaissance factuelle des conditions de traitement existantes. Cette connaissance permet de restreindre l’éventail des causes potentielles nécessitant une enquête au cours de la phase d’Analyse. Une part importante de la phase Mesurer consiste à établir un niveau de capacité de base.

Les outils les plus couramment utilisés au cours de la phase de Mesure sont:

• Les matrices des priorités.
• L’efficacité du cycle de processus.
• L’analyse de la valeur de temps.
• Les diagrammes de Pareto.
• Les cartes de contrôle.
• Les diagrammes de production.
• L’Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité (Failure Modes and Effect Analysis, FMEA).

Les sections suivantes fournissent une brève description de ces outils et techniques.

Matrice des priorités

La matrice des priorités fournit un procédé de tri d’un ensemble diversifié d’éléments par ordre d’importance. Elle permet également d’identifier l’importance relative de chaque élément en y associant une valeur numérique. Ainsi, un article avec un score de 300 sera beaucoup plus important qu’un second présentant un score de 30, mais ne sera en revanche pas beaucoup plus important qu’un troisième ayant un score de 280. Les éléments sont comparés, évalués en fonction d’un ensemble de critères clés, et les scores pour chaque élément sont ensuite additionnés.

Figure 5: Exemple de matrice des priorités

L’efficacité du cycle de processus

Méthode de calcul permettant de déterminer la quantité de temps à valeur ajoutée en regard du temps total du cycle dans un processus.

Analyse de la valeur de temps

Graphique qui sépare visuellement la valeur ajoutée de temps à l’absence de valeur ajoutée de temps dans un processus.

Diagrammes de Pareto

Vilfredo Pareto, économiste italien au début du siècle, a étudié la distribution de la richesse de différents pays, et en a conclu qu’une minorité relativement stable (environ 20%) contrôlent la grande majorité (environ 80%) de la richesse d’une société. Cette même répartition a été observée dans d’autres domaines, ainsi baptisée l’effet de Pareto.

Figure 6: Exemple de diagramme de Pareto

L’effet de Pareto fonctionne à l’identique dans l’amélioration de la qualité : 80% des problèmes découlent généralement de 20% des causes. Les diagrammes de Pareto sont utilisés pour mettre en évidence le principe de Pareto en action, organisant les données de sorte de montrer comment quelques facteurs essentiels peuvent causer la plupart des problèmes qui se manifestent. Concentrer les efforts d’amélioration sur ces quelques problématiques sera gage d’un impact plus rapide et plus  mportant , ainsi que d’une rentabilité améliorée, contrairement aux efforts non-dirigés.

Cartes de contrôle

Chaque processus est de naturer à varier. Si vous écrivez votre nom dix fois, vos signatures seront tous semblables, mais aucune ne sera exactement identique aux autres. Il existe une variation inhérente selon des limites prévisibles. Si, alors que vous signez votre nom, quelqu’un pousse votre coude, vous obtenez une modification inhabituelle en raison de ce qu’on appelle une cause « particulière ». Si vous travaillez à la taille de diamants, et que quelqu’un pousse votre coude, la cause particulière peut s’avérer coûteuse. Pour de nombreux processus, il est important de relever les causes spéciales de variation dès qu’elles se produisent.

Figure 7: Exemple de carte de contrôle

Il existe également une cause commune de variation. Considérons un joueur de football. Si il a un bon contrôle, la plupart de ses tirs vont partir dans la direction souhaitée. Il y aura certes quelques variations, malgré tout modérées. S’il perd son sang froid et joue avec empressement les ballons, ses tirs deviendront imprécis; la variation augmente. Il peut ne se produire aucune cause spéciale (pas de vent, pas de changement de ballon), juste l’influence cette cause commune de variation. Le résultat: les passes sont moins précises et le jeu devient moins fluide et moins efficace. Au football, le contrôle est un avantage décisif. Il en va de même dans la plupart des processus : réduire la cause commune de variation permet d’économiser de l’argent.

Heureusement, il existe des cartes simples à utiliser qui facilitent l’identification des causes particulières et communes de variation à l’intérieur d’un processus, appelées cartes de contrôle ou tableaux de Shewhart, d’après le nom de leur inventeur, Walter Shewhart. Il existe de nombreuses sous-espèces de cartes de contrôle qui peuvent être appliquées aux différents types de données des processus les plus classiques.

Toutes les cartes de contrôle possèdent trois composantes de base :

• Un axe central, en général la moyenne arithmétique de tous les échantillons tracés.
• Des limites supérieures et inférieures de contrôle statistique qui définissent les contraintes de variation de la cause commune.
• Des données de performance tracées au fil du temps.

Diagrammes de production

Les diagrammes de production (souvent connus sous le nom de graphiques linéaires en dehors du domaine de gestion de la qualité), permettent de montrer la performance d’un processus dans le temps. Les tendances à la hausse ou à la baisse, les cycles, et les aberrations remarquables peuvent être repérées et donner lieu une enquête plus approfondie. Dans un diagramme de production, sont repésentés en ordonnées les événements, et en abscisses l’un intervalle de temps. Par exemple, le diagramme de production d’un hôpital pourrait tracer le nombre de retards lors des transferts des patients au cours d’une journée ou d’une semaine déterminée. Les résultats pourraient montrer qu’il se produit plus de retards à midi qu’à quinze heures. Analyser ce phénomène pourrait permettre de révéler de potentiels besoins d’amélioration. Les diagrammes de production peuvent aussi être utilisés pour suivre et de vérifier les améliorations déjà été mises en place afin de déterminer leur degré de réussite. En outre, une ligne moyenne peut être ajoutée à un diagramme de production pour mettre en évidence les variations de données par rapport à la moyenne.

Figure 8: Exemple de diagramme de production

L’Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité (FMEA)

Les procédures et les outils permettant d’identifier chaque mode de défaillance éventuel d’un processus ou d’un produit sont exploités pour déterminer son effet sur d’autres sous-éléments et / ou sur la fonction souhaitée du produit ou du processus. Le FMEA est également utilisé pour classer et hiérarchiser les causes possibles de défaillance, ainsi que pour développer et mettre en oeuvre les actions de prévention adéquates, en lien avec les responsables chargés de réaliser ces actions.

Analyser (Analyse)

La phase de Mesure a permis l’identification des performances de base du processus. En stratifiant les données à l’intérieur du modèle de performance de référence, il devient possible de localiser l’emplacement ou la source de problèmes par l’élaboration d’une connaissance factuelle des conditions de traitement existantes. La phase d’Analyse a pour objectifs d’étudier les hypothèses sur les causes réelles de problèmes, de confirmer ces hypothèses à l’aide des données, et enfin d’identifier la(les) cause(s) du problème. La(les) cause(s) vérifiée(s) constitueront alors la base des solutions dans la phase Améliorer.

Les outils les plus couramment utilisés dans la phase d’analyse sont les suivants :

• La méthode des Cinq pourquoi (5 Whys Analysis).
• Le remue-méninges (brainstorming).
• Les diagrammes de cause et d’effet (diagramme d’Ishikawa ou diagramme en arêtes de poisson).
• Les diagrammes des affinités.
• Les cartes de contrôle.
• Les diagrammes d’activité.
• Les diagrammes de Pareto.
• Les analyses de régression.
• Les diagrammes de dispersion.

La méthode des Cinq pourquoi (5 Whys Analysis)

La méthode des Cinq pourquoi est une technique de résolution de problèmes permettant de découvrir assez rapidement la cause d’un problème. Son application implique de considérer tout problème en se posant la question : « Pourquoi – qu’est-ce qui a causé ce problème ? »

En posant à plusieurs reprises la question « Pourquoi » (cinq est une bonne règle), il est possible d’isoler les symptômes pour révéler racine du problème. Très fréquemment, la cause originale d’un problème conduira à une autre question, puis à une autre encore. Bien que cette technique soit appelée les Cinq pourquoi, vous pourrez être amenés à répéter la procédure de questionnement un nombre variable et plus ou moins important de fois avant de parvenir à mettre au jour la cause profonde d’un problème.

Exemple d’une analyse des Cinq pourquoi :

1. Pourquoi est-ce que notre client le plus important est-il mécontent ? Parce que nos bicyclettes ont été livrées en retard le mois dernier.
2. Pourquoi nos bicyclettes ont-elles été livrées en retard  le mois dernier ? Parce que la production a pris du retard.
3. Pourquoi la production a-t-elle pris du retard? Parce qu’il y a une pénurie de roues.
4. Pourquoi subisssons-nous une pénurie de roues? Parce qu’un grand nombre de roues a été rejeté pour défaut de qualité.
5. Pourquoi avons-nous rejeté un si grand nombre de pièces ? Parce que le marché a été conclu avec un fournisseur moins cher dont la production s’avère de qualité inégale.

Remue-méninges (brainstorming)

Le remue-méninges consiste tout simplement à lister tous les idées avancées par un groupe en réponse à un problème donné ou une question. En 1939, une équipe dirigée par Alex Osborn a inventé le terme « remue-méninges ». Selon Osborn, le remue-méninges consiste à utiliser le cerveau de sorte de prendre d’assaut un problème de création et de le faire en mode commando, chaque participant attaquant un même objectif, avec la même audace. La créativité est encouragée en ne permettant qu’aucune idée puisse être évaluée ou discutée jusqu’à ce que tous les participants aient épuisé leur inspiration. Toutes les idées sont ainsi considérées comme légitimes, les plus farfelues étant bien souvent les plus fertiles. Les remue-méninges structurés produisent de nombreuses idées créatives à partir de nimporte quelle question centrale. Bien réalisé, il favorise la propension du cerveau humain pour la pensée latérale et la libre association.

Le remue-méninges aide à répondre à des questions spécifiques telles que:

• Quelles sont les opportunités face à nous cette année ?
• Quels sont les facteurs limitant la performance dans le département X ?
• Que pourrait être la cause du problème Y ?
• Que pouvons-nous faire pour résoudre le problème Z ?

Toutefois, un remue-méninges ne peut pas vous aider à identifier avec certitude des causes de problèmes, à classer des idées de façon pertinente, à sélectionnez des concepts clefs, ou à contrôler des solutions.

Diagrammes de cause et d’effet

Diagrammes d’Ishikawa ou diagrammes en arêtes de poisson

Le diagramme de cause et d’effet est une idée originale de Kaoru Ishikawa , pionnier des processus de gestion de la qualité dans les chantiers navals de Kawasaki, et devenu l’un des pères fondateurs de la gestion moderne. Le diagramme de cause et d’effet est utilisé pour explorer toutes les causes réelles ou potentielles (entrées) qui aboutissent à un effet unique (sortie). Les causes sont classées selon leur niveau d’importance ou de détail, résultant en une représentation des relations et de la hiérarchie des événements. Le diagramme de cause et d’effet aide à rechercher des causes, à identifier les domaines où il peut y avoir des problèmes, et à comparer l’importance relative des différentes causes.

Les causes dans un diagramme de cause et d’effet sont souvent organisées en quatre grandes catégories. Bien que ces catégories peuvent être de toutes natures, on retrouve généralement :

• La main-d’oeuvre, les méthodes, les matériaux et les machines (recommandé pour la fabrication).
• Le matériel, les politiques, les procédures, et le personnel (recommandé pour l’administration et les services).

Ces lignes directrices peuvent être utiles mais ne doivent pas être utilisées si elles limitent le diagramme ou s’avèrent inappropriées. Les catégories utilisées doivent répondre aux besoins identifiés et spécifiques à chaque contexte. Bien souvent, il est possible de créer les branches de l’arbre de cause et d’effet à partir des items tirés des diagrammes des affinités déjà évoqués.

Figure 9: Exemple de diagramme de cause et d’effet

Diagrammes d’activité

Les diagrammes d’activité sont des cartes ou des représentations graphiques d’un processus. Les étapes d’un processus sont représentées avec des formes symboliques, et le flux du processus est indiqué par des flèches reliant les symboles. Les programmeurs ont popularisé les diagrammes d’activité dans les années 1960, les ayant utilisé intensivement pour cartographier le comportement des programmes.

Dans les travaux d’amélioration de la qualité, les diagrammes d’activité sont particulièrement utiles pour montrer comment un processus fonctionne réellement ou pourrait fonctionner idéalement. Les diagrammes d’activité peuvent aider à vérifier si les étapes d’un processus sont logiques, à révéler des problèmes ou des interprétations erronées, à définir les limites d’un processus, et à développer une base commune de connaissances à propos d’un processus.

Cartographier un processus conduit souvent à mettre en lumière des redondances, des retards, des impasses et des détours qui seraient autrement passés inaperçus ou simplement ignorés. Mais les diagrammes d’activité ne fonctionnent pas si ils ne sont pas strictement exacts, si les membres de l’équipe ont peur de décrire ce qui se passe réellement, ou si l’équipe est trop éloignée du fonctionnement effectif du processus.

Il existe de nombreuses variétés de diagrammes d’activité, et de nombreux symboles sont à disposition. L’expérience a montré qu’il existe trois types principaux adaptés à presque toutes les situations :

• Les diagrammes d’activité de haut niveau ne cartographient que les principales étapes d’un processus dont elles fournissent un bon aperçu :

Figure 10: Exemple de diagramme d’activité de haut niveau

• - Les diagrammes d’activité détaillés déplient étape par étape tous les événements et les décisions d’un processus :

Figure 11: Exemple de diagramme d’activité détaillé

• - Les diagrammes de déploiement structuent le diagramme en colonnes, chacune représentant une personne ou un service au sein d’un processus :

Figure 12: Exemple de diagramme de déploiement

Analyse de régression

L’analyse de régression est un modèle de prévision statistique qui décrit et évalue la relation entre une variable donnée, généralement appelée la variable dépendante, et une ou plusieurs autres variables dites indépendantes.

Les modèles d’analyse de régression sont utilisés pour aider à prédire la valeur d’une variable par rapport à une ou plusieurs autres variables dont les valeurs peuvent être prédéterminés.

Diagrammes de dispersion

Les nuages de points (également appelés diagrammes de dispersion) sont utilisées pour étudier la relation possible entre deux variables se rapportant à un même événement. Une ligne droite de meilleur ajustement utilisant la méthode des moindres carrés, est souvent incluse.

Figure 13: Exemple de nuage de points

Eléments à rechercher dans un nuage de points :