TRAVAIL DE FIN D’ETUDEjprevot/Documents/...nouvelle méthode de gestion de l’obsolescence et ui...

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é


1

JULIE PREVOT

Remerciements

Tout d’abord, je souhaiterais remercier Jean-Pascal Depetris, responsable du bundle* ITS* et

Delphine Hanser, ma tutrice et manager pour m’avoir accueilli au sein de leur équipe et pour m’avoir

fait confiance pour mener à bien mes missions.

J’adresse également un grand merci aux quatre membres de l’équipe d’obsolescence qui m’ont

considéré comme l’un des leurs durant ce stage de six mois, pour avoir partagé leurs connaissances

et leurs expériences et pour m’avoir soutenu dans la prise de compétences et de responsabilités sur

tous les sujets et problématiques qui sont les leurs.

Je remercie Céline Perfetti et Philippe Delaye qui ont été respectivement ma marraine et mon

parrain durant ce stage, qui m’ont intégré dans l’équipe du bundle* ITS*.

Un merci tout particulier à Chloé Gomes qui a participé avec moi au projet de construction de la

nouvelle méthode de gestion de l’obsolescence et qui m’a confié l’intégralité de son activité pendant

ses congés d’été.

Enfin, merci à toutes les personnes que j’ai rencontré dans le cadre de mon stage, au sein du bundle

ou chez Airbus pour l’aide qu’ils m’ont apportée dans mes différentes missions.


2

JULIE PREVOT

Sommaire

Remerciements ....................................................................................................................................... 1

Sommaire ................................................................................................................................................ 2

Résumé .................................................................................................................................................... 3

Abstract ................................................................................................................................................... 4

Introduction ............................................................................................................................................. 5

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

Bibliographie.......................................................................................................................................... 37

Glossaire ................................................................................................................................................ 38

Table des illustrations ............................................................................................................................ 40

Annexes ................................................................................................................................................. 41


3

JULIE PREVOT

Résumé

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.


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.


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.


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.


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.


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*.


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.


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.


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.


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.


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.


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.


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


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.


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.


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*.


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é.


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].


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.


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*.


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.


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.


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.


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

SMART* (Specific, Measurable, Acceptable, Relevant, Time-bound).

Mon rôle est de prendre en charge l’intégralité de l’audit depuis de retravail de la grille d’audition,

jusqu’à l’analyse des résultats et l’établissement de plans d’action personnalisés par Service Line*.

J’essaie au travers de cette mission de m’inscrire au maximum dans les principes d’amélioration

continue afin d’ajouter une plus-value dans l’analyse des résultats et être force de propositions

innovantes dans le plan d’action délivrés aux Service Lines* auditées.


27

JULIE PREVOT

C. Mise en place de l’audit Avant toute chose, l’ISOM* est un outil spécifique adapté à la complexité de l’organisation

Airbus. Il nécessite d’être appréhender par des formations. Afin de pouvoir mener à bien l’audit

de bout en bout, il faut comprendre l’application des processus dans le contexte de l’activité

globale de gestion des applications et adaptés aux différentes activités de chaque Service Line*.

De plus, il est nécessaire de se familiariser avec le vocabulaire définit par le référentiel qui est

adopté seulement en parti sur le terrain.

La grille d’audit

L’audit est un outil pour l’amélioration continue, mais pour être réellement efficace il doit lui

aussi se soumettre à l’évolution, l’examen des audits précédents permettent de le rendre de

plus en plus significatif dans sa mesure de la standardisation. Cette année, deux axes sont

développés.

L’analyse de l’audit de l’année précédente a révélé un taux de conformité relatif* moyen de

81%, en a été déduit une bonne maturité globale des Service Lines* et des possibilités

d’améliorations plus restreintes. D’où la nécessité d’établir une mesure plus détaillée de la

conformité. Nous décidons alors de travailler la grille d’audit sur les parties Incident

Management et Problem Management car elles représentent le cœur du métier des SLM* et

SLL*.

L’évolution du questionnaire doit répondre à des besoins de continuité dans l’analyse de

l’historique des résultats par rapport aux deux années précédentes. Afin de ne pas

déstructurer l’audit j’ai décidé de ne pas modifier les questions existantes et d’ajouter des

sous-questions qui viendront agrémenter les parties de l’Incident Management et du

Problem Management. Pour créer les questions j’ai fait appel à deux experts qui ont

contribué chacun dans leur domaine à la construction de processus. Ainsi ils ont chacun

apporté leurs connaissances pour identifier les points importants qui peuvent être

significatifs de la maturité du service. Il en résulte un total de 17 sous-questions crées.

Le second axe d’amélioration est identifié par une demande des SLL* qui souhaitent la

création de bonnes pratiques sur les réunions. Pour chacune des réunions aillant lieux dans

les Service Lines*, nous souhaitons distinguer la fréquence, la liste des invités, les supports

utilisés dans la réunion et les sujets traités de façon récurrente. Alors une grille séparée est

créée pour réaliser une interview sur chaque Service Line* et un total de 50 questions sont

soumises pour chaque réunion. La grille de l’audit global évolue pour ne pas être redondant

avec l’interview réalisée sur les réunions.


28

JULIE PREVOT

Au-delà des questions qui sont soumises aux personnes qui sont audités, il faut aussi se

pencher sur les réponses qui leurs sont apportées et le crédit qui peut leur être donné. En

effet, les questions posées ne sont pas chiffrées et leurs réponses peuvent donc être

subjectives. L’audit reflète alors la maturité de la Service Line* du point de vue du SLL*.

Malgré ce constat, nous proposons des réponses suivantes, qui se veulent le plus objectif

possible.

Figure 11: Choix de réponse pour l'audit

Ainsi chaque année, l’activité d’audit de remet en question elle-même pour s’inscrire dans les

principes de l’amélioration et augmenter son efficience. Il vient surtout appuyer la réponse aux

besoins de perfectionnement des équipes du bundle. La grille d’audit est disponible en annexe 7

et l’interview sur les réunions en annexe 8.


29

JULIE PREVOT

Rencontre des SLL

L’ensemble de l’audit est divisé en deux parties, comme expliqué ci-dessus, l’audit global

pour mesurer la standardisation du service et l’interview sur les réunions. Les campagnes

d’interview et d’audit sont réalisées en décalé pour répartir la charge de travail et assurer

mes autres activités en parallèle. J’invite les SLL* dans un premier temps à participer à

l’interview sur les réunions. Ces derniers sont libres d’inviter à leur tour leur SLM* si ils le

souhaitent, pour leur faire partager les initiatives d’amélioration continue menées par CGI et

de donner un point de vue différent sur la maturité de la Service Line*.

Cette première étape pour l’audit est prévue sur une heure, après une remise en contexte et

la présentation de la grille, les participants sont invités à identifier l’ensemble des réunions

qui sont en lien avec les activités de la Service Line*. Neuf réunions recommandées par le

référentiel ISOM* sont préinscrites pour guider l’interview. Ils renseignent ensuite

l’ensemble des informations demandées pour chacune des réunions identifiées.

Figure 12: Synthèse sur la campagne d’interview

C’est un total de 21 interviews que j’ai mené auprès des SLL* et quelques SLM*. Une

attention particulière est donnée sur les réunions qui ont été créés par les acteurs d’une

Service Line* eux-mêmes et non reconnues par l’ISOM car ils résultent de besoins liés à

l’activité. Ils peuvent faire l’objet de bonnes pratiques et répondre aux mêmes besoins

encore insatisfaits dans d’autres Service Lines*.


30

JULIE PREVOT

La seconde étape est l’audit global, il se déroule en moyenne sur une heure, et comme pour

l’interview, les SLM* sont libres de participer. Après avoir présenté la grille et les règles qui la

régissent, les questions sont successivement adressées. Elles sont directement orientées sur

la mise en place des processus et l’utilisation des outils recommandés par le référentiel.

Chaque question invite les participants à s’interroger sur les responsabilités mises en jeu

dans les processus ISOM*.

Cette réflexion doit mener les SLL* à identifier des points d’amélioration. Ils s’engagent

moralement à les mettre en place pour élever la qualité du service. C’est un résultat à court

terme qui a son importance car il implique les SLL* dans la démarche de l’amélioration

continue et rehausse l’image de l’audit. En effet, un audit donne une impression négative

comme un outil d’autorité et de jugement sur le travail personnel. Ce dernier est mené de

façon à se détacher de sa mauvaise image, en adressant les questions au niveau de la

globalité de la Service Line*, en invitant les SLL* à donner leur point de vue sur la maturité du

service et à participer à la démarche d’amélioration continue.

Figure 13: Synthèse sur la campagne de l'audit

La réalisation de l’audit et la rencontre des SLL* est aussi l’occasion de prêter attention aux

questions bloquantes, imprécises ou qui peuvent créer une confusion dans l’objectif

d’améliorer la prochaine grille d’audit.


31

JULIE PREVOT

Résultats et analyse

Les interviews sur les réunions

Les résultats globaux sur la campagne d’interview sont consultables en annexe 9, on y

observe le taux de réalisation des réunions référencées dans l’ISOM*. Ce taux nous informe

de l’importance accordée par les Service Lines* à chacune des réunions, ces données

peuvent être utilisées à l’ouverture d’une nouvelle Service Line* et leur indiquer quelles

réunions sont à mettre en place en priorité pour atteindre rapidement un niveau de service

correct. Néanmoins les résultats sont à modérer en fonction des réunions car les SLL* ne

participent pas à chacune d’entre elles et n’ont pas toujours connaissance des activités

menées chez le client. C’est le cas des réunions stratégiques qui ont lieu au niveau du

domaine et donc concerne plusieurs Service Lines*.

Le second graphe en annexe 9 indique le taux de respect du référentiel selon les critères de

la grille d’interview sur l’ensemble des Service Lines* qui réalisent la réunion. Pour établir un

taux de respect, un poids équivalent est donné à chacune des parties de la grille : fréquence,

liste des invités, les supports et les sujets récurrents abordés. Ainsi les SLL* peuvent

comparer leurs actions avec les bonnes pratiques préconisées par le référentiel en terme de

réunions, demander des conseils aux autres SLL* ou savoir comment mettre en place une

réunion dans une Service Line*. Ces données sont également à relativiser, en effet le respect

du référentiel n’est pas un gage de maturité en terme de réunion, car les activités les plus

matures se détachent du référentiel pour adapter les réunions à leurs activités à la lumière

de leur expérience.

L’analyse des données recueillies est un sujet délicat, il est nécessaire de se poser les bonnes

questions pour comprendre le contexte de la réunion et le contexte de la Service Line*. Ainsi

dix bonnes pratiques ont été créées, une globale pour prioriser les réunions à mettre place et

une concernant chaque réunion indiquant comment mettre en place la réunion de façon

réaliste et efficace.


32

JULIE PREVOT

L’audit global

Quant à l’audit, il a permis de réalisé une photo sur l’état actuel de la maturité des 23

Services Lines* auditées. Le résultat global par cluster [Annexe 10] donne une vision

d’ensemble du niveau de maturité sur l’ensemble des Service Lines*. C’est une élévation de

22% qui est observée entre 2015 et 2016 sur l’ensemble des clusters. Cette nette

amélioration est en partie due à une priorité qui fût levée l’an passé, considérant que le taux

de conformité absolu* du Service Maintenance de 26% était insuffisant. La décision a porté

ses fruits car ce chiffre atteint 82% cette année.

Les priorités cette année, sont mises sur les questions dont le taux de conformité est en

dessous de 50%, cette stratégie permet de définir trois points :

Figure 14: taux de conformité absolu sur les questions jugées prioritaires en 2016

Ces priorités lorsqu’elles ne sont pas respectées viennent s’ajouter aux points

d’améliorations identifiés par les SLL* eux-mêmes durant l’audit, l’ensemble vient compléter

un plan d’action et définit les objectifs d’amélioration continue d’une Service Line*.

Un plan d’action est spécifique à chaque Service Line*, c’est un retour sur les résultats et

l’analyse de l’audit vers les SLL* et propose une vue d’ensemble sur le passé, le présent et le

future. Il fait d’abord un état global sur l’ensemble du questionnaire sur l’historique

disponible de la Service Line*, ensuite un point sur les taux de conformités par cluster ISOM*

en 2016, enfin une synthèse des points d’améliorations identifiés ci-dessus.

Les résultats sur l’ensemble de l’audit, autant sur la partie interview sur les réunions que l’audit

global, seront présenté à la rentrée en septembre auprès des clients, conjointement avec l’audit

ISPL*, à l’occasion d’une réunion de comité de direction.


33

JULIE PREVOT

Les suites de l’audit SLL

Il est certain que l’audit va persister l’an prochain et encore pour une durée indéterminée. Les

améliorations qui seront apportées l’an prochain ne sont pas encore déterminé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é que le taux de conformité au référentiel croit d’année en année, il est nécessaire

d’augmenter la finesse de la mesure afin de pouvoir encore identifier des pistes d’améliorations,

bien qu’un processus soit globalement jugé bien mis en place sur la Service Line*. L’initiative

nous a permis cette année de qualifier le besoin de mettre en place des d’indicateurs de

performance plus précis sur le Problem Management et l’Incident Management comme priorité

d’amélioration. Cet approfondissement dans la mesure de la conformité 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*.


34

JULIE PREVOT

IV. Conclusion La gestion de l'obsolescence est un combat interminable dans lequel toutes les entreprises se

sont aujourd'hui lancées afin de rester compétitives : adapter ses solutions, proposer des

innovations et un service de qualité sont des objectifs qui ne peuvent être atteint sans

renouveler constamment ses logiciels et son hardware. L’obsolescence est un problème

perpétuel et qui ne peut être évité, il faut donc mettre en place des mesures pour gérer cette

problématique.

L'industrialisation des processus semble donc pouvoir permettre de gagner en efficacité et en

efficience pour répondre à ces attentes. Il existe déjà de nombreuses normes (ISOM*, ITIL*) qui

donnent un premier cadre afin de rationaliser ses activités. Le but étant de construire une

méthode pour pouvoir rassembler des informations auprès d'un réseau complexes

d'interlocuteurs et d'organiser ces données pour en construire des business cases qui aideront

ensuite à la prise de décision et permettront d'anticiper les risques.

Par ailleurs, la standardisation permet de faciliter les transferts de connaissance, d'optimiser

l'efficacité des processus et d'abaisser les coûts en externalisant certains services

(développements techniques, support...). Cela représente un enjeu majeur pour les sociétés de

services aujourd'hui qui doivent faire face aux exigences de leurs clients en termes de tarifs,

délais et qualité. Celles-ci essayent donc par tous les moyens d'améliorer leurs processus car elles

ne peuvent pas réellement compter sur une innovation technologique comme les autres

entreprises industrielles. Elles travaillent donc directement avec les acteurs concernés pour

proposer des bonnes pratiques et des évolutions aux systèmes existants chez leur clients.

Toutefois, cette industrialisation des processus ne constitue en aucun cas une solution miracle à

long terme pour créer de la valeur. En effet, il est impossible par essence de continuer à toujours

standardiser toutes les activités en espérant d'un autre côté de la créativité de la part des

collaborateurs et un certain sens de l'innovation. L'externalisation d'une partie des services a

d'ailleurs montré une partie de ses limites notamment à cause de la maturité des sociétés sous-

traitantes mais aussi à cause de l'évolution des salaires qui rendra cette pratique moins rentable

dans les années à venir. Il est donc nécessaire pour chaque entreprise, voire pour chacun d'entre

nous, de voir à partir de quel niveau il est préférable de rationaliser une activité.


35

JULIE PREVOT

Bilan personnel

Le stage de fin d’étude est un premier pas dans le monde professionnel, j’attendais de celui-ci de

pouvoir faire mes preuves au quotidien en tant qu’ingénieur dans la gestion de projet, apprendre de

l’expérience des personnes qui m’accompagne dans mes missions et de découvrir le rôle de CGI en

tant que société de service pour une multinationale.

L’environnement professionnel

L’équipe d’obsolescence a eu à cœur de m’intégrer comme un membre à part entier de

l’équipe et a su me transmettre les problématiques fondements de l’activité d’obsolescence.

Au sein de l’équipe ou au sein du bundle, j’ai pu apprendre à connaitre et à travailler avec

des personnes de formations et d’origines différentes.

J’ai pu découvrir le fonctionnement d’une société de service internationale notamment au

travers de la relation SLL*-SLM* ainsi que le rôle du consultant en participant aux activités

quotidiennes de l’équipe d’obsolescence pour IMST*. En effet, grâce à mes deux missions j’ai

pu évoluer au sein de deux environnements différents.

- D’une part, la réalisation de l’audit interne me permet d’obtenir au sein de

l’organisation de notre client Airbus une vision transversale précieuse et

enrichissante par l’expérience et la compréhension de l’environnement que cette

vision offre. Chaque SLL* m’a impliqué le temps d’une interview dans son

environnement et ses activités.

- D’autre part, l’initiative d’une RoadMap budgétaire pour la gestion de

l’obsolescence me permet d’avoir une vue d’ensemble verticale sur les rôles et

interactions des acteurs au sein de la Service Line* Programmes. Prendre contact

avec chacun d’entre eux m’a permis de toucher du doigt les contraintes relatives

à chaque fonction et qui construisent à leur niveau la complexité d’Airbus.


36

JULIE PREVOT

Les compétences, savoir-faire et savoir-être

D’un point de vue personnel, ce stage m’a permis d’apprendre à adopter une posture et une

communication adéquate, cela passe par exemple par l’organisation des réunions avec des

cadres d’Airbus. Cela implique dans un premier temps d’établir le contact (téléphone ou

courriel), de préparer dans un second temps la réunion avec un document Powerpoint

généralement. Il faut ensuite être capable d’animer et de diriger la réunion tout en prenant

des notes afin d’envoyer un compte-rendu rédigé en anglais à la fin des réunions. De plus, ce

stage m’a aussi permis d’améliorer mon niveau d’anglais oral pendant les différentes

réunions ainsi qu’écrit avec la rédaction de nombreux documents qui se faisait exclusivement

en anglais. De plus, j’ai pu bénéficier de formations au sein de l’entreprise (ISOM, posture du

consultant…) pour pouvoir mieux comprendre le métier de SLL* et la place du consultant.

Enfin, j’ai pu approfondir mes connaissances dans le domaine de l’informatique grâce à toute

l’équipe qui a su m’aider quand j’en avais besoin.

Le projet professionnel

J’ai intégrée l’entreprise CGI dans l’objectif de pouvoir acquérir de l’expérience dans la

gestion de projet informatique. La mission que j’ai menée ici me conforte dans ce projet

professionnel. Prendre place dans la gestion de projet ca au-delà de la construction d’un

livrable et de la satisfaction de son achèvement, il nécessite de comprendre la complexité

d’un environnement, la communication et la collaboration de tous les acteurs.


37

JULIE PREVOT

Bibliographie

[A]Wikipédia, Groupe CGI (consulté le11 aout 2016), lien : https://fr.wikipedia.org/wiki/Groupe_CGI

[B]Forbes, Forbes Europe, (colsulté le 4 juillet 2016), lien : http://www.forbes.com/forbes/welcome/

[C]Dynamique-Mag, C’est entreprises qui ont bien su gérer les attentats (consulté le 21 juin 2016),

lien : http://www.dynamique-mag.com/article/entreprises-bien-su-gerer-attentats.8239

[D] CFE CGC Le + syndical, CGI change de modèle (consulté le 8 août 2016), lien: http://www.fieci-

cgc.org/cgi/images/stories/dossiers/metro_market_model.pdf

[E]Wikipédia, Airbus (cunsulté le 3 juin 2016), lien : https://fr.wikipedia.org/wiki/Airbus

[F] Airbus Conquering the skies, Airbus, 25 juin 2016 (lien web: http://www.airbus.com/fr/dossiers-

de-presse-commandes-livraisons/?eID=maglisting_push&tx_maglisting_pi1%5BdocID%5D=108921)

[G]Le monde : entreprises, Airbus enregistre 129 commandes fermes au Salon de l’aéronautique de

Farnborough (consulté le 13 juillet 2016), lien:

http://www.lemonde.fr/entreprises/article/2016/07/12/airbus-enregistre-129-commandes-fermes-

au-salon-de-l-aeronautique-de-farnborough_4968496_1656994.html

[H] Aspire Product update follow-up – 01 juillet 2016, IG, juillet 2016, Aspire Products KPIs report

(2).pdf

https://fr.wikipedia.org/wiki/Groupe_CGI

http://www.forbes.com/forbes/welcome/

http://www.dynamique-mag.com/article/entreprises-bien-su-gerer-attentats.8239

http://www.fieci-cgc.org/cgi/images/stories/dossiers/metro_market_model.pdf

http://www.fieci-cgc.org/cgi/images/stories/dossiers/metro_market_model.pdf

https://fr.wikipedia.org/wiki/Airbus

http://www.airbus.com/fr/dossiers-de-presse-commandes-livraisons/?eID=maglisting_push&tx_maglisting_pi1%5BdocID%5D=108921

http://www.airbus.com/fr/dossiers-de-presse-commandes-livraisons/?eID=maglisting_push&tx_maglisting_pi1%5BdocID%5D=108921

http://www.lemonde.fr/entreprises/article/2016/07/12/airbus-enregistre-129-commandes-fermes-au-salon-de-l-aeronautique-de-farnborough_4968496_1656994.html

http://www.lemonde.fr/entreprises/article/2016/07/12/airbus-enregistre-129-commandes-fermes-au-salon-de-l-aeronautique-de-farnborough_4968496_1656994.html


38

JULIE PREVOT

Glossaire

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

IMH ICT / Management, Enable, Common Application / Humain Ressources & Programmes Solutions

IMS ICT / Management, Enable, Common Application / Application Services

IMSA ICT / Management, Enable, Common Application / Application Services / Architecture

IMSC ICT / Management, Enable, Common Application / Application Services / Common Solutions

IMSF ICT / Management, Enable, Common Application / Application Services / Finances Solutions

IMSG ICT / Management, Enable, Common Application / Application Services / Corporate Functions & General Procurements Solutions

IMSH ICT / Management, Enable, Common Application / Application Services / Humain Ressources & Programmes Solutions


39

JULIE PREVOT

IMST ICT / Management, Enable, Common Application / Application Services / Transversal Activities

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


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


41

JULIE PREVOT

Annexes Annexe 1: GPP NG - Generic Project Process New Generation


42

JULIE PREVOT

Annexe 2: ISOM Referential - IT Service Operating Model

CFT2013-735 IM-SLL-IT Services-Operating-Model-Poster.pdf

Visuel:

CFT2013-735%20IM-SLL-IT%20Services-Operating-Model-Poster.pdf


43

JULIE PREVOT

Annexe 3 : Organigramme de la Direction des Systèmes d’information Airbus, orienté

sur le domaine IMS

q

ICT: Direction des Systèmes d’Information

IL ICT /

Procurements

IN ICT / Services &

common solutions

IC ICT / Customer & Communication

IM ICT/Management, Enable, Common

Solutions

IG ICT / Governance

Run Mode Project Mode

IMF ICT/Management

/ Finances Solutions

IMG ICT/Management

/ Corporate Functions &

General Procurements

Solutions

IMH ICT/Management

/ Humain Ressources & Programmes

Solutions

IMC ICT/Management

/ Common Solutions

IMS ICT/Management

/ Application Services

IMA ICT / Management / Architecture & Transversal Activities

IMSC

IMSH

IMSG

IMSF

IMST

IMSA

SAP COE


44

JULIE PREVOT

Annexe 3 bis : Organigramme détaillé IMS


45

JULIE PREVOT

Annexe 4 : La roue de Deming


46

JULIE PREVOT

Annexe 5 : Cycle de vie des produits selon le référentiel Aspire


47

JULIE PREVOT

Annexe 6: ITIL Quick Reference Card Abstract


48

JULIE PREVOT

Annexe 7 : Grille de l’audit SLL 2016


49

JULIE PREVOT

Annexe 8 : Interview sur les réunions


50

JULIE PREVOT

Annexe 9 : Résultats globaux des interviews

Taux de réalisation des réunions sur l’ensemble des Service Lines

Taux de respect des critères de l’interview par rapport au référentiel ISOM

sur l’ensemble des Service Lines qui réalisent la réunion


51

JULIE PREVOT

Annexe 10 : Résultats par cluster ISOM de l’audit

Taux de conformité absolu par cluster ISOM sur l’ensemble des Service Lines

TRAVAIL DE FIN D’ETUDEjprevot/Documents/...nouvelle méthode de gestion de l’obsolescence et ui...

Documents

Transcript of TRAVAIL DE FIN D’ETUDEjprevot/Documents/...nouvelle méthode de gestion de l’obsolescence et ui...