Actualité

Le changement organisationnel a toujours été le sujet d'intérêt principal de Serge.

• Quelle est la productivité d'une équipe dans le travail quotidien?
• Comment la direction peut-elle assurer l'excellence et la performance de manière durable?
• Comment le changement peut-il être mis en œuvre efficacement et sans perturber la productivité actuelle?

La gestion des processus de l'entreprise et la gestion de projet sont les deux disciplines clés pour le changement organisationnel.

Lorsque, au début des années 2000, la gestion de projet a commencé à attirer davantage l'attention, Serge a contribué à établir cette discipline dans de grandes sociétés multinationales et à favoriser les échanges professionnels en co-fondant et en s'engageant dans des associations locales de gestion de projet comme le PMI Switzerland Chapter et eco-HERMES.

Il y a cinq ans, Serge a démarré son entreprise de conseil et de formation "processCentric GmbH" avec un focus clair sur la gestion des processus de l'entreprise, domaine dans lequel il voit beaucoup de potentiel pour les organisations dans les années à venir.

La gestion de projet n'a rien perdu de son importance pour lui, mais elle est passée de son domaine d'intervention à un simple moyen de mise en œuvre du changement de processus de l'entreprise. En plus d'offrir des formations de gestion de processus, de règles et de cas (parfois regroupés sous le terme «business analysis»), il partage ses connaissances et son expérience de la gestion de projet dans des formations et des cours universitaires.

Qui est Serge et comment en est-il arrivé là où en est maintenant? Lisez ses réponses à notre interview ci-dessous.

 

Quel est votre titre d'emploi actuel? Que faites-vous réellement?

Je travaille en tant que consultant (et chef d'entreprise) pour processCentric GmbH, une société de conseil spécialisée dans la gestion des processus de l'entreprise, de règles et de cas, que j'ai fondée il y a 5 ans. Dans le cadre de mes activités, je propose également des formations liées à mon conseil tant en tant qu'instructeur dans la formation continue et en tant que chargé de cours à l'Université de Fribourg et la Haute Ecole Spécialisée Bernoise.

 

Comment avez-vous fini comme formateur en gestion de projet et consultant pour le secteur hospitalier?

Je ne pense pas avoir "fini" quoi que ce soit; avec chaque client, j'apprends de nouvelles choses et je continue à développer mes compétences. J'adore travailler avec des gens qui veulent s'améliorer dans leur travail, c'est la raison d'être de la gestion des processus de l'entreprise. Très souvent, un élément clé pour la mise en œuvre du changement est la gestion de projet.

C'est pourquoi, même si mon intérêt principal est la gestion des processus de l'entreprise, la gestion de projet a toujours retenu une grande part de mon attention. Le secteur hospitalier est particulièrement intéressant à cet égard car ici, à la fois le travail quotidien et les résultats du projet ne permettent pas d'erreurs, ceci en parallèle avec un progrès technique et une pression sur les coûts qui ne cessent d'augmenter.

 

Qu'est-ce qui rend les projets en milieu hospitalier exceptionnels?

L'environnement hospitalier est très interdisciplinaire. Comme je l'ai mentionné dans la question précédente, les erreurs ou défauts ne peuvent pas être acceptés dans de nombreux domaines de travail. En même temps, les effectifs sont limités, les progrès technologiques sont à couper le souffle et la politique continue à exercer de la pression sur les coûts.

En ce qui concerne la gestion de projet, il est important de porter une attention particulière à la gestion des risques et de la qualité, qui pour moi sont de toute façon les disciplines clés de la gestion de projet.

 

Comment les "best practices" de gestion de projet peuvent-elles améliorer les performances dans les hôpitaux?

Il s'agit de focaliser! Lorsque j'analyse les processus de l'entreprise, l'un des facteurs les plus préjudiciables à la performance est la distraction. Le personnel hospitalier a des tâches très importantes sur lesquelles il doit focaliser afin d'assurer le fonctionnement de l'organisation dans son ensemble pour le bien de la santé des patients.

Ils doivent pouvoir s'appuyer sur les infrastructures et les processus mis en place par les projets. Il ne faut pas les déranger avec des projets en difficulté. Les projets gérés par des professionnels doivent fonctionner comme une machine bien huilée afin que personne qui n'y est pas directement impliqué ne s'en rende même compte.

 

Quels sont vos conseils sur la façon de relever ces défis?

Soyez conscient que la gestion de projet est une discipline à part entière et nécessite de l'attention. Ce n'est pas quelque chose qui peut être bien fait par quiconque, sans une formation appropriée et avec la priorité la plus basse possible en plus d'avoir des dizaines d'autres responsabilités.

Allouez des ressources appropriées à la gestion de projet pour améliorer la performances et les résultats. Les hôpitaux sont des systèmes en changement continu et le moyen d'assurer une mise en œuvre durable du changement est la gestion de projet. Cela en fait une discipline clé pour vous!

  Serge Schiltz a complété ses études de mathématiques (dipl. math.) et d'informatique (dipl. inf.) avec un doctorat en informatique (Dr. sc. inf.). En parallèle à ses activités professionnelles, il a fait une formation en gestion de l'entreprise (MBA in Business Administration), gestion de projets (MSc in Project Management, PMI PMP), processus (OMG OCEB Business Advanced, IASSC Lean Six Sigma Black Belt) et services (ITIL v4 Foundation) . processCentric GmbH a été fondé en 2015 par Serge Schiltz.  

Le business analyst (BA) ou analyste d’affaires est une personne qui aide les organisations à améliorer leurs processus, services et produits grâce à l’analyse des données, de la documentation et à l’évaluation du business model ou de son intégration avec la technologie (il aide à combler le fossé entre la partie informatique et Business). Le business analyst a pour rôle :

• L’identification des besoins de changement de l’entreprise et l’évaluation de leur impact sur l'entreprise,
• L'analyse, la documentation et la communication des exigences avec les parties prenantes concernées.

 

Le rôle du business analyst

L’activité principale des analystes d’affaires consiste à aider les entreprises à mettre en œuvre des solutions technologiques de manière rentable. Le professionnel doit déterminer les exigences d’un projet ou programme et les communiquer clairement aux parties prenantes.

Le business analyst est le professionnel responsable de la recherche de solutions techniques aux problèmes de l’entreprise. En outre, il définit, analyse et documente les besoins, en étudiant l'entreprise dans sa globalité et les besoins en informations de l’organisation.

 

Les responsabilités du business analyst 

Les responsabilités du business analyst peuvent varier d’une entreprise à l’autre. Certaines responsabilités peuvent être limitées à des projets liés aux technologies de l'information, alors que d'autres organisations peuvent impliquer le business analyst dans des domaines tels que les ventes, la finance, le marketing ou les opérations.

Quoi qu’il en soit, le business analyst doit conserver une vision holistique des systèmes de l’entreprise en se concentrant sur 4 domaines clés:

• L’organisation,
• Les personnes,
• Les processus,
• La technologie.

 

Les responsabilités communes des BA sont 

La création d'une analyse détaillée de l’entreprise, décrivant les problèmes, les opportunités et les solutions pour l’entreprise. L’analyse de la structure d'entreprise, son utilisation de la technologie et ses objectifs :

• La formulation de pistes d’amélioration,
• L’analyse stratégique,
• La cartographie des processus et des flux de valeur,
• La cartographie des aptitudes et des compétences,
• L’aide à la conception, la documentation et le maintien des processus du système,
• La supervision et la mise en œuvre de nouvelles technologies et systèmes,
• La communication des informations clés et des résultats à l'équipe produit,
• La définition et communication des exigences de l'entreprise aux parties prenantes.

 

Les compétences du business analyst

Selon le guide BABOK®, les compétences principales du business analyst peuvent être identifiées suivant 6 catégories de compétences :

• La pensée analytique et la résolution des problèmes,
• Les caractéristiques comportementales,
• Les connaissances Business,
• Les compétences en communication,
• Les compétences relationnelles,
• Les applications et logiciels.

 

1. Les compétences analytiques et la capacité à résoudre les problèmes sont les compétences essentielles du métier de Business Analyst et comprennent:

• La pensée créatrice,
• La prise de décision,
• La résolution de problème,
• La pensée critique.

 

2. Les caractéristiques comportementales sont essentielles pour gagner la confiance des parties prenantes, puisque le BA aura accès à des informations, des systèmes et d’autres actifs de grande valeur et sera impliqué dans des projets critiques. Ces compétences comprennent:

• Les compétences interpersonnelles et consultatives,
• La gestion du temps et les compétences organisationnelles.

 

3. Les connaissances Business donnent au BA un avantage supplémentaire et comprennent :

• Les principes et pratiques Business,
• Les connaissances de l'industrie,
• Les connaissances organisationnelles.

 

4. Le BA doit s’assurer qu’il communique clairement ses principales idées et ses observations/conclusions. C’est pourquoi les compétences en communication sont des compétences clés comme par exemple :

• Les compétences en communication orale et écrite,
• La communication visuelle,
• L’écoute active.

 

5. Le Business Analyst facilite les interactions entre les parties prenantes afin de les aider à exprimer leurs besoins et à résoudre les désaccords concernant la priorité et la nature des exigences. Ces compétences relationnelles comprennent :

• La conciliation, la négociation ou la médiation,
• Les compétences en leadership et en management,
• Le travail en équipe.

 

6. Le Business Analyst doit avoir une connaissance des applications et des logiciels qui sont susceptibles de l’aider dans son activité quotidienne, des plus populaires aux plus spécialisés, tels que les systèmes de gestion de documents, les systèmes de gestion de contenu, etc. qui sont parfois construits spécialement pour l’organisation pour laquelle il travaille.

Quelle est votre fonction actuelle ? Quelles sont vos missions ?

Je suis responsable du domaine gouvernance et gestion de projet de façon transverse pour les différents bureaux, au sein d’ITECO. Je définie et promeus l’offre et j’apporte le support méthodologique, le «knowledge management» aux différents bureaux de gestion de projets.

A côté de ça, j’ai également une activité de consultant auprès d’un certain nombre de client, en relation avec le périmètre gouvernance et gestion de projet.

 

Comment êtes-vous arrivé à effectuer une carrière en gouvernance et gestion de projet ?

J’ai suivi la voie classique à l’époque, c’est-à-dire que j’ai commencé ma carrière à Bruxelles en tant qu’analyste-programmeur en systèmes bancaires, puis à Paris pour contribuer au logiciel d’assurance. Après cela, j’ai eu l’opportunité de rejoindre un fournisseur de logiciels développant des solutions pour les groupes financiers. Avant de rejoindre Itecor, j’ai travaillé pendant plusieurs années en tant que consultant puis chef de projet chez Cap Gemini Suisse.

En 15 ans d’expérience en gestion de projet, j’ai eu l’opportunité d’intervenir sur d’autres sujets en relation avec la gouvernance en générale, le service management, la gestion de portefeuille, l’arbitrage des investissements et j’ai également réalisé beaucoup d’audit.

Mon expérience – et mes cheveux gris – m’ont permis de m’orienter vers ce type de prestation en faisant moins de gestion de projet. Je conseille désormais un certain nombre de clients en matière de GRC, de gestion de portefeuille, de gestion de service. Ses prestations sont pour moi, un excellent moyen de partager la connaissance et l’expérience acquises, en complément d’une gestion de projet pure et dure. J’interviens toujours au niveau de la gestion de projet mais sur des aspects méthodologiques, en proposant des prestations de conseil et des formations.

 

Quel est le plus gros changement auquel vous avez dû faire face lors de l’implémentation des Bonnes Pratiques dans vos portefeuilles projets ?

Basé sur mes expériences, j’ai constaté un réel changement dans l’attitude des directions ces 5 dernières années. Au-delà de l’aspect technique de la gestion de projet, il y a une plus grande sensibilité des directions à la notion de portefeuille de projet, au besoin d’avoir de la visibilité sur les projets, sur leur investissements et également de pouvoir exercer un arbitrage sur ces investissement.

Je trouve ce changement très intéressant car il place enfin la gestion de projet au bon niveau, c’est-à-dire au niveau du pilotage stratégique et de l’arbitrage, là où il aurait dû être depuis toujours.  

Quel est l’impact ce changement sur le quotidien des chefs de projet, si il y en a un ?

Il y a en effet des répercussions sur la gestion de projet. Je ne parlerais pas de complications mais cela implique effectivement d’avantage d’exigences. Le fait de mettre en place une gestion de portefeuille, ne fût-ce que pour la remontée d’information et le suivi d’indicateur des projets, nécessite plus de rigueur.

Le chef de projet doit désormais renseigner les différents indicateurs plus régulièrement mais également structurer le projet par phase (si on souhaite une découpe par phase plus ou moins homogène au niveau d’un portefeuille).

L’impact peut être important sur la gestion de projet dans les situations où les chefs de projet géraient de façon peut-être trop laxiste le projet, sans être hyper rigoureux ou pas totalement dans un outil et se retrouvent face à des exigences plus importantes, qu’ils doivent désormais satisfaire.

 

Selon vous, ce changement est-il compatible avec la gestion de projet Agile ?

Malgré ce qu’on peut entendre, je ne pense absolument pas qu’une méthode agile réduise le contrôle. L’Agilité amène bien au contraire, un contrôle ou un suivi beaucoup plus proche de la réalité.

Il peut éventuellement y avoir une problématique de remontée d’information, qui est uniquement technique, entre un cadre méthodologique agile qui a ses propres indicateurs et les indicateurs classiques des méthodes traditionnelles.

On voit d’ailleurs émerger cette notion de projet hybride, dans lequel on voit cohabiter des projets traditionnels (waterfall), des projets purement agiles et des projets mixtes (hybrides). Le mélange est très intéressant car il combine par exemple, les aspects d’infrastructure d’une démarche classique et les aspects de développement une démarche agile.

D’une manière générale, chacun interprète les méthodes agiles comme il le veut, souvent par manque de connaissance. Il y a souvent cette perception d’équipe qui s’auto-organise où l’on s’imagine que les membres de l’équipe font ce qu’ils veulent dans leur coin, sans la moindre autorité ni contrôle.

En réalité c’est plutôt l’inverse, un projet agile demande énormément de rigueur si l’on souhaite le mener à bien, d’où l’importance de s’appuyer sur un cadre de référence ou une méthodologie pour fixer un cadre structuré.  

Avez-vous des leçons tirées de l’expérience ou conseils à partager avec les PMO ?

Une des spécificités de notre marché est qu’il n’est pas rare de rencontrer des chefs de projet dits « de milice ». Ces professionnels sont parfois des gens du métier, des informaticiens, qui n’ont pas nécessairement une formation ou une expérience poussée dans la gestion de projet et à qui on confie des projets.

Le conseil que je me permettrais de donner, par rapport à ce constat de miliciens, à qui l’on demande de conduire des projets en plus de leurs activités opérationnelles, est de laisser le temps à un PMO de commencer petit et de grandir. Il est important de permettre au PMO de se déployer pas à pas, pour ne pas perdre les chefs de projet et les faire monter graduellement en compétences.

Il faut également faire attention de prendre le temps de monter une structure, d’avoir une ambition qui correspond à la réalité du terrain et de ne pas monter un PMO en compétence pour le plaisir du PMO. Le cas échéant, le danger est de se couper de la réalité des chefs de projet en leur imposant des exigences avant tout méthodologique et non pragmatique. Il faut nous, être pragmatique et y aller progressivement, bien embarquer les chefs de projet dans la mise en œuvre d’un PMO ou d’un portefeuille de projet.  

Quelles sont selon vous les étapes majeures pour mettre en place un PMO ?

La première chose à faire, qui rejoint ce qui a été mentionné auparavant, c’est de définir ce qu’on attend de ce bureau de support et les objectifs à atteindre. On sait que les PMO sont à géométrie variable selon les entreprises, ils peuvent avoir des rôles et objectifs qui diffèrent d’un environnement à un autre.

La première chose à faire est donc de définir les objectifs et les bénéfices business qui sont attendus. Encore une fois, il ne faut pas faire de la technique pour faire de la technique ni de la méthodologie pour faire de la méthodologie, mais veiller à ce que la mise en place d’une organisation de ce type réponde aux objectifs métiers et que ces derniers ont été clairement définis et communiqués à l’ensemble des parties prenantes.

Il faut ensuite calibrer son PMO par rapport à ces objectifs définis et validés par la ou les directions, puis progressivement mettre en place le PMO, de façon classique. Cette première étape d’alignement sur les besoins métiers est primordiale selon moi.

Ensuite pour les professionnels qui ne connaissent pas les étapes suivantes, je pourrais leur recommander de suivre une ou plusieurs des formations QRP International, mais je dirais encore une fois, la prochaine étape dépend des attentes du PMO.

Pour moi, en termes d’attente, un PMO doit pouvoir mettre à disposition des chefs de projets auprès des projets, apporter un support méthodologique, effectuer les remontées d’indicateurs mais également de gérer le portefeuille. En fonction des objectifs visés, il faut définir les objectifs et les prestations du PMO à mettre en œuvre.

Je conseille vivement d’instaurer une culture métier de base, si elle n’existe pas. Quand je dis une culture métier de base, j’entends définir ce qu’est un projet, définir si il y a des découpes en phases qui doivent être respectées et qui peuvent varier d’un projet à l’autre et déterminer les indicateurs et les responsabilités du chef de projet par rapport à l’activité du PMO.

Une fois que tout cela est défini, les étapes suivantes consistent à mettre progressivement ces éléments en place et amener petit à petit la rigueur souhaitée auprès des différents projets.

 

Quelles sont pour vous les clés du succès d’une transformation organisationnelle ?

La clé du succès d’une transformation organisationnelle est selon moi la conduite du changement, que l’on retrouve en tant que telle comme méthodologie et mais également associée à la gestion de programme. Je ne parle pas du côté technique mais plus de l’accompagnement des personnes.

 

Quelles sont les compétences et qualités d’un bon PMO ?

Tout dépend des attentes du PMO mais en général :

• l’expertise en gestion de projet, notamment pour apporter du support au chef de projet les relations humaines, qui sont primordiales,
• garder à l’esprit les besoins et objectifs stratégiques (ne pas suivre une démarche purement méthodologique mais s’adapter et être à l’écoute du business).

 

Citez trois notions que vous souhaiteriez apprendre dans un proche avenir pour vous développer en tant que professionnel ?

• Tout d’abord, d’un point de vue personnel, je souhaite en savoir plus sur les aspects compliance et contrôle interne.
• Ensuite, sur le plan projet, je voudrais développer la problématique des données personnelles à prendre en compte dans une démarche projet, c’est-à-dire d’un point de vue de la découpe en activité, de bien positionner cette problématique dans la gestion de projet.
• Enfin, j’aimerais améliorer mes connaissances actuelles sur la sécurité de l’information dans l’optique de la certification ISO 27 000.

 

Alain Geerts

Avec plus de 25 ans d’expérience professionnelle en informatique, dont 15 ans en gestion de portefeuille, de projet et en conseil informatique, Alain est un manager et consultant senior spécialisé dans les domaines de la gouvernance informatique, de la conformité, du contrôle interne et des Bonnes Pratiques.

Suivez Alain sur Linkedin.

Pour ceux qui se penchent pour la première fois sur le monde Agile, les deux rôles Scrum Master et Chef de Projet peuvent sembler similaires, mais en réalité, ils ne le sont pas. Le Scrum Master et le Chef de Projet jouent deux rôles très différents.

Le Chef de Projet est un leader qui gère le projet et son équipe. Sa responsabilité principale est d’atteindre les objectifs du projet.

Le Scrum Master a un rôle de facilitateur, de coach pour l’équipe Scrum. C’est un servant leader qui veille à ce que le cadre de référence Scrum soit compris et utilisé par tous les membres de l’équipe et qui élimine les obstacles suceptibles de nuire au travail de l’équipe de développement. Il est considéré comme coach, facilitateur pour diverses raisons :

1. Contrairement au Chef de Projet, il ne gère pas l'équipe projet, mais veille au respect des valeurs et des principes du cadre de référence Scrum.
2. Le Scrum Master soutient le Product Owner.
3. Il est responsable des processus Scrum, de leur mise en œuvre correcte et de la maximisation de leurs bénéfices.

Si le Chef de Projet guide la planification des activités pour l'exécution du projet, le Scrum Master soutient les autres membres de l'équipe, travaillant en étroite collaboration avec eux, tout en veillant à ce que les principes Agile soient correctement suivis.

Le Scrum Master se distingue du Chef de Projet pusqu’il n'assigne pas de tâches aux membres de l'équipe et ne leur dit pas quoi faire. Il a pour rôle de faciliter le processus en aidant l'équipe à s'autogérer et à s'auto-organiser. Les équipes Scrum se différencient de la structure hiérarchique de la gestion de projet traditionnelle puisqu’elles s’auto-organisent: les membres de l’équipe choisissent comment s’organiser pour mener à bien leur travail et ne reçoivent aucune instruction de l’extérieur.

Les responsabilités du Chef de Projet traditionnel, dans un projet Agile, sont réparties entre:

• Le Product Owner.
• Le Scrum Master.
• L’équipe de développement.

Les activités du Scrum Master changent quotidiennement en fonction des besoins de l’équipe: le Scrum Master doit permettre à l’équipe de mener à bien son travail en la protégeant des risques externes. Il joue un rôle fondamental car il accompagne l’équipe dans son cheminement vers la réussite du projet.

Le Chef de Projet se concentre sur le projet, tandis que le Scrum Master se concentre sur l'équipe et ses membres. Le Chef de Projet doit s'assurer du succès du projet, tandis que le Scrum Master doit s'assurer que l'équipe réussit.

 

Le Chef de Projet dans un contexte agile: relation avec l'équipe Scrum

Il peut arriver que les entreprises passent des méthodes traditionnelles à des méthodes agiles et que le Chef de Projet ait beaucoup de difficultés à passer aux processus agiles, précisément en raison des différences de fonctionnement entre les deux types d’équipes traditionnelles et agiles.

Dans un contexte agile, le Chef de Projet doit déléguer la planification détaillée aux équipes Scrum. La relation entre les Chefs de Projet et les équipes de développement a tendance à être plus informelle: le rôle du Chef de Projet est beaucoup plus centré sur la garantie que les équipes Scrum travaillent dans le bon contexte que sur la vérification du travail spécifique effectué par les équipes.

Le Chef de Projet doit collaborer avec les équipes de développement, les aidant à résoudre les problèmes plutôt que de les gérer. Le Chef de Projet doit toutefois s’assurer que l’équipe de développement a bien compris les objectifs convenus au début de chaque timeboxe et comprend l’importance de respecter les livraisons prévues afin d’atteindre les objectifs.

En conclusion, les rôles de Chef de Projet et de Scrum Master sont différents. Certe ils ne s’excluent pas, mais il ne faut pas pour autant penser que le Chef de Projet peut devenir un Scrum Master. En effet, certains Chefs de Projet ne parviennent pas à assumer le rôle de Scrum Master précisément parce qu'ils essaient d'appliquer le style "management et contrôle" dans l'équipe Scrum.

Un bon Scrum Master est un professionnel passionné d’Agile qui sait mettre ses connaissances à disposition des autres, à travers le «servant leadership», peu importe que son background soit plus technique ou issu de la gestion.

 

Sources:

• Schwaber and Sutherland, The Scrum Guide;
• DSDM Agile Project Management Handbook v2;
• Agile Project Management and Scrum v2, DSDM Consortium.

Lors d’une première Interview avec Bernard Gauchier, consultant expert sur les activités de tests et de qualification, impliqué dans la mise en place de la démarche DevOps au sein de grands groupes français, nous mettions en avant les problématiques du mouvement DevOps. Dans ce second article, nous revenons ensemble sur les différentes étapes de l’implementation du mouvement DevOps, les techniques, les conseils et les leçons tirées de l’expérience.

 

Bernard, pouvez-vous nous décrire les différentes étapes de l'implémentation DevOps au sein des entreprises dans lesquelles vous avez travaillé ?

1. Réaliser un audit, comprendre l’existant, et l’organisation actuelle Il est nécessaire de démarrer par une étude des flux d’opérations depuis la conception d’un produit/projet jusqu’à son utilisation/exploitation quotidienne. Cette étape menée par exemple avec l’approche VSM va reconstituer la chaine de valeur, identifier notamment les points de décisions, les contraintes, les temps morts, les pertes d’énergie, et cibler le type d’outillage et d’organisation à viser.
2. Définir des objectifs et traiter les contraintes L’étape suivante, la plus critique, est celle qui définit et apporte les solutions orientées DevOps: Shift Left, Continuous Integration, Delivery et Deployment. Elle va favoriser les expérimentations (POC, Pilote) pour démontrer l’efficacité de ces solutions et alimenter l’adhésion au changement. Il peut y avoir beaucoup d’itérations sur cette étape et il importe de se fixer des objectifs réalistes dans des périodes limitées (six mois à un an) pour démontrer et acter le changement dans un esprit d’Agilité.
3. Amélioration continue La dernière étape consiste à ajuster les solutions et le dispositif DevOps mis en œuvre. A l’aide de tableaux de bord sur les différents axes de gains (productivité, couverture des tests, délai de mise à disposition, taux d’incidents…) on va vérifier la valeur ajoutée fournie à l’entreprise et s’inscrire dans une boucle d’amélioration.

 

Parmi les diverses techniques proposées par DevOps, lesquelles préférez –vous ?

• Value Stream Mapping
• Théorie des Contraintes
• Kanban

 

Avez-vous des leçons tirées de l'expérience ou conseils à partager avec la communauté DevOps ?

Un changement aussi important que celui apporté par DevOps se prépare en impliquant les équipes Développement et Opérations dès le départ. J’ai connu des situations ou l’une des deux organisations conçoit seule l’implantation du DevOps avant de tenter de convaincre un peu tardivement l’autre entité de l’accompagner.

Je conseille de s’appuyer sur un sponsor de la direction générale et de mettre en place très rapidement des groupes de travail mixte pour rapprocher les équipes et éviter le fonctionnement en « silo ». Il est nécessaire de communiquer régulièrement et largement sur les acquis déjà obtenus (QuickWin en particulier).

De plus, ce type de changement dans la gestion du SI peut représenter un investissement initial non négligeable. L’offre en terme d’outillage étant riche et se renouvelant constamment, il faut garder une certaine capacité à changer ou à adapter les solutions choisies. Encore une fois la direction joue un rôle très important dans la communication et des meetings, des séminaires ou des ateliers sont les bienvenus pour maintenir une communication claire et effective.

 

Bernard Gauchier

Consultant expert sur les activités de tests et de qualification, Bernard est également formateur sur les référentiels ISTQB et TMMI. Il intervient sur des programmes de transformation DevOps en mettant en place les procédés et outils de Continuous Testing et en étant impliqué dans la coordination des différents chantiers de transformation et d’accompagnement au changement. Il a récemment complété cette expérience terrain par la certification DevOps Foundation et est en voie de devenir Formateur accrédité.

Suivez Bernard sur Linkedin ou consultez son site internet

Le Service Manager est garant de la bonne fourniture de son service et en charge de sa perpétuelle amélioration pendant toute la durée du contrat et suivant les termes de celui-ci.  

Service Manager, définition

Un responsable de service est généralement responsable de la définition du service, de la gestion des SLA (Service Level Agreement) et de la garantie que les services répondent aux besoins de l'entreprise.

Il / Elle gère les membres de l'équipe du service, mesure et analyse le travail effectué, propose des améliorations aux processus, y compris une interaction avec le service client (plaintes et demandes).

 

Le rôle du Service Manager

La principale responsabilité du responsable de service est d’interagir avec l’équipe commerciale, de comprendre les contrats de SLA et de superviser l’équipe de service chargée du support et de la maintenance des infrastructures.

C’est le professionnel responsable de la création de valeur pour les clients, mais sous forme de services.

 

Les responsabilités du Service Manager

Les responsabilités communes du Service Manager sont :

• Superviser et guider toutes les activités de l'équipe de service.
• Coordonner les créations de SLA (via l'interaction avec l'équipe commerciale).
• S'assurer que l'équipe respecte les Bonnes Pratiques et maintiennent les SLA.
• Surveiller les problèmes du service et les plaintes des clients.
• Élaborer des plans de gestion des problèmes et d’amélioration des services.
• Veiller à ce que les clients, le support technique et les autres parties techniques soient représentés dans la définition et l'évolution des services.
• Offrir un service client.
• Maintenir la relation client.

 

Les compétences du Service Manager

Les compétences clés d’un Service Manager peuvent être identifiées suivant 2 catégories de compétences :

Compétences Commerciales

• Réflexion stratégique.
• Analyse commerciale.
• Délégation efficace.
• Gestion des risques.
• Priorisation et gestion du temps.
• Communication claire.
• Gestion de la relation commerciale.

Compétences Techniques

• Large compréhension technique.
• Gestion des niveaux de service.
• Ingénierie de service.
• Orientation client.