Home » Posts tagged 'processus'

Tag Archives: processus

Abonnez-vous à ce blog par e-mail.

Saisissez votre adresse e-mail pour vous abonner à ce blog et recevoir une notification de chaque nouvel article par email.

ITIL – 6 autres erreurs de mise en oeuvre

Après la publication de notre article intitulé ITIL – 5 erreurs majeures de mise en oeuvre, nous vous proposons 6 autres erreurs parmi les plus importantes et les plus courantes commises pendant dans la phase d’implémentation.

ITIL - 6 autres erreurs de mise en oeuvre ou comment chaque erreur d'implémentation des meilleurs pratiques ITSM peut conduire votre organisation à l'échec
Crédit © Photo 5000 – 2018

Dans un précédent article, j’ai décrit cinq façons différentes de mal utiliser ITIL :

  • Vouloir absolument « implémenter » ITIL,
  • Se focaliser seulement sur les processus,
  • Miser sur un nouvel outil de gestion des services informatiques (ITSM) p
  • our résoudre tous les problèmes,
  • Démarrer la réalisation de projets (ou de programmes) volumineux et trop longs à générer de la valeur,
  • Et enfin assigner une personne pour chaque rôle.

Dans ce nouvel article, je propose six autres erreurs parmi les plus courantes dans le cadre de la mise en oeuvre des bonnes pratiques ITIL. Bien sûr je vous indique également ce que vous pouvez faire pour les éviter.

Il n’est pas nécessaire d’avoir lu mon précédent article. Cependant il peut vous aider à mieux comprendre tout ce qui pourrait empêcher votre organisation de tirer pleinement parti des avantages offerts par ITIL.

Il existe donc six autres façon de mal comprendre et de mal utiliser ITIL.

Erreur N° 6 : Mettre en place des SLA pour de mauvaises raisons

Un accord de niveau de service (SLA) est un accord signé entre un fournisseur de service et son client. C’est donc un « contrat » entre deux parties sur la fourniture d’un service dans lequel le fournisseur prend des engagements. La différence entre un SLA et un contrat c’est que dans le cas d’un SLA les deux parties peuvent appartenir à la même organisation. Il n’y a donc généralement pas de clause juridique dans un SLA. Cependant, tout comme un contrat, le SLA contient une description du service, ainsi que les mesures et objectifs convenus. Ce sont ces objectifs qui seront utilisés pour mesurer et consigner dans quelle mesure le fournisseur fournit le service.

Les accords de niveau de service sont des outils utiles pour formaliser la relation entre deux parties prenantes. Les conseils de meilleures pratiques ITIL suggèrent qu’ils sont très utiles. Toutefois, certains fournisseurs de services informatiques pensent que s’ils respectent les mesures du contrat de niveau de service, ils ont alors fait tout ce qui était nécessaire. Malheureusement, les SLA sont souvent rédigés par le service informatique avec très peu ou pas de participation des clients. Trop souvent, les clients sont totalement insatisfaits, même lorsque tous les paramètres SLA ont été respectés.

Les mauvaises raisons pour la mise en oeuvre des SLA

Le premier cas consiste à mettre un SLA en place à l’initiative du département informatique afin de montrer aux métiers que l’informatique est performante malgré leur mauvais ressenti. Les indicateurs et les métriques sont alors élaborés dans ce sens. Au final le client est toujours insatisfait, mais en plus il s’aperçoit qu’on a essayé de le tromper. Cela n’améliorera pas la relation.

A l’inverse, le SLA peut également être mis en oeuvre à l’initiative des clients qui ne sont pas satisfaits du service. Ils veulent ainsi démontrer de façon tangible que les services délivrés par le département informatique sont de mauvaise qualité. Le risque c’est qu’alors, afin de satisfaire les clients, le département informatique accepte des engagements de niveau de service irréalisables. Cela est souvent dû à un manque de ressources ou à une prise de risque trop importante.

La bonne approche pour les accords de niveau de service

Si vous avez convenu d’un accord de niveau de service avec votre client, il est important de respecter les engagements que vous avez pris. Mais il est bien plus important encore de satisfaire les besoins réels du client, même s’ils sont difficiles à mesurer et à consigner. Les clients sont tout à fait capables de vous dire ce qu’ils ressentent vraiment si vous leur demandez. Un accord de niveau de service peut être un outil utile si vous souhaitez fournir de bons services. Par contre, il est beaucoup plus important de parler à vos clients et de vous assurer qu’ils sont satisfaits de ce que vous livrez. C’est là l’objectif de la gestion de la relation client dont l’implémentation doit être réalisée en parallèle de la gestion des niveaux de service. Malheureusement, c’est rarement le cas dans les entreprises que j’ai pu conseiller.

Erreur N° 7 : Oublier les attentes des vrais clients de l’informatique

J’ai travaillé avec de nombreuses organisations informatiques constituées de groupes cloisonnés (on parle de silos) qui ne comprennent pas comment ils s’intègrent dans une chaîne de valeur globale. Chaque groupe effectue simplement le travail qui lui est assigné de la manière la plus logique. Il n’a aucune idée de la manière dont cela contribue à la création de valeur pour les clients payants. Cela aboutit le plus souvent à des activités inefficaces et peu rentables, qui n’apportent aucune valeur réelle pour l’organisation ou ses clients.

Il y a de nombreuses années, un manager très sage m’a dit: « Je veux que vous arrêtiez ce que vous faites au moins une fois par jour et que vous vous demandiez: « Si les clients payeurs savaient qu’ils finançaient cette activité, que ressentiraient-ils? « . C’est un exercice fabuleusement simple que tout le monde peut faire. Et cela aide vraiment les gens à se concentrer sur la création de valeur pour les clients réels.

Une autre façon d’éviter les comportements cloisonnés consiste à rassembler des personnes appartenant à différentes équipes informatiques. Par exemple, organisez un atelier où les participants font un suivi détaillé de leur travail. L’objectif est de voir comment chacun contribue à la réalisation des objectifs généraux. Un exercice comme celui-ci peut aider à identifier les principales opportunités d’amélioration. En effet, il indique les domaines dans lesquels il ya un gaspillage important et où certaines équipes peuvent difficilement obtenir des résultats.

Erreur N° 8 : S’intéresser uniquement à la transition et à l’exploitation

Certaines personnes pensent qu’ITIL conseille uniquement sur la gestion des incidents, des problèmes et des changements. Ces éléments sont importants, certes, mais ils ne peuvent en aucun cas suffire à créer de la valeur pour vos clients. Si vous ne gérez pas le cycle de vie complet du service, il manquera des éléments essentiels.

ITIL 2011 décrit très précisément le cycle de vie des services qui est composé de 5 étapes :

  • La stratégie de service consiste à comprendre les marchés, à engager le dialogue avec les clients, à définir une orientation, à définir un portefeuille de services et à gérer les finances nécessaires pour offrir la valeur requise.
  • La conception de services consiste à collecter des exigences détaillées et à concevoir tout ce qui est nécessaire pour que les services nouveaux ou modifiés répondent aux besoins des clients.
  • La transition de service consiste à concevoir, créer le service nouveau ou modifié, à s’assurer qu’il est adapté à son usage et à son utilisation, et à le mettre en production tout en gérant les risques associés.
  • L’exploitation du service consiste à garantir que le service continue de fournir la valeur attendue aux clients et aux utilisateurs.
  • L’amélioration continue du service consiste à surveiller et à améliorer tout ce que vous faites dans l’informatique, pas seulement les processus, mais également les services, les compétences, la conception de l’organisation, les rapports, etc.

La mise en oeuvre de chacune de ces phases est absolument nécessaire dans votre implémentation ITSM. A défaut il y aura des « trous dans la raquette » et vos ne satisferez pas les besoins de vos clients. Est-ce vraiment le cas donc votre organisation?

Erreur N° 9 : L’Obsession d’avoir des mesures positives

Les praticiens ITSM comprennent l’importance de mesurer ce qu’ils font. Les métriques sont idéales pour signaler les tendances et pour déclencher des actions. Mais dès que la métrique devient l’objectif, peu importe la qualité de ces métriques, elles cessent d’avoir du sens.

La loi de Goodhart (du nom de l’économiste Charles Goodhart) dit que « lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure« . Cela est aussi vrai dans l’ITSM que dans l’économie. Si vous dites à quelqu’un que sa prochaine augmentation de salaire dépend de l’obtention d’un indicateur spécifique, fera tout ce qui est nécessaire pour que ce objectif soit correct. Mais cet objectif correspond-il vraiment à ce que vous ou votre client souhaitez qu’il fasse.

Une chose que je fais toujours lorsque je définis des indicateurs de performance clés (KPI) est de demander: «Quel comportement les gens adopteront-ils pour s’assurer que cet indicateur de performance clé est respecté?». C’est souvent suffisant pour me dire que l’indicateur causera un comportement que je ne veux pas encourager. C’est donc un indicateur que je ne devrais PAS mesurer ni signaler. Deux questions sont essentielles. Vos clients sont-ils satisfaits des métriques que vous utilisez? Et savez-vous quels types de comportement sont induits par vos indicateurs de performance clés?

Erreur N° 10 : Déléguer l’amélioration continue à quelqu’un d’autre

Certaines organisations ignorent complètement en quoi consiste l’amélioration continue. D’autres désignent un responsable de l’amélioration continue. Alors le plus souvent,  tous les autres présument qu’ils ne sont pas obligés de participer, car «c’est le travail de quelqu’un d’autre».

C’est bien d’avoir un responsable de l’amélioration continue qui facilite et encourage l’amélioration continue. Mais cela suppose que tout le monde s’attende à assumer la responsabilité de certains aspects de l’amélioration continue. Il est essentiel que chaque processus, chaque service, chaque technologie, chaque équipe et chaque individu contribue à une amélioration continue. Et cela ne peut être fait que par des personnes qui connaissent, comprennent et s’approprient ce qui doit être amélioré.

Par exemple, je pense à mes propres compétences et à mon expérience et j’identifie les choses que je peux faire pour améliorer. Il peut s’agir de lire un livre ou un blog, d’assister à un cours de formation, de travailler avec un mentor, de télécharger et de essayer un outil logiciel, etc.

Erreur N° 11 : Investir uniquement sur des formations ITIL de base

Il existe de nombreux cours de formation ITIL Foundation et de nombreux professionnels de l’informatique réussissent leur certification ITIL. Malheureusement ces cours ne permettent pas, le plus souvent, de faire progresser la compétence de leurs étudiants. Nombreux sont ceux qui deviennent des professionnels certifiés ITIL mais ne savent absolument pas comment appliquer les concepts ITIL.

La vérité est que tout le monde peut lire un guide de l’étudiant et apprendre les concepts ITIL. Malheureusement cela ne les mènera pas très loin, pas plus que leur organisation. ITIL est un guide et non un évangile. Vous devez donc comprendre son impact et son intégration dans votre organisation. La seule façon de le faire est d’investir dans le cours de base ITIL Foundation avec un instructeur expérimenté qui peut montrer aux étudiants comment appliquer ITIL à leur organisation. Mais surtout, vous ne devez pas vous limiter à apprendre par coeur des concepts du vocabulaire (ce qui est l’objet du cours Foundation).

Vous devez approfondir ces concepts et apprendre à les mettre en pratique. C’est l’objet des formations Intermediate Capability et du niveau Practitioner. Dans la réalité peu de professionnels de ‘ITSM (moins de 5%) suivent ces cours et obtiennent les certifications correspondantes. Ils restent donc sur le bord de la route à parler de sujets qu’ils ne comprennent pas en profondeur. Lorsqu’ils essaient de les mettre en oeuvre, l’échec est souvent au bout de la route.

En conclusion…

ITIL peut être extrêmement utile si ses concepts sont soigneusement adoptés et adaptés. Et si vous envisagez de l’utiliser pour soutenir votre organisation, rien ne remplace la réflexion sur ce que vous faites. Évitez les erreurs que j’ai décrites dans cet article. Adoptez et adaptez avec soin les meilleurs pratiques. Dès lors, vous et vos clients obtiendrez une réelle valeur ajoutée grâce à ITIL. Parlez nous de votre expérience!

Les changements à l’ère de DEVOPS

ITIL propose un processus de gestion des changements destiné à ne mettre en production que des services éprouvés pour éviter les impacts négatifs sur les utilisateurs. A l’heure où les entreprises sont en recherche permanente d’agilité et où DEVOPS s’impose, l’approche ITIL semble dépassée. Mais est-elle vraiment dépassée où n’est-ce pas plutôt un échec de mise en oeuvre des meilleurs pratiques qui est en cause? Dans cet article, nous allons faire un gros plan sur ce que devrait être la gestion des changements. Et nous allons nous intéresser tout particulièrement au CAB (Comité Consultatif des Changements), mal utilisé le plus souvent.

ITIL - Le CAB à l'heure de DEVOPS
Crédit © rawpixel.com 2018

La seule raison pour laquelle la plupart des personnes et des organisations ont entendu parler du CAB (Change Advisory Board) est qu’il est décrit dans la section sur la gestion du changement des publications ITIL. La plupart des organisations ont alors considéré que si le CAB est décrit dans ITIL, c’est qu’il est obligatoire. Souvent il a donc été mis en œuvre avec enthousiasme comme mécanisme de contrôle de la qualité dans les grandes entreprises. Pour beaucoup de professionnels des opérations non informatiques, le CAB est leur seul contact avec ITIL. Il en est d’ailleurs presque devenu synonyme. Cela signifie également qu’ITIL est lui-même devenu synonyme de douleur récurrente qui revient toutes les deux semaines…

Le conte des trois erreurs

Il en va de la gestion des changements comme de beaucoup d’autres domaines de l’informatique. Il y a une différence significative entre la théorie et la pratique. Pourtant, il est exact que la théorie (dans l’ITSM) a été (partiellement) construite sur la base des pratiques du monde réel. Cependant, il s’agit en fait d’une version idéalisée d’une tentative de description globale destinée à être adaptée à chaque situation particulière. Ce n’est en aucun cas une prescription de ce qui doit être mis en oeuvre tel quel dans les organisations.

Nous allons tenter de mettre tout le monde d’accord pour commencer à travailler à améliorer la pratique de la gestion des changement. A mon sens, c’est une approche à privilégier plutôt que d’essayer de se rassurer dans des initiatives de type «dénigrement» ou «coup de tête». Elles conduisent le plus souvent à des actions de type « paniqué-coupé-renommé-collé » à partir d’une théorie mal comprise..

Il y a trois domaines principaux dans lesquels la confusion à propos du CAB (Change Advisory Board / Comité Consultatif des Changements) et des pratiques de gestion du changement en général ont entraîné des dysfonctionnements importants. Nous allons essayer de les identifier avant de les comprendre dans le détail..

Survol des trois erreurs

Tout d’abord, il y a beaucoup d’incompréhension quant à la signification de la lettre «A» dans l’acronyme «CAB». Deuxièmement, il y a également une incompréhension quant aux changements qui devraient «passer par le CAB». Troisièmement, il existe une confusion relative à la séparation des pratiques de gestion des changements et des pratiques de gestion des mises en production. Cela fait beaucoup pour un seul processus, certes majeur, parmi les 25 processus décrits dans les publications ITIL 2011.

Commençons par rappeler quelques notions issues d’ITIL, mais souvent incomprises :

  • CAB signifie «Change Advisory Board» (Comité Consultatif des Changements) et non pas «Change Approval Board» (Comité d’Autorisation des Changements).
  • Le CAB n’est pas obligatoire dans ITIL, pas plus que l’envoi de toutes les demandes de changement (RFC) au CAB.
  • A chaque fois que les auditeurs exigent des décisions du CAB, ils confondent la fin et les moyens.
  • Lorsque les managers exigent des décisions du CAB, alors c’est qu’il existe probablement un problème de confiance.
  • L’automatisation (pour les modifications logicielles) rend même les auditeurs plus heureux.
  • Le logiciel circulant dans le pipeline CI / CD (intégration continue / livraison continue) n’est pas destiné à passer par le CAB.
  • L’amélioration des pratiques de gestion du changement requiert la réduction du nombre d’intermédiaires intervenant dans le processus pour améliorer son efficacité.

1 – « A » pour « Advisory » (conseiller)

Comme son nom l’indique, le CAB (Comité Consultatif sur les Changements) a pour objectif de conseiller sur l’évaluation des changements. Il est utile principalement lorsqu’il s’agit de changements à haut risque ou de changements à grande échelle qui vont au-delà du champ de perception d’une équipe particulière. Dans ce cas de figure, ils nécessitent la coordination et la gestion de situations complexes. Il faut alors faire face à des priorités conflictuelles et faire des choix en raison de coûts ou de délais. Le rôle du CAB, dans de telles situations, est essentiel car il permet de recueillir les avis de toutes les parties prenantes.

Pour diverses raisons, le mot «Advisory» (Consultatif) est devenu «Approval» (Approbateur) dans de nombreuses entreprises. Le CAB s’est alors transformé en un mécanisme de création de retard sans valeur ajoutée. Il est censé être là pour des raisons de qualité, mais il atteint rarement son objectif. La différence entre les mots est loin d’être seulement une question pédante de sémantique :

  • Advisory: avoir ou exercer le pouvoir de conseiller
  • Approval: acte ou instance d’approbation de quelque chose

Un mode de fonctionnement inefficace qu’il faut absolument améliorer

De plus, les CAB, dans les entreprises, ont souvent tendance à être statiques. C’est toujours même groupe de managers qui discute de tous les changements qui leur sont apportés, quels que soient l’équipe / l’application / le service concerné. Ils invitent parfois les auteurs de RFC (Request For Change / Demande de Changement) ternes et volumineuses à y ajouter un peu de couleur. Cette approche introduit un niveau d’intermédiation qui perd beaucoup de détails.  Par conséquent le risque est grand de créer un type de pratique, fonctionnel techniquement mais défaillant dans la pratique. L’absence d’avis est une chose, mais l’échec en matière d’approbation en est une toute autre.

La pratique consistant à utiliser des RFC dans l’entreprise semble davantage venir d’un livre de recettes que de l’ITSM. La dynamique de la mise en œuvre repose alors sur un examen minutieux afin de s’assurer que tous les champs du formulaire sont remplis. Elle ne repose pas sur des conseils pertinents. En effet, souvent, les RFC contiennent des informations destinées au CAB. Elles ne contiennent pas les questions et les réponses de / à la personne ou l’équipe recherchant un avis.

Cela ne veut pas dire que des contrôles de qualité ne doivent pas être mis en place. Cependant un mécanisme intervenant tardivement dans le jeu, de type Potemkin, est plus susceptible de gêner que d’aider l’entreprise à atteindre ses objectifs. La réduction du nombre d’erreurs est alors obtenue en évitant les changements plutôt qu’en améliorant la résilience du système. En effet, la dynamique est tellement lourde, coûteuse et chronophage que les « petits » changements seront rejetés. Ceci peut souvent conduire, en retour, à un besoin de changements de grande ampleur. C’est notamment le cas  lorsque le système a dépassé sa date de péremption et échoue sur plusieurs fronts simultanément.

Pour améliorer les pratiques dans ce domaine, une réduction réfléchie et consciente des intermédiaires est nécessaire. Ainsi l’évaluation de l’impact et la prise de décision seront rapprochées du lieu où le travail est réalisé. L’efficacité, les coûts et les délais n’en seront qu’améliorés.

2 – Pratiques obsolètes et manque de confiance

Comme nous venons de le voir, le CAB peut être un élément utile de la gestion des changements pour certains types de changements. Il sera beaucoup moins utile pour d’autres. Notez bien que je dis «peut être», ce qui signifie que le CAB est facultatif et en aucun cas obligatoire. Il ne devrait être introduit que s’il est vraiment utile. Sa conception, sa portée, son rôle et sa valeur doivent être réexaminés de manière continue.

Parmi les autres raisons, il y en a deux concernant le «CAB abusif» que je voudrais évoquer ici. La première concerne les pratiques d’audit. Il s’agit de l’exigence de documenter et d’approuver chaque changement. Il est alors tentant de considérer le CAB comme la seule / meilleure méthode pour y parvenir. La première partie de cette exigence est plutôt raisonnable. Pourquoi ne voudrions-nous pas garder la trace des changements? La deuxième partie, par contre, est un exemple de prédominance du « comment » sur le « pourquoi ». Cette exigence est souvent tellement enracinée qu’elle ressemble à une loi intangible. Elle élimine alors d’autres méthodes de travail qui permettraient d’atteindre le même résultat, mais avec un fonctionnement différent.

Les pratiques obsolètes pour satisfaire les auditeurs

Demander au CAB de signer chaque demande de changement a peut-être été le seul moyen pour l’organisation de répondre aux exigences de la vérification par le passé. Ce n’était certainement pas une préconisation figurant dans les directives ITIL. Il suffit de voir, par exemple, l’autorité de changement et la notion de changement standard. Cela a, très probablement, satisfait les objectifs de la gestion des risques, sur papier uniquement. Et finalement cela a été considéré comme suffisant.

Du matériel coûteux, des temps d’approvisionnement longs et des temps de planification encore plus longs ont rendu les approches, idéales d’un point de vue théorique, plutôt populaires. Cependant, le monde a changé.  La plupart des entreprises disposent maintenant d’un soutien suffisant pour investir dans les méthodes et les pratiques informatiques modernes. Il n’est donc plus nécessaire de continuer à jouer ainsi sur le registre de la gestion des risques.

Evitons donc de compter sur des revues de qualité souvent gérées par des personnes ignorantes du contexte. Nous pouvons plutôt utiliser des pratiques d’automatisation, dans lesquelles la documentation détaillée de chaque changement est fournie par défaut. Outre l’amélioration de la qualité du service, nous disposerons alors d’une grande quantité d’informations, plus fiables. Et nous pourrons fournir ces informations aux auditeurs qui seront satisfaits.

L’option d’automatisation s’applique principalement, à priori, aux changements logiciels. Or, dans le contexte du cloud, ceux-ci incluent des éléments de gestion d’infrastructure (« infrastructure as a code »). Mais ensuite, dans quelle mesure est-il raisonnable de prendre en compte les changements logiciels individuels dans le cadre de la gestion «traditionnelle» des changements?

Le manque de confiance dans les équipes

La deuxième raison pour laquelle les CAB sont si populaires et pourtant mal utilisés est la méfiance. Derrière cela se cache aussi la nécessité de sauver ses fesses au cas où quelque chose se passerait mal. Le CAB devient alors un mécanisme pour imposer un contrôle sur des équipes de spécialistes. En effet, sinon, comment savoir si elles travaillent exactement comme on le souhaite?

Dans ce scénario, plutôt que d’utiliser le concept d’autorité de changement et de laisser les équipes les plus proches du travail prendre des décisions, toutes ces décisions sont transférées au niveau du CAB. C’est là que les responsables du responsable du responsable de l’équipe discutent et décident des changements acceptables. Même si le pouvoir décisionnel revient au CAB, c’est toujours le demandeur du changement qui est tenu pour responsable. C’est-à-dire que, si quelque chose se passe mal, le CAB pourra prétendre avoir demandé des informations complètes et justes. Alors, la raison pour laquelle des résultats inattendus sont obtenus sera qu’il disposait d’informations erronées ou incomplètes. Et, on vous expliquera que dès qu’on identifiera qui est l’individu responsable du fiasco, on s’assurera que cela ne puisse plus se reproduire…

3 – La bataille du RAP

La troisième incompréhension porte sur la confusion entre les changements et les mises en production. Mais elle renvoie également au défi que pose la portée du CAB. La gestion du changement détermine si quelque chose doit être changé et quand. La gestion des mises en production vérifie si le package de modifications, quel que soit son contenu, est prêt à être mis en production et à quel moment. Par souci de simplicité, examinons la gestion des mises en production dans le cadre de la gestion des changements…

La manière dont le CAB a été conçu dans de nombreuses organisations pour les changements liés aux logiciels est en réalité un processus d’approbation de mise en production (RAP : Release Approval Process). D’ailleurs ce processus est assez amusant. Plutôt que d’évaluer l’état de préparation à la mise en production et au déploiement (ce qui est à nouveau une tâche à effectuer, de préférence de manière automatisée avec beaucoup de retours), le RAP/CAB évalue la viabilité du changement lorsque le travail sur ce changement a déjà commencé, ou même le plus souvent, a déjà été achevé. C’est évidemment bien trop tard!

Les processus de prise de décision pour les changements (si une modification logicielle est nécessaire) et pour les mises en production (comment valider au mieux la modification) sont déconnectés et mal alignés. Dans ces organisations, la pratique de gestion du changement – bien que généralement non dénommée ainsi – s’appuie sur« le métier», et« l’informatique » et permet de prendre les commandes une fois la décision prise, de livrer ce qui était prévu (mais rarement décrit correctement), et d’assurer qu’aucune perturbation ne surviendra sur aucun service.

Il y a trop de dysfonctionnements dans ce scénario pour pouvoir les détailler et les intégrer dans cet article. Aussi, ce que je voudrais faire, c’est proposer un point de vue différent pour examiner les changements logiciels. Cela permettra peut-être de supprimer en partie la tension entre la communauté ITSM et la communauté DevOps.

Etendre le mandat

Examinons le développement logiciel agile avec intégration continue (CI: Continuous Integration) et livraison continue (CD: Continuous Delivery). En principe, nous pouvons supposer que le code injecté dans le pipeline CI / CD a été pré-approuvé. C’est-à-dire que le développeur a le mandat de travailler dessus. Il nécessite seulement de passer les contrôles de qualité (automatisés) avant d’atteindre l’environnement de production.

Cette approbation préalable ne signifie pas que quiconque a demandé que le travail de développement soit effectué soit sûr à 100% que ces changements spécifiques produiront les résultats escomptés. Pas plus que le développeur n’est totalement convaincu que le code passera les revues qualité sans problèmes. Le temps de retour pour le développeur se compte en minutes / heures. Il se compte pour le client en heures / jours / semaines, en fonction de la conception du pipeline et de la méthodologie de développement utilisée. Le délai de retour est donc extrêmement long et ne correspond pas aux besoins des métiers.

Si le client a déjà décidé qu’il souhaite le changement, cette décision doit en réalité être une décision du CAB. Mais ce n’est pas le CAB tel qu’il est mis en oeuvre habituellement. Ainsi, plutôt que d’essayer même d’évaluer manuellement chaque version logicielle en cours de traitement dans un CAB (ou RAP), les équipes chargées de la gestion des changements et des mises en production doivent alors travailler ensemble pour concevoir et améliorer le pipeline CI / CD. et des revues qualité automatisées.

Est-il raisonnable de démanteler le CAB?

Quelle que soit la conception de votre CAB actuel ou futur, la question clé à garder à l’esprit est la suivante: aide-t-il à obtenir les résultats attendus des métiers?

Une Gestion des Changements efficace ne peut pas être limitée à un portique de sécurité pour l’accès au service informatique. Cela signifie que la gestion du changement n’est pas basée uniquement sur le CAB. Le CAB n’est pas le processus de gestion des changements. C’est juste un mécanisme qui peut être utile au sein du processus. Il reste probablement beaucoup d’autres choses nécessitant une amélioration dans votre gestion du changement.

S’agissant de votre CAB, s’il s’agit d’un groupe de personnes qui ne connaissent pas les détails des changements / mises en production dont ils discutent mais qui prennent cependant des décisions en évitant de répondre de ces décisions, alors c’est clairement un CAB à éliminer d’urgence.  En effet, ce n’est pas du tout le CAB, préconisé par les bonnes pratiques, dont votre entreprise a besoin..

Mais si c’est un groupe de personnes qui peuvent conseiller sur les changements planifiés, aider à la coordination et à la hiérarchisation, et qui sont là pour aider l’organisation plutôt que leur carrière personnelle, alors conservez-le. Mais améliorez-le de façon continue également.

Vous souhaitez évaluer la viabilité des changements? Alors, vous devez le faire en vous appuyant sur des personnes qui comprennent ces changements. C’est la viabilité des Mises en Production que souhaitez évaluer? Alors, cette tâche devrait être effectuée par des personnes qui comprennent ces Mises en Production.

Pour améliorer la qualité, n’oubliez jamais que vous devez réduire les intermédiaires et automatiser autant que faire se peut.

 

Crédits : cet article est inspiré d’une publication de Kaimar Karu

ITIL – 5 erreurs majeures de mise en oeuvre

Vous suivez les réseaux sociaux? Vous discutez avec des responsables informatiques dans des entreprises, comme je le fais chaque jour? Alors nul doute que vous entendez beaucoup de critiques vis à vis d’ITIL. Pas assez agile. Sa mise en oeuvre coûte très cher aux entreprises. Difficile de convaincre le management d’obtenir les ressources nécessaires. Depuis l’implémentation d’ITIL, on est moins performants qu’avant. Toutes ces critiques sont souvent justifiées. Malheureusement, elles sont souvent la conséquence d’erreurs majeures dans l’implémentation des bonnes pratiques proposées par ITIL.

ITIL : 5 erreurs majeures de mise en oeuvre
Crédit © rawpixel 2018

En tout état de cause, qu’il s’agisse de mauvaise compréhension des « meilleures pratiques » de gestion des services informatiques ou de difficultés de mise en oeuvre, le risque est toujours le même. L’informatique est devenue un outil indispensable au fonctionnement des entreprises. Une informatique qui fonctionne mal ou qui n’est pas alignée sur les besoins des métiers constitue un risque important pour les opérations. Ce premier article recense 5 erreurs parmi les plus importantes mais aussi les plus courantes lorsqu’on veut s’appuyer sur ITIL.

Erreur N°1 : Vouloir réaliser l’implémentation d’ITIL

La pire erreur de toutes est probablement d’essayer de réaliser la «mise en oeuvre» d’ITIL. ITIL est un cadre de bonnes pratiques et, par conséquent, n’est pas destiné une mise en oeuvre en l’état dans une organisation. La règle, souvent incomprise, c’est qu’on ne fait jamais l’implémentation d’ITIL. D’ailleurs, chaque publication ITIL explique bien que chaque pratique est destinée à être «adoptée et adaptée». On doit réaliser l’implémentation de processus spécifiques à chaque Entreprise. Et on le fera en s’appuyant sur les bonnes pratiques préconisées par ITIL. ITIL devrait être vu comme un recueil de conseils. Ce sont seulement des exemples génériques dont vous devez tirer des leçons. Si on essaie d’appliquer à la lettre ces conseils sans tenir compte du métier de l’entreprise, de sa culture et des ressources disponibles, on est assuré de l’emmener au mieux dans une impasse, et au pire à un désastre.

La dernière publication parue à ce jour, ITIL Practitioner, a été publiée en 2015. Elle décrit un ensemble de lignes directrices pouvant vous aider à adopter et à adapter les principes d’ITIL. Ces principes incluent des idées telles que «se concentrer sur la valeur», «rester simple» et «progresser de manière itérative». Si vous utilisez ces principes pour vous guider dans l’adoption et l’adaptation d’ITIL aux besoins de votre organisation, vous n’irez jamais trop loin dans l’erreur. Et même, vous avez réellement de grandes chances d’atteindre vos objectifs.

Erreur N° 2 : Se focaliser uniquement sur les processus

La plupart des gens imaginent qu’ITIL concerne uniquement les processus. Ils s’efforcent donc d’optimiser ces processus, de les rendre plus efficaces et de veiller à ce que chacun atteigne ses objectifs. Is oublient alors l’essentiel. Aucun processus ne se fonctionne dans le vide. Donc, si vous voulez être efficace, vous devez avoir une vue d’ensemble de l’entreprise. Il vous faut donc absolument conserver une vision holistique de l’organisation. En aucun cas, vous ne devez vous limiter seulement à ce qui est écrit dans une publication ITIL ni au seul département informatique..

La notion de création de valeur

ITIL a pour objectif de vous aider à créer de la valeur pour vos clients. Cela signifie que chaque fois que vous améliorez un processus, l’amélioration réalisée doit être axée sur l’amélioration pour vos clients, et pas seulement sur l’amélioration du processus pour lui-même. Demandez-vous donc si vous pouvez expliquer à vos clients le but d’une amélioration en des termes qui ont du sens pour eux. Si la réponse est «non», essayez de trouver ce qui cloche.

N’oubliez jamais que l’informatique ne crée aucune valeur directement. Les services informatiques ne servent qu’à aider les métiers de l’entreprise. Ce sont eux qui sont créateurs de valeur grâce à leurs clients. Vos processus doivent donc les aider à être plus performants vis à vis de ceux-ci. Ainsi, au quotidien, lorsque je travaille avec mes clients, je documente toujours l’objectif de haut niveau de chaque processus. Et je le fais dans des termes qui ont du sens pour les clients des métiers. Par exemple, «la gestion du changement garantira que les changements vont du développement aux opérations en temps voulu pour répondre aux besoins de l’entreprise». Je peux alors travailler avec mon client pour l’aider à optimiser ses processus de gestion du changement de manière à répondre à ses attentes. Ce qui est, en fait, exactement ce que les meilleures pratiques ITIL me conseillent de faire.

Les facilitateurs de la création de valeur

Pour réussir à créer de la valeur, les processus ne suffisent pas. Il faut bien sûr que les processus soient opérés par des ressources humaines. Ces ressources humaines doivent elles-mêmes être organisées en structures au seins de l’entreprise. Il est donc essentiel de ne pas se limiter aux processus mais de travailler en même temps sur les ressources humaines et sur les structures organisationnelles, au minimum.

Erreur N° 3 : Se focaliser sur les outils

La troisième grande erreur que je rencontre est celle des organisations informatiques qui pensent qu’un outil de gestion des services informatiques peut obliger les équipes à se conformer aux bonnes pratiques ITIL. Ils reconnaissent qu’ils ne gèrent pas les incidents, les problèmes et les changements aussi bien qu’ils le souhaiteraient. Alors ils décident que le meilleur moyen de résoudre ce problème est d’acheter un nouvel outil, qui résoudra tous leurs problèmes.

Bien entendu, ce nouvel outil n’a que très peu d’utilité, à moins que l’organisation ne définisse d’abord ce qu’elle tente d’obtenir et ce qu’elle devra faire pour s’assurer que c’est ce que l’outil fournit. Lorsqu’un nouvel outil ITSM est simplement configuré pour prendre en charge toutes les mauvaises pratiques de travail qui posaient problème avec l’ancien outil, l’organisation ne va pas tarder à attribuer au nouvel outil des problèmes qui ne peuvent être résolus qu’en intégrant de meilleures pratiques de travail.

Un nouvel outil ITSM ne vous aidera à vous améliorer que si vous avez correctement préparé le terrain. Comprenez-vous les améliorations dont vous avez besoin dans vos processus, relations, compétences, votre organisation et les autres domaines de gestion des services informatiques?

Erreur N° 4 : Assigner une personne à chaque rôle

ITIL décrit de nombreux rôles. Par exemple, chaque processus définit le rôle d’un propriétaire et d’un gestionnaire du processus, ainsi que de nombreux autres rôles spécifiques. Il est courant de penser que chaque rôle ITIL doit correspondre à un titre de poste unique. Habituellement, il est alors courant de le confier à une seule personne qui devra répondre aux objectifs du rôle. Dans ces circonstance, il sera alors nécessaire de disposer d’un grand nombre de ressources humaines. De plus, cela aura pour conséquence des  personnes essayant de faire des choses similaires avec beaucoup trop peu de collaboration. Il est clair que ce schéma est très inefficient.

Voyons ce que ITIL dit réellement sur les rôles.


Les rôles sont souvent confondus avec les postes, mais il est important de réaliser qu’ils ne sont pas identiques. Chaque organisation définira les intitulés de poste et les descriptions de poste correspondant à ses besoins, et les détenteurs de ces intitulés de poste peuvent jouer un ou plusieurs des rôles requis.


Il est donc essentiel de ne pas confondre les notions de poste et de rôle.

Erreur N° 5 : Lancer un « énorme » projet de mise en oeuvre

Il y a de nombreuses années, avant que les informaticiens aient entendu parler d’Agile, un projet typique d’ITIL pouvait impliquer une équipe de plusieurs consultants qui prendraient deux ans ou plus pour documenter les processus, configurer les outils ITSM, former le personnel et «mettre en œuvre» le nouvel outil aligné sur ITIL. La première fois que quelqu’un tirait parti de la solution, ce serait quelques semaines avant la fin du projet. C’est à dire longtemps après avoir lancé le projet. Et encore, dans la plupart des cas, le projet n’arrivait jamais à ce stade. Il était arrêté avant cela après avoir gaspillé beaucoup de ressources et cassé des choses qui fonctionnaient…

Aujourd’hui, même les entreprises informatiques qui utilisent encore une approche en cascade pour le développement de logiciels n’adoptent plus cette approche pour améliorer l’ITSM. Les experts ITIL savent que toute amélioration des services informatiques peut être réalisée de manière progressive.

Alors, établissez d’abord une vision partagée de ce que vous essayez d’atteindre. Cela vous permettra de faire un premier petit pas vers votre objectif. Ensuite, prenez ce que vous avez appris de cette première étape pour planifier et exécuter la suivante. N’essayez pas de documenter chaque étape avant de commencer. Au contraire, continuez à apprendre et à vous améliorer et vous continuerez à vous rapprocher de votre vision.

Conclusion

Voici donc 5 erreurs absolument majeures que vous risquez de commenter lors de l’implémentation de votre gestion des services IT. Vous vous reconnaissez dans l’une d’entre elles ou même dans plusieurs? Alors ne vous étonnez pas si les métiers de l’entreprise considèrent que l’informatique coûte très cher et ne leur apporte pas grand chose en terme de valeur.

Malheureusement, il y a bien d’autres erreurs courantes que vous risquez de commettre. Dans une deuxième partie qui sera publiée prochainement, nous étudierons 5 autres erreurs d’implémentation.

Vous avez vous-même une expérience de mise en oeuvre qui n’a pas apporté les résultats escomptés? N’hésitez pas à commenter cet article et à lancer le débat. ITIL n’est-il pas un cadre de bonnes pratiques issues du terrain?

ISO/IEC 20000-1 : le cru 2018 est arrivé

Fantastique nouvelle pour toutes les personnes impliquées dans la gestion des services informatiques (ITSM), la norme internationale ISO/IEC 20000-1:2018 a été publiée ce 15 septembre 2018. Elle est désormais disponible en Anglais et en Français sur le site de l’ISO

ISO/IEC 20000-1:2018 nouvelle version de la norme de gestion des services (ITSM)
Crédit image © raw pixel.com

En cette saison de vendanges, les nouveaux crus sont très attendus. Et le millésime 2018 de la norme internationale ISO/IEC 20000-1 ne fait pas exception à la règle. Il s’agit là de la 3ème version de cette norme dont la première publication remonte à 2005. A l’origine, il s’agissait essentiellement de traduire les bonnes pratiques ITIL V2 sous forme d’une norme de gestion des services informatiques (ITSM). L’objectif était de permettre aux organisations informatiques de certifier leur système de management des services TI. Les référentiels de bonnes pratiques tels que ITIL ne permettant pas de certifier une organisation, ISO/IEC 20000 était la première norme ITSM.

L’enquête annuelle réalisée par l’ISO (International Standard Organization) montre qu’en 2016 la norme ISO 20000 est classée en 9ème position des normes sur lesquelles les entreprises se certifient le plus, avec 4537 certificats d’entreprises délivrés en 2016. Elle connaît d’ailleurs une croissance très importante de 63%, et spécialement en Asie.

ITSM - ISO 20000 dans le monde. Devant ITIL
Répartition des certifications ISO 20000 délivrées dans le monde en 2015 & 2016 – © ISO 2017

Aujourd’hui, ISO/IEC 20000-1:2018 reste alignée sur les bonnes pratiques ITSM, parmi lesquelles ITIL. Cependant, elle a largement pris son autonomie et son périmètre s’est sensiblement élargi. Nous vous livrons ici quelques unes des nouveautés attendues par tous les acteurs de la gestion des services.

Vue d’ensemble de la version 2018 d’ISO/IEC 20000-1

Les membres du sous-comité SC40 du JTC1 (ISO/IEC) ont fait un travail remarquable. Ils ont pris en compte les tendances et les défis actuels dans l’environnement de gestion des services. L’accent est désormais mis davantage sur la gestion et l’assurance qualité. Il est moins centré sur la formulation des processus et des procédures. Le fait qu’un écosystème de services soit composé d’un environnement multi-fournisseurs empêche souvent les entreprises de normaliser tous les processus dans toutes les organisations impliquées incluant leur chaîne logistique de service.

Les changements les plus importants dans la norme ISO/IEC 20000-1:2018

Les modifications suivantes ont été apportées par rapport à la version précédente de 2011:

  1. Au plus haut niveau, une nouvelle structure hiérarchique conforme aux autres normes relatives au système de management a été introduite. Cela facilite la certification des entreprises pour plusieurs normes, telles qu’ISO 9001 (gestion de la qualité) ou ISO 27001 (gestion de la sécurité de l’information).
  2. La section Termes et définitions a été supprimée. Elle est désormais remplacée par une référence aux termes et définitions de l’ISO / IEC 20000-10.
  3. Toutes les références à la « méthode PDCA » (« Plan-Do-Check-Act ») ont été supprimées.
  4. De nouvelles exigences sur le contexte de l’organisation et sur les activités relatives aux risques et aux opportunités ont été ajoutées.
  5. Une exigence explicite de «créer, mettre en œuvre, maintenir et améliorer continuellement un système de management des services (SMS)» a été ajoutée.
  6. Les exigences en matière d’informations documentées, de ressources, de compétences et de sensibilisation ont été mises à jour.
  7. Des exigences supplémentaires dans les domaines de la planification des services, de la connaissance, de la gestion des actifs, de la gestion de la demande et de la fourniture de services ont été introduites.
  8. Les exigences relatives à la gestion des incidents et à la gestion des demandes de service ont été divisées en deux chapitres distincts.

À première vue, la norme semble être devenue plus vaste et donc plus complexe. Cependant, les exigences concernant les processus sont beaucoup plus simples. De même, les exigences en matière de documentation ont été considérablement réduites. Cela permet aux organisations de définir leurs processus beaucoup plus librement. La norme est maintenant conçue davantage pour l’effet de la gestion des services que pour sa description détaillée.

La nouvelle norme sur l’ITSM en un seul coup d’oeil

Les changements et améliorations de cette nouvelle version de la norme ISO/IEC 20000 se reflètent dans le schéma suivant :

Schéma de la norme ISO/IEC 20000-1:2018. Au delà du périmètre ITIL
Crédit © ISO 2018

Comme on peut le voir, des questions telles que le leadership et l’engagement, la gestion des risques, la planification des services d’évaluation et l’amélioration de performance deviennent centrales.

Il est également clair que le nombre de processus a nettement augmenté par rapport à la version précédente de 2011. Cette nouvelle mouture de la norme voit son périmètre augmenter. Il est désormais aligné sur celui d’ITIL 2011 et prend en considération les nouveaux référentiels ITSM comme VeriSM, SIAM, COBIT, etc..

Un changement dans la cible de la norme

Le terme « service informatique » figurait déjà dans la dernière version de la norme. Mais la norme était principalement réservée aux organisations informatiques pour certifier leur système de management à ISO 20000. Avec la connectivité accrue des fournisseurs de services externes et les exigences moins détaillées pour les processus informatiques tels que la disponibilité et la gestion de la capacité, la norme est désormais également prédestinée à être utilisée en dehors des organisations informatiques. C’est la base de la certification de la gestion professionnelle des services d’entreprise à l’avenir avec la nouvelle norme ISO/IEC 20000-1: 2018. Attendons donc de voir comment cela va évoluer dans les prochains mois.

Quelles suites sont à prévoir dans les prochains mois?

Si votre organisation est déjà certifiée ou si vous commencez à mettre en œuvre ISO20000-1, ne vous inquiétez pas. Il est probable qu’il y aura une période de transition minimale de deux ans après la révision de la première partie. Rien de ce que vous faites actuellement pour l’ISO/IEC 20000-1:2011 actuelle ne sera perdu.

Pour les entreprises déjà certifiées ISO/IEC 20000-1:2011

Pour les entreprises déjà certifiées ISO/IEC 20000-1:2011, la transition doit être bien préparée. Cependant les changements ne seront pas vraiment importants. Il est toutefois conseillé de convenir de la date de transition avec le certificateur en temps utile. La date limite probable de cette nouvelle certification sera sans doute d’ici 2021 au plus tard.

Pour les entreprises non encore certifiées ISO/IEC 20000-1

Pour les entreprises qui souhaitent obtenir la certification ISO 20000-1 pour la première fois, cette édition est simplifiée. Elle est moins détaillée au niveau des exigences. Elle se concentre sur ce que les entreprises doivent faire pour avoir plus de liberté de mise en œuvre. La mise en oeuvre d’un système de management des services, en vue de la certification, devrait donc être plus facile.

Parmi les points-clés dont vous devez désormais vous préoccuper pour faire certifier votre SMS sur ISO/IEC 20000-1:2018 :

  • Quels sont les résultats attendus de votre système de gestion de services (SMS) et de vos services?
  • Qu’est-ce qui constitue une valeur pour l’organisation et les clients du SMS et des services?
  • Qui a le pouvoir de prendre des décisions clés sur le SMS et les services?
  • Comment les exigences SMS sont-elles intégrées dans les processus métier de l’organisation?
  • Quelles connaissances sont nécessaires pour soutenir le fonctionnement du SMS et des services?

Ce sont là des aspects clés pour l’ITSM et l’alignement sur le business. Aucune surprise donc de les retrouver au coeur de la nouvelle version de la norme. Ce sont également des questions qui matérialisent un peu plus la particularité d’ISO/IEC 20000-1:2018 vis à vis d’ITIL. En effet ITIL 2011 reste essentiellement focalisé sur les processus exclusivement. Ce sont également les questions qui sont au coeur des nouveaux référentiels ITSM tels que SIAM, VeriSM, etc. Il semble que la nouvelle version d’ITIL (ITIL4) annoncée pour le premier trimestre 2019 aille également dans ce sens.

Quid de la formation et des certifications de personnes?

A l’heure actuel, plusieurs organismes de certification de personnes proposent des certifications individuelles sur ISO/IEC 20000. Parmi elles, on peut citer APMG, EXIN ou PECB. Là encore ne vous inquiétez pas. votre certification ISO 20000 (Foundation, auditor, professional, lead implémenter ou lead auditor) demeurera valide. Les organismes de formations vont simplement devoir mettre à jour leurs cursus de formation pour les adapter à la nouvelle version de la norme. La mise à niveau des examens de certification devrait intervenir dans les prochaines semaines.

2AB & Associates (ex AB Consulting), accrédité auprès de l’APMG, d’EXIN et de PECB pour délivrer les formations et les certifications de personnes sur ISO/IEC 20000 est déjà en train de finaliser les nouveaux cours alignés sur la version 2018 de la norme. Nous préparons aussi un cours de transition vers ISO/IEC 20000-1:2018. Ce cours a pour objectif d’aider les personnes en train de conduire une certification de leur organisation sur la version 2011.

 

PRINCE2 – Elaborer le projet

Elaborer un projet PRINCE2

Un projet démarre toujours par une idée qu’il va falloir ensuite concrétiser sous la forme d’un produit. Le processus Elaborer le projet évalue la viabilité et la justification d’un tel projet. Hélas, bien souvent, on a des idées irréalistes ou ne conduisant nulle part. Il est possible aussi que l’idée soit belle mais pas vraiment justifiée vis à vis de la stratégie de l’entreprise. Le premier processus de PRINCE2 va donc devoir s’assurer que les produits préalables à l’initialisation du projet sont bien en place et répondre à la question fondamentale : le projet est-il viable et justifié?

PRINCE2 - Processus Elaborer le Projet

Le projet est-il viable et justifié?

C’est la question à laquelle doit répondre le premier processus de PRINCE2 : Elaborer le projet. L’objectif de ce processus est de s’assurer qu’il existe une justification continue pour l’entreprise, que le périmètre du projet est confirmé et qu’une approche du projet a été approuvée. Il est conçu afin d’assurer les principales parties prenantes de l’Entreprise que le projet est raisonnable et créera bien la valeur attendue conformément à la stratégie de l’Entreprise.

L’élément déclencheur de cette étape est le mandat du projet. Il s’agit d’un document fourni par la direction (d’entreprise / de programme) pour décrire les objectifs et les raison du projet. Il pourra, de plus, fournir une estimation de haut niveau du coût et du temps. Le processus Elaborer le projet est exécuté une seule fois sur chaque projet. Il est focalisé sur l’obtention d’une approbation, obligatoire pour initialiser le projet. Cette autorisation déclenchera l’exécution du processus Diriger le projetqui sera donc le deuxième processus de PRINCE2.

L’objectif du processus Elaborer le projet

Rien ne doit être entrepris avant que les informations nécessaires à la prise de décisions rationnelles n’aient été définies. Il faut aussi avant d’aller plus loin doter les principaux rôles et responsabilités des ressources adéquates. Rien ne peut être démarré non plus sans que les bases nécessaires à une planification détaillée soient disponibles.

L’objectif du processus Elaborer le projet vise à éviter l’initialisation de projets mal conçus et n’approuver que des projets viables. C’est donc un processus « léger » qui effectue seulement les vérifications minimum nécessaires pour déterminer si l’initialisation du projet se justifie.

Le contexte

PRINCE2 utilise le Mandat de Projet pour déclencher le projet. Ce mandat est généré par par l’autorité responsable ayant commandité le projet. Il s’agit généralement de la Direction de l’Entreprise ou de la Direction de Programme. Par Mandat de projet, il faut entendre toutes les informations disponibles et utiles pour déclencher le projet. Il peut s’agir d’une étude de faisabilité ou encore d’une demande proposition client ou fournisseur par exemple. Le Mandat de projet doit établir les termes de référence du projet. Il doit également contenir suffisamment d’informations pour permettre d’identifier le candidat au rôle d’Exécutif du Comité de Pilotage du projet. Il sera ensuite affiné pendant l’exécution du processus Elaborer le projet pour aboutir à l’Exposé de Projet.

Le Comité de Pilotage devra disposer de suffisamment d’informations pour décider si, oui ou non, il peut autoriser l’initialisation du projet. C’est la raison d’être de l’Exposé de projet.

La préparation de l’ébauche du Cas d’affaire et de l’Exposé de projet exigent une interaction et des consultations régulières entre le Chef de Projet, les membres du Comité de pilotage et les autres parties concernées. Plus les exigences seront définies de façon précise et plus on économisera de temps lors de la réalisation du projet. Cela permettra également de réduire les incidences, exceptions et replanifications. Cette phase est donc absolument cruciale pour la réussite du projet.

PRINCE2 - Workshop Elaborer le Projet

Les activités du processus

Les activités du processus Elaborer le projet se répartissent entre la Direction de l’Entreprise, l’Exécutif et le Chef de projet.

Nommer l’Exécutif et le Chef de projet

Pour avancer le projet a besoin d’un décideur disposant le l’autorité appropriée. Pour ce faire, la première activité de projet est la nomination à la fois d’un Exécutif qui sera responsable de la justification continue sur le projet et de représenter les intérêts des partie prenantes de l’entreprise sur le Comité de pilotage du projet, et d’un Chef de projet à qui l’exécutif délèguera la gestion quotidienne du projet.

Recueillir les Retours d’expérience

Il est important de tirer enseignements, en termes de faiblesses et de points forts, d’autres projets menés par le passé. Ces Retours d’expérience peuvent influencer la composition de l’équipe de projet et la préparation de l’ébauche de cas d’affaire. Il sera ensuite nécessaire de tenir un registre des retours d’expérience tout au long du projet, afin de faciliter la réussite du projet et de pouvoir en tirer des leçons pour l’avenir.

Composer et nommer l’équipe de projet

La réussite d’un projet passe par la nomination de personnes compétentes et justifiant de l’autorité, des responsabilités et des connaissances nécessaires pour pouvoir prendre les décisions opportunes. L’équipe de projet doit refléter les intérêts de toutes les parties concernées. Ceci inclut bien évidemment  l’Entreprise, les utilisateurs et les fournisseurs.

Afin d’assurer que chaque rôle de l’équipe de gestion de projet est rempli de manière appropriée et que chacun sait qui est responsable pour chaque rôle, il est important de définir des descriptions de rôles pour l’équipe de gestion de projet .Ceci est principalement de la responsabilité du Chef de projet. Par contre, la nomination des personnes sur chacun des rôles est de la responsabilité de l’Exécutif.

Préparer l’ébauche de Cas d’Affaire

Le Cas d’affaire est un élément crucial du projet vu qu’il détermine sa viabilité. L’exécutif est chargé de la création de l’ébauche du cas d’affaire qui explique pourquoi le projet est nécessaire ou utile. Pour sa création, on s’appuiera sur le mandat du projet et le journal des retours d’expériences. Après avoir développé l’ébauche du cas d’affaire, une Description du Produit du projet est écrite par le Chef de projet. Elle formalise les attentes des utilisateurs sur ce qui doit être livré par le projet. Dès que possible, les critères d’acceptation du projet sont documentés. Il s’agit là des caractéristiques mesurables du produit projet acceptables pour le client.

Définir l’approche du projet et préparer l’Exposé de projet

Il est de la responsabilité du Chef de projet de créer l’approche du projet et l’Exposé de projet, puis de les soumettre au Comité de pilotage en vue de leur approbation. L’approche du projet décrit la manière dont le projet sera abordé. La solution doit-elle être développée en interne ou externalisée? La solution sera-t-elle une modification d’un produit existant? Sera-t-elle développée à partir de zéro? La solution sera-t-elle basée sur un produit du commerce ou conçue sur mesure?

L’Exposé de projet doit contenir des informations détaillés dans le but de prendre connaissance des contraintes et des exigences pertinentes pour le projet, incluant le cas d’affaires (fourni par l’exécutif), la description du Produit du projet (créée par le chef de projet, avec la participation de l’utilisateur principal) et l’approche projet (avec la participation du fournisseur principal).

Planifier la Séquence d’Initialisation

Le processus d’initialisation du projet nécessite du temps et des ressources. Avant que le projet ne puisse être initialisé, le Chef de projet doit donc préparer un plan de la séquence d’Initialisation. Ce plan, accompagné de l’Exposé du Projet et de l’Ebauche de Cas d’Affaire sera soumis au Comité de Pilotage. Celui-ci devra alors l’approuver dans le cadre du processus Diriger le Projet. Ce n’est qu’à partir de ce moment que projet pourra réellement commencer.

Formation accréditée

Vous voulez en savoir plus?

Bien sûr cet article n’a pas vocation à être un cours exhaustif sur le processus Elaborer le Projet. Ce sujet, comme tout le contenu de la méthodologie PRINCE2 sont décrits dans le manuel « Réussir le Management de Projet avec PRINCE2 » (Ed. TSO).

Nous vous invitons également à lire nos articles précédents relatifs aux thèmes Cas d’affaire et Organisation en particulier. Pour mieux comprendre les processus de PRINCE2, vous pouvez également lire sur ce même blog 7 processus pour un projet PRINCE2.

Pour vous familiariser avec PRINCE2, nous vous invitons également à suivre une formation accréditée par AXELOS durant laquelle, sur 5 jours vous apprendrez le contenu de la méthode ainsi que l’utilisation pratique de PRINCE2 au travers d’études de cas. AB Consulting, ATO d’AXELOS, organise régulièrement des sessions de formation PRINCE2 Bootcamp de 5 jours vous permettant d’obtenir les qualifications PRINCE2 Foundation et PRINCE2 Practitioner et de faire reconnaître votre compétence en matière de Gestion de projet.

N’hésitez pas à nous laisser vos commentaires sur cet article et à nous apporter vos témoignages sur votre expérience de PRINCE2. Vous pouvez également interroger nos experts sur toute question pratique d’application de la méthodologie PRINCE2.

Nouveau: DevOps débarque en Afrique!

Une évolution nommée DevOps

Apparu depuis quelque temps, un nouveau mouvement professionnel et culturel visant à améliorer le flux entre les développeurs de logiciels et les équipes opérationnelles commence à faire ses preuves. Encore peu répandu sur le continent Africain où, pourtant, de nombreuses organisations réalisent leurs propres développements de logiciel en interne avant de les exploiter, DevOps répond clairement à un besoin croissant d’agilité des organisations dans un contexte de plus en plus mondialisé. Certains en ont peut-être déjà entendu parler sur des blogs ou via des offres d’emploi.

Dans un premier temps, DevOps peut être vu comme un outil d’amélioration des performances opérationnelles fonctionnant de manière intelligente. La stratégie DevOps aura un impact sur l’ensemble des réseaux de distribution. A la clé figurent des avantages non négligeables:

  • réduction du temps de commercialisation,
  • diminution des problèmes liés aux nouvelles publications,
  • réduction des délais de mise à disposition de correctifs
  • et accélération des temps de reprise après sinistre.

L’évolution constante des entreprises vers le numérique pousse désormais les développeurs à revoir sérieusement les modes de création d’applications.

DevOps-Evolution

Il n’est désormais plus tolérable d’attendre 6 mois, voire 1an avant de livrer les services demandés par les entités business. Les systèmes d’information doivent s’aligner sur la sortie des produits et services métiers. Le marketing ne peut plus attendre, surtout que les projets futurs deviennent de plus en plus complexes notamment en matière informatique. Le tout se retrouve dans un contexte économique pesant sur les budgets. Dans le cadre de ce développement, DevOps répond parfaitement à ce défi digital et les entreprises en ont maintenant pris conscience.

Qu’est-ce que DevOps?

DevOps est l’abréviation de « Développement » et « Opérations » dans le domaine informatique. Ce n’est pas un outil, un processus ou une méthodologie. DevOps a débuté comme étant, et continue d’être, une convergence d’idées en vue de combler le fossé qui sépare les équipes de développement et d’exploitation dans les Directions Informatiques. L’idée maitresse est de rationaliser le développement de logiciels et de faciliter leur exploitation et leur maintenance. Le terme DevOps identifie un mouvement déclenché par la frustration des professionnels de l’informatique, vers 2010, résultant des dysfonctionnements et de l’incapacité d’y remédier du fait d’outils et de processus inadaptés. Ces professionnels IT frustrés ont partagé leur vision du fait que le développement de logiciels et les opérations peuvent, et doivent être plus efficaces et moins douloureux.

Aujourd’hui, la définition originale de DevOps comme étant l’intégration du « développement » et des « opérations » est devenue trop limitée et inexacte. DevOps implique plus d’acteurs que les seuls développeurs et les techniciens d’exploitation. Le cycle de développement de logiciel  implique également de nombreux autres rôles qui constituent des contributeurs essentiels. Parmi ceux-ci, citons la gouvernance, l’assurance qualité (QA), les tests, la sécurité et la gestion des versions. DevOps est donc une combinaison de personnes, de culture, de processus, d’outils et de méthodes  réduisant les risques et les coûts, et permettant à la technologie d’évoluer à la vitesse de l’entreprise, et d’améliorer la qualité globale.

Pourquoi une nouvelle approche?

L’approche traditionnelle repose sur un ensemble de facteurs qui la fragilisent et l’alourdissent. DevOps représente une prise de conscience que l’approche traditionnelle n’est plus en mesure de satisfaire le besoin d’agilité nécessaire à l’Entreprise pour rester concurrentielle. Un exemple typique serait le cas du web qui gère des applications dans le Cloud. DevOps est une démarche innovante qui s’apparente à une philosophie destinée à des personnes à la recherche d’efficacité.

Pour la réalisation des grands projets informatiques, différentes équipes aux rôles bien définis sont impliquées. Il s’agit d’une part de l’équipe de développement et d’autre part de celle chargée de l’exploitation. Habituellement, les équipes de développement tentent de répondre à des spécifications fonctionnelles issues du métier ou du client. Elles travaillent généralement dans leur propre environnement, avec leurs outils destinés aux développements. Elles ne se soucient guère de l’impact que peut avoir leur code sur la phase d’exploitation qui exécutera l’application sur un environnement de production. Les équipes chargées de l’exploitation, quant à elles, tentent de répondre à des impératifs de performance ou de stabilité du système. Et c’est pourquoi, elles sont très attentives à minimiser les impacts des modifications afin de préserver ces performances. Hélas, cela risque de générer un goulot d’étranglement pour l’ajout de nouvelles fonctionnalités aux applications.

Quelle que soit l’équipe, il est toujours compliqué d’être au courant de comment une autre équipe gère ses tâches. Cela rend difficile l’optimisation des deux côtés. C’est à ce niveau qu’intervient DevOps dont le rôle est, en quelque sorte, de réaliser l’intégration des différentes équipes pour faciliter la communication et diffuser l’information. Les autres fonctions de DevOps incluent l’amélioration de la coordination durant les phases de livraison et de déploiement afin de limiter les erreurs.

Les résultats sont-ils probants?

Les résultats sont probants et donnent un bon aperçu des avantages de DevOps. Selon un sondage récent 66% des entreprises dans le monde utilisent déjà une stratégie DevOps ou envisagent d’en mettre une en œuvre. Plus de 90% d’entre elles ont observé ou s’attendent à un gain substantiel grâce à leurs initiatives DevOps. Les résultats de DevOps sont réels et quantifiables car cette approche génère des améliorations, augmentations ou réductions, à deux chiffres (de 17 à 23%).

Infographie DevOps

Les résultats concernant la France sont inférieurs aux chiffres résultants du sondage mondial mais sont néanmoins significatifs.

Quels sont les enjeux?

L’arrivé de DevOps met la pression aux développeurs car ils doivent produire davantage dans un temps réduit et réaliser des tests supplémentaires tout en respectant les contraintes budgétaires imposées. Parmi les enjeux majeurs apparaissent la réactivité commerciale et les délais de commercialisation qui bien souvent affectent l’expérience du client. Cela dit, DevOps impose un niveau de collaboration, d’agilité, de visibilité de développement et de rapidité de distribution qui relève le défi des projets à long terme dont la lenteur est à bannir compte-tenu des contraintes du monde de l’entreprise.

La stratégie DevOps est moins adaptée aux mainframes car il est généralement compliqué de faire évoluer des processus traditionnels bien ancrés et de développer la collaboration autour de technologies solidement établies. La majorité des schémas organisationnels sont en réalité inadaptés ou insuffisants pour permettre aux équipes de développement d’atteindre leurs objectifs et le niveau de productivité qu’exige leur entreprise.

DevOps, pour quels bénéfices

Le slogan pré-Devops était « Vite vite on met en production ! ». Mais attention, il ne faut pas confondre vitesse et précipitation. La production c’est du sérieux ! En effet, les développeurs produisent du code à partir d’un cahier des charges précis. Ils se préoccupent peu des impacts que peut avoir leur code sur la production. De la même façon, les équipes de production sont quant à elles obnubilées par la stabilité de l’infrastructure, garante de la création de valeur pour les métiers. Elles freinent donc les mises en production et blâment le code du développeur si le résultat voulu par l’utilisateur n’est pas satisfaisant. La vision DevOps tente de pallier à ce problème en favorisant une répartition des responsabilités et l’implication de l’ensemble des acteurs de la chaine. Le développeur devient ainsi testeur de son code.

Les intérêts d’adoption d’une démarche Devops sont multiples :

  • Réduire le cycle et le coût de mise en production,
  • Avoir une approche plus fragmentée (petites évolutions),
  • Faire que les mises à jour deviennent transparentes,
  • Mise en commun des responsabilités (tout le monde dans le même bateau!)
  • Une amélioration continue du produit,
  • Répondre plus rapidement aux besoins des clients.

NETFLIX, Amazon, Singapore Power ont été conquis par DevOps

Eh oui, même les plus grands ont adopté Devops ! Des entreprises telles que Netflix ou Amazon ont bâti une bonne partie de leur succès en s’appuyant DevOps.

Cycle de vie DevOpsChez Netflix, par exemple, le déploiement est totalement automatisé, depuis le packaging du nouveau code jusqu’à la mise en production. Cela passe par la mise en oeuvre de l’infrastructure virtuelle et les tests fonctionnels. Une nouvelle version d’application sera promue automatiquement dans une nouvelle infrastructure virtuelle. Elle est mise en service en lui redirigeant un sous-ensemble du trafic utilisateur. Après une phase pilote avec monitoring automatisé, si le comportement s’avère satisfaisant, la totalité du trafic est redirigé. L’ancienne instance de l’application et son infrastructure sont alors automatiquement décommissionées.

Vous souhaitez en savoir plus sur DevOps?

DevOps est désormais accessible en Afrique. Laissez vous tenter par cette révolution. Faites partie des premiers à satisfaire enfin le besoin d’agilité tant attendue par le Business. Grâce à DevOps vos équipes informatiques pourront concevoir et déployer des applications plus rapidement. Elles travailleront de manière efficace et efficiente, s’adapteront facilement au changement, développeront de meilleurs logiciels. Dernier avantage non négligeable, DevOps vous permettra d’optimiser les coûts. Une mise en œuvre parfaite de DevOps est essentielle et nécessite des professionnels expérimentés dans le domaine. C’est pourquoi AB Consulting, seul organisme officiellement accrédité en Afrique, vous aide à comprendre et à mettre en œuvre DevOps dans votre Organisation. Nous vous accompagnons également dans la conduite du changement culturel au sein de vos équipes. Pour plus d’informations sur nos prochaines formations DevOps Foundation, consultez notre site.

N’hésitez pas à nous adresser vos commentaires et vos questions qui seront les bienvenues pour que s’instaure un dialogue fructueux autour de la révolution DevOps.

Implémentation d’ITIL: bien commencer

Implémentation d'ITIL - Raisons d'échecL’implémentation d’ITIL dans votre organisation n’est pas une partie de plaisir. Lorsque vous envisagez de mettre ITIL en œuvre, les premières questions qui vont inéluctablement se poser seront où commencer? Comment dois-je commencer? Qu’est-ce que je cherche à atteindre? Quelles informations me sont nécessaires pour y arriver, quelles personnes dois-je impliquer, et que doit produire ce projet?

Si vous ne disposez pas des réponses complètes à vos questions, votre implémentation d’ITIL va inéluctablement échouer. Nous allons dans cette série d’articles essayer d’identifier les causes d’échecs et vous donner quelques conseils pour pouvoir les éviter.

Implémentation d’ITIL, ça veut dire quoi?

Tout d’abord il est important de souligner qu’on n’implémente pas ITIL®. ITIL® est un référentiel de bonnes pratiques de gestion des services informatiques, publié par AXELOS®, basé, dans sa version 2011, sur les 5 étapes du cycle de vie des services, et couvrant 25 processus et 4 fonctions. Il est totalement impensable, même pour une très grande Entreprise, de tenter d’implémenter la totalité des bonnes pratiques décrites dans les cinq publications de base d’AXELOS®. De plus cela ne ferait absolument aucun sens. L’objectif est de décider, en accord avec les orientations portées par le Conseil d’Administration de l’Organisation et traduites en stratégies par le Comité de Direction, qu’est-ce qui pourrait, parmi les 25 processus et les 4 fonctions décrits dans ITIL®, améliorer le soutien de l’informatique au Business et lui permettre d’atteindre plus facilement les objectifs fixés par les stratégies de l’Entreprise. L’informatique a un rôle de « facilitateur » mais elle ne crée pas de valeur directe pour les parties-prenantes. Ca c’est le rôle des métiers de l’Entreprise.

Prenons le cas, par exemple, d’une banque. Tous les services bancaires s’appuient sur l’informatique qui est un élément clé du fonctionnement quotidien de la banque. Lorsque l’informatique s’arrête, la banque est dans l’impossibilité totale de délivrer ses services à ses clients. Cependant l’informatique ne crée aucune valeur directe pour la banque. L’informatique PERMET aux directions métiers de la banque d’élaborer des services financiers qui seront ensuite vendus aux clients de la banque et créeront de la valeur pour les parties-prenantes. Les véritables créateurs de valeurs sont les directions métiers qui vont « embarquer » des services informatiques dans les services qu’elles vendent et délivrent à leurs clients. Il est donc important que le département informatique soit en permanence aligné avec les besoins des directions métiers et en même temps suffisamment flexible pour leur permettre, dans un environnement extrêmement concurrentiel de créer de nouveaux services financiers afin de rester leaders sur leur marché en fonction des attentes nouvelles des clients.

Donc on implémente seulement des processus et des fonctions les plus indispensables pour permettre à l’Entreprise de créer de la valeur, c’est à dire ce qui est strictement nécessaire dans le cadre des stratégies de l’Entreprise. La décision relève donc des mêmes personnes en charge de valider les stratégies de l’Entreprise et « comptables » (Accountable) des ressources notamment humaines et financières de l’Organisation devant les parties-prenantes. C’est à dire que la décision se prend au niveau du Conseil d’Administration. Ce ne doit jamais être une décision prise par le DSI, ce qui conduirait inévitablement le projet à l’échec après avoir dépensé en pure perte beaucoup de temps, d’argent et gaspillé les ressources humaines disponibles au détriment d’autres projets plus importants. C’est la raison pour laquelle il est important de mettre en place une Gouvernance du SI et d’établir une stratégie informatique claire et validée.

Pour les processus et les fonctions, dans la mesure où il existe des bonnes pratiques reconnues de façon universelle pour la fourniture des services informatiques, on pourra bien sûr s’appuyer utilement sur ITIL®. Seul bémol, les processus et les fonctions ne suffiront pas. Il va également falloir travailler sur les ressources humaines et notamment leurs compétences techniques, bien sûr, mais, plus important encore, leur aptitude à adopter un comportement adéquat basé sur l’éthique de l’Organisation et la création d’une véritable culture du service. Et cela ne fait pas partie directement du périmètre d’ITIL® version 2011 même si les changements culturels et organisationnels sont effleurés dans la publication sur la transition des services.

Où commencer?

La première étape consiste à commencer par faire le constat d’un besoin de mise en oeuvre ou d’amélioration de la fourniture des services informatiques aux métiers de l’Entreprise et à obtenir le consentement à une telle initiative. Il faut cerner les points sensibles et les déclencheurs actuels, et créer un véritable désir de changement au sein de la haute direction.

Il est important de ne pas se focaliser uniquement sur comment on va s’y prendre mais de bien définir ce qui doit être fait pour soutenir les stratégies de l’Entreprise. Ce qui doit être fait doit entrer dans un cadre d’amélioration continue de l’Organisation en vue de créer davantage de valeur en alignement avec les stratégies de l’Entreprise et s’appuyer sur des points sensibles (« là où ça fait mal ») pour le business ou bien des déclencheurs tels que le remplacement de membres du Comité de Direction ou bien le résultat d’un audit externe ou bien encore un changement important sur notre marché ou une nouvelle exigence légale ou réglementaire à laquelle on ne pourra pas échapper. Les points sensibles sont des points de douleur ressentis par l’Entreprise vis à vis de son département informatique tels que par exemple l’incapacité de l’informatique à répondre favorablement à des demandes de nouveaux services IT correspondant à un besoin marché ou bien la perception par le business que la qualité des services IT qui lui sont livrés ne sont pas en adéquation avec ses besoins et sont finalement beaucoup trop chers comparativement à la valeur qu’ils permettent de créer.

Dans tous les cas il va falloir sensibiliser le top-management sur ces aspects pour arriver à transformer le besoin d’agir, dont tout le monde est bien conscient au niveau de l’Entreprise, en désir de changement en vue d’obtenir un sponsoring par au moins un des membres du Comité de Direction pour pouvoir lancer un pré-projet. Nous appellerons cette phase incontournable la « facilitation du changement ». C’est seulement lorsque vous aurez un sponsor pour ce projet que vous pourrez le démarrer, et cela commencera toujours par l’élaboration d’une ébauche de business case. Il s’agit d’un projet comme n’importe quel autre et il devra être géré comme tel, en s’appuyant sur une méthodologie de projet, comme par exemple PRINCE2®.

L’étape suivante se concentre sur la définition de la portée de l’initiative de mise en oeuvre ou d’amélioration et la mise en correspondance des objectifs de l’entreprise, des objectifs liés à l’informatique et des processus IT connexes, et en tenant compte des scénarios de risque qui pourraient également mettre en évidence des processus clés à cibler. Pour réaliser cela, on pourra utiliser par exemple la cascade d’objectifs décrite par COBIT® 5 et expliquée dans notre article sur la stratégie informatique.

Des diagnostics de haut niveau seront également utiles pour cerner la portée du projet et comprendre les domaines à prioriser. Une évaluation de l’état actuel doit ensuite être effectuée, de même qu’une évaluation de l’aptitude des processus existant pour cerner les problèmes ou lacunes. Les initiatives à grande échelle doivent être structurées sous forme d’itérations multiples du cycle de vie ne dépassant pas chacune une durée de six mois maximum. En effet, pour toute initiative de mise en oeuvre s’échelonnant sur plus de six mois, il existe un risque d’essoufflement, de perte de concentration et de démotivation des parties prenantes qui risque fort de conduire votre projet à l’échec.

Notre prochain article traitera des points suivants :

  1. Comment s’y prendre?
  2. De quoi ai-je besoin pour réussir une telle initiative?

Pour plus d’informations ou pour vous inscrire à notre newsletter, merci de compléter le formulaire de contact :

COBIT® is a trademark of ISACA® registered in the United States and other countries.
ITIL® is a registered trade mark of AXELOS Limited.
PRINCE2® is a registered trade mark of AXELOS Limited.

7 processus pour un projet PRINCE2

PRINCE2 est une méthodologie de management de projet qui fournit un cadre de gestion de la performance des projets d’une façon contrôlée. Elle est basée sur sept principes, sept thèmes et  sept processus qui seront exécutés à chaque niveau de management par l’équipe projet. PRINCE2® indique également à quel moment dans le cycle de vie d’un projet les activités de chaque processus doivent être exécutées.

processus projet PRINCE2

Dans cet article, qui fait suite à celui publié récemment sur ce blog et intitulé 7 thèmes pour un projet PRINCE2, nous allons nous intéresser aux sept processus de la méthodologie PRINCE2®.

Un processus est constitué d’une suite structurée d’activités décrivant ce que chaque rôle de l’équipe de projet doit exécuter pour que le processus délivre un résultat précis. PRINCE2 compte sept processus qui couvrent l’ensemble des activités requises pour diriger, manager et livrer un projet avec succès.

Le parcours PRINCE2 en 7 processus

Le Comité de Pilotage de Projet définit l’orientation et prend les décisions clés tout au long du cycle de vie du projet. Les activités du comité de pilotage sont couvertes par le processus Diriger le Projet qui se déroule de la phase de pré-projet jusqu’à la séquence finale inclue.

Les processus PRINCE2

1. Elaborer le projet

Exécuté principalement par le Chef de Projet dans la phase de pré-projet, il repose sur le mandat de projet qui permet de démarrer l’étude préalable au projet en vue de recueillir suffisamment d’informations pour décider si le projet est viable et justifié dans le cadre de l’Entreprise. La première étape consiste à déterminer qui occupera le rôle d’Exécutif qui siègera au sein du comité de pilotage du projet. C’est la Direction de l’Entreprise qui va le nommer. Le mandat de projet sera ensuite utilisé pour développer l’exposé de projet et l’ébauche de cas d’affaire, qui, à leur tour laisseront la place à la documentation d’initialisation de projet pendant la phase d’initialisation du projet. L’objectif principal de ce processus est de s’assurer que l’idée initiale est effectivement bonne et créera de la valeur pour l’Organisation. Si ce n’est pas le cas, alors pourquoi commencer un projet?

2. Diriger le projet

Ce processus est déclenché à la fin du processus « Elaborer le projet » et doit permettre au Comité de Pilotage de pouvoir décider si le projet doit être lancé. Par la suite, le Comité de Pilotage aura la responsabilité d’assumer la réussite du projet en prenant les décisions essentielles tout en délégant au Chef de projet le management au quotidien. Le rôle du Comité de Pilotage est d’exercer un contrôle général du projet, d’être en mesure de s’assurer de sa viabilité, de sa justification pour l’Entreprise, et de fournir des conseils et recommandations au Chef de Projet. Le processus Diriger le Projet est exécuté par le Comité de Pilotage pendant toute la durée du projet pour en assurer la direction et le contrôle jusqu’à la clôture définitive..

3. Initialiser le projet

Exécuté par le Chef de Projet au cours de la première séquence de management pour planifier le projet en détail, ce processus s’assure que toutes les parties concernées du projet comprennent les missions qui leur ont été confiées ainsi que les objectifs à atteindre par le projet. Ceci permet au Comité de Pilotage de savoir si les directives du projet répondent aux objectifs de l’Entreprise avant d’engager des dépenses importantes. Le résultat principal de ce processus est la Documentation d’initialisation du projet qui contiendra entre autres les différentes stratégies (communication, risques, configuration et qualité) ainsi que le cas d’affaires détaillé et les différents contrôles du projet. C’est sur la base de cette documentation d’initialisation que le Comité de Pilotage, dans le cadre du processus « diriger le projet » décidera d’autoriser -ou non- la livraison du projet.

4. Gérer une limite de séquence

Dans PRINCE2, la gestion du projet est réalisée séquence par séquence. La fin de chaque séquence est un point où le Comité de Pilotage devra prendre la décision de continuer en autorisant la séquence suivante ou d’arrêter le projet. Pour ce faire, il faut lui fournir certaines informations lui permettant de prendre sa décision de façon « éclairée » notamment en lui fournissant un rapport de fin de séquence et un plan de la séquence suivante. Ces documents sont préparés par le Chef de Projet de telle sorte que le Comité de Pilotage soit en mesure d’évaluer la réussite de la séquence en cours et d’approuver le plan de la séquence suivante. Ce processus couvre la préparation de ces informations par le Chef de Projet. Le processus de Gestion d’une Limite de Séquence est exécuté une première fois à l’approche de la fin de la séquence d’initialisation puis vers la fin de chaque séquence de management, à l’exception de la dernière séquence de management à la fin de laquelle c’est le processus « Clore le projet» qui sera exécuté par le Chef de Projet.

5. Contrôler une séquence

C’est le processus que le Chef de Projet exécute pour gérer le projet au quotidien après que le Comité de Pilotage ait donné son autorisation de livrer le projet. Il couvre le management de la séquence autorisée par l’autorisation des différents Lots de Travaux attribués aux Chefs d’Equipes Techniques, le suivi du progrès de la séquence, le rapports de la progression au Comité de Pilotage et le traitement des incidences et des risques au fur et à mesure qu’ils surviennent. Ce processus a pour but d’affecter les tâches aux personnes concernées et d’informer le Comité de Pilotage de la progression de la séquence en cours.

6. Gérer la livraison du produit

C’est le processus qui contrôle le lien entre le Chef de Projet et le ou les Chefs d’Equipe en établissant des exigences formelles pour l’acceptation, l’exécution et la livraison des travaux du projet. Les Chefs d’Equipe exécutent ce processus pour livrer les produits spécialistes (techniques) du projet et rendre compte des progrès au Chef de Projet. Ils sont responsables de livrer les produits de la séquence au Chef de Projet. Les Chefs d’Equipe peuvent être internes ou externes à l’Entreprise.

7. Clore le projet

Les projets doivent avoir un début, un milieu et une fin contrôlés. Ils ne doivent pas partir à la dérive ou se diluer petit à petit. Ce processus est exécuté par le Chef de Projet a pour objectif de fournir un point fixe correspondant à la confirmation que le produit du projet est accepté, que les objectifs spécifiés dans la documentation d’initialisation de projet d’origine ont bien été atteints ou encore que le projet n’a plus rien à apporter à l’Entreprise, en vue d’assurer une fin de projet contrôlée. Il garantit que tout le travail qui était prévu a bien été achevé et il nous donne l’occasion d’évaluer le projet et de documenter les retours d’expérience qui pourraient être utilisés pour des projets futurs.

Ainsi les processus vous indiquent quelles activités vous devez effectuer et le moment dans le cycle du projet auquel il faut les faire. En exécutant ces activités vous soutenez les sept Principes qui font que le projet est un projet PRINCE2®.

Ce que les processus ne nous disent pas c’est comment vous devez exécuter ces activités. C’est là que les sept thèmes entrent en jeu. Ils vous donnent des éléments d’approche PRINCE2® vis à vis de certains aspects de management du projet qui doivent être traités tels que l’organisation, les risques, les changements, etc.

Pour apprendre les fondamentaux de la méthodologie, vous pouvez suivre une formation PRINCE2® Foundation. Pour devenir un praticien reconnu et enregistré auprès d’AXELOS®, vous devrez suivre une formation PRINCE2® Practitioner et réussir l’examen de certification correspondant.

Pour en savoir plus sur le cursus de formation et de certification PRINCE2, nous vous invitons à consulter notre page décrivant le cursus PRINCE2.

Pour plus d’informations ou pour vous abonner à notre newsletter, merci de remplir le formulaire de contact :

COBIT for Assurance : Nouvelle publication de l’ISACA à destination des auditeurs

Alain Bonneaud - CGEIT®, COBIT, ITIL Expert
Le 30 mai 2013, l’ISACA a publié un nouveau guide de la famille COBIT® 5. A destination des auditeurs internes et externes, COBIT® for Assurance a pour objectif d’aider les Entreprises à mettre en oeuvre efficacement les activités d’évaluation, leur permettant ainsi d’obtenir l’assurance que leurs processus sont bien suivis et que les risques sont contrôlés et maîtrisés. Ce guide est disponible en téléchargement sur le site officiel de l’ISACA.

Une approche de l’audit partagée par toutes les parties-prenantes

Établir la confiance dans les processus et contrôles informatiques est important, même si les activités d’audit sont souvent une source d’irritation pour les partenaires commerciaux qui ont bien souvent le sentiment que ces activités consomment beaucoup de ressources, ralentissent les activités commerciales et peuvent entraîner un surcroît de travail, tout cela pour atteindre des objectifs dont ils ne comprennent pas l’intérêt. Le nouveau guide COBIT 5 for Assurance de l’ISACA tente de combler ce fossé en traduisant les activités d’audit et de contrôle dans un langage commun pertinent pour les Entreprises et leurs partenaires technologiques, et fait le lien direct entre les objectifs d’évaluation  et les objectifs commerciaux. Dernière publication en date du cadre de référence COBIT 5 mondialement reconnu, COBIT 5 for Assurance propose des directives pratiques pour fédérer les professionnels d’entreprises, de l’informatique et de l’audit autour d’une approche partagée lors de la planification et de la réalisation des évaluations.

COBIT 5 for Assurance aide les entreprises à rendre possibles des activités de contrôle et d’audit de l’IT efficaces afin d’obtenir un degré de confiance raisonnable dans les processus qu’elles appliquent et dans la façon dont elles gèrent les risques. Ce guide fournit une feuille de route claire, fondée sur des approches acceptées internationalement en matière d’audit.

« Les entreprises peuvent utiliser COBIT 5 for Assurance pour profiter de l’homogénéité, de la structure, du contexte et du vocabulaire du cadre de référence COBIT 5 », a indiqué Tony Noble, CISA, directeur de l’équipe de développement de la publication et vice-président de l’audit informatique chez Viacom. « Lorsque les professionnels de l’assurance baseront leurs évaluations sur le même cadre de référence qu’utilisent les entreprises et les directeurs de l’informatique pour maximiser la valeur de l’information et de la technologie, toutes les personnes concernées utiliseront un langage commun et auront un objectif commun. »

La seconde publication COBIT® destinée aux professionnels

COBIT 5 for Assurance est destiné aux auditeurs internes et externes, aux comités d’audit et aux organismes de réglementation, ainsi qu’aux conseils d’administration et directions d’entreprises. Il propose des exemples de programmes d’audit et de contrôle liés à la gestion des changements, à la gestion du risque et au BYOD. Ce tout dernier guide fait partie de la famille de publications COBIT 5 dédiées aux professionnels, et fait suite à COBIT 5 for Information Security.

« La gouvernance et la gestion de l’information et de la technologie sont un sujet vaste et complexe. COBIT contribue à contrer cette complexité grâce à des directives pertinentes, efficaces et simples à utiliser sur des domaines particuliers au sein des systèmes d’information. COBIT 5 for Assurance offre la perspective spécifique au domaine de l’assurance de cet important cadre de référence pour entreprises. Il a été conçu en réponse à l’importante demande en ce qui concerne des directives en matière d’audit et d’assurance en utilisant l’approche structurée éprouvée de COBIT 5 », a confié Greg Grocholski, CISA, président international de l’ISACA et directeur financier international de la division Ventures and Business Development au sein de la société Dow Chemical.

Catégories

Archives

Calendrier

janvier 2019
L M M J V S D
« Déc    
 123456
78910111213
14151617181920
21222324252627
28293031  
%d blogueurs aiment cette page :