Demande de Service ou Demande de Changement ?

Voici une présentation au sujet du doute qui subsiste encore souvent à propos de l'usage des Demandes de Service ou des Demandes de Changement pour demander la réalisation de travaux (souvent en interne DSI).
ITIL vous aide avec les définitions, mais concrètement... ?
Je vous propose une façon de voir les choses avec ce support.
Bonne lecture. Changement ou Demande de Service ?

Devops quelle présence sur Internet ?

Je me suis demandé si on parlait beaucoup de DEVOPS, ce qui serait un symptôme de l'intérêt que pourraient luis porter les entreprises...

Intérêt comparé pour le mot DEVOPS dans le monde

Comparons DEVOPS avec des référentiels bien installés ITIL, CMMI, AGILE, COBIT

Courbes d'intérêt des recherches pour ces référentiels depuis 2004 dans le monde

La même chose en France

Principale conclusion vis à vis des référentiels établis : l'intérêt sur l'Agile continue de se développer, alors que celui pour ITIL semble s'émousser. Les Autres référentiels sont en déclins aussi en terme de recherches, sauf Devops qui semble décoller (lié à l'Agile?).

Comparons DEVOPS avec des référentiels plus spécialisés ou récents ISO 20000, ISO 27000, E-SCM

Courbes d'intérêt des recherches pour ces référentiels depuis 2004 dans le monde

La même chose en France

Principale conclusion vis à vis des référentiels moins "généralistes" ou plus récents : Devops présente une courbe de croissance d'intérêt qui l'amène à dépasser ISO 27001 (Sécurité). Ce mouvement est vrai en France comme dans le Monde. Devops à surveiller ... Quant à ISO 20000, il suit visiblement la tendance ITIL, ce qui est plus étonnant, car si cela est confirmé par des projets en entreprise moins importants, ISO 20000 n'aura pas été le relai à ITIL qu'on pouvait imaginer / espérer.

Gestion des changements : on ne vous dit pas tout...

Petits rappels de départ, je vais donner quelques définitions.

Non pas que je veuille insulter le lecteur en lui jetant des banalités au visage, mais plutôt que dans notre quotidien et au bout d'un temps suffisamment long (2 jours pour certains, 2 ans pour d'autres...) on finit par faire des "à peu près" ou à perdre de vue le point de départ.

 C'est quoi un(e) :

• Changement : Ajout, modification ou suppression de tout ce qui peut avoir un effet sur les services informatiques. Le périmètre doit inclure les changements aux architectures, aux processus, aux outils, aux métriques et à la documentation aussi bien que les changements aux services informatiques et aux autres, éléments de configuration.

NDLR : ça veut dire plusieurs choses... Un changement c'est un événement, un processus ce n'est pas un ticket dans un outil (heu bah oui...). Ça veut aussi dire qu'un changement ce n'est pas la plupart du temps une "modif" de type "changer le routeur. Et ça veut aussi dire que tout ce qui sert au Service est éligible à subir un changement qui pourra être instruit pas ce processus. Mais j'y reviens plus loin...

• Demande de Changement : Demande formelle de changement à effectuer. Une RFC comporte des détails sur le changement proposé et peut être enregistrée sur papier ou électroniquement. 

NDLR : une demande n'est pas en soit le changement, c'est simplement l'enregistremen. J'ai l'air d'enfoncer une porte ouverte, là comme ça... Mais pensez-y est-ce que là où vous êtes on ne mélange pas les deux ? Est-ce qu'on dit "Tiens Bernard (ou Cécile ou autre...) j'ai fait une demande de changement ? Ou pluôt "Je t'ai envoyé un changement" "T'as saisi un changement?".
J'aime la précision de la définition : papier ou électronique... ou encore : vous n'êtes pas obligé dans un premier temps d'acheter un outil à 300k€ pour gérer vos changements (voir un prochain billet sur la mise en œuvre).

•  Enregistrement de changement : Enregistrement contenant tous les détails d’un changement. Chaque enregistrement de changement documente le cycle de vie d’un seul changement. Un enregistrement d’un changement est créé pour chaque demande de changement ayant été reçue, même pour celles qui seront rejetées par la suite. Les enregistrements de changement doivent référencer les éléments de configuration affectés par le changement. Ils sont stockés dans le système de gestion des configurations, ou quelque part dans le système de gestion des connaissances des services. 

NDLR : ça c'est un notion rarement utilisée... Le plus souvent on a Changement = Demande de changement = Enregistrement de changement.
On devrait donc dire : j'ai soumis une demande de changement, tu trouveras toutes les informations utiles dans l'enregistrement pour te permettre d'évaluer le changement.

•  Changement Normal (Normal change) : Changement qui n'est ni un changement urgent, ni un changement standard. Un changement normal suit les étapes prédéfinies du processus de Gestion des Changements. Changement Urgent (standard change)

NDLR : là ça se corse... en Français on aurait tendance à dire que le "normal" c'est celui qu'on fait tous les jours et donc à penser à celui qu'ITIL appelle le "standard". Bref un changement normal c'est en fait le changement de base, moyen, basique... et concrètement c'est celui qu'on va devoir étudier car on ne sait pas à l'avance le sort qu'on lui réserve ni qui va pouvoir le valider etc...
Au démarrage du processus, théoriquement on ne devrait avoir que des changements normaux (sauf si on a fait un inventaire des changements récurrents avant...)

•  Changement Standard (Standard Change): Changement pré-autorisé présentant peu de risque, relativement commun et qui sera exécuté selon une procédure ou une instruction de travail. Par exemple, la réinitialisation d’un mot de passe ou la fourniture d’un équipement standard à un nouvel employé. Des demandes de changement (RFC) ne sont pas requises pour implanter un changement standard, car ceux-ci sont journalisées et suivies selon un mécanisme différent, tel qu’une demande de service.

NDLR : le changement standard c'est le changement qui s'est institutionnalisé, banalisé, qu'on fait "tous les jours" sans y penser. ITIL étant pragmatique (sisi je vous assure) il propose donc de ne pas se poser la question de son évaluation à chaque fois et perdre du temps dessus. On devrait avoir pour objectif de balancer les changements qui représentent "80%" de l'activité dans des standards à moyen / long terme et ne se donner la peine d'évaluer que les "20%" restants (notamment en CAB). Mine de rien là je vous donne une cote mal taillée mais qui devrait désengorger les CABs et mettre au chômage quelques Gestionnaires de Changements qui n'ont pas cette ambition...

• Changement Urgent (Emergency Change): changement qui doit être mis en oeuvre dès que possible. Par exemple, pour résoudre un incident majeur ou implémenter un correctif de sécurité. Le processus de Gestion des Changements aura normalement une procédure spécifique pour traiter les changements urgents.

NDLR : Alors là je les vois venir les petits malins : tiens, en voilà un bon moyen d'éviter de passer en CAB... Un changement urgent n'est pas seulement la solution pour résoudre un incident (ça c'est le cas d'un grand nombre de changements...) mais surtout c'est un risque qu'on accepte de prendre car il est plus faible que le risque qu'on fait porter au service si on ne corrige pas.
Autrement dit, on convient à l'avance de cas où on accepte de contourner le processus (et oui ITIL est bien pragmatique ;) ) et pour lesquels le "cas de force majeure" peut être invoqué.
Attention ceci n'est pas un changement urgent :

• remplacement du PC du patron / VIP par un Ipad
• changement "de dernière minute" juste parce que son initiateur se réveille un peu tard, par exemple vers 17H00 pour un déploiement à 17H30. (Celui-là devrait être refusé / reporté histoire qu'on ne l'y reprenne pas). Ça c'est un changement à l'arrache, pas un changement urgent.
• changement "qu'il faut que je fasse avant de partir en vacances", le vendredi en fin d'après midi.

 Bref, le lecteur aura compris : un changement urgent c'est le cas hyper particulier. Et il y a un comité prévu pour ça : le CAB d'urgence (eCAB), souvent avec un ou plusieurs membres de l'encadrement, des clients, capables d'assumer la décision du "bon bah on y va quand même car on n'a pas le temps de tout tester".

Existe-t-il d'autres types de changements ? NON : ça ne sert à rien
Est-ce que je peux "inventer" mes propres types de changements ? NON ça ne sert à rien (bien que je crois l'avoir vu partout !)
Je vous propose de bien relire à chaque fois que vous vous posez ces questions les définitions, vous verrez que tout est prévu et que ce n'est pas parce que votre contexte vous semble différent sur ce point, qu'il l'est vraiment.
Vous voulez que ça marche ? Vous voulez faire efficace ? Contentez-vous de ces types de changements et focalisez-vous sur ce qui compte.

Si on vous demande un nouveau type de changement pour gérer le cas où le changement n'est pas passé au CAB mais doit être fait quand même, vous avez deux réponses possibles :

• Vous émettez un avis négatif sur le changement et vous dites que la prochaine fois il devrait le planifier suffisamment tôt... Mais ça ça n'est pas pragmatique : dans la vraie vie les changements arrivent n'importe quand... et ne peuvent pas forcément attendre un CAB que vous aurez arbitrairement (qui a dit bêtement au fond de la salle ?) fixé un jour de la semaine
• Vous émettez un avis négatif le changement et vous vous dites que vous allez améliorer votre processus en
• arrêtant ce principe stupide auquel tout le monde semble tenir :
• tout changement devrait passer au CAB (c'est anti-ITIL et contre productif). Il faut déléguer l'approbation et utiliser au maximum les changements standards.
• le CAB est une grand messe hebdomadaire dont le principal but est de faire perdre un maximum de temps à un maximum de personnes (ça aussi c'est l'inverse de ce que propose ITIL). Il peut y avoir plusieurs CAB, chacun à un moment différent, avec un périmètre différent, un casting différent. Et surtout on vient en CAB pour entériner (ou pas) une évaluation déjà faite d'un changement : on ne découvre pas le changement en séance en ouvrant le débat, sans avoir les éléments qui permettent de prendre une décision.
  Le CAB ce n'est pas "tiens au fait on changerait bien le serveur  de messagerie ce week end vous en dites quoi ?". Ça devrait être : nous avons étudié le changement qui propose le remplacement du serveur de messagerie. Le dossier est complet mais nous recommandons son report car il intervient à un moment critique pour nous. Le CAB confirme-t-il cette préconisation ?
• prévoyant un circuit d'approbation via voie hiérarchique pour ces cas particuliers qui font partie de la réalité.

Alors pour finir :

CAB ou comité consultatif des changement (Change Advisory Board): Groupe de personnes qui apporte un support à l’évaluation, la définition des priorités, les autorisations et la planification des changements. Le comité consultatif sur les changements est habituellement composé de représentants de tous les domaines au sein du fournisseur de service informatique, du business et des tierces parties tels que les fournisseurs externes.

Voilà tout pour aujourd'hui !
Ça me fait penser qu'un laïus sur le CAB pourra être utile, tant on se désespère en voyant ce qui est fait de ce concept.

Pourquoi donc "Gestion de..."

Avez-vous remarqué que tous les processus ITIL portent un intitulé commençant par "Gestion de ..." ?
Traduction plus ou moins heureuse de "Management" en Anglais.

Bien souvent, au quotidien on ne parle plus de "gestion des incidents" mais du processus "Incidents". On cesse de parler de gestion des changements pour parler des changements tout court...

C'est à la fois une mauvaise habitude et un symptôme de l'idée qu'on se fait d'ITIL et des processus dans trop de cas.

Quelle idée est-ce que j'essaie d'introduire ici ?

Les processus ITIL sont des processus "administratifs" et il faut l'assumer.
Attention : en France, c'est un mot connoté de façon péjorative... Il faut comprendre "qui servent à administrer, piloter, conduire...".

En effet, dans les DSI, ce qui manque ce n'est pas le savoir faire technique ou l'expérience. Des "techos", des "héros", des "barbus de la prod", ça on en a...

Les processus ITIL n'ont pas pour objet de remplacer ce savoir-faire.
C'est à la fois leur force et pour certains leur faiblesse...

• C'est une force car cela permet à ITIL de s'implémenter sur une organisation existante.
• C'est une faiblesse seulement si on attend d'ITIL qu'il résolve des problème dans le management RH ou qu'il comble un manque de savoir-faire opérationnel.

Je résume : ITIL vient mettre une perspective (celle du Service et du Client) et un liant (celui des processus entre eux) qui unit de façon transversale les équipes. Il ne dira pas à un administrateur système comment faire ses opérations techniques. Il lui dira comment s'organiser avec ses collègues pour que ces opérations s'inscrivent dans un tout cohérent et dans le but de fournir le service convenu aux clients.

Tel que je vous vois vous voulez un exemple concret ?
La Gestion des Incidents met en place les mécanismes permettant de "s'assurer" que les incidents sont résolus.
Il ne dit pas "comment" résoudre un incident (passer une commande de relance du serveur,  remplacer le matériel, livrer un patch, revenir à la version n-1...).

C'est la même chose pour chaque autre processus.
Y compris la Gestion des Changements.
Celle-ci a pour vocation à "s'assurer" que les changements arrivent à bon port (certains traduisent par le passage d'un état stable à un nouvel état stable).

Les DSI ressentent souvent le besoin de mieux gérer les déploiements en production (parfois appelés en interne mises en production).
Souvent cela fait suite à une accélération des modifications apportées par les projets, qui créent de plus en plus d'interruptions de service.
Et là, les choses s'enchaînent...

On se dit, "tient on va se faire un coup d'ITIL...":

• un déploiement c'est une mise en production, or une mise en production modifie "quelque chose". 
• donc si ça modifie c'est un changement...
• donc la réponse c'est la gestion des changements...

"Et là c'est le drame".
Immanquablement on commencera à enregistrer toute modification en production par "un changement".
Au début cela semble cohérent et un premier pas en avant.
Jusque là, aucune modification n'était tracée... on se dit que c'est mieux que rien...
Sauf que...ce job c'était celui d'une procédure de déploiement, qui devrait exister, même sans ITIL...
Pas celui de la GESTION des changements...

A ce stade, j'espère que je ne vous ai pas perdu cher lecteur...

Mon propos c'est de dire que l'objectif de la Gestion des Changements, ce n'est pas de savoir qu'on a installé un serveur lame ce matin à 10H05.

Ça se situe sur un autre plan, il s'agit en premier lieu de :

• savoir qui le demande
• s'assurer qu'on a évalué les gains on peut en attendre (résoudre un incident, accueillir une nouvelle application, améliorer les performances...) 
• s'assurer qu'on a évalué les risques et le résultat
• s'assurer qu'on a évalué le coût, les ressources nécessaires, les possibilités de planning
• et sur la base de tout ça... autoriser -ou pas- le changement de cette lame.

Ensuite, ce processus "délègue" à la Gestion des Mises en Production la création et la planification du paquet qui devra apporter le changement.
Autrement dit une nouvelle fois, "s'assurer que" le job sera fait comme convenu.

Et alors la Gestion des Mises en production ?

Rendez-vous dans les prochains billets : Gestion des Changements, Gestion des Mises en production et des déploiements.



 

Redémarrage des Publications

Le blog est resté inactif depuis un moment...
La reprise s'annonce.
Au menu du prochain post : la Gestion des Changements : ce qu'on ne vous a pas dit...
Un petit tour d'horizon sur la gestion des changements et ses proches collègues Gestion des Mises en Production et Gestion de Projets.

Quel cap pour ITIL en 2012 ?

Et si la fin du mon n'arrivait pas en 2012... que deviendrait ITIL ?

ITIL en 2012 ?

Une étude a été menée auprès des participants de la dernière conférence itSMF à Paris (Novembre 2011) par Orsyp.
Le but de cette étude était de définir quelles perspectives les professionnels du domaine voyaient autour d'ITIL.
Les thèmes évoqués sont :

• La productivité des opérations informatiques
• L’efficacité du système de management
• Les leviers de transformation d’une « démarche ITIL »
• La recherche de la performance

Avant de vous laisser en prendre connaissance, en voici quelques grandes lignes.

Première tendance : "aller au-delà d'ITIL"

Alors que 56% des interviewés considèrent qu'ITIL répond bien aux problématiques de productivité des Opérations Informatiques, 44% considèrent que ce n'est plus suffisant, ou bientôt plus suffisant.
On perçoit que la maturité des entreprises aidant, on revient aux fondamentaux : ITIL comme un outil et plus comme un écosystème complet dans lequel on s’intégrerait complètement.
ITIL passerait donc progressivement de statut de "nouveauté" ou "élément différenciant" au statut de "minimum requis". Comme un socle, plutôt qu'un tout.

Seconde tendance : "la combinaison de référentiels"

La question se pose alors : si ITIL ne se suffit pas, à quoi le combiner...
L'étude montre que chacun, encore une fois, a son point de vue. Il diffère en particulier entre les DSI "Internes" et les SSII.
Les premiers préfèrent combiner ITIL et CMMI, les seconds ITIL et COBIT.
L'explication qu'en fait Orsyp est que les DSI Internes veulent maîtriser une chaîne Etudes-Production et les que pour les seconds, gouvernance (COBIT) informatique et gouvernance de l'entreprise se rejoignent étant donné la nature de leur activité.
La conclusion de l'étude serait à vérifier, dans le sens où d'autres facteurs pourraient expliquer ces différences (natures des SSII interrogées, clients...).

Troisième tendance : "Des priorités assez opérationnelles pour 2012 et l'émergence d'ISO20000"

C'est  à présent acquis, ISO 20000 fait partie de l'avenir d'ITIL. Un tiers des interviewés pensent initier une démarche ISO20000. Probablement que ce bon score est dû aux différents usages qu'on peut faire d'une démarche ISO20000 qui peuvent répondre à plusieurs réalités : réduire les projets ITIL à l'essentiel (exigences ISO20000), certifier l'entreprise pour valider des acquis (ITIL ne certifiant que les individus), certifier l'entreprise pour améliorer son image...


Un second tiers des participants signale vouloir aller vers une "excellence opérationnelle" des processus existants. Effectivement, de nombreuses entreprises sont à présent "itilisées" et la question qui se pose est comment optimiser. La préoccupation est moins la mise en place.


Enfin, un dernier tiers regroupe les entreprises qui sont dans l'implémentation. Implémentation d'ITIL 2011 pour la plus grande part (24% des interviewés), implémentation d'un outil de support à ITIL (12% des interviewés).
Étonnant de voir qu'autant d'entreprises veulent aller sur ITIL 2011 là où de nombreuses sont toujours "V2" et n'ont pas voulu aller vers V3 par un projet dédié. Il faudrait voir si les sondés pouvaient répondre ITIL V3 ou ITIL 2011 pour conforter cette idée.
Malgré tout, une part non négligeable de participants va se lancer dans un outillage. Il aura été intéressant de savoir si c'était un "premier outil" ou s'il s'agissait de remplacer un outil existant (et pourquoi...).


Dernière tendance : "Le lean et en arrière plan les préoccupations de performance de service et de coût".


L'enquête montre que le Lean n'est plus quelque chose d'inconnu pour près du tiers des participants. Cependant il reste 69% qui ne souhaitent pas lancer de démarche autour du Lean. Là encore, il serait intéressant de savoir pourquoi... Est-ce parce les problématiques d'excellence opérationnelle, de réduction de coût ne sont pas à l'ordre du jour / tabou.. Ou est-ce que les entreprises ne se voient pas se lancer dans "une démarche de plus", manquant parfois de ressources pour les projets en cours.
Quoi qu'il en soit, on peut considérer que le Lean et les préoccupations liées font une première percée.
Ce qui est intéressant de noter c'est que parmi les entreprises qui se disent prêtes à se lancer, plus de la moitié le feraient soient en dehors de l'informatique, soit dans "les métiers" en même temps de dans l'informatique. On voit ici, que le Lean est peut être porté par les clients (le "métier"), ce qui peut faciliter son déploiement et justifier les projets (à contrario d'ITIL souvent lancé par l'informatique).


Pour consulter l'étude Quel cap pour itil en 2012 ?


Enfin, vous pouvez aussi participer à l'étude de l'itSMF sur l'adoption d'ITIL en France (en retour à votre participation, vous recevrez les résultats de l'étude Adoption ITIL par itSMF.

Gestion des Capacités ... des Services

Gestion de la capacité des ressources / Gestion de la capacité des Services

La Gestion des Capacités est une nouvelle fois un processus pour lequel le nom est source de méprises.
Ainsi, probablement par volonté de ne pas alourdir l'énoncé qui semble déjà barbare à certains (...), on ne précise pas qu'il s'agit de la Capacité des Services. Autrement dit, de l'aptitude ou non de délivrer le service tel qu'il est convenu avec le client.
Trop souvent, nous qui sommes "informaticiens" avons tendance à avoir une compréhension réductrice : la Gestion des Capacités c'est s'assurer qu'on a assez de CPU, de Disque, de débit Réseau pour que cela fonctionne...
Or, il ne s'agit là que de la Gestion de la capacité des ressources Technique. La capacité ou non d'une entreprise à fournir un service dépend de bien d'autres facteurs, en particuliers Humains... A-t-on les bonnes ressources ? ces ressources sont-elles suffisamment compétentes ? Cela doit être évalué (parmi d'autres aspects) au même titre que la capacité technique de l'infrastructure.

Enfin, la Gestion des capacités doit évaluer la capacité à coller au plan "business" de l'entreprise ou des clients. C'est à dire, de s'assurer que globalement on peut accompagner la politique qui est menée.
Par exemple : déploiement à l'étranger, restructuration, fusion avec un concurrent...

Il existe un autre aspect que l'on oublie trop souvent dans la Gestion de la Capacité : il ne s'agit pas d'ajouter toujours plus de ressources techniques ou humaines pour arriver à couvrir un besoin, il s'agit de s'assurer qu'elles sont correctement utilisées...
On comprend ainsi le lien notamment avec la Gestion Financière, qui doit déterminer les coûts.
La Gestion de la Capacité a donc en responsabilité de déterminer comment utiliser au mieux les ressources et seulement si c'est nécessaire de signaler qu'il faut en ajouter.

La démarche qui consiste à dire : j'achète maintenant pour couvrir un potentiel besoin plus tard "au cas où" est caduque. Le but est d'avoir ce qu'il faut, au moment où le faut...ni trop tôt ni trop tard.

Capacité Infrastructure Technique < Capacité des Ressources < Capacité des Services