Actualité

Nous étions à table. C’était un espace de co-working que je souhaitais tester, dans ma région, regroupant des co-workers d’horizons divers prêts à partager leur savoir et leur savoir-faire avec d’autres personnes d’autres entreprises. Une expérience neuve pour moi. Nous étions en 2014 et je venais de recevoir ma certification ITIL V3. Je préparais la formation de mes 60 collègues. Un jeune homme, très fraîchement sorti des études monopolise non pas l’attention mais du moins la conversation, convaincu d’avoir quelque chose à vendre à toute cette joviale assemblée… Son discours est assez péremptoire, il semble assez sur de lui et a une forte envie d’en découdre avec tout supporter d’ITIL… Je l’entends dire : « il faut absolument se séparer de la bureaucratie inhérente à l’implémentation d’ITIL dans les entreprises ». Je défends une conception de la gestion des services qui est beaucoup plus flexible et efficace. Mon référentiel est facile à mettre en place, remplacera rapidement ITIL qui coûte cher et enferme les entreprises dans des processus lourds et inutiles. Tous ceux qui ont implémenté ITIL s’en mordent les doigts parce qu’aujourd’hui ils souhaiteraient en sortir et n’en ont plus la possibilité. Je venais d’investir une semaine de mon temps, et m’apprêtais à signer un bon de commande de 40000 € pour former tout un service aux bonnes pratiques, vous imaginez donc mon inquiétude. En même temps, il me fallait en savoir plus.   Je posai donc quelques questions rapides :

• Comment résout-on les incidents avec ce framework ?
• Il n’y en a presque plus, donc un retour au tableau Excel est largement suffisant.
• Wow… Donc il y a une gestion de l’imprévu en amont, une résolution proactive d’incidents potentiels sur base d’événements constatés ?
• Même pas, les systèmes sont stables par nature…
• Eh bien, et ce grâce à un ensemble de choix technologiques particuliers ?
• Oui bien sûr, mais surtout grâce à une méthode de développement qui supprime tout bug à la source…
• Une méthode Agile ?
• Quoi, il y a d’autres méthodes de développement ?

  Là, j’ai pensé « On avance » !

• Dis-moi, as-tu des exemples concrets d’organisations qui sont enfermées dans ITIL et voudraient en sortir ? Cela m’intéresserait de partager leur expérience pour éviter cela à mon Service.
• Toutes !

  J’ai compris à ce moment que j’avais en face de moi une brillante jeune pousse formée à l’argumentation et au bagout, mais en aucun cas à la gestion des services. Laissant la discussion se terminer de cette façon, je remis à plus tard la suite de mon interrogatoire. De retour à nos postes de travail, je retournais près de lui pour connaître le nom de ce référentiel magique. Du bout des lèvres, il me dit : ça s’appelle ‘DevOps’. Ce fut mon premier contact avec DevOps, et j’avais déjà l’intuition qu’il avait bien retenu les leçons de son gourou, mais qu’il n’en avait pas capté l’essence. J’ai donc cherché par moi-même… trouvé de bonnes pistes et suis finalement entré dans ce monde, sans jamais quitter ITIL. Il n’y avait à cette époque que très peu de documentation vraiment structurée sur le sujet. Des bonnes idées qui ensemble formaient un magma plein de bonnes intentions dont on ne pouvait que ressentir l’énorme potentiel. C’est durant cette année cependant qu’une première mise en mots vit le jour. Un roman sur l’IT et  DevOps appelé « The Phoenix Project ». Une immersion dans un effort de transformation d’une entreprise à travers la modification profonde de son service IT. Lire ce livre, c’est un peu comme prendre de l’expérience sans rien faire : une immersion pleine d’enseignements. Il est vrai qu’au début du livre, certains processus ITIL sont attaqués pour leur lourdeur, mais en aucun cas il n’est recommandé de s’en défaire complètement. Mieux au fil du livre, on se rend compte de l’influence essentielle des bonnes pratiques ITIL sur la réussite de la transformation DevOps, et de l’égale importance pour celles-ci d’être élaguées de ce qui ne produit pas de valeur. On peut donc avancer vers un concept de Lean-ITIL, et une partie du chemin vers DevOps est parcouru. Avec le temps, DevOps ayant gagné en maturité, de même que ses adeptes et praticiens, il est clairement indiqué, dans les premières pages des formations ‘Foundations’ que les 3 sources d’inspiration de DevOps sont ITIL, Lean et l’Agilité. Pour insister un peu plus, l’obsolescence d’ITIL est considérée comme l’un des mythes accompagnant systématiquement le seul nom DevOps. Je crois fermement que ITSM et le mouvement DevOps ne sont pas opposés. Au contraire, ils offrent un mariage Culturel parfait (Selon Gene Kim, auteur - entre autres-  du Phoenix Project et du DevOps Handbook, traduction libre de l’auteur de cet article) . Cette citation a été lancée avant même la sortie d’ITIL 4… qui s’est agilisé. DevOps n’effaçait pas l’intérêt d’ITIL V3, inutile de dire ce qu’il advient d’ITIL 4 dans ces conditions. Il reste donc critique pour les services IT de prendre connaissance et de mettre en place les pratiques ITIL , DevOps en utilisera le fruit avec succès. J’ai souvent repensé à ce jeune homme. Je ne peux que le remercier d’avoir déclenché cette remise en question. En aucun cas je ne lui reprocherai sa légèreté insouciante… Au contraire, je lui souhaite aujourd’hui d’avoir gagné en maturité au même rythme que le mouvement qu’aujourd’hui nous représentons ensemble.  

Xavier Heusdens

Xavier a plus de 20 ans d’expérience dans la gestion de projets, programmes au sein des organisations. En plus de son activité de consultant, Xavier est formateur multilingue pour PMP, PRINCE2 et DevOps. Il est également formé aux méthodes AgilePM, ITIL, COBIT, MOP et change management. Suivez Xavier sur Linkedin

«Les approches agiles n'impliquent pas de planification» est certainement l'une des idées reçues les plus courantes sur l'agilité. C’est en réalité l'exact opposé! Dans cet article, nous passerons en revue quelques conseils et techniques pour gérer le changement de manière agile et présenterons une approche pour réaliser une planification de haut niveau ainsi que les techniques nécessaires pour développer des plans spécifiques pour chaque élément de changement. Dans notre précédente interview avec Mélanie Franklin, coprésidente du Change Management Institute UK, nous avons vu combien il est important de gérer le changement dans un monde agile. Les changements agiles sont en effet complexes et continus.

• Complexes car l'innovation continue implique une obsolescence continue, de sorte que la durée de chaque changement devient de plus en plus courte et les changements de plus en plus fréquents.
• Continus parce qu'ils font désormais partie de l'entreprise comme une activité habituelle.

 

Comment planifier dans un environnement agile?

Dans un contexte Agile, on parle souvent de «solution évolutive» (evolving solution). Une solution évolutive nécessite une planification continue tout en gardant en vue l'objectif final. Pour planifier chacun des changements nous avons besoin d’orientation, d’avoir un but/une destination, qui conduira à la transformation de notre façon de travailler. Il faut ensuite se demander quelle est la partie la plus utile, celle qui pourrait vraiment nous aider à atteindre l’objectif. C'est ce qu’on appelle réaliser un schéma de décomposition, où l’on prend une idée dans sa totalité et on la divise en petites parties. Il est ensuite plus facile de comprendre quelles parties réaliser en premier et lesquelles faire ultérieurement. Il est donc conseillé d'utiliser une approche “bottom up” pour identifier le temps et les ressources nécessaires et d’en informer les parties prenantes. Dans la planification agile, il y a une forte implication des ressources, afin qu'elles puissent réellement contribuer au projet. Il faut constamment se demander : "faisons-nous vraiment la chose la plus pertinente dans notre planification en ce moment"? Cette activité peut sembler facile, mais ce n'est pas le cas: il est important de se demander constamment quelles composantes de l'idée finale peuvent réellement fonctionner et donner vie à l’objectif final. De cette façon on obtient une planification globale de haut niveau puis une planification plus spécifique pour chacune des parties. Avec l'agilité, le niveau de détail augmente progressivement.  

Changement de comportement

Qu’est-ce que c'est et pourquoi c'est important

L'une des plus grandes difficultés des approches agiles est de comprendre l'importance du changement de comportement. Souvent, l'accent est exclusivement mis sur le temps pour créer des changements techniques et tangibles, mais l'impact du changement sur la façon de travailler est sous-estimé. Les employés seront peut-être déstabilisés, leur expertise ou méthode de travail se trouvant impactées et ils devront être formés aux nouvelles techniques et aux nouveaux systèmes. Les activités de transition prennent du temps, il faut accepter le changement, partager l'objectif, accepter de faire des erreurs, continuer de s'entraîner et pratiquer les nouvelles méthodes de travail. Lorsque le changement est constant, il est essentiel que les ressources acceptent que leur travail change et donc de prendre en compte leur bien-être émotionnel. Il est nécessaire de s’assurer que les ressources impliquées sont prêtes pour les nouvelles activités et les nouvelles façons de travailler. Il arrive souvent que la partie technique et tangible aille beaucoup plus vite et qu'une différence se crée entre les activités du projet et celles du changement. Ils se peut malheureusement que les ressources soient encore absorbées par les récentes activités de changement. Mélanie Franklin identifie trois éléments de changement de comportement:

• tester de nouvelles façons de travailler
• comprendre comment faire les choses
• créer de nouvelles habitudes

Par conséquent, les activités de projet et de changement de comportement doivent être synchronisées afin de ne pas avoir de nouvelles fonctionnalités ou choses que les ressources n'utilisent pas car elles ne sont pas encore en mesure de le faire. La première étape consiste à être conscient que le changement n'est pas seulement matériel, mais qu’il affecte également les ressources humaines et leur façon de travailler. Ainsi on obtient l'équation: livraison + mise en œuvre = une nouvelle façon de travailler. À la fin de chaque itération, les parties prenantes devraient être d’accord sur la façon de gérer le changement. Il s'agit d'une activité collaborative, puisqu’elle implique les responsables du changement et les utilisateurs.  

L'importance d'une livraison ponctuelle

Respecter les délais de livraison permet d’anticiper, de savoir quand les changements arriveront et le temps nécessaire pour voir des améliorations. Diviser les activités et respecter les délais, c'est aussi donner une réponse aux ressources qui attendent le nouveau service et la nouvelle façon de travailler, ces mêmes ressources qui ont reçu les outils et la formation adaptée pour pouvoir commencer à travailler autrement. Il est important de respecter les promesses de livraison car le changement est toujours une source de stress: les ressources mettent tout en œuvre pour être prêtes et un retard pourrait augmenter l'impact émotionnel du changement. Le respect des temps est donc fondamental. Mais comment décomposer la totalité de l'échéancier ? M. Franklin suggère des niveaux de planification (image ci-dessous) La période donnée (timeframe) est décomposée en itérations, où les résultats (outcome) sont identifiés à la fin de chaque itération. Afin d'atteindre les différents jalons (milestone), Mélanie Franklin met en place un processus reproductible composé de 3 étapes:  

1. Getting started
2. Making progress
3. Realising benefits

  1 Getting started Cette première étape est un brainstorming sur toutes les activités à faire (si le projet évolue dans un environnement agile cela se fera sous forme de user stories). Il s'agit d'une activité collaborative et il est essentiel de couvrir à la fois les «livraisons» et les «transitions», liées aux activités de conduite du changement. C'est l'occasion pour toutes les personnes impliquées de comprendre comment le temps sera géré et quelle est la meilleure façon de travailler.   2 Making progress Cette étape est celle qui inclut tous les changements dans les procédures de travail, c'est-à-dire les changements techniques qui entraîneront également des changements dans la façon de travailler. À la fin de cette étape, le travail effectué est passé en revue et la qualité des éléments de changement évaluée, tout en prenant en compte les différentes conséquences qu’ils impliquent.   3 Realising benefits  La solution/les résultats obtenus sont utilisés mais les utilisateurs essaient encore d'encourager l'élimination de tout ce qui n’est plus nécessaire. Pour finir, il est important de créer un environnement motivant, en remerciant les ressources pour le travail accompli (par exemple en partageant les remerciements d'un client pour le service). Ces étapes offrent une structure répétable pour chaque itération utilisée pour planifier les éléments de changement Agile. Pour en savoir plus sur Agile Change Management, consultez l’article: Comment améliorer la conduite du changement dans un monde Agile – Interview de Mélanie Franklin   Sources : How to plan and Agile change initiative, APMG International

Nous savons tous que DevOps est une transformation des personnes et de la culture. Briser le «mur de confusion» entre les Dev et les Ops suppose la collaboration et DevOps encourage une culture de collaboration et d’apprentissage. DevOps veut créer des équipes interfonctionnelles et, bien sûr, requiert une équipe de spécialistes pragmatiques ayant une expérience pratique. Mais DevOps n’est pas un métier et il n’y a pas d’équipe spécifique. En parlant “d’équipe DevOps”, l’industrie est divisée sur la question de savoir s’il devrait y avoir une équipe DevOps ou non. L’article “The Industry Just Can’t Decide about DevOps Teams”* présente différents points de vue. L’opinion la plus populaire est que les équipes DevOps sont un contre-modèle: elles peuvent créer des silos supplémentaires et, plus généralement, toutes les personnes d’une organisation doivent souscrire à la culture DevOps.   Theresa Naete, dans

“Break down DevOps team roles so you can actually get to DevOps”**précise: «Le fait est que nous ne pouvons mettre en place DevOps si nous continuons à cloisonner les équipes. (…) Dans un environnement DevOps, les dev et les op font partie de la même équipe. Je répète: la même équipe ! Ce que certains d’entre nous ne comprennent pas, c’est que la culture est primordiale et essentielle pour les outils. Cette culture comprend la suppression des rôles de l’équipe DevOps, des silos et des barrières de travail afin que tous les outils choisis puissent ensuite être optimisés pour atteindre les résultats souhaités.»

Il y a aussi des partisans de l’idée que les équipes DevOps sont un moyen efficace de passer à une nouvelle façon de travailler et, malgré le fait que la majorité de l’industrie pense que les équipes ne sont pas la bonne approche pour faire évoluer les capacités DevOps à travers une organisation, les équipes DevOps sont en augmentation. L’objectif de DevOps au sein d’une organisation est d’améliorer la livraison de valeur pour les clients et l’entreprise; différentes organisations pourraient avoir besoin de différentes structures d’équipe afin de créer une collaboration efficace entre les Dev et les Ops. Cela signifie que la structure organisationnelle idéale pour implémenter DevOps dépend de nombreuses variables.  

Les rôles DevOps

Comme nous le disions précédemment, il n’y a pas de structure unique établie pour une équipe DevOps (l’équipe DevOps n’existe pas). Les rôles et les responsabilités varient selon les organisations: le plus important est d’identifier les rôles et responsabilités clés et d’avoir les professionnels qualifiés pour les couvrir. Selon TechBeacon ***, les rôles DevOps les plus courants, qui sont essentiels pour toute organisation qui souhaite adopter une approche DevOps réussie, sont: . DevOps Evangelist La personne qui fait la promotion des avantages de DevOps dans toute l’organisation. Il / elle est passionné(e) par DevOps et son rôle est d’assurer l’adhésion des équipes de développement et opérationnelles. L’évangéliste DevOps est votre leader DevOps. . Release Manager Parfois appelé Release Engineer ou Product Stability Manager, il ou elle est responsable de la progression globale et coordonne, gère le produit du développement à la production. . Automation Architect Également appelé ingénieur / expert en automatisation ou spécialiste de l’intégration; il analyse, conçoit et met en œuvre diverses stratégies pour le déploiement continu du produit. Ce rôle est essentiel car il garantit un environnement fiable entièrement automatisé et exempt d’obstacles. . Software Developer/Tester Ce rôle est bien sûr au cœur d’une organisation DevOps (le Dev de DevOps!). Mais dans un environnement DevOps, les développeurs sont responsables non seulement de la conversion de nouvelles exigences en code, mais également des tests unitaires, du déploiement et de la surveillance continue. . Experience Assurance (XA) Professional Si dans le développement de logiciels «classique», l’assurance de la qualité (AQ) a un rôle vital pour la livraison réussie du produit final, dans DevOps, il évolue dans l’assurance de l’expérience, car ce rôle doit également garantir que toutes les nouvelles fonctions et fonctionnalités sortiront en ayant à l’esprit l’expérience de l’utilisateur final. . Security Engineer Il/elle travaille en collaboration étroite avec les développeurs, sécurisant le produit en cours de développement. . Utility Technology Player Professionnel traditionnel des opérations informatiques ou de l’administration de systèmes qui se concentre sur le maintien des serveurs en fonctionnement; il/elle opère efficacement sur les plateformes de développement, les réseaux, les bases de données, les serveurs et les outils.    

La culture DevOps

DevOps consiste à partager et à apprendre. Avoir une personne qui veut constamment apprendre et échanger dans l’équipe est aussi important que d’avoir un membre qualifié. Il y a trois caractéristiques clés pour un professionnel DevOps:

• Avoir un bon esprit d’équipe et être capable d’intégrer la culture de l’organisation.
• Etre curieux et avide d’expérimentation. Expérimenter encore et encore et continuer d’essayer même en cas d’échec, jusqu’à ce que la solution soit trouvée : DevOps encourage l’échec, mais un échec responsable.
• Etre capable de s’adapter et d’approcher le changement avec positivité.

Copyright 2017-2019 Peoplecert International Ltd. Other sources: * Helen Beal, The Industry Just Can’t Decide about DevOps Teams ** Theresa Naete, Break down DevOps team roles so you can actually get to DevOps *** 7 key DevOps roles you need to succeed What Team Structure is Right for DevOps to Flourish?

HERMES est la méthode suisse de gestion de projet pour tous les types de projets. Il s'agit de la norme utilisée par l'administration fédérale pour les projets informatiques ainsi que par de nombreux cantons et communes, et elle est également utilisée dans le secteur privé. HERMES 5 Advanced est la certification destinée aux chefs de projet.  

HERMES Advanced Public visé

• Chef de projet
• Chefs de sous-projet
• Contrôleurs
• Collaborateurs du PMO
• Gestion de la qualité

 

HERMES Advanced Format de l'examen

• Langue: Français et allemand.
• Durée: 120 minutes Partie 1: 60 minutes, Partie 2: 60 minutes.
• Matériel autorisé: Partie 1: Examen à livre fermé. Soit aucun document n'est autorisé, Partie 2: le manuel de référence HERMES et un aperçu des scénarios peuvent être utilisés.
• Questions: Partie 1: 30, Partie 2: 15.
• Taux d’admissibilité: Partie 1: 18, Partie 2: 9. Pour réussir l'examen écrit, au moins 60% du nombre maximal de points réalisables est requis.
• Niveaux taxonomiques (selon Bloom): 1, 2, 3, 4, 5 & 6.
• Format de l’examen : Épreuve écrite.

 

Exemples de questions à l’examen HERMES 5 Advanced

Les épreuves écrites consistent en des questions relatives aux thèmes pertinents et basées sur les objectifs didactiques de l'examen. La procédure pour l'examen HERMES 5 Advanced est la suivante : Questions à choix multiples: plusieurs options de réponse sont disponibles par question. Une ou plusieurs réponses peuvent être correctes (questions à choix multiples complexes). L'évaluation est basée sur un système de points.

• Chaque bonne réponse rapporte un point,
• chaque réponse fausse enlève un point.
• Une absence de réponse (absence de coche) vaut zéro point.
• La notation la plus faible au sein d'une question est zéro point.

 

Exemple de question à choix unique :

Quelle est la source des Bonnes Pratiques? a) Q b) R c) P d) S  

Modèle de demande HERMES 5 Advanced

Les éléments suivants font partie du module système IT: a) Le résultat "concept de migration" b) Le résultat "étude détaillée" c) La tâche "préparer l'intégration du système" d) La tâche "mettre l'ancien système hors service"

Objectifs de la formation HERMES 5 Advanced

Les participants savent comment conduire et piloter un projet selon HERMES et se sont familiarisés avec les tâches de conduite de projet en travaillant sur des exemples types des scénarios standard «Système IT standard» et «Système IT agile». Voici la liste des objectifs d'apprentissage les plus importants :

• Les participants ont revu le contenu du niveau Foundation.
• Les participants ont acquis des connaissances approfondies des modules «Système informatique», «Exploitation informatique», «Migration informatique» et «Développement agile» dans le cadre des scénarios standard «Système IT standard» et «Système IT agile». (Scrum/agil ne fait pas parti de l’examen).
• Les participants ont étudié les modules «Bases du projet» et «Conduite du projet» en détail en travaillant sur un exemple type du scénario standard «Système IT standard» et se sont exercés à mettre en œuvre certaines tâches issues du module.
• Les participants ont étudié en détail le module «Pilotage du projet» en travaillant sur une situation donnée et sont prêts à collaborer avec le mandant et le comité de pilotage.
• Les participants sont préparés pour l'examen de certification de niveau HERMES Advanced (ne fait pas partie de l'examen).

 

Certification HERMES 5 Advanced

En cas de réussite à l'examen, le candidat obtient un certificat. En cas d'échec, il recevra une notification de résultat. Le certificat HERMES 5 Advanced est valable trois ans.  

ITIL 4 fournit une base flexible pour aider les organisations à réussir leur transformation numérique dans la nouvelle ère technologique. ITIL 4 est un modèle de gestion des services informatiques de bout en bout pour la fourniture et l’exploitation de produits et services basés sur les technologies informatiques et permet aux équipes informatiques de continuer à jouer un rôle crucial dans une stratégie d’entreprise plus large. Avec l’augmentation de la demande clients, l’entreprise doit fournir des services informatiques et numériques toujours plus efficaces. Pour faire face à ces besoins en constante évolution et rester compétitifs, les responsables et les professionnels SI se doivent de développer leurs compétences. La formation ITIL 4 Foundation est une introduction au management moderne de services. Elle fournit une compréhension générale du langage et des concepts clés d’ITIL et montre comment les professionnels de l’ITSM peuvent améliorer leur travail et celui de leur organisation grâce au guide ITIL 4. Une fois certifié ITIL 4 Foundation, les candidats peuvent s’inscrire à l’un des quatre nouveaux modules du parcour ITIL 4 Managing Professional (MP).  

ITIL 4 Specialist: Create, Deliver and Support (CDS)

Le module CDS a pour but de former les responsables informatiques afin d’obtenir les compétences essentielles dont ils ont besoin pour planifier leur travail, améliorer leurs produits ou gérer les changements organisationnels. ITIL 4 CDS aide les candidats à devenir des «spécialistes» capables de:

• Mesurer efficacement la performance du service et améliorer son efficacité.
• Intégrer les nouvelles technologies dans les services informatiques et numériques.

Découvrir les prochaines sessions - ITIL 4 Create, Deliver and Support (CDS).  

ITIL 4 Strategist: Direct, Plan and Improve (DPI)

Le module DPI a pour but de former les professionnels des SI afin d’obtenir les compétences essentielles dont ils ont besoin pour assurer une prestation de service efficace, notamment le développement, le déploiement, la surveillance et le support. ITIL 4 DPI aide les candidats à devenir des «stratèges» capables de:

• Établir une direction stratégique forte et efficace et éliminer les silos.
• Diriger le changement organisationnel et développer des techniques essentielles de gestion du changement.

Découvrir les prochaines sessions - ITIL 4 Direct, Plan and Improve (DPI).  

ITIL 4 Specialist: Drive Stakeholder Value (DSV)

Le module ITIL 4 DSV a pour but de former les professionnels chargés de gérer et d’intégrer les parties prenantes, afin d’obtenir les compétences essentielles dont ils ont besoin pour se focalisent sur le parcours ou l’expérience client et pour renforcer les relations avec les partenaires et fournisseurs. ITIL 4 DSV aide les candidats à devenir des «spécialistes» capables de:

• Gérer efficacement les parties prenantes pour s’adapter et répondre à la demande des clients
• Intégrer la conception CX/UX et la cartographie du parcours client pour optimiser l’expérience client.

Découvrir les prochaines sessions - ITIL 4 Drive Stakeholder Value (DSV).    

ITIL 4 Specialist: High Velocity IT (HVIT)

Le module ITIL HVIT a pour but de former les responsables et professionnels informatiques impliqués dans les services digitaux ou dans des projets de transformation digitale, qui travaillent dans ou en direction des environnements à haute vélocité. ITIL 4 HVIT aide les candidats à devenir des «spécialistes» capables d’:

• Intégrer le cycle de vie des produits numériques au modèle d’exploitation principal d’ITIL pour atteindre les objectifs.
• Optimiser et améliorer continuellement le flux pour créer de la valeur dans des environnements à haute vélocité.

Découvrir les prochaines sessions - ITIL 4 High Velocity IT (HVIT).    

Quel module choisir en premier avec ITIL 4 Foundation ?

Avec notre expert Kais Albassir, nous avons développé une série de mini webinaires de 30 minutes sur les nouveaux modules intermédiaires ITIL 4, afin de vous aider à comprendre les différences et choisir le module intermédiaire qui vous convient. S’inscrire aux webinaires pour découvrir les modules en détail.

La certification HERMES Foundation est une qualification professionnelle dans le domaine de la gestion de projets. Cette certification atteste de la compréhension de la méthode de gestion de projet HERMES 5. Il n'y a pas de prérequis obligatoires. Une expérience professionnelle dans la gestion de projets est recommandée.  

HERMES Foundation Public visé

• Chefs de projet
• Chefs de sous-projet
• Contrôleurs
• Décideurs
• Collaborateurs du PMO
• Gestion de la qualité

 

HERMES Foundation Format de l'examen

• Langue: Français et allemand
• Durée: 60 minutes
• Matériel autorisé: Examen à livre fermé. Livres et notes ne sont autorisés
• Questions d'examen: 40
• Taux d’admissibilité: Pour réussir l'examen écrit, au moins 60% du nombre maximal de points réalisables est requis (24 réponses correctes).
• Niveaux taxonomiques (selon Bloom): 1, 2 & 3
• Format de l’examen : Épreuve écrite

 

Exemples de questions à l’examen HERMES 5 Foundation

Les épreuves écrites consistent en des questions relatives aux thèmes pertinents et basées sur les objectifs didactiques de l'examen. La procédure pour l'examen HERMES 5 Foundation est la suivante : Questions à choix unique: Plusieurs options de réponse sont disponibles par question. Une seule réponse est correcte (choix unique), par conséquent une seule réponse doit être cochée. L'évaluation est basée sur un système de points.

• Chaque bonne réponse rapporte un point,
• une réponse fausse ou une absence de réponse (absence de coche) vaut zéro point

 

Exemple de question à choix unique :

Quelle est la source de bonnes pratiques? a) Q b) P c) R d) S  

Modèle de question HERMES 5 Foundation

Dans quel résultat sont consignées les procédures pour la vérification d'autres résultats? a) Plan de release b) Plan de gestion du projet c) Liste des parties prenantes d) Plan de test   Téléchargez maintenant 25 exemples de questions de HERMES 5 Foundation !  

Objectifs de la formation HERMES 5 Foundation

Sur la base du scénario «prestation / produit», les participants ont acquis une compréhension approfondie de l'interaction des différents éléments d'HERMES. Ils savent comment établir des scénarios individuels et sont prêts à collaborer de manière efficace dans des projets HERMES. Voici la liste des objectifs d'apprentissage les plus importants :

• Les participants ont compris les bases d'HERMES.
• Les participants ont acquis une vue d'ensemble du champ d'application et de la structure du scénario standard «Prestation / Produit».
• Les participants ont acquis des connaissances approfondies des modules «Pilotage du projet», «Conduite du projet», «Bases du projet», «Produit», «Structures organisationnelles» et «Organisation du déploiement» dans le cadre du scénario standard «Prestation / Produit»
• Les participants ont traité en profondeur les questions relatives à l'organisation du projet (rôles) du scénario «prestation / produit».
• Les participants savent comment établir des scénarios individuels.
• Les participants sont préparés pour l'examen de certification de niveau HERMES Foundation (ne fait pas partie de l'examen).

 

Certification HERMES 5 Foundation

En cas de réussite à l'examen, le candidat obtient un certificat. En cas d'échec, il recevra une notification de résultat. Une fois la certification HERMES 5 Foundation obtenue, elle est valable à vie. Il n’y a pas de date d’expiration.