Du 7 mars au 14 août 2016 CGI 15 Avenue du Docteur Maurice Grynfogel 31100 TOULOUSE Julie PREVOT, Promotion 2016, domaine GIPSI, option GSI Delphine HANSER, tuteur de stage Chloé GOMES, superviseur de stage Frederick BENABEN, tuteur école TRAVAIL DE FIN D’ETUDE Stage en Gestion de l’Obsolescence et Gestion de la Qualité
52
Embed
TRAVAIL DE FIN D’ETUDEjprevot/Documents/...nouvelle méthode de gestion de l’obsolescence et ui m’a confié l’intégalité de son activité pendant ses congés d’été. Enfin,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Rapport d’action ...................................................................................................................................... 6
I. La RoadMap budgétaire de gestion de l’obsolescence ................................................................... 6
II. L’audit SLL 2016 ............................................................................................................................... 8
Rapport d’étude .................................................................................................................................... 10
I. Contexte ........................................................................................................................................ 10
A. Contexte interne : CGI ............................................................................................................... 10
B. Contexte client : Direction des Systèmes d’Information Airbus ............................................... 11
C. Présentation de la mission ........................................................................................................ 12
II. La gestion de l’obsolescence : un pas vers le futur ....................................................................... 14
A. Les problématiques de gestion de l’obsolescence .................................................................... 14
B. L’activité aujourd’hui ................................................................................................................. 15
C. Construction de l’activité future : 3 years RoadMap ................................................................ 19
III. L’audit SLL 2016 ......................................................................................................................... 25
A. L’activité du SLL et le référentiel ISOM ..................................................................................... 25
B. Les problématiques d’un audit .................................................................................................. 26
C. Mise en place de l’audit ............................................................................................................ 27
IV. Conclusion ................................................................................................................................. 34
Bilan personnel ...................................................................................................................................... 35
Table des illustrations ............................................................................................................................ 40
Dans le cadre de mon travail de fin d’étude, j’ai intégré l’équipe d’obsolescence IMST* chez CGI à
Toulouse. Au sein de cette équipe, nous accompagnons les SLM* dans le remplacement des produits
obsolètes ou obsolescents. Je prends la responsabilité de deux missions.
Le première est la création et la mise en place d’une nouvelle méthode de gestion de l’obsolescence
avec une Service Line* pilote afin de d’obtenir une démarche proactive qui doit amener à terme les
Service Lines* à être autonome sur la gestion de l’obsolescence. De ce travail résulte une clarification
des données actuelles sur les applications et la définition de budget pour des études et la réalisation
de migrations sur les trois années à venir et sur l’ensemble des produits obsolètes ou qui seront
obsolètes dans trois ans. Le travail effectué fût présenté à une seconde Service Line* et lui sera
adressée dès le mois de septembre.
La seconde mission est la réalisation d’un audit interne dans le cadre de l’amélioration continue de
l’ensemble du service du bundle*. Je suis en charge de l’audit des SLL*, il s’agit de se familiariser avec
le référentiel de bonnes pratiques ISOM*, puis mettre en place des améliorations sur le
questionnaire, rencontrer les SLL* et enfin analyser les résultats afin de définir des plans d’action
personnalisés par Service Line* afin d’augmenter la qualité du service.
Ce stage m’aura donc apporter d’avantage d’expérience et de connaissances du fait de la diversité
des activités qui m’a permis, au fil des rencontres des différents acteurs, d’adopter autant de points
de vue variés sur le mode de fonctionnement d’Airbus.
TRAVAIL DE FIN D’ETUDE
4
JULIE PREVOT
Abstract
As part of my last internship, I joined the team of IMST obsolescence in CGI, Toulouse. Within this
team, we support the Service Line Manager in the migration of obsolete or obsolescent products. I’m
in charge of two missions.
The first is the creation and implementation of a new obsolescence management method with a
driver Service Line to get a proactive approach that should lead the Service Lines to be independent
on their activities of obsolescence management. That results a clarification of existing data on
applications and a 3 years roadmap budget definition for study and implementation on all obsolete
products or going obsolete within the 3 years. The initiative was introduced to another Service Line
and will be addressed to it, starting in September.
The second mission is an internal audit as part of the continuous improvement on ITS* bundle. I’m
responsible for Service Line Leader audition. The mission starts getting familiar with the best
practices repository called ISOM*, then implementing improvements to the questionnaire, meeting
the Service Line Leaders to evaluate the standardization relative to ISOM*, eventually analyze the
results to define personalized action plans by Service Line to increase their quality of service.
This internship provided me knowledge and experience due to the diversity of my activities that
allowed me, over the meetings of the various actors to adopt as various points of view on Airbus’
horizon.
TRAVAIL DE FIN D’ETUDE
5
JULIE PREVOT
Introduction
Suite à ma formation en gestion de systèmes d’information à l’école des mines d’Albi, je décide de
m’orienter vers la gestion de projet, en mettant de côté la composante technique de ma formation.
Mes études d’ingénieure s’achèvent par ce stage chez CGI Toulouse pour mettre en œuvre mes
compétences et savoir-faire en gestion de projet, appliqués aux applications informatiques chez
Airbus.
Une grande partie de l’activité toulousaine repose aujourd’hui sur l’un des principaux acteurs de
l'aéronautique : Airbus. Cette immense multinationale s’organise autour de plusieurs sous-traitants
notamment dans le domaine informatique. En effet, le constructeur aéronautique possède une
multitude d’applications en projet, en services ou sur le point d’être retirées. Il est donc nécessaire
de mettre en place des processus de management de l'obsolescence afin d'assurer une continuité du
service et de diminuer les coûts.
C’est au sein de l’équipe d’obsolescence pour IM* que j’évolue pendant ce stage. Ce dernier se
décompose en deux missions principales qui ont pour point commun de prendre part aux principes
de l’amélioration continue.
Ce rapport s’articule de la façon suivante. Une première partie constitue le rapport d’action où je
présenterai succinctement chacune de mes missions qui me sont confiées avec leur contexte, les
résultats, et les suites à donner. La seconde est le rapport d’étude qui présente plus précisément les
méthodologies mises en place et reprend le contenu du rapport d’action de manière plus détaillée.
Enfin, la dernière partie présentera le bilan personnel de mon projet professionnel.
TRAVAIL DE FIN D’ETUDE
6
JULIE PREVOT
Rapport d’action
Durant mon stage, deux missions principales me sont confiées, ce qui m’a permis de découvrir
plusieurs aspects de CGI et notre client Airbus. En plus d’avoir appuyé le travail de l’équipe
d’obsolescence au quotidien, j’ai principalement réalisé deux missions qui sont la création d’une
nouvelle méthode de gestion de l’obsolescence nommée RoadMap budgétaire et la réalisation d’un
audit interne à destination des Service Line Leaders (SLL*). Les deux activités ayant un même objectif
commun, l’amélioration du service rendu par les SLL*.
I. La RoadMap budgétaire de gestion de l’obsolescence L’équipe d’obsolescence est créé en 2014 pour répondre aux besoins d’accompagnement chez
IM* en terme de gestion de l’obsolescence. L’activité de l’équipe s’est développée et représente
aujourd’hui quatre personnes à temps plein. Le service est encore jeune et peu mature alors
chacun est très à l’écoute des besoins des Service Line Managers (SLM*) pour augmenter le
niveau de service.
Le SLM* de la Service Line* Programmes nous fait part de son besoin de pourvoir gérer
l’obsolescence sur l’ensemble des produits de son champ d’action et attribuer un budget
prévisionnel sur les trois années à venir. Nous avons travaillé avec les acteurs chez Programmes
de mai à juillet 2016 pour construire ce nouvel outil, affiner leurs besoins et y répondre.
L’identification globale des besoins est formalisée dans la figure 6.
La RoadMap budgétaire pour la gestion de l’obsolescence considère les 44 applications en
service chez Programmes, chacune est liée à des produits qui sont des systèmes d’exploitation,
logiciels ou plateformes. C’est alors un total de 152 produits distincts et 692 liens qui sont traités
lors de l’étude. Il s’agit de valider ou corriger les liens avec les application managers, de collectés
les informations manquantes sur les produits auprès des product owners et construire une vue
de l’obsolescence pour chaque lien application-produit afin de définir des besoins budgétaires
sur les années à venir.
J’ai rencontré cinq application managers et un architecte réseau pour traiter l’ensemble des 44
applications. La première phase de validation et de correction des liens renseignés dans le
référentiel nous amène à un statut sur l’obsolescence de leurs applications et des produits qui la
composent, voir figure 10. Grace à ce statut nous identifions ensuite des besoins budgétaire,
dans un premier temps pour des études de compatibilité et de coût, dans un deuxième temps
pour l’implémentation du changement.
TRAVAIL DE FIN D’ETUDE
7
JULIE PREVOT
Plusieurs difficultés me font face lors de l’exécution de la RoadMap. Les application managers
ont peu de connaissances en terme d’infrastructure sur leurs applications, ils sont d’avantage en
mesure de fournir des informations fonctionnelles, c’est pourquoi l’architecte de Programmes
nous accompagne à chaque rencontre afin de pouvoir apporter son expertise et compléter les
informations.
De plus, nous souffrons d’un manque d’information sur l’obsolescence des produits. En effet, sur
l’ensemble des domaines, le taux de remplissage Aspire de la date Airbus End of Standard
Support est de 52,13% au 1er juillet 2016 [H]. Pour obtenir ces données, je contacte les product
owners mais il existe une barrière dans la communication, c’est-à-dire que pour un certain
nombre de contacts, je demande le sponsor soit de l’architecte soit de l’application manager
pour obtenir une réponse. Malgré cet appui, il persiste des points bloquants dus à des produits
spécifiques dont les product owners n’ont pas connaissance. Ce problème existe car « product
owner » est un statut et non une fonction, il désigne la personne censée connaître au mieux le
produit dans l’organisation Airbus.
L’outil créé aujourd’hui est bien abouti, certes certains points bloquants restent à éclaircir pour
être exhaustif sur l’étude de l’obsolescence et nous ne sommes pas encore en mesure de
répondre au besoin d’autonomie sur la gestion de l’outil. Pour faire évoluer l’outil au mieux et
être utilisable par les acteurs de la Service Line eux-mêmes, il faut informatiser et automatiser la
RoadMap pour afficher une vue de l’obsolescence telle que nous la proposons actuellement en
récupérant les données directement dans le référentiel Aspire. Attention car l’outil informatisé
ne sera efficace que si la Service Line a un bon niveau de qualité des données dans Aspire.
Néanmoins, l’outil de gestion de l’obsolescence est jugé suffisamment mature pour poursuivre
de l’adresser. Le travail effectué sur Programmes a été présenté à une seconde Service Line et le
SLM* s’est engagé moralement à mettre en place la méthode sur ses applications. Le travail
amorcé est d’envergure car représente potentiellement 108 applications.
TRAVAIL DE FIN D’ETUDE
8
JULIE PREVOT
II. L’audit SLL 2016 CGI s’engage auprès d’Airbus à mettre en place des initiatives d’amélioration continue. Parmi les
différentes actions menées au niveau du bundle, un audit est réalisé annuellement depuis sa
création, soit le troisième audit réalisé. Un audit est une manière efficace de mesurer la
standardisation du service par rapport aux référentiels, ainsi Airbus s’assure de la qualité du
service rendu et pour CGI c’est un point santé sur l’état et la maturité du service.
Je suis responsable de l’intégralité de l’audit du côté des SLL*, depuis le retravail de la grille
d’audition, jusqu’à l’analyse des résultats et l’établissement de plans d’action personnalisés par
Service Line*.
- Suite à l’analyse des résultats de l’année précédente, nous observons qu’un bon niveau de
standardisation et de maturité est atteint sur l’activité des Service Lines*.Afin de pouvoir
encore trouver des pistes d’améliorations malgré le bon niveau de standardisation, il est
nécessaire d’affiner la mesure de la conformité, c’est-à-dire faire évoluer la grille tout en
respectant une continuité dans l’historique des données. Je décide créer des sous-questions
qui viendront évaluer la bonne utilisation des outils et le respect des points clés dans les
processus. Ces questions ont été créées avec la collaboration d’expert en Problem
Management et Incident Management, voir le questionnaire en Annexe 7.
- La réalisation de l’audit s’effectue en deux parties. La première concerne uniquement les
réunions, 50 questions sont adressées pour chaque réunion réalisée dans la Service Line*
interviewée [Annexe 8]. Le but est de créer des bonnes pratiques pour refléter la réalité du
terrain, comment fonctionnent chaque réunion, en termes de fréquence, invités, documents
et sujets récurrents.
- La seconde partie est l’audit global qui mesure la maturité des processus mis en place dans la
Service Line*. L’audition compte un total de 41 questions répartis en fonction des clusters de
l’ISOM, se référer à la figure 13. Au terme de l’audition, le SLL* est invité à s’engager sur des
améliorations qu’il souhaite ou juge nécessaire de mettre en place. L’accent est porté sur le
fait que le travail du SLL* n’est pas jugé, c’est la maturité de la Service Line* que l’on
souhaite mesurer.
- Enfin, j’ai réalisé des plan d’action personnalisés pour chacune des Service Lines* que j’ai
interviewé. Ce retour est composé de deux graphes : le taux de conformité absolu* sur
l’ensemble des questions sur toutes les années où la Service Line fût interviewée et le taux
de conformité absolu de l’année 2016 sur les différents clusters. Et d’une liste d’objectifs
d’amélioration qui résulte des engagements pris pendant l’audition et de sujets jugés
prioritaires suite à l’analyse des résultats globaux sur toutes les Service Lines*.
Des résultats globaux sont disponibles en annexe 9 sur l’interview concernant les réunions et en
annexe 10 une vue du taux de conformité par cluster ISOM* sur l’ensemble des Service Lines*.
TRAVAIL DE FIN D’ETUDE
9
JULIE PREVOT
Le travail d’audit que j’ai réalisé pendant le stage sera présenté à la rentrée de septembre à
l’occasion d’un comité de direction, avec l’audit réalisé en parallèle auprès des ISPL*. A plus long
terme, il est plus que probable que l’audit va persister encore plusieurs années. Les
améliorations qui seront apportées l’an prochain ne sont pas encore décidées, néanmoins des
idées ont déjà été identifiées. En effet lors des audits des points bloquants sont apparus, c’est le
cas d’une confusion entre les différents outils de « knowledge management » et « document
management ». Il s’agira donc d’indiquer clairement les outils attendus correspondant à chacun
des processus mis en cause.
Etant donné le taux de conformité au référentiel grandissant d’année en année, la finesse de
l’évaluation telle qu’elle est aujourd’hui sera bientôt insuffisante car des pistes d’améliorations
ne peuvent être identifié si tous processus sont jugés bien mis en place sur la Service Line* et
conformes au référentiel ISOM*. Cette année j’ai permis de répondre à des besoins de précision
du questionnaire sur le Problem Management et l’Incident Management. Cet approfondissement
pourrait se poursuivre avec les sous-parties Functional Request Fulfilment et Request Fulfilment
car ils fonctionnent de façon synchrone avec les processus d’Incident Management et de
Problem Management [ISOM en Annexe 2] et ensemble représentent le cœur de l’activité du
SLL*.
Ce stage fût riche en activités, en rencontres et donc en expérience grâce à un point de vue
transverse sur les activités du bundle ITS* et au sein de la direction des systèmes d’information chez
Airbus et grâce à la diversité des actions que j’ai mené. Je retiendrai de ce stage une expérience
humaine où j’ai pu apprendre comment communiquer et quelle attitude adopter devant les
différents acteurs dans un environnement de travail complexe.
TRAVAIL DE FIN D’ETUDE
10
JULIE PREVOT
Rapport d’étude
I. Contexte J’intègre une équipe de 4 personnes dans l’agence CGI Toulouse. La présentation du contexte va
d’une part replacer l’équipe dans l’organisation et la hiérarchie au sein de l’entreprise CGI. D’autre
part, le contexte du client Airbus doit circonscrire le champ d’action des différentes activités que je
mène durant mon travail de fin d’étude.
A. Contexte interne : CGI Le groupe canadien CGI se place parmi les cinq plus grands groupes mondiaux dans son domaine,
les services en technologies de l’information et la gestion des processus d’affaires [A]. A l’aube de
ses 40ans cette année, le groupe se distingue en figurant dans la liste Forbes Global 2000 [B].
Cette publication annuelle met en avant les 2000 plus grandes entreprises mondiales sur la base
de quatre critères économiques.
CGI emploie 65000 employés répartis dans 40 pays dont près de 10000 en France [C].
L’organisation en France est divisée autour des 3 grands comptes clients français, c’est pourquoi
ces divisions sont appelées Business Unit : Nord, Grand-Est et Grand-Ouest. Les différentes
agences fonctionnent sous le principe de « metro market » [D], cela signifie que les catalogues
services proposés sont orientés et définis en fonction des clients et les départements de l’agence
correspondent à un catalogue de service. Les départements sont nommés « Bundle »,
littéralement « regroupement » car le catalogue du dit bundle* est un groupement de services.
Mon équipe est partie intégrante du bundle ITS* (ISPL-Testing-SLL). Les services du catalogue
proposent d’accompagner les applications sur tout leur cycle de vie. On différentie deux états
principaux pour une application : en projet ou en service. Deux fonctions principales se
distinguent alors, d’une part les Information System Project Leaders (ISPL*) font de la gestion de
projet déléguée pour le client et sont en charge la gestion des plannings et des ressources selon
le modèle GPP NG (Global Project Process New Generation) [Annexe 1], d’autre part les Service
Line Leaders (SLL*) prennent le relais lors de l’entrée en service de l’application et gèrent par
exemple les tickets, la disponibilité, les accès de l’application, selon le référentiel ISOM (IT
Service Operating Model) [Annexe 2]. Enfin des environnements de tests sont mis à disposition
pour anticiper la transition et sécuriser la mise en service.
Au sein de l’équipe d’obsolescence, bien que nous ne gérons pas des applications en service
comme le font les SLL* classiquement, notre champs d’action vise un ensemble d’applications en
service, c’est pourquoi nous endossons la fonction de SLL*. Notre objectif est d’informer le client
sur les sujets courants d’obsolescence et de l’accompagner dans la gestion de ses
décommissionnements et remplacements de produits.
TRAVAIL DE FIN D’ETUDE
11
JULIE PREVOT
B. Contexte client : Direction des Systèmes d’Informat ion Airbus Airbus, le géant français de l’aéronautique fut fondé en 1970 et compte 62 751 employés en
2010 [E]. L’entreprise se confond de plus en plus avec la société mère Airbus Group depuis la
restructuration d’EADS qui devient Airbus le 2 janvier 2014. Avec ses filiales Airbus, Defence &
Space et Airbus Hélicoptère, Airbus Group se place parmi les leaders dans le secteur aérospatial,
l’aéronautique civile et militaire.
Aujourd’hui, non seulement Airbus fabrique plus de la moitié des avions dans le monde, mais
possède un carnet de commande record qui s’élève à 1006 milliards d’euros en juin 2016[F] et ne
cesse de s’étoffer cette année avec encore 15,5 milliards d’euros de commandes enregistrées
début juillet au Salon de l’aéronautique de Farnborough [G].
Du point de vue organisationnel interne, toutes les activités proposées par le bundle ITS* chez
CGI sont dirigés vers un département unique Airbus nommé IM* (I pour ICT, la direction des
systèmes d’information et M pour Management, Enable, Common Application), voir
l’organigramme en Annexe 3. Dans le département IM* en question, sont gérés l’ensemble des
applications Airbus et Airbus Group. Les applications sont réparties dans le département par
domaine fonctionnel, on va retrouver ainsi la division de tous les domaines importants de
l’entreprise. Par exemple la section IMH* est en charge du mode projet des applications du
domaine Human Ressources. Ce sont dans ces divisions que sont répartis les ISPL*.
Au sein du département IM* on retrouve également la division IMS*, S pour Services. Cette
division est spécifique, elle ne correspond pas à un domaine global Airbus comme les autres
divisions d’IM*. En effet IMS* est dédié à la gestion des applications déjà mises en service.
Néanmoins on retrouve la même différentiation fonctionnelle, ainsi pour chaque division projet
correspond un domaine de service, dont la dernière lettre de l’acronyme est associée. Un
domaine représente alors un ensemble d’applications où sont affectés les SLL*.
Un domaine de service fait exception car ne correspond pas avec une division projet. Le domaine
IMST* (ICT-Management, enable, common application-Services-Transversal) vient recueillir
toutes les activités de types transversales, c’est-à-dire qui auront potentiellement un impact sur
l’ensemble des applications. Mon équipe et moi-même, nous situons dans ce domaine car les
activités de l’obsolescence sont adressées aux quatre grands domaines fonctionnels : IMSC*,
IMSH*, IMSG* et IMSF*.
J’acquière, au sein de l’organisation de notre client Airbus une vision transversale précieuse pour les
missions qui me sont confiées et enrichissante par l’expérience et la compréhension de
l’environnement que cette vision offre. Ce point de vue est renforcé par ma situation chez CGI au
sein d’une équipe soudée, car elle a à cœur de partager ses connaissances et ses savoir-faire.
TRAVAIL DE FIN D’ETUDE
12
JULIE PREVOT
C. Présentation de la mission Deux missions principales me sont confiées pendant ce travail de fin d’étude, leurs activités et
leurs résultats sont tout à fait dissociés. Elles ont pourtant de nombreux points communs qui
construisent le fil rouge de mes objectifs chez CGI et justifie d’acquérir une vision transversale
sur l’ensemble de l’activité réalisée dans la division IMS*.
Malgré leurs différences, les deux activités servent un objectif commun qui est l’amélioration
continue. Pour mener à bien les sujets il faut dans un premier temps comprendre leur contexte
global et identifier la place qu’ils occupent par rapports aux principes de l’amélioration continue
et notamment la roue d’Hemming [Annexe 4].
La première mission est la construction d’une nouvelle méthode de suivi de l’obsolescence. Les
Service Line Managers (SLM*) sont les responsables Airbus d’un ensemble d’applications dans un
domaine, ils sont depuis peu sensibilisés aux sujets de l’obsolescence qui sont adressés par le biai
de la mission encore jeune de l’équipe d’obsolescence, créée il y a deux ans. L’un d’entre eux a
émis le besoin d’obtenir une démarche plus proactive sur la gestion de l’obsolescence sur ses
applications, il devient pilote sur l’activité et nous avons ensemble construit une démarche
nouvelle pour répondre à des besoins plus exigeants : « Obsolescence 3 years RoadMap ».
Figure 1: L'initiative de la RoadMap d'obsolescence dans le contexte de la roue de Deming
La finalité du projet de RoadMap est l’acquisition d’une autonomie des Service Lines* par rapport
à la gestion de l’obsolescence sur leurs applications c’est pour répondre à ce besoin que le projet
de construction de la RoadMap existe et deviendra une activité à part entière des Service Lines.
L’activité de « Check » n’apparait pas dans cette roue car il n’existe pas à ce jour de référence
pour guider la gestion de l’obsolescence. La boucle se clôt avec la mise à jour des informations
collectées dans l’outil Aspire* et l’amélioration successive de l’outil construit.
TRAVAIL DE FIN D’ETUDE
13
JULIE PREVOT
La seconde mission est la réalisation d’un audit interne auprès des SLL* pour mesurer la maturité
de leurs activités et la standardisation par rapport au référentiel ISOM [Annexe 2]. Pour cette
mission je prends en charge non seulement la rencontre des SLL* pour adresser l’audit mais
également la gestion de tout l’environnement de l’audit, depuis la maitrise du référentiel jusqu’à
la réalisation de plans d’action personnalisés pour les Service Lines* et la création de bonnes
pratiques sur les activités.
Figure 2: L'audit SLL dans le contexte de la roue de Deming
Les principes d’amélioration continue sont le fondement de mes missions et doivent
accompagner les activités au quotidien afin d’apporter une plus-value dans mon travail.
En plus de l’expérience apportée par ma situation transverse vis-à-vis de l’organisation client, ma
double casquette me permet d’une part d’appliquer mes connaissances et savoir-faire dans des
situations très différentes, d’autre part d’apprendre à gérer des activités en parallèles et répartir ma
charge de travail.
TRAVAIL DE FIN D’ETUDE
14
JULIE PREVOT
II. La gestion de l’obsolescence : un pas vers le futur Un produit est un composant d’une application, il peut être un système d’exploitation de type
serveurs ou bases de données, un logiciel ou une plateforme. Un produit est définit comme étant
obsolète lorsque la date de fin de support Airbus est passée. Une application est jugée comme étant
obsolète lorsque l’un des produits qui lui sont liés est obsolète.
Les liens entre les applications et leur produits sont référencés dans l’outil Aspire*. Dans la base de
données de l’outil on retrouve également des informations précieuses sur les applications et les
produits : des dates d’obsolescence, des descriptions fonctionnelles, les personnes à contacter, etc.
A. Les problématiques de gestion de l’obsolescence Lorsqu’un produit est obsolète, dans un premier temps un support étendu peut être proposé
cela signifie que la Service Line doit payer un supplément pour obtenir un support de
maintenance. Dans un deuxième temps, le support du produit est complètement arrêté alors le
maintien du niveau de service délivré par l’application est mis en péril, voir le cycle de vie d’un
produit en Annexe 5. Une application qui cesse de fonctionné peut avoir des répercussions
économiques très importante pour la société : avions bloqués au sol (Aircraft on ground*), arrêt
de la production, non accès aux sites…
Les actions de l’équipe d’obsolescence ont pour but de transformer la façon de gérer
l’obsolescence au sein des Service Lines* pour devenir une gestion du cycle de vie des produits et
faire face le moins possible à l’obsolescence sur des applications qui peut être un sujet bloquant
en cas de non disponibilité des applications. Ainsi l’équipe souhaite s’inscrire dans une démarche
de standardisation et d’industrialisation de leurs activités afin de rendre un service toujours plus
efficient.
TRAVAIL DE FIN D’ETUDE
15
JULIE PREVOT
B. L’activité aujourd’hui L’activité d’obsolescence fut créée il y a deux ans afin d’accompagner les SLM* dans la gestion de fin
de vie des produits et applications impliqués dans leur champ d’action. Les sujets à traiter par
l’équipe est définit par le département de la gouvernance lorsqu’un produit est jugé obsolète. Ainsi
l’équipe a suivi l’an passé la migration des navigateurs vers Internet Explorer 11 sur un ensemble de
200 applications. Deux sujets sont traités actuellement par l’équipe : la mise hors service ou
décommissionnement des serveurs Windows 2003 et la migration vers Windows 10.
Décommissionnement des serveurs Windows 2003
Une attention toute particulière est donnée sur les serveurs et les bases de données des
applications car ils impactent directement la disponibilité de l’application et l’intégrité des
données. A la fin de l’année 2014, la gouvernance demande aux différents départements de
mettre tous leurs serveurs Windows 2003 hors service avant la fin d’arrêt du support Airbus
soit avant la fin de l’année 2016.
Figure 3: Fenêtre Aspire, Obsolescence view Windows server 2003 product
TRAVAIL DE FIN D’ETUDE
16
JULIE PREVOT
L’équipe accompagne depuis janvier 2015 les Service Lines* dans la définition de scénarios et
de plannings de migration et mise hors service pour leurs serveurs Windows 2003 pour
atteindre l’objectif et lisser les efforts. L’analyse des résultats du trimestre 2 de l’année 2016
est encourageant car l’effort s’intensifie à l’approche de la date butoir néanmoins insuffisant
pour que l’objectif soit atteint avant cette date. A ce jour il n’y a pas de solution alternative
définie pour conserver un support sur ces serveurs. A partir de janvier 2017 un risque pèse
sur des applications si les serveurs en question persistent.
Figure 4: Suivi du décommissionnement des serveurs Windows 2003
A moins de six mois de l’échéance, le travail de l’équipe d’obsolescence continue,
notamment en alertant sur les serveurs qui n’ont toujours pas de scénarios identifiés ou dont
le scenario est bloqué par le manque de prise de décision ou prise de responsabilité entre les
différents acteurs. Nous travaillons également à estimer le nombre de serveurs mis hors
service à la fin du troisième et quatrième trimestre de l’année 2016, en nous basant sur les
scénarios identifiés et en attribuant un indice de confiance sur les plannings fournis.
TRAVAIL DE FIN D’ETUDE
17
JULIE PREVOT
Migration vers Windows 10
Un nouvel objectif est parvenu courant 2016 de la gouvernance : la migration de tous les
systèmes d’exploitation Microsoft vers Windows 10. Toutes les applications sont
potentiellement impactées par cette migration car elles doivent être compatibles pour
l’utilisation avec Windows 10 installé sur le poste des utilisateurs.
Dans un premier temps, il fût nécessaire d’identifier le champ d’action que notre équipe
possède vis-à-vis de ce projet global à Airbus, de déterminer macroscopiquement les
objectifs et les actions à menés pour valider la montée en version. En réalisant l’état des lieux
des systèmes d’exploitation aujourd’hui, nous identifions deux types de mises à jour :
- Windows 8.1 vers Windows 10
Le système d’exploitation Windows 8.1 est utilisé chez Airbus uniquement sur des
tablettes et PC hybrides. Dans le domaine IM* seuls 6 applications ont été développées
pour des tablettes. Cette migration concerne plus d’applications chez les autres
domaines et le projet est coordonné par la gouvernance elle-même. Ce dernier a débuté
en juin 2016 et doit prendre fin en décembre 2016. La date Airbus End of Standard
Support est annoncée au 31/01/2018.
Le projet est décomposé en trois phases dans lesquelles sont réparties les applications.
Dans la première vague d’action, trois applications IM* ont été testées compatibles et
une application a été rendue compatible par des changements. Les deux applications
restantes feront partie de la deuxième vague en septembre.
- Windows Seven vers Windows 10
Le produit Windows Seven sera considéré comme obsolète à partir de la date Airbus End
of Standard Support: 31/12/2019. Pour cette partie de la migration, chacun des
domaines est libre de conduire l’évolution par ses propres méthodes.
Les 774 applications IM* en service sont potentiellement concernées par cette migration,
selon les données du référentiel Aspire*. En vue du grand nombre d’applications
concernées, la phase d’étude du projet a déjà commencé et les actions commenceront à
partir de janvier 2017 par une phase de tests de compatibilité.
Je participe à l’estimation du budget pour la mise à jour de Windows Seven vers
Windows 10, d’une part pour le coût de réalisation des tests sur l’ensemble des
applications et d’autre part l’implémentation des changements pour les applications non
compatibles. Dans cette estimation nous prenons en compte le type de développement
de l’application : en interne ou par des éditeurs, et certains produits liés, potentiellement
impactant pour la mise à jour.
TRAVAIL DE FIN D’ETUDE
18
JULIE PREVOT
Toutes les applications devront être testées néanmoins nous envisageons des stratégies
afin de réduire le coût des tests. Le crowdsource testing est un mode de test participatif,
les utilisateurs proposent volontairement de réaliser les tests sur les applications qu’ils
utilisent au quotidien. Grâce au retour d’expérience sur la migration vers Internet
Explorer 11 où cette méthode fut déjà mise en place, nous estimons que 10 à 20% des
tests peuvent être ainsi réalisés.
Figure 5: Retour d’expérience sur les tests réalisés pour la migration vers Internet Explorer 11
Des modifications seront apportées uniquement sur les applications non compatibles.
Nous prévoyons par exemple que les applications liées au produit Internet Explorer 11.0
sont des applications web et ne seront pas impactées par la montée en version du
système d’exploitation. Avec d’autres critères pris en compte, l’ensemble des
applications qui peuvent nécessiter une modification représente moins de 300
applications.
Les versions antérieures des systèmes d’exploitation Microsoft ont étés migrés lors du projet
de migration vers Windows Seven qui a eu lieu entre 2011 et 2013. Ainsi nous nous assurons
d’être exhaustif sur la méthode apportée.
L’activité de l’équipe d’obsolescence telle qu’elle est aujourd’hui se contente d’un service
d’accompagnement des SLM* et de faire le relais entre la gouvernance et les SLM* chez IM* sur les
sujets concernant les produits obsolescents. La démarche est passive et ne permet pas d’avoir un
horizon large sur le vieillissement des produits. De plus, plusieurs défauts sont relevés sur la méthode
actuelle : seuls les produits génériques c’est-à-dire impliqués sur de nombreuses applications sont
pris en compte par la gouvernance, l’outil de référence Aspire* n’est pas suffisamment renseigné, les
outils de gestion de l’obsolescence sont méconnus de la part des acteurs des Service Lines*.
TRAVAIL DE FIN D’ETUDE
19
JULIE PREVOT
C. Construction de l’activité future : 3 years RoadMap
Les besoins et les enjeux
Les méthodes proposées aujourd’hui ne sont pas suffisamment proactives pour être
satisfaisantes. En effet, les SLM* souhaitent passer peu de temps sur la gestion de leur
obsolescence, néanmoins c’est un sujet important qui nécessite d’être prévoyant, car la
défaillance d’un produit obsolète peut représenter une perte économique importante. La
méthode que nous construisons doit permettre de réaliser une gestion autonome de
l’obsolescence par la Service Line* avec un horizon de trois ans minimum afin de définir des
priorités et attribuer des budgets plus précis. Il est également nécessaire que la méthode
considère tous les produits liés aux applications de manière exhaustive et de consolider
l’information recueillie et en faire l’historique sur tous les produits de façon transversale à la
Service Line* voir à toutes les Service Lines.
Figure 6: Identification globale des besoins pour la construction de la RoadMap
Du point de vue de CGI, la création d’une nouvelle activité est une opportunité de démontrer
nos compétences, en accompagnant le client vers un service de qualité. En particulier la
construction de la RoadMap illustre notre savoir-faire pour le développement de méthodes
innovantes et notre adaptabilité à des nouveaux besoins. Cette mission participe à la
diversification de l’activité de l’équipe et à sa promotion auprès des internes Airbus.
La mission dispense d’autres avantages pour l’équipe d’obsolescence : une connaissance plus
large des produits, des applications, de leurs fonctionnalités et interactions.
Au-delà des enjeux économiques que peut représenter la gestion de l’obsolescence, la Service
Line Programmes possède des applications sensibles car directement liées à la production Airbus,
elle doit tenir place de modèle. Les attentes sont plus élevées de la part de la gouvernance et les
acteurs de Programmes favorables au développement de méthodes innovantes. C’est pourquoi
la Service Line Programmes est pilote sur cette activité.
TRAVAIL DE FIN D’ETUDE
20
JULIE PREVOT
Activité pilote sur Programmes
Dans un premier temps est réalisé un état des lieux sur le statut des applications à traiter et
répartir la charge de travail en fonction des Application Managers* auxquels adresser le
sujet. Il s’agit de traiter uniquement les applications en service et de vérifier que la version en
cours dans l’outil Aspire* est la version actuellement déployée. De ce premier survol du sujet
résulte 44 applications à traiter et réparties en 5 vagues avec chacune un Application
Manager* capable de nous renseigner sur la vague en question.
Le travail effectué est basé sur les liens application-produit qui sont renseignés dans Aspire*
avec les données d’obsolescence associées. La vue par application sur l’obsolescence de tous
ses produits est nommée « Time Ticket »
Figure 7: Vue simplifiée sur le Time Ticket
A première vue le time ticket est un moyen d’identifier rapidement l’état de l’obsolescence
des produits, mais il présente un inconvénient majeur car les couleurs ne correspondent pas
aux codes définis dans le cycle de vie des produits [Annexe5], alors nous ne sommes pas
capables aujourd’hui d’expliquer la mise en place des couleurs. De cette vue nous prenons en
considération les liens application-produit et la date Airbus End of Standard Support des
produits, qui définit l’obsolescence de ce dernier.
Nous rencontrons chaque Application Manager* deux fois. La première fois, il s’agit de
valider ou corriger les liens application-produit identifiés et éventuellement renseigner des
liens non présents dans Aspire*. C’est également l’occasion de lancer des actions afin de
récolter l’information manquante auprès des Product Owners*. Sur l’ensemble des
domaines, le taux de remplissage Aspire de la date Airbus End of Standard Support est de
52,13% au 1er juillet 2016 [H].
TRAVAIL DE FIN D’ETUDE
21
JULIE PREVOT
Lors de notre deuxième rencontre, nous apportons à l’Application Manager* une vision
globale orientée autour des produits afin de définir des besoins budgétaires pour chaque
produit, connaissant les applications impactées par une migration :
Figure 8: Vue simplifiée de la RoadMap
Enfin les Application Managers* ont tous les éléments en main afin décider la mise en place
réelle d’actions ou de projets pour la gestion de l’obsolescence en fonction des sujets
prioritaires identifiés dans la RoadMap et du budget dont ils disposent.
Pour consolider l’information, il faut que celle-ci transite entre les différentes vagues et la
rendre disponible pour tous les Application Managers*, pour cela nous avons conçu la
RoadMap comme un tableau à plusieurs entrées. La vue proposée en figure 6 est simplifiée
afin de mieux comprendre le point de vue adressé, car le fichier original contient une ligne
par lien application-produit. Ainsi les filtres permettent plusieurs lectures du fichier selon que
l’approche soit orientée par application, par produit, par date ou par acteur.
Le nouvel outil créé répond aux exigences en terme de contenu néanmoins les acteurs de la
Service Line* n’acquièrent pas l’autonomie souhaitée, à ce jour deux éléments sont bloquants
afin de pouvoir atteindre l’objectif final et la mise en place d’une telle méthode au sein même
des Service Lines. En effet, les informations dans Aspire* ne sont pas suffisamment mises à jour
pour construire automatiquement une vision complète et actualisée sur les applications. Le
second point est l’informatisation de l’outil pour se passer du traitement des données effectué
aujourd’hui par l’équipe d’obsolescence.
TRAVAIL DE FIN D’ETUDE
22
JULIE PREVOT
Les résultats de la RoadMap
Le travail réalisé avec la Service Line* Programmes a permis d’adresser les sujets
d’obsolescence sur un ensemble de 44 applications en service, soit 152 produits et 692 liens
application-produit. De la première phase du projet qui consiste à établir un état mis à jour
des liens, résulte l’ajout de 100 liens et la suppression 64 liens dans les données du
référentiel Aspire*.
Figure 9: Synthèse sur les liens dans la RoadMap
Ce n’est pas seulement une charge de travail qui est exposée dans ces chiffres, c’est
également la volonté des acteurs Programmes de disposer d’un référentiel clair et
représentatif qui viendra étayer non seulement la RoadMap budgétaire pour l’obsolescence
mais aussi aider à atteindre des objectifs internes en terme de remplissage du référentiel
Aspire*.
TRAVAIL DE FIN D’ETUDE
23
JULIE PREVOT
Nous avons pu également établir un bilan global sur la situation d’obsolescence de la Service
Line* en terme d’applications et en terme de produits :
Figure 10:Obsolescence globale de la Service Line Programmes
A la lumière de l’analyse que nous pouvons porter à ces chiffres, ils révèlent que peu de
produits sont avérés obsolètes mais que ceux-ci affectent un large pourcentage des
applications. Ainsi l’étude et le remplacement réalisé sur un produit sera un effort important
car affecte beaucoup d’application. L’exemple le plus évident est celui des produits Java, une
étude sera lancée prochainement pour leurs remplacements et la réalisation a tout intérêt à
être faite car 21 applications sont impactées.
L’état d’obsolescence des produits a permis d’identifier des besoins budgétaires, pour des
études prises en charge par le SLM* et pour des migrations de produits par les Applications
Managers*, afin de prendre en compte l’obsolescence actuelle et à venir, en priorisant les
produits et répartissant les budgets entre 2017 et 2019.
La dernière initiative mise en place dans le cadre de la RoadMap est la création d’un fichier
pour la consolidation des informations sur les produits. Pour favoriser la suite du projet et
éviter toute perte d’information, ce fichier contient toutes les informations qui ont été
récoltées par les actions menés dans l’équipe d’obsolescence auprès des Product Owners*,
ainsi que les contacts pour faciliter les recherches en cas de besoin.
TRAVAIL DE FIN D’ETUDE
24
JULIE PREVOT
Les suites de la RoadMap
Le travail réalisé avec la Service Line Programmes arrive à son terme, il faut clôturer les
actions lancées auprès des Product Owners* pour collecter les informations manquantes et
mettre en place une stratégie de communication sur le travail effectué afin de promouvoir la
méthode de gestion de l’obsolescence.
En effet, l’objectif est que la méthode, plus innovante, se démocratise parmi toutes les
Service Lines* IM*. Nous avons d’ores et déjà présenté ces résultats auprès de la Service
Line* Human Ressources (IMSH*) et débutons une introduction afin de définir ensemble une
marche à suivre.
Le traitement des données de la RoadMap représente une charge de travail très importante
et pour être viable, la méthode doit devenir informatisée. La démarche sur l’informatisation
de l’outil est encore peu réfléchie mais représente un pas important dans l’aboutissement de
la mission globale d’IMST*. De plus, l’informatisation de l’outil et l’automatisation du recueil
de données est une condition nécessaire pour obtenir une autonomie sur l’outil de la part
des Service Lines.
TRAVAIL DE FIN D’ETUDE
25
JULIE PREVOT
III. L’audit SLL 2016 L’audit SLL est l’évaluation du service rendu par CGI au travers des SLL* mandatés au niveau des
Service Lines*. Cette évaluation s’appuie sur le catalogue des services ISOM*, c’est pourquoi il est
nécessaire de comprendre en quoi consiste l’activité du SLL* relativement au catalogue afin de
mener à bien l’audit et savoir analyser ses résultats.
A. L’activité du SLL et le référentiel ISOM Le rôle du SLL* est de seconder un SLM* dans ses activités quotidiennes, ainsi chacun des SLL*
ont des missions différentes en fonction des services qui sont demandés par leur SLM*. Ces
services sont commandés dans le catalogue ISOM*, c’est donc le repère commun des activités de
tous les SLL*. Conjointement, ils assurent le bon fonctionnement et la disponibilité de quelques
applications, de 10 à 50 applications selon la Service Line* et la criticité des applications.
Le référentiel est utilisé comme guide pour les activités des Service Lines* et comme catalogue
de service, et concrètement qu’est-ce que c’est ? L’ISOM* est un ensemble de bonnes pratiques
formalisées sous forme de processus. Il se décompose en cinq parties principales, et l’ensemble
décrit toutes les étapes de la gestion de service. Ce recueil, en annexe 2, fût créé par Airbus et
est largement inspiré d’ITIL qui est le référentiel le plus reconnu dans le monde pour la gestion
de systèmes d’information. Une partie de l’ITIL Basics est disponible en annexe 6.
Le cœur du métier des SLM* et des SLL* est la partie « Service Support » de l’ISOM*, il consiste à
traiter les tickets des utilisateurs, les tickets, en fonction de leur catégorie et leur nombre, seront
traités en tant que requêtes, incidents, problèmes ou crises. Le prix de résolution d’un ticket
varie selon le niveau attribué alors quatre objectifs principaux sont définis pour réduire le coût
total :
- Améliorer l’arbre de décision pour l’ouverture de problème et de crise
- Réduire le « misrouting » c’est-à-dire les erreurs d’aiguillage des tickets
- Prendre des actions de « backlog » pour que les tickets puissent redescendre à un niveau
inférieur quand c’est possible
- Réduire le nombre global d’ouverture de tickets
Les autres parties du référentiel ISOM* viennent supporter cette activité principale mais n’en
sont pas moins nécessaires pour assurer la continuité du service. Ce constat est à nuancer car
chaque Service Line* fonctionne différemment et possède des contraintes propres à ses activités
donc certains processus proposés par le référentiel ne sont pas ou ne peuvent pas être
implémentés.
TRAVAIL DE FIN D’ETUDE
26
JULIE PREVOT
B. Les problématiques d’un audit CGI s’engage auprès d’Airbus a réalisé des actions d’amélioration continue dans son service.
Parmi les différentes actions menées au niveau du bundle, un audit est réalisé chaque année
depuis sa création, soit le troisième audit réalisé. L’audit des ISPL* est basé sur le référentiel GPP
NG* et est réalisé en parallèle de l’audit des SLL*. En effet, ils seront présentés conjointement
aux clients.
Pour Airbus, la réalisation d’un audit est une manière efficace de vérifier que le contrat est
rempli. Le client s’assure que le service commandé est fait et de quelle manière avec la
certification que la qualité du service ne se dégrade pas et que la motivation et les efforts sont
présents de la part des SLL* pour mener l’activité de la Service Line vers le haut avec le soutien
de la hiérarchie chez CGI.
Du point de vue de CGI, l’audit est important pour faire un point santé sur la qualité du service
rendu. Les enjeux sont doubles. Il s’agit d’une part de défendre les intérêts des SLL*, soit auprès
du client en montrant que le service est délivré, soit en identifiant des difficultés et en apportant
des solutions préventives ou curatives. D’autre part de distinguer les points d’améliorations
possibles et encourager les initiatives des SLL* pour la standardisation de l’activité.
Aujourd’hui la standardisation et l’industrialisation des activités de management des applications
vers le référentiel ISOM* est un gage de maturité et de qualité du service. Cette stratégie
favorise l’intégration Airbus-Airbus Group. Enfin, bien que l’audit soit adressé aux SLL*, on ne
peut juger le travail de celui-ci d’autant plus qu’il dépend entièrement du mode de
fonctionnement définit dans la Service Line* c’est donc la maturité des processus mis en place au
sein de la Service Line* qui est mesuré.
Le dernier objectif de l’audit est aussi de remettre en cause le référentiel à la lumière de l’analyse
des résultats qui reflètent la réalité du terrain. Il est nécessaire que l’ISOM* ne soit pas
seulement un idéal mais un recueil capable de guider l’activité dans ses problématiques
quotidiennes. C’est seulement à cette condition que le référentiel ISOM deviendra un objectif
Aircraft on Ground AOG caractérise un incident ou problème qui a pour conséquence de bloquer un ou plusieurs avions au sol, ça résolution devient alors une priorité absolue qui prévaut sur toute autre activité
Application Manager
L’Application Manager est un acteur des Service Lines, il est responsable technique d’un petit nombre d’applications, il a par exemple pour responsabilité la gestion des licences, de capacité et performance des plateformes, des serveurs et bases de données
Aspire Aspire est un outil Airbus dans lequel sont référencés des informations sur les applications et les produits. On y trouve les contacts et personnes responsables des différentes entités, les liens entre les applications et les produits ou des dates d’obsolescence par exemple
Bundle Regroupement en français dans le texte, le bundle représente un ensemble de services groupés dans un même catalogue. Le terme bundle est employé pour désigner l’entité qui comprend les employés et les services, associés les uns aux autres
GPP NG Global Project Process New Generation – Le référentiel GPP NG comprend des processus macroscopiques qui viennent décrire comment fonctionnent les projets de développement des applications Airbus, voir Annexe 1
IM I pour ICT, la direction des systèmes d’information et M pour Management, Enable, Common Application
ISOM IT Service Operating Model – Le référentiel ISOM comprend des processus pour la gestion des applications en service chez Airbus. Le référentiel fait également office de catalogue pour commander les services d’un SLL*, voir annexe 2. Il est divisé en cinq parties qui sont appelées des clusters.
ISPL Information System Project Leader
ITS Est le nom du bundle où j’évolue, chaque lettre correspond à un type de service propose dans le catalogue: I pour ISPL, T pour Testing, S pour SLL
Product Owner Product Owner est un statut et non une fonction. Ce statut est attribué à une personne interne Airbus de préférence ou chez un sous-traitant, la mieux placée possible pour pouvoir donner des renseignements sur le produit en question. Il est aussi en charge de renseigner les informations relatives au produit dans le référentiel Aspire
Service Line Une Service Line est une entité appartenant à un domaine (4 lettres dans l’organisation) qui est rattachée à un sous-ensemble d’application. Ainsi l’entité de Service Line peut désigner les applications ou l’ensemble des personnes, internes et externes à Airbus, qui s’emploient au bon fonctionnement des applications
SLL Service Line Leader – Les Service Line Leaders sont mandatés par les Service Line Managers pour les aider dans leurs activités quotidiennes : la gestion d’un ensemble d’applications en service
SLM Service Line Manager – Les Service Line Managers sont les responsables Airbus sur la gestion d’un ensemble d’application en service, ils doivent assurer le bon fonctionnement et la disponibilité de leurs applications
SMART On dit d’un objectif qu’il est SMART lorsqu’il est « Specific » dépendant d’une action clairement établie, « Measurable » mesurable par des indicateurs chiffrés et objectifs, non contestables, « Acceptable » réalisable par le biais unique de la motivation du collaborateur, « Relevant » pertinent par rapport à l’activité, et « Time-bound » inscrit dans le temps
Taux de conformité absolu
Est le nombre de question de l’ISOM sur lesquelles la Service Line estime être en conformité avec le référentiel ISOM sur le nombre total de question
Taux de conformité relatif
Est le nombre de question de l’ISOM sur lesquelles la Service Line estime être en conformité avec le référentiel ISOM sur le nombre de question « applicable » aux activités de la Service Line
TRAVAIL DE FIN D’ETUDE
40
JULIE PREVOT
Table des illustrations
Figure 1: L'initiative de la RoadMap d'obsolescence dans le contexte de la roue de Deming ............. 12
Figure 2: L'audit SLL dans le contexte de la roue de Deming ................................................................ 13
Figure 3: Fenêtre Aspire, Obsolescence view Windows server 2003 product ...................................... 15
Figure 4: Suivi du décommissionnement des serveurs Windows 2003 ................................................ 16
Figure 5: Number of application tested for Internet Explorer 11 Migration ........................................ 18
Figure 6: Identification globale des besoins pour la construction de la RoadMap ............................... 19
Figure 7: Vue simplifiée sur le Time Ticket ............................................................................................ 20
Figure 8: Vue simplifiée de la RoadMap ................................................................................................ 21
Figure 9: Synthèse des données de la RoadMap ................................................................................... 22
Figure 10:Obsolescence globale de la Service Line Programmes ......................................................... 23
Figure 11: Choix de réponse pour l'audit .............................................................................................. 28
Figure 12: Synthèse sur la campagne d’interview ................................................................................. 29
Figure 13: Synthèse sur la campagne de l'audit .................................................................................... 30
Figure 14: taux de conformité absolu sur les questions jugées prioritaires en 2016 ........................... 32
TRAVAIL DE FIN D’ETUDE
41
JULIE PREVOT
Annexes Annexe 1: GPP NG - Generic Project Process New Generation
TRAVAIL DE FIN D’ETUDE
42
JULIE PREVOT
Annexe 2: ISOM Referential - IT Service Operating Model