Home » Posts tagged 'Lean'

Tag Archives: Lean

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.

VeriSM: le nouvel ITIL de l’ère digitale?

En proposant une approche nouvelle de la gestion des services, le modèle VeriSM pourrait bien être l’évolution digitale du référentiel ITIL à l’ère du numérique.

VeriSM est-il le nouvel ITIL de l'ère digitale?
Crédit © VeriSM Global

ITIL, le référentiel phare d’AXELOS, commence à sérieusement prendre de l’âge et à perdre de son avance. VeriSM, plus adapté aux contraintes de l’entreprise du futur, pourrait bien être un challenger sérieux dans les prochains mois pour ITIL. AXELOS est bien conscient de la nécessité de faire évoluer son cadre de bonnes pratiques. La Société Britannique a d’ailleurs lancé récemment une initiative qui devrait aboutir Q1/2019 au lancement de ITIL 4. Il n’en reste pas moins que de sérieux concurrents commencent à voir le jour. VeriSM a été conçu dès l’origine pour répondre aux attentes des Entreprises de l’ère digitale. Ce nouveau cadre de bonnes pratiques semble être, assez logiquement, aujourd’hui, en bonne position pour prendre l’avantage.

VeriSM, qu’est-ce que c’est?

VeriSM (de l’anglais Value-driven Evolving Responsive Integrated Service Management) a été développé en 2017 par l’IFDC. Il s’agit d’une gestion des services intégrée, réactive, évolutive et centrée sur la création de valeur.

Cette approche vise à mettre en place des pratiques nouvelles de gestion des services, au niveau de l’ensemble de l’organisation. On ne se focalise plus sur le seul département informatique. Ces nouvelles pratiques sont plus flexibles. Elles sont également plus centrées sur la création de valeur et l’accélération du « Time-to-Market » de produits ou services nouveaux.

ITIL ne suffit pas?

En 2007, le référentiel ITIL a été revu en intégralité dans une version ITIL V3 plus cohérente et ambitieuse, autour de 5 ouvrages. Chacun de ces ouvrages recense les meilleures pratiques pour la gestion des services informatiques (IT Service Management ou ITSM) en suivant les 5 phases du cycle de vie des services. En 2011, le Cabinet Office, alors en charge du portefeuille des bonnes pratiques de l’état Britannique publie une refonte « cosmétique » d’ITIL dénommée ITIL 2011. Malheureusement, ITIL 2011 n’apporte pas de grand changement aux bonnes pratiques d’ITIL V3. ITIL reste ITIL. C’est d’ailleurs le sens de l’appellation ITIL 2011 qui n’est en aucun cas une nouvelle version du référentiel. Il est cependant évident que depuis la parution d’ITIL V3 en 2007 le contexte des Entreprise a largement évolué. La mondialisation des affaires nécessite toujours plus d’agilité des Entreprises pour qu’elles puissent survivre.

Pourquoi un échec relatif d’ITIL à créer de la valeur business?

Dans le même temps, les mises en oeuvre des bonnes pratiques basées sur ITIL ont largement échoué à produire les résultats attendus. La faute n’est pas à ITIL. La faute est à attribuer pour une large part à des consultants incompétents lorsqu’on parle de mise en oeuvre. Les implémentations réalisées ont essentiellement contribué à « rigidifier » les entreprises pour tirer un maximum de bénéfices au niveau de l’informatique. Hélas ces avantages ont été ciblés au détriment de l’agilité du business.

La faute est également à porter à l’étendue du cadre de bonnes pratiques d’AXELOS. Il ne se focalise malheureusement que sur les aspects informatiques. Une entreprise ne devrais utiliser l’informatique que comme un « outil » au service du business. Or les mises en oeuvre de processus basés sur ITIL sont réalisées pour la plupart pour les DSI. De plus, elles se déroulent bien souvent sans la participation du Business. Or c’est bien le business qui crée de la valeur et en aucun cas l’informatique. L’informatique est et doit rester un outil au service du business.

AXELOS s’en est d’ailleurs est bien rendu compte et a publié « ITIL Practitioner » accompagné d’une nouvelle certification. Cette publication, mal positionnée et surtout mal ciblée a été un échec. La plupart des consultants « experts » ont échoué à obtenir la certification ITIL Practitioner.

Qu’apporte VeriSM en plus d’ITIL?

L’évolution du modèle d’affaire des Entreprises entraîne un besoin d’évolution des pratiques. Et c’est cette évolution des pratiques qui explique le besoin des professionnels de l’informatique de disposer d’un nouveau référentiel intégrant les nouveaux enjeux de la DSI et des métiers (et plus seulement ceux de la production) : « time-to-market », « user experience / customer experience (UX/CX) », agile-DevOps, nouvelles pratiques du support, intégration du cloud sous toutes ses formes dans la fourniture des services, positionnement de la production en tant qu’agrégateur de services, etc. Autant d’enjeux déjà embarqués dans le modèle VeriSM. VeriSM pourrait donc bien être une alternative au référentiel ITIL 4 dont la sortie est prévue en 2019. Ce d’autant que le contenu t’ITIL 4 reste encore largement inconnu.

Comment est conçu VeriSM?

Le modèle VeriSM, récemment traduit en français, est décrit dans plusieurs ouvrages, dont un « pocket guide » disponible sur le site de Van Haren Publishing proposant une approche de la gestion des services d’un point de vue organisationnel.

La première publication, structurée en quatre parties, parait finalement assez générique :

  • La première partie, plutôt exploratoire du service management, interroge sur le bien-fondé d’une culture « service », sa structuration et ce qu’elle implique, notamment en matière de gestion des compétences.
  • La seconde partie, plus descriptive, est au cœur de l’ouvrage. A première vue, elle parait très conceptuelle et est pourtant enrichie d’exemples explicites.
  • La troisième partie propose un rappel des concepts, technologies et pratiques liés à l’agilité, à la culture DevOps, au Lean management, au cloud, au big data, à l’IoT, au shift left, à la CX et UX (Consumer et User eXperience), au continuous delivery, à la méthode Kanban, à la Théorie des contraintes ou encore à l’amélioration continue.
  • Enfin, la quatrième partie propose des annexes illustrant par exemple les notions d’asset management, de « security by design » ou encore la structure générique d’une « policy ».

Le modèle VeriSM repose également sur un découpage intéressant – façon SIAM (Service Integration And Management) – et décrivant les activités clés d’un intégrateur de services. VeriSM propose d’aider les métiers à se digitaliser en ne se contentant plus de fournir des services en mode infrastructure. Il faut désormais créer de la valeur, identifier et explorer des technologies de pointe. Cela nécessite des compétences nouvelles dans un écosystème qui se diversifie chaque jour un peu plus.

Le modèle VeriSM
Le modèle VeriSM © IFDC Global

Alors pourquoi adopter VeriSM?

Toute l’originalité de VeriSM réside dans le cœur même de son modèle, le « Management Maillé » sur lequel s’appuient quatre groupes d’activités autour du cycle de vie d’un service : définir, produire, fournir et supporter.

Ce modèle favorise une approche flexible permettant de s’adapter aux besoins d’un produit ou d’un service spécifique.

VeriSM - Le management maillé
Crédit © Van Haren Publishing

L’idée centrale du modèle est de construire un modèle d’opération couvrant ces 4 groupes d’activités en s’appuyant et en mixant intelligemment l’utilisation de pratiques et de facilitateurs issus des 4 pôles du « management maillé » :

  • L’environnements : les éléments « stabilisateurs » (processus, métriques, outillages), les concurrents, la culture, les contraintes légales, etc.
  • Les ressources : équipes, budgets, actifs, connaissance, temps, etc.
  • Les pratiques de management : ITIL / COBIT / CMMI / IT4IT, ISO/CEI 20000, ISO/CEI 27000, DevOps, agilité, lean management, PPM, SIAM, etc.
  • Les technologies émergentes : cloud, containers, IoT, big data, automation, dont certaines ne sont plus forcément émergentes mais désormais intégrées dans la fourniture de services.

Pour chaque produit, ces domaines sont pris en considération et interagissent.

Même si, aujourd’hui, la description du cœur même du référentiel n’est pas encore très détaillée et peut-être un peu trop « stratosphérique », la prochaine version dont la sortie est planifiée pour fin 2018 devrait tenir ses promesses et offrir de nouveaux horizons à la gestion des services. Tous les espoirs sont désormais  permis. Ce modèle est pensé et structuré pour répondre aux nouveaux enjeux de la transformation digitale des entreprises. Il pourrait donc devenir le nouveau référentiel de pratiques pour le management des services.

 

Etes-vous plutôt agile ou classique?

AGILE ou traditionnelle, quelle approche choisir?

L’approche agile vous semble peut-être nouvelle ou au contraire, peut-être êtes vous un ou une adepte des méthodes agiles? Quoi qu’il en soit, il est important de partir sur de bonnes bases. Déjà quand nous parlons d’agile à quoi faisons-nous référence? Ce blog étant spécialisé dans la gouvernance, le management et la sécurité, vous comprenez bien sûr que nous faisons référence à l’agilité dans la gestion de projets. Avant de démarrer il faut comprendre que le terme « Méthode » est trop limitatif pour aborder ce mode de gestion de projet. Le terme approprié serait plutôt « Approche Agile » car il s’agit plus d’une philosophie que d’une méthodologie.

Approche agile

Cette approche, donc, est devenue au cours de ces dernières années, très populaire dans les entreprises. Elle est conçue de sorte à apporter de nombreux avantages mais requiert une discipline stricte pour produire la valeur promise. Chaque étape est importante et indispensable. Nous allons vous montrer, au travers de cet article, les avantages de cette approche déjà très populaire. Il vous appartient ensuite de décider si elle est pertinente pour vous.

Agile, de quoi s’agit-il?

Né aux Etats-Unis, le mouvement agile est apparu en 2001, lorsque 17 experts se sont alliés pour mettre au point une nouvelle façon de développer des logiciels, visant à réduire le taux d’échec important des projets informatiques. C’est d’ailleurs à cette occasion que le terme Agile est apparu pour  qualifier cette nouvelle approche. Ce rassemblement a donné naissance à un manifeste définissant quatre axes de valorisation pour les projets :

  • Les individus et leurs interactions avant les processus et les outils
  • Des fonctionnalités opérationnelles avant la documentation
  • Collaboration avec le client plutôt que contractualisation des relations
  • Acceptation du changement plutôt que conformité aux plans

L’approche agile est une approche de gestion de projet défiant les approches classiques. La notion même de « Gestion de projet » est remplacée au profit de « Gestion de produit » de façon à mieux se focaliser sur le produit plutôt que sur le projet. L’objectif de tout projet est de livrer un produit. Dans une approche dite « classique », on attend généralement du client une expression détaillée et validée du besoin. Cette expression de besoin validée en début de réalisation laisse peu place au changement. La réalisation prend le temps qu’il faut et rendez-vous est repris avec le client pour la recette. Cet effet tunnel peut être mauvais et très conflictuel.

On remarque fréquemment un déphasage entre le besoin initial et l’application réalisée. On se rapporte alors aux spécifications validées et au contrat. La majorité des projets se terminent très mal au risque d’affecter la relation avec le client. De plus, il peut arriver que certaines fonctionnalités demandées soient inutiles à l’usage. D’autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.

En quoi consiste réellement l’approche agile?

En 1994, une enquête réalisée par le «  Standish Group » a démontré que 31% des projets informatiques sont stoppé en cours d’exécution, 52% n’aboutisse pas et ne respectent pas les délais et le budget imposés proposant souvent moins de fonctionnalités qui étaient prévus. Et pour finir, seuls 16% des projets sont synonyme de réussite. La même enquête de nouveau menée en 2008 indique un taux de réussite de 35%. Cela représente une nette progression mais reste insuffisant.

Parmi les principales causes d’échec relevées on peut citer :

  • Manque d’implication des utilisateurs finaux : 12,8 %.
  • Changements de spécifications en cours de projet : 11,8 %.

L’approche Agile propose de réduire complètement les conséquences de cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s’adapter aux changements de ce dernier. Mais cela ne peut pas se faire sans un minimum de règles.

Comment est-ce que cela fonctionne?

Le principe de base des méthodes « Classiques » est qu’il peut être contre-productif. C’est-à-dire qu’avant de développer un produit, il faut le planifier et en spécifier les moindres détails. En effet, prévoir tous les aspects de la production entraîne dans la plupart des cas des frustrations et pertes de temps car les imprévus surviennent très souvent pendant la réalisation. C’est cette approche prédictive et séquentielle de type waterfall ou cycle en V que les tenants des méthodes « Agile » veulent casser.

Ainsi, le mieux serait de procéder par étapes c’est-à-dire se fixer des objectifs à court terme et commencer le développement sans perdre de temps. Une fois l’objectif atteint, on passe à la phase suivante et ainsi de suite jusqu’à atteindre le but recherché. Concernant le niveau de développement de logiciel, il appartient au client de transmettre à l’équipe de développeurs sa vision du produit avec les fonctionnalités qui l’accompagnent. Cela permet ainsi d’avoir un échange direct avec l’équipe et et de définir ensemble le coût de chacune des fonctionnalités pour aboutir à un budget final approximatif. L’équipe devra choisir ensuite une partie des exigences du client à exécuter dans un court délai appelé « itération ».

Itération agile

Le principe des itérations

Dans chaque itération se trouvent les travaux de conception, les techniques de développement et les spécifications fonctionnelles. Au terme de chaque itération, le produit semi-fini mais utilisable, est montré au client. Il peut donc se rendre compte par lui-même du travail réalisé dans un temps très court. Quant à l’utilisateur final, il peut déjà se projeter dans l’usage du produit. Cela lui permet de transmettre des feedbacks importants pour les prochaines itérations. Cette transparence est un grand avantage pour solidifier la relation de confiance et de collaboration entre le client et le fournisseur. Cela permet ainsi d’économiser son budget et de récolter rapidement un premier retour sur investissement. Le client a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développés (prochaines itérations).

Cette souplesse ainsi offerte est donc un véritable atout pour le client. Encore une fois, on pense plus « Produit » que « Projet » d’où le terme approprié ici est « gestion de produit » remplaçant celui de « gestion de projet ».

Les différentes méthodes agiles

Il existe plusieurs types de méthodes Agiles, se différenciant par leur capacité d’adaptabilité à certains projets. Parmi ces méthodes nous retrouvons la méthode RAD qui implique par exemple la présence d’une tierce personne pour résoudre les problèmes et les incompréhensions. La méthode SCRUM, la méthode FDD et la méthode DSDM sont quant à elles basée sur l’organisation de plusieurs mais courtes réunions permettant de d’approuver chaque étape, contrôler les avancées et développer une bonne relation de confiance entre les intervenants en la rendant plus interactive.

Loin d’être une simple méthodologie, l’approche Agile définit un état d’esprit impactant l’ensemble des entreprises souhaitant s’y conformer. Cette démarche, à la fois longue et difficile à mettre en œuvre, en vaut largement la peine. Elle permet, en effet, d’obtenir des résultats très satisfaisants. Il est donc primordial d’en maitriser chaque partie afin de faire accepter ce changement tant au sein de l’entreprise qu’auprès du client.

Les évolutions récentes

La plupart des méthodes « agile » de gestion de projet sont ciblées sur les projets de développement de logiciel. Est-ce à dire qu’on ne peut utiliser Agile que pour l’informatique? A l’heure où la mondialisation exige des Entreprises qu’elles soient toujours plus agiles pour se repositionner sur le marché grâce à des innovations constantes, ne pourrait-on pas imaginer créer des produits non logiciels de façon agile?

La réponse est bien sûr positive. Les méthodes de gestion de projet traditionnelles se sont récemment enrichies d’une version agile. L’agilité n’entame en rien la nécessité d’utiliser une méthode éprouvée. Aussi, récemment les principaux éditeurs ont publié des versions « agile » de leur méthode traditionnelle :

  • AXELOS, éditeur de PRINCE2, vient de publier PRINCE2 Agile qui à donné naissance à la certification PRINCE2 Agile Practitioner,
  • PMI a créé récemment la certification PMP-ACP (PMP Agile Certified Practitioner).

Alors au final vous êtes plutôt Agile ou Classique?

Les méthodes Agiles pourront être utilisées pour de gros projets car elles proposent une adaptabilité, une meilleure visibilité et gestion des risques. Elles pourraient tout aussi bien être utilisées pour les projets où il n’y pas de documentation détaillée. Le client peut alors suivre la progression du projet et l’adapter au fur et à mesure selon ses besoins.

.Par contre, les méthodes Traditionnelles seront plus adaptées si vous avez une idée précise de votre projet avec un cahier des charges et planning très détaillé où vous avez anticipé tous les risques envisageables. Nous essaierons prochainement de vous orienter entre l’approche Traditionnelle ou l’approche Agile selon les types de projets. Notre prochain article proposera une étude comparative des approches et méthodes « agile » pour vous aider à faire un choix raisonné.

Bien sûr, nous vous invitons à réagir et à nous communiquer vos commentaires.

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.

ITIL Practitioner, une certification UTILE?

Au moment où la nouvelle certification ITIL Practitioner d’AXELOS arrive sur le marché, nous nous sommes posé la question de son utilité alors que le cursus ITIL est déjà bien fourni et que la grande majorité des informaticiens se contentent de la formation et de la certification ITIL Foundation. Alors était-ce vraiment utile de rajouter encore un niveau supplémentaire?

ITIL Practitioner

ITIL Practitioner, le chaînon manquant

La nouvelle certification introduite sur le marché par AXELOS début février 2016 vient compléter le cursus existant basé sur les niveaux Foundation, Intermediate, Expert et Master qui existent depuis la publication d’ITIL V3 en 2007, en y ajoutant un niveau se situant immédiatement au dessus de la certification ITIL Foundation. En gros ITIL Practitioner c’est en quelque sorte le chaînon manquant dans le parcours de certification d’AXELOS. Nous avons essayé, dans notre précédent article ITIL Foundation, Guide de survie, de clarifier quelque peu le schéma global hérité de celui défini par APMG il y a maintenant bientôt 10 ans. Le diagramme suivant illustre la structure du nouveau parcours de certification:

ITIL Practitioner dans le schema de certification

ITIL Practitioner, c’est quoi?

Il manquait donc, dans ce parcours de certification « historique », un niveau pratique destiné à certifier les aptitudes des praticiens et des consultants dont la tâche quotidienne est de travailler sur des projets d’implémentation ou d’amélioration des bonnes pratiques de gestion des services IT dans les Organisations. C’est bien là l’objectif de cette formation et de la certification ITIL Practitioner. A priori, c’est une excellente nouvelle pour tous les certifiés Foundation qui vont pouvoir maintenant apprendre comment mettre en oeuvre leurs connaissances dans la pratique. La mauvaise nouvelle c’est que le format de la formation préparant à cette qualification tel qu’il est été défini par AXELOS n’est pas vraiment adapté. En effet, cette session est prévue sur une durée de seulement deux jours (examen inclus), ce qui est nettement insuffisant pour couvrir la totalité d’un contenu extrêmement riche et dense. De plus cet examen de certification se déroule à livre ouvert et la formation associée va souvent, en fonction de votre organisme de formation et de la compétence de ses formateurs, se focaliser sur la façon d’utiliser le manuel dans un cas réel plutôt que sur un retour d’expérience sur les problématiques rencontrées par les consultants dans leur expérience concrète de conseil en Entreprise. C’est bien dommage. Bien sûr on m’objectera que les personnes concernées peuvent toujours demander une formation de durée plus longue pour appréhender l’ensemble des pratiques décrites mais, franchement, quelle Entreprise acceptera de financer une session plus longue que les deux jours préconisés par AXELOS?

Le parcours existant de certification était-il suffisant?

Nous avons clairement montré dans notre article sur le parcours « historique » de certification ITIL qu’il manquait de toute évidence un niveau de certification destiné à la fois aux consultants en charge de mener des projets d’implémentation et/ou d’amélioration des bonnes pratiques ITIL ainsi qu’aux personnels internes aux organisations concernés et impliqués dans les projets d’implémentation et/ou d’amélioration. Bien sûr, on m’objectera que c’était normalement la vocation des niveaux dits « Intermediates » et du niveau MALC conduisant à la certification ITIL Expert. Hélas, sur aucun de ces niveaux ne sont abordées les problématiques clés liées spécifiquement à un projet d’implémentation telles que la gestion du changement organisationnel, la facilitation du changement culturel, la communication à mettre en oeuvre pour viser à assurer la réussite d’un tel projet ou encore la conception d’un modèle de métriques et d’indicateurs nécessaires pour s’assurer que les bénéfices attendus en termes de création de valeur pour les parties prenantes de l’organisation sont bien réalisés conformément au cas d’affaire validé en début du projet. Ces aspects ne sont traités nulle part dans le parcours de certification ITIL « historique ». Cela signifie que même un « Expert ITIL » se trouve complètement démuni face à ces problématiques qui constituent cependant le quotidien des consultants et qu’il sera souvent incapable de mener avec succès un projet d’adoption et surtout d’adaptation des pratiques ITIL dans une Entreprise. Trop de lacunes existent!! Cela explique sûrement en partie les raisons de l’échec de tant de projets d’implémentation de bonnes pratiques ou de processus sur la base d’ITIL.

Les apports du cours et de la certification ITIL Practitioner

La publication par TSO de ITIL Practitioner Guidance vient combler quelque peu les lacunes existant dans les 5 publications centrales sur lesquelles sont basée les certifications historiques depuis ITIL Foundation jusqu’à ITIL Expert. Cette nouvelle publication sert de trame à la nouvelle certification ITIL Practitioner à laquelle elle donne son nom. On retrouve donc dans le syllabus de la formation et de la certification ITIL Practitioner les éléments clés de la publication qui est d’ailleurs autorisée pour le passage de l’examen.

Concrètement, elle s’articule autour 3 grands thèmes principaux correspondant aux trois compétences clés indispensables pour réussir un projet d’implémentation ou d’amélioration des pratiques de gestion des services en adaptant les processus ITIL au contexte de l’organisation :

  1. Communication
  2. Gestion des Changements Organisationnels (OCM)
  3. Mesures et métriques

Un consultant, certifié ITIL Expert, qui ne possèderait pas ces trois compétences clés se retrouverait un peu dans la situation du joueur de tennis avec un énorme potentiel qui possède parfaitement le jeu d’échange de fond de court mais qui est incapable de réussir un service ou de monter au filet face à son adversaire. Il ne pourrait que perdre la partie, étant dans l’impossibilité de s’adapter au contexte…

Elle est complétée par les 9 principes qui doivent guider toute initiative d’implémentation ou d’amélioration, hérités d’autres cadres tels que COBIT, DevOps, Agile, Lean etc.

La gestion de changement est un facteur-clé de réussite

Les neuf principes supportant une initiative d’implémentation

L’expérience a montré que la réussite de tout projet d’implémentation basé sur une approche d’amélioration continue résulte systématiquement de neuf principes directeurs suivis par le projet et permettant de délivrer les résultats attendus. Ces neuf principes, repris par de nombreux cadres de bonnes pratiques, s’appliquent bien évidemment aux projets ITSM.

1 – Focalisation sur la valeur

Tout projet d’implémentation ou d’amélioration des services IT doit créer de la valeur pour les parties prenantes de l’Entreprise et, seules ces mêmes parties prenantes sont à même d’évaluer les bénéfices résultant du projet.

2 – Focalisation sur l’expérience utilisateur

Les services et les processus IT doivent toujours être conçus pour satisfaire les besoins des clients et des utilisateurs afin de leur fournir une expérience positive de bout-en-bout.

3 – S’appuyer sur l’existant

Il ne faut jamais repartir de zéro. Un projet ne peut réussir que si l’existant, avec ses forces et ses faiblesses est bien compris pour permettre l’adaptation des bonnes pratiques, génériques par essence, au contexte spécifique de l’Entreprise, en capitalisant sur ses forces existantes.

4 – Utiliser une approche holistique

Aucun composant ou service n’existe en isolation. Les services sont des systèmes complexes qui doivent toujours être envisagés depuis la conception jusqu’à l’exploitation et l’amélioration comme un tout.

5 – Progresser de façon itérative

Il faut résister à la tentation, souvent forte, de vouloir tout faire en même temps. Toujours découper le travail en « tranches » faciles à gérer et délivrant chacune un bénéfice mesurable sur lequel on pourra capitaliser pour conserver l’élan afin d’entamer la tranche suivante. Ce sont les petits cours d’eau qui créent les grands fleuves…

6 – Observer directement

Toujours baser ses décisions sur des informations vraies, pertinentes et incontestables. A chaque fois que c’est possible, toujours remonter à la source de l’activité et observer directement, en personne.

7 – Faire preuve de transparence

Toujours être clair et honnête sur ce qui se passe vraiment et pourquoi, dans le déroulement du projet de telle sorte que les rumeurs et bruits de couloir ne puissent pas miner la confiance des personnes concernées et que la vérité soit toujours clairement établie de telle sorte que chacun puisse toujours s’exprimer sereinement sur des bases claires et incontestables.

8 – Favoriser un approche collaborative

Toujours travailler ensemble de façon créative avec les personnes concernées par le projet dans la direction validée. Le partage des efforts et de l’engagement permettra ensuite de partager les résultats et les bénéfices.

9 – Garder les choses aussi simples que possible

Ne faire que ce qui est indispensable pour atteindre l’objectif fixé et toujours éliminer ce qui ne contribue pas directement à la création du bénéfice attendu et qui constitue, de fait, du gaspillage.

A qui s’adresse la certification ITIL Practitioner?

Cette certification, comme vous l’aurez certainement compris, s’adresse directement aux personnes impliquées dans un projet d’implémentation ou d’amélioration des services et processus IT en Entreprise, mais aussi, et de façon primordiale, aux consultants accompagnant ce type de projets chez leurs clients.

Cette certification se situe, dans le nouveau parcours de certification, au niveau immédiatement au dessus de la certification ITIL Foundation. Pourtant, il apparaît clairement que les professionnels qui en tireront le plus grand profit sont avant tout les certifiés ITIL Expert, car elle leur apportera le côté pratique qui leur manquait jusque là. Très sincèrement, après avoir passé (et réussi) cette certification, et malgré les nombreux projets de ce type que j’ai eu la chance de mener dans des Entreprises de toutes tailles et dans des régions du monde différentes, j’ai trouvé cet examen d’un niveau de difficulté tel que j’imagine que peu de candidats sans expérience et possédant seulement la certification ITIL Foundation seront capables de le réussir, surtout après une formation de deux jours.

Alors, ITIL Practitioner, UTILE ou pas?

Oui, bien sûr, ITIL Practitioner est une certification très utile pour tous les consultants, même s’ils risquent de « tomber de haut » à la lecture de leurs résultats à l’examen. Je la préconiserais plutôt à des consultants expérimentés qui y trouveront des réponses à des challenges qu’ils auront dû gérer de façon empirique dans le cadre de leurs missions. A mon sens, compte tenu du format de la formation qui tient sur deux journées, examen inclus, il est nécessaire que les participants aient déjà consacré un temps important à la lecture et à la compréhension du manuel ITIL Practitioner Guidance (Ed. TSO) qui doit impérativement faire partie du package pédagogique remis par votre organisme de formation accrédité (ATO), au minimum 3 semaines avant la session. La formation elle-même portera alors d’avantage sur les retours d’expériences délivrés par le formateur, sur un échange des bonnes pratiques et une bonne compréhension des compétences à mettre en oeuvre et, bien sûr, sur la préparation à l’examen.

Comment se former et se certifier ITIL Practitioner?

Aujourd’hui quelques ATOs proposent d’ores et déjà cette formation à leur catalogue, dont AB Consulting. Vous pouvez également vous auto-former en vous référant au manuel ITIL Practitioner Guidance (Ed. TSO). La meilleure approche consiste indéniablement à approfondir le manuel dans un premier temps avant de suivre la formation ITIL Practitioner auprès d’un ATO (Accredited Training Organization) d’AXELOS qui saura vous apporter les retours d’expérience indispensables à la réussite de cet examen assez difficile.

Pour en savoir plus

A l’occasion du lancement de la certification ITIL Practitioner, AXELOS organise le 25 Février 2016, une conférence internationale au travers de 6 webinaires gratuits accessibles en ligne, directement depuis votre poste de travail. AB Consulting, partenaire d’AXELOS sur cette initiative, vous invite à découvrir en exclusivité cette nouvelle certification avec la participation de l’équipe qui est à l’origine de cette initiative. Pour vous inscrire, cliquez simplement sur l’image ci-dessous:

ITIL Practitioner - Conférences gratuites

 

Si vous avez aimé ou détesté cet article et si vous souhaitez nous apporter vos commentaires, merci d’utiliser le formulaire de contact suivant :

Catégories

Archives

Calendrier

octobre 2018
L M M J V S D
« Sep    
1234567
891011121314
15161718192021
22232425262728
293031  
%d blogueurs aiment cette page :