ITIL - Chapitre 4 - Les démarches qualité - Suite

7. BS1500 : ITIL bientôt dans ISO 9000 ?

La norme BS 15000 (British Standard for IT Service Management) est le premier standard mondial destiné spécifiquement à la gestion des services informatiques. Il décrit un ensemble de processus de gestion pour optimiser la fourniture de services à l'entreprise et ses clients.

BS 15000 est complémentaire de l'approche par processus définie dans le cadre d'ITIL. C’est la norme, le standard que ses promotteurs essaient actuellement de rattacher à ISO-9000 en tant que contribution à part entière.

BS 15000 est constitué de deux parties :

BS 15000 – 1 est un ensemble de dix sections qui constituent la spécification formelle, les exigences qui permettent à une organisation d’atteindre un bon niveau de qualité dans la gestion des services. Ces dix sections sont :

.Le scope

.Termes et définitions

.Exigences du système de management

.Planifier et implémenter la gestion des services

.Planifier et implémenter les modifications de services

.Le processus de livraison

.Les processus de gestion des relations

.Les processus de résolution

.Les processus de contrôle

.Le processus de gestion des versions

BS 15000 – 2 est un ensemble de documents normatifs qui permettent d’aider une organisation à se préparer à l’audit BS 15000 ou simplement à préparer une démarche d’amélioration des processus selon le schéma d’ITIL. C’est le code de pratique de BS 15000 qui permet à une organisation de “ s’y mettre concrétement ”

Les meilleures pratiques d ITIL pour un meilleur contrôle des services :

ITIL se concentre sur les processus métier, et est le fruit de l’expérience de centaines de praticiens de la gestion des services. A partir du canevas de meilleures pratiques d’ITIL, un standard a vu le jour, c’est BS15000.

La logique d’ITIL est bien entendu reprise par BS 15000, à savoir que les actrivités sont réparties entre le “ service support ” et le “ service delivery ”.

Les besoins motivant sa création :

L’idée sous-jacente à la création du standard est bien entendu la possibilité d’auditer, homologuer, certifier. Pour avoir un système auditable, ce dernier doit être formalisé selon des règles. Pour renforcer le poids d’ITIL, le passage à une norme de type ISO permettra à l’ensemble des acteurs des services de gagner en crédibilité.

C’est pourquoi BS15000 s’appuie à la fois sur practivces ITIL, et sur le “BSI Code of Practice for IT Service Management (PD0005) ”. L’autre idée maîtresse est de rattacher à ISO la série de normes BS1500x pour bénéficier de la visibilité et de l’image d’ISO, tout en restant axé fortement sur la gestion des services. Plus exactement, BS15000 pourrait donner naissance à nouveau ISO-15xxx. Le rattachement à ISO, en donnant plus de force à la norme, rendrait également sa roadmap plus crédible vis-à-vis des décideurs.

Fournir des lignes directrices non propriétaires pour l’industrie des services : c’est l’idée qu’essaient de promouvoir les managers sensibles à la qualité de service : offirir des méthodes qui garantissent l’obtention du niveau de service défini avec le client, dans le respect des délais et des coûts (et sans ré-inventer la roue).

La place d’ITIL :

ITIL fournit une couche de liaison entre les procédures maisons et les codes de bonnes pratiques du référentiel BS15000 : en imaginant une pyramide de la consolidation des méthodes qualité, on pourrait dire que la première couche est celle des procédures maison, la seconde leur implémentation selon les standards ITIL, la troisième est la conformité au standard BS15000, et le pinacle est ISO

[Fig 6 : les domaine couverts par BS15000 – in BS15000 - IT Service Management Standard 2001 :1]

 

 

8. Le Microsoft Operation Framework

 

Microsoft a bien compris l’intérêt d’ITIL d’un point de vue opérationnel vraisemblablement, et d’un point de vue marketing sans aucun doute. C’est pourquoi la firme de Redmond a mis en place 2 guides complémentaires dans la définition et la gestion des services : MOF et MSF, soit Microsoft Operation Framework et Microsoft Soluttions Framework. Leur raisonnement est le suivant : pour répondre au mieux aux besoins de ses clients, l'équipe informatique doit accomplir deux tâches essentielles :

• Comprendre l'objet du service en question et créer une solution.
• Mettre la solution en oeuvre pour fournir le service requis.


Le premier point est l’objet du guide MSF, le second est abordé par MOF qui reprend l’ensemble des directives d’ITIL, et ajoute “ sa propre couche ”.

1. MSF

MSF, qui permet de définir le produit et/ou le service, se veut un intermédiaire entre le modèle de processus dit “ en cascade ”, correspondant à une approche analytique classique avec ses point de validation, et le modèle de processus “ en spirale ”, approche utilisée pour les petits développements et le RAD, dans lequel le prototypage est rapide et proche des spécifications, et de fréquentes allées et venues permettent de revenir rapidement sur les spécifications pour les adapter aux contraintes découvertes. Cette seconde approche est plus systémique. La structure de MSF veut allier le meilleur des deux mondes dans sa démarche processus.

 2. MOF

MOF, quant-à lui, est un framework directement inspiré d’ITIL. Il ajoute simplement des outils et dimensions supplémentaires par rapport à l’approche de base d’ITIL : en effet, au modèle de processus d’ITIL, Microsoft ajoute un modèle d’équipe et un modèle de risque. Par ailleurs, ITIL fait référence de manière assez vague à la roue du progrès de Deming, Microsoft “ se l’approprie ” et en fait une étape incontournable et instanciée de chacune des étapes de sa démarche.

Le modèle de processus MOF :

Les processus ITIL sont “ mappés ” sur un PDCA et organisés en quatre quadrants.

De nombreux processus de la structure MOF sont directement basées sur la bibliothèque ITIL de l'OGC. Font exception à la règle les fonctions liées à la gestion des effectifs (dans le quadrant d'optimisation) ainsi que toutes les fonctions du quadrant d'exploitation. La bibliothèque ITIL ne couvre donc pas ces aspects, car elle est indépendante des plates-formes.


Par conséquent, le quadrant d'exploitation est celui pour lequel la majorité des conseils de la structure MOF sont spécifiques aux produits et technologies Microsoft.
 
Principes du MOF
 
Le modèle de processus de la structure MOF se base sur quatre grands principes :

Architecture structurée. Le modèle de processus est une architecture qui structure toutes les activités opérationnelles qu'impliquent les systèmes informatiques stratégiques pour faciliter leurs interactions avec des environnements de plus en plus complexes.

Cycle de vie rapide, perfectionnement itératif. L'évolution des opérations informatiques se poursuit à un rythme de plus en plus soutenu. Cette évolution rapide s'explique directement par le fait que les entreprises doivent s'adapter et innover en permanence pour rester compétitives. C'est la raison pour laquelle la structure MOF a intégré le concept de cycle de vie itératif qui permet non seulement d'introduire rapidement des changements, mais aussi d'évaluer et d'améliorer sans cesse l'environnement global d'exploitation.

Gestion basée sur la révision. Le modèle de processus prévoit des révisions à des stades clés du cycle de vie. Lors de ces révisions, les équipes évaluent la performance des activités liées aux versions ainsi que les activités opérationnelles permanentes ou quotidiennes. Ces grandes révisions offrent aussi aux membres de la direction la possibilité de s'impliquer dans le processus lorsque leur contribution est la plus utile.

Gestion intégrée des risques. Aujourd'hui, les opérations informatiques sont plus importantes et plus complexes que jamais et les défaillances opérationnelles ne peuvent plus guère échapper aux clients et aux utilisateurs d'informatique du monde entier. Il est donc crucial d'intégrer la gestion des risques dans les opérations pour écarter la menace qu'une défaillance fait peser sur les entreprises.

Le modèle d'équipe MOF
 
Le modèle d'équipe de la structure MOF décrit :


• des groupes de rôles tirés des pratiques recommandées pour structurer les équipes opérationnelles
• les activités et compétences clés de chaque groupe de rôles
• la dotation en personnel des équipes selon la taille et le type d'organisation
• les rôles qui peuvent être combinés efficacement
• les principes fondamentaux qui facilitent la mise en oeuvre d'environnements informatiques distribués sur la plate-forme Microsoft
• les liens entre le modèle d'équipe de la structure MOF et celui de la structure MSF

En fait le modèle d’équipe de MOF donne une vision intégrée de ce que peut être une organisation conforme à ITIL dans sa définition des rôles des différents intervenants. Un peu comme pour l’utilisation de la roue de Deming, c’est une proposition de modèle d’organisation instancié compatible avec le modèle de processus d’ITIL.

Le modèle de risques de MOF :

Le deuxième modèle complémentaire proposé par Microsoft dans MOF est le modèle de risques. Ce modèle se base sur les principes.suivants :

évaluation constante des risques. L'équipe ne cesse de rechercher de nouveaux risques et les risques existants sont régulièrement réévalués.

Intégration de la gestion des risques dans chaque rôle et chaque fonction. à un haut niveau, ce principe implique que chaque rôle TI partage les responsabilités de gestion des risques et que chaque processus informatique est conçu compte tenu de la gestion des risques.

Traitement positif de l'identification des risques. Pour que la gestion des risques porte ses fruits, les membres de l'équipe doivent avoir envie d'identifier les risques sans craindre de menaces ni de critiques.

Planification basée sur les risques. Préserver un environnement revient souvent à introduire des changements dans un certain ordre. Lorsque c'est possible, il est préférable que l'équipe introduise les changements les plus risqués en premier lieu afin d'éviter de consacrer du temps et des moyens à des changements qui ne pourront être appliqués.

établissement d'un niveau acceptable de formalité. La réussite passe par l'élaboration d'un processus que l'équipe comprend et applique.

étape 1 : Identification. Cette étape sert à déterminer l'origine du risque, la nature de la défaillance, la condition ainsi que les conséquences opérationnelles et commerciales.

étape 2 : Analyse. Evaluation de la probabilité et l'impact du risque qui seront utilisés pour calculer la valeur d'exposition au risque.

étape 3 : Planification. Définition des mesures permettant d'éviter totalement le risque, de le transférer à une autre partie ou de réduire son impact ou sa probabilité, voire les deux.

étape 4 : Suivi. Cette étape sert à recueillir des informations sur la manière dont divers éléments du risque évoluent au fil du temps.

étape 5 : Contrôle. Cette étape sert à mettre en oeuvre les mesures prévues lorsque certains changements interviennent.

ITIL - Chapitre 4 - Les démarches qualité, une culture processus dominante

En matière de qualité IT, les référentiels et recueils de bonnes pratiques s'appuient surtout sur une approche processus. Pour le développement informatique en particulier, des référentiels comme SO/IEC 15504, évaluation de processus du logiciel (norme également connue sous le nom de SPICE : Software Process Improvement and Capability dEtermination) ou encore la famille de référentiels CMM (Capability Maturity Model) offrent des modèles de processus et des démarches d'amélioration des pratiques selon un cheminement progressif par niveaux de maturité.

Pour les services informatiques (exploitation/production), ITIL (IT Infrastructure Library) est le recueil de bonnes pratiques relatives à la gestion des services IT qui fait référence en la matière. Sans être spécifique au monde IT, la série de normes ISO 9000:2000 reste incontournable en terme d'exigences pour des systèmes de management de la qualité. Ceci est d'autant plus vrai depuis la parution de la version 2000 des normes qui s'appliquent plus facilement au monde IT que la version précédente. En terme de sécurité IT, des référentiels se préoccupent des contrôles techniques (Common Criteria - ISO 15408 - Common Criteria for Information Technology Security Evaluation) et organisationnels (BS7799- Bristish Standards Code of Practices for Information Security Management) mis en place dans le cadre d'un processus de gestion globale formalisé dans la norme ISO13335 (Guidelines for the Management of IT Security) et soutenu par diverses méthodes publiques ou commerciales (EBIOS, OCTAVE, CRAMM...).

Le modèle propre au développement logiciel le plus largement répandu est le Capability Maturity Model (CMM) du Software Engineering Institute, bientôt remplacé par le CMMI, qui fournit un cheminement logique pour l’amélioration des processus. Ce modèle comporte cinq niveaux de maturité, dont l’atteinte est officialisée par une évaluation formelle. Plus générique, la famille ISO 900x vise l’amélioration continue du système de gestion de la qualité. Ses normes sont de deux types : certaines mènent à une accréditation, d’autres constituent des lignes directrices permettant la standardisation des pratiques dans une organisation. CMM et ISO 900x dérivent des mêmes principes de gestion de la qualité totale.

Pour sa part, l’International Institute of Electronical and Electronic Engineers (IEEE) a fixé plusieurs normes touchant le logiciel, que ce soit pour le concept d’opération, la spécification système, la spécification logicielle, le plan d’assurance qualité, etc.


Présentation des principales méthodes qualité orientées processus

1. L'approche qualité totale : ISO 9000

2. L'approche production industrielle : six Sigma
3. Le modèle COBIT

4. La balanced ScoreCard

5. Le modèle CMM

6. Le modèle SPICE
7. BS15000
8. Le modèle Microsoft

 

1. L'approche qualité totale : ISO 9000

 

Contexte :

Les normes ISO 9000 sont nées en 1987. Les deux révisions en 1994 et 2000 qu'elles ont vécues, en font aujourd'hui de véritables outils de progrès adaptables à tous les domaines de l'activité sociale et économique et à toutes les tailles de structures. La dernière version, sortie en décembre 2000.

Pourquoi les normes ont-elles été révisées?

Les principales raisons des révisions de l'année 2000 sont les suivantes: souligner la nécessité de mesurer la satisfaction des clients, répondre aux besoins de documents d'utilisation plus conviviale, assurer la cohérence entre les exigences et les lignes directrices relatives au système de management de la qualité, promouvoir l'utilisation de principes génériques de management de la qualité par les organismes, et améliorer la compatibilité de ces normes avec la norme ISO 14001

Structure de la nouvelle famille ISO 9000 - 4 normes principales composent la nouvelle famille:

ISO 9000:2000 Systèmes de management de la qualité - Principes essentiels et vocabulaire. Établit un point de départ pour comprendre les normes et définit les termes et définitions fondamentaux utilisés dans la famille ISO 9000, qui permettent d'éviter tout malentendu dans leur utilisation.

ISO 9001:2000 Systèmes de management de la qualité - Exigences. Norme sur les exigences à utiliser pour évaluer votre aptitude à répondre aux exigences des clients et aux exigences réglementaires applicables et, par conséquent, pour traiter de la satisfaction clients. Cette norme est désormais la seule norme de la famille ISO 9000 permettant d'effectuer une certification par tierce partie.

ISO 9004:2000 Systèmes de management de la qualité - Lignes directrices pour l'amélioration des performances. Cette norme de lignes directrices fournit des conseils pour une amélioration continue de votre système de management de la qualité qui permettra à toutes les parties d'en tirer avantage par une satisfaction continue des clients.

ISO 19011 Lignes directrices relatives aux audits de systèmes de management qualité et environnement (en cours d'élaboration). Des lignes directrices permettent de vérifier l'aptitude de votre système à réaliser des objectifs qualité définis. Vous pouvez utiliser cette norme en interne ou pour procéder à l'audit de vos fournisseurs. Les normes ISO 9001, ISO 9002, et ISO 9003 ne forment plus qu'une norme révisée ISO 9001. La nouvelle norme ISO 9001 comprend dans sa nouvelle version 9 chapitres par rapport aux 20 chapitres de la version 1994 : 5 concernent l'organisation de la norme et 4 autres correspondent aux 20 chapitres de la norme version 1994. De même¸ il n'existe plus qu'une seule norme de recommandation, la norme ISO 9004 :2000 Vue d'une manière globale, la norme ISO 9001 version 2000 comprend les exigences relatives aux QUI et QUOI alors que la norme ISO 9004 version 2000 donne des indications sur le COMMENT.

Transition vers ISO 9001:2000 : Passer de la démonstration de la conformité (version de 1994) à la démonstration de l'éfficacité. Quand ? : Un groupe mixte formé par le Forum international de l'accréditation, l'ISO/TC 176 et l'ISO/CASCO est convenu d'une période de “transition” de 3 ans durant laquelle les certifications accréditées selon les normes de 1994 et selon l'ISO 9001:2000 pourront coexister. Cette période de transition prendra fin le 15 décembre 2003. A cette date, tous les organismes souhaitant conserver une certification accréditée devront avoir fait migrer leur système de management de la qualité pour conformité à l'ISO 9001:2000.

Les normes révisées relatives au système de management de la série ISO 9000 : 2000 sont fondées sur huit principes de management.

Principe 1 : Ecoute client Les organismes dépendent de leurs clients, il convient donc qu'ils en comprennent les besoins présents et futurs, qu'ils satisfassent leurs exigences et qu'ils s'efforcent d'aller au-devant de leurs attentes.

Principe 2 : Leadership Les dirigeants établissent la finalité et les orientations de l'organisme. Il convient qu'ils créent et maintiennent un environnement interne dans lequel les personnes peuvent pleinement s'impliquer dans la réalisation des objectifs de l'organisme

Principe 3 : Implication du personnel Les personnes à tous niveaux sont l'essence même d'un organisme et une totale implication de leur part permet d'utiliser leurs aptitudes au profit de l'organisme

Principe 4 : Approche processus Un résultat escompté est atteint de façon plus efficiente lorsque les ressources et activités afférentes sont gérées comme un processus.

Principe 5 : Management par approche système Identifier, comprendre et gérer des processus corrélés comme un système contribue à l'efficacité et l'efficience de l'organisme à atteindre ses objectifs.

Principe 6 : Amélioration continue Il convient que l'amélioration continue de la performance globale d'un organisme soit un objectif permanent de l'organisme.

Principe 7 : Approche factuelle pour la prise de décision Les décisions efficaces se fondent sur l'analyse de données et d'informations.

Principe 8 : Relations mutuellement bénéfiques avec les fournisseurs Un organisme et ses fournisseurs sont interdépendants et des relations mutuellement bénéfiques augmentent les capacités des deux organismes à créer de la valeur.

L'approche processus

Les nouvelles normes internationales encouragent l'adoption d'une approche processus lors du développement, de la mise en œuvre et de l'amélioration de l'efficacité d'un système de management de la qualité, pour accroître la satisfaction des clients par le respect de leurs exigences. Pour qu'un organisme fonctionne de manière efficace, il doit identifier et gérer de nombreuses activités corrélées. Toute activité utilisant des ressources et gérée de manière à permettre la transformation d'éléments d'entrée en éléments de sortie, peut être considérée comme un processus. L'élément de sortie d'un processus constitue souvent l'élément d'entrée du processus suivant.

"L'approche processus " désigne l'application d'un système de processus au sein d'un organisme, ainsi que l'identification, les interactions et le management de ces processus. L'un des avantages de l'approche processus est la maîtrise permanente qu'elle permet sur les relations entre les processus au sein du système de processus, ainsi que sur leurs combinaisons et interactions. Le modèle de système de management de la qualité basé sur les processus présenté ci-dessous illustre les relations entre les processus suivants : Responsabilité de la direction, Management des ressources, Réalisation du produit ou service et Mesures, analyse et améliorations.

- Responsabilité de la direction C'est une partie fortement renforcée dans la nouvelle norme et qui était source de nombreuses non-conformités. La direction doit identifier les attentes du client et mettre tout en œuvre pour que celles-ci soient respectées. Pour cela, il faut fixer les objectifs et les ressources, permettre une bonne communication de la politique qualité au sein de l'entreprise et nommer des responsables. La direction est également responsable du management de la qualité. - Management des Ressources Ces ressources doivent être déterminées par l'entreprise et ajustées aux objectifs. Par exemple pour les ressources humaines il s'agit d'ajuster la formation et les qualifications.

Cet aspect particulier de la nouvelle génération de normes iso rejoint tout à fait les recommandations imposées par la mise en œuvre de la loi Sarbanes-Oxley, notamment l’alinea 802 sur la responsabilité pénale des dirigeants qui certifient les comptes des entreprises : des erreurs manifestes sur les comptes des sociétés peuvent être sanctionnées de 20 ans de prison s’il est prouvé que le dirigeant a sciemment manipulé les comptes, et 10 ans si il “ ignorait “ les pratiques incriminées.

Autres ressources :

- Le temps

- Les finances

- Les infrastructures

- L'information

- L'environnement de travail

- Réalisation du produit et/ou des services

Il s'agit du respect d'un processus permettant la satisfaction du client. Il existe un point très intéressant des nouvelles normes concernant la conception. Les entreprises recherchaient souvent une certification ISO 9002 mais celle-ci a maintenant disparue. Cependant les entreprises n'ayant pas d'activité de conception pourront toujours exclure ce processus lors de leur mise aux normes, en revanche, si conception il y a, l'entreprise ne pourra en ignorer l'existence et devra en garantir l'efficacité. - Mesures, analyses et amélioration- A ce niveau, la principale nouveauté porte sur l'exigence d'effectuer des mesures de performances concernant les processus. Aucun outil n'est préconisé

2. Six Sigma

 

Six Sigma est une démarche qualité / processus issue du monde de l'industrie. C'est Motorola qui l'a créé en 1986 ; au départ c'était le surnom donné la démarche qualité démarrée dans l'entreprise. A partir de là une méthodologie complète de mesure et d'amélioration de la qualité, essentiellement basée sur des outils statistiques, a vu le jour. Cette démarche, d'abord portée par des industriels comme General Electric ou Kodak, est maintenant appliqué dans l'industrie informatique dans certaines grosses structures en quète de qualité totale.  

Six Sigma vise à réduire la variabilité de ce que l'on produit par l'amélioration continue des processus. C'est une référence à la notion de "presque parfait" : elle fait référence à la courbe de Gauss de densité de distribution d'une variable aléatoire, dans laquelle x est la distribution moyenne et sigma la déviation standard : sigma mesure l’écart-type d’une population d’erreurs

La représentation graphique, célèbre s'il en est, est la suivante :

Ce graphe illustre à quel niveau de standard, de conformité correspond Six Sigma : 99,9997 %, la valeur de 100 % étant impossible à atteindre car la courbe est asymptotique à l'axe des absices.



Les principes de la méthode :

Utiliser chaques étape du processus et non le processus dans sa globalité : le calcul d'une valeur Six Sigma passe donc par le calcul de la valeur de chaque étape, et la valeur produite par le processus est égale au produit des valeurs calculées à chaque étape du processus.

Le modèle DMAIC est au coeur de l’approche Six Sigma, qui se présente comme une méthode systématique d’analyse et d’amélioration des processus d’affaires. Ce modèle comprend cinq phases, d’où le modèle tire son nom :

Définir les occasions

Mesurer la performance

Analyser les occasions

Améliorer(Improve) la performance

Contrôler la performance (IYEN03).

Ce ne sont pas les organisations qui sont certifiées Six Sigma, mais les individus (ceinture verte, ceinture noire), ce qui rend à peu près impossible la comparaison des organisations qui ont adopté cette approche.

3. Le modèle COBIT

La mission de COBIT se formule comme suit : “ Étudier, concevoir, diffuser et promouvoir un ensemble international moderne et universel d’objectifs de contrôle en matière de technologie de l’information pour les besoins quotidiens des gestionnaires et des vérificateurs ”


COBIT procède selon le principe suivant : Pour obtenir l’information nécessaire à l’atteinte de ses objectifs, l’entreprise doit gérer ses ressources informatiques selon des processus, eux-mêmes regroupés par grands domaines fonctionnels couvrant toute l’activité informatique. COBIT retient ainsi 32 processus pour 4 domaines fonctionnels. Ce sont des objectifs de contrôle de haut niveau. Ils se composent de 271 tâches qui correspondent aux objectifs de contrôle détaillés ou points d’audit.


COBIT (Control Objectives for Information and Related Technology ) est un cadre de référence international basé sur l’observation des bonnes pratiques, en matière de gouvernance et de contrôle de l’IT. Il permet d'aider à rencontrer les besoins de gestion tout en réduisant les écarts entre les risques d'affaires, les besoins de contrôle et les défis technologiques en fournissant une structure de travail logique permettant de lier les processus, les ressources et les informations aux stratégies et objectifs des entreprises en y ajoutant une valeur. De ce fait, il a pour objectif d’aider les dirigeants à comprendre et à gérer les risques informatiques, donc à maîtriser l’informatique et les systèmes d’information. COBIT a été créé par l'ISACA (Information Systems Audit and Control Association) représentée en France par l'AFAI (Association Française de l'Audit et du conseil Informatique).


COBIT procède selon le principe suivant : Pour obtenir l’information nécessaire à l’atteinte de ses objectifs, l’entreprise doit gérer ses ressources informatiques selon des processus, eux-mêmes regroupés par grands domaines fonctionnels couvrant toute l’activité informatique. COBIT retient ainsi 32 processus pour 4 domaines fonctionnels. Ce sont des objectifs de contrôle de haut niveau. Ils se composent de 271 tâches qui correspondent aux objectifs de contrôle détaillés ou points d’audit.

COBIT c'est un peu ITIL en version compliquée, pour faire simple  :-)
 

Control Objectives for Information and related Technology (COBIT) (“ Objectifs de contrôle pour la technologie de l’information et les technologies connexes ”), qui en est à sa troisième édition, contribue à répondre aux besoins multiples de gestion en reliant risques opérationnels, besoins de contrôle et problèmes techniques. COBIT permet d’adopter de bonnes pratiques dans l’ensemble d’un domaine et d’un cadre de processus en présentant les activités selon une structure gérable et logique. On entend ici par “ pratiques optimales ” un consensus d’experts; ces pratiques optimiseront les investissements consentis et fourniront une mesure permettant de faire un constat lorsque quelque chose va mal.



Le modèle COBIT peut s'enorgueillir d'un bon palmarès principalement outre Altlantique : l'État du Kansas utilise les standards COBIT dans le cadre de sa stratégie de gouvernement virtuel. L'objectif est de conserver des coûts réduits et d'offrir des services conséquents aux utilisateurs. Dell Computer a intégré des éléments COBIT à sa politique Control Self Assessment (CSA), visant à produire un audit de gestion susceptible d'aider la société à maintenir un haut degré de qualité. Sa qualité principale est par contre aussi sa faiblesse : son exhaustivité en fait une démarche beaucoup plus lourde qu’ITIL à mettre en œuvre.


4. Le Balanced ScoreCard

Le Balance ScoreCard (BSC), a initialement été développé en 1993 par Robert S Kaplan de ‘Harvard school of business’ et le consultant David Norton pour l’ensemble des organisations et ceci quels que soient leurs domaines d’activités. Ces auteurs définissent le BSC comme un cadre conceptuel (framework) offrant une infrastructure multidimensionnelle pour décrire, implanter et maintenir la stratégie de l’organisation à tous ces niveaux en liant au travers d’une structure logique des objectifs, des indicateurs, des cibles et des mesures. Le but d’un BSC est de traduire la vision et la mission d’une unité ou de l’entreprise dans un ensemble d’objectifs à travers de l’identification de facteurs clefs de succès et des indicateurs clefs de succès et de performance. Il est aussi un cadre de gestion des performances qui permet aux entreprises de conduire des mesures et des suivis basés sur les stratégies.



Une nouvelle génération de tableau de bord ?


Au travers du BSC, une organisation supervise ses performances courantes (finance, satisfaction du client et le résultat du processus d’entreprise) et ses efforts pour s’améliorer (les processus, la formation de ses employés et l’amélioration du système d’information) donc son habileté à apprendre et à innover. Le BSC est une évolution des concepts inclus dans le tableau de bord. Il fournit alors une vue de l’entreprise construite sur une organisation globale de la performance. Pour ce faire, il intègre les mesures financières avec d’autres indicateurs de performances clefs autour de la perspective client, de la perspective processus interne de l’organisation et finalement autour de la perspective “croissance, apprentissage et innovation”. On doit remarquer que le BSC n’est pas une liste statique de mesures mais plutôt une infrastructure pour implanter et aligner les programmes complexes du changement de manière à gérer les organisations en mettant l’emphase sur leurs stratégies. Un BSC doit être utilisé pour traduire la stratégie en action et cela selon plusieurs perspectives.


• Financière : dans le secteur privé les objectifs financiers représentent généralement une vue claire à long terme pour la recherche de profits des organisations, opérant dans unenvironnement commercial pur. Les considérations financières pour les organisations sont en général un cadre de contraintes mais sont rarement l’objectif primaire des système d’information. Par contre les organisations sont jugées sur leur capacité à optimiser la ressource financière (car cette contrainte porte sur une ressource).


• Processus de gestion interne : cette perspective met l’accent sur l’efficacité de la gestion interne en termes de capacité à assurer la satisfaction du client. Afin d’être en ligne avec les objectifs stratégiques des métiers et obtenir un bon niveau de satisfaction des clients, l’organisation doit identifier les points clés de succès,


• Apprentissage,croissance et innovation : cette perspective examine les habilités des employés, la qualité des systèmes d’information et les effets de l’alignement de l’organisation à supporter la réalisation des buts de l’organisation. Le processus aura du succès seulement si des employés motivés et qualifiés, sont alimentés avec une information à temps, et réalisent ces dernières activités. Cette perspective est particulièrement importante pour les organisations qui se retrouvent dans des environnements changeants.


Les BSC représentent une des infrastructures adoptées avec succès dans les organisations au cours de dernières années. Une de ses plus grandes forces est le lien prévu entre les niveaux stratégiques et le niveau opérationnel grâce à une gestion qualitative et quantitative utilisant une série d’indicateurs divisés selon quatre perspectives. Quelques travaux préliminaires de recherche ont déjà été accomplis pour introduire le cadre du BSC dans le domaine du génie logiciel mais il manque encore plusieurs pièces conceptuelles pour offrir à l'industrie du logiciel un ensemble complet et facile d'utilisation.


5. Le modèle CMM (ISO 15504)

Au milieu des années 80, le Department of Defense (DOD) américain lançait un appel d’offre pour l’élaboration d’un référentiel de critères permettant d’évaluer la capacité de ses fournisseurs. Après une lente mais nécessaire maturation, la première version du "Modèle d’évolution des capacités logiciel" (Capability Maturity Model®) voyait le jour en 1991, fruit du travail conjoint du Software Engineering Institute (SEI), un centre de recherche financé par le DOD, et de Mitre Corporation, une organisation à but non lucratif.


Cette première version était composée d’une liste de pratiques réparties par secteurs clés (gestion des exigences, planification de projet, etc.), sur lesquelles s’appuyait une méthode d’évaluation du niveau de maturité d’une entreprise dans le domaine du développement logiciel. Les niveaux de maturité étaient répartis sur une échelle allant de 1 (initial) à 5 (en amélioration continue). Deux ans plus tard, en 1993, le SEI rendait public une version améliorée de son modèle, CMM version 1.1.


Le modèle CMMI s’articule autour d’un certain nombre de secteurs clés (25 au total dans sa version complète, mais il existe des modèles allégés pour des applications à des domaines particuliers), auxquels sont associés des objectifs et des pratiques. On distingue des objectifs génériques et des objectifs spécifiques, selon qu’ils sont partagés par tous les secteurs clés ou qu’ils sont spécifiques à un secteur en particulier. Idem pour les pratiques.


A la différence de l'assurance qualité (ou du label ISO), le CMM dépasse le cadre de l'ingénierie logicielle, méthodes et outils, pour s'intéresser au déploiement réel des processus, respect des délais et des coûts inclus.


La notion d’institutionnalisation des processus n’est pas directement couverte par ITIL. Elle est par contre couverte par les buts et pratiques généraux du CMMI. La gestion des processus du CMMI n’a que peu ou pas d’équivalent dans ITIL.


Deux modes de représentation du modèle coexistent, correspondant à deux points de vue légèrement différents: la représentation continue (continuous) et la représentation étagée (staged). Les deux s’appuient sur les mêmes secteurs clés, mais ceux-ci sont utilisés différemment.


• La représentation continue


Dans cette représentation, les secteurs clés sont regroupés en quatre catégories: gestion de processus, gestion de projet, ingénierie et support, comprenant respectivement 5, 8, 6 et 6 secteurs clés. À chaque secteur clé est associé un niveau de capacité, sur une échelle allant de 0 à 5:


Niveau 0 – Incomplet Les objectifs associés à ce secteur clé ne sont pas remplis.
Niveau 1 - Réalisé Les objectifs sont atteints, mais cette réussite repose essentiellement sur les individus.
Niveau 2 - Géré Les objectifs sont remplis en suivant des plans préétablis.
Niveau 3 - Défini Une politique de normalisation des processus est mise en place au niveau de l’organisation.
Niveau 4 - Maîtrisé Des mesures sont effectuées pour contrôler les processus et agir en cas de déviation par rapport aux objectifs de l’organisation.
Niveau 5 - En optimisation Les processus sont sans cesse remis en question afin d’être toujours en adéquation avec les objectifs de l’organisation.


Il est ainsi possible de déterminer le profil d’une organisation, en étudiant pour chaque secteur clé son niveau de capacité. Tous les secteurs clés n’atteignent pas forcément le même niveau, ce qui permet de déceler les points forts et les points faibles de l’organisation.



• La représentation étagée


Dans cette représentation, c’est un niveau global de maturité de l’organisation qui va être déterminé, et non pas un niveau par secteur clé. Les 25 secteurs clés sont regroupés par niveaux de maturité sur une échelle de 1 à 5, comprenant chacun respectivement 0, 7, 14, 2 et 2 secteurs clés. Les niveaux de maturité ont les caractéristiques suivantes:


Niveau 1 - Initial Les objectifs associés à ce secteur clé ne sont pas remplis.

Niveau 2 - Géré Les processus sont imprévisibles et incontrôlables.
Niveau 3 - Défini Des procédures sont mises en place pour chaque projet.
Niveau 4 – Maîtrisé L’organisation se fixe des objectifs quantitatifs et qualitatifs et se dote de moyens pour contrôler qu’ils sont atteints.
Niveau 5 - En optimisation Les processus sont en continuelle amélioration.

La structure étagée du CMM repose sur des principes de qualité-produit établis depuis soixante ans. En effet, les principes de contrôle statistique de la qualité ont été promulgués dans les années trente par Walter Shewart. Ils ont ensuite été développés et démontrés avec succès dans les travaux de W. Edwards Deming et Joseph Juran [Juran88, Juran89]. Ces principes ont été adaptés par le SEI sous forme d'un cadre d'évolution définissant les aspects fondamentaux de gestion de projet et d'activités d'ingénierie en vue du contrôle quantitatif du processus logiciel, qui constitue le fondement d'une amélioration continue de tout processus. Le cadre d'évolution dans lequel ces principes de qualité ont été adaptés fut tout d'abord inspiré par le livre de Philip Crosby “Quality if Free...”[Crosby 74]. La grille d'évolution de la gestion de la qualité de Crosby décrit cinq étapes successives d'adoption de pratiques dans ce domaine. Ce cadre d'évolution a été adapté au processus logiciel par Ron Radice et ses collègues, sous la direction de Watts Humphrey de IBM. W. Humphrey a présenté ce cadre d'évolution au Software Engineering Institute en 1986, y a ajouté le concept de niveaux de maturité et a développé les fondements de son utilisation actuelle dans l'industrie logiciel.
 

 
Le niveau de maturité d'une organisation : variante du Gartner Group

Le modèle de maturité du Gartner Group, avec la répartition des entreprises européennes sur les différents niveaux de maturité


Maturité / Caractéristiques / Répartition des entreprises


Valeur Alignement des services sur des indicateurs "business" 1%
Service Capacity planning, Service Level Management 4%
Proactif Gestion des changements, performance, disponibilité, industrialisation de la production, gestion des problèmes, disponibilité 30%
Réactif Gestion des événements, outils d'administration, inventaire, consolidation du help desk 40%
Chaos Plusieurs help desks, les utilisateurs découvrent les problèmes, l'exploitation n'est pas stratégique 25%

6. Le modèle ISO15288 – ou SPICE



Software Process Improvement


Inspirée sur le plan de la forme par la norme ISO/CEI 12207 – AFNOR Z 67- 150 (Typologie des processus du cycle de vie du logiciel), cette norme de l'ISO étend les processus techniques à tout le cycle de vie du système (elle couvre ainsi les processus d’exploitation, de maintien en condition opérationnelle et de retrait de service).


La norme s’applique à l’ingénierie des systèmes contributeurs qui ont leur propre cycle de vie (systèmes de fabrication, de déploiement, de soutien logistique, de retrait de service) : que l’on songe par exemple à l’ingénierie des systèmes de démantèlement et de traitements des déchets d’une installation nucléaire.


Elle complète les processus s’appliquant aux projets par des processus, dits d’entreprise, qui ont pour objectif de développer le potentiel de l’organisme d’IS en manageant les domaines communs au profit des projets d’IT.