Download - Représentations systémiques d’une organisation opérationnelle en s’appuyant sur la méthode graphique OSSAD (Full)

Management des Systèmes d'Information Répartis PROMOTION 2004/2006

THÈSE PROFESSIONNELLE

Représentations systémiques

d’une organisation opérationnelle (service d’étude informatique)

en s’appuyant sur la méthode graphique OSSAD

Jean-Pascal Perrein – décembre 2006

Thèse MSIR 2004-2006 Jean-Pascal Perrein Représentation systémique d’une organisation

10/04/2007 MSIR2004-2006 - Thèse JPP - V3,81.doc /158

Mots clefs

Organisation, vue, méthode, France-Telecom, CRISTAL, AGATHONE, incidents, proces-

sus, ISO9000 - 2000, procédure, OSSAD, six sigma, pareto, systémique, pensée complexe,

manager, Merise, QQOQCCP, Diagramme de cause à effet



Remerciements

« Je suis en proie à une étrange sensation.

Si ce n'est pas une indigestion, ça doit être de la gratitude ! » Benjamin Disraeli1.

Cette étude était riche mais difficile, mais avoir été accompagné jusqu’au bout de mes ré-flexion est une grande satisfaction et une grande gratitude que j’adresse à celles et ceux qui ont fait ce bout de chemin avec moi. Maria, Daniel, Théodore et Archimède merci pour votre présence, vos appuis, votre patience et votre aide Aussi j’adresse mes remerciements pour les bons conseils de Guillaume Balan ainsi qu’à Monsieur Dominique Briolat pour sa rigoureuse patience et inébranlable neutralité dans le suivi de cette étude. Je remercie de même Florent pour ses critiques très stimulantes. Enfin je tiens à remercier la société C - LOG International qui m’a offert gracieusement l’usage de son logiciel OSSAD PROCESS DESIGN ainsi qu’une formation appropriée. L’ensemble des schémas OSSAD a été réalisé avec ce logiciel.

A toutes et tous « Un seul mot, usé, mais qui brille comme une vieille pièce de monnaie : merci ! »

Pablo Neruda2

1 Benjamin Disraeli a été le premier ministre de la Reine Victoria du Royaume Uni en 1868 (Né à Londres le 21 décembre 1804, décédé le 19 avril 1881) 2 Neftali Ricardo Reyes Basoalto est un poète Chilien (Né à Paral (Chili) le 12 juillet 1904, décédé le 23 septembre 1973) – Prix Nobel de littérature en 1971



Résumé Il peut être judicieux pour un responsable opérationnel de s’enrichir avec une ré-flexion et une approche qui soit fondé sur des représentations différentes de son or-ganisation.

Celle que son entité lui demande d’appliquer : L’organisation théorique, Celle que lui et son équipe vivent : Une des organisations existantes, Celle qu’il serait nécessaire de mettre en place : L’organisation souhaitée.

Pour représenter et échanger sur ces organisations, il est possible d’utiliser une mé-thode graphique appelé OSSAD (Office Support Systems Analysis and Design). Cette méthode est fondée sur un principe de réflexion systémique, c'est-à-dire qui considère la référence à étudier comme étant un système : un ensemble délimité d’éléments qui interagissent entre eux. A travers l’exemple d’un service d’étude informatique travaillant sur une applica-tion métier de France Telecom, cette thèse aborde une réflexion en deux grandes parties :

la situation : qui est la délimitation de tous les éléments permettant d’appréhender au mieux l’étude. Ce sont les ressources de l’étude. la réalisation : qui est la construction, l’analyse et la comparaison des 3 organisations.

La comparaison finale de trois vue différentes d’une même organisation fait ressor-tir des incohérences de définition de rôles et des fonctionnements trop exactes qui occultent un certain nombre d’information susceptibles d’apporter de fortes amélio-rations.



Introduction

Nous vivons dans un monde d’organisation, personnelle, sociale, industrielle, informatique, biologique, …. Néanmoins, lorsqu’on parle d’organisation au niveau d’une entité juridique, nous avons souvent sous les yeux une macro - organisation, au plus simple un organigramme (linéaire, fonctionnel ou matriciel). Si l’on souhaite plus de détail, on regarde alors au niveau des processus, qui permettent de représenter "une série d'activités qui, à partir d'un intrant, y ajoute de la valeur pour pro-duire un extrant" [Harrington, 1987]. Ainsi nous avons une vue plus précise sur ce que fait l’entité, ses finalités, ses rôles, ses missions. Afin que ces processus soient connus, opéra-tionnels et cohérents entre eux, ils sont alors décrits, parfois cartographiés. Un pas supplémentaire dans le niveau de détail, et nous arrivons à des organisations opéra-tionnelles, c'est - à - dire qui doivent réaliser les opérations définies au niveau supérieur, et qui en général s’appuient sur un ensemble de procédures.

Stratégique

Tactique

Opérationnel

B

A

C

E

Organisationopérationnelle

Figure. 1 - Pyramide de décisions

Sur la figure 1, sont représentés trois éléments constitutifs de l’environnement de décision d’une entreprise :

sa stratégie : quelle orientation doit - elle prendre ? sa tactique : comment va - t - elle réaliser sa stratégie ? son opérationnel : ce avec quoi elle va la réaliser.

C’est à ce dernier niveau, au cœur de l’opérationnel, que se trouve la plus petite forme d’organisation hiérarchique de l’entreprise (l’élément le plus petit sur un organigramme). Cette dernière utilise des ressources et a une vie propre qui évolue dans le temps et en fonc-tion des interactions avec l’extérieur, elle peut être représentée par le schéma suivant (Figure. 2 - Les interactions d’une organisation générique) où l’on voit apparaître des zones de responsabilité, des liens d’interactions, des acteurs, des outils (dossier, bases de données, ordinateurs, . .), …. C’est un système d’action intelligent évoluant par interactions entre cha-cune de ses parties.



B

A

C

E

Figure. 2 - Les interactions d’une organisation générique

Cet ensemble d’interactions, appelé Système a des objectifs à suivre, et les acteurs qui le composent nécessitent l’appui d’une personne qui en est responsable. Ce dernier, que nous appellerons Manager3 a la mission de conduire ce système en prenant en compte un certain nombre de variables : l’organisation cible (pour réaliser ce qui est nécessaire à l’entreprise), ce qui existe (ce que chacune voit et vit) et ce qui est souhaité (ce qui convient à tou (te) s). (Figure. 3 - Le révérenciel d’une organisation générique)

Manager

Organisation nécessaire

Organisation souhaitée

Organis

ation

exist

ante

B

A

C

E

Figure. 3 - Le révérenciel d’une organisation générique

3 Dans le périmètre de notre étude cette personne est aussi appelée Chef de projet Maitrise d’œuvre, à ne pas confondre avec une autre personne qui est Chef de projet Version, dont nous parlerons aussi par la suite.



« Newell et H. A. Simon (1972, 1986) ont montré que l’on pouvait toujours représenter un système d’action intelligente par un système de computation symbolique, donc par un arte-fact (une machine de Turing) » [Le Moigne, 1994]. Il se trouve que dans un cas fondé en partie sur des composants humains, cette représentation formelle comporterait un très grand nombre de données fortement variables. Effectivement, l’être humain en tant que tel nécessiterait une gigantesque analyse et un grand nombre de traitements mathématiques pour pouvoir être représenté sous forme d’équation. Il serait né-cessaire de recueillir une infinité de variables qui serait démultipliée lorsqu’il s’agirait d’intégrer la notion de groupe. Même en simplifiant excessivement, une réflexion analytique de ce type, serait longue et très incertaine. Une autre manière serait de définir ce Système comme étant complexe « est complexe ce qui ne peut se résumer en un maître mot, ce qui ne peut se ramener à une loi, ce qui ne peut se réduire à une idée simple » [Morin, 1990]. Cette approche systémique serait fondée sur les composants du système et ses interactions. Pour travailler de cette façon, nous avons choisi d’utiliser une méthodologie de représentation graphique : OSSAD (Office Support Systems Analysis and Design), construite en s’appuyant sur de nombreuses méthodes comme Merise et étant très adaptée à des analyses systémiques. Elle a de plus le mérite d’être simple et donc de permettre une collégialité regroupant des utilisateurs, chef de projet, manager, …. Cette approche s’appliquera dans l’étude en s’appuyant sur un cas concret : « la mise en place d’un pilote sur une montée de version d’une application d’un Opérateur de télécom-munications » le Système étant le service informatique en charge de cette application. Ainsi grâce à la concrétisation de cette approche nous nous efforcerons de représenter au plus prés de la réalité, différentes vue d’organisation de ce service. Au final cette étude permettra de répondre à une question du manager qui serait : « Comment puis - je comprendre, mon organisation, afin de connaître et de maîtriser le fonctionnement des ressources qui la composent, et le cas échéant l’améliorer ou l’adapter afin de mieux répondre au besoin de ma Direction et de sa stratégie ? » Cette étude aidera à trouver des réponses par une démarche qui, s’imprégnant d’un certain nombre d’outils, méthodes et concepts, présentera une organisation sous trois vues d’interprétation : ce qui doit être, ce qui est, ce qui pourrait être.



Organisation du document

Etude

Situation Réalisation

Entités concernées

Présentation de l’étude

Bases de mûrissement

Compréhension de l’organisation

théorique

Analyse de l’organisation

existante

Projection des organisations souhaitées

ReprésentationOrganisation

Méthode

Figure. 4 - Organisation du document – Présentation

Ce document est composé de deux parties chacune ayant 3 chapitres. Nous aborderons, dans la première partie, l’ensemble des éléments permettant de si-tuer, cadrer et comprendre ce que nous allons traiter dans ce document. La se-conde partie sera la mise en application des représentations d’organisations et leurs analyses en se fondant sur un cas concret.



Sommaire RREESSUUMMEE 44 IINNTTRROODDUUCCTTIIOONN 55 OORRGGAANNIISSAATTIIOONN DDUU DDOOCCUUMMEENNTT 88 SSOOMMMMAAIIRREE 99 TTAABBLLEE DDEESS FFIIGGUURREESS 1122 SSIITTUUAATTIIOONN 1155

1. Entités concernées_________________________________________________________ 16 1.1. Le groupe France Telecom 16 1.1.1. Activités 16 1.1.2. La Stratégie de France Telecom 17 1.1.2.1. Le programme NExT 18 1.1.3. Organisation 19 1.1.3.1. France Telecom 19 1.1.3.2. Le SI Client 21 1.2. L’application CRISTAL 22 1.2.1. Présentation 22 1.2.2. Composition de l’application 23 1.3. La Maîtrise d’œuvre CRISTAL 25 1.4. Les directions Régionales 27 1.5. Synthèse des entités concernées 29 2. Présentation de l’étude _____________________________________________________ 30 2.1. Problématique 30 2.1.1. Problème à résoudre 30 2.1.2. Démarche de résolution envisagée 32 2.2. Cadrage de l’étude 35 2.2.1. Définition unitaire du sujet 35 2.2.2. Les limites 36 2.3. Contexte de l’étude 37 2.3.1. Le cycle de vie d’une montée de version 37 2.3.2. La mise en place d’un pilote (MPP) 38 2.3.3. La gestion des signalisations 40 3. Bases de mûrissement ______________________________________________________ 44 3.1. Introduction 44 3.2. Méthodologies, concepts et langage 44 3.2.1. Les processus et leurs représentations 44 3.2.1.1. ISO 9000 V2000 44 3.2.1.2. La définition de processus 46 3.2.1.2.1. Les processus opérationnels ou de réalisation 47 3.2.1.2.2. Les processus de support 47 3.2.1.2.3. Les processus de management 48 3.2.2. La méthode OSSAD 48 3.2.2.1. Présentation 48 3.2.2.2. Le modèle abstrait 49



3.2.2.3. Les modèles descriptifs 49 3.2.2.3.4. Le modèle descriptif de procédures 50 3.2.2.3.5. Le modèle descriptif de rôles 50 3.2.2.3.6. Le modèle descriptif d’opérations 51 3.2.2.4. Le modèle prescriptif 51 3.2.2.5. Le dictionnaire OSSAD 52 3.2.2.6. Les principes OSSADIQUES 52 3.2.2.7. La notion de zoom 53 3.3. Outils employés pour la modélisation 54 3.3.1. OSSAD PROCESS DESIGN 54 3.3.2. QQOQCCP 58 3.4. Synthèse du mûrissement 59

RREEAALLIISSAATTIIOONN 6611 4. L’organisation théorique – (Agathone)________________________________________ 62 4.1. Présentation 62 4.1.1. Le cycle de vie Agathone 62 4.1.2. La mise en place Pilote 64 4.2. Les processus 67 4.3. Les phases 68 4.4. Les rôles 69 4.5. Un exemple : La gestion des signalisations 69 5. L’organisation existante ____________________________________________________ 70 5.1. Présentation 70 5.2. Les phases et processus 72 5.3. Les rôles 75 5.4. Un exemple : La gestion des signalisations 77 6. Projection de l’organisation souhaitée ________________________________________ 82 6.1. Progression 82 6.2. Les phases et processus 83 6.2.1. Les rôles 86 6.3. Un exemple : La gestion des signalisations 88 7. Synthèses ________________________________________________________________ 91 7.1. L’organisation théorique 91 7.2. L’organisation existante 94 7.3. L’organisation souhaitée 96 7.4. Remarques 98

CCOONNCCLLUUSSIIOONN 110000 AAPPPPOORRTT PPEERRSSOONNNNEELL 110022 AANNNNEEXXEE 110033

8. Bibliographie ____________________________________________________________ 104 9. Glossaire _______________________________________________________________ 106 10. Complément : Le dictionnaire OSSAD______________________________________ 108 11. Complément : Méthodes et outils complémentaires ___________________________ 111 11.1. Six Sigma 111



11.2. MERISE 113 11.3. UML 114 11.4. Ishikawa. 116 11.5. La Loi de Pareto 118

12. Complément : Recueil des composants de la MPP__________ 120 12.1. Les Pôles autour de Cristal 120 12.2. Le Pôle MPP 121 12.2.1. Les livrables 121 12.2.2. Les outils 121 12.2.3. Les réunions 121 12.2.4. Les rôles 122 12.3. Les Pôles contributeurs directs 123 12.3.1. La qualification 123 12.3.1.1. Les rôles 123 12.3.1.2. Les outils 124 12.3.2. Le référentiel 124 12.3.2.1. Les rôles et activités associées : 124 12.3.2.2. Les livrables 125 12.3.2.3. Les outils 125 12.3.3. Les études 125 12.3.3.1. Les rôles et activités associées : 125 12.3.3.2. Les livrables 126 12.4. Les Pôles contributeurs indirects 126 12.4.1. Les rôles 126 12.4.2. Les livrables 127 13. Complément : Documentation des activités AGATHONE MPP _________________ 128 13.1. Descriptif des processus AGATHONE 128 13.1.1. (A) MO_ORGANISATION, AVANCEMENT ET SUIVI 128 13.1.2. (A) MO_QUALIFICATION MOE SI 131 13.1.3. (A) MO_INSTALLATION 132 13.1.4. (A) MO_FORMATION METIERS 134 13.1.5. (A) MO_COMMUNICATION 135 13.1.6. (A) MO_RELATIONS AVEC LE SITE PILOTE 137 13.1.7. (A) MO_QUALIFICATION UTILISATEURS 138 13.2. Représentation OSSAD des processus AGATHONE MPP 139 13.2.1. Les activités du processus AGATHONE MPP 139 13.2.2. Les phases du processus AGATHONE MPP 146 13.2.3. Les relations avec les autres processus 154



Table des figures

Figure. 1 - Pyramide de décisions 5 Figure. 2 - Les interactions d’une organisation générique 6 Figure. 3 - Le révérenciel d’une organisation générique 6 Figure. 4 - Organisation du document – Présentation 8 Figure. 5 - Organisation du document – Situation 15 Figure. 6 - Positionnement CRISTAL au sein de France Telecom 16 Figure. 7 - Le comité de direction Générale de France Telecom 19 Figure. 8 - Organisation globale de France Telecom 20 Figure. 9 – Les processus métier de France Telecom 22 Figure. 10 – Macro - composants de CRISTAL 24 Figure. 11 - Macro - composants de CRISTAL Infocentre 24 Figure. 12 - Pilotage d’une mise en place d’un pilote 26 Figure. 13 - Carte des Directions Régionales de France Telecom 27 Figure. 14 - Organisation d’une Direction régionale chez France Telecom 28 Figure. 15 - Différences entre différentes organisations 31 Figure. 16 - Différences et relations entre organisations 34 Figure. 17 - Cycle de vie d’un projet de montée de version 38 Figure. 18 - Cycle de vie : Étapes ayant une relation forte avec le pilote 39 Figure. 19 - Signalisations : Les différents évènements et leurs traitements 40 Figure. 20 - Signalisations : Processus d’escalade simplifié 41 Figure. 21 - Signalisations : Différentiation des mémoires 42 Figure. 22 - Cartographie simplifiée des normes autour d’ISO 9000 V2000 (Source AFNOR) 45 Figure. 23 - Présentation d’un processus 46 Figure. 24 - ISO 9000 - Les trois familles de processus 47 Figure. 25 - OSSAD – Méta Modèle abstrait (UML) 49 Figure. 26 - OSSAD – Méta Modèle descriptif de procédures (UML) 50 Figure. 27 - OSSAD – Méta Modèle descriptif de rôles (UML) 50 Figure. 28 - OSSAD – Méta Modèle descriptif d’opérations (UML) 51 Figure. 29 – Macro schéma des modèles OSSAD 53 Figure. 30 - Écran de base d’OSSAD Process Design 55 Figure. 31 - OSSAD Process Design – Modèle abstrait 55 Figure. 32 - OSSAD Process Design – Modèle descriptif de procédures 56 Figure. 33 - OSSAD Process Design – Graphe des rôles 56 Figure. 34 - OSSAD Process Design – Modèle descriptif des opérations 56 Figure. 35 - OSSAD Process Design – Matrice des processus et rôles 57 Figure. 36 - OSSAD Process Design – Graphe des unités organisationnelles 57 Figure. 37 - QQOQCCP – Quelques questions 58 Figure. 38 - Organisation du document – Réalisation 61



Figure. 39 - Différences et relations entre organisations 62 Figure. 40 – AGATHONE - Le cycle en Y 63 Figure. 41 - AGATHONE – les processus et phases 63 Figure. 42 - AGATHONE – les relations du processus MPP avec les autres processus 64 Figure. 43 - AGATHONE – Les regroupements du processus MPP 65 Figure. 44 - AGATHONE – Les activités de suivi des signalisations 69 Figure. 45 - Différences et relations entre organisations 70 Figure. 46 – Ensembles des composants de la MPP 71 Figure. 47 – (Organisation existante) – Phase préparation 72 Figure. 48 – (Organisation existante) – Phase installation 73 Figure. 49 – (Organisation existante) – Suivi et bilan 74 Figure. 50 – (Organisation existante) – UML des rôles 75 Figure. 51 – Organisation et positionnement de la MOE CRISTAL 76 Figure. 52 – Equipes de la MPP 77 Figure. 53 - Signalisations : Processus d’escalade simplifié 78 Figure. 54 - AGATHONE – Les activités de suivi des signalisations 78 Figure. 55 – Processus existant de gestion des signalisations 79 Figure. 56 – Vie d’une signalisation : visibilité de la MPP 81 Figure. 57 – Différences et relations entre organisations 82 Figure. 58 – Ensembles des composants de la MPP 82 Figure. 59 – (organisation souhaitée) - Phase préparation 83 Figure. 60 – (organisation souhaitée) - Phase initialisation 84 Figure. 61 – (organisation souhaitée) - Phase lancement 84 Figure. 62 – (organisation souhaitée) - Phase réalisation 85 Figure. 63 – (organisation souhaitée) - Phase terminaison 85 Figure. 64 – Les phases projet 86 Figure. 65 – Processus cible gestion des signalisations 88 Figure. 66 - Signalisations : Les différents évènements et leurs traitements 89 Figure. 67 - AGATHONE – Complexité de la méthodologie 91 Figure. 68 - AGATHONE – La notion de cycle de vie d’une information 92 Figure. 69 - Six Sigma - Coubre de satisfaction avant 111 Figure. 70 - Six Sigma - Courbe de satisfaction après 112 Figure. 71 - MERISE – Les modèles de données et de traitements 113 Figure. 72 - UML – Une Classe 115 Figure. 73 - UML – Une association 115 Figure. 74 - UML – Une multiplicité 116 Figure. 75 - UML – Une Agrégation 116 Figure. 76 – Le modèle de diagramme de causes à effet 117 Figure. 77 – Pareto ou le 80/20 118 Figure 78 – AGATHONE, Activité : Organisation, avancement et suivi. 139 Figure 79 – AGATHONE, Activité : Qualification MOE SI 140



Figure 80 – AGATHONE, Activité : Installation 141 Figure 81 – AGATHONE, Activité : Formation métiers 142 Figure 82 – AGATHONE, Activité : Communication 143 Figure 83 – AGATHONE, Activité : Relation avec le site pilote 144 Figure 84 – AGATHONE, Activité : Qualification utilisateurs 145 Figure 85 – AGATHONE, Phase 1 MPP : Mûrissement 146 Figure 86 – AGATHONE, Phase 2 MPP : Recherche du site pilote 147 Figure 87 – AGATHONE, Phase 3 MPP : Préparation du déploiement (1/2) 148 Figure 88 – AGATHONE, Phase 3 MPP : Préparation du déploiement (2/2) 149 Figure 89 – AGATHONE, Phase 4 MPP : Initialisation du site pilote 150 Figure 90 – AGATHONE, Phase 5 MPP : Installation 151 Figure 91 – AGATHONE, Phase 6 MPP : Suivi et Bilan 152 Figure 92 – AGATHONE, Phase 7 MPP : Post Bilan 153 Figure 93 – Abstrait MA - Agathone MPP - Relation avec les autres processus 154 Figure 94 – Abstrait MA - Agathone MPP - synthese MO par Activité 155 Figure 95 – Abstrait MA - Agathone MPP - synthese MO par phase 157 Figure 96 – Abstrait MA - Agathone MPP - synthese MO par Activité 157 Figure 97 – Abstrait MA - Agathone MPP - synthese MO par phase 158



Situation

Etude






théorique


existante



Méthode

Figure. 5 - Organisation du document – Situation

La « situation » est la première étape de notre réflexion. Nous considérons que notre thèse est un système, qui est donc composé d’un ensemble d'éléments qui interagissent entre eux, et qui échangent des informations. La délimitation de ce système se fait par l'énumération des composants qui par leurs présences intègre des créations, modifications ou suppressions de contraintes. Ainsi, cette première partie sera la délimitation de la thèse. A savoir : donner au lecteur l’ensemble des briques nécessaire à la bonne compréhension de l’ensemble de notre démarche : les limites, les composants et les contraintes.



1. ENTITES CONCERNEES Dans ce chapitre, nous situons l’environnement qui a permis de réaliser la partie ap-plication de l’étude. Pour cela nous aborderons l’entreprise à travers sa stratégie et son organigramme, pour au final présenter la Maîtrise d’œuvre CRISTAL et son or-ganisation du moment. Nous parlerons aussi des Directions Régionales qui sont les clients finaux de l’application et donc les témoins des Pilotes. L’application CRIS-TAL4 sera plus détaillée car au centre de notre étude.

Figure. 6 - Positionnement CRISTAL au sein de France Telecom

1.1. Le groupe France Telecom

Le groupe France Telecom, d’envergure mondiale, a été créé en 1988, et est l’un des principaux opérateurs de télécommunication. Il dispose d’atouts technologiques déterminants qui lui permettent d’être à la pointe des différents secteurs de la télé-communication.

1.1.1. Activités

En 2005, avec un effectif de 199 557 salariés, France Télécom a généré un chiffre d’affaires de 47 157 millions d’Euros. Ses activités se répartissent autour de quatre secteurs :

Le téléphone fixe5 : Activité historique de France Telecom, le téléphone fixe concerne 49,25 millions de lignes téléphoniques. Ouvert à la concurrence, le téléphone fixe est l’une des activités majeures de France Telecom.

4 Application commerciale et technique de gestion des lignes fixes et des offres associées. 5 L’activité de la téléphonie fixe est la raison d’être de l’application CRISTAL.

France Telecom

Division Réseau et Système d’Information Direction Développement

du Système d'Information Direction Système d’Information Client Direction Processus

Livraison

CRISTAL

Etudes

RéferencielQualification

Réalisation

Pilote

Direction Régionale




Les mobiles : Leader en France et en Angleterre du marché de la téléphonie mobile avec Orange, France Telecom est aujourd’hui l’un des principaux opérateurs mobiles dans le monde. Internet : Fournisseur d’accès à Internet par l’intermédiaire de Wanadoo, l’ensemble des métiers Internet est représenté dans le Groupe avec des portails généralistes et spécialisés, du commerce électronique, des annuaires et des solutions d’hébergement. Services aux entreprises : A travers sa filiale Equant, France Telecom offre une gamme de produits et services comprenant l’IP, le Frame Relay, l’ATM, la voix, l’intégration voix - données, l’hébergement et les applications et services aux professionnels.

Afin d’avoir une meilleure visibilité de la taille du groupe et donc de la criticité des applications orientées client final (exemple : CRISTAL), voici un état numérique du Parc Client de France Télécom au 30 septembre 2005 :

Pour le monde : 130, 7 millions de clients. Mobile : 70 millions de clients dont 57, 9 millions de clients Orange Fixe5 : 49, 25 millions de clients Internet : 11. 41 millions de clients

Pour l’Europe : 120, 18 millions de clients (France incluse) Mobile : 60, 46 millions de clients dont 51, 33 millions pour Orange Fixe5 : 48, 36 millions de clients Internet : 11, 35 millions de clients

Pour la France : 60, 933 millions de clients Mobile : 21. 67 millions de clients Fixe5 : 33. 64 millions de clients Internet : 5. 61 millions de clients

1.1.2. La Stratégie de France Telecom

L’objectif cible de France Telecom est de devenir le fournisseur de services télé-coms de référence en Europe. Le groupe ayant réussit à rembourser ses dettes de-puis la fin du premier trimestre 2005, peut désormais arrêter de se limiter dans les investissements. Solidement positionné sur ses métiers et porté par des activités à forte croissance dans les domaines de l'Internet, du haut débit et des mobiles, sa stratégie est orienté sur une croissance rentable fondée sur l'innovation et l'intégration. Il est à la fois un fournisseur de services de télécoms et un opérateur de réseaux télécoms. S'appuyant sur un portefeuille complet d'offres et de solutions, sur sa maîtrise de tous les réseaux et sa capacité d'innovation intégrée, France Télécom est en train de développer un nouveau monde de services dans le domaine de la communication, de l'information et des loisirs, de la vie pratique ainsi que des services aux entrepri-ses. Ce « nouveau monde » est décrit dans un Programme (NExT) de façon à communiquer en interne et externe sur les orientations prises.



1.1.2.1. Le programme NExT

NExT (Nouvelle Expérience des Télécoms), est un programme de transformation qui a été lancé en Juin 2005 et s’étalera jusqu’en 2008. Son objectif est d’accompagner l’ensemble des entités du Groupe vers l’objectif stratégique de de-venir opérateur intégré. Ceci afin de faire de France Télécom le fournisseur de ser-vices de référence en Europe en matière d'innovation, de qualité de services, et de performance économique. Cette orientation s’explique de par les habitudes de communication qui évoluent : avec la généralisation des usages Internet et mobiles, nous sommes passés d'une of-fre mono forme, assujettie à la durée et la distance, à une offre fondée sur l'abon-dance. L’ouverture de la boucle locale (ce qui relie l’utilisateur final au moyens d’extrémité de l’opérateur historique), a favorisé une concurrence qui pour se dé-marquer a orienté sa stratégie vers de la diversification d’offres6. Face à ce foisonnement d’offres sur le marché et à la multiplicité des moyens de communication, les consommateurs comme les entreprises attendent une simplifica-tion des usages, avec des terminaux et équipements qui leur facilitent la communi-cation, faciles à utiliser et qui communiquent entre eux. Ils veulent définir et per-sonnaliser leurs services, qui deviennent multi - accès, et recréer de façon instantanée leurs univers de communication. Cet évolution du marché apporte la notion de convergence des technologies afin, de dissocier l’offre et les services associés à l’aspect technique des produits. La projec-tion finale de cette évolution pourrait être l’indépendance des besoins que nous pourrions avoir dans notre vie de tous les jours avec l’architecture technique néces-saire à leurs résolutions. Par exemple, avoir un artéfact qui permettrait de téléphoner de n’importe où (Internet sur WiFi à la maison ou le réseau d’un opérateur à l’extérieur), pourrait être télécommande de la TV et chaîne HiFi, serait synchronisé automatiquement avec le carnet d’adresse et l’agenda du bureau et de la maison, permettrait de régler des transactions à distance (parcmètres, magasins, . .) etc. L’utilisateur pourrait en changer sans avoir à faire de paramétrage, toutes les don-nées seraient associées à son empreinte digitale, …. Cette « révolution » a un impact très fort au niveau des systèmes d’information, car pour avoir au final un ensemble d’offres et de services, il est nécessaire d’avoir un système d’information intégré, c'est - à - dire qui soit capable de comprendre qu’une offre peut toucher, entre autre, à la fois le domaine du fixe, du mobile et de l’internet. En clair le système d’information doit être réactif et suffisamment mal-léable pour répondre au besoin du marché qui pousse à l’affranchissement de contraintes techniques. La présentation hiérarchique qui suit permettra d’avoir une vue globale de l’organisation de France Telecom et de la situation de l’Étude à tra-vers l’organigramme. Un autre aspect très important lié à cette « révolution », est la volonté de France Telecom de mettre en place une convergence le plus rapidement possible, à com-

6 Un phénomène complémentaire s’aperçoit de plus en plus et qui est de regrouper un grand nombre de ces offres dans des « packages » .



mencer par la fusion des systèmes d’informations des différentes entités du Groupe. Cette volonté de fusion, liée à l’évolution du marché et l’importance de la concur-rence, apporte de très nombreux effets de bord, à commencer par des réductions de coûts, et des priorités posées sur des projets stratégiques. Ces remaniement impliquent des baisses de budgets, et poussent à des réorganisa-tions en bout de chaîne, principalement sur les projets jugés moins importants. C’est le cas notamment des équipes autour de l’application CRISTAL, dont nous parle-rons par la suite. Ces remaniements sont une des raisons de l’étude.

1.1.3. Organisation

1.1.3.1. France Telecom

Figure. 7 - Le comité de direction Générale de France Telecom

Il est à noter que le comité de direction intègre le responsable de la Direction Ré-seaux et Système d’Information. Cela s’explique par le fait que le cœur de métier est le réseau (opérateur de télécommunication) et bien sûr l’importance du Système d’Information dans la stratégie de l’entreprise (aspect réactivité au marché).



Figure. 8 - Organisation globale de France Telecom

Au niveau de son organisation structurelle, France Télécom est fondée sur un orga-nigramme matriciel, il possède :

Quatre divisions métier : Elles sont chargées de l’amélioration de la performance opérationnelle du Groupe (ce sont les Maîtrises d’œuvre au niveau du système d’information) :

La division Contrôle de Gestion : La division Ressources Humaines, La division Communications et Relations Extérieures, La division Transformation et développement,

Sept divisions opérationnelles ; elles sont orientées vers la demande du client et les marchés correspondants (ce sont les Maîtrises d’ouvrage au niveau du système d’information) :

La division Services Entreprises, La division Réseaux, Opérateurs et Système d’Information, La division Développement, La division Ressources, La division Grand Public – Services Fixes, La division Grand Public – Internet, La division Distribution,

La division qui nous intéresse est Réseaux, Opérateurs et Système d’Information, elle a la responsabilité :

de définir les politiques de développement et d'assurer le pilotage des réseaux de France Télécom, toutes technologies confondues, de piloter le développement et la maintenance de l'ensemble des systèmes d'information du Groupe et de mieux intégrer, dans le réseau et le SI, tout ce qui permettra aux lignes de produits de créer des services intégrés, elle est également en charge de la vente de services aux opérateurs tiers, aspect important de part l’ouverture à la concurrence, qui oblige France Telecom à revendre une partie de ses services à la concurrence.



Au sein de cette division se trouve la Direction Développement du Système d'In-formation (DDSI) qui a en charge le pilotage du développement des systèmes d’information des différents domaines du Groupe (commercial, facturation, réseau et services) et des processus métiers du Groupe. Cette direction héberge le Système d’Information Client (SI Client).

1.1.3.2. Le SI Client

Le service sur lequel se positionne l’étude est le SI Client. Cette direction est très fonctionnelle, son organisation est majoritairement fondée sur des processus métier (Études, Livraison, …), elle a plusieurs missions principales :

Conduire le développement de processus métier, Contribuer à mutualiser les compétences et les solutions SI et obtenir des synergies entre les entités, Orienter les équipes SI vers les clients pour pouvoir servir avec réactivité et au meilleur coût les besoins SI du domaine.

En termes d’employés, le SI Client représente un peu plus de 1000 personnes. Au sein de la Direction SI Client, on trouve la Direction de projet Livraison7 dont le projet CRISTAL fait partie. Cette Direction gère l’ensemble du processus Livraison à travers deux applications : CRISTAL pour le marché des particuliers et AGATHE pour le marché des professionnels. Il est à noter qu’en fait CRISTAL gère aussi le processus Commande8, ceci de par son évolution historique.

7 Le processus Livraison prend en compte l’ensemble des actions à réaliser afin de répondre à une commande (actions principalement tech-niques). 8 Le processus métier Commande, englobe l’ensemble des actions permettant de traiter une demande d’un client. Cela signifie de le quali-fier (possible ou non), de le mémoriser, de le chiffrer, et de demander un règlement.



1.2. L’application CRISTAL

1.2.1. Présentation

CRISTAL signifie Commandes Résidentiels Intégrant un Système de Traitement et d’Affectation des Lignes (CRISTAL) et a pour objectif premier de simplifier le pi-lotage du processus de livraison pour l’élaboration des Ordres de Travaux (OT) et la mise en service technique des Accès Réseaux (AR), par un dialogue plus efficace entre les applications sollicitées. CRISTAL est un véritable outil de gestion interfacé avec un ensemble d’applications de gestion commerciale et technique, qui se base pour la prise de commande sur le marché Résidentiel. Aujourd’hui c’est une application transverse, et fédératrice, car utilisée à la fois par les acteurs de la vente pour la prise de com-mande et par les acteurs de la livraison pour le suivi de la réalisation technique. C’est aussi un système de référence dans l’application des processus Commande et Livraison.

Figure. 9 – Les processus métier de France Telecom

Pour information, la Figure. 9 – Les processus métier de France Telecom présente la cartographie des processus métier de France Telecom. Nous avons entouré le processus Commande Livraison dans lequel s’insère CRISTAL. On remarque que ce dernier est à cheval sur les processus Client (Customer) et Livraison (Service De-livery).



Deux raisons à cela :

Cristal était à l’origine une application de gestion de la livraison. Elle a évolué en prenant en compte une partie du processus de commande. Il existait, historiquement, deux processus indépendant : La livraison et la commande de service. Ces derniers sont restés dans les usages.

Le processus Commande et Livraison associe l’ensemble des étapes de la com-mande à ceux de la livraison dans une suite continue et cohérente permettant d’assurer la réponse au besoin exprimé du client. Pour une commande, cela débute dès la prise en compte du souhait du client et s’achève après sa réalisation avec l’envoi de la première facture. La date de la commande est donc le point de départ : c’est la date à laquelle un client manifeste sa volonté claire et affichée de commander un accès réseau, un produit ou un service. Cette commande se matérialise par un bon de commande ou son équivalent, quel-que soit le contexte de la commande : physique, téléphonique ou écrite. De façon résumée le processus Commande - Livraison suit par l’intermédiaire de CRISTAL, les trois étapes suivantes :

La commande : la prise de commande est réalisée par les conseillers - vendeurs, elle se termine à l’enregistrement de la commande. La réalisation : elle débute avec l’édition des ordres de travaux et se termine par le compte rendu de l’application qui pilote l’exécution de la réalisation Le compte rendu de réalisation : il est automatique et permet de solder la commande par l’émission des fiches de liaison vers l’application de facturation.

Afin de reporter les évolutions de ces processus, l’application doit vivre et s’adapter au mieux aux modifications nécessaires. Ces besoins du marché, une fois transcrits en expressions fonctionnelles, sont développés et appliquées par modifications des composants de l’application. Ces derniers sont parmi les éléments clefs du cycle de vie de l’application. Nous nous permettons de préciser que la stratégie du groupe France Telecom impli-que des demandes d’évolutions majeures qui sont très difficiles à réaliser et pous-sent indirectement à modifier les organisations de travail.

1.2.2. Composition de l’application

Au niveau technique, CRISTAL s’insère dans un environnement très riche en ter-mes de produit et de matériel. Afin de rester sur l’essentiel, nous représentons ici les macros - composants de CRISTAL qui vont nous être directement utiles. Ils peu-vent être regroupés en 2 familles :

Les composants applicatifs : (Ceux qui peuvent être représentés sous forme de produits binaires)

CRISTAL Serveur : Comporte l’ensemble des produits livrables s’installant sur le serveur CRISTAL et constituant le cœur de l’application,



CRISTAL Client : Composé par les produits livrables s’installant sur les serveurs clients de CRISTAL (redondant par Direction régionale), CRISTAL Services : Composants permettant de mettre à jour l’interface de type « MiddleWare » et s’ouvrant vers d’autres applications.

Les composants référentiels : (ceux qui sont représentés par des données, en générale sous forme de code SQL)

Catalogue : Contient l’ensemble des offre, services, matériels, … composant l’application CRISTAL, Règles de traduction : Contient les traductions pour l’interface CRISTAL Service, permettant de traduire les ordres émis et reçus d’autres applications CRISTAL, Tables de références : Contient des données de lien et de fonctionnement au niveau Catalogue.

Cristal

Cristal Serveur

Cristal Client

Cristal Services

CatalogueTable

deréférence

Règles de

traduction

DonnéesSpécifiquesCRISTAL

Figure. 10 – Macro - composants de CRISTAL

A noter que CRISTAL est aussi composé d’un infocentre qui est la réplique du CRISTAL de production, aussi bien en termes de données que des composants Ser-veur de l’application.

InfocentreCristal

Cristal Serveur

CatalogueTable

deréférence

DonnéesSpécifiquesCRISTAL

Figure. 11 - Macro - composants de CRISTAL Infocentre

L’ensemble de ces éléments sont générés par une équipe d’étude, appelé Maîtrise d’œuvre CRISTAL, qui prend en compte la gestion des évolutions de l’application, ceci en terme de correction (maintenance applicative) et d’évolutions (cycle de prise en compte des demandes d’évolution).



1.3. La Maîtrise d’œuvre CRISTAL9

La maitrise d’œuvre (MOE) CRISTAL fonctionne en mode projet10 elle a en charge la maintenance applicative de l’application CRISTAL et est composée de 4 pôles :

Études : Réalise la conception et le mûrissement des futures évolutions de l’application. Qualification : Pilote et réalise la qualification des composants de CRISTAL, qualifie les incidents lors du pilote. MPP : Mise en Place Pilote, prend en charge l’ensemble de la mise en place du pilote d’une nouvelle version. De la réception des livrables, à la terminaison validé du pilote. Référentiel : Gère, à partir de demandes, les mises à jour des référentiels

La réalisation des livrables de CRISTAL est sous traitée à une Tierce Maintenance Applicative (TMA) pilotée par la Direction de Service (DS) ; elle s’assure de la bonne réalisation des développements, et est responsable du support niveau 3 en Activités Récurrentes (hors mode projet). Elle est en renfort sur le pilote. Ce service gère l’ensemble du cycle de vie de l’application CRISTAL ; ce cycle de vie est alimenté par des corrections et des évolutions à mettre en œuvre ; c’est alors un processus de montée de version qui se met en place. Pour piloter ce processus, intervient un chef de projet version (CPV) qui va suivre l’ensemble du déroulement du cycle à partir de la réception des choix des évolu-tions et correctifs (décidé par une maîtrise d’ouvrage), jusqu’à la généralisation. Ce chef de projet version délègue une partie de son travail lors de la Mise en Place d’un pilote (MPP), rôle qui est pris en compte par le pôle MPP de la MOE que nous appellerons pilote de la MPP.

9 La Maîtrise d’œuvre (MOE) CRISTAL sera abordée en détail dans le cadre de cette étude, c’est pourquoi nous ferons une présentation succincte dans cette partie, ceci afin de transmettre suffisamment d’éléments pour permettre la bonne compréhension de la suite du docu-ment. 10 On appelle mode projet un fonctionnement suivant un cycle de vie. C'est-à-dire ayant un début et une fin et composé d’étapes planifiées. Le support n’est pas en mode projet, car il est en activité continu de réaction à un événement.



Pilotage

Besoins(évolutions/correctives)

Spécifications

Conception

Codage

Qualification

Intégration

Pilote

Généralisation

MOA

CPV

MPP

Figure. 12 - Pilotage d’une mise en place d’un pilote

Sur le schéma (Figure. 12 - Pilotage d’une mise en place d’un pilote), on voit appa-raître les étapes d’une montée de version d’une application11 ainsi que les liens de pilotage du pilote MPP et du chef de projet. Le Pilote de la MPP se concentre prin-cipalement sur les étapes directement liées à l’installation de la nouvelle version de l’application (Qualification, Intégration) et à celle de la Généralisation (le Client du Pilote). Le chef de projet est directement relié à l’ensemble des étapes. Il est à noter que le chef de projet version ne dépend pas de la MOE CRISTAL, tan-dis que le Pilote de la MPP l’est (la MOE CRISTAL est pilotée par un manager ap-pelé chef de projet MOE). L’objectif de cette répartition est de permettre au chef de projet version d’avoir un meilleur appui de pilotage au moment critique qu’est la mise en place du pilote. Ef-fectivement, le Pilote de la MPP faisant partie intégrante de la MOE sa maîtrise de l’organisation en place le rend donc plus réactif. La vie de la maîtrise d’œuvre est rythmée par des montées de version qui s’achèvent par une mise en place pilote suivi d’une généralisation. Il est important de noter que le pilote s’appuie sur des Directions Régionales afin de valider les étapes qui servi-ront pour la généralisation. Ces directions, une fois choisies font partie intégrante de la mise en place pilote et apportent à ce titre des ressources permettant la validation de la version et de l’organisation.

11 Ce cycle de vie sera détaillé par la suite (2.3.1 Le cycle de vie d’une montée de version)



1.4. Les directions Régionales

Les Directions Régionales sont les premières utilisatrices de l’application CRIS-TAL.

Figure. 13 - Carte des Directions Régionales de France Telecom

Dans le cadre de notre étude, ce sont aussi les clients directs des Pilotes sur cette application à ce titre il est utile de présenter leur organisation ainsi que les rôles ma-jeurs pouvant être rencontrés dans le cadre d’un Pilote. La France est découpée se-lon le schéma de la figure ci-dessus. Concernant la téléphonie Fixe, ces Directions Régionales (DR) sont autonomes au niveau des processus Commande et Livraison, elles possèdent des entités capables de livrer le service chez le Client. Chacune de ces directions régionales se compose d’une ou plusieurs Agences, qui possèdent des services avec des rôles bien définis et chaque agence maîtrise la tota-lité du cycle de commande/livraison en réunissant une équipe de vente et une équipe de production.



Les rôles rencontrés en DR sont :

Le vendeur : accueille le client, écoute ses besoins, traduit sa demande en terme compatible TELECOM, se situe à un accueil physique ou téléphonique, Le service consommateur 14 et 36 58 : traite les différés de règlements, règle les litiges sur les contrats en cours, Le Soutien Applicatifs et Méthodes (SAM) : joue le rôle de soutien auprès d’un groupe de vendeurs est un relais de formation local, Le pilote de livraison : surveille le bon déroulement de la réalisation des actions de livraison, suit les rendez - vous pris avec les clients, débloque certaines commandes tombées en anomalie, est le garant de la tenue des délais de livraison, Le rôle d’affectation des ressources réseau : réalise les études permettant d’affecter des ressources transport et distribution, est sollicité pour donner certains délais de livraison de la commande, utilise l’application de gestion des données réseau appelée 42C, Le rôle de contrôle des ressources commutation : contrôle de la programmation des commutateurs, les équipes d’intervention lignes réalisent les travaux liés aux lignes téléphoniques : pose de jarretières, installations terminales, Les agents des commutateurs : réalisent la pose de jarretières sur le répartiteur, Le Responsable Qualité des Données : assure différentes tâches de prévention et de corrections des données, vise à éviter la dégradation des données. Les personnes suivantes sont concernées :

La cellule d’intervention Locale (CIL), Les responsables qualité des données (RQD), Les administrateurs des tables locales et régionales.


Contrôle de Gestion

Transformation et développement

Ressources Humaines

Communication et Relations Extrérieures

Agences Distribution Agences

Unité Intervention Client

Unité Régionale de Réseaux

Agences Entreprises

Agences Vente Indirecte et

Publiservices

Direction developpement managériale et emploi

cadreSecrétariat

Figure. 14 - Organisation d’une Direction régionale chez France Telecom

On peut remarquer l’orientation de la Direction régionale vers la vente (Agences, processus Commande) ), possède ses entités de support (Unité, processus Livraison) et un certain nombre d’entités de soutien (Ressources Humaines, secrétariat, Contrôle de gestion, …).



1.5. Synthèse des entités concernées

France Telecom passe à travers une révolution culturelle où les clients recherchent des services riches et multiples, tout en étant extrêmement accessibles. Ce couple extrême entre la nécessité de complexité et la simplicité d’apparence a poussé cette entreprise à orienter sa stratégie vers de la convergence de technologie, et son mar-keting vers du regroupement de services. Cette (r)évolution très rapide a un impact fort au niveau des systèmes d’information impliquant des évolutions plus rapides et des équipes plus réactives afin de permet-tre aux briques du système d’information d’évoluer de façon optimale. Pour piloter ces mouvements, des équipes prennent en charge l’ensemble des étapes qui permet-tent de répondre à ces évolutions, ceci en se calquant sur un cycle qui se termine par la mise en place d’un pilote puis d’une généralisation. Ces deux dernières étapes nécessitent de faire appel aux utilisateurs finaux de l’application dont il est ques-tion ; ce sont les Directions Régionale qui, afin de valider le processus « pilote » vont devenir pendant un certain temps, des acteurs à part entière du projet d’évolution. L’ensemble de ce chapitre à présenté les entités qui seront la base sur laquelle se ré-alisera l’étude. Ces bases permettront de mieux situer le contexte et la raison de l’étude. Le chapitre suivant présentera le pourquoi ainsi que l’ensemble du cadrage de l’étude.



2. PRESENTATION DE L’ETUDE L’objectif est de poser l’ensemble des briques d’information, qui permettront de comprendre la démarche et la réflexion décrite par la suite. C’est le Pourquoi de l’étude. Il est nécessaire de comprendre le sens donné ici au mot Organisation. On appelle organisation, « un ensemble d'individus regroupés au sein d'une structure régulée, qui ont comme but de répondre/d'atteindre à un/des besoin (s) /objectif (s) détermi-né (s) » [Wikipédia]. Pour adapter cette définition, à cette étude, parlant de la struc-ture régulée, nous préciserons : « la plus petite structure régulée reconnue dans les organigrammes de la dite entreprise » . Concrètement l’organisation dont il est question dans l’étude est la Maîtrise d’Œuvre de CRISTAL.

2.1. Problématique

2.1.1. Problème à résoudre

Karl Marx (1818 - 1883) : économiste et philosophe allemand a dit : "L'humanité ne se pose que les problèmes qu'elle peut résoudre" La première partie de notre « problème à résoudre » se trouve donc dans la défini-tion du mot « problème » . Un problème n’existe que lorsque l’on constate un « dysfonctionnement » . Or il se trouve qu’il y a « dysfonctionnement » lorsque « l’existant à un moment donné » n’est pas ce qu’il « doit être » . Ce « dysfonction-nement » est communément appelé un problème. Que se passe t’il s’il y a perte du « ce qu’il doit être » ? En toute logique il n’y a plus de problème possible, c’est soit la situation idéale, soit une perte totale de contrôle de l’objectif de l’organisation, soit une satisfaction naïve sur un environ-nent qui existe sans réels objectifs que ceux du moment. Ce raisonnement très simple résume la base de réflexion de cette étude. Ne pas forcément partir d’un problème pour lancer une action visant à amélio-rer une organisation. Dans le schéma qui suit, dans lequel nous entrerons plus en détail par la suite, nous présentons quatre niveaux concernant une Organisation :

Existante : celle qui existe à un moment donné, Ressentie : chaque membre ayant son point de vue, plus on entre dans le détail, plus son point de vue devient différent des autres membres. Il est donc multiple, Souhaitée : la cible du manager, celle qu’il estime être la meilleure dans son contexte, Nécessaire ou théorique : ce qui devrait être afin de suivre aux normes définies par l’entreprise.



Il va de soi que sans impulsion orientant un service vers une organisation théorique (donc avec un effort), la tendance de chacun et donc du groupe sera d’aller vers sa propre organisation, qui dépend d’intérêts « non normalisés » (intérêts pouvant être différents de ceux de l’entreprise) ; nous appelons cela la tendance naturelle.

Effort volontaire

Tendance involontaire

Figure. 15 - Différences entre différentes organisations

Une seconde partie de notre « problème à résoudre » se trouve être dans la cible de ce que l’on veut faire. Considérant que les organisations d’un service donné peuvent être multiples en fonction du poste d’observation que l’on a, un ingénieur qualité verra l’organisation théorique, un manager verra l’organisation souhaitée, les mem-bres de l’équipe verront l’organisation ressentie et tout ce monde évoluera dans une organisation existante. Ce n’est pas un problème, que d’avoir ces différences, cela peut l’être de ne pas les maîtriser ou de ne pas en être conscient. Là se trouve notre seconde raison de cette étude. Être conscient et capable de connaître une organisation réelle existante afin de pouvoir la comparer à d’autres (théorique, souhaitée, . .) La dernière partie de notre « problème à résoudre » concerne le positionnement de notre réflexion. La société d’aujourd’hui est très orientée qualité de service au client final. Nous sommes passés successivement d’une ère où la demande était plus forte que l’offre, impliquant une production de masse, à une ère où la demande rejoint l’offre avec une socialisation de l’entreprise, impliquant une optimisation des pro-cessus de production, pour arriver aujourd’hui à une ère où l’offre est plus forte que la demande et le client plus capricieux, impliquant une réorientation de l’entreprise vers le client final. Au cours du temps il se trouve que les orientations stratégiques liées aux évolutions du marché, provoquent des réajustements nécessaires dans l’organisation des entre-



prises. Ces réajustements se font souvent sur des orientations stratégiques qui met-tent en place une tactique impactant l’ensemble des opérationnels de l’entreprise. Qu’en est-il justement de cet opérationnel ? Comment va - t - il appliquer cette tac-tique, comment pourra se faire son adaptation à ces grands mouvements qui sont souvent compris qu’à moitié (lorsqu’il en est conscient) ? La réponse se trouve dans le rôle des managers ; ils sont parmi les plus petits élé-ments exécutifs de l’entreprise, ils ont la responsabilité de s’adapter et de faire adapter leurs équipes aux mouvements stratégiques initiaux. Ils pourront difficile-ment le faire s’ils ne maîtrisent pas leur propre organisation. Là se trouve la dernière raison de cette étude : Aider le manager à maîtriser son organisation.

2.1.2. Démarche de résolution envisagée

Ainsi nous sommes face à une organisation avec comme objectif premier de cher-cher à la connaître afin de mieux la maîtriser. A cet objectif, nous rajouterons : Être capable de représenter visuellement une organisation de façon à pouvoir communiquer et travailler collégialement avec la même vue. Et être capable de comprendre la raison d’avoir une organisation cible. Considérant l’organisation comme étant composée d’individus, il est important de prendre en compte la notion de complexité du système étudié. Vouloir mettre en équation un système complexe serait illusoire. « la pensée complexe aspire à la connaissance multidimensionnelle. Mais elle sait au départ que la connaissance complète est impossible : un des axiomes de la complexité est l'impossibilité, même en théorie, d'une omniscience. » [Morin, 1990]. Effectivement une étude analytique s’applique à des éléments simples, éventuelle-ment compliqués mais non complexes, des éléments qui peuvent être fragmentés en unités élémentaires. Une organisation est un système vivant, composé de relations récurrentes et aléatoires. Elle nécessite d’être vue à travers une analyse systémique qui se fonde sur des interactions, liens et complexités et qui définit des éléments par leurs rôles et activités plutôt que par leurs effets formels. Cette approche systémique permettra d’aborder l’organisation comme étant un sys-tème complexe, J. - L. Le Moigne définit un système comme "quelque chose d'iden-tifiable, dans un environnement, muni d'une finalité (projet), qui fonctionne (activi-té), au moyen d'une forme stable (structure), et qui se transforme dans le temps (évolution) " [Le Moigne, 1984]. A cela nous pouvons rajouter la vue de L Von Bertalanffy, « le point d'entrée de l'exploration systémique est le... système, c'est - à - dire ses composants, ses flux » [VON BERTALANFFY, 1973].



Ainsi nos objectifs évoluent vers : Nous souhaitons être capables de présenter l’organisation réelle existante par des représentations visuelles en utilisant une approche systémique. Notre stratégie étant posée, il apparaît nécessaire de définir la tactique. L’organisation sur laquelle nous allons nous appuyer est un service de maîtrise d’œuvre informatique qui a en compte les évolutions d’une application qui est cen-trale au Processus métier Commande/Livraison. Nous sommes donc en face d’un service où l’ensemble du travail est fondé sur un fonctionnement Projet. Le mode projet que suit ce service est fondé sur une méthodologie propriétaire qui s’appelle AGATHONE ; cette méthodologie est très orientée processus et prend en compte l’ensemble des étapes du cycle de vie d’une application (entre autres). Nous sommes donc dans un environnement projet fondé sur des processus, dont le travail est principalement bureautique, et s’appuyant sur une méthodologie projet d’entreprise. Cet environnement sera pour nous l’organisation théorique (théorique) 12. La représentation de l’organisation de ce service d’études ne serait pas complète si elle était dissociée de l’environnement projet dans lequel elle doit évoluer. Cette contrainte nous aidera à justifier de la nécessité d’adapter notre réflexion afin de re-présenter l’existant par rapport à la cible. Un aspect important dans la représentation d’un existant est qu’elle est fondée sur des retours d’entretiens de personnes appartenant ou non à l’organisation cible. Et que chacune de ces personnes n’a pas la même vision de l’organisation, de par ses rôles, ses activités, ses compétences, son vécu et ses expériences. Ces organisations ressenties constituent l’organisation réelle existante. L’importance de différencier les deux organisations est de bien faire comprendre que l’organisation existante est dépendante des personnes qui la composent, ainsi un mouvement de personne implique une modification de l’organisation existante. L’ensemble des attributs qualifiant une personne et ses rôles doit donc faire partie intégrante de notre réflexion. La cible finale du manager étant bien sûr d’orienter son service vers les recomman-dations de l’entreprise, tout en tenant compte des particularités de son environne-ment propre et de ses équipes. Le schéma ci - dessous résume cet aspect. Il repré-sente les différentes organisations avec une vue par niveau.

12 Cette organisation sera celle décrite par la méthodologie du groupe France Telecom : AGATHONE



Organisation représentable

Organisation réelle existante

Organisations ressenties

Organisation Souhaitée

Organisation théorique

Différence a

Différence b

Différence c

Figure. 16 - Différences et relations entre organisations

Ainsi, comme le présente Edgar Morin, « La pensée de la complexité se présente (…) comme un édifice à plusieurs étages » [Morin, 1990], il sera nécessaire de rai-sonner par “étages” mais aussi en ayant la possibilité d’enrichir ces étages des dé-tails qui nous seront nécessaires. Nous devrons donc progresser dans le raisonnement :

en tenant compte de l’aspect systémique de l’environnement ; en se rapprochant le plus possible d’un raisonnement processus ; en faisant des regroupements de détails par « étages » .

Cette partie a permis de traiter de la cible de notre étude, en justifiant de la nécessité de prendre en compte une organisation sous différents angles et surtout d’avoir une approche systémique. Cette cible nécessite un enrichissement quant à son orienta-tion et au niveau du périmètre de réalisation. Ce cadrage sera effectué au cours de la partie suivante.



2.2. Cadrage de l’étude

2.2.1. Définition unitaire du sujet

Afin de délimiter le sujet, il est nécessaire de définir unitairement les composants qui constituent le sujet, et ceci dans le cadre de notre étude.

Service d’étude informatique : Un service informatique est une organisation prenant en compte l’ensemble des tâches nécessaires afin de livrer un ou plusieurs composants logiciel modifiant, créant ou remplaçant un logiciel existant. Ce service informatique inclus généralement un bureau d’étude, des équipes de développement, de tests et recette, de qualification, … Montée de version : Dans un système d’information informatique, il arrive qu’il soit nécessaire de faire évoluer une application en production. L’opération de montée de version consiste à prendre en compte l’ensemble des actions faisant passer l’application d’origine vers un nouvel état portant les modifications et/ou nouveautés. Mise en place d’un Pilote : Lorsque l’on doit toucher à un élément du système d’information, il est important de valider que cet élément nouveau ou modifié répond bien à ce qui était souhaité et soit le moins possible impactant au niveau des utilisateurs finaux. Pour cela on met en place un Pilote. Le Pilote est un ensemble d’utilisateurs qui vont tester les fonctionnalités ayant été impactées de près ou de loin par le nouvel élément ou la modification d’un élément applicatif existant. Organisation : « Une organisation est un ensemble d'individus, regroupés au sein d'une structure régulée, dans le but de répondre/d'atteindre à un/des besoin (s) /objectif (s) déterminé (s) » [Wikipédia] Flux : « Le flux est un ensemble d'éléments (données, énergie, matière, ...) évoluant dans un sens commun » [Wikipédia] Processus : Ensemble cohérent d’activités, d’opérations, d’interactions humaines qui traite des informations entrantes et en restitue de nouvelles. Représentation : « Action de présenter à nouveau » (Larousse), que l’on peut compléter par « par l’usage de composants visuels » .

En s’appuyant sur les définitions précitées, l’objet du sujet est donc de :

Reproduire de façon interprétable, des séquences de phénomènes dynamiques ayant au moins une entrée et au moins une sortie, ainsi que des mouvements d’ensembles d’éléments évoluant dans des sens communs pour un ensemble d’individus regroupés dans une structure régulée et ayant des objectifs déterminés. Ceci se faisant pour un service d’étude qui met en place un pilote pour une montée de version.



Reformulé notre sujet sera : Reproduire visuellement, de façon la plus simple possible, comment les membres d’une organisation d’étude informatique fonctionnent lorsqu’une mise en place pilote se fait pour une nouvelle version d’une application.

Le périmètre ainsi défini, la présentation des limites ci-après permettront à la réali-sation de cette reproduction visuelle de se faire de façon contrôlée.

2.2.2. Les limites

A partir du moment où il est question de comportement et fonctionnement humain, apparaît une très forte richesse difficilement formalisable. Ce mémoire va traiter de façon mixte l’aspect “industriel” et l’aspect “humain”. Le premier dans la création et la formalisation de ce qui doit être, la seconde dans la reproduction de ce qui est. Les comportements humains ont des logiques qui ne sont pas universelles et donc non reproductibles sous forme de modèles car ils sont complexes. Ce mémoire ne se positionnera pas sur :

la gestion des compétences, mais pourra être une bonne base pour lancer un projet de ce type. un audit organisationnel ; même si cela peut y ressembler voire être utilisé à cette fin, l’objectif est de sensibiliser sur une démarche. une représentation générique d’un service d’études. Même si la majorité des éléments sont présents et pourraient être reproduits dans d’autres organisations, l’idée est de livrer une représentation d’un service d’étude spécifique en utilisant une démarche particulière. l’analyse de la méthode OSSAD : Cette méthode étant un des outils de cet étude.

La granulosité des représentations s’arrêtera à ce qu’il peut être nécessaire de dé-crire pour comprendre. Les événements unitaires et aléatoires seront volontairement omis et considérés comme bruit. Cela ne veut pas dire qu’ils sont inutiles au jour le jour, mais seulement qu’ils sont trop détaillés pour être élucidés dans le cadre de ce document. Ces représentations couvriront un périmètre déterminé que nous défini-rons dans la partie suivante.



2.3. Contexte de l’étude

L’étude se déroule au sein de la maîtrise d’œuvre CRISTAL. Cette organisation est calquée sur un cycle de vie de montée de version d’application métier. Ce cycle de vie se termine par la fin de la phase Mise en Place Pilote qui est la base même de l’étude.

2.3.1. Le cycle de vie d’une montée de version

Dans le cadre du cycle de vie d’une application, apparaît une récurrence d’opérations appelée « montée de version » . Cette opération suscitée par des be-soins comporte un ensemble d’activités que nous regrouperons en trois phases prin-cipales :

Étude : Cette phase comprend toute la partie qui consiste à partir d’un besoin de livrer des spécifications suffisamment explicites pour que la réalisation puisse se faire (expression des besoins, proposition de solution, spécifications fonctionnelles et techniques, …), Réalisation : La réalisation comprend l’écriture ainsi que la compilation du code permettant de mettre en œuvre les modifications/évolutions spécifiées par les livrables de la phase d’étude, une fois ce codage réalisé, Qualification : Elle permet de réaliser les tâches de tests et validation des éléments livrés (tests unitaires, de non régressions, …), et de qualifier les incidents rencontrés au cours de la mise en place d’un pilote (MPP), Déploiement : La phase de déploiement prend en compte l’intégration des éléments livrés par la Réalisation afin de pouvoir être intégrés en production. La mise en place d’un pilote permet de valider à grande échelle les modifications apportés et la généralisation de l’étendre à l’ensemble du Système d’information.

Au cours de la mise en place d’une nouvelle version, apparaîtront deux nouvelles phases que nous détaillerons par la suite : la chaîne de soutien et la production.



Phase Déploiement

Phase Réalisation Phase d’étude

Besoins(évolutions/corrections)

Spécifications

Conception

Codage

Qualification

Intégration

Pilote

Généralisation

Cycle réccurent

Figure. 17 - Cycle de vie d’un projet de montée de version

La mise en place d’un pilote est en fait l’aboutissement final du cycle de vie d’un projet de montée de version d’une application. La généralisation étant une reproduc-tion industrielle de ce qui a été fait en Pilote, qui lui est la dernière étape pour ajus-ter ce qui sera mis en production. Notre étude s’appuie sur cette étape Pilote que nous appelons « Mise en Place du Pilote » .

2.3.2. La mise en place d’un pilote (MPP)

La Mise en Place du Pilote est le point le plus interactif vis - à - vis de toutes les au-tres étapes du cycle de vie, les doubles flèches en pointillés (Figure. 18 - Cycle de vie : Étapes ayant une relation forte avec le pilote) représentent les interactions for-tes existantes avec les autres étapes. On voit aussi apparaître la notion de support et d’exploitation. Effectivement, la chaîne de soutien est activée afin de suivre les incidents qu’apporte le projet Pilote, et l’exploitation est mise à contribution afin de prendre en compte l’installation des produits livrés.



Phase Déploiement

Phase Réalisation Phase d’étude

Besoins(évolutions/correctives)

Spécifications

Conception

Codage

Qualification

Intégration

Pilote

Généralisation

Cycle réccurent

Chaîne de soutien .

Prise d’appel(Niveau 1)

Résolution (Niveau 2)

Correctifs (Niveau 3)

Utilisateurs

Production

Exploitation

Figure. 18 - Cycle de vie : Étapes ayant une relation forte avec le pilote

Dans notre périmètre, la chaîne de soutien, est décomposée en trois niveaux de ges-tion des événements :

Niveau 1 : prise d’appel et résolution des problèmes simples et connus et accompagnement de l’utilisateur sur un usage du logiciel, Niveau 2 : prise en compte des appels n’ayant pu être résolus au niveau 1, résolution des incidents connus, qualification détaillé du problème afin de le réacheminer vers d’autre support, Niveau 3 : prise en compte de problèmes ne pouvant être résolus par des actions simples : Incidents nécessitants une retouche du code, ou des manipulations sensibles des données de l’application. Ce niveau est le même qui code les évolutions dans notre cas d’étude.

Il est à noter que les relations du Pilote avec tous les acteurs du service (qualifica-tion, chaîne de soutien, conception, intégration, généralisation, exploitation, . .) ne sont actives que lorsque la phase pilote est activée ; ce ne sont pas des relations per-sistantes. Ainsi ce schéma présente le contexte de l’étude qui prendra en compte l’organisation de l’étape Pilote incluant ses acteurs directs au cours de la mise en place d’une nouvelle version.



2.3.3. La gestion des signalisations

Dans le cadre de la MPP existe un processus, qui est récurrent sur toute la durée de test de la nouvelle version, c’est la gestion des signalisations13. Ce processus sera utilisé comme exemple afin de décrire et comparer les différentes organisations, leurs niveaux de détails et leurs cohérences. Dans le cadre de ce mémoire, il y a 3 grands éléments importants à connaître concernant la gestion des signalisations :

Evénement

Incident

Information

Evolution

Bruit

Patch

Correctif

Traité

Supprimé

Redirigé Information

Tâche

Redirigé

Traité

Service continu

Figure. 19 - Signalisations : Les différents évènements et leurs traitements

Les évènements : Lors d’un projet, un certain nombre d’éléments non prévisibles vont venir impacter le projet ; on appelle en général ces éléments des évènements. Dans le cadre de notre étude certains seront appelés « signalisations » . Ces évène-ments peuvent être des incidents, des erreurs, des informations, du bruit, des de-mandes, …. Ils sont multiples, ont chacun des caractéristiques particulières et né-cessitent des prises en compte et des traitements tout aussi particuliers. Dans le schéma (Figure. 19 - Signalisations : Les différents évènements et leurs traite-ments), un exemple est donné pour un processus de traitement d’évènements, afin de présenter les différents évènements ainsi que les résultants du traitement de ces derniers :

Incident : c’est une anomalie qui a été remontée par un acteur (il peut y avoir différents acteurs et pour lesquels il faudra gérer les incidents de façon différente), Information : une demande de renseignement, un complément d’information qui nécessite d’être relevé et noté car pouvant impacter le projet, ou se transformer en incident, Évolution : un incident ou une information peuvent se transformer après qualification ou analyse en une demande d’évolution. Officiellement la

13 Une signalisation est, pour le Groupe France Telecom, quelque chose qui a fait l’objet d’une déclaration puis d’un enre-gistrement. Un incident est par exemple une signalisation.



demande d’évolution doit suivre un circuit externe à la MPP, mais il est possible que cela passe dans une corrective14, Bruit : un évènement sans intérêt.

L’ensemble de ces évènements sont traités et se transforment en :

Correctif : Une modification du programme qui corrige une erreur ou qui améliore un fonctionnement. Cette modification passe à travers un processus qualité, Patch15 : une opération qui modifie le fonctionnement du programme de façon temporaire (des fois du temporaire durable), Information : Une information à l’origine peut rester une information. Un incident peut se transformer en information s’il est exceptionnel ou sans impact ou aléatoire. Une information étant un élément qu’il est nécessaire de connaître, Tâche : Un incident ou une information peuvent se transformer en action qui nécessite par exemple une communication.

Pour finir, ces évènements peuvent être supprimés, une trace est gardée, sinon trai-tés ou redirigés, dans ce cas ils sortent du suivi et sont transmis à d’autres acteurs.

Figure. 20 - Signalisations : Processus d’escalade simplifié

Le processus d’escalade : Un évènement connu va poursuivre un cheminement particulier qui lui permettra d’être correctement traité dans un délai maitrisé. Cela signifie qu’un certain nombre d’acteurs, de compétences et d’expertises différentes sont disponibles pour ce traitement. Certains de ces acteurs ne peuvent pas être acti-vés à chaque évènement, c’est pourquoi il est nécessaire de filtrer l’évènement au fur et à mesure de sa non - possibilité de prise en compte (trop complexe). L’événement poursuit différents étages de prise en compte où plus il avance et plus les équipes en place auront d’expertise pour le traiter. C’est le processus d’escalade.

14 Une ‘corrective’ est la désignation logicielle de la correction d’une ou plusieurs anomalies. On dit « passer une correc-tive » afin d’exprimer l’action d’installer dans l’environnement de production un ou plusieurs composants logiciels qui ré-soudront les anomalies qu’ils doivent corriger. 15 Le patch n’existe théoriquement pas car non acceptable à un niveau qualité (il est ce qui n’a pas été fait en amont, donc suite à une lacune)



Projet (phase MPP) Service continu

Occurrences événements

Emetteurd’un

Evénement

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Niveau 1

Niveau 2

Emetteurd’un

Evénement

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Niveau 1

Niveau 2

Emetteurd’un

Evénement

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Niveau 1

Niveau 2

Emetteurd’un

Evénement

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Redirection

Mémorisation

Résolution

Niveau 1

Niveau 2

Mémoire des évènementsMémoire des évènements

Figure. 21 - Signalisations : Différentiation des mémoires

La différenciation des mémoires : Une des clefs de la maitrise d’un projet est d’être capable de mémoriser l’ensemble des mouvements du projet, en particulier les évènements. Cette mémorisation se fait par l’intermédiaire de plusieurs bases, en fonction du dit évènement. Incidents, demande récurrente, compte rendu, ordre de travail, information, …. Lorsqu’on travaille en mode projet, une règle est d’être complètement autonome et non perturbant pour le service continu16 ; cela signifie que les évènements du projet ne doivent pas interférer avec ceux du service continu et vice versa. Un évènement sera donc qualifié à sa détection pour savoir s’il sera pris en compte par le projet ou par le service continu. Il sera fait de même au cours de son escalade, et à la fin de sa vie (cet évènement il devra être rebasculé pour trai-tement par le service continu à la fin du projet ?). Afin de tracer les évènements, France Telecom utilise deux outils :

Genesis : Est un outil de gestion et suivi des appels. Chaque appel fait l’objet d’un enregistrement appelé « signalisation », OGA : Cet outil permet de mémoriser et suivre les enrichissements d’une anomalie. OGA est utilisé en fin de chaîne, lorsque l’anomalie a été identifiée et qu’il est possible de la corriger par un développement. Par abus de langage nous appelons un incident mémorisé sous OGA : « une OGA » .

Pour France Telecom, un incident déclaré est une signalisation, qui après qualifica-tion estimant la nécessité de le corriger, devient une OGA. Nous utiliserons de fa-çon plus large, et ce volontairement, le terme d’évènement. Ceci afin de ne pas se fermer à des possibilités d’interprétation des organisations que nous observerons. Il est à noter que le service continu est appelé « Actions récurrentes » chez France Telecom. Nous pourrons donc citer le service continu pour des explications généri-ques et Actions Récurrentes lorsque nous parlons spécifiquement de France Tele-com.

16 Est appelé Service continu (ou activités récurrentes) l’ensemble des actions nécessaire au fonctionnement d’un système donné sur une période non déterminée.



Un aspect que nous aborderons dans les exemples que nous prendrons sera l’évolution de l’événement vers une signalisation puis vers une OGA. Une OGA est un enregistrement d’un incident qui pourrait être corrigé par modification du code de l’application. Lors de l’application des correctives de la MPP, cela concerne la mise en place de correction attaché à des OGAs. Les circuits de traitement des si-gnalisations et des OGA sont très différents. Les signalisations sont traitées aux ni-veaux 1 et 2 (prise d’appel et résolution sur incidents connus) et l’OGA l’est au ni-veau 3 (nécessite une modification du code). La gestion des signalisations sera l’exemple utilisée pour étayer et enrichir notre étude.



3. BASES DE MURISSEMENT

3.1. Introduction

des éléments, bases pour mûrir la démarche, seront détaillés ici afin de présenter le raisonnement appliqué pour construire l’objectif cible : comprendre et représenter une organisation. A l’origine, mon souhait était d’utiliser un certain nombre de méthodes et concepts existants (principalement MKSM, UML et la notion de processus ISO 9000 V2000) sur lesquels je pourrais m’appuyer pour modéliser les différentes organisations (ré-elle, existante et cible). Durant la phase de mûrissement du sujet de cette étude, j’ai découvert OSSAD qui s’est avéré être une méthode graphique très adapté à la re-présentation de processus orienté organisation. Cette étude utilise donc majoritairement OSSAD. Néanmoins, il a été nécessaire de m’appuyer sur d’autres méthodes, outils et concepts, ceci afin d’avoir un système d’étude complet pour retranscrire l’ensemble de la réalisation, et surtout mûrir ma perception de l’environnement dans lequel j’allais évoluer. Il m’a semblé nécessaire d’insérer en annexe des présentations résumées ainsi qu’un avis sur les autres éléments qui ont influencé mon mûrissement. Le lecteur pourra s’y reporter le cas échéant.

3.2. Méthodologies, concepts et langage

3.2.1. Les processus et leurs représentations

3.2.1.1. ISO 9000 V2000

L’Organisation International de Normalisation (ISO) est un organisme de normali-sation mondial qui a comme objectif premier d’élaborer des normes techniques. Mis en place en 1947 par 25 pays, cet organisme est aujourd’hui représenté à travers 156 pays par des instituts donc le secrétariat général, fondé à Genève, assure la coordi-nation. « L'ISO 9000 traite du "management de la qualité", ce terme recouvrant tout ce que l'organisme réalise pour améliorer la satisfaction des clients en répondant à leurs exigences et aux exigences réglementaires applicables et en améliorant à cet égard continuellement ses performances. » [AFNOR, 2000], ces notions « d’amélioration



de performance » et « d’amélioration de la satisfaction au client » sont les deux axes principaux d’ISO 9000 V200017. Ainsi ISO permet, à tout organisme qui souhaite appliquer cette norme, de suivre des orientations à travers le respect d’exigences de qualité, sans stipuler de com-ment faire, afin de rendre générique et indépendant son application. ISO 9000 oriente la démarche des entreprises vers un certain nombre de points :

Mettre en place un système de management de la qualité, le documenter, le maintenir, Avoir un système documentaire à jour, maitrisé et utilisé, Identifier les processus nécessaires au système de management de la qualité et leur application dans tout l'organisme, Mettre en place et suivre un système d'indicateurs fiables sur les processus clefs, Améliorer continuellement ces processus, Rechercher, mesurer, et améliorer de façon permanente la satisfaction client, Manager sur la base de prises de décision motivées et argumentées, …

Figure. 22 - Cartographie simplifiée des normes autour d’ISO 9000 V2000 (Source AFNOR)

Sur la figure (Figure. 22 - Cartographie simplifiée des normes autour d’ISO 9000 V2000 (Source AFNOR)), nous pouvons voir représentés les fascicules de documen-tation AFNOR permettant d’orienter un système qualité vers ISO 9000 V2000. La partie qui concerne plus particulièrement les processus est la norme FD X 50 - 176.

17 L’ancienne version ISO 9000 datait de 1994 et n’avait pas la notion de processus ; son orientation était dans la formalisation des métho-des et du fonctionnement de l’organisme qui souhaitait l’appliquer. « Écrire ce qu'on fait et faire ce qu'on écrit" » cette maxime, résumant cette norme, ne prenait malheureusement pas en compte l’aspect satisfaction au client final. Chose faite avec la nouvelle version d’ISO 9000 V2000



En plus de l’aspect documentation, management et qualité, il apparaît que la norme ISO 9000 V2000 a évolué vers la notion de processus pour conduire son orientation qualité.

3.2.1.2. La définition de processus

Harrington le définit ainsi : "Un processus d'entreprise est une série d'activités qui, à partir d'un intrant, y ajoute de la valeur pour produire un extrant"... [Harrington, 1987]. Un processus est une collaboration de traitements élémentaires ayant comme objec-tif commun la transformation d’éléments en entrées en éléments de sortie (Figure. 23 - Présentation d’un processus). Les entrées et les sorties sont généralement des produits, des équipements, des matériaux, des informations ou des ressources finan-cières. Pour que les activités du processus se déroulent correctement, il est impor-tant d’attribuer les ressources (moyens, acteurs, . .) appropriées. Il est également important d’analyser la performance du processus et d’analyser les caractéristiques des entrées et des sorties en utilisant un système de mesure. Un processus est mis en œuvre par l’application d’un ensemble de tâches formalisées sur un document appe-lé procédure, qui lui - même est composé d’opérations (nous retrouverons plus en détail ces notions dans la description d’OSSAD).

Figure. 23 - Présentation d’un processus

Pour reprendre les termes de l’ISO 9001 version 2000 : « l’organisme doit établir, documenter, mettre en œuvre et entretenir un système de management de la qualité et en améliorer en permanence l’efficacité... Il convient que les processus nécessai-res au système de management de la qualité décrits ci - dessus comprennent les pro-cessus relatifs aux activités de management, à la mise à disposition des ressources, à la réalisation des produits et aux mesures. » Ainsi on trouve une classification en 3 grandes familles de processus :

Les processus de réalisation dit opérationnel : Les processus de support relatifs aux ressources Les processus de management orientés décision et mesure



Figure. 24 - ISO 9000 - Les trois familles de processus

L’ensemble de ces trois familles de processus s’inclut dans une organisation qui a comme objet la livraison de services à des Clients pilotés par une nécessité de satis-faction au client final (Figure. 24 - ISO 9000 - Les trois familles de processus).

3.2.1.2.1. Les processus opérationnels ou de réalisation

Ils contribuent à la réalisation du produit ou service, de la détection des besoins et attentes des clients à leur satisfaction. Ils regroupent les activités dédiées au cycle de vie de produit ou service. C’est souvent un processus métier. Exemples : La conception, la fabrication, la vente, …

3.2.1.2.2. Les processus de support

Également appelés processus de soutien, ils concernent les systèmes dédiés aux res-sources humaines (implication du personnel, formation et qualifications), et les res-sources liées aux infrastructures. Ils contribuent au bon fonctionnement des autres processus par l'apport de ressources nécessaires. Exemples : Gestion des compétences, formation et qualification des auditeurs, ges-tion de la trésorerie...



3.2.1.2.3. Les processus de management

Ils contribuent à la détermination, à l'élaboration de la politique et au déploiement des objectifs dans l'organisme. Ils sont les fils conducteurs des procès opérationnels et de soutien. Exemples : Pilotage de l'amélioration continue, Management de la qualité. . Il est important de noter que la nature des processus est fonction de l’environnement de l’entreprise et de son cœur de métier, la gestion de compétence, peut être un pro-cessus de soutien dans une entreprise industrielle mais un processus de réalisation dans une entreprise d’intérim. Dans une réflexion orientée processus, ce qu’il est important à la base c’est de maî-triser le processus en tant que tel, une fois cela fait, sa classification est relative aux orientations données au projet le nécessitant. Dans notre cas notre étude est fondée sur des processus de réalisation. Cette thèse étant orientée vers l’analyse de repré-sentation de processus dans le cadre d’une organisation, la classification ne nous concernera que pour compréhension. De plus la méthode OSSAD que nous allons utiliser permet de représenter ce qui est souhaité, dans notre cas des processus mais nous aurions aussi pu appeler cela des systèmes (aspect systémique vu précédem-ment).

3.2.2. La méthode OSSAD

La méthode OSSAD (Office Support System Analysis Design) a été choisie pour cette étude afin de représenter les organisations pour sa simplicité. L’un des argu-ments fort est que cette méthode est graphique, elle décrit comment représenter un processus, avec quels symboles, mais laisse libre l’utilisateur d’utiliser sa propre méthode pour gérer son projet. Cela correspond parfaitement à un des objectifs de l’étude qui est de pouvoir représenter graphiquement des morceaux d’organisation.

3.2.2.1. Présentation

OSSAD est le résultat d’un projet de recherche qui a été réalisé dans le cadre du programme Européen ESPRIT (European Strategic Program for Research in Infor-mation Technology) pour améliorer l’organisation des processus tertiaires en Eu-rope. Elle est appliquée depuis 1990 dans de nombreuses entreprises sous le nom d’OSSAD ou sous d’autres noms car c’est une méthode ouverte et non - proprié-taire. La maintenance évolutive est assurée par un comité international OSSAD qui siège à Genève. OSSAD est un outil de description de besoins mais surtout et avant tout un langage commun, simplifié, visuel qui permet à l’ensemble des acteurs de s’approprier la méthode très rapidement. Son objectif premier est de permettre de représenter gra-



phiquement des processus et de faire ressortir des problèmes organisationnels. Ef-fectivement, son approche n’est pas informaticienne mais orientée utilisateur. Elle est très visuelle et possède un dictionnaire limité. C’est un outil qui rend facilement possible une participation et implication de l’utilisateur. La base d’OSSAD est d’avoir une approche à travers différents modèles reliés entre eux : les modèles abstraits, descriptifs et prescriptifs.

3.2.2.2. Le modèle abstrait

Le modèle abstrait est orienté stratégie, il permet de représenter les objectifs d’une organisation. Ce modèle s’attache à représenter de façon conceptuelle les processus du système étudié. Il ne doit représenter que les caractéristiques stables, on peut parler de macro - schéma de processus. Ce modèle a l’avantage de rester très simple et facilement interprétable. Sur le Méta - modèle UML on constate l’existence de deux classes dont une qui forme une agrégation (Proces-sus) pouvant donner ainsi un ensemble de sous processus. Il est à noter sur ce Méta modèle qu’une information ne peut avoir qu’un seul processus comme émetteur, si tel n’était pas le cas, cela signifierait que plusieurs processus génèrent la même information, donc un problème d’optimisation. En complément de ce modèle, il est possi-ble d’utiliser des modèles descriptifs en réutilisant les pro-cessus déjà nommés.

Figure. 25 - OSSAD – Méta Modèle abstrait (UML)

3.2.2.3. Les modèles descriptifs

Le modèle descriptif complète le premier modèle et inclus des procédures, opéra-tions, ressources, rôles, et outils, …. Il permet une représentation transversale et concrète des activités de l’entreprise. C’est ce modèle qui va nous permettre de re-présenter l’organisation Réelle Existante à partir des organisations Ressenties. Ces modèles vont permettre de représenter le « qui fait quoi » et le « comment » du sys-tème étudié. Pour rappel notre démarche étant systémique, les représentations dé-coulant de ces modèles n’auront comme détails que ce qui nous intéresse ; ce ne se-ront que des photographies d’une partie de l’environnement dans lequel nous nous trouvons. Pour décrire ces photographies, plusieurs modèles descriptifs existent et concernent : les procédures, les rôles et les opérations.

Informations (Paquet)

Processus

-Génère

0..*

-Pro

vien

t

1

-Reçoit

1..*

-Ser

t 1..*

-Est

con

stitu

ée0.

.1

-Constitué

0..*



3.2.2.3.4. Le modèle descriptif de procédures

Le modèle descriptif de procédure permet de représenter les procédures d’un pro-cessus donné ainsi que les ressources utilisées. En restant dans la simplicité du mo-dèle abstrait, on commence à représenter les éléments opérationnels du système ci-ble.

Ressources

Procédure

-Génère

0..*

-Pro

vien

t0..*

-Reçoit

0..*

-Env

oit

0..*

Figure. 26 - OSSAD – Méta Modèle descriptif de procédures (UML)

3.2.2.3.5. Le modèle descriptif de rôles

Le modèle descriptif des rôles permet de voir apparaître l’ensemble des res-sources du système, incluant les per-sonnes qui la composent. Le lien entre les différents éléments de ce modèle est le rôle. Une représentation de ce type permet de visualiser l’organisation opérationnelle attachée aux personnes elle - même rattaché à une Unité. Afin d’apporter toute sa va-leur, ce modèle peut être appliqué après les autres, ceci afin d’arriver progressivement à se détacher d’une représentation d’usage qui est l’organigramme d’entreprise.

Figure. 27 - OSSAD – Méta Modèle descriptif de rôles (UML)

Ressources

Rôle

-Génère

0..*

-Pro

vien

t

1..*

-Reçoit

1..*

-Env

oit

1..*

Acteur Unité

-Exerce

1..*

-Est

joué

par

1..*

-Herberge

1..*

-Est

tenu

par

0..*

-Est dépendante0.

.*

-Dép

end

0..*



3.2.2.3.6. Le modèle descriptif d’opérations

Ce modèle est le plus riche car l’ensemble des composants opérationnels sont pré-sents. On remarque deux ensembles : la partie opérations et la partie tâches. Nous serons confrontés dans cette étude à la similarité des opérations avec les tâ-ches ; en fait, au final, la tâche reste un travail, tout comme l’opération. La diffé-rence est sémantique, l’opération est rattachée à un ensemble d’éléments analyti-ques (appuyer sur un bouton, pointer un état oui/non, …), la tâche à un ensemble de traitement moins mathématique, qui ressemble plus à un aspect systémique (vérifier le bon déroulement, qualifier une liste, ..). Cette différenciation est intéressante car elle permet de mieux comprendre les problématiques auxquelles nous pourrions être confrontées au cours de l’étude : une tâche peut être comprise sans être décrite de façon formelle, une opération peut être décrite sans pour autant être imaginée ou mémorisée par un acteur car elle fait partie d’un savoir implicite.

-Ser

t à

1..*

-Est

util

isé

par

0..*

-Reçoit0.

.*-P

rodu

it0..*

-Génère0.

.*-U

tilis

e0..*

-Se

déco

mpo

se e

n

0..*

-Appartient

0..*

1..*

-Dép

end

1..*

-Est constitue

1..*

-Est

util

isée

par

1..*

Figure. 28 - OSSAD – Méta Modèle descriptif d’opérations (UML)

3.2.2.4. Le modèle prescriptif

OSSAD stipule simplement que la partie prescription doit être traitée avec d’autres outils adaptés à la situation du projet. Néanmoins des études sont effectuées afin d’orienter une démarche vers la mise en œuvre d’automatismes dans l’application des opérations et procédures des modèles descriptifs. L’application la plus logique étant de faire une transition vers la mise en place d’un « WorkFlow » (automatisa-tion d’un processus par l’usage d’un outil). Ce modèle est le « Comment » de la mé-thode. Afin de permettre un dialogue cohérent avec les acteurs d’un projet, une grammaire fondée sur un dictionnaire permet de normaliser l’ensemble de ces modèles.



3.2.2.5. Le dictionnaire OSSAD

Un des objectifs de la méthode OSSAD fait qu’elle possède un dictionnaire très simplifié, afin que les graphiques puissent être assimilables facilement et rapide-ment. Dans les tableaux en annexe (1010 - Le dictionnaire OSSAD) nous vous pré-senterons les détails d’OSSAD en nous appuyant sur le dictionnaire utilisé par le logiciel OSSAD PROCESS DESIGN. A savoir que chacun peut, comme il le sou-haite, adapter ce dictionnaire, l’important étant de rester homogène durant tout le cycle projet de représentation.

3.2.2.6. Les principes OSSADIQUES

Cette méthode ne serait pas complète si elle n’était pas enrichie par une philoso-phie : Les principes d’OSSAD :

Contingence : l’avantage d’OSSAD est d’être souple dans ses représentations d’une organisation. La contingence est cette capacité à s’adapter à l’environnement dans lequel l’étude est menée, à ne pas être forcément nécessaire, Participation : OSSAD est une méthode orientée organisation, cela signifie qu’un projet OSSAD travaillera dans un environnement très humain. Or, dans tout projet où la composante maître est la personne, il est primordial d’inclure tous les acteurs impactés par le projet, ceci afin que l’ensemble des participants puissent adopter et enrichir le projet, Pragmatisme (Orientation du problème) : ne pas avoir d’à priori dans la démarche et le « problème à résoudre », rester le plus neutre possible et garder l’objectif en vue afin de ne pas s’égarer vers de multiples détails et/ou problèmes inhérents au projet, Expérimentation : OSSAD base l’expérimentation comme étant une étape de définition réelle d’un besoin. L’expérimentation peut effectivement être un prototype d’organisation permettant de valider des choix en termes de concrétisation des besoins qualifiés durant le projet, Itéractivité : la notion d’itéractivité pour OSSAD est très importante car l’ensemble de la méthode se base sur des enrichissements progressifs au fur et à mesure de l’évolution du projet. « Les tâtonnements et retours en arrière sont la conséquence logique des choix faits pour la Participation, le Pragmatisme et l’Expérimentation permanente. » [OSSAD, 1990] Agrégation/décomposition : comme nous l’avons expliqué, la méthode OSSAD est systémique, c'est - à - dire qu’elle base sa réflexion sur un système complexe avec ses processus et ses flux. Dans un environnement de ce type, il est primordial d’être capable de décomposer et/ou d’agréger les informations qui sont construite au cours du projet. Présenté sous la notion de Zoom, ces agrégations/décompositions permettent d’avoir la vue nécessaire à la meilleure réflexion. D’autres méthodes restent sur une description soit trop détaillées soit trop générales, occultant ainsi la possibilité de garder une vue macro du système tout en ayant la possibilité de projeter une petite partie cible et ses liens.



3.2.2.7. La notion de zoom

Une particularité d’OSSAD par rapport à d’autres méthodologies permettant de re-présenter une organisation est de pouvoir adapter le niveau de détail en fonction des besoins (devant des opérationnels ou devant des décideurs par exemple). C’est la notion de Zoom, qui est plus un concept qu’un outil. Cela est extrêmement intéres-sant car permet d’avoir :

Une approche généralisée (démarche générale) Une approche mixte (complétée avec une approche plus spécifique) Une approche spécifique

Chacune de ces approches, permet de « cascader » des informations (exemple : un processus est composé de plusieurs sous - processus, que l’on peut voir si on le sou-haite (par un zoom) ). L’intérêt de cette notion de zoom est de permettre de rester sur un schéma ayant le niveau de détail nécessaire à sa bonne compréhension. D’ailleurs, pour rappel, le fondement du processus ISO 9000 V2000 est d’être une boite avec des entrées et des sorties et interconnectée avec d’autres boîtes. La possi-bilité de voir l’ensemble des processus en pouvant zoomer facilement sur l’intérieur du processus permet de ne pas avoir les deux extrêmes : trop ou trop peu d’informations.






Différence b

Différence c

Alternatives

Alternatives

Alternatives

Alternatives

ModèlePrescriptif

Modèle Abstrait

Modèles Descriptifs

Figure. 29 – Macro schéma des modèles OSSAD

La figure (Figure. 29 – Macro schéma des modèles OSSAD ) nous présente les mo-dèles utilisés par OSSAD et leurs positionnements dans une progression. A partir d’un ensemble d’organisation (Figure. 16 - Différences et relations entre organisa-tions), il est possible de générer le modèle abstrait ainsi que les modèles descriptifs. Après un certain nombre d’enrichissements ces modèles pourraient permettre de créer des alternatives à l’organisation cible, et le choix de ces alternatives permettra de définir le modèle prescriptif qui sera appliqué. Le triangle permet de représenter



la notion de Zoom, ainsi que la notion d’itéractivité qui est représenté par les flè-ches entre le modèle abstrait et les modèles descriptifs. OSSAD est une méthode fondée sur une grammaire et des modèles de représenta-tion d’organisations opérationnelles (originalement OSSAD été prévue pour des or-ganisations tertiaires, qui ont donc leur productivité associée à l’outil bureautique). L’intérêt est de pouvoir représenter une organisation en étant maître du niveau de détail, ce qui n’est pas le cas d’autres méthodes qui sont plus fondées sur un tout ou rien. Son usage est excellent pour réaliser des études courtes et précises dans le ca-dre d’un audit, de préparation à la conduite de changement ou simplement de ges-tion de compétences. Dans notre cas OSSAD répond à notre besoin, pouvoir repré-senter plusieurs aspects d’une organisation.

3.3. Outils employés pour la modélisation

3.3.1. OSSAD PROCESS DESIGN

OSSAD Process Design est un logiciel édité par la société C - Log International, qui propose des solutions dans le domaine du Business Process Management. Cette so-lution, sans équivalent sur le marché, permet de couvrir tout le cycle lié à la maîtrise des processus de l’entreprise :

Modélisation des processus et procédures d'entreprise grâce au logiciel OSSAD Process Design Documentation, publication et diffusion des processus, par l’intermédiaire d’ OSSAD Process Portal Automatisation des processus grâce au logiciel WORKEY.

OSSAD Process Design est utilisé dans cette étude pour toute la phase de cartogra-phie du Pôle Mise en Place Pilote, ceci quelque soit l’organisation (théorique ou re-présentable). Cet outil très ergonomique a l’avantage de respecter la méthode OS-SAD. De par sa simplicité, il peut faire partie intégrante de la mise en œuvre d’une cartographie d’organisation. La principale raison est qu’il permet de communiquer par son intermédiaire avec n’importe lequel des niveaux hiérarchiques ou profil d’acteur de la dite organisation. Ceci est très important afin de capitaliser sans blo-cage ni mauvaise compréhension avec les équipes en place. « L’atelier Ossad permet d’éditer tous les types de graphes Ossadiens, avec le contrôle automatique de la syntaxe et des formes graphiques. Cette facilité permet d’utiliser effectivement le langage graphique Ossadien de manière participative, car le coût de mise à jour des graphes devient insignifiant et ne constitue pas un frein à l’imagination. » [C - Log, 2003]



Figure. 30 - Écran de base d’OSSAD Process Design

Les différents graphes utilisables par cet atelier sont (Figure. 30 - Écran de base d’OSSAD Process Design) :

Modèle Abstrait : qui permet de représenter une organisation de façon macroscopique à l’aide de Systèmes pouvant être imbriqués ainsi que de paquets représentant des échanges entre ces systèmes.

Figure. 31 - OSSAD Process Design – Modèle abstrait

Modèle descriptif de procédures : Représentant les procédures d’un processus donné ainsi que les ressources utilisées.



Figure. 32 - OSSAD Process Design – Modèle descriptif de procédures

Graphe des rôles : Ce graphe permet de voir apparaître l’ensemble des ressources du système, incluant les personnes qui la composent.

Figure. 33 - OSSAD Process Design – Graphe des rôles

Modèle descriptif des opérations : Fait apparaître les détails séquentiels que compose une procédure.

Figure. 34 - OSSAD Process Design – Modèle descriptif des opérations



Matrice des processus et rôles : Cette matrice permet de visualiser, par croisement, les rôles avec les processus.

Figure. 35 - OSSAD Process Design – Matrice des processus et rôles

Graphe des unités organisationnelles : Permet de représenter un organigramme avec des acteurs et unités

Figure. 36 - OSSAD Process Design – Graphe des unités organisationnelles

OSSAD PROCESS DESIGN est un outil est très simple sans pour autant perdre de richesse en termes de représentation. Sa prise en main est assez rapide, bien qu’il soit nécessaire d’avoir une certaine rigueur pour éviter des erreurs. Un grand avantage d’OSSAD Process Design est qu’il possède un certain nombre de contrôles et d’outil de synthèse. Ce logiciel s’avère être un parfait outil qui peut être utilisé rapidement et pour toute opération de qualification d’un fonctionnement simple ou complexe. De plus la Société C - Log, dans la continuité de cet outil, propose deux autres logi-ciels permettant de globaliser l’ensemble de la démarche de cartographie de d’organisation (et de processus) avec une publication interactive sur intranet (OS-SAD PORTAL) et la mise en œuvre de WorkFlow évolué directement construit à partir de la démarche effectuée avec OSSAD Process Design (WORKEY). En plus d’un outil permettant de représenter nos organisations, il était important d’avoir dans sa valise des outils méthodiques qui permettraient d’être organisé dans notre démarche, le Quoi, Qui, Où, Quand, Comment, Combien, Pourquoi en est un.



3.3.2. QQOQCCP

QQOQCCP est un acronyme de Quoi, Qui, Où, Quand, Comment, Combien, Pour-quoi. Cet outil n’a rien de particulier si ce n’est de se poser les bonnes questions. Souvent utilisé dans le cas de résolution de problèmes, il permet de ne pas se perdre dans un ensemble vaste de détails complexifiant une réflexion. Son objectif est de parvenir à une vision claire d’une situation donnée. Le QQOQCCP peut être utilisé de façon méthodique en se fondant sur des formu-laires posant les questions (Quoi, Qui, …) permettant de renseigner des colonnes associées « est, n’est pas, différences » .

Figure. 37 - QQOQCCP – Quelques questions

Cet outil définit qu’il est important de se poser les bonnes questions, et que le mieux est pour cela de se les poser toutes. Ceci afin de s’appuyer sur le principe qu’une question ou une réponse en apporte d’autres et surtout le fait de s’interroger sur un point est déjà un enrichissement de compréhension de ce point ! Dans notre étude, nous utiliserons cet outil face à une situation difficilement com-préhensible ou nécessitant d’être éclaircie.



3.4. Synthèse du mûrissement

Avant tout chose, il est important de noter qu’il y a deux manières d’aborder une étape de mûrissement : verticalement, c'est-à-dire avec une volonté d’apprentissage et de maîtrise détaillées des éléments étudiés, avec une démarche d’expertise. Ou horizontalement, en cherchant alors à comprendre les intérêts, contraintes, logiques des éléments étudiés, cela nous mets alors dans une attitude de généraliste, qui cherche a avoir une vue d’ensemble d’un sujet donné. C’est en tant que généraliste que nous avons abordé ce mûrissement. L’ensemble des éléments présentés dans ce chapitre ont comme objectif d’alimenter plusieurs aspects de cette étude :

Les sources d’inspiration permettant d’élargir une ouverture de réflexion, et de comprendre l’environnement d’étude :

ISO 9000 V2000 : La notion de processus doit être maitrisée, c’est une condition permettant de mieux appréhender ce projet.

Des méthodes de modélisation permettant de répondre au mieux au besoin OSSAD : Est la méthode de représentation des processus d’organisation et de leurs fonctionnements qui est utilisé dans cette étude.

Les outils utilisés dans le cadre de l’étude QQOQCCP : Il est nécessaire de se poser des questions pour mieux appréhender un fonctionnement. Cet outil est un bon entrainement à l’acquisition d’un reflexe valorisant toute étude d’analyse. ISHIKAWA : Surtout utilisé afin de reconstruire un ensemble de cas particuliers. Dans le cas où un processus a plusieurs manières (plusieurs procédures semblables) et qu’il faut retrouver le fonctionnement adapté, le diagramme de causes à effet apporte une grande facilité de reformulation. (Annexe 11.4 - Ishikawa.) La Loi de Pareto : Il est important de considérer le détail comme étant un objet d’enrichissement d’un objectif et non comme une nécessité. Dans une étude systémique, le détail doit être considéré avec attention, au risque de rendre des représentation/explications indigeste et inutilisable. (Annexe 11.5 - La Loi de Pareto)

D’autres éléments ont été utilisés indirectement pour cette étude, ceci principale-ment afin d’influencer une méthode de travail et de mûrir l’orientation qui devait être prise. Ces méthodes/outils et concepts sont résumés en annexe, pour informa-tion et renvoi éventuel. Une fois tous les éléments regroupés pour construire l’étude, il est nécessaire de dé-finir une démarche de base qui sera notre fil conducteur. Il est à noter qu’il est très difficile de proposer une démarche précise car l’environnement, systémique, aura une appréhension directement liée à la vision qu’en aura l’auteur des représenta-tions. Il y a des grandes étapes à suivre, ensuite il faut s’adapter avec bon sens à son environnement. Aucune organisation opérationnelle n’est semblable car très dépen-dante de ses composants variables.



La première étape directement nécessaire à la construction des représentations est le recueil des informations, qui se fait en traçant et mémorisant l’ensemble des li-vrables, acteurs, rôles, activités, éventuellement un certain nombre d’opérations. Ce recueil peut être fait seul, et nécessite d’être détaillé et arrangé en terme de famille de regroupement. L’objectif de cette étape est de dégrossir le contexte de l’étude et de s’enrichir de 80% du nécessaire. La seconde étape concerne la partie construction ; à l’aide des éléments recueillis, la construction s’opère en appliquant les différents modèles (Abstrait, descriptifs, . .). L’ensemble des modèles doit permettre d’avoir une représentation cohérente du périmètre étudié. Dans le cas d’une représentation de l’organisation théorique, il est souhaitable de réaliser en premier les représentations abstraites. Ceci car l’organisation théorique suit une stratégie, qui par définition est générale. Vouloir représenter quelque chose de global de façon détaillée risque d’apporter une infinité de combinaisons. Par contre, dans le cas des représentations des organisations exis-tantes, l’application de modèles descriptifs sera plus appropriée car collant bien avec les détails de la situation existante. Attention cependant à rester assez généri-que pour ne pas se perdre dans une multitude de détails qui rendrait la lecture im-possible. La troisième étape est l’analyse ; beaucoup plus collégiale, elle nécessite d’affiner, par des entretiens, l’ensemble des schémas et d’enrichir le recueil effectué au pré-alable. Ces entretiens seront croisés avec plusieurs acteurs afin que l’organisation réelle soit une représentation concrète convenant à la majorité des acteurs. C’est naturellement à travers cette étape que l’on pourra voir apparaître les incohé-rences et / ou le delta entre l’organisation « existante » et « théorique ». Ces différences permettront de prendre conscience de certaines situations, d’apporter d’éventuelles corrections et de définir l(es) ’organisation s) cible(s).



Réalisation

Etude






théorique


existante



Méthode

Figure. 38 - Organisation du document – Réalisation

Dans le cadre de notre réalisation, nous allons présenter trois organisations de notre service et détailler un cas particulier qui est la gestion des signalisations. Notre objectif étant de comprendre le nécessaire permettant d’apporter des critiques constructives. Il est important de considérer que ces trois organisations sont les mêmes mais vues selon des angles diffé-rents. Elle traite des mêmes processus, des mêmes rôles, peuvent avoir les mêmes problè-mes, elles ne diffèrent que par leurs objectifs. Cette subtilité est la clef de la compréhen-sion de cette partie.



4. L’ORGANISATION THEORIQUE – (AGATHONE)

4.1. Présentation

La méthodologie Agathone a été défini par France Télé-com dans le cadre des programmes ARCHIMEDE (nor-mes organisationnelles relatives à l’architecture fonc-tionnelle) et ARISTODE (normes organisationnelles relatives à l’architecture technique). Cette méthodologie oriente un projet vers une réflexion mixte sur deux acti-vités d’ingénierie transverse : l’analyse métier qui impli-que une étude fonctionnelle et l’architecture techni-que qui implique une étude technique L’ensemble de ces études effectuées simultanément donne l’enrichissement d’un cahier des charges qui sera utilisé pour les phases de conceptions et réalisation.

Figure. 39 - Différences et re-

lations entre organisations

AGATHONE suit un cycle de vie et est organisée d’une part en processus de réali-sation reprenant chacun des métiers du système d’information, et d’autre part en ja-lon et phases. Le croisement de ces deux systèmes donne des activités nommées modes opératoires.

4.1.1. Le cycle de vie Agathone

Le cycle de vie de projet décrit de façon statique les différentes phases nécessaires à la réalisation d’un besoin. Dans le cas d’AGATHONE elles sont délimitées par des jalons.





Organisation Nécessaire (théorique)

Différence b

Différence c



Figure. 40 – AGATHONE - Le cycle en Y

Dans ce cycle, on aperçoit à travers les différentes étapes la forme du cycle en Y et la fusion des analyses fonctionnelles et techniques pour aboutir à la conception. Ce cycle ne prend pas en compte la notion de pilote et de généralisation, (mais ils sont traités dans la méthodologie AGATHONE), il s’arrête au jalon J1a qui corres-pond à la construction du logiciel. Les autres jalons (notamment celui de la MPP) sont visibles sur le graphe des processus et phases AGATHONE.

Figure. 41 - AGATHONE – les processus et phases

AGATHONE est composé de 6 phases majeures :

Études : Première analyse du besoin, permettant d’avoir une réponse concrète à une expression de la maîtrise d’ouvrage et incluant un chiffrage global du coût de réalisation, Mûrissement : L’étude ayant été acceptée il est nécessaire de définir au mieux l’ensemble des éléments permettant d’initier une conception, le mûrissement est le cadrage fonctionnel et technique du besoin, Conception : Élaboration des livrables définissant précisément le produit à fabriquer (spécifications techniques et fonctionnelles), Fabrication : Élaboration des produits, qualification, tests et recettes, intégration des produits, et Mise en Place d’un Pilote, Généralisation : Déploiement sur l’ensemble du périmètre sélectionné pour le projet. Transfert de compétence du projet aux équipes du service continu, Utilisation : Usage du/des produit (s) en environnement de production. La phase utilisation se termine avec la fin de vie de l’objet dont il est question (logiciels, …),



Il est à noter que ces processus comprennent des sous - ensembles d’activités indé-pendants non représentés sur le tableau ; ainsi un processus peut démarrer très tôt dans le cycle de vie du projet afin, par exemple, de permettre à ses équipes de mon-ter en compétence. Mais ce processus ne sera véritablement actif que bien plus tard. C’est le cas de la mise en place pilote qui commence au J - 1 pour finir au J2a, soit une longue période. Ces phases sont parcourues par 10 processus AGATHONE qui sont orientés vers les métiers des systèmes d’information. Nous détaillerons plus précisément le pro-cessus de la Mise en Place Pilote par la suite.

Analyse Conception, Construction du logiciel, Qualification des logiciels, Exploitabilité, Management du projet, Maintenance, soutien et amélioration des produits et services (MSAP), Gestion de configuration, Acquisition, Mise en Place Pilote et Déploiement (MPP), Instruction des demandes d’évolution du système d’information

4.1.2. La mise en place Pilote

Nous avons déjà commencé une présentation de la Mise en Place Pilote (en page 38). Cette partie va permettre de positionner ce processus dans la méthodologie AGATHONE.

Figure. 42 - AGATHONE – les relations du processus MPP avec les autres processus



Il est intéressant de constater que le processus MPP touche presque tout le cycle AGATHONE. Théoriquement, les phases non impactées sont la Généralisation et l’Utilisation

Figure. 43 - AGATHONE – Les regroupements du processus MPP

La figure (Figure. 43 - AGATHONE – Les regroupements du processus MPP) re-présente les modes opératoires du processus MPP ainsi que les livrables nécessaires à sa bonne réalisation et qui sont : 1 Critère de sélection du site pilote : Afin de choisir au mieux les sites qui vont héberger le pilote, il est nécessaire de connaître les critères de choix, qui sont dé-pendants de la version du logiciel et de l’environnement (projet en cours, périodes sensibles, …). 2 Scénario de MPP : Le scénario de MPP définit de l’organisation de la MPP, ceci en terme d’acteurs mais aussi de livrables. 3 Plan de travail commun (PTC) : Le PTC liste l’ensemble des tâches à réaliser durant la MPP, l’objectif est que ce document soit consultable par les autres mem-bres de l’équipe afin d’être le référant du projet de MPP. 4 Planning MPP : Liste toutes les dates clefs de la MPP (réunions, jalon, instal-lation, livraisons, …) 5 Reporting MPP : L’état d’avancement, la listes des contraintes rencontrées et les actions en cours ou à venir. 6 Dossier MPP : Le dossier de MPP reprend l’ensemble de l’organisation, ainsi que la description des grandes étapes, l’équipe qui est activée, les contraintes et ris-ques, …. C’est un document qui doit résumer l’ensemble de la MPP.



7 Contrat MPP ; Le contrat est une version allégée du dossier de MPP. Il est en-voyé au (x) site (s) retenus (directions régionales) pour signature de bon pour ac-cord. 8 Support de communication : Les supports de communication présentent la version ainsi que les modifications d’usages qu’elle apporte. 9 Comptes - rendus de réunion : Les comptes rendus de l’avancement de la MPP, des signalisations, … 10 Produits de formation et supports associés : Dans le cas d’un grand change-ment au niveau de la version, il peut être nécessaire de faire de la formation directe aux utilisateurs. Dans ce cas les livrables seront des supports de cours, cd - rom d’auto formation, … 11 Compte rendu de la réunion de « GoNoGo » : Avant de partir en MPP un état des lieux est fait afin de savoir si tout est livré, qualifié, intégré et prêt à être instal-lé. Si ce n’est pas le cas des réserves seront émises, réserves qui devront être levées pour pouvoir partir en MPP. 12 Dossiers de contrôle : Les dossiers de contrôle présentent les évolutions et corrections apportées par la version afin que les utilisateurs du site Pilote puissent les suivre et vérifier le bon fonctionnement du logiciel. 13 Documents utilisateurs : Tous les modes opératoires à destination des utilisa-teurs finaux. Cette documentation est enrichie et validée au fil de la MPP afin d’être livrée durant la généralisation. 14 Comptes rendu des contrôles : Ces comptes rendus reprennent l’état d’avancement du dossier de contrôle. 15 Synthèse des signalisations : Un tableau reprenant l’ensemble des signalisa-tions (incidents, évènements particuliers, durant la MPP. 16 Bilan de la MPP : La synthèse du déroulement de la MPP ; tous les acteurs in-cluant le (s) site (s) pilote (s) participent à ce bilan. 17 Compte rendu de réunion de démarrage de la généralisation : Synthèse de la réunion de GoNoGo qui trace les grandes contraintes rencontrées, les points positifs et négatifs ainsi que les actions de vigilance pour la généralisation. En plus de ces regroupements (au nombre de 17, et avec 17 livrables) le processus MPP est expliqué à travers 7 modes opératoires qui décrivent chacun une activité : relations avec le site pilote, qualification utilisateur, formation métiers, qualification MOE SI, installation, communication, et avancement et suivi. Ces modes opératoi-res présentent des fiches procédures qui expliquent le travail à réaliser ainsi que les livrables associés. Ces dernières sont, pour chaque mode opératoire, regroupées par phases (phase de mûrissement MPP, phase recherche du site pilote, phase de prépa-ration du déploiement, phase d’initialisation du site pilote, phase d’installation, phase de suivi et bilan, phase de post - bilan).



4.2. Les processus

Pour représenter AGATHONE, il a été important de reprendre l’ensemble de la do-cumentation existante et unitairement de reconstruire chacun des sous - processus. La méthode du groupe France Telecom a comme plus petit niveau de processus ce-lui de la MPP. Si nous entrons dans le contenu de ce processus alors AGATHONE parle de Modes opératoires et de Phases. Les modes opératoires étant composés de sous - modes opératoires qui sont des regroupements de tâches. Nous les appelle-rons donc des procédures puisque cela suit la même définition qu’OSSAD. Cette étape de représentation a été très difficile car AGATHONE, à travers sa do-cumentation ne nous propose que des fiches de mode opératoire d’activité et des macros schémas par processus projet et par activité, mais sans présenter les liens en-tre les différents systèmes. Ne sont pas représentés, non plus, de façon directe, les liens qu’il peut y avoir entre chacun des modes opératoires ni entre chacune des phases. Il est nécessaire de reprendre chaque descriptif et faire apparaître les liens, quand ils existent. Pour avoir la meilleure visibilité, nous avons croisé l’ensemble des sous - processus AGATHONE MPP par phase et par activité afin de reconstruire les paquets qui lient chacune de ces briques. Cela donne deux modèles abstraits. L’un par phase et l’autre par activité. Pour rappel, (4.1.2 La mise en place Pilote) nous avons comme objet pour notre ré-flexion :

Le processus AGATHONE MPP Composé de 17 regroupements fonctionnels

Expliqué par 7 modes opératoires (pour 7 activités) Composé de 7 regroupements temporels (appelé des phases)

La première étape a donc été de représenter des systèmes qui se rapprochent le plus de ce qui est proposé par AGATHONE. C’est pourquoi nous nous sommes appuyés sur la documentation qui est composé majoritairement par les modes opératoires des activités de la MPP. Nous avons ensuite projeté une représentation par phase, afin de nous rapprocher le plus possible d’une méthode de travail naturelle : progresser étape par étape en sui-vant le temps. Afin de ne pas refaire une méthodologie déjà existante, nous n’avons pas détaillé l’ensemble des schémas, mais avons juste présenté un résumé. L’intérêt de l’étude étant de représenter différentes organisations pour en faire ressortir des points d’attention, pas de les expliquer dans le détail (pour rappel, notre démarche est sys-témique et non analytique). Il est à noter que lors de la représentation OSSAD d’AGATHONE, il n’a pas été possible d’imbriquer des processus les uns dans les autres de façon naturelle. Ceci est dû principalement à la présentation très descriptive et segmenté de la méthodo-logie en question. On peut dire que le processus MPP contient d’autre processus comme par exemple : ORGANISATION et QUALIFICATION, le contenu de ces



derniers est trop hachuré pour pouvoir constituer des niveaux de profondeur. C’est à dire qu’il manque trop d’informations en termes de lien entre les différents proces-sus (quel est le commencement et quels sont les liens entre processus ?). De même, concernant les phases que nous avons créées, pour avoir une représenta-tion chronologique, il n’est pas possible d’avoir plusieurs niveaux de détails en ter-mes de processus, ceci car ces phases utilisent des morceaux des précédents proces-sus. Ces zooms seraient incohérents car composés de petits morceaux d’opérations, le tout avec quelques rares liens entre eux. Par soucis de lisibilité et afin de ne pas surcharger le corps de l’étude, l’ensemble des schémas et détails associés se trouvent en annexe (13.1 Voir pour les descriptifs l’annexe 13.1 - Descriptif des processus AGATHONE, et pour les schémas l’annexe 113.2 - Représentation OSSAD des processus AGATHONE MPP). Lors de l’aperçu que le lecteur pourra avoir de ces descriptifs et schémas, il conviendra de noter que l’organisation théorique, dans le cas d’AGATHONE, est très détaillé et organisée sous forme de procédure (notion d’activités). Dans la partie schémas, il pourra être remarqué l’absence de liens entre les différents phases et ac-tivités. Ces caractéristiques particulières rendent cette organisation difficilement appréhendable de façon globale et linéaire (suivre son déroulement pas à pas), cet aspect, entre autre, sera décrit dans le chapitre suivant.

4.3. Les phases18

AGATHONE base sa chronologie sur la notion de jalon19, on parle de J0, J1, J2, … La MPP, comme nous avons pu le voir sur le schéma : Figure. 43 - AGATHONE – Les regroupements du processus MPP, s’étend du J - 1 au J2. Les phases que l’on peut rencontrer dans les documentations AGATHONE et sur la partie qui nous inté-resse sont : mûrissement, conception, fabrication. Ce sont des phases de dévelop-pement des produits logiciels qui sont difficilement appropriées pour classer les procédures de la MPP. Par contre, en entrant dans les descriptifs des modes opératoires, sur les synoptiques de description de l’organisation de ces derniers nous avons trouvé des intitulés de phases appropriés et qui permettent d’ordonner au mieux les tâches de la MPP. Ces phases sont : Mûrissement, recherche site pilote, préparation du déploiement, initialisation du site pilote, installation, suivi et bilan, post bilan. Au vue du grand nombre de schémas, le lecteur pourra trouver en annexe l’ensemble des synoptiques qui ont été réalisés à partir des documents AGA-THONE. Leur description détaillées apporte très peu d’éléments, seule leurs cons-truction et la vue d’ensemble réalisée a permis de mûrir l’organisation théorique.

18 La phase est la principale composante de regroupement d’étapes sur le cycle de vie d’un projet, elle intègre une notion de temps (un positionnement dans le temps). 19 Les jalons sont noté J0, J1, J2, … J pour jalon et le numéro pour une séquence



4.4. Les rôles

AGATHONE associe les acteurs aux rôles, cela signifie que le seul rôle qui concerne directement la mise en place pilote est le pilote de la MPP. Ce pilote est appuyé par d’autres acteurs (pilote de qualification, installateur, …) ; ces rôles se-ront présentés dans le chapitre de l’organisation existante. Ils sont les mêmes que l’organisation théorique.

4.5. Un exemple : La gestion des signalisations

Un aspect intéressant de la MPP est la gestion des incidents. Dans le cadre d’un pi-lote, l’objectif majeur est de valider la mise en place d’une nouvelle version, de cor-riger les dernieres « erreurs » et d’ajuster la version en fonction des remontées dé-tectées.

Figure. 44 - AGATHONE – Les activités de suivi des signalisations

AGATHONE ne présente que quelques enchaînements concernant cette partie qui se trouve dans la phase Organisation, avancement et suivi. Il est question d’organiser la gestion des signalisations, de les gérer, et de les clôturer. Ce niveau de détail est suffisant pour une méthodologie projet d’entreprise, par contre, elle né-cessite un enrichissement de détail lorsque l’on est directement confronté à sa mise en place et réalisation. Nous verrons par la suite la nécessité de creuser ce processus, afin de détecter des incohérences et donc de proposer des améliorations. A ce stade ce que nous pou-vons dire est qu’Agathone dit qu’il est nécessaire de gérer les incidents et de les clô-turer. Ceci sans aucun détail supplémentaire. Nous verrons dans le chapitre suivant que l’organisation existante est fortement semblable à l’organisation théorique. Nous essaierons de faire apparaître les élé-ments qui ne sont pas semblable, ou qui le seraient peut être un peu trop.



5. L’ORGANISATION EXISTANTE

5.1. Présentation

L’organisation existante est beaucoup plus simple à décrire que la précédente, ceci de par le fait :

qu’elle concerne une population travaillant dans un unique domaine (études informatique), n’intervenant que sur une partie du macro - processus Agathone et qu’elle a adaptée son organisation à un fonctionnement plus simple que celui proposé par Agathone20.

Figure. 45 - Différences et re-lations entre organisations

L’organisation existante ne représente que ce qui est réellement présent et utilisé. Néanmoins, elle est la plus intéressante car celle qui nécessite d’être comprise pour connaître le point de départ d’éventuelles améliorations. Appliquer des concepts ou orienter des organisations vers des cibles théoriques, sans connaissance de l’existant peut avoir des conséquences difficiles à gérer. Afin d’arriver à une cible synthétique et lisible, notre démarche a été, dans un pre-mier temps, de lister l’ensemble des éléments que nous pourrions avoir. Il a été en-suite nécessaire d’organiser ces éléments de façon cohérente et exploitable pour constituer un vivier d’informations attaché à la mise en place pilote : la liste de composants21.

20 Pour rappel l’organisation existante est tributaire d’un grand nombre de facteurs difficilement industrialisables. C’est, à l’opposé de l’organisation théorique, qui est théorique et mathématique, une organisation malléable et adaptative aux com-posants qui l’enrichissent, composants humains et complexes, … systémiques. 21 Voir : 12 - Complément : Recueil des composants


Organisation existante



Différence c



Acteurs (pôles ou famille) Réunions

Livrables Outils

Mise en place Pilote

MOE CRISTAL

ContratScénario

MOA

lancement signalisation

Excel 26D

WebDoc

Direction de Service

TMA CRISTAL

Productioninformatique

Chaîne de soutien

Généralisation

Supportmétier

Qualité

Les utilisateurs(DR)

Plan de travail communPlanning

ReportingPlan de mobilisation

AnnuaireDossier MPP

Ordre d’installationFil conducteurMPP Metre

BilanSignalisation

Présentation contributeurs

Présentation utilisateurs

Fiches de testFiches croisière

Doc. utilisateurOuverture file mpp

Temps de réponse

Sonde Vantage

OGA

Genesis

lancement installationlancement MOE

Présentation à la DRPrésentation

aux Contributeurstests sur la version

suivi des signalisations

suivi de la MPP

validation Ordre d’Installation

suivi de l’installation présentation

fiches croisièreprésentation

fiches de tests

présentation organisation

Figure. 46 – Ensembles des composants de la MPP

Le diagramme de cause à effet22 de la Figure. 46 – Ensembles des composants de la MPP, représente la synthèse de la démarche de recensement des différents compo-sants de la MPP. Les 4 branches principales représentent chacune un ensemble dont le contenu est nécessaire à la bonne réalisation de la MPP : acteurs, réunions, livra-bles, et outils. Au niveau processus, nous avons décidé d’effectuer des regroupements par phase, ceci afin d’avoir une vue séquentielle de l’organisation, qui colle parfaitement avec la réalité de vie du projet de MPP. Les phases se comportant dans ce cas comme des processus, avec leurs entrées et sorties.

22 Voir : 11.4 - Ishikawa



5.2. Les phases et processus

Au sein de la MOE, on ne parle pas de phases de façon formelle, le projet évolue en fonction de livrable ou d’étapes. Les intitulés donnés ici l’on été afin d’arriver à re-grouper un ensemble d’actions pour arriver à livrer des représentations lisibles. Dans l’organisation existante, la MPP se construit au fil de l’eau, sur la connais-sance des personnes, en s’appuyant si besoin sur la référence AGATHONE, et plus particulièrement sur des documents préformatés, et listant, de façon exhaustive les tâches à ne pas oublier. Les listes qui suivent présentent les différentes phases ainsi que les moments forts de ces dernières. L’important est de noter que pour appréhender une organisation il faut être capable de la visualiser par sous-système. Nous faisons donc des regrou-pements de sous-système que nous appelons phase. Dans cette partie, ainsi que la même partie des chapitres suivants, nous chercherons à présenter ces phases dans leurs ensembles afin d’apporter une sensibilité sur la nécessité de raisonner par ensemble et non par détails.

Préparation Constitution de la version / Montée en puissance / Choix du site pilote Rédaction du dossier, contrat, … Constitution des packages logiciels, test d’installation, rédaction de l’ordre d’installation.

Figure. 47 – (Organisation existante) – Phase préparation



Installation GoNoGo23, ordre d’installation, plan de mobilisation24, Réunion de suivi de l’installation et d’utilisation, …

Figure. 48 – (Organisation existante) – Phase installation

Suivi et bilan Suivi des signalisations et des correctifs, préparation du bilan Bilan25, clôture des signalisations, préparation du jalon « J2 »

23 GoNoGo est une expression souvent utilisée avant de lancer un projet ou une phase d’un projet, cela signifie « nous y allons ou non », la réponse à cette question se fait après qu’un collège de décideurs ait passé en revue une liste de point et ait statué s’il y avait présence de points bloquants ou non. 24 Le plan de mobilisation regroupe toutes les informations de support, d’intervention, d’astreinte pour les équipes néces-saire à une opération en environnement de production (par exemple : installation d’un logiciel) 25 Le Bilan est la réunion qui termine une phase ou un projet. Le GoNoGo le commence, le Bilan le termine. En général, les mêmes listes sont utilisées.



Figure. 49 – (Organisation existante) – Suivi et bilan

Pour rappel ce qui est intéressant à noter est que les personnes qui travaillent sur la MPP ne se basent pas sur un fonctionnement par phase mais en fonction des jalons. A la question où en est ce projet, la réponse sera au J1, J2, ... (La référence étant le jalon d’AGATHONE). L’inconvénient est que ces jalons n’offre pas de niveau de détails fort : être avant le J2 signifie être entre le tout début du projet dans son en-semble (analyse des besoins, accord de budget, …), et au début de la généralisation, c’est assez vaste. Lorsque les acteurs de la MPP nécessitent donc de se positionner temporellement sur le projet, à part les jalons, ce qui est utilisé est souvent la tâche à venir et plus particulièrement la livraison de produits logiciels (ce qui sera mis en paquets et ins-tallé sur les machines). C'est-à-dire à la question ; « où en sommes-nous du pro-jet ? » la réponse est : « avant le J2 » (positionnement sur Jalon), ou alors : « avant la livraison des produits livrables » (positionnement sur un évènement de type tâ-che. Cela ne pose pas de problèmes particuliers car les acteurs se positionnent chacun en fonction de leur rôle. L’inconvénient est que chacun ayant ses repères, et ces der-niers étant semblables (cas des produits livrables), les appréhensions de l’avancé du projet divergent. Car chacun n’a pas forcément la même vue sur ce qu’il y a à faire. Une bonne communication est nécessaire pour ajuster et uniformiser la vue et le po-sitionnement sur le projet de chacun. Nous verrons que cela pourra être amélioré en portant, entre autre, une attention particulière aux rôles.



5.3. Les rôles

Pour rappel, il est important de bien comprendre qu’un acteur a un ou plusieurs rô-les attribués qui peuvent varier au fil du temps, et qu’un même rôle peut être partagé par plusieurs acteurs.

Rôle

Acteur

Figure. 50 – (Organisation existante) – UML des rôles

Dans le cadre de l’organisation existante, les rôles sont ceux qui sont décrits dans AGATHONE. Ce sont ces rôles que l’on retrouve regroupés dans l’organigramme de la MOE de CRISTAL (Figure. 51 – Organisation et positionnement de la MOE CRISTAL) et celui représentant les équipes de la MOE CRISTAL (Figure. 52 – Equipes de la MPP). Ces rôles sont assez nombreux (certains interviennent réguliè-rement et d’autres très rarement). Les principaux sont pour ceux qui sont les plus impliqués : le pilote de la MPP, le chef de projet version, le chef de projet de la Di-rection régionale, le pilote de qualification. Les autres rôles sont moins impliqués mais nécessaires : Gestionnaire des environnements techniques, Responsable des tests, Qualificateur du SI, Expert fonctionnel, Expert technique, Concepteur, Sup-port Études, Accompagnateur métier (SPOT), la MOA, packageur logiciel (Kim-meur) – Intégration, Pilote d’exploitabilité – Exploitation, Réalisateur développeur (Sopra), Réalisateur développeur (Ordo_DR), …26.

26 Les rôles les plus importants sont présentés en annexe (12 - Complément : Recueil des compo-sants de la MPP)



Figure. 51 – Organisation et positionnement de la MOE CRISTAL

Avec une vue macro et au niveau de l’organisation globale des équipes de la MPP et leurs positionnements dans l’organigramme de SIClient, on peut noter deux grands aspects intéressants : 1) La transversalité entre le Direction du projet représentée par le chef de projet ver-sion (figure ci-dessus), 2) L’association un à un entre les pôles et les rôles impactés par la MPP. Concernant la transversalité, nous remarquons que le point d’accroche des deux domaines de responsabilités est la DP Commande - Livraison, et qui situe les deux chefs de projet au même niveau hiérarchique. On peut en déduire que ces rattache-ments permettent de garder une organisation « administrative » orientée vers le ma-nagement d’une équipe opérationnelle qui met à disposition d’un chef de projet, pour un événement temporel, une partie de ses ressources.



Figure. 52 – Equipes de la MPP

Sur un périmètre élargi, hors MOE CRISTAL qui prend en compte la conception, le pilotage du développement, la qualification, la gestion du référenciel, la MPP im-pacte un grand nombre d’entités. De l’intégration pour valider la compatibilité tech-nique des produits logiciels qui vont être insérés dans la production informatique, à l’exploitation qui prend en compte le suivi de l’application modifiée, au support qui soutient la période de mise en place et le récurrent une fois la MPP terminée. Cette chaîne de soutien est une des composantes majeurs en terme d’organisation pour la bonne maitrise de la mise en place pilote (dont l’objectif est de valider une nouvelle version sur un périmètre défini). L’organisation existante suit à l’identique l’organisation théorique. Les rôles sont nombreux et bien définis. De même chaque acteur a un rôle, et on remarque qu’en général, il y a unicité entre rôle et acteur.

5.4. Un exemple : La gestion des signalisations27

Dans le cadre de la mise en place d’une nouvelle version sur un pilote, la gestion des signalisations est un processus clef car, une fois les opérations d’installation terminées, il est le point focal du projet. La gestion des signalisations, dans le cadre de l’organisation existante, est un processus qui est cantonné au suivi des incidents remontés de la mise en place pilote.

27 Il est à noter que nous n’avons pas intégré 100% des possibilités dans les schémas de ce processus, mais uniquement ceux qui nous paraissaient pertinents pour notre analyse.



Figure. 53 - Signalisations : Processus d’escalade simplifié

Nous avons vu au chapitre 2.3.3 - La gestion des signalisations, les différents types d’évènements ainsi que leurs transformations. Il est important de noter que la mé-thodologie AGATHONE ne parle que de signalisation d’incidents. C’est aussi ce que nous constatons dans le cadre de la gestion des incidents de la MOE Cristal. Dans l’organisation existante, la gestion des signalisations est telle que décrite dans l’organisation théorique. Il n’y a pas de différences majeures.

Figure. 54 - AGATHONE – Les activités de suivi des signalisations

Ce qui est présenté de façon simple sous AGATHONE, donne, en réalité un chemi-nement plus détaillé qui prend en compte deux étapes de qualification :

Déterminer si la signalisation entre dans le cadre de la MPP : Si ce n’est pas le cas alors elle passe dans le périmètre de gestion AR (Actions récurrentes : qui correspond au service continu, et donc hors projet). Déterminer le type de signalisation : Avant d’être transformé en OGA, il est nécessaire de reproduire et de qualifier le problème. Dans la majorité des cas, une signalisation se transforme en OGA, mais il est possible qu’elle soit simplement clôturée.



Figure. 55 – Processus existant de gestion des signalisations28

Dans le schéma ci - dessus, nous apercevons les étapes d’évolution d’un évènement, qui ensuite devient signalisation puis OGA. Ce schéma présente trois grandes famil-les de transformation, les signalisations, les OGA et les correctives. Ensemble très cohérent sur papier, le fonctionnement l’est moins dans ses subtilités et sur le terrain. Effectivement, que se passe - t - il si une signalisation n’est pas vraiment un incident, si c’est un effet de bord d’une évolution qui modifie les usa-ges des utilisateurs ? Cela doit il être corrigé dans la MPP (effet de bord) ou passée en AR (ancien problème) ? Qu’en est - il des incidents non reproductibles qui peu-vent être dus à une mauvaise manipulation ? Ou même qu’en est il d’une évolution qui après pratique se révèle incomplète et nécessite de bénéficier d’une extension d’évolution ? En résumé, qu’en est - il des cas particuliers, officieux ou officiels ? La méthodolo-gie AGATHONE ne parle que du suivi des signalisations. Ces dernières ne peuvent

28 (xxx) abcdef = xxx le type d’événement (SIGnalisation, OGA, CORrection, abcdef l’action. Exemple : (SIG) Transfor-mation OGA = L’évènement signalisation est transformé en OGA.



être que des anomalies déclarées et prise en compte dans le circuit normalisé. Dans la réalité il existe d’autres circuits pour d’autres types d’informations, mais ces der-niers sont traités différemment, des fois avec des zones de flous qui se maitrisent par des échanges croisés et informels entre acteurs. On ressent, dans l’ensemble, une volonté de coller à AGATHONE, mais pour ce dont AGATHONE traite. Pour le reste, il n’existe pas de formalisme, alors chacun s’est adapté, souvent en utilisant la voix pour communiquer, ce qui offre une sou-plesse mais aussi des risques de mauvaise compréhension, de perte d’information, de bruits, …. . Une règle d’or lorsque l’on travaille en mode projet est d’avoir un fonctionnement complètement dissocié du service continu. (6.2 - Les phases et processus). Les limi-tes entre les équipes MPP (Projet) et les équipes AR (fonctionnement service conti-nu) sont assez floues ; ce qui présente un risque de complexification des occurren-ces de cheminement d’évènement (mauvaise qualification ou qualification tardive, effet ping - pong entre les deux services). Ici aussi il est généré un certain nombre d’échanges afin de réaliser une qualification du moment, des fois en urgence. Enfin pour finir, l’équipe MPP est chargé du pilotage de cette chaîne d’évènements, elle s’appuie pour cela sur :

une équipe qui gère les signalisations en entrée (Niveau 1 : enregistrement de l’incident, et niveau 2 : résolution évoluée d’un incident), une équipe qui gère le suivi des OGA, l’équipe du service continu qui gère les signalisations et OGA au fil de l’eau.

La grande difficulté de cet ensemble se joue sur l’aspect coordination, considérant qu’excepté les niveaux 1 et 2 qui sont directement liés à la MPP ; le niveau 3 a un fonctionnement complètement autonome, en tant que service continu et en mode projet. Les limites entre ce qui touche la MPP, ce qui relève d’une future version (les cycles de montée de version se chevauchent), et ce qui relève du support d’ancienne version peuvent bouger et des fois se chevaucher ou ne plus se rejoindre. Considérant qu’une information appartenant à la MPP peut voyager entre ces diffé-rents niveaux, il faut être capable de la suivre et d’être sûr qu’elle sera prise en compte tout le temps. Cela implique, parfois, une coordination sportive. La qualification des signalisations se fait sur un périmètre géographique, il est donc aisé de relever toutes les signalisations touchant l’application CRISTAL puis de les qualifier. Pour le service continu (Gestion des signalisations et OGA AR) et le Pôle qualification, cela est plus difficile car chacun a sa vie propre et chacun peut géné-rer des évènements impactant la MPP et le suivi des signalisations en cours. Il s’avère alors difficile de centraliser une information à 3 points d’entrée en n’en re-gardant qu’un.



Figure. 56 – Vie d’une signalisation : visibilité de la MPP

La figure ci-dessus illustre la vue que peut avoir le pilote MPP dans la vie d’une si-gnalisation. Ce qui est sur fond bleu (devant l’œil non barré) peut être suivi car le point d’entrée est la signalisation, qui se transforme en OGA, …. Par contre l’OGA a générée des effets de bord, c'est - à - dire que son analyse a fait apparaître d’autres problèmes. Ces derniers provoquent la création d’une autre OGA qui va être corri-gée puis installée lors d’une corrective, ceci dans le cadre de la MPP, et sans que le pilote de la MPP puisse le savoir. Le problème est le même avec une autre OGA ef-fet de bord, qui elle passera en AR. On peut aussi rencontrer cet aspect si une OGA est créée sans signalisation, donc sans passer par le point d’entrée de la MPP. Ceci se fait en usage normal durant la qualification. L’importance de ce disfonctionnement apparemment anodin, est lié à la maitrise du processus. Le fait de ne pas connaître une étape de la vie d’un incident n’empêche en rien au projet de se dérouler. Par contre qu’en est-il lorsque qu’un incident grave se produit ?, il est fort probable qu’il y ait une grande perte de temps pour retracer et requalifier le problème. Nous sommes là sur un raisonnement d’anticipation qui se résume à « il me faut avoir tous les éléments en main afin de pouvoir anticiper sur un incident grave ». Ce raisonnement est souvent assez difficile à comprendre car il ne concerne que la per-sonne qui a besoin de cette visibilité complète. Il se trouve que ce n’est pas celui qui a le contrôle complet sur le déroulement du flux. Si l’ensemble des acteurs ne sont pas sensibilisés, alors l’information nécessitera un coût conséquent en pilotage de « recherche d’information ».



6. PROJECTION DE L’ORGANISATION SOUHAITEE

6.1. Progression

Nous avons vue l’organisation apportée par AGA-THONE ainsi qu’une des organisations que vit l’équipe de la MOE CRISTAL à travers la mise en place d’un pilote. Ce chapitre nous présentera une vue sur l’organisation souhaitée. Cette organisation devra intégrer des contraintes qui auront été exposées au préalable, et apporter des solutions qui amélioreraient l’organisation existante.

Figure. 57 – Différences et relations entre organisations

La première étape pour présenter une organisation cible a été d’enrichir le recueil effectué lors de la représentation de l’existant. Ce nouveau recueil, figure ci-dessous, a été réalisé dans le cadre d’un transfert de compétences vers un nouveau Pilote MPP. Il est enrichi entre autre d’une brique phase et de quelques modifica-tions relatives aux outils et aux documents projet.

Acteurs (pôles ou famille) Réunions

Livrables Outils

Mise en place Pilote

MOE CRISTAL

Contrat

Dossier de scénarioPTC + Planning+ annuaire + ...

MOA

lancement signalisation

Universalisation du suivi des versions

(Excel 26D)

WebDoc

Phases

Direction de Service

TMA CRISTAL

Productioninformatique

Chaîne de soutien

Généralisation

Supportmétier

Qualité

Les utilisateurs(DR)

ReportingPlan de mobilisationDossier MPP

Ordre d’installationFil conducteurMPP Metre

BilanSignalisation

Présentation contributeurs

Présentation utilisateurs

Fiches de testFiches croisière

Doc. utilisateurOuverture file mpp

Temps de réponse

Sonde VantageOGA

Genesis

lancement installationlancement MOE

Présentation à la DRPrésentation

aux Contributeurstests sur la version

suivi des signalisations

suivi de la MPP

validation Ordre d’Installation

suivi de l’installation présentation

fiches croisièreprésentation

fiches de tests

présentation organisation

Préparation

Initialisation

Lancement

Réalisation

Terminaison Suivi des signalisations

Figure. 58 – Ensembles des composants de la MPP






Différence b

Différence c



6.2. Les phases et processus

Au travers de l’analyse du regroupement des informations qui sont ressorties de ce diagramme et de la réflexion que nous avons eu sur les organisations théorique et existante, nous avons considéré qu’il pouvait y avoir 5 phases projet29 dans la MPP et que ces phases avaient des comportements et des règles spécifiques :

Préparation : Prend en compte l’ensemble des étapes permettant de recueillir les informations et d’initier les actions de base pour l’enrichissement du projet, sans générer de contrainte de dates. Les actions faites à ce stade restent informatives et intemporelles, le projet peut donc ne pas avoir de dates de réalisation planifiées, mais cette phase peut inclure un rétro planning. Nous sommes dans la phase majeure du projet, celle de sa construction en avance de phase. Cette phase est unique.

Figure. 59 – (organisation souhaitée) - Phase préparation

Initialisation : Le projet est acté, les dates connues, il est donc nécessaire d’initier toutes les tâches qui vont permettre sa réalisation effective. Cela va de l’activation des ressources, à la communication, en passant par la réalisation d’étapes préliminaires (développement spécifiques, …). Cette phase est unique.

29 Nous notons deux modes de fonctionnement : Le mode projet qui est volatile dans le temps et a une organisation spécifi-que car liée à la durée du projet, et le mode service continu qui prend en compte les activités récurrentes sur un « projet » donné (ce « projet » est une activité ou un ensemble d’activités. Il est d’usage de l’appeler aussi « projet », mais il ne suit pas le même fonctionnement qu’un projet. Cet aspect est à prendre avec beaucoup d’attention car très souvent synonyme d’incompréhensions entre équipes, de failles d’organisations (croisement / manques de responsabilités, désynchronisation d’actions, …))



Figure. 60 – (organisation souhaitée) - Phase initialisation

Lancement : Le lancement est une étape qui peut être récurrente au sein même du projet. C’est dans cette phase que sont regroupées les actions opérationnelles d’une séquence du projet (la séquence pouvant être le projet en entier). Si une installation a lieu sur un périmètre donné alors cela fera partie du lancement.

Figure. 61 – (organisation souhaitée) - Phase lancement



Réalisation : La réalisation intègre les opérations de déroulement du projet une fois que celui ci a été initié et lancé. Des opérations de pilotage, suivi, contrôles, rapports, de déploiement, de corrections, ….

Figure. 62 – (organisation souhaitée) - Phase réalisation

Terminaison : Une fois la fin de la réalisation actée, la phase de terminaison permet de gérer l’ensemble des actions de fin de projet, et de transférer les compétences et actions, objets restants aux équipes de service continus.

Figure. 63 – (organisation souhaitée) - Phase terminaison



La figure, ci dessous, reprend le séquencement des différentes phases présentées. On aperçoit les notions de phase autonome, (pour ce qui peut être fait en avance de phase, sans contrainte de délai) les phases séquentielles, qui s’enchaînent les unes derrière les autres, et les phases récurrentes qui peuvent se réaliser en chevauche-ment en suivant les mêmes processus de réalisation.

Figure. 64 – Les phases projet

Pour rappel, la mise en place pilote s’insère dans un processus informatique projet possédant un début et une fin est donc fondée sur un axe temporel déterminant de son évolution prévisible. Il nous a paru logique de segmenter l’ensemble des actions dans des phases qui auraient 2 natures : unique, qui ne s’applique qu’une fois dans le processus projet de la MPP ou récurrente qui peuvent se reproduire autant de fois que nécessaire, avec le même contenu. C’est le cas de la phase de réalisation qui a pour particularité de pouvoir se réappliquer sur autant de directions régionales qu’il peut être nécessaire. (Figure. 64 – Les phases projet) L’intérêt de cette récurrence est d’industrialiser autant que possible les actions à réaliser.

6.2.1. Les rôles

Fondée sur l’organisation théorique, l’organisation existante que nous avons décrite garde une bonne répartition des rôles utiles à la MPP. La projection que nous pour-rions faire pour l’organisation souhaitée serait la même que celle que nous ferions pour l’organisation existante. Ceci tout simplement car nous n’avons pas détecté d’incohérence dans les rôles en tant que tel, mais dans leurs interprétations et contextes. Un aspect qui nécessiterait une évolution serait l’interaction entre les différents rô-les qui peuvent être liés (ou le sont faiblement). La constatation faite lors de l’analyse de l’existant est que les acteurs ont un périmètre de travail qu’ils gardent bien délimité, ce qui est tout à fait normal et évite des croisements de responsabilité. Néanmoins si les rôles d’un acteur restent trop délimités, il existe un risque fort d’avoir une interactivité nulle avec les autres acteurs. Cela peut être assez problé-matique. Concrètement, un rôle est composé d’un ensemble d’opérations de travail qui ont pour objectif de participer au fonctionnement d’un processus. Si cet ensemble d’opérations de travail ne s’interconnecte pas avec d’autres rôles d’autre acteur,



alors il peut y avoir un dysfonctionnement. Surtout si ces deux rôles nécessitent de communiquer entre eux pour apporter une complémentarité à un processus ou une opération. Pour rappel, dans le cadre de l’organisation existante, qui reprend quasiment l’organisation théorique, les rôles sont bien définis, les processus le sont aussi mais l’engrenage ne tourne pas aussi bien qu’il serait souhaitable. Ceci tout simplement car il n’existe pas ou peu de dimensions qui permettraient d’attacher ou d’interconnecter des rôles entre eux. Pour prendre un exemple extrême où il y a cloisonnement d’un rôle : le pilote MPP, dans son rôle principal, nécessite de coordonner les applications de correctives du-rant la période de MPP. Ces dernières sont composées de produits logiciels qui ont un numéro de version. (1.2.2 - Composition de l’application) l’application Cristal est composée de deux familles de composants : les composants applicatifs et les composants référentiels. Ces deux familles de composants sont gérées le premier par le pôle qualification, le second par le pôle référentiel. Le rythme d’évolution des composants Cristal est de, maximum, 4 - 5 fois par an, celui du référentiel de 1 fois par mois. Il existe le rôle de « Gestionnaire logiciel » qui a en charge de suivre les versions des différents produits livrables. La personne tenant ce rôle est le respon-sable du pôle référentiel. Les deux ensembles de versions sont suivis par l’intermédiaire de deux outils. Il se trouve que durant les MPP, il apparaissait régulièrement des difficultés à obte-nir, de façon rapide et directe, les versions des composants référentiels. Ceci tout simplement car le cycle de vie des composants du référentiel est plus ra-pide que celui des composants applicatifs et suit un cycle de qualification différent. Ce qui fait que le rôle de « gestionnaire logiciel » doit effectuer un ensemble d’opérations pour suivre les versions des composants Cristal, et un autre pour le ré-férentiel, ceci mémorisé à travers deux outils. Le moment où un rapprochement doit être fait est celui où le pilote de la MPP sollicite les deux informations en même temps. C’est à ce moment où le rôle « gestionnaire logiciel composant Cristal » et celui de « gestionnaire logiciel composant référentiel », tenu par la même personne devient un seul et même rôle. Du moins devrait devenir un seul rôle. Cette incohérence, amusante avec recul, est complètement compréhensible car dé-pendante d’un historique, de mutualisation de rôles et de responsabilités. Ce qui était intéressant de montrer est que la définition d’un rôle est importante, et que les interconnexions de ces rôles doivent tout autant être maitrisées. Une solution dans cet exemple serait tout simplement d’adapter l’outil de suivi des versions utilisé à l’origine pour les composants Cristal afin qu’il devienne la réfé-rence aussi pour les composants référentiels. Cet outil deviendrait alors le liant qui manquait. Dans notre organisation souhaitée, il paraît nécessaire d’enrichir les liens entre les rôles afin de fluidifier et de favoriser les échanges.



6.3. Un exemple : La gestion des signalisations

Figure. 65 – Processus cible gestion des signalisations

Pour rappel, concernant notre exemple, le problème majeur que nous avons ren-contrés est la restriction d’information relative au suivi des incidents de la MPP, complété par le cloisonnement des rôles (cas de la gestion du référenciel) de notre dernier exemple. Notre problème est donc une perte de lien entre les informations ainsi qu’une visibi-lité réduite. Afin d’améliorer cette situation la logique nous suggère :

d’augmenter notre champs de vision sur les opérations liées aux signalisations, ceci afin d’avoir le recul nécessaire pour maitriser toutes les informations, d’étendre le processus de gestion des signalisations à l’ensemble des acteurs impactés par la MPP. Cela correspondrait à une redéfinition des rôles en les étendant à un périmètre plus grand.



Concernant l’aspect visibilité nous pouvons tout simplement appliquer une règle qui serait : toute information nécessite d’être considérée et mémorisé. Une fois tracée, il serait nécessaire de qualifier les différents types d’information et les suivre. La sub-tilité étant bien sûr de savoir classer, ce qui n’est pas considérable, comme étant du « bruit ». A ce sujet, les compétences et le bon sens des personnes concernées prennent la relève. Concrètement, le schéma Figure. 65 – Processus cible gestion des signalisations présente le nouveau processus. On remarque entre autre qu’apparait l’enrichissement de la transformation de l’évènement en OGA, en patch, en signali-sation, ceci au niveau de la MPP ainsi qu’au niveau de la AR. En nous appuyant sur le schéma théorique Figure. 66 - Signalisations : Les différents évènements et leurs traitements nous faisons apparaître un ensemble de type d’information pouvant être géré et transformé (voir 2.3.3 - La gestion des signalisations).

Evénement

Incident

Information

Evolution

Bruit

Patch

Correctif

Traité

Supprimé

Redirigé Information

Tâche

Redirigé

Traité

Service continu

Figure. 66 - Signalisations : Les différents évènements et leurs traitements

Deux nouveaux éléments que nous faisons apparaître sont la notion « d’évolution » ainsi que la notion de « correctif » . Effectivement, il est nécessaire d’ouvrir ce processus vers la prise en compte d’un nouvel aspect d’un événement ( « théoriquement non officielle » car devant entrer dans le cadre d’un processus en amont de la MPP) : la gestion des évolutions. L’objectif est de ne pas permettre de traiter en MPP (phase réalisation) des évolu-tions de logiciels mais uniquement des évolutions de référenciel. Ceci est possible de par le fait que la partie référenciel a un cycle très court (entre le besoin, l’étude, le développement, la qualification, l’intégration et le passage en production). Cette



aspect froisserait les puristes du mode projet30, à cela nous répondrons que des fois il faut être capable d’assouplir certaines règles afin de répondre aux contraintes du marché31. Au niveau des correctifs, leurs prises en compte permettent de suivre l’évènement de sa création à sa disparition, par la mise en place des corrections. Ceci afin de permettre le pilotage de l’ensemble des transformations et aussi la résolution effec-tive de l’incident premier. Comme nous pouvons le constater dans cet exemple, les modifications qui ont été réalisées sont très simples et l’on été en donnant plus d’ouverture au processus. Ainsi notre processus de gestion des signalisations s’est enrichi par la prise en compte d’évolution, ainsi que la notion d’information et de bruit. L’objectif du tracé des informations et bruits est de valoriser la nécessité de tout tracer sans pour autant tout traiter. Mais avec comme objectif final de simplement savoir ce qui se passe.

30 On ne mélange pas une étape de conception avec une autre plus en aval de déploiement d’éléments déjà conçus. C’est un mélange de phase projet qui peut mener à des incohérences de réalisation (c’est comme si on peignait une portière de voi-ture en même temps que l’on (re)conçoit les serrures, opération hasardeuse. 31 Pour rappel le référenciel contient les offres et services. Et ce sont ces données qui sont amenées en ce moment à bouger très rapidement pour suivre le marché qui, nous l’avons vu, est aussi très mouvant.



7. SYNTHESES

7.1. L’organisation théorique

AGATHONE est une méthodologie très avancée dans la description de l’ensemble des actions à réaliser pour un projet et à un moment donné. L’avantage indéniable est que l’ensemble du groupe a un référant unique en termes de Projet, et que cha-que personne maîtrisant cette méthodologie est rapidement autonome quel que soit son périmètre d’activité. La méthodologie est bien documentée et facilement acces-sible. L’ensemble des détails peut être trouvé afin de comprendre les grandes lignes. Cette vue macro permet à chaque équipe de posséder sa propre latitude d’évolution quant à l’application dans le détail tout en parlant le même langage avec les autres équipes. Il existe plusieurs remarques importantes concernant cette méthodologie. C’est une démarche bien adaptée à des projets de grande envergure. Elle est par contre très coûteuse pour être utilisé dans des petites structures, car très lourde à mettre en place. Le fait qu’il existe un cadre de fonctionnement dans lequel il suffit simplement de s’insérer, peut impliquer une dévaluation mémorielle du fonctionnement de chaque équipe. Étant donné que tout le monde suit AGATHONE, alors il n’est pas néces-saire de décrire ce qui se fait (puisque c’est la méthodologie de référence). Par contre qu’en est - il de l’adaptation que chacun en a faite ? Elle reste souvent orale et très rarement formalisé par écrit.

Figure. 67 - AGATHONE – Complexité de la méthodologie



La difficulté à former les équipes sur cette méthodologie qui pour être très généri-que et adaptable par tous n’en est que plus compliqué, implique une difficulté d’appréhension de ce qu’il faut faire et ce qu’il ne faut pas faire. Cette non - maî-trise apporte une adaptation très personnelle de la méthode, qui peut impliquer des dégradations de qualité. La figure (Figure. 67 - AGATHONE – Complexité de la méthodologie), qui est un extrait « simplifié » des relations entre phases, montre une certaine richesse dans la bonne compréhension des interrelations entre les diffé-rentes activités et paquets d’information entre activités. Effectivement, il est très difficile de bien appréhender la logique de cette méthode, si la vie des livrables n’intègre pas plus de richesse (quand il est créé, à qui va-t-il servir, …). Un troisième aspect concerne la notion de cloisonnement. AGATHONE, de par sa complexité, est détaillée sous forme de processus, de phase et de mode opératoire, et de livrables. Il existe des croisements entre les phases, avec des liens entre les phases et processus, processus et mode opératoire, mode opératoire et livrable, mais il n’existe pas de fil conducteur entre les processus. Il est en fait très difficile de ré-pondre à la question « comment va se transformer, et par où va passer une informa-tion entrée dans le premier processus de la première phase » . Cette discontinuité de liens entre les différents processus montre que la méthodologie est très directive sur les tâches à réaliser, et beaucoup plus souple sur l’imbrication entre ces tâches. Ceci se voit par la présence de livrables qui servent à des phases antérieures à la phase pendant laquelle ils sont construits, ou des disparitions de livrables, ….

Figure. 68 - AGATHONE – La notion de cycle de vie d’une information

Bien que suivant un axe temporaire, on ressent dans cette méthode une certaine sta-tique, il n’existe pas de notion de vie des flux d’information (document, objets logi-ciels, …) qui permettrait de suivre un cheminement dans le temps intégrant les éventuelles transformations de l’information.



On remarque sur la figure (Figure. 68 - AGATHONE – La notion de cycle de vie d’une information), représentant une partie du modèle abstrait inter - mode opéra-toire, que le livrable « plan de travail commun » est utilisé pour plusieurs activités, mais sans pouvoir avoir d’ordre chronologique. L’ensemble de ces points nous fait penser que AGATHONE pourrait avoir été cons-truit à partir de macro activités puis suivant une approche descendante (dite « top down ») de plus en plus détaillé afin d’arriver à des modes opératoires set des livra-bles. L’image que nous pouvons en avoir est celui d’une construction en silo, c’est à dire une représentation complète d’un ensemble d’opérations sur un périmètre détermi-né. Périmètre fonctionnel qui dans notre cas serait la MPP. La particularité d’un silo est qu’il englobe un grand nombre d’éléments du plus général au plus détaillé. Son inconvénient est qu’il reste sur ce périmètre et il peut être difficile de trouver des ponts entre différents silos. Effectivement, un aspect intéressant concerne le nombre de rôles associés au nom-bre d’acteurs, le rapport est proche de 1. Cela signifie que le travail des personnes est fortement délimité sur un domaine unique. Phénomène d’industrialisation du travail, afin de simplifier des tâches et augmenter la montée en compétence ainsi que la productivité. L’inconvénient est qu’un fonctionnement mono domaine peut entrainer une visibilité réduite et un cloisonnement à terme. Quoiqu’il en soit, dans notre étude, cette méthodologie nous donne tous les élé-ments permettant d’avoir une organisation théorique bien explicitée. Résumé : Agathone est une méthodologie très complète fondée sur un fonctionnement jalon-née, prenant en compte toutes les étapes d’un projet. C’est pour nous l’organisation théorique, c'est - à - dire qui représente la stratégie que doit suivre notre service d’étude informatique. AGATHONE est très procédurale, elle décrit l’ensemble des composants des processus par des modes opératoires et décrit des rôles et activités de façon très précise. Les « défauts de ses qualités » sembleraient être la présence de risque d’une interprétation trop rigoureuse de ce qu’il faut faire à travers ses ac-tivités et rôles, ceci sans forcément pouvoir s’adapter à un existant. De même il est difficile d’avoir une vue vivante des flux entre les différents processus. AGA-THONE semble être une description complète mais statique dans sa circulation d’information.



7.2. L’organisation existante

Certaines des contraintes qui ont été vues à travers des exemples (Gestion des si-gnalisations, suivi du référenciel, . .) paraissent anodines et aisément gérables par un bon pilotage et des équipes proches et communicantes. Néanmoins il faut prendre en compte que CRISTAL est une application complexe et qui s’insère dans un sys-tème d’information complexe, l’ensemble étant soumis à une stratégie qui casse complètement la logique sectorisé de ce dernier32. Effectivement, la convergence pousse les applications à communiquer encore plus entre elles et modifie les offres dans leurs caractéristiques propres. Nous ne parlons plus d’une offre de service sur le fixe, mais d’une offre packagée incluant par exemple le fixe et le radio mobile. La particularité de l’organisation existante est qu’elle s’appuie énormément sur AGATHONE sans prendre la liberté d’adapter cette méthodologie à un contexte collégial particulier. Par contre, on sent que dans un périmètre de responsabilité uni-taire, les équipes s’adaptent et s’affranchissent facilement des contraintes d’AGATHONE. Cela est parfaitement normal, l’effort est moindre lorsque l’on peut s’organiser de son propre chef. Un fonctionnement devient compliqué lorsqu’il s’agit d’intégrer plusieurs équipes ayant chacun leur propre autorité. L’effet de bord de ces observations est qu’il est très difficile d’avoir une bonne mai-trise du processus de gestion des signalisations. Rien n’explique, n’impose, ou ne conseille de la nécessité de suivre toutes les informations qui peuvent impacter la MPP. Les entités participants à ce processus ont une vue interne dans la gestion des signa-lisations, ce qui fait que le pilote de la MPP est obligé de courir derrière l’information, car cette information n’est pas prévue d’arriver jusqu’à lui. L’organisation existante33 correspond dans l’ensemble à ce qui est induit par l’organisation théorique. Néanmoins elle est perfectible sur tout ce qui peut permet-tre d’élargir les champs d’actions des acteurs.

32 La téléphonie fixe a été, en France, un produit avec très peu d’évolution en termes de service. Forcément le système d’information relatif à cette téléphonie avait le même faible rythme d’évolution d’où l’aspect statique et fermé sur un sec-teur technique : la téléphonie sur le fil. 33 Pour rappel, nous nous sommes mis devant une organisation existante, il ne faut pas oublier qu’il y en a plusieurs, mais en prendre une et la travailler est une manière de procéder par couche successives qui permet de la rendre meilleure.



Résumé : L’organisation existante colle le plus parfaitement possible à l’organisation théori-que. Les rôles et activités sont très semblables à ce que nécessite AGATHONE, les acteurs s’appuient beaucoup sur ce qui doit être, l’évolution du projet est fondée sur le référenciel de jalons. Cette volonté de vouloir respecter à l’identique l’organisation théorique affaiblit le fonctionnement des équipes entre elles. La communication est réduite à ce qu’il doit être fait au détriment de ce qu’il faudrait réellement faire. Ceci est complété par une limitation induite principalement par la définition trop précise des rôles d’un acteur à un périmètre donné, et à l’exécution des opérations contenu dans son processus. Il existe une forte fréquence d’unicité entre rôle et acteur, n’incitant pas une personne à ouvrir son travail vers d’autres. Les personnes sont très ouvertes entre elles, les relations dans leurs échanges d’informations sont plus restreintes. Des processus en silo, des rôles trop bien défi-nis, des échanges de flux d’informations appauvris, cette organisation a besoin de s’assouplir au niveau de ses échanges.



7.3. L’organisation souhaitée

Une des organisations souhaitées34 se résume par la nécessité d’étendre et d’enrichir les champs d’action de certains processus, partant du principe qu’avec une réflexion transverse, il est possible d’avoir un champ de vision suffisamment large pour dé-tecter des processus silos et de les rendre plus étendus et plus complets. Bien sûr, il est important de considérer que rendre complet ne doit pas rendre com-pliqué, ce qui, forcément, rendrait l’application du processus inexploitable. Nous restons toujours dans une logique systémique. A travers des expériences, on apprend dans le monde projet qu’il existe un certains nombre de règles basiques qui sont des conditions sine qua none de la bonne ou mauvaise réussite d’un projet. Deux d’entre elles concernent les responsabilités :

Les croisements de responsabilités : lorsque deux acteurs ou deux rôles ont dans leurs procédures les mêmes opérations ainsi que les mêmes responsabilités sur les résultats de ces dernières, il y a risque de dysfonctionnement (et de conflit) car cette responsabilité identique peut se balancer entre les deux au gré de la bonne ou mauvaise volonté des acteurs ou porteurs des rôles. Les vides de responsabilités : c’est le contraire, il existe entre deux responsabilités qui se complètent (qui travaillent ensemble) un ensemble d’opérations orphelines (personne ne les (re)connait). Ainsi lorsque l’une de ces opérations est en échec (ce qui est forcément le cas), personne ne la prend en compte pour résolution.

De notre contexte nous pouvons faire ressortir une nouvelle règle attachée aux res-ponsabilités qui serait :

Les responsabilités en silo : la trop bonne protection des responsabilités de chacun (par une application très théorique d’une méthode ou par protection d’un périmètre donné (pour qualité, par affinité, par historique, …) ) implique une perte de communication et d’information entre chaque acteur ou porteur de rôles concerné.

Un exemple simple résumerait ceci : dans un circuit électrique, s’il est nécessaire que le courant passe bien d’un point à un autre, il ne faut pas pour autant qu’il passe partout, ni qu’il ne passe pas du tout, et surtout qu’il passe pour chaque élément le nécessitant. Encore faut - il pour ce dernier point connaître les éléments qui en ont besoin. D’où l’intérêt de connaitre le circuit actuel et sa composition. De même, il nous parait, important de ne pas sous estimer les outils de liaison entre les différents rôles et acteurs (contributeur du bon fonctionnement des processus). Ces outils ne doivent pas être bloquants, juste structurants pour ce qui est néces-saire. Ainsi dans le cadre de l’évolution du processus de gestion des incidents, la

34 Tout comme il existe une infinité d’organisation existante, il existe aussi une infinité d’organisation souhaité, nous som-mes dans un raisonnement systémique donc global, qui n’est pas analytique et n’a donc pas une seule réponse mais une in-finité.



mise en place d’un simple tableau Excel bien renseigné, et un suivi régulier sont amplement suffisant au bon suivi de tous les évènements. Ainsi notre organisation souhaitée serait plus ouverte au niveau de ses rôles. Elle saurait s’affranchir d’une éventuelle rigidité naturellement imposée par l’organisation théorique. Résumé : Dans notre organisation souhaitée, nous avons à palier les faiblesses de l’organisation existante que nous avons décrite auparavant. Pour cela nous avons à axer notre effort sur l’ouverture d’interprétation d’AGATHONE : cas de la gestion des signalisations qui nécessitent de prendre en compte plus d’information que sim-plement un incident. Il serait nécessaire d’ouvrir les descriptions des rôles afin de permettre aux acteurs porteurs de s’interconnecter plus facilement avec leurs autres contacts. Puis il faudrait transmettre une dynamique aux interconnexions de certains processus afin de favoriser les échanges de flux.



7.4. Remarques

Comme nous l’avons évoqué dans notre cadrage, nous nous intéressons en particu-lier au manager de cette organisation. Lui transmettre une réflexion afin de partici-per à un mûrissement nécessaire pour modifier sa propre organisation (en fonction de ses besoins). Comparer trois organisations35 peut être difficile dans le cas où la stratégie d’entreprise n’est pas connue, ou lorsqu’elle est connue, mais que rien ne précise l’organisation théorique. Dans le premier cas, malheureusement il n’y a pas grand - chose à faire que de s’appuyer sur la bonne volonté des membres de l’organisation pour assumer le quo-tidien de la façon la moins rébarbative possible. S’il n’y a pas de stratégie, il nous parait difficile de savoir où aller, encore plus de comparer des organisations en fonction d’une cible. Néanmoins, il pourrait être intéressant de construire une organisation théorique fon-dé sur des aspects de type qualité de travail, ou amélioration de la qualité. Cela re-viendrait à laisser le manager définir sa propre stratégie, et adapter son organisation pour y répondre. Vu du niveau global de l’entreprise, cela risque de donner des ré-sultats assez aléatoires36. Dans le second cas il sera possible d’adopter une méthode « descendante » (dite « top down ») pour définir l’organisation théorique. En fait cela revint à dire que notre entreprise à une stratégie, qu’il faut convertir en organisation cible. Nous par-lons là de l’aspect tactique de cette stratégie. Cette tactique va offrir une cible aux équipes managériales pour orienter leurs organisations. Pour traduire une stratégie en modèle tactique, il peut être utile d’adopter une cons-truction visuelle qui offrira à la direction le moyen de représenter leurs pensées ain-si que les manières de les réaliser. OSSAD est une méthode qui peut aider à cette formalisation. Elle est suffisamment simple à appréhender pour pouvoir facilement dessiner un schéma lisible à une étape où le détail n’est pas nécessaire. Elle peut en-suite permettre d’entrer dans le détail.

35 Il pourrait être judicieux de comparer ce que nous venons de voir dans cette étude : comparaison de trois points de vue d’une organisation, avec une méthode d’audit classique (COBIT, propriétaire, ..). Cela pourrait revenir à la comparaison d’une analyse systémique à une analytique. Cela n’est pas l’objet de ce document, mais pourrait faire l’objet d’une autre étude. 36 Si cette entreprise n’a pas de stratégie, il y aura de toutes les façons des résultats aléatoires à terme.



En plus d’être une méthode graphique laissant une grande liberté d’usage, cette mé-thode permet beaucoup de souplesse lorsqu’il s’agit de représenter les grandes li-gnes d’une organisation ainsi que les paquets d’information qui transitent entre dif-férents processus. Cela est aussi très utile lorsque l’on souhaite entrer dans le détail, par contre cela est assez couteux en temps et nécessite une attention particulière afin d’obtenir une bonne représentation. Dans notre étude nous sommes plus dans une optique de sensibilisation, nos représentations apportent leurs valeurs à partir du modèle abstrait, car nous sommes sur un concept de raisonnement sur des vues d’organisation. Nous avons utilisé le modèle descriptif pour notre exemple. Il aurait été gigantesque de représenter tous les processus, et cela n’aurait apporté qu’une minuscule valeur ajouté à notre démonstration et à l’enrichissement de l’organisation souhaitée. Par contre OSSAD prendrait toute sa valeur dans le cas où il serait nécessaire de décrire en détails un ou plusieurs processus en vue de la mise en œuvre d’une automatisation de travail (en anglais : Work Flow) L’intérêt d’OSSAD pour cette étude était d’être un outil permettant d’appuyer la ré-flexion que nous souhaitions apporter sur les différentes vue d’une organisation. A la fin de cette étude, nous pouvons affirmer que cet outil a bien tenu son rôle d’outil, et a permis de représenter les organisations de façon à pouvoir les découvrir avec une vue globale permettant des comparaisons ; ce qui était recherché.



Conclusion Cette étude a comme objectif d’apporter une réflexion sur le thème de l’organisation. Elle s’appuie sur deux concepts clefs que sont la systémique (2.1.2 Démarche de résolution envisagée) et la représentation, et sur un découpage en trois vues : le théorique, l’existant, et le souhaité. Enfin comme notre orientation est de cibler l’aspect opérationnel de l’organisation, nous avons fondé la substance de l’étude sur la notion de processus. Réflexion : « Tu es assis près d'un ruisseau et tu as soif. Même si tu es idiot, tu sais que l'eau va te désaltérer. C'est ça comprendre... » [Barjavel, 1976]. Cette étude a comme objectif d’apporter des éléments de réflexion aidant à comprendre, selon un point de vue personnel, une organisation opérationnelle. La démonstration sous - jacente à cette réflexion est qu’un service, composé de res-sources, nécessite d’être organisé, que cette organisation est relative à son environ-nement, et qu’il est nécessaire de la comprendre avant de vouloir la changer. Organisation : Notre réflexion s’est fondée sur un service d’études informatiques. Afin de comprendre et d’améliorer ce service, nous avons fondé notre réflexion sur la possibilité de décrire trois vues de son organisation. Nécessaire (aspect théori-que), existante (aspect concret), souhaitée (aspect cible). « Il est sans comparaison plus facile de faire ce qu'on est, que d'imiter ce qu'on n'est pas. » [Louis XIV, 1712]. Pour que notre réflexion soit mûrie il nous fallait mettre en place des éléments de comparaison, de ce qui devrait être, ce qui est et ce que l’on souhaiterait voir être. Systémique : Afin de rester en phase avec une compréhension globale de nos diffé-rentes organisations, il fallait trouver une approche qui n’amène pas la réflexion vers des analyses de la situation détaillées. Une approche systémique permet de garder la capacité de recul pour comprendre une vue d’ensemble. Si cette étude doit pouvoir servir à un lecteur qui aura pu mûrir une réflexion personnelle, il est nécessaire que cela soit par des influences et non des équations. Représentation : Il nous fallait un outil afin de pouvoir construire les éléments permettant au manager d’enrichir sa propre réflexion. Il fallait que cet outil soit simple et facilement assimilable. Nous avons donc décidé d’enrichir cette étude par des représentations visuelles. Et afin que cela ne soit pas anarchique, il était nécessaire de trouver ou de créer un ou-til visuel orienté organisation. Cet outil existe et s’appelle OSSAD.



Processus : Une organisation est vaste, et touche un grand nombre de sujets : le tra-vail, les compétences, la productivité, l’affectif, la finance, les conflits, …. Il est ab-solument nécessaire de cadrer la réflexion que nous voulions avoir. Étant dans une logique de système d’information nous avons choisi de construire nos organisations sur la notion de processus. Ainsi, à la lecture de cette étude, il sera nécessaire de comprendre que l’organisation dans laquelle nous évoluons n’est pas et ne doit pas être une fatalité, une construction aléatoire, ni même l’exactitude de ce qui est souhaitée. Elle est multiple, elle provient d’une nécessité, elle existe et idéalement est souhaitée sous d’autres formes. « Les détails font la perfection, et la perfection n'est pas un détail. » [deVinci, 1518]. A partir d’une organisation théorique évoluée et détaillé (AGATHONE) il apparait des imperfections liées à une définition trop précise et à un travail trop délimité. Imperfections qui peuvent être corrigées par un réajustement élargi des rôles des ac-teurs, par le décloisonnement des processus, et la volonté de dynamiser les échanges entre ces derniers. L’ensemble de ces améliorations proviennent d’une réflexion assez générale, gar-dant une logique systémique, en ayant une vue multiple de ce qui doit être, de ce qui est et de ce que l’on souhaite, alors en connaissance de causes et d’effets.



Apport personnel

Cette thèse a été réalisée avec à la base les objectifs d’enrichir le mastère par une réflexion personnel orientée sur l’organisation. L’idée était de trouver un moyen pour représenter des organisations opérationnelles de façon simple et rapide afin de pouvoir faire ressortir des axes d’amélioration. Il fallait donc absorber puis fusionner un maximum de méthodes qui permettraient d’obtenir une sorte de méta mo-dèle de représentation orienté organisation. Au cours de la phase de recherche et mûrissement, j’ai pu découvrir OSSAD qui suivait exac-tement ce principe. Poussant plus loin ma recherche, j’ai ainsi pu m’imprégner de la notion de réflexion par système. Cela a été la plus grande richesse que j’ai pu retirer de cette thèse. A un niveau de raisonne-ment professionnel, déjà la notion de processus m’attirait fortement. La volonté de vouloir as-socier une réflexion sur une organisation, un aspect processus, ainsi que cette sensibilisation à la notion de système m’a permis d’avoir une véritable plus value dans mon mûrissement. Ain-si, de fil en aiguille, j’ai pu avoir une vue sur ce monde qu’est la systémique et la notion de pensée complexe. Il se trouve qu’un raisonnement systémique ressemble beaucoup à un raisonnement processus à la seule différence que la notion de processus est souvent associée à une vision très fonc-tionnelle au niveau des systèmes d’information. La vision systémique déborde sur des domai-nes tels que la psychologie, la gestion des conflits, la formation, la politique, ... C’est une chose assez nouvelle pour le monde assez technique dans lequel j’évolue professionnellement. Avoir un raisonnement systémique me paraît aujourd’hui quelque chose de primordial car il permet de mieux comprendre des situations comportementales que nous pouvons facilement rencontrer dans notre vie professionnelle de tous les jours. Aujourd’hui, à l’issu de cette thèse, la triple satisfaction que je peux avoir concerne :

L’acquisition d’une vision plus large et plus riche de la notion d’organisation, de processus et de raisonnement systémique, La réalisation d’une étude qui a complétée ce que j’ai acquis au cours du mastère Une réflexion en complete adéquation avec l’apport que m’a apporté cette thèse.

Effectivement, ce Mastère Spécialisé Management de Systèmes d’Information Réparties en partenariat avec l’ESSEC et Telecom Paris constituée d’un volume de cours principalement académique sur un grands nombre de sujets. Cette thèse a été le coté découverte et enrichis-sement personnel. Les deux étant pédagogiquement et intellectuellement nécessaires.



Annexe



8. BIBLIOGRAPHIE

SOURCES PRIMAIRES

[AFNOR, 2000] AFNOR X50 - 176, Management des processus, AFNOR, 2000.

[Barjavel, 1976] René Barjavel, Si j'étais Dieu..., p. 69, Garnier, 1976 [C - Log, 2003] C - Log International – Tutorial sur OSSAD, 2003

[deVinci, 1518] Léonard de Vinci – Extrait des carnets, 1478 - 1518

[Harrington, 1987] Harrington, H. James. The Improvement Process : How Amer-ica's Leading Companies Improve Quality. New York : McGraw - Hill, 1987.

[Le Moigne, 1984] J. L. Le Moigne, La théorie du système général - théorie de la modélisation, 2ème édition, Presses Universitaires de France, 1984.

[Le Moigne, 1990] J. L. Le Moigne, La modélisation des systèmes complexes, Du-nod, Paris, 1990.

[Le Moigne, 1994] J. L. Le Moigne, Le Constructivisme, T1, p 122 ESF, édition, 1994

[Louis XIV, 1712] Louis XIV, Mémoires - 1712

[Morin, 1990] Edgar Morin, "Introduction à la Pensée Complexe" ESF Éditeur, 1990.

[ORYX, 2003] ORYX Choix d’outils de modélisation des processus, http : //www. oryxsi.com/telechargement /Choix_outils_modelisation. pdf, 2003.

[OSSAD, 1990] Philippe Dumas, Gilles Charbonnel, La méthode OSSAD – Tome I « Principes » - Les éditions Organisation, 1990.

[Pillet, 2003] M. . Pillet, Six Sigma : comment l'appliquer, Editions d'Organi-sation, Paris, 2003.

[VON BERTALANFFY, 1973] Ludwig Von Bertalanffy, Théorie générale des systèmes, Dunod, Paris, p 153, 1973.

SOURCES SECONDAIRES

[Authier et al., 1992] M. Authier, P. Levy, Les arbres de connaissances, La Décou-verte, Paris, 1992.

[Beckhard, 1975] R. Beckard, Le développement des organisations : stratégies et modèles, Editions Dalloz, 1975.

[Belot, 1918] E. Belot, Principes généraux de l’organisation systématique des machines et de l’industrie, La Technique Moderne, 1918.

[Büyükozkan, 1999] G. Büyükozkan, Une approche de formalisation d'un processus de benchmarking coopératif, Thèse de l'INPG, 1999.

[Cattan et al., 2001] M. Cattan, N. Idrissi, P. Knockaert, Maîtriser les processus de l’entreprise, Editions d’organisation, 2001.



[De Nanteuil, 1998] M. De Nanteuil, La participation des salariés aux changements du travail, Ed. Liaisons, Paris, 1998.

[Desreumaux, 1998] A. Desreumaux, Théorie des organisations, Ed. Management et Société, 1998.

[Durand, 1979] D. Durand, La systémique, Presses Universitaires de France, Bi-bliographie 141, 1979.

[Eckes, 2001] G. Eckes, Objectif Six Sigma, Ed. Village Mondial, Paris, 2001.

[Herniaux et al., 2001] G. Herniaux, D. Noyé, Organiser et améliorer les processus, IN-SEP Editions, 2001.

[ISO 7144, 1986] ISO 7144 « Présentation des thèses et documents assimilés », Genève : ISO, 10p, 1986.

[Jacob, 1994] G. Jacob, Le reengineering de l’entreprise, l'entreprise reconfi-gurée, Hermès, Paris, 1994.

[Levan, 1999] S. K. Levan, Le Projet Workflow : Concepts et outils au service des organisations, Eyrolles, Paris, 1999.

[Rouveyran, 1999] ROUVEYRAN, Jean - Claude, « Le guide de la thèse, le guide du mémoire. Du projet à la soutenance », Paris : Maisonneuve et Larose, 249 p, 1999.

[Vas, 2002] A. Vas, Les processus de changement organisationnel à l’épreuve des faits : une approche multi - pragmatique, Actes de la 11ème Conférence Internationale de l’AIMS, Paris, 2002.



9. GLOSSAIRE

Action corrective : Action visant à éliminer la cause d'une non - conformité ou d'une autre situation indésirable détectée. (ISO 9000)

AFNOR : Association française de normalisation (AFNOR). L'AFNOR est l'organisme français de normalisation membre de l'ISO.

AGATHONE : Méthodologie de description et de gestion de projet informatique créée et utilisée par le Groupe France Telecom

Assurance qualité : Assurance qu'une entité (entreprise ou administration) a adopté des principes d’organisations telles que la qualité des produits ou services rendus sera effec-tive par la mise en œuvre de ces principes.

Audit : examen méthodique et indépendant qui vise à mettre en évidence objectivement les écarts par rapport à un référentiel.

Bénéficiaire : Personne ou entité (client, usager, service demandeur) au profit de la-quelle est menée une activité.

Cartographie : Synonyme de recensement. La cartographie d'un processus consiste à recenser et à décrire l'ensemble des tâches ou activités composant un processus.

Consultant : Personne ou organisme ayant un rôle de conseil en matière d'organisation d'entreprises ou d'administrations. Le consultant souvent rémunéré pour ses services possède l'autorité d'un partenaire compétent, extérieur à l'entité demandeuse de ses ser-vices.

Corrective : Ensemble de composants logiciel qui contiennent des corrections à des problèmes recensés d’une application. Le passage de cette corrective sur l’application concernée permet de supprimer les problèmes.

Correctif : (Voir corrective) Diagramme d'Ishikawa : Voir « Diagramme causes/effets » Diagramme causes/effets : Diagramme (appelé aussi diagramme d'Ishikawa) élaboré à

l'issue d'un groupe de travail. Ce diagramme ayant la forme d'une arête de poisson sert à analyser le rapport existant entre un problème et ses causes classées en 5 grandes famil-les (les "5 M").

Diagramme de Pareto : Graphique faisant apparaître les causes les plus importantes qui sont à l'origine du plus grand nombre d'effets, sachant que 20% des causes sont à l'ori-gine de 80% des conséquences. Le diagramme de Pareto est un diagramme en colonnes, exposant et classant, par ordre décroissant d'importance, les causes ou problèmes. La hauteur des colonnes est alors proportionnelle à l'importance de chaque cause.

Diagramme phase - entité : Tableau synthétique de description d'un processus où les entités (services, bureaux) sont présentées horizontalement et les différentes phases du processus verticalement.

Efficacité : niveau de réalisation des activités planifiées et d'obtention des résultats es-comptés. (ISO 9000)

Efficience : rapport entre le résultat obtenu et les ressources utilisées. (ISO 9000) FT : France Telecom



Gestion des difficultés : Recensement et analyse des difficultés survenues lors de la ré-alisation d'une tâche ou d'une procédure. Cette analyse doit déboucher sur une améliora-tion du mode opératoire de la tâche ou de la procédure.

Gestion des signalisations : Recensement et analyse des incidents survenues lors de l’usage de briques su système d’information (application, poste de travail, . .). Cette ana-lyse doit déboucher sur une résolution du problème directement ou indirectement par la prise en compte dans une corrective.

FD X50 - 550 (fascicule de documentation AFNOR) : Fascicule de documentation AFNOR publié en octobre 2001, relatif à la démarche qualité EN recherche. Formulation de recommandations pour mettre en place une démarche qualité cohérente dans les acti-vités de recherche ainsi que dans le fonctionnement des entités dans lesquelles elles sont menées que ce soit en recherche fondamentale ou en recherche appliquée.

ISO : Organisme international de normalisation. ISO 9001 : Norme d'exigence de la "famille" des normes ISO 9000, servant de référen-

tiel de certification (responsabilité de la direction, management des ressources, réalisa-tion du produit, mesure, analyse et amélioration).

Norme : Une norme est un document écrit définissant les caractéristiques techniques d'un produit ou d'un service. Elle est de nature volontaire (non obligatoire) et homolo-guée par un organisme reconnu par un état.

Normes IS0 9000 : Ensemble de normes internationales relatives à la gestion de la qua-lité dans les organisations (entreprises, administrations). Cet ensemble, appelé parfois "normes de la famille ISO 9000" regroupe 4 normes : ISO 9000, ISO 9001, ISO 9004 et ISO 19011.

MPP : Mise en Place Pilote : processus projet de la méthodologie AGATHONE Procédure : Description normative définissant la réalisation d'une activité ou une tâche. Processus : Ensemble d'activités, corrélées ou enchainées qui à partir de matières pre-

mières délivrent des produits finis. Cette définition industrielle peut être adaptée à l'acti-vité des services telles que les administrations (exemple : la demande d'aide en entrée génère une décision d'aide en sortie).

QQOQCPC : Initiales des questions à se poser lorsque l'on aborde un problème : Quoi, qui, où, quand, comment, pourquoi, combien ? C'est aussi un outil d'audit Qualité qui permet de vérifier l'existence d'exigences et d'en vérifier l'application au travers des pro-cédures Qualité.

Référentiel : disposition de référence, servant de guide pour la construction et la vérifi-cation d'un système. Ce sont des modèles d'exigences.

Système : ensemble d'éléments corrélés ou interactifs. (ISO 9000) Système Qualité (ou système de management de la Qualité) : système de manage-

ment qui fixe une politique et des objectifs permettant d'orienter et de contrôler un orga-nisme en matière de Qualité. (ISO 9000)



10. COMPLEMENT : LE DICTIONNAIRE OSSAD La liste de tableaux qui suit présente les éléments de base du dictionnaire OSSAD permettant d’avoir des représentations uniformes. Nous avons enrichi ces tableaux avec quelques commentaires afin de bien comprendre certaines différences impor-tantes pour une bonne représentation.

Icône et concept Règle de création Type

de modèle Exemple

Substantif, éventuellement suivi d’un complément d’objet En majuscule

Abstrait GESTION DES INCI-DENTS - ADMINISTRA-TION DU SERVICE

Substantif, éventuellement suivi d’un complément d’objet En majuscule

Abstrait GESTION DES INCI-DENTS - ADMINISTRA-TION DU SERVICE

Les processus à l’origine appelés « fonction » dans la méthode d’origine, peuvent être :

Processus : à savoir un système (ou sous système) suffisamment significatif pour qu’il soit valorisé, ceci quelques soient les interactions qu’il peut avoir avec d’autres systèmes. L'analyse peut se faire par la décomposition du système global en sous - systèmes observables et d'une complexité abordable. [Mélèse - AMS]. Il est important que le processus soit parlant pour l’ensemble des acteurs et que sa complexité soit de même niveau que les autres processus. Processus externe : Considéré comme étant nécessaire que pour information, il peut être représenté afin de valoriser ou d’aider à comprendre un modèle. Par exemple, l’acte d’achat d’un client peut être représenté comme un processus externe. Sous - processus : est l’imbriquement d’un autre processus ou sous - processus. De par la possibilité de la méthode d’effectuer des zooms dans les différents modèles, il est possible donc d’avoir des processus composés d’autres processus. Nous parlerons alors de Macro - processus. Dans le cas de représentation complexe, il est tout de même déconseillé de descendre trop profondément au niveau du zoom, tout simplement pour garder une lisibilité de l’ensemble. La meilleure solution est alors de travailler par périmètre fonctionnel.

Il est à noter que plus on entre en profondeur dans la description des processus (par la représentation de sous - processus) et plus on se rapproche du modèle descriptif pour qui le processus devient une procédure (déroulement d’opérations). OSSAD utilise le terme d’activité pour définir les sous - processus d’un niveau très détaillé.



Substantif, éventuellement suivi d’un qualificatif En minuscule

Abstrait incident – contrat de main-tenance – ordre de lance-ment

Afin d’échanger des informations, les processus sont reliés par des paquets. Les paquets d’information véhiculent le résultant d’un processus pour l’apporter en entrée à un autre processus. Au niveau du modèle abstrait, cela reste au niveau d’information générique, il n’y a rien de représentable physiquement à ce stade. Bien sûr, les paquets n’existent que s’ils sont reliés à des processus.

Infinitif, éventuellement suivi d’un complément d’objet En majuscule

Descriptif SUIVRE UN INCIDENT – COMMUNIQUER AUX UTILISATEURS

Infinitif, éventuellement suivi d’un complément d’objet En minuscule

Descriptif mémoriser l’incident – qualifier l’incident – re-produire l’incident

L’opération est l’action minimum ayant un intérêt pour le projet et qui peut être effectuée par une personne (ou une machine). L’opération doit être présentée et décrite afin d’alimenter la réflexion de l’étude, il est juste nécessaire de la présenter de façon très simple (le contraire risque de rendre illisible la représentation). Il est à noter que dans la méthode OSSAD, il est question de tâches, qui sont des composants de l’opération. Etant donné la similarité entre ces deux concepts, nous considérons que la notion de Tâche pourra être fusionnée avec celle d’Opération, ceci afin de gagner en lisibilité. Néanmoins, lorsque nous parlerons d’opérations, implicitement cela comprendra un nombre de tâches (représentées ou non). La procédure est un ensemble d’opérations permettant de réaliser un Processus. C’est l’aspect descriptif de ce processus et c’est de plus une représentation dynamique car elle regroupe un ensemble d’opérations qui ont une durée de vie propre et un état qui peut changer dans le temps.

Rôle

Substantif, éventuellement suivi d’un complément d’objet Première lettre en majuscule

Descriptif Animateur – Décideur - Pi-lote – Responsable des in-cidents

Unité


Descriptif

Production – Qualification – Marketing - s

Le rôle est une notion très importante lorsque l’on se trouve dans un contexte d’Organisation. Son utilisation est un atout conséquent de la méthode OSSAD, car complètement détaché des unités organisationnelles, et des acteurs. Un rôle est un ensemble de tâches ou de responsabilités qui regroupées peuvent former une activité facilement nommable. Par exemple le rôle d’administrer des données, d’être garant du référencement des versions, de



piloter l’avancement de la qualification de composants logiciels, …. L’ important est que le rôle soit indépendant des personnes, car une personne peut avoir plusieurs rôles, et un rôle peut être pris en compte par plusieurs personnes. Pour mieux comprendre cette aspect, imaginez que en tant que manager, vous deviez faire en sorte que votre équipe soit opérationnelle 24h/24h, il faut donc, lors de l’absence d’une personne, que son travail soit pris en compte par les autres. Vous pouvez le faire unitairement, en doublant tout ce qu’elle fait ou par répartition de ses rôles. Autre aspect intéressant d’usage des rôles, tout simplement afin de dépassionner un projet touchant à l’organisation, on ne parle pas de personnes mais de rôles lissant ainsi une implication qui pourrait être trop personnelle pour certains acteurs. L’unité, est un regroupement de rôles fondée soit sur une notion de responsabilités soit sur des besoins de coordination et de contrôles. L’Unité permet de représenter la structure formelle de l’organisation.

ET ou alors OU En majuscule Descriptif ET – OU

Les opérateurs ET et OU permettent d’enrichir le modèle descriptif par l’usage de conditions. Le ET signifie il faut que les conditions entrantes soient toutes respectées. Le OU permet une alternative, soit cette condition soit cette autre condition permettront de réaliser l’opération.


Descriptif

Fiche incident – Demande de moyens – Orde d’installation. Etat = A valider – En cours – A tester


Descriptif Produit livrable – Bandes de sauvegarde – Dossier collaborateur

La Ressource pour OSSAD est un couple : Ensemble d’information et son support. A la différence du modèle abstrait qui parle du Paquet comme étant un ensemble d’information générique, la ressource inclus en plus son moyen de stockage. Exemple : Une disquette, un paquet logiciel, un email, …. Le document est une ressource ayant la possibilité de porter un état particulier et pouvant évoluer dans le temps. Cet objet a été rajouté par la société C - LOG International à son logiciel afin d’enrichir la méthode par une meilleure appréhension de l’évolution des Ressources.

Outil


Descriptif Tableau de suivi – Logiciel de références – Business Object

L’outil physique et/ou technologique est utilisé pour accomplir une opération. Il est utile de bénéficier de cet objet afin de rendre plus lisible et compréhensible une représentation. L’outil rattaché à une opération peut, en fonction du contexte être soit une ressource soit un outil (Exemple : une base de donnée est un outil si nous sommes sur un projet orienté Système de gestion de données, mais peut être une ressource si notre projet s’intéresse aux données stockées).



11. COMPLEMENT : METHODES ET OUTILS COMPLE-MENTAIRES

Ce chapitre présente des méthodes et outils qui peuvent être nécessaires à un enri-chissement ou une poursuite de l’étude. Merise est une méthode qui a beaucoup inspiré OSSAD, c’est d’une part pourquoi il m’était nécessaire de la présenter, et d’autre part car sa richesse m’a permis de mieux appréhender la notion de segmen-tation d’un système. Quand à Six Sigma, l’approche permettait d’apporter une forte sensibilisation à la raison de l’étude (la notion de satisfaction, de qualité). UML a surtout été un outil pour représenter les macros modèles d’OSSAD. Il est à noter que certain diagrammes peuvent être assez semblables à ceux d’OSSAD, sans néanmoins être liés entre eux.

11.1. Six Sigma

Six Sigma a été mis en place aux Etats - Unis, chez Motorola, dans les années 1980. A l’origine cette méthode était fondée sur l’analyse statistique de processus afin de faire apparaître la notion de variabilité et de défaut. Cette méthode a été mise en place dans un univers industriel afin de réduire de façon drastique les coûts de pro-duction et améliorer la disponibilité des machines. Après mûrissement auprès de nombreuses entreprises qui l’ont utilisé, Six Sigma s’est enrichi afin de prendre en compte l’aspect stratégique et managérial (notamment chez Général Electric). Toute la philosophie de cette méthode est fondée sur la notion de variable. Ce qui fait la qualité pour un utilisateur/client final, c’est le delta entre le temps où est at-tendu le produit ou service et le temps ou ce dernier est réellement livré. Ce delta, représenté par une variable est dépendant de la variabilité des processus qui permet au produit ou service d’être livré. Il est donc nécessaire de chercher et corriger les causes de la présence de cette variabilité. Cette recherche peut se faire avec un outil classique qui est le QQOQCCP, le diagramme d’Ishikwa. 37, ...

Figure. 69 - Six Sigma - Coubre de satisfaction avant

37 Voir le chapitre outil/QQOQCCP



Sur cette figure, on constate à travers des statistiques, que la livraison d’un produit ou service s’étale dans le temps autour d’une cible (plage de tolérance). Des spécifi-cations donnent un cadre à la période pendant laquelle le produit ou service doit être livré. Ce qui se trouve en dehors de cette plage peut provoquer de l’insatisfaction.

Figure. 70 - Six Sigma - Courbe de satisfaction après

A l’issu d’un projet Six Sigma, la cible devrait ressembler à cette figure. On cons-tate que la courbe de livraison s’est fortement réduite dans ses extrémités afin de rester entre les spécifications. La méthode Six Sigma est très orientée vers la qualité de service livré à l’utilisateur final ou client. Elle est fondée sur la mise en place d’indicateurs de performance, de la mise en place d’une organisation des compétences et responsabilités des person-nes et d’une méthode de résolution de problème. Cette méthode s’applique à travers la mise en place d’un projet formel et la démar-che de résolution de problème peut être décomposée en huit étapes (Reconnaître, Définir, Mesurer, Analyser, Améliorer, Contrôler, Standardiser, Intégrer), les cinq étapes de base sont appelé DMAIC. L’objectif final étant de réduire les occurrences d’insatisfaction de par la présence de nombreuses variations, l’ensemble de la ré-flexion est posée sur la notion de mesure : mesurer ce qui existe, ce que l’on veut, comment on le suivra, …. L’intérêt de Six Sigma dans notre étude est d’apporter une réflexion sur la nécessité d’améliorer une organisation en considérant la notion de variabilité. Sur un compor-tement non anticipatif, la relativité des choses fait qu’un environnement de qualité est dépendant d’un ressenti des composants de cette organisation : si, de par des ha-bitudes, il apparaît une satisfaction d’usage alors peut - on dire pour autant que les livrables de cette organisation donnent pleine satisfaction à leurs utilisateurs ? Peut - on dire qu’ils vont donner pleine satisfaction à court terme ? La réponse peut se trouver dans la lecture d’indicateurs (un des éléments contraignant d’ISO 9000 V2000), mais s’il n’existe pas d’indicateurs, ou que ces derniers ne sont pas adaptés alors une des rares solutions possibles, en dehors de l’escalade sur un problème blo-quant, est la prise de conscience. Six Sigma apporte des arguments relatifs à l’importance d’indicateurs et des spécifications pour une satisfaction finale. Dans notre étude, notre objectif étant de de comprendre une organisation en la considé-rant sous trois vue. La connaissance d’une méthode comme Six Sigma (entre autre) permet d’aider à comprendre qu’il peut être nécessaire d’améliorer un existant.



11.2. MERISE

Merise est une méthode française qui a été mis en place par le Ministère de l’Industrie en 1979 (recherche de 1974 à 1978). L’objectif était de mettre en place une méthode systémique d’intérêt national. Cette méthode devant intégrer l’approche par les données et une démarche garantissant une rigueur et une facilité d’application sur le terrain. Pour MERISE, la description des données est primor-diale. Cette méthode est très complète et s’appuie sur 4 niveaux d’abstraction regroupé en deux systèmes :

- Le système d’information Organisationnel (SIO) avec les niveaux : Conceptuel : exprime les choix de gestion (recherche d’éléments stables indépendamment des moyens à mettre en œuvre, de leurs contraintes et de leur organisation). Organisationnel : exprime les choix d'organisation de ressources humaines et matérielles.

- Le système d’information Informatique (SII) avec les niveaux : Logique : exprime les choix de moyens et de ressources informatiques, en faisant abstraction de leurs caractéristiques techniques précises (aspect logiciels). Physique : traduit les choix techniques et la prise en compte de leurs spécificités (aspect techniques).

Pour chacun de ces 4 niveaux, Merise définit des modèles de représentation :

Fort

(Nive

au d

e dé

tails

)

faib

le

Figure. 71 - MERISE – Les modèles de données et de traitements



Chacun de ces modèles permet de reproduire un système donné à travers l’usage d’une grammaire visuelle et de règles précises de représentation. MERISE ne s’arrête pas à une modélisation, un ensemble de livrables, des cycles de décision, une méthodologie d’application, … apporte tous les éléments permettant de réaliser un projet complexe. Merise, est aussi une méthode systémique, très orientée vers de la modélisation pour réalisation d’application (incluant une forte notion de base de données). Cela signi-fie que la méthode touche l’aspect organisation et ses processus en vue de réaliser un développement, pas forcément pour modeler les rôles et activités de l’organisation, elle ne semble pas offrir de concepts forts permettant de représenter la dimension humaine, tandis que la méthode OSSAD propose un diagramme, dé-nommé "réseau de relations entre rôles" permettant de représenter à la fois les Inte-ractions personnelles dans une Relation et ceci au sein d'une Unité organisation-nelle. Un autre aspect important concerne la richesse de Merise qui rend cette méthode plutôt difficile à appréhender pour un projet où le maître mot est simplici-té. OSSAD possède cette simplicité qui permet de rapidement communiquer avec les acteurs du projet et de se concentrer sur la substance du projet plutôt que sur sa méthode. Enfin pour finir il est intéressant de prendre en compte que OSSAD s’est beaucoup inspiré de MERISE, entres autres. .

11.3. UML

UML (Unified Modeling Language) est un langage de modélisation orienté objet pour représenter, spécifier, construire et documenter des constituants logiciels. Il a été développé et standardisé par Rational Software Corporation et Object Manage-ment Group (OMG) à partir de 1997. L'OMG est un organisme professionnel re-groupant à la fois des fournisseurs de solutions informatiques et des utilisateurs. Il s'est donné (entre autres) comme mission de promouvoir et de faire évoluer UML. Ce langage de modélisation est à la base très orienté pour le développement, ceci en couvrant les principales étapes du cycle de vie d’une application (Analyse, concep-tion et implémentation) par l’usage de trois familles de vue et de neuf types de dia-grammes : Les 3 familles de vues :

La vue fonctionnelle : les services offerts à l’utilisateur, Le diagramme de cas d’utilisation : représente les comportements d’un système du point de vue de l’utilisateur, Le diagramme d’activités : décrit les flux entre activités au sein d’un système. Cela permet de représenter le déroulement d’une procédure ou d’une fonction, Le diagramme de séquence : représente les objets et leurs interactions selon une ligne temporelle,



La vue statique : La structure des données et des objets, Le diagramme de classes : représente la structure statique d’un système sous la forme de classes et de relations et ne contient pas d’informations temporelles. Une classe est une représentation abstraite d’un ensemble d’éléments similaires, Le diagramme d’objets : représente les objets et leurs relations, un objet étant un élément particulier d’une classe, Le diagramme de composants : montre l’implémentation physique d’un système, en termes de composants logiciels, Le diagramme de déploiement : décrit la configuration des éléments de traitement à l’exécution et les composants qui leur sont rattachés,

La vue dynamique : Les flux d’information et les interrelations des données et objets,

Le diagramme de collaboration : représente les objets, leurs liens et leurs interactions de manière structurelle, Le diagramme de transition d’états : exprime le comportement dynamique d’un objet en termes d’états, d’activités, de transitions et d’événements.

Les diagrammes qui pourraient être utilisés pour représenter une organisation se-raient ceux de la famille fonctionnelle enrichie du diagramme de collaboration. Dans le cadre de notre étude, nous avons utilisé les diagrammes de classe qui nous ont permis de documenter, entre autres, les vues OSSAD. C’est pourquoi nous avons décrit les objets et leurs représentations utilisées dans le cadre d’un dia-gramme de classes UML.

CLASSE : Description générique ayant des caractéristiques propres pouvant représenter des objets. Dans le cadre de notre étude nous utiliserons des objets de méta - modèle. Il est à noter qu’une classe comporte des objets (occurrence d’une classe ayant un état et un comportement), des attributs (type d’information qui constitue une classe), et d’opérations (élément représentant un comportement (calculs, actions, . .), se trouvant dans une classe). Ces éléments ne seront pas utilisés dans le cadre de cette étude. Exemple : Les classes « processus «

Figure. 72 - UML – Une Classe

ASSOCIATION : Une association est une relation continue et durable entre deux classes Exemple : L’association « gère et utilise » entre « procédure » et « Ressources »

RessourcesProcédure

-Génère

0..*

-Provient

0..*

Figure. 73 - UML – Une association



MULTIPLICITE : Figure aux 2 extrémités d’une relation et indique le nombre d’objets pouvant parti-ciper à la relation dans chacun des sens (Classe 1 vers classe 2, et vice versa) Exemple : « Procédure » génère aucune ou une infinité de « Ressources » « Ressources » provient d’aucune ou d’une infinité de « procédures »

Figure. 74 - UML – Une multiplicité

AGREGATION : Une agrégation est une relation (ASSOCIATION) particulière, unilatérale, de contenance Exemple : La classe « Procédure » est une agrégation de la classe « Tâche »

Figure. 75 - UML – Une Agrégation

La forte richesse d’UML nécessite une appréhension de tous les diagrammes et du dictionnaire associé afin de maîtriser convenablement le langage. Le mélange entre la notion de rôle et d’acteur est un manque dans la cartographie des processus d’organisation. De plus UML ne permet pas de représenter la nature des informa-tions qui circulent entre acteurs (données, documents, paroles, …). La notion de système et de sous - système imbriqué est difficilement représentable. Cette mé-thode est meilleure en définition de besoin orienté application que orienté organisa-tion. Elle a un plus sur OSSAD qui concerne le diagramme de séquence d’UML contenant la notion de chronologie.

11.4. Ishikawa.

Du nom de son auteur (professeur Ishikawa, Président de l’Institut de Musashi), ce diagramme en forme d’arrête de poisson, permet de décrire des causes pour un effet donné. Sa représentation se fait à l’aide d’une flèche principale horizontale qui pointe vers un résultat cible (la dorsale), elle représente l’Effet, le résultat recherché. D’autres flèches pointent alors sur cette dorsale (les arrêtes), et sont les Causes. Ces arrêtes peuvent être subdivisées autant de fois qu’il est nécessaire. Afin d’aider au regroupement des causes la méthode conseille d’utiliser ce qui est appelé aux États - Unis : les 5M :



Men : Les hommes Matérial : La matière, ce qui est consommable Méthods : La méthode, ce qui est une façon de faire Milieu : L’environnement Machines : Les machines, ce qui nécessite un investissement

La meilleure façon d’utiliser cet outil est de commencer par un « remue méninges ». Qui a comme objet de récupérer un maximum d’information, sans aucune contrainte et sur un sujet donné.

Figure. 76 – Le modèle de diagramme de causes à effet

Ce diagramme de cause à effet est très judicieux car il permet de représenter un « écoulement » des causes apportant un effet. L’intérêt premier étant d’organiser un ensemble d’information et surtout de les lier entre elles, ce qui est souvent difficile sans formalisation. Ishikawa sera utilisé dans le cadre de notre étude de deux façons :

Pour déterminer une organisation cible sur une partie de nos représentations. L’idée sera de partir d’un élément qui paraît perfectible pour remonter aux causes qui pourraient être objet d’amélioration. Dans ce cas nous n’utiliserons pas les 5 M, mais d’autres familles, en fonction de notre recherche. Pour représenter l’ensemble des informations (ordres, communication) ou objets (mail, livrables, …) permettant d’activer une action. C’est en fait la description des entrées d’un processus. Effectivement au cours de la MPP, un grand nombre d’informations transite par un grand nombre de média. Ces informations, pour la plupart ne sont pas formalisées et nécessitent d’être « mises à plat » afin d’être maîtrisés.



11.5. La Loi de Pareto « L'économiste italien Vilfredo Frédérico Damaso surnommé par ses étudiants : "Marquis de Pareto" observa au début du XXème Siècle que 20% de la population italienne possédait 80% des richesses nationale d'où le nom de la loi 80 - 20 ou 20 - 80. » [Wikipédia]. Aujourd’hui, plus communément, c'est un graphique (histogramme) qui représente les données quantitatives relatives à un même sujet. Il est fondé sur le principe que 20 % des facteurs expliquent 80 % des résultats. En étant un moyen simple pour classer des phénomènes par ordre d’importance, il permet de se concentrer sur les causes majeures d’un fait (problème, résultats, . .). La démarche consiste à : établir une liste de données (nommées : les facteurs), les quantifier et les regrouper, faire un pourcentage pour chacune de ces valeurs, et après les avoir triées, les représenter sur un graphique. Exemple : 80% du chiffre d’affaire est généré par 20% des produits d’une entre-prise.

Figure. 77 – Pareto ou le 80/20

Dans le tableau (Figure. 40 – Pareto ou le 80/20) on remarque que 80% des occur-rences proviennent de 20% des éléments mesurés. Bien sûr les valeurs peuvent être



différentes du 80 ou du 20, l’important étant de se concentrer sur un périmètre ré-duit mais très significatif. La loi de Pareto (des 80/20) est à considérer comme étant une réflexion sur le fait qu’une minorité de faits produit une majorité de résultats. En générale, la démons-tration s’appuie sur des relevés numéraires permettant de faire des graphiques ex-ploitables. Dans notre étude, nous utiliserons cette loi comme filtre qui nous per-mettra de restreindre notre réflexion qu’aux actions majeures, dans un premier temps. Par la suite un grand nombre de cas particuliers pourront ressortir (les 80% restant), nous essaierons d’en lister quelques uns afin de démontrer que peut être il serait nécessaire de gérer ces cas particuliers à part. Nous n’utiliserons donc pas l’aspect numérique qui est souvent constaté dans l’usage de cet outil, mais plutôt la notion des 80/20, notion assez subjective mais qui permettra, au cours d’entretiens, d’aider à ne pas se focaliser sur des cas particuliers.



12. COMPLEMENT : RECUEIL DES COMPOSANTS DE LA MPP L’ensemble de cette partie regroupe les informations nécessaires à la construction des représentations. Ces informations, regroupées par familles et par type provien-nent en premier lieu de la méthodologie AGATHONE, puis d’entretiens avec les acteurs de la MPP, ainsi que de l’expérience acquise sur le poste de pilote MPP. El-les ont été ensuite enrichies dans le cadre d’un transfert de compétence. Les regroupements ont été fait de façon à être les plus exploitables par les graphi-ques de représentation, ceci en faisant ressortir le plus possible :

Les rôles Les activités Les livrables Les sources de regroupement d’information (réunions, outils, . .)

12.1. Les Pôles autour de Cristal

Nous appelons pôle un regroupement de rôles servant des objectifs communs au sein d’une unité organisationnelle. Il peut être composé au minimum d’un rôle. (Figure. 27 - OSSAD – Méta Modèle descriptif de rôles (UML)) Les pôles majeurs liés à la MPP sont :

Les utilisateurs de Cristal : Les Directions Régionale

La MOE CRISTAL : La qualification, le référentiel, les études, la MPP.

La Direction de service : Le support niveau 3.

La Tierce Maintenance Applicative CRISTAL : La réalisation.

La production informatique : L’exploitation, l’intégration, l’installation.

La chaîne de soutien : Le support niveau 2, le support niveau 1.

Autres : La généralisation, le support métier, la Maîtrise d’ouvrage la qualité (les tests et mesures).



12.2. Le Pôle MPP

12.2.1. Les livrables

Scénario de MPP Plan de travail commun Planning de MPP Reporting MPP (CR réunions de suivi) Plan de mobilisation Annuaire de la MPP Dossier de Mise en Place Pilote Ordre d’installation Fil conducteur et compte rendu de réunion de GoNoGo MPP Mètre Contrat de Mise en Place Pilote Bilan de MPP Tableau de suivi des signalisations Enquête de satisfaction Présentation de la version aux contributeurs Présentation de la version à la DR1 Fiches de test Fiches croisière Lot Qs Fiches croisière Évolution Exercices sur les évolutions (cf présentation contributeurs) Documentation utilisateur Lot QS (peut être la doc de SOPRA) Fiche de demande d’ouverture de la file MPP (P10) Scénario de retour arrière Tableau des temps de réponse Liens vers les modes opératoires métier

12.2.2. Les outils

WebDoc Excel 26D Sonde Vantage OGA (PVCS) Genesis

12.2.3. Les réunions

Réunion de lancement signalisation



Réunion de lancement installation Réunion de lancement MOE Réunion de lancement Présentation de la version à la DR Réunion de lancement Présentation de la version aux Contributeurs Réunion de tests sur la version pour contributeurs et utilisateurs Réunion de suivi des signalisations (Récurrente) Réunion de suivi de la MPP avec la DR (Récurrente) Réunion de validation de l’Ordre d’Installation (Récurrente) Réunion de suivi de l’installation (Récurrente) Réunion de présentation des fiches croisière Réunion de présentation des fiches de tests Réunion de présentation de l’organisation MPP

12.2.4. Les rôles

Préparateur MPP Recensement des pré - requis - post - requis Recensement des évolutions Recensement des fiches correctives (Lot QS+…) Montée en compétence sur les évolutions de la version Montée en compétence sur les correctifs (ou correctives) de la version Choix des sites Pilote

Organisateur de la MPP Définir le planning de la MPP Définir le séquencement des actions de MPP Constituer l’annuaire de la MPP Réaliser le contrat Réaliser le dossier de MPP Préparer le GoNoGo Préparer le Bilan Définition de l’organisation de suivi des évènements

Animateur Présentation « rapide » de la version aux contributeurs (large) Présentation de la version aux contributeurs + utilisateurs Création du document de présentation global Création des documents d’exercices sur la version (DoFo) Organisation de la journée

Sélection et invitation des invités (cf MOA) Réservations, aménagement, impression, . . Déroulement de la journée Réalisation d’une synthèse

Présentation de la version à la DR Adaptation du document de présentation global

Présentation des fiches de croisière à la DR Adaptation du document de présentation (évolution) Qualification du lot QS pour lisibilité et reproduction (lot QS)

Présentation des fiches de contrôle à la DR



Définition des fiches de test en fonction de la version Présentation de l’organisation de suivi des évènements

Pilote Demande de mise en place des sondes Mettre à jour le référentiel des documents Réaliser le reporting du suivi de la MPP Installation

Détermination du périmètre à embarquer (référencement) Constitution de l’Ordre d’Installation Validation de l’Ordre d’Installation Planning de mise en production MPP Livraison des PL Répétition d’installation Définition du planning Constitution des paquets (Kim) Tests d’installation Installation Création du plan de mobilisation

Pré et Post requis Lancer une demande de mesure des temps de réponses Autres actions dépendantes de la version

Des événements Demande d’ouverture de file MPP (P10) Suivre l’ensemble des évènements MPP Signalisation, interrogations, évolutions Passage en revue, récurrent, des évènements Mise à jour du tableau de suivi des événements

12.3. Les Pôles contributeurs directs

12.3.1. La qualification

12.3.1.1. Les rôles

Pilote de qualification Défini le plan de qualification Suit la réalisation du plan de qualification

Gestionnaire des environnements techniques Administrer les environnements (plate - formes)

Responsable des tests Qualifieur du SI

Rédige des dossiers de tests Fait les test Rédige des fiches de bug

Expert fonctionnel Expert technique



12.3.1.2. Les outils

26C : Cartographie du SI en développement 26D : Cartographie du SI de référence Référentiel JE : Base contenant les cas de tests (description du cas, mode opératoire). Une copie de ce référentiel sera transmise à DFO à chaque évolution majeure (prise en compte d’une nouvelle fonctionnalité, nouvelle interface) afin de pouvoir réaliser les TI

Gestion de Campagnes : Association d’un cas de test (JE) à une sous - campagne – Suivi de l’avancement d’une campagne et de ses sous - campagnes

FLEMIX : Lecture simplifiée des fiches 02Z et SNAT comparaison avec les contrats d’interface rattachés

PVCS TRACKER : Gestion et suivi des fiches d’anomalies (en client léger ou client lourd) AppCreerCommande : invocation du service de création de commande à partir d’un message LPA de création de commande codé dans un fichier texte, récupération dans un fichier texte du retour de la méthode (qui mentionne le statut SI de la commande). AppCreerCommande donne accessoirement la possibilité d’appeler le service de création de commande avec des commandes LIA. Cette possibilité est utilisée lors des phases de tests unitaires avec des commandes LIA. InterPublication : interception des évènements opérationnels publiés par SERVICES CRISTAL, et consignation de ces derniers dans un fichiers texte. OrdoSCris : lancement manuel de la procédure de relance des commande en attente, et de la procédure de publication des évènements opérationnels (nécessaire en l’absence d’ordonnancement). IHMTRAD : atelier de mise au point et de tests unitaires des règles de traduction LPA – LIA.

12.3.2. Le référentiel

12.3.2.1. Les rôles et activités associées :

Gestionnaire des installations, versions et correctives Vérifier les PL et la documentations associées Suivre les patchs du référentiel

Gestionnaire de logiciel (Gestion de configuration.) Référencer des PL Cristal Référencer des versions catalogue Référencer des versions Tables de références Référencer des versions Règles de traduction Contrôler les livrables à leurs réceptions

Producteur du catalogue 1 Réception fiche d’ordre (de Mise à jour, de création, de suppression) 2 Qualification de la fiche 3 Mise à jour du modèle de catalogue 4 Vérification des erreurs de saisies



12.3.2.2. Les livrables

(DGP/FAC) Fiche OSI : Complément fiche OSI : CR Hebdo FCF :

Soutien Fiche de signalisation :

Autre Fiches produit (OCISI) : PMP Catalogue : MOP (Version SI) : Planning d’installation : Flash info : Extrait du catalogue Cristal (OCISI) : Catalogue Cristal Packagé : PV de recette d’industrialisation technique : Bilan de MPP :

12.3.2.3. Les outils

(A) Forms Oracle (Mise à jour du modèle de catalogue) (B) Extraction (Création du Produit Livrable Data

12.3.3. Les études

12.3.3.1. Les rôles et activités associées :

Expert fonctionnel Concepteur

Réceptionne une demande MOA/étude Qualifie la demande de la MOA/étude = valide l’expression du besoin MOA Propose une/des solutions (s) Spécifie le besoin fonctionnel Valide les spécifications détaillées « Marchande » le chiffrage de l’évolution Met à jour la documentation fonctionnelle Valide les dossiers de tests de la qualification Propose des études de faisabilité : nouveauté lié aux restrictions de budget = prise en compte de la demande à SI constant ou 0 euro Propose des solutions à certaines fiches de bug jugées comme évolution et non bug Présentation des évolutions au :

Soutien N2/N3 MPP qualification



Support Études Aide à la MPP : répondre aux questions Aide à la MOA : idem

12.3.3.2. Les livrables

Accusé de réception de la demande : Dossier de qualification de la demande : Dossiers d ’étude de l ’existant : Dossier d ’architecture fonctionnelle transverse : Dossier d ’étude des scénarios : Glossaire : Synthèse d ’étude : Dossier de synthèse des modifications apportées au SI DAE (Dossier d’architecture) ? : DM1 : DM2 : CR de revue du DM2 : CI/DI : DM3 : DFG : CR de revue du DFG : Demande d’avis d’urbanisme

12.4. Les Pôles contributeurs indirects

12.4.1. Les rôles

Accompagnateur métier (SPOT) La MOA Chef de Projet Version

Faire le Macro Planning du projet Chef de projet DR Packageur logiciel (Kimmeur) - Intégration Pilote d’exploitabilité – Exploitation Réalisateur développeur (Sopra) Réalisateur développeur (Ordo_DR)



12.4.2. Les livrables

Ordre d’installation (en entrée) AppliOP Documentation d’exploitation



13. COMPLEMENT : DOCUMENTATION DES ACTIVITES AGATHONE MPP

Ces informations ont été reprise pour la plupart des fiches explicatives de la métho-dologie AGATHONE, et adaptée afin de correspondre à l’environnement CRIS-TAL. L’ensemble des descriptifs suit les représentations d’OSSAD (description in-sérées dans OSSAD pour décrire les processus et activitées).

13.1. Descriptif des processus AGATHONE

13.1.1. (A) MO_ORGANISATION, AVANCEMENT ET SUIVI Processus non décomposés Description

(A) CONSTITUER L EQUIPE DE LA MPP

Composer une équipe pluridisciplinaire en correspondance avec les besoins du projet . . Définir les compétences requises pour les différentes activités de la MPP : . . les impacts métiers. . l'installation . . les impacts clients. . l'exploitation . . la communication. . le suivi de la MPP, le soutien . . la formation. . les enquêtes utilisateurs . . la gestion de la documentation . . la gestion des signalisations et des livraisons . . . . Identifier les contributeurs de la MPP (en définissant la mission de chacun) et de-mander la nomination d un responsable (ou d un correspondant) par entité . . Constituer l équipe de la MPP avec les ressources définies et nommer un leader applicatif ayant des compétences fonctionnelles et techniques si besoin

(A) CONSTITUER L'EQUIPE LOCALE DE LA MPP

Avoir un correspondant du projet dans chaque entité impactée par la MPP . . Faire construire au chef de projet site pilote l'équipe locale de la MPP en s'ap-puyant sur : . . les compétences de chacun . . l'organisation nécessaire à la MPP . . Mettre à jour le plan de mobilisation

(A) CONSTITUER LE REFEREN-TIEL ET CENTRALISER LES DOCU-MENTS

Préparer la documentation pour sa diffusion . . En attente de l organisation cible : . . répertorier la documentation auprès de chaque projet . . lorsque tous les documents sont répertoriés, alimenter le tableau » référentiel documentaire » du projet . . effectuer le ciblage par profil, en indiquant (dans le tableau » référentiel documentaire » ) si le document est diffusé pour information ou pour action . . centraliser la documentation pour la duplication et la diffusion selon les modalités de la procédure de gestion de la documentation

(A) CONSTITUER LES LOTS DO-CUMENTAIRES, DIFFUSER ET POINTER LEUR RE-CEPTION

S assurer de la diffusion et de la prise en compte de la documentation . . Vérifier que le format des documents centralisés correspond à l'attendu . . Dupliquer la documentation (CDrom ou papier), ou assurer la mise en ligne des documents . . Constituer les lots à diffuser en s'appuyant sur le référentiel documentaire et sur l'annuaire des destinataires . . Envoyer au chef de projet site pilote le référentiel documentaire, une lettre d'ac-compagnement décrivant le contenu des lots, et, si envoi papier, un accusé réception à retourner . . Si envoi papier, . . prévenir les destinataires de la diffusion des documents en envoyant une fiche » avis de diffusion » par fax ou mail 48h avant l envoi des lots . . S'assurer que tous les acteurs ont bien reçu l'ensemble de la documentation (re-tour des accusé réception) . . Faire un compte - rendu au Pilote et au MOE généralisation

(A) DEFINIR L ORGANISATION POUR LA DIFFUSION DES DOCUMENTS

Avoir un circuit de diffusion des documents fiable auprès des destinataires . . Etablir les modalités de diffusion de la documentation adaptées au support défini (papier ou en



ligne) . . Identifier les acteurs pour : . . la duplication (support papier ou CDrom), ou la mise en ligne des documents . . la diffusion : si une mise en ligne est prévue prévoir les outils et les compétences nécessaires . . la réception par les destinataires finaux (rédiger l'annuaire des destinataires) . . Pour chaque flux, arrêter les dates de livraisons et communiquer le rétro planning aux équipes projet

(A) DEFINIR POUR CHAQUE ETAPE DE LA MPP LES RESSOURCES A MOBI-LISER

Prévoir les moyens nécessaires à la MPP . . Identifier les acteurs locaux, leurs tâches (en terme de charge) . . Le chef de projet site pilote . . Les correspondants locaux . . Le soutien niveau 1 (soutien applicatif, soutien technique) . . Le responsable qualité des données ... . . . . Définir les conditions de fonctionnement, les périodes de sollicitation et les enga-gements pour chacune des phases de la MPP (préparation, installation, suivi, bilan) . . Décrire pour chaque acteur local et national, les périodes et les charges par tâche dans le plan de mobilisation

(A) DESIGNER UN CHEF DE PROJET SITE PILOTE

Avoir la contribution d un responsable site qui mobilise les acteurs et coordonne les actions de préparation et de suivi . . Faire identifier un responsable au niveau de chaque site pilote (chef de projet site pilote) qui soit le point d entrée unique pour le site (même pour les établissements qui ne sont pas sous la responsabilité de l entité signataire du contrat) . . Faire nommer et établir la lettre de mission du chef de projet site pilote . . Intégrer le chef de projet site pilote à l'équipe de la MPP

(A) ELABORER LE PLAN�DE TRA-VAIL COMMUN

Identifier l ensemble des tâches et les acteurs de la MPP . . A partir du Plan de Travail Commun type, lister les tâches nécessaires à la MPP . . Ajouter si nécessaire des tâches spécifiques au projet . . Définir pour chaque tâche les dates, le responsable et les acteurs . . Alimenter le Plan de Travail Commun (PTC) pour suivre l avancement de la prépa-ration de la MPP

(A) ELABORER LES PRE - REQUIS DE LA MPP

Définir les conditions de Go/No Go MPP . . Etablir la liste des pré - requis techniques amont à la MPP : . . issus de l'intégration (PV de recette d'intégration, liste des anomalies résiduelles, ...) . . issus des normes du déployeur technique et du pilote de l exploitabilité (recette d'exploitabilité, métrologie, cahier de sécurité, . .) . . remettre à jour cette liste en tenant compte de la recette d'exploitabilité provisoire (feux rouges, feux oranges, feux verts) . . Etablir la liste des pré - requis (organisationnels, techniques, métiers et applicatifs) à vérifier sur le site pilote, distinguer : . . les pré - requis nécessaires pour le déploiement : les intégrer au phasage type . . les pré - requis spécifiques à la MPP (outil de gestion des signalisations, ...) . . Constituer la liste des pré - requis de Go/NoGo d'après la synthèse de ces listes . . Vérifier que pour chaque pré - requis sont définis : . . les dates de réalisation . . le responsable et les acteurs

(A) FINALISER ET DIFFUSER LE DOSSIER DE BILAN

Formaliser les éléments du bilan dans un document . . Finaliser le dossier de bilan de la MPP qui comprendra les points suivants : . . rappel des objectifs de la MPP . . rappel du contexte de la MPP . . évaluation des aspects techniques (installation, production) . . évaluation des aspects fonctionnels . . évaluation des conditions de la MPP . . évaluation de l'appropriation des évolutions et des changements métiers par les utilisateurs . . bilan général du projet . . annexes (référentiel logiciel, référentiel documentaire, synthèse des fiches de tâ-ches de contrôle, signalisations non closes, tableaux récapitulatifs des signalisations, courbes des signalisations, bilans utilisateurs, bilan installation et production, CR de la réunion de bilan) . . Diffuser le dossier de bilan de la MPP

(A) NOMMER UN PILOTE ET ETABLIR LE FONCTIONNEMENT DE L EQUIPE

contributeurs . . Nommer le pilote de la MPP . . Etablir le planning des différentes phases de la MPP à partir des dates clés déter-minées lors du J0 (période de début, de fin, de généralisation) en identifiant les tâches principales et



incontournables . . Réévaluer les charges et les ressources à partir de l évaluation faite pour le J0 . . Fixer les modalités de reporting interne à l équipe projet

(A) PARTICIPER A LA PREPARATION DU J2

Mettre en relief les éléments tangibles de la MPP permettant d asseoir la décision du J2 . . Faire la synthèse des bilans fonctionnels, métiers, techniques et financiers des si-tes . . Construire avec le MOA le plan d actions éventuel issu du bilan de MPP et nommer les acteurs chargés de réaliser les actions

(A) PREPARER LA REUNION DE GO - NOGO

Evaluer la préparation de la MPP et la qualité du logiciel pour permettre de prendre une décision argumentée sur le Go/NoGo . . Préparer la réunion de Go/NoGo en s'appuyant sur les plans d'actions fixés suite à l'analyse des résultats de la revue de qualité . . Faire une revue de qualité sur l'état de la MPP . . passer le MPPmètre . . présenter le diagramme de Kiviat au chef de Projet SI . . analyser les résultats et lancer des plans d'actions

(A) REDIGER ET FAIRE SIGNER LE CONTRAT DE MPP

Obtenir l engagement des représentants locaux et nationaux de la MPP . . Identifier les signataires du contrat de MPP . . Rédiger le contrat de MPP (pas plus de 7 pages) : . . Définir le cadre de fonctionnement de la MPP sur le site pilote . . décrire : . . les objectifs et les enjeux du projet. . l organisation de la MPP . . les dates clés du projet. . les acteurs concernés . . faire référence au dossier de la MPP . . Faire signer le contrat par le décideur local (exemple le Directeur Régional), par le MOA principal, par le responsable du centre de production et par : . . Soit le directeur du SN MOE SI (si c'est un projet transverse sur plusieurs direc-tions opérationnelles) . . soit le directeur de la Direction opérationnelle (ou le directeur de projet)

(A) REMETTRE A NIVEAU LE SITE PILOTE

S assurer de la remise à niveau le site pilote pour que celui - ci soit conforme à tout site mis en place lors de la phase de généralisation . . remettre à niveau la documentation utilisateur . . donner les supports de formation émis pour la généralisation . .

(A) REUNION DE GO - NOGO DE LA MPP

Suite à l examen des pré requis, évaluer l'état de la préparation de la MPP et prendre la décision stratégique de Go/NoGo après consultation des décideurs nationaux, des représen-tants des entités contributrices, des décideurs des entités du site pilote. . . Prendre la décision d'installer sur le site pilote à partir : . . du bilan des tests fonctionnels . . du rapport des résultats de la qualification ou des campagnes d'intégration de la métrologie et de la volumétrie, de la recette d'exploitabilité . . de l'existence de la check - list référentiel de la documentation . . de la préparation et du basculement du site

(A) REUNIONS DE SUIVI D'AVAN-CEMENT DE LA PREPARATION DE LA MPP

S assurer de l avancement de toutes les tâches de préparation de MPP . . Prévoir des réunions d avancement avec l équipe de la MPP et les contributeurs afin de faire le point (utiliser le Plan de Travail Commun) . . Suivre la production des livrables . . Suivre les vérifications des pré - requis . . Tenir à jour le planning de l équipe . . Alerter le chef de projet SI en cas de difficulté . . Faire un reporting régulier au chef de projet SI

(A) SUIVRE LE DEROULEMENT DU SITE PILOTE ET ASSURER LE SOUTIEN

Organiser le suivi et le soutien afin de garantir un accompagnement efficace du site et une évaluation exhaustive de la qualité des logiciels, des impacts métiers, clients, utilisa-teurs, . . Assister le site au démarrage de l'exploitation . . Animer des réunions périodiques de suivi pour faire l'évaluation de la MPP au fil de l eau : . . déroulement de l'exploitation . . avancement des contrôles de croisière . . point sur les signalisations . . difficultés rencontrées . . actions à venir et à entreprendre (campagne de mesures, installation d'un correctif) . . Prévoir des ponts téléphoniques pour la résolution de problèmes spécifiques (hors réunion de suivi) . . Rédiger le compte rendu de chaque réunion de suivi et le diffuser rapidement . . Déclencher si nécessaire des réunions en comité de crise



13.1.2. (A) MO_QUALIFICATION MOE SI Processus non décomposés Description

(A) CLOTURER LES SIGNALISATIONS

S assurer que toutes les signalisations émises ont reçu réponse pour se mettre en si-tuation de soutien de croisière . . Produire une synthèse quantitative et qualitative de l'ensemble des signalisations relatives au projet de manière globale et les répartir selon : . . leur origine . . leur type (incidents, questions, ...) . . leur criticité (bloquant, gênant, mineur) . . les réponses apportées, les palliatifs . . Informer le MOE généralisation, le soutien niveau 2, les formateurs, le MOE mé-tiers et les sites pilotes sur les signalisations n'ayant pas fait l'objet de correctifs ou de palliatifs . . Informer l équipe chargée de reprendre l application (activités récurrentes, )

(A) CONSTITUER LES DOSSIERS DE CONTROLES D INSTALLATION ET DE CROISIERE

Identifier les contrôles à effectuer . . Lors de l installation du nouveau produit . . Au cours de la MPP (croisière) . . Rédiger un dossier de contrôles d installation après basculement pour vérifier sur le site le fonctionnement de la nouvelle version. Il comprend : . . la liste récapitulative par item de l ensemble des tâches . . des fiches de tâches précisant : les pré - requis, les acteurs, la durée, les actions, le résultat attendu . . Rédiger un dossier de contrôles de croisière, pour tester les fonctionnalités lors de la MPP, comprenant : . . la liste récapitulative par item de l ensemble des tâches . . des fiches de tâches précisant : les pré - requis, les acteurs, la durée, le mode opératoire, le but, le résultat attendu

(A) FAIRE DES REUNIONS DE PREBILAN (PAR THEME) ET DE BILAN

Obtenir les éléments factuels d évaluation pour la décision de généralisation (J2) . . Faire, le plus tôt possible, des réunions de pré - bilan par thème (formation, instal-lation, métrologie, documentation...) . . Envoyer les fiches bilans aux acteurs concernés 10 jours avant la réunion . . Exploiter les fiches bilans retournées pour constituer les supports de la réunion . . Initialiser ou mettre à jour le dossier bilan . . Faire une réunion de préparation du bilan sur chaque site (en cas de sites multi-ples) . . Faire une réunion bilan physique tous sites pilotes confondus si les objectifs de la MPP sont les mêmes pour tous les sites. . . Faire rédiger au chef de projet site pilote un avis motivé et signé des décideurs lo-caux sur la généralisation (favorable, défavorable, réserves)

(A) FIXER L ORGANISATION POUR LA GESTION DES SIGNALISATIONS

Garantir un suivi rigoureux et efficace des signalisations . . Fixer le circuit de remontée en précisant . . les engagements pour la traçabilité des signalisations . . les engagements pour la résolution des problèmes bloquants . . Fixer les modalités du suivi et la périodicité des réunions . . Prévoir, si nécessaire, une formation pour les utilisateurs de l'outil de gestion des signalisations . . S assurer de la présence en nombre suffisant des soutiens locaux et nationaux et de leur disponibilité Associer fortement le soutien niveau 2 dans l organisation du suivi des signalisations

(A) GERER LES SIGNALISATIONS

Avoir un suivi rigoureux des signalisations émises par le site pilote . . Mettre en oeuvre la gestion des signalisations prévue : . . faire constater l'incident par le soutien niveau 1 et le faire initialiser dans l'outil de gestion des signalisations : préciser le contexte d'apparition de l'incident, ses conséquences, les messages d'erreur . . faire attribuer les signalisations par le soutien niveau 1 . . analyser/traiter les signalisations . . valider les corrections et clôturer les signalisations . . Produire les tableaux de synthèse . . Faire le point sur les signalisations lors des réunions de suivi de la MPP [La "fiche de signalisation" et la "fiche de réponse" figurent dans la procédure de ges-



tion des signalisations]

(A) ORGANISER ET EFFECTUER LA LIVRAISON DES CORRECTIFS

Avoir une procédure de livraison qui respecte les règles d installation et garantisse la mise à niveau du site pilote avec la version généralisée . . Définir le contenu des livraisons avec le chef de Projet SI et le (s) projet (s) en rap-prochement avec les signalisations (leur nombre et leur gravité) . . Planifier et confirmer les livraisons avec les différents acteurs, en rappelant et res-pectant le délai de préparation pour le déploiement . . Mobiliser les équipes locales et nationales comme pour l'installation initiale (cf. : MPP611, MPP614), . . Organiser les contrôles techniques et fonctionnels après l'installation des correctifs en ayant informé les utilisateurs sur les palliatifs à ne plus utiliser, les signalisations corrigées . . Mettre à jour le dossier de MPP (base du dossier de déploiement) . . Suivre les lots correctifs en configuration

13.1.3. (A) MO_INSTALLATION Processus non décomposés Description

(A) ADAPTER LES PRE REQUIS AVEC LE SITE PILOTE

Garantir des conditions nominales pour le déploiement du projet sur le site pilote . . Demander au site pilote une description précise de l'architecture technique, de l'en-vironnement fonctionnel et organisationnel (recenser les produits installés, ...) . . A partir de cette description, adapter la liste des pré - requis nécessaires au dé-ploiement sur le site en faisant ressortir les points à surveiller (spécificités locales) . . pré - requis organisationnels : utiliser des moyens techniques pour soulager un ser-vice (basculer les appels téléphoniques d'un service vers un autre pendant des forma-tions), . . . . pré - requis métier : préparer le planning éventuel d'intervention du MOE Métiers, ... . . pré - requis technique . . Planifier les horaires pour l'installation des applications . . réactualiser le planning prévisionnel suite aux contraintes locales (le faire valider par les acteurs concernés)

(A) CONSTITUER LE REFEREN-TIEL ET LE PACKAGE DES LOGICIELS

Après qualification du produit à installer, identifier et avoir un produit référencé et conforme aux normes d installation . . En fin d intégration : . . finaliser le « référentiel des logiciels » à embarquer en MPP . . produire la liste des anomalies résiduelles, les palliatifs et obtenir de l intégrateur le PV de recette d intégration . . demander au packageur l industrialisation finale des logiciels en s assurant de la purge des éléments obsolètes de l ancienne version . . faire tester auprès de l intégrateur le bon fonctionnement du logiciel packagé . . vérifier la conformité du package par rapport au logiciel intégré . . déposer le logiciel packagé à l organisme de référencement

(A) CONSTRUIRE LE SCENARIO DE MPP

Préparer dès la MPP un scénario proche des conditions de généralisation . . Prendre en compte s'il y a lieu, la stratégie et les contraintes de généralisation . . sur plusieurs types de sites . . sur plusieurs types d environnements techniques (par exemple : serveurs exté-rieurs)

(A) DECRIRE L ORGANISATION POUR LA DIFFUSION DES LIVRABLES LOGI-CIELS

Avoir un circuit et des règles de diffusion fiables et efficients . . Décrire les modalités de livraison (dépendantes de l environnement technique) pour chaque application du projet en identifiant l expéditeur et le destinataire final . . pour la version initiale . . pour les correctifs . . Adapter le document réponse de contrôle de réception pour chaque circuit confor-mément aux procédures . . Pour chaque flux, arrêter les dates de livraison et les communiquer aux équipes projet et au Chef de Projet Site Pilote

(A) DEFINIR LES CRITERES DE S assurer des caractéristiques nécessaires au site pilote pour répondre aux objectifs



SELECTION DE SITE du projet et être représentatif de la généralisation . . Définir la représentativité des sites par rapport aux exigences du projet : . . l environnement fonctionnel (présence de toutes les applications interfacées, mise en place de tous les postes de travail en configuration et organisation cible) . . le volume d activité, le nombre de postes de travail et leur répartition géographique, . . l infrastructure technique, l environnement d exploitation et les conditions d installa-tion, . . les profils utilisateurs (niveau de compétence et besoins en formation), la motiva-tion du site

(A) DESIGNER LES PERSONNES D ASTREINTES POUR L INSTALLATION

Organiser les astreintes pour garantir une installation sécurisée . . Désigner les astreintes : . . Nationales (MOE SI, pilote de l exploitabilité, déployeur technique, Réalisateurs, Concepteurs, ...) . . Locales (expert réseau, exploitant d'autres systèmes utilisés pour les contrôles d'installation) . . Prévoir les ponts téléphoniques (fonctionnels, techniques, ...) . . Préciser les délais d'intervention et les compétences nécessaires . . Distinguer les plages d'astreintes (physique/téléphonique) Faire valider l'annuaire et les numéros des ponts téléphoniques par les intervenants respectifs

(A) FAIRE UNE REPETITION D INSTALLATION

Vérifier les procédures d installation et de retour arrière . . cas de migration de base pour : . . s'assurer du bon déroulement des opérations conformément au phasage d'installa-tion . . vérifier les points de synchronisation, les points de contrôle, la volumétrie . . relever les temps de traitement pour faire une estimation fiable de l'opération réelle . . Tester la procédure de retour arrière Prendre les décisions nécessaires au bon déroulement de l'installation

(A) FAIRE UNE REUNION DE PRESENTATION TECHNIQUE DE L INSTALLATION

Informer et mobiliser les acteurs techniques sur les spécificités de l installation . . Présenter le déroulement détaillé : . . de l'installation . . des contrôles d'installation . . Présenter les tâches et les acteurs (connus du dossier de phasage) . . Identifier les positions de travail et les périphériques nécessaires aux contrôles d'installation . . Vérifier les pré - requis d'installation et la mobilisation des acteurs . . Dresser l'annuaire des intervenants . . S'assurer que les administrateurs des tables applicatives sont en possession des informations à saisir

(A) INSTALLER ET METTRE A JOUR LES TABLES APPLICATIVES

Assurer la mise en place des tables applicatives . . Installer les tables . . Saisir les données dans les tables applicatives ou récupérer des tables télédiffu-sées . . Faire les tests d'installation technique : tester la lisibilité de la table au moins à tra-vers un applicatif . . Faire remonter les signalisations éventuelles

(A) INSTALLER LES LOGICIELS Installer les logiciels en capitalisant pour la généralisation . . Installer les logiciels . . Noter la durée de chaque tâche . . Signer le procès verbal de recette d'installation et rédiger le rapport d'intervention . . Faire les tests d'installation technique . . Mettre à jour le dossier de configuration locale du site (ou du centre de production) . . Faire remonter les signalisations . . Rédiger rapidement le bilan de l'installation pour enrichir le bilan final

(A) INSTALLER LES MATERIELS, LES RESEAUX, LE MOBILIER, . .

Préparer le site à l installation . . Installer : . . les matériels (machines, stations de travail, ...) . . les réseaux (X25 ou IP) . . l'environnement technique (énergie, climatisation) . . le mobilier ... . . . . Penser aux éléments logistiques (bâtiments, ...) . . Faire mettre à jour la liste des pré - requis au pilote MPP

(A) LIVRER LES LOGICIELS, LES TABLES ET POINTER LA RECEP-TION

S assurer de la disponibilité des logiciels sur site pour l installation . . S'assurer de la disponibilité du logiciel et des tables chez le diffuseur accompagnés du bordereau de livraison . . Donner le feu vert au diffuseur pour la livraison au destinataire . . S'assurer de la réception par le destinataire nommé . . Pointer la livraison à l'aide du référentiel logiciel

(A) PRENDRE EN COMPTE LES IMPACTS SUR L ARCHITECTURE TECHNI-

Définir les adaptations techniques à réaliser sur le site pour les besoins du projet . . Recenser les besoins en infrastructure et en ressources nécessaires à l exploita-tion sur site



QUE, (matériels informatiques, réseaux, locaux, mobilier, ... .) . . Rédiger si besoin les procédures d approvisionnement . . Informer le fournisseur sur la prévision de commande

(A) REDIGER LE PHASAGE D INSTALLATION ET LES MODALITES DE RETOUR ARRIERE

Décrire l enchaînement des tâches qui garantit une installation opérationnelle et re-productible . . Rédiger le phasage d installation par type d'architecture technique en prenant en compte . . la métrologie rapportée au contexte terrain . . les acteurs . . les périodes de réalisation de chaque tâche . . les points de synchronisation . . des points de contrôle . . les actions à mener après l installation du logiciel . . Décrire le déroulement de retour arrière pour l ensemble des applicatifs . . Identifier les contraintes utilisateurs liées à l installation des applications (par exem-ple : indisponibilité des applications) . . Valider la durée et la période d installation avec le MOE généralisation

(A) VERIFIER QUE LES DOSSIERS D INSTALLATION ET D EXPLOITA-TION SONT REDIGES

Constituer une documentation technique, conforme aux normes d installation et d ex-ploitabilité . . Récupérer les dossiers d installation et d exploitation par application initialisés par les projets . . Ajouter la liste des composants logiciels (ajouts, modification, suppression) . . Regrouper ces dossiers par type d architecture technique (ATN, serveur UNIX, sys-tèmes nationaux, serveur DR hors UNIX, ...) . . S'assurer de la conformité avec les normes d'installation et d'exploitabilité : . . existence des procédures d installation et de désinstallation des logiciels . . identification précise des « feux » (verts, oranges, rouges) de la recette d exploitabilité provisoire

13.1.4. (A) MO_FORMATION METIERS Processus non décomposés Description

(A) APPROFONDIR LES IMPACTS METIERS ET CLIENTS

Déterminer l importance des impacts métiers et clients du produit pour construire le plus en amont possible les actions liées au métier et à la communication client . . Déterminer l'importance des impacts métiers à partir de la description du processus métier. Dans le cas d'impacts forts (nouvelle organisation, nouvelle position de travail, . .) pré-voir un accompagnement métier et l'implication des encadrants du site pilote, prendre contactégalement avec les syndicats et les ressources humaines (une expérimentation pré-alable à la MPP est prévue dans ce cas). . . Dans le cas d'impacts clients (modification des courriers, des contrats, de la fac-ture...), associer le service marketing de la Branche pour vérifier la prise en compte de ces impacts et leur évaluation dans le cadre de la MPP. . . S assurer que toutes les positions de travail impactées sont bien recensées et s assurer que les compétences à développer sont bien définies.

(A) ASSURER LES FORMATIONS Former la population ciblée lors de la préparation de la MPP . . Dispenser la formation technique . . aux exploitants . . aux installateurs . . Dispenser la formation fonctionnelle . . aux soutiens niveau 1 . . aux utilisateurs (formation assurée soit directement, soit par les soutiens niveau 1) . . Faire une évaluation à chaud de la formation

(A) CONCEVOIR LES DOCUMENTS UTILISATEURS

Donner les moyens aux utilisateurs de s approprier les nouveautés fonctionnelles et les processus métier . . Constituer un groupe pluridisciplinaire chargé de définir : . . les documents à produire, . . le support final (papier, mise en ligne, CDrom) en fonction du type de projet et des lecteurs cibles, . . le format intermédiaire (documents papier non reliés pour la reprographie, format électronique adapté pour un CDrom ou une mise en ligne),



. . les réalisateurs et les valideurs des documents.

. . Rédiger :

. . les fiches évolutions par application : si les impacts métiers sont faibles, les fiches évolutions peuvent être associées à la documentation utilisateur, . . les modes opératoires éventuels, . . la documentation utilisateur. S assurer que tout a été vu en faisant une visite sur le terrain

(A) ELABORER LE PRODUIT DE FORMATION

Répondre aux besoins en formation identifiés en fonction des évolutions Avec un groupe pluridisciplinaire : . . Analyser l'apport de l'application (delta pour les nouvelles versions, nouveaux utili-sateurs, nouvelles applications), déterminer s'il faut faire une simple information ou une forma-tion . . Cibler la population à former (soutien niveau 1, experts, utilisateurs, encadrants de proximité, exploitants, soutiens techniques, ...) . . Etablir un cahier des charges, en évaluant bien les coûts, les délais (validation du MOA) . . Définir le produit de formation : le contenu, la durée des formations suivant le type de population à former . . Choisir les outils, correspondant au produit de formation, adaptés aux contraintes du projet . . des VIF. . des bases écoles, des simulateurs interactifs . . des formations physiques (pour ces produits, anticiper les formations) . . Centre de Ressource Formation. . une cassette et un guide d accompagnement . . Réaliser les produits de formation et les supports associés

(A) ORGANISATION DES SESSIONS DE FORMATION

Assurer la mise en oeuvre de la formation en cohérence avec le planning de déploie-ment et la population à former . . Fournir au site les modalités de formation définissant : . . la durée, les moyens pédagogiques et les supports associés (base école, cassette, guide d'accompagnement, transparents, ...), la population à former, le lieu de la formation (VIF, physique, ...), la période prévisionnelle de formation. . . ordonnancer et planifier la formation . . identifier et dénombrer les personnes concernées . . constituer les groupes de formation . . installer l'infrastructure nécessaire à la formation . . vérifier la livraison des outils pour la formation (transparents, cassettes, ...)

13.1.5. (A) MO_COMMUNICATION Processus non décomposés Description

(A) ASSURER LA MONTEE EN COMPETENCE DES CONTRIBUTEURS NATIONAUX

Garantir la sécurité de la généralisation en préparant les acteurs du déploiement . . Cibler les acteurs nationaux devant monter en compétence : soutien niveau 2 (ap-plicatifs, métiers, ...), le MOE généralisation, ... . . Les faire participer à la recette pour leur permettre de comprendre le fonctionne-ment de l'application et les nouveautés. . . Faire informer par la MOE métiers le soutien niveau 2 sur les changements et les apports du projet. . . Faire former éventuellement par les formateurs le soutien niveau 2 à partir des pro-duits de formation préparés pour le site pilote.

(A) COLLECTER REGULIEREMENT AUX DIFFERENTS PARTENAIRES DE LA MPP AFIN DE RESTITUER

Tenir les responsables nationaux informés de l avancement du projet . . Collecter auprès des différents contributeurs de la MPP les informations concer-nant : . . les impacts métiers . . l'installation et la production . . le soutien sur site . . la documentation . . le suivi de la MPP . . les évaluations des formations . . le traitement des incidents . . Donner les informations au chef de projet SI pour qu il puisse faire le reporting du projet en



s'appuyant sur les informations précédentes. (A) COMMUNIQUER AUX UTILISA-TEURS SUR LA VIE DU PROJET

Maintenir les acteurs locaux informés des événements de la MPP . . Rédiger un journal (fréquence à adapter selon les événements) présentant la vie du projet et de la MPP : . . les éventuels dysfonctionnements . . les palliatifs . . le calendrier des correctifs . . les informations plus générales d'avancement . . Diffuser massivement le journal aux utilisateurs concernés par le projet

(A) FAIRE UNE PRESENTATION AUX EQUIPES PROJET ET AUX MOA

Assurer la communication aux équipes projet et à la MOA sur le contenu de la MPP . . Présenter : . . l équipe de MPP et son organisation . . le planning prévisionnel . . le scénario de MPP . . les impacts métiers et clients . . l avancement de la préparation de la MPP . . les objectifs du projet

(A) FAIRE UNE REUNION DE LANCEMENT DE LA MPP

. . présenter les nouveautés du projet aux acteurs locaux

. . les sensibiliser et les mobiliser sur la mise en oeuvre de son déploiement en site pi-lote . . Réunion de lancement de la MPP : . . Présenter . . l'objectif de la MPP et les nouveautés du projet . . les pré - requis. . le calendrier prévisionnel . . les rôles des différents intervenants. . le déroulement de la formation . . l'organisation de la MPP. . les actions de communication . . la charge des différents intervenants . . Recueillir . . les informations spécifiques au site (techniques, organisationnelles, ...) . . les informations nécessaires pour compléter le contrat et le dossier de MPP . . Faire une évaluation à chaud de la réunion (questionnaire d évaluation)

(A) PREPARER LE DOSSIER DE MPP

Formaliser les conditions de mise en oeuvre de la MPP . . Dans le Dossier de MPP, expliciter dans le détail le fonctionnement de la MPP sur le site pilote . . les objectifs du projet. . les nouveautés du projet . . les acteurs. . le planning de la MPP . . le déroulement de la formation. . le plan de communication . . les besoins en ingénierie. . la gestion des signalisations . . la préparation du bilan. . les besoins en matériel, en réseau . . Préciser clairement les rôles et les responsabilités des différents acteurs . . Joindre en annexe du dossier de MPP, le plan de communication, le plan de mobi-lisation, la procédure de gestion de la documentation, la procédure de gestion des signalisa-tions, les procédures de gestion des livraisons logicielles et de suivi des diffusions terrain.

(A) PREPARER LES ACTIONS DE COMMUNICATION

Concevoir une communication efficace, ciblée selon le profil des destinataires Définir les objectifs du plan de communication (information sur les évolutions et les vecteurs de communication, accompagnement du changement, identification et résolution des dif-ficultés) . . Elaborer le plan de communication du projet en différenciant la population qui doit être informée (les décideurs, le soutien, les utilisateurs, les encadrants, l'équipe technique, ...) . . Prévoir des supports de communication adaptés à chaque type de population, an-nexés des commentaires, et préparer des questionnaires d évaluation pour les différentes ré-unions . . Prévoir les dates des différentes réunions . . Prévoir si nécessaire une communication en interne (article dans journaux locaux, VIF, ) et s assurer que la communication éventuelle vers les clients de FT est prévue . . Insister sur le rôle et les responsabilités du site pilote . . Joindre le plan de communication au dossier de MPP

(A) PRESENTER LE CONTEXTE DE LA MPP AU CHEF DE PROJET SITE PILOTE

Préparer la construction du déploiement sur le site pilote avec le chef de projet site pi-lote . . Lors d une réunion d initialisation, présenter au Chef de Projet Site Pilote : . . les nouveautés du projet . . le planning prévisionnel de la MPP et les contraintes de déploiement (par exemple, les besoins en matériels, en locaux) . . les pré - requis nécessaires . . l organisation de la MPP . . les acteurs locaux et le plan de mobilisation . . le questionnaire d évaluation de la démarche qualité MPP et son objectif . . Initialiser, avec le Chef de Projet Site Pilote le PAQ site pilote (évaluation des ris-ques de la



MPP, gestion des signalisations et de la documentation). Prendre en compte les critè-res qualité du site . . Arrêter les dates adéquates d'installation . . Arrêter les dates prévisionnelles des différentes réunions

(A) PRESENTER LE PROJET ET LA MPP AUX ENCADRANTS DU SITE PI-LOTE

Sensibiliser l encadrement sur les apports et les contraintes du projet . . Présenter le projet et la MPP aux encadrants du site pilote . . insister sur les apports de l'applicatif (gain de productivité, gain de qualité du SI...). . . Informer les décideurs . . sur la formation prévue . . sur les actions de communication . . Rappeler les charges induites par la MPP pour les correspondants locaux et le Chef de Projet Site Pilote

13.1.6. (A) MO_RELATIONS AVEC LE SITE PILOTE Processus non décomposés Description

(A) EVALUER LE RESSENTI DES UTILISATEURS

Evaluer la satisfaction des utilisateurs . . Faire des visites sur le site pilote pour connaître le ressenti utilisateurs face : . . aux nouveautés du projet . . aux impacts métiers . . aux temps de réponse . . à la documentation . . à la qualité du logiciel . . à l accompagnement du changement . . Utiliser le questionnaire d enquête utilisateur et analyser les réponses de satisfac-tion utilisateurs

(A) IDENTIFIER LES SITES PILOTES POTENTIELS

Trouver des sites pilotes disponibles et correspondants aux critères identifiés . . Etudier les sites sur l ensemble des dimensions suivantes : . . Organisation . . Configuration matérielle . . disponibilité . . exploitation . . configuration logicielle . . dimension (volumétrie) . . Prendre en compte les déploiements prévus pendant la période de MPP . . Contacter les DED des sites sélectionnés . . Solliciter les responsables locaux

(A) OBTENIR L ACCORD DES DECIDEURS LOCAUX ET LA SIGNATURE D ENGAGEMENT

Faire confirmer aux décideurs leur accord et leur engagement dans la participation à la réussite du projet . . Organiser une réunion de présentation aux décideurs : . . s assurer de la présence des personnes concernées . . Actualiser (si besoin) le planning prévisionnel suivant les contraintes du site . . En cas d impacts sociaux importants, informer les organisations syndicales . . Demander au site pilote une lettre d acceptation

(A) PREPARER L ENQUETE DE SATISFACTION DES UTILISATEURS

Construire une enquête satisfaction utilisateurs pour l évaluation en fin de MPP. Cette enquête est l un des éléments permettant de prendre la décision de généraliser . . Préparer une enquête d évaluation du produit et du déroulement de la MPP . . Cibler la population qui doit être sondée . . Utilisateurs . . Exploitants . . Encadrants . . Soutiens niveau 1... . . . Définir les modalités d'accompagnement du questionnaire d enquête



13.1.7. (A) MO_QUALIFICATION UTILISATEURS Processus non décomposés Description

(A) EFFECTUER LES CONTROLES D INSTALLATION

. . Effectuer les contrôles d'installation conformément au dossier de contrôle d'installa-tion . . Vérifier la conformité par rapport aux fiches de contrôle . . Chronométrer la durée des contrôles . . Faire part des résultats du passage des contrôles au chef de projet site pilote

(A) INFORMER LES UTILISATEURS SUR LA PERIODE D ARRET DU SI

. . Informer les utilisateurs sur :

... . la date et l'heure de l'arrêt du système

... . l'heure prévisionnelle de reprise du SI

. . les applications indisponibles durant l'installation En cas de fermeture TP anticipée, formaliser la période d'arrêt avec le Chef de Projet Site Pilote (acceptation écrite)

(A) S ASSURER DE LA MESURE DES TEMPS DE REPONSE

Avoir un référentiel temps de réponse fondé sur les informations données par un site réel (site pilote) . . Préciser les conditions de mesures (nombre d utilisateurs connectés, nombre d utilisateurs actifs). . . Chronométrer les transactions demandées dans les fiches de tâches du référentiel de temps de réponse (temps machine). . . Comparer les mesures faites au résultats attendus . . Faire remonter les signalisations éventuelles . . Valider le tableau de synthèse des mesures

(A) S ASSURER DU PASSAGE DES CONTROLES DE CROISIERE

S assurer, à partir du dossier de contrôles de croisière, du bon fonctionnement du site pilote . . Compléter le dossier de contrôles avec les données résultantes du test (N° com-mande, ND, ...) . . Vérifier le fonctionnement dans un environnement opérationnel (d'après le dossier de contrôles de croisière) . . Valider les contrôles dans des réunions de suivi



13.2. Représentation OSSAD des processus AGATHONE MPP

13.2.1. Les activités du processus AGATHONE MPP

Figure 78 – AGATHONE, Activité : Organisation, avancement et suivi.



Figure 79 – AGATHONE, Activité : Qualification MOE SI



Figure 80 – AGATHONE, Activité : Installation



Figure 81 – AGATHONE, Activité : Formation métiers



Figure 82 – AGATHONE, Activité : Communication



Figure 83 – AGATHONE, Activité : Relation avec le site pilote



Figure 84 – AGATHONE, Activité : Qualification utilisateurs



13.2.2. Les phases du processus AGATHONE MPP

Figure 85 – AGATHONE, Phase 1 MPP : Mûrissement



Figure 86 – AGATHONE, Phase 2 MPP : Recherche du site pilote



Figure 87 – AGATHONE, Phase 3 MPP : Préparation du déploiement (1/2)



Figure 88 – AGATHONE, Phase 3 MPP : Préparation du déploiement (2/2)



Figure 89 – AGATHONE, Phase 4 MPP : Initialisation du site pilote



Figure 90 – AGATHONE, Phase 5 MPP : Installation



Figure 91 – AGATHONE, Phase 6 MPP : Suivi et Bilan



Figure 92 – AGATHONE, Phase 7 MPP : Post Bilan



13.2.3. Les relations avec les autres processus

Figure 93 – Abstrait MA - Agathone MPP - Relation avec les autres processus



Figure 94 – Abstrait MA - Agathone MPP - synthese MO par Activité



Figure 95 – Abstrait MA - Agathone MPP - synthese MO par phase

Figure 96 – Abstrait MA - Agathone MPP - synthese MO par Activité



Figure 97 – Abstrait MA - Agathone MPP - synthese MO par phase