Pilotage du changement/La gestion opérationnelle des services
La gestion opérationnelle des services est composée de la gestion des supports et de celle des services. Pour ce chapitre, nous allons privilégier davantage notre présentation sur la gestion des supports.
La gestion des incidents[modifier | modifier le wikicode]
« Un incident est tout événement qui ne fait pas partie des opérations standard, pouvant provoquer une interruption de service ou altérer sa qualité. »
L’objectif est de restaurer au plus vite le niveau de service avec le client-utilisateur et ce en accord avec ce qui a été convenu (SLA) car un incident est synonyme de stress, d'autant que plus de 80% des incidents sont liés à des changements.
La gestion des incidences est un processus réactif, obligatoire dans une organisation de production de service IT.
Ex : une incompatibilité de la version d’un logiciel de base SGBD ou système d’exploitation.:
MÉTHODES ET OUTILS:
On établit une traçabilité des incidents et un historique des erreurs et des problèmes connus pour faciliter la compréhension des suivants.
Les phases du processus suivent l'acronyme « CRIME »:
- d’abord caractériser le motif (et non la cause) de cet événement
- puis réparer en proposant une autre solution
- ensuite identifier la cause et afin de trouver une solution pérenne
- alors mettre en œuvre la solution retenue
- enfin évaluer la qualité de la solution mise en place
Le domaine d’application d’un incident porte sur l’ensemble des services catalogués (SLM), les moyens, organisations et infrastructure (gestion des infrastructure-CM) mis en œuvre pour assurer leur fourniture à des niveaux de service déterminés. C'est pourquoi une cartographie des services de l’entreprise sera construite pour définir les engagements de chaque acteur de la chaîne.
La caractérisation d’un incident[modifier | modifier le wikicode]
Un incident doit être standardisé avec une description détaillée servant ainsi à tracer les événements de manière lisible. Une fois l’incident enregistré, on donne un Ticket d’incident. Ce ticket permet d’avoir des informations de gestion (identifiant unique, date/heure ouverture/fermeture, responsable de l’incident, déclarant…), descriptives (service affecté, date/heure de détection,…) et de traitement (priorité, état d’avancement, ressources et moyens alloués, nom des acteurs, affectation…). On priorise un incident en fonction de l’impact qu’il peut avoir sur le business et de l’urgence de la résolution ou de la mise en place d’une solution de contournement, d'où l’ordre de traitement des incidents.
La règle de gestion est la suivante: si 2 incidents ont le même niveau de priorité on les traite par ordre d’apparition (FIFO).
L’impact de l’incident est défini selon trois classes de fonction qui permettent de mesurer le volume et l’ampleur de l’incident, ainsi que l’effet produit sur l’entreprise (tels que définis par le help desk). Alors que l’urgence est fonction de la criticité de l’incident par rapport à l’activité de l’utilisateur.
La priorité est un délai de résolution (si 1 : <1H ; si 2 : <8H, si 3 : sous 3jours).
Tableau de matrice des incidents
L’état d’un incident[modifier | modifier le wikicode]
Dès détection d’un incident, l’avancement de son traitement est connu par tous les acteurs (clients, utilisateurs, producteurs) et par les autres processus ITIL. En effet, c’est une information de gestion pertinente pour l’ordonnancement du traitement.
Tableau des états d’incident
| État | Description |
|---|---|
| Nouveau, ouvert | Détection et enregistrement d’un incident avec un numéro unique (ticket d’incident) |
| Qualifié ou accepté | Une analyse préalable pour s’assurer que toutes les informations descriptives sont suffisantes pour le traiter et que cet incident est bien de la compétence de l’organisation en charge de résolution. |
| Programmé ou planifié | Incident ordonné selon sa priorité dans une file d’attente avec une date de fin de traitement prévisionnelle (délai max). |
| Affecté ou alloué | L’incident est alloué à une organisation ou à ceux qui disposent des ressources pour son traitement. |
| En-cours | L’incident fait l’objet d’une action opérationnelle pour le traiter. |
| Suspendu ou en attente | Le traitement nécessite une ressource qui demande un délai de mise à disposition. |
| Résolu | L’incident est éradiqué techniquement c’est-à-dire que solution et correction ont été apportées. |
| Clos ou fermé | L’incident est résolu donc le ticket est administrativement fermé. Par contre la personne qui a déclaré l’incident doit autoriser la fermeture. |
L’incident est résolu donc le ticket est administrativement fermé. Par contre la personne qui a déclaré l’incident doit autoriser la fermeture.
Il y a deux types de clôture :
- Clôture technique : c’est l’arrêt du chronomètre: le technicien a permis à l’utilisateur de reprendre son travail.
- Clôture administrative : le propriétaire de l’incident rappelle l’utilisateur pour voir si la solution convient, si l’incident n’est pas survenu de nouveau.
Schéma de relation incidents, problème, erreur connue et demande de changement
La phase finale est la Résolution:
Une mode d’action synchrone correspond à un contournement pour une remise en service rapide. Une mode d’action asynchrone surgit lorsque le problème rend nécessaire l'appel à un ou plusieurs spécialistes pour analyser avec précision le processus de génération de l’incident. Cette analyse se fait indépendamment du service délivré.
Le cycle de vie d’un incident
Les activités du processus de gestion des incidents[modifier | modifier le wikicode]
Ce processus de six activités traite l’ensemble des demandes et incidents qui lui sont affectés.
| Activités | Tâches |
|---|---|
| Détecter et enregistrer l’incident et/ou la demande | qualifier, enregistrer tous les incidents/appels,
trouver les correspondances par rapport aux événements déjà survenus, déterminer la priorité, faire un premier diagnostic, assurer si possible une solution immédiate (=solution de contournement), router vers les groupes compétents (escalade), informer l’utilisateur, clore l’appel (propriétaire de l’incident) |
| Classer les incidents et/ou demandes et apporter une première assistance | |
| Investiguer et faire un diagnostic | |
| Résoudre et rétablir le service (ou exécuter la demande) | |
| Clôturer l’incident ou la demande | |
| Communiquer, suivre, piloter et affecter les incidents (escalade) |
Les deux types d’escalade fonctionnelle et hiérarchique
L’escalade fonctionnelle : le technicien n’est pas capable de résoudre l’incident dans le temps convenu, alors il passe au niveau supérieur (les experts). Elle se différencie de l’escalade hiérarchique, qui survient lorsque le technicien n’a pas le pouvoir d'apporter une solution.
La gestion des problèmes[modifier | modifier le wikicode]
« Un problème arrive lorsque l’on ne connaît pas la cause d’un phénomène ou d’un comportement (identifiable et caractérisable), qu’il ait ou non donné lieu à un incident. Un problème peut se définir aussi comme la cause inconnue d’un incident significatif ou de plusieurs incidents présentant les mêmes symptômes (répétitives). »
L’objectif est de rechercher/ d’analyser la cause première des incidents, d’apporter des solutions pour prévenir de nouveaux incidents afin de minimiser l’impact négatif sur le business.
On ouvre un problème lorsque le contournement d’un incident entraîne des coûts et des délais de traitement prohibitifs.
Le processus gestion des problèmes se préoccupe des causes profondes et particulièrement de celles qui affectent directement le client et/ou l’utilisateur.
Deux modes d’activation du processus :
- Synchrone « cadre réactif » : apporter une résolution rapide si l’incident n’a pas été résolu par le help desk.
- Asynchrone « cadre proactif » : trouver la cause et résoudre. Il n’y a pas de notion de délai.
Le problème devient une erreur connue quand la cause du ou des incidents est connue, qu’une solution de contournement a été trouvée, mais que la solution définitive n’a pas été trouvée ou déployée.
Méthode et outils
Le processus de gestion des problèmes et des erreurs est le même que celui de l’incident (CRIME) mais bénéficie en plus d’une traçabilité active : observer, mémoriser, corréler, indiquer et conserver. On utilisera également le diagramme d’Ishikawa, la méthode Kepner et Tregore (mémoire d’entreprise en cinq phases : définition, description, causes possibles, test des causes les plus probables, Vérification de la cause réelle).
La priorité devient donc forte, moyenne ou faible tandis que l’impact s'avère majeur, significatif ou mineur.
Les activités du processus gestion des problèmes[modifier | modifier le wikicode]
| Activités | Tâches |
|---|---|
| Contrôler les problèmes | identifier, enregistrer ; classifier et allouer les ressources;
analyser les causes premières et trouver des solutions de contournement; effectuer des revues sur les problèmes majeurs; rechercher des solutions de contournement; faire une demande de changement (RFC= Request For Change) |
| Contrôler les erreurs connues | |
| Gérer proactivement les problèmes | |
| Communiquer, suivre, piloter et affecter les problèmes |
La classification d’un problème[modifier | modifier le wikicode]
On classe un problème par :
- Catégorisation du problème
- Mesure de son impact
- Identification de son urgence
- Détermination de la priorité de résolution
L’état de gestion des problèmes se clôture par une revue PIR (Post-Implémentation de la solution)
Le cycle de vie d’un problème
La gestion des configurations[modifier | modifier le wikicode]
Le plan de configuration est composé de deux parties tout d’abord par la définition et organisation de l’activité puis par le planning des opérations de mise en œuvre avec une prise en compte des encours opérationnels. Un système d’information est composé d’un ensemble de "briques" (applications, postes de travail, documentations, procédures,…). La gestion des configurations va dénombrer les composants pour établir des rapports entre eux (relations) sous la forme de composés. Chaque brique porte le nom d’élément de configuration (CI) ou article de configuration dans le monde industriel. Le composant est ce qui est lié à l’infrastructure.
L’objectif est de maîtriser tous les composants de l’infrastructure nécessaires à la fourniture des services. Par conséquent maîtriser ses configurations c’est optimiser ses ressources et délivrer des services au niveau d’engagement défini et à un coût justifiable.
« La gestion des configurations est l’outil de garantie de votre patrimoine IT. Elle est constituée d’une base de données de gestion des configurations (CMDB=Configuration Management Data Base) qui permet de rassembler toutes les informations descriptives et opérationnelles relatives aux éléments de configuration (CI).»
Schéma le contenu d’une CMDB
La CMDB est un outil opérationnel de production qui s’appuie sur un référent, les configurations de nos systèmes IT. Son périmètre et son domaine d’application sont très larges.
Une configuration de référence (configuration baseline) est l’état complet prélevé dans la CMDB d’un produit ou d’un système à un instant donné, qui est établi pour servir de référence pour des activités ultérieures. Elle se segmente en trois états : en production, de référence, et archivée. Le passage d’un état à un autre est régi par des règles de gestion et d’organisation sous la responsabilité du gestionnaire des configurations.
La configuration de référence est comme un cliché utilisé pour le démarrage de tests. Elle est faite par rapport à un métier ou une application.
Les objectifs du processus de la gestion des configurations sont:
- De maîtriser tous les composants de l’infrastructure nécessaire à la fourniture des services IT (référentiel)
- D’être la source primaire d’information sur l’infrastructure du SI
- D’assurer la précision et la fiabilité de cette information
- De vérifier l’adéquation entre le référentiel et la réalité (audit)
- De fournir une base solide pour la gestion des incidents et pour la traçabilité des changements
- D’aider à contrôler l’infrastructure du SI
- D’assurer la traçabilité de toutes les mises en production (MEP)
Les missions et activités de la gestion des configurations
| Activités | Tâches |
|---|---|
| Planifier la gestion des configurations | Concevoir le plan de configurations : définir le niveau de détail;
Identifier les composants; Vérifier que l’infrastructure ne contient que des CIs autorisées; Mettre à jour la CMDB ; Vérifier la conformité des informations |
| Identifier les configurations | |
| Contrôler les éléments de configuration | |
| Effectuer un reporting sur le statut des éléments de configuration | |
| Vérifier et auditer les configurations | |
| Fournir un service de gestion des configurations |
La gestion de mise en production est le lien entre l’univers de développement et celui de la production de service. Elle vise à protéger l’environnement de production et les services associés des nouveaux éléments de configuration introduits, en les contrôlant au travers de procédures et de tests formels ainsi qu'en conservant une trace de leur composition et des actes opérationnels associés.
Un MEP est caractérisé par une unité d’œuvre (UO) c’est-à-dire un élément minimum autorisé qui peut activer le processus de mise en production. Donc on crée un catalogue des unités d’œuvre de mise en production. Par exemple pour un matériel : 1 poste de travail, 1 serveur d’application, 1 serveur de base de donnée, 1 serveur de présentation.
Deux éléments de gestion des mises en production (release management):
- Les bibliothèques : definitive software library (DSL) et Definitive Hadware Store (DHS).
- Bibliothèque des logiciels définitifs (DSL) : stockage sécurisé des versions logicielles autorisées et installées.
- Réserve de matériels définitifs (DHS) : zone de stockage des pièces de rechange homologuées. Ces matériels sont maintenus au même niveau que ceux en production.
CMDB = DSL + DHS
Objectifs/missions de la gestion de mises en production (MEP)
| Objectifs |
|---|
| S’assurer que seules les versions autorisées et testées des logiciels et des matériels sont mises en production;
Prévoir et communiquer sur la disponibilité des nouvelles fonctionnalités avant, pendant et après leur implémentation; Constituer et assurer l’intégrité de la bibliothèque des logiciels utilisés (DSL) et d’un stock (DHS) |
| Missions |
| Concevoir, construire et configurer les mises en production
Valider les nouvelles versions des produits à mettre en production Planifier leur déploiement, Effectuer les tests Valider les tests et la version de mettre en place Analyser les matériels et logiciels Communiquer avec les clients, préparer et former Distribuer et installer |
| Activités |
| Gérer la politique de mise en production
Planifier la MEP Concevoir et construire la MEP Accepter la MEP Planifier le déploiement Communiquer, préparer et former Distribuer et installer Clôturer la MEP Effectuer le retour en arrière de la MEP Gérer la DSL Gérer la DHS |
Le cycle de vie d’une mise en production[modifier | modifier le wikicode]
La relation configuration, changement et mise en production Ces trois processus sont étroitement liés. Les phases sont : l'émission d'une demande de changement, la réalisation d'une mise en production, puis après autorisation, l'enregistrement dans la base de gestion des configurations.
La mise en place de gestion de configuration se caractérise par cinq grandes activités : planifier, identifier, enregistrer, maitriser et vérifier la conformité opérationnelle.
Les éléments de configuration (CI)
Il existe deux grands types CI :
- L’élément de configuration logiciel (SCI= Software Component Item)
- L’élément de configuration matériel (HCI= Hardware Component Item)
Un CI est un composant de l’infrastructure IT qui permet de fournir un service, unique et indentifiable, modifiable, gérable et documenté. La structure de configuration décrit les relations et la position des CIs dans l’arborescence (hiérarchie).
Domaine d’application
La gestion des configurations s’applique à tous les constituants de l’infrastructure dans leur état stable et à tous les services délivrés aux utilisateurs et clients.
La caractérisation d’une configuration
Un composant doit être :
- Descriptif (décrit)
- Lisible (toujours de la même manière)
- Référencé (être associable à un état de configuration)
- Numéroté par Version (être associable à un changement)
Le niveau de détail (CI level) est le niveau auquel on arrête la décomposition en item de configuration. Plus le niveau de détail est important, plus le suivi est complexe. Il ne doit pas atteindre un niveau supérieur à ce qui est maîtrisable et contrôlable.
La caractérisation d’un item de configuration Il y en a quatre:
- Statut : en commande, en service, hors service ….
- Trace : l’historique
- Attributs : nom, n° de série, localisation, fournisseur, date de livraison…
- Relations : Parent/enfant, inclusion, connexion, est une version de… (point le plus important)
La gestion des configurations aide à chercher l’impact d’un changement. C’est l’entreprise qui doit voir jusqu’à quel niveau de détail elle souhaite descendre.
Particularité : pour la gestion des versions, on se sert des règles d’identification du processus de développement ou de l’éditeur. Par exemple pour la version d’un CI logiciel on s’appuie sur le format M.N.Ci c’est-à-dire :
- M= une refonte total du CI ou un ajout de fonctionnalités importantes (de 1 à 99).
- N=des évolutions ou fonctionnalités mineures du CI avec ou sans correction d’anomalies (de 1à 99).
- C= une livraison de correction d’anomalies (de 1 à 999).
- i= indique une version dérivée de la version de base (ex : correction d’anomalies bloquantes), sans respecter le processus normal de livraison (de A à Z).
Les états d’un élément de configuration
| État | Description |
|---|---|
| Planifié/en commande | Date de mise en œuvre du changement autorisé, de la création, modification ou achat du CI est fixé |
| Développé/reçu/livré | Changement construit ; le CI en commande a été livré ; la maintenance est achevée et peut être soumise au test |
| Testé | Une analyse préalable pour s’assurer que toutes les informations descriptives sont suffisantes pour le traiter et que cet incident est bien de la compétence de l’organisation en charge de résolution. |
| Qualifié | Le résultat du CI engendre une acceptation |
| Mis en production (déployé) | Dès accord du client et/ou utilisateur, le changement est jugé conforme et le CI est installé |
| Revue | Ci évalué au travers d’une revue de post-implémentation après avoir défini un temps de fonctionnement de l’environnement de production |
| En maintenance | CI existant est en phase de maintenance (correction, curative ou évolutive) et nécessite un arrêt dit « planifié ». Une réparation sur site ou chez un prestataire |
| Indisponible | CI en opération n’offre plus le service pour lequel il est conçu |
| Archivé/en rebut | CI n’est plus utilisé ou obsolète |
Le cycle de vie d’un élément de configuration[modifier | modifier le wikicode]
La gestion des configurations est très interdépendante des processus de gestion des changements et de gestion des mises en production. Ce dernier processus décrit les modalités de construction d’un produit « MEP » alors MEP = CI. C'est la raison pour laquelle le choix des états (de configurations, de changement, de MEP) doit être cohérent pour limiter les erreurs d’interprétation et simplifier le travail de chacun.
Le cycle de vie d’un élément de configuration peut être différent selon la catégorie de ce dernier. Par ex : l’état d’un CI logiciel peut être installé mais pour une documentation, cet état n’a aucun sens pratique. Donc le document serait applicatif.
Le cycle de vie de gestion des configurations
Les outils[modifier | modifier le wikicode]
Ce processus permet de maîtriser l’évolution du système IT afin d’être efficace et efficient sur son activité.
La CMDB est un outil indispensable car elle constitue une phase importante de l’industrialisation. Elle doit contenir des informations opérationnelles (changements, incidents, problèmes, erreurs connues), structurelles (composants, organisations, acteurs) et de gestion (coûts, licences, obsolescence) relatives au système IT et aux services offertes aux clients et utilisateurs. On distingue deux grandes familles d’outils : la base de données des configurations et les outils d’inventaire automatique.
La gestion des changements[modifier | modifier le wikicode]
Le changement correspond à toute modification de l’infrastructure (matériel, logiciel, environnement, système, poste de travail, documentation, service, procédure) qui a pour conséquence l’évolution du statut (l’état) d’un ou de plusieurs items de configuration. On établit une demande de changement (RFC) pour qu’il soit pris en considération.
Un changement doit être :
- Administré : c’est-à-dire réduction des risques entreprise, sévérité de l’impact, estimation du résultat financier potentiel
- Géré : mesure de sa couverture, coût délai, organisation, suivi
Le changement est un événement dont il ne faut pas sous estimer la portée car il peut amener à vivre des instants critiques. Le changement est le fondement de l’évolution qui doit être guidé, suivi et être compatible avec la capacité d'action (ressources, moyens financiers, ROI) d'une entreprise, face à l'environnement sur lequel elle opère. Il s'équilibre entre le besoin de changer et l’impact du changement sur le monde environnant.
En conséquence, l’outil de gestion des changements se définit en regard de la capacité et la maturité d’une entreprise, afin qu'elle fournisse un service de qualité et en conformité avec les engagements pris. Le changement nécessite des niveaux adéquats sur trois pôles: expertise, charisme et pouvoir de décision.
Gérer le changement c’est « faire agir », on distingue deux modes :
- Proactif = projet et/ou planification en production de service
- Réactif = lors d’un fort impact sur le business ou pour le client
Il y a donc des changements sans risque ou des changements avec des conséquences désastreuses, pouvant affecter la continuité du business. On peut changer dès l’instant où le client ne subit pas de gène et en lui donnant une visibilité suffisante.
Alors gérer le changement c’est évaluer le risque et mesurer l’impact sur la continuité du business.
L‘impact du changement sur les incidents (référence loi PARETO)
Le poids du changement a un impact direct sur les incidents. L’objectif : appliquer des changements autorisés, de manière efficace et en faisant porter un risque acceptable sur la qualité des services (QoS) existants et/ou nouveaux.
Tout changement doit apporter une parcelle de réponse à la question « Pourquoi cela ne fonctionne-t-il plus? ». On va chercher à planifier le changement par opération. Exemple : dans le cadre d’un projet, utilisation de 2 nouvelles technologies inconnues par votre équipe de production (JAVA et ORACLE). Il faudra s’entourer de nouvelles ressources expérimentées ou refuser. Dans le milieu industriel, la gestion du changement est sous le contrôle de l’organisation opérationnelle d’ordonnancement/ lancement.
Le processus de gestion des changements répond à la question « quoi? » c’est-à-dire à la gestion et au suivi ainsi qu'au respect du plan temporel. Il est important de ne réaliser des changements que lorsqu’ils sont autorisés. Pour tous système IT, la mise en œuvre du changement autorisé voire conseillé s'effectue de préférence durant les périodes de la journée où les sollicitations sont minimales.
Il existe deux types de planification :
- Un calendrier prévisionnel des changements (FSC= forward schedule of change) : il détaille tous les changements planifiés et approuvés pour l’implémentation avec la date prévisionnelle de mise en production
- Un calendrier de disponibilité prévisionnelle des services (PSA= projected service avaibility) : il détermine la disponibilité de service prévue, il présente l’influence possible de tous les changements planifiés (FSC) sur la disponibilité du service avec les engagements pris (SLA)
Ces deux documents sont primordiaux car ils servent de base de communication et doivent être approuvés par le client concerné, le gestionnaire des niveaux de service, le gestionnaire de la disponibilité et le centre de services.
Pour tous événements, il est nécessaire et obligatoire de faciliter la traçabilité opérationnelle c’est-à-dire de rattacher un changement à un élément de configuration (CI).
Exemple : si un changement important est planifié à 3h du matin avec une durée estimée de 5h (soit fin du programme à 8h) mais que le changement est terminé à 10h, la période comprise entre 8h et 10h doit être déclarée en incident. Ceci est très important pour augmenter l’efficacité du processus de mise en place.
Le PIR (post implementation review) est le bilan final de la mise en œuvre du changement.
Rôle et responsabilité[modifier | modifier le wikicode]
Le gestionnaire des changements (chef d’orchestre) s’occupe de la gestion des changements et est garant de son institutionnalisation.
Selon l’impact des changements, il peut faire appel à une instance opérationnelle de caractère opérationnel appelée comité consultatif (CAB= change advisory board) ou un comité consultatif d’urgence sur les changements (CAB/EC= change advisory board/emergency committee).
Le CAB n’est pas définitif, il est défini par rapport à chaque changement. Il doit y avoir un équilibre entre les représentants des métiers et les techniciens. Le CAB n’est pas dans l’obligation de se réunir tous les x jours, en revanche, des échanges informels peuvent survenir par mails entre deux réunions.
Certains changements peuvent se décider uniquement par mails avec un CAB, il n’est pas nécessaire de faire des réunions.
C’est le gestionnaire qui préside le CAB et le propriétaire n’est pas obligé d’en faire partie.
Le comité de direction de l’entreprise conserve son rôle de décisionnaire pour les changements ayant une dimension (c’est-à-dire un impact) société.
Le changement a des arrêts dits planifiés. Il est nécessaire de s’appuyer sur le client afin qu’il donne son quitus avant toute intervention.
Il faut être très attentif au management pour éviter que les ressources soient systématiquement affectées aux taches réactives, au détriment des actions proactives. Une vigilance maximale sur l’allocation des ressources limite les risques car les conséquences induites peuvent être désastreuses pour l’avenir, à court et moyen terme.
Une fois avoir défini votre capacité à gérer, en mode proactif ou planifié, il faut piloter par priorité afin d’assurer une continuité de business conforme aux engagements. Il est important de vérifier le délai nécessaire à la revue finale car pendant les périodes critiques pour les métiers, les ressources informatiques sont à leur plus bas niveau (fin journée « le vendredi », fin d’année « entre le 15 décembre et le 15 janvier »).
Méthodes outils
Une historisation des changements autorisés ne peut être faite dans un environnement isolé.
La pertinence de l’association des environnements de gestion des changements et des configurations permet :
- De mieux évaluer les risques en termes d’impact lors de la planification des changements
- De faire des retours-arriérés pour mesurer leur intérêt
Pour une structure, vivre sans changement serait synonyme de stagnation, de perte d’innovation et de leadership. Ainsi le processus de gestion des changements est un élément déterminant pour toute évolution planifiée et très complexe. La notion de revue importe vis-à-vis de l’impact du changement car c’est un gage de succès et de sécurité. La meilleure chose est faire est de standardiser les changements par un catalogue des changements standards.
L’origine des changements[modifier | modifier le wikicode]
Dans un service IT, un changement peut provenir des éléments suivants :
- La déclaration d’un incident ou d’un problème
- Une demande de service utilisateur
- Un plan d’amélioration des services liée à la gestion de la capacité, de la disponibilité et des niveaux de service
- La mise en place de nouvelles exigences de sécurité
- Les fournisseurs de logiciels et progiciels qui corrigent les anomalies rencontrées ou ont évolué le périmètre fonctionnel de leurs offres
- L’obsolescence d’une version matérielle ou logicielle
- L’application de la loi et les obligations légales (ex : la CNIL)
- Les acteurs opérationnels qui proposent des améliorations aux processus et aux systèmes en place (PDCA)
- Une optimisation financière de nos ressources avec la suppression des applications inactives
- Les évolutions ou nouveaux produits et service qui au travers de s projets et maintenances, apportent d’énormes changements
Schéma contexte d’un changement
Maîtriser et optimiser un changement c’est établir un juste compromis entre différents facteurs
La priorité d’un changement[modifier | modifier le wikicode]
D’abord, on qualifie l’impact qu’il peut avoir sur le business puis l’urgence de la résolution ou de la mise en place
L’impact mesure l’influence du changement sur le business (potentiel), selon lequel il reste vulnérable L’urgence mesure l’influence de la mise en place du changement basée sur l’impact et sur les besoins du client. Il y a quatre types d’urgence : urgent, haut, moyen, bas. La priorité est l’ordre selon lequel le changement est traité en se basant sur l’impact et l’urgence. Par la notion de priorité on sous-entend la notion de gestion du risque.
Les priorités sont classées en deux grandes catégories :
- Demande urgente ou immédiate : les pertes de services/problèmes sont très significatives et concernent un nombre important d’utilisateurs.
- Demande non urgente : est classée selon trois niveaux :
- haute : affecte sévèrement les utilisateurs ou un grand nombre d’entre eux.
- Moyenne : pas de grande urgence ni d’impact majeur. Cette demande peut être différée
- Faible : nécessaire mais de toute évidence peut attendre (exemple : nouvelle version du produit concerné par le changement)
La catégorisation d’un changement[modifier | modifier le wikicode]
C’est l’importance du changement et les moyens à déployer. Pour approuver une demande, on effectue une analyse de risque du changement sur le business afin d’évaluer précisément l’impact.
Le but de la catégorisation est de déterminer l’importance du changement approuvé et l’organisation en termes de moyens nécessaires à sa réalisation.
La catégorie est une classification d’un groupe d’éléments de configuration, de demande de changement ou de déclaration de problèmes. Alors que la classification est un processus d’identification formelle des demandes de changement par type (exemple : demande de validation).
On distingue deux grandes catégorisations des demandes de changement :
- Le changement standard : c’est le suivi d’un cheminement préétabli. Il suppose la mise en place d’un catalogue des changements qui est généralement revu deux fois, souvent délégué à une organisation sans contact avec le gestionnaire des changements.
- Le changement non standard est décliné à trois niveaux :
- Majeur : les ressources, coûts et risques sont majeurs donc la décision revient au comité directeur. Exemple : passer de Windows à Linux.
- Significatif : les ressources, coûts et risques sont importants donc la décision revient au CAB ou au comité de pilotage. Exemple : ajout d’une imprimante réseau.
- Mineur : les ressources, coûts et risques sont faibles donc la décision revient à l’administrateur. Exemple : installer Excel nouvelle version sur un poste.
On constate que la majorité des demandes de changements est catégorisée en standard ou en mineur et que 80% à 85% des incidents proviennent d’un changement.
Tableau d’un état du changement
| État | Description |
|---|---|
| Enregistré | Demande de changement émise et enregistrement dans un journal avec un numéro unique. |
| Accepté / refusé | Analyse et filtrage de la demande. Si elle est identifiée non conforme à la complétude: refusé; sinon accepté. |
| Évalué | Mesure de l’impact sur le business client, l’infrastructure, les conséquences d’une non mise en œuvre, l’organisation et l’évaluation des ressources permettent de déclarer la demande comme évaluée. |
| Autorisé | Demande soumise à une approbation multiple (financière, technique, business, organisationnelle) est autorisée |
| Planifié | Changement autorisé soumis à une planification pour la construction du changement. |
| Développé | Le changement construit et soumis au test. |
| Testé | Le changement est testé sur les aspects fonctionnels et exploitabilité. |
| Qualifié | Après développement et tests, le changement est accepté par le client (qualification) |
| Mis en production | Avec accord du client/utilisateur, le changement est mis en production. |
| Revu | Évaluation du changement à travers une revue post implémentation (PIR). |
| Clos ou fermé | La PIR est déclaré satisfaisant au changement, alors la demande de changement est fermée avec l’approbation du client. |
Le cycle de vie du changement[modifier | modifier le wikicode]
De la demande à la clôture le changement est soumis à un nombre limité d’activités qui sont majoritairement de nature de gestion. Toutes les activités opérationnelles qui dépendent du changement sont externes au processus.
Schéma du cycle de vie des changements
Ce schéma montre les étapes et les jalons caractérisés par des délais (ou temps de réponse) très utiles à l’efficience et l’efficacité du processus. Ce sont toutes les étapes de la vie d’un changement mais, selon la catégorie de changement ou le type de travail à effectuer, certains états peuvent être implicites. C'est pourquoi un changement standard accepté va directement à l’état autorisé.
Les deux premiers niveaux représentent le cœur d’ITIL qui recouvre le soutien des services et les fournitures de services.
Les activités et les missions du processus gestion des changements
| Activités | Tâches |
|---|---|
| Enregistrer et filtrer les demandes de changement | Gérer les demandes de changements (RFC);
Estimer l’impact et les coûts du changement; Autoriser les changements; Planifier les changements; Mettre en œuvre les changements approuvés; Évaluer les changements après réalisation |
| Affecter une priorité initiale | |
| Affecter un modèle standard ou une catégorie | |
| Traiter un changement standard | |
| Analyser et autoriser un changement non standard | |
| Traiter un changement urgent et Effectuer la revue post-implémentation (PIR) | |
| Suivre et coordonner l’exécution du changement |
Conclusion[modifier | modifier le wikicode]
ITIL dispose de deux approches: globale « TOP – DOWN » et à résultats rapides « BOTTOM-UP » (recherche de gains immédiat ⇒ quick wins). ITIL permet à une entreprise d’avoir une démarche structurée, de connaitre ses facteurs clés de succès et les risques. Son impact sur l’organisation informatique (DSI): il s'avère très structurant car le centre de services a un rôle déterminant. Le processus ITIL permet de décloisonner la DSI et de formaliser les relations avec les maîtres d’ouvrage dans le cadre d’une gestion de la relation client.
ITIL se place parmi les référentiels à adopter dans le cadre de la gestion d’infrastructure. Les modules de gestion opérationnelle sont les plus exploités (Service Support et Service Delivery) par les entreprises. Il s'agit de 12 processus appliqués aujourd’hui essentiellement à la production.
La certification ITIL est attribuée uniquement à des individus. Si l’entreprise veut démontrer la bonne application des processus, elle devra aller vers la certification ISO 20000, laquelle impose une application exhaustive de ces processus. Il est donc important de disposer des bons outils pour rassurer ses clients et accroître sa performance.
À l’inverse d’ITIL, COBIT (control objectivities for information and related technology) est utilisé pour la gouvernance du SI. CMMI (capability maturity model integration) est une méthode d’organisation pour le développement et la maintenance d’applications. PMI (project management institute) s'applique au management de projet.
