Soutenance mémoire
La stratégie de services
Méthodologie
Le but de la recherche est d’acquérir des réponses aux questions formulées au travers de l’application d’une démarche scientifique. Avec cette motivation, nous avons identifié et appliqué une méthodologie de recherche. Les différents éléments qui la constituent sont comme suit.
Type de travail
Ce travail est de type :
Descriptif et analytique : une partie de cette recherche consiste à établir la situation actuelle et la décrire pour en comprendre l’environnement et les corrélations qui agissent.
Mais principalement, cette recherche s’appuie sur des faits et des informations qui sont à disposition et l’activité principale est d’évaluer ces données et formuler une analyse critique.
Appliqué : la finalité de cette étude est de proposer des solutions pratiques aux problèmes que rencontre le service informatique.
Qualitatif : nous nous intéressons aux investigations sur le comportement humain et plus particulièrement les interactions de ceux-ci. Ceci dans le but de comprendre les motifs sous-jacents.
Empirique : dans cette étude nous nous appuyons sur des observations et expériences. Elle est soutenue par la collecte de données et la formulation de solutions vérifiables et mesurables.
3.2 Choix de la méthodologie
Dans le cadre de ce travail nous utilisons la méthode de recherche scientifique. Cette méthode est basée selon les axiomes (Kothari, 1990) :
1. Elle s’appuie sur des preuves empiriques,
2. Elle utilise des concepts pertinents,
3. Elle prend en considération uniquement les objectifs,
4. Elle est éthiquement neutre, elle ne vise qu’à faire des déclarations adéquates et correctes,
5. Elle conduit à des solutions prévisibles et probabilistes,
6. C’est une méthode réplicable et explicite,
7. Elle vise à formuler la plupart des axiomes généraux ou ce que l’on peut appeler des théories scientifiques.
Cette démarche est représentée comme suit :
Nous employons cette méthode car elle encourage à procéder de manière rigoureusement et impersonnelle. Elle repose sur des objectifs logiques et systématiques sans biais personnel ou préjudice. Une méthode utilisée pour démontrer par le raisonnement logique, et pour mener les investigations de manière organisée, reproductible et constante.
Collecte des données
Nous recueillons essentiellement des données qualitatives par deux canaux :
La participation aux séances d’équipes : la pratique de la méthode Scrum exige la présence de plusieurs réunions d’équipe. Parmi celles-ci, nous avons participé à des Sprint Review, Sprint Retrospective, Sprint Planning et Program Increment Planning.
Des entretiens individuels avec les collaborateurs :
o Membres du service informatique : développeurs, product owners, scrum masters, business analystes, responsables qualité et membres du management o Membres externes du service informatique
Résultat escompté et risques
Le souhait du service informatique est d’obtenir des suggestions d’améliorations pratiques et concrètes. Nous procédons selon la méthode scientifique expliquée précédemment pour atteindre cet objectif.
Par conséquent, nous identifions que le risque principal de cette étude est la modification du périmètre initialement défini. En effet, ce travail à initialement pour but d’étudier les éléments en amont et en aval de la réalisation de produits et la possibilité d’élargir les principes de l’agilité à l’extérieur du service informatique par le marketing.
Avec l’introduction aux problématiques et premiers échanges avec les membres du service informatique, nous pensons que l’étude aura une orientation axée à l’interne du service. Et, que par marketing nous entendons la promotion de la stratégie, pilotage, gouvernance et engagement transverses comme hiérarchique.
Analyse
Par le biais des observations récoltées lors de la participation aux séances d’équipes, d’entretiens et d’échanges avec les membres du SI et externes, nous sommes en mesure d’évaluer les problématiques communiquées par le service informatique. Cette récolte à large spectre, nous permet d’identifier des problématiques additionnelles qui n’ont pas été identifiées préalablement.
Ces problématiques sont comme suit (sans ordre particulier et sans distinction de catégorie) :
La définition d’un « projet » n’est ni claire ni homogène.En octobre, le service informatique a fait l’acquisition d’un nouveau module de gestion de projets qui vient compléter les fonctionnalités existantes de ServiceNow®. Cette nouveauté technique comme procédurale introduit une nouvelle terminologie qui est celui d’un « projet ». Lorsqu’une demande est réceptionnée par le SI, qu’elle soit clinique ou non, elle peut être transférée en état de projet. Mais ce changement de statut soulève la question primaire : quand est-ce qu’une demande est-elle considérée comme un projet ?
Aucune priorisation centralisée
Le service informatique peine à prioriser les demandes qu’elle reçoit. La cause principale, relève d’une décentralisation de la priorisation :
Les demandes cliniques sont priorisées par le Clinical Board,
Les demandes non cliniques sont priorisées par d’autres Boards et la plateforme SI.
Les projets business sont validés par la plateforme SI et sont transmis par l’Entreprise Architect®.
Lors de ces priorisations, nous retrouvons très peu de critères d’évaluation communs et ceux-ci présentent des degrés de complexité variés. Il est par conséquent très difficile de comparer les évaluations entre elles.
Le SI ne dispose pas des informations nécessaires pour uniformiser ces évaluations. D’autant plus, que le SI évolue dans un environnement dynamique et est confronté à des variations et facteurs externes qui peuvent influencer les travaux en cours. Ces enjeux soulèvent les questions suivantes : comment garantir une priorisation fiable lors de l’évaluation de la demande ? Et, comment réévaluer la priorisation en t+1 ?
Il y a un écart entre ce qui est perçu comme réalisé par le client et par le SI.La réalisation d’une tâche pour le SI est régie par la « Definition of Done ». Cette définition a été faite sur mesure et est propre à chaque équipe du SI. Mais le lien entre les attentes clients et ce qui est considéré comme réalisé selon cette définition est dans la plupart des cas désaligné voire flou. Cela relève les questions suivantes : quand est-ce qu’une demande peut être clôturée ? Quels sont les impacts d’éléments partiellement complétés sur un projet et sur l’image du service informatique ? Comment garantir la transparence et la cohésion ? Et, comment assurer la traçabilité et le suivi avec le client ?
Impossible d’avoir une roadmap
Depuis le mois de septembre, le SI pratique l’exercice de « Program Increment Planning ». Cet exercice doit remplir plusieurs objectifs pour le SI, il doit :
1. Permettre aux équipes d’avoir une vue commune des travaux à venir et – sur une plus longue durée.
2. Avoir une priorisation commune des travaux à venir.
3. Synchroniser les travaux transverses.
4. Aligner les objectifs business avec les objectifs métier et IT.
5. Être un lieu de partage inter-équipes.
6. Injecter les projets business dans le processus de gestion de la demande du SI.
Cet exercice a nécessité quelques séances avant de parvenir au livrable final qui est le « Program Board ». Celui-ci regroupe les EPICs à venir pour chaque équipe sur quatre mois. Les EPICs possèdent des activités transverses qui impliquent d’autres équipes et sont indiquées selon un code couleur.
C’est une pratique qui manque encore de maturité. Mais elle nous permet de relever les interrogations suivantes : comment le SI doit-il prendre des décisions quant à sa priorisation sans avoir une vue d’ensemble des facteurs macro environnementaux (politiques, stratégiques, gouvernementaux, légaux, économiques etc.) ? Quelles sont les interactions entre le Clinical Board, la plateforme SI et le service informatique quant aux activités de priorisation ? Quels projets mettre en avant lors de ces séances ?
Communication peu claire sur les demandes en cours
Les utilisateurs qui déposent une demande peuvent accéder au statut et l’avancement du traitement de celle-ci sur le portail interne de l’Hôpital du Valais. Les différents statuts disponibles quant au traitement sont : Brouillon, Soumis, En évaluation, Qualifié, Approuvé et Terminé. Mais ces statuts ne sont pas tous affichés et sont sans explications. Nous nous interrogeons sur la compréhension de ces statuts par les clients. Cette page représente le canal primaire de communication avec le client et n’est évidemment pas adaptée pour une communication claire ni explicite.
Déséquilibre entre les activités de maintenance et les activités de développement
Le service informatique fait face à un réel déséquilibre quant aux activités de maintenance et d’exploitation, et les activités de développement (projets). Les équipes estiment que les tâches de maintenance représentent 40 à 70% de leurs occupations. Parmi ces tâches de maintenance nous distinguons : les tâches d’exploitation panifiées et les tâches non planifiées.
Actuellement, le service informatique ne dispose pas de mesure pour quantifier exactement la répartition, mais d’après les informations collectées nous pouvons certifier que la majorité des tâches sont non planifiées. Ce qui est en accord avec le sentiment partagé des membres du service
informatique : « qu’ils travaillent uniquement de manière réactive et en flux tendu ». Ceci soulève le questionnement : comment réconcilier les activités planifiées et non planifiées ? Comment avoir un meilleur équilibre entre les activités d’exploitation et les activités de développement ?
Manque de maturité dans les processus et méthodologies
Une évaluation de la maturité des processus internes a été effectué. Les processus évalués sont ceux de la gestion du changement, gestion des incidents, gestion des problèmes et le design des services. Cette évaluation s’est basée sur une échelle de 1 à 5, selon les critères :
Formalisation du processus,
Enregistrements,
Indicateurs du tableau de bord,
Actions d’améliorations,
Système d’information et communication,
Lien avec les autres processus,
Veille technologique et benchmarking4,
Capitalisation du savoir-faire,
Maîtrise des risques, et,
Gestion des compétences
Ce graphique représente la superposition des processus évalués susmentionnés selon différents axes. Comme l’indique ce graphique, les processus évalués ont les lacunes considérables. Nous notons deux axes qui sont critiquement absents : la maîtrise des risques et les actions d’améliorations. Nous en concluons une performance faible, lacunaire et en retard.
En complément à cette évaluation, l’état actuel du niveau de maturité de l’agilité du service informatique a également été examiné. Il en ressort que la culture agile et que la création de valeur selon les principes agiles sont les axes les plus lacunaires.
Nous nous interrogeons sur la réussite de l’implémentation de l’agilité au sein du service informatique en phase avec la certification ISO 9001. Mais surtout sur la sensibilisation et l’acceptation des collaborateurs de ces normes, méthodes, applications et outils.
|
Table des matières
1.INTRODUCTION
1.1 CONTEXTE
1.2 OBJECTIFS
1.3 QUESTION DE RECHERCHE
1.4 DÉFINITION DÉTAILLÉE DU TRAVAIL
1.4.1 L’Hôpital du Valais
1.4.2 Centre de Services (CdS)
1.4.3 Service Informatique HVS
1.4.4 Problématiques du service informatique de l’Hôpital du Valais
2 ÉTAT DE L’ART
2.1 ITIL
2.1.1 La stratégie de services
2.1.2 Le design de services
2.1.3 La transition des services
2.1.4 L’exploitation des services
2.1.5 L’amélioration continue des services
2.2 MÉTHODE AGILE
2.3 SCRUM
2.3.1 Phases du Scrum
2.3.2 Artefacts du Scrum
2.3.3 Rôles du Scrum
2.3.4 Avantages du Scrum
2.4 KANBAN
2.5 SCALED AGILE FRAMEWORK (SAFE)
2.5.1 PI Planning
3 MÉTHODOLOGIE
3.1 TYPE DE TRAVAIL
3.2 CHOIX DE LA MÉTHODOLOGIE
3.3 COLLECTE DES DONNÉES
3.4 RÉSULTAT ESCOMPTÉ ET RISQUES
4 ANALYSE
4.1 PRIORISATION
5 DÉVELOPPEMENT ET RECOMMANDATIONS
5.1 RECOMMANDATION N°1 – PROMOTION DE LA COMMUNICATION PROJET
5.1.1 Définition « projet »
5.1.2 Communication projet
5.2 RECOMMANDATION N°2 – RÉCONCILIATION DU PROCESSUS D’AMÉLIORATION CONTINUE
5.2.1 Encouragement
5.2.2 Support organisationnel
5.2.3 Ressources dédiées
5.2.4 Marche à suivre
5.2.5 Mesures de la performance et succès
5.2.6 Plan d’implémentation
5.2.7 Exemple de lettre d’engagement du Management Team
5.3 RECOMMANDATION N°3 – ÉQUILIBRAGE DES ACTIVITÉS
5.3.1 Actions d’amélioration
6 SYNTHÈSE ET CONCLUSION
6.1 LIMITES
6.2 AMÉLIORATIONS FUTURES
7 REFERENCES
8 TABLE DES FIGURES
9 TABLE DES TABLEAUX
10 ANNEXES
Télécharger le rapport complet
