Ecole Centrale Marseille Logica LCL France Travail de Fin ... · Mathieu Esposito – Ecole Centrale Marseille – Promo tion 2012 Rapport de Stage Ingénieur de F in d’Etude s

Ecole Centrale Marseille Logica LCL Paris France

Travail de Fin d’Etudes Du 02/04/2012 au 28/09/2012

Fiabilisation du circuit des commandes Avantage

Mathieu Esposito 3ème année promotion 2012

Parcours Microsystèmes Avancés

Tuteur école : Salah Bourennane tuteur Entreprise : Richard Chong

2

Mathieu Esposito – Ecole Centrale Marseille – Promotion 2012 Rapport de Stage Ingénieur de Fin d’Etudes – Consultant Junior Logica

Remerciements Je tiens à remercier Pascale Monnerie du LCL, pour m’avoir accueilli et intégré au sein de son équipe Pilotage PNB/Client. Je tiens également à remercier Richard Chong, mon responsable de stage, consultant Logica, pour m’avoir encadré, avoir répondu à mes questions et avoir effectué un suivi de mon travail, tout au long de ce stage. J’aimerais remercier, tout particulièrement, Françoise Leuillier, responsable de la MOAP Avantage, et Anne Déchaux, consultante de cette même structure dans laquelle s’est déroulé mon stage, pour le suivi régulier de mon activité, les responsabilités qu’elles m’ont confiées, la formation dispensée et la confiance témoignée. Enfin, mes derniers remerciements iront à toute l’équipe Pilotage PNB/Client avec qui ce fut un réel plaisir de travailler chaque jour.

3


Résumé LCL dispose d’un programme de fidélité, nommé Avantage, et permettant aux adhérents de cumuler des points qui donnent accès à des récompenses. Même s’il est globalement satisfaisant, le programme présente des faiblesses au niveau processus ou système d’information, qui génèrent des risques opérationnels ou des insatisfactions de clients relatives au traitement des commandes de récompenses extra-bancaires. En effet, de nombreuses actions sont effectuées manuellement par le Service Client Avantage et reposent sur des outils bureautiques peu évolutifs, et non maintenus, ce qui représente à la fois un risque élevé en termes d’exploitation, mais aussi une perte de productivité. Le but de mon stage était de mener à bien la mise en place de solutions techniques dans le but de fiabiliser le circuit des commandes Avantage.

Mots clefs

Système d’information, fiabilisation, fidélisation client, gestion de la relation client, conduite du changement, recueil du besoin, analyse d’impact.

4


Summary LCL proposes a fidelity program, named Avantage, in which customers can cumulate points which give access to recompenses. Even if it is overall satisfying, this program presents some weakness concerning process and information system, which trigger operational risks and customers’ dissatisfactions in relation with treatments of recompenses orders. Indeed, several manual actions are realized by the Avantage Customers Service and are supported by office tools not evolutive and not maintained, that represents an exploitation risk and a loss of productivity. The aim of this mission is to organize the developement of technical solutions to get the circuit of Avantage orders reliable.

Keywords Informative technologies system, reliability, development of customer loyalty, customer relationship management, change management, establishing needs, Impacts study.

5


Introduction Chez LCL, le programme Avantage est l’un des 4 piliers du Contrat de Reconnaissance. C’est un programme de fidélité gratuit qui permet de concrétiser la promesse de reconnaissance porté par le contrat. En effet, les adhérents peuvent engranger des points leur permettant ainsi de commander des récompenses. Cependant le circuit des commandes actuel présente des failles au niveau fiabilité, sécurité, évolutivité, et traçabilité. Le stage, dont le présent rapport fait l’objet, fait partie intégrante du projet de refonte de ce circuit des commandes, dont les objectifs à terme pour le LCL sont de corriger les faiblesses décrites ci-dessus, dans la perspective d’un gain financier et d’un gain en termes de fidélisation client.

6


Tables des matières

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

I. Présentation des entreprises.............................................................................................8

A. Présentation accueil Logica.....................................................................................8 1. Historique.......................................................................................................................... 8 2. Activités............................................................................................................................ 9 3. Organisation.................................................................................................................... 10 4. La Practice Banques....................................................................................................... 11

B. Présentation LCL .....................................................................................................12 1. Historique........................................................................................................................ 12 2. Quelques chiffres............................................................................................................ 12 3. La maîtrise d’ouvrage au LCL....................................................................................... 12

II. Contexte et objectifs du Projet....................................................................................15

A. Présentation du programme Avantage.................................................................15 1. Description générale....................................................................................................... 15 2. Chiffres clés.................................................................................................................... 15 3. Les acteurs du programme.............................................................................................. 15

B. Description du Projet................................................................................................17 1. Circuit des commandes actuels...................................................................................... 17

a) Gestion des commandes............................................................................................. 17 b) Suivi des commandes.................................................................................................. 18 c) Pilotage........................................................................................................................ 19

2. Inconvénients et faiblesses de la situation actuelle........................................................ 19 a) Fiabilité de l’outil Access........................................................................................... 20 b) Evolutivité de l’outil Access....................................................................................... 20 c) Sécurité........................................................................................................................ 20 d) Traçabilité des commandes......................................................................................... 21

i. Suivi des commandes .............................................................................................. 21 ii. Pilotage du programme Avantage .......................................................................... 21

e) Redondance et perte de temps.................................................................................... 21 3. Objectifs du projet.......................................................................................................... 22 1. Fiabilisation.................................................................................................................... 23

a) Intégrer les fonctions de l’outil Access dans le SI LCL............................................. 24 b) Automatiser et sécuriser les échanges avec les partenaires........................................ 24

2. Suivi des réclamations et pilotage du programme......................................................... 25

C. Avancée du projet jusqu’à mon arrivée................................................................25 1. Déroulement du projet.................................................................................................... 25 2. Planning du projet........................................................................................................... 26

7


3. Solutions retenues........................................................................................................... 26

III. Mon rôle au sein du projet.........................................................................................27

A. Optimisation du processus de saisie et traitement des commandes Avantage.......27 1. Développements réalisés par la MOE............................................................................ 28 2. Réalisation de la recette à la charge de la MOA............................................................ 30

a) Conception de plans et cahiers de tests....................................................................... 30 b) Réalisation de la recette.............................................................................................. 31 c) Suivi des anomalies..................................................................................................... 31 d) Rédaction du Procès Verbal de recette (PV).............................................................. 31

3. Suivi de recette LCL....................................................................................................... 32 4. Suivi de recette partenaires............................................................................................. 33 5. Mises à jour des règles de gestion.................................................................................. 33

B. Optimisation du processus de suivi des réclamations...............................................34 1. Recueil du besoin auprès du SCA et des partenaires externes....................................... 34 2. Etude d’impacts.............................................................................................................. 36 3. Analyse et mise en œuvre de solutions.......................................................................... 36 4. Rédaction de manuels utilisateurs.................................................................................. 40

C. Gestion de projet et conduite du changement.......................................................40 1. Comités de suivi et de coordination............................................................................... 41 2. Rédaction plannings et feuilles de route......................................................................... 41 3. Organisation de répétitions............................................................................................. 42

D. Plan de continuité d’activité..................................................................................42 1. Analyse d’impacts.......................................................................................................... 42 2. Solutions en mode dégradé............................................................................................. 43

E. Mise en place et suivi de production.........................................................................43 1. Mise à jour des tables récompenses et partenaires......................................................... 43 2. Suivi de production......................................................................................................... 44

Conclusion Projet.................................................................................................................46

Conclusion personnelle........................................................................................................47

Liste des figures....................................................................................................................48

Glossaire..............................................................................................................................49

8


I. Présentation des entreprises

A. Présentation accueil Logica

1. Historique Logica est une entreprise européenne de services en informatique, spécialisée dans le conseil, l'intégration de systèmes et l'outsourcing. Logica est issue de rapprochements effectués dans les années 2000 entre plusieurs leaders européens du même domaine (Logica, CMG, Unilog et WM-data).

Figure 1– Naissance de Logica

Logica est aujourd’hui présente dans 36 pays à travers le Monde et compte plus de 41000 collaborateurs, dont 9200 en France. Voici notamment son implantation actuelle en Europe :

9


Figure 2– Logica en Europe

En août 2012, Logica est rachetée par le groupe canadien CGI.

2. Activités Son activité englobe le conseil en management, conseil en gestion et technologies de l’information (activité relative à mon stage), l’intégration de systèmes et l’outsourcing de processus métier et IT, dans des secteurs très divers tels que l’assurance, la banque, l’énergie, la distribution, le secteur public, les télécommunications ou les transports.

10


Figure 3– Secteurs d’activité Logica

Au titre de son activité en 2011, Logica a réalisé un chiffre d’affaires de 4,9 milliards d’euros, ce qui la positionne plus que jamais parmi les grands leaders européens et mondiaux de services en informatique.

3. Organisation La diversité des secteurs d’activités, des technologies et des métiers entraîne une organisation de type matricielle chez Logica :

11


Figure 4– Organisation Logica

Lors de ce stage, j’ai intégré la HBL (Horizontal Business Line) BSS (Business Solutions Services) au sein de la Practice Banques.

4. La Practice Banques La Practice Banques apporte de la valeur ajoutée à ses clients dans les domaines du crédit, des risques, du paiement, de la fidélisation (domaine relatif à mon stage) et de la tenue de compte. Elle intervient principalement en maîtrise d’ouvrage et maîtrise d’œuvre pour la définition des besoins d’évolution du système d’information et la mise en œuvre de projets, de transformation, ou d’intégration de solutions spécifiques et/ou de type progiciels. Les points forts de cette Practice sont : - Une position reconnue sur le marché en France. - Des compétences fonctionnelles fortes - Un savoir faire méthodologique - Une variété d’offres en adéquation avec les attentes des clients.

12


B. Présentation LCL

1. Historique LCL (Le Crédit Lyonnais) est une banque française fondée en 1864 par Henri Germain et ses associés. Appelé Crédit Lyonnais jusqu’en 2005, LCL est né du rapprochement avec le Crédit Agricole S.A. Considéré comme l'un des trois piliers de l'industrie bancaire française, avec BNP Paribas et la Société générale, LCL fait maintenant partie du groupe Crédit Agricole.

2. Quelques chiffres LCL est, en France, la seule banque à réseau national qui se consacre exclusivement aux activités de banque de détail. Avec 6 millions de clients et 1 970 agences dont 50% dans les agglomérations de plus de 200000 habitants, l'activité bancaire de LCL couvre 3 marchés : les particuliers, les professionnels et les entreprises. C'est aussi une banque privée, spécialisée dans la gestion de patrimoine privé ou professionnel.

3. La maîtrise d’ouvrage au LCL La totalité de mon stage s’est déroulé au sein de la maîtrise d’ouvrage et processus (MOAP) Avantage. Il convient alors de définir dans ce rapport la place des maîtrises d’ouvrage au sein du LCL et des différentes entités qui composent les équipes de travail. La MOAP joue son rôle sur un périmètre de systèmes d’informations et processus couvrant : - Les processus client de la banque commerciale (exemple : commercialisation de produits d’épargne, de crédit…). – Les processus support transverses fortement adhérents aux processus client (exemple : comptabilité, pilotage commercial…). La MOAP assure, pour le compte de LCL, des missions d’animation et de gouvernance en rapport avec les systèmes d’information et processus. L’analyste d’études MOA effectue des analyses de besoins, rédige des cahiers des charges et des spécifications fonctionnelles. Il sait concevoir une recette et la mettre en œuvre. Il est responsable de l’obtention d’un résultat optimal et conforme à un cahier des charges en garantissant la meilleure adéquation qualité / performance / coût / délai. Les pôles de la MOAP doivent entretenir la documentation nécessaire et suffisante pour permettre à leurs collaborateurs :

13


• D’acquérir rapidement les connaissances requises en cas de prise de poste. • D’intervenir efficacement sur le système d’information en cas d’évolution ou en cas d’incident. • De répondre efficacement à des demandes d’information justifiées émanant d’interlocuteurs extérieurs. Ils doivent également communiquer toutes les informations utiles pour permettre aux utilisateurs finaux de mener leurs activités au sein des processus qu’ils gèrent. La documentation à entretenir se compose donc de : • La documentation fonctionnelle (fonctions, données et règles de gestion). • La documentation organisationnelle (processus et activités). • La documentation sécurité (exigences, scénarios de risques, dispositifs de sécurité, risques résiduels). • La documentation de recette (scénarios, jeux de données et environnement nécessaires pour recetter les évolutions de l’application). Les MOAP instruisent les demandes d’évolution selon un processus appelé “gestion de la demande” : • Application d’un principe de versionning, visant à regrouper le plus possible les demandes touchant aux mêmes ensembles applicatifs, afin de limiter les coûts d’intervention. • Mise en place d’instances de décisions, sous la présidence d’un représentant des directions demandeuses, validant les demandes, les priorités de lancement. • Mise en place d’instances de suivi et de coordination, réunissant les maîtrises d’ouvrage et les maîtrises d’oeuvre, chargées d’instruire les demandes, d’analyser et de chiffrer les impacts, de proposer des priorités cohérentes et d’entretenir les plannings. Les différentes activités de la maîtrise d’ouvrage sont donc les suivantes : • Analyse des besoins. • Rédaction des cahiers des charges. • Conception des plans de recette. • Déroulement de la recette. • Gestion des incidents. • Evolutions du système d’information. • Mise à jour des documents utilisateurs. • Planification des travaux. • Suivi du projet. • Reporting auprès du Pilote de Processus. • Conduite du changement. Les MOAP sont regroupées par pôles structurés selon les domaines de processus LCL. Lors de ce stage, j’ai intégré le pôle Comptabilité, Risques, Pilotage de la banque (CRP) sous la direction de Gérard Tranin.

14


Figure 5– Organigramme MOAP au LCL

Dans de ce pôle, j’ai rejoint l’équipe Pilotage PNB/Client (PPC), dirigée par Pascale Monnerie, au sein de la MOAP Avantage, sous la responsabilité de Françoise Leuillier.

Figure 6– Organigramme pôle Comptabilité, Risques, Pilotage de la banque

15


II. Contexte et objectifs du Projet

A. Présentation du programme Avantage

1. Description générale Avantage est un programme de fidélisation de la clientèle des particuliers reposant sur le principe d'un système à points à l'image des programmes qui se développent fortement dans les compagnies aériennes, chaînes hôtelières, ou grands magasins. Tout client particulier chez LCL peut adhérer gratuitement au programme, et ses opérations bancaires (paiements par carte, variation positive du flux des comptes épargne, etc) lui permettront de cumuler des points. Ces points donnent accès à deux types de récompenses :

• les récompenses bancaires (rétrocession de cartes et autres avantages bancaires)

• les récompenses extra-bancaires (bons FNAC, produits d’électroménager, produits de beauté, dons pour des associations caritatives etc…)

2. Chiffres clés Le programme Avantage a été lancé en 1998 par Le Crédit Lyonnais. En 2012, ce programme compte plus de deux millions d’adhérents dont 81% sont clients LCL depuis plus de 10 ans ; 550 000 récompenses sont envoyées à 400 000 bénéficiaires par an. De plus, Avantage permet de récompenser le parrainage de nouveaux clients LCL, ce qui contribue à l’ouverture de plus de 30 000 comptes par an. Ces chiffres montrent l’importance que représente le programme Avantage pour LCL, d’autant que disposer d’un programme de fidélité entièrement gratuit est un avantage concurrentiel non négligeable.

3. Les acteurs du programme

• Le client LCL adhérent au programme Avantage Il dispose de différents moyens pour commander une récompense. Il peut commander via Internet en passant par le site LCL, via un bon de commande à envoyer par courrier au Service Client Avantage (SCA) situé à Bordeaux, ou en appelant directement le SCA.

16


• Le Service Client Avantage Le SCA est responsable de la saisie dans un opérationnel des commandes arrivant chez lui (par bons de commande ou par téléphone). Le SCA est également responsable de la gestion et du suivi des réclamations clients en coordination avec les partenaires fournisseurs de récompenses. • Les partenaires fournisseurs de récompenses Ils sont responsables de l’acheminement des récompenses aux clients, de la gestion des réclamations clients en coordination avec le SCA et envoient la facturation des récompenses au Marketing Clients Avantage. • Le Marketing Métier Avantage Le Marketing est responsable du pilotage du programme, c’est-à-dire que c’est lui qui effectue un suivi de l’activité. C’est lui qui fixe le barème de points des récompenses, qui décide du catalogue des récompenses (par exemple, si des récompenses entraînent trop de réclamations le Marketing peut décider de les retirer du catalogue), c’est lui qui négocie et paye les partenariats avec les fournisseurs de récompenses, c’est lui qui émet une expression de besoin lorsque selon lui le programme nécessite une évolution et c’est d’ailleurs lui qui est à l’origine du projet qui fait l’objet de ce rapport. Il est également responsable d’assistance directe aux utilisateurs, ce que l’on appelle assistance de premier niveau. Par exemple, lorsqu’un adhérent Avantage réclame un bonus de points qu’il n’a pas touché, c’est au Marketing de gérer ce problème. • La Maîtrise d’ouvrage Avantage (MOAP Avantage) Elle est responsable d’assistance de niveau fonctionnel ou assistance de 2nd niveau, c’est-à-dire que si le Marketing n’a pas les informations nécessaires pour résoudre ce problème, c’est à la MOAP de s’en charger. Elle est également responsable de la conduite de projets (si ces projets pour l’optimisation du programme ont été approuvés), du maintien du système d’information en condition opérationnelle, et de la gestion de cohérence du système d’information. J’ai donc intégré cette structure, lors de la conduite du projet de refonte du circuit des commandes Avantage. • La Maîtrise d’œuvre Avantage (MOE Avantage) Elle est responsable du fonctionnement du SI, et assure les développements techniques au sein du SI pour la prise en charge des évolutions demandées.

17


B. Description du Projet

1. Circuit des commandes actuels Le circuit des commandes Avantage actuel est assez complexe, nous allons expliciter le schéma ci-dessous.

Figure 7– circuit des commandes Avantage actuel

a) Gestion des commandes Il existe deux points d’entrée pour la saisie de commandes de récompenses :

• Le client peut saisir directement sa commande sur la Plateforme Site Produit (PSP) gérée par un partenaire externe.

18


• Le client peut appeler le SCA ou lui envoyer un bon de commande afin d’effectuer sa demande de récompense. C’est ensuite le SCA qui est chargée de saisir cette commande à partir d’un outil nommé Fidelis.

Les commandes saisies via Fidelis et via la PSP sont ensuite extraites, puis traitées, quotidiennement par le SI LCL. Lors de ce traitement, des contrôles sont effectués afin de déterminer si la commande est valide ou non. Si la commande n’est pas valide, elle alimente un ficher de rejets, appelé RBEL (Rejets Banque En Ligne). Si la commande est valide, elle alimente le fichier de commandes du partenaire correspondant. Le SI envoie ensuite le fichier RBEL et les fichiers de commandes au SCA à Bordeaux par TFHE (Transfert de Fichiers Hors ELAN). Un outil Access permet au SCA, par une action manuelle, de récupérer quotidiennement ces fichiers. Les rejets du fichier RBEL sont ensuite analysés au cas par cas par le SCA afin de déterminer s’ils nécessitent une action auprès du client. Par exemple, un rejet pour motif de solde de points insuffisant par rapport à la valeur de la récompense ne nécessite pas d’action auprès du client, en revanche un rejet pour motif d’adresse topée NPAI (N’est Pas à l’Adresse indiquée) implique pour le SCA d’entrer en contact par téléphone avec le client, si cela est possible, afin de déterminer quelle est son adresse actuelle. Lorsque l’outil Access récupère les fichiers de commandes venant du SI, il va les reformater, et créer de nouveaux fichiers de commandes par fournisseur. Par exemple, en entrée de l’outil Access, on a un fichier de commandes au format texte pour le prestataire logistique EMC, et en sortie de l’outil Access on a sept fichiers de commandes au format Excel pour chacun des fournisseurs du prestataire logistique. Par exemple, le prestataire logistique EMC a sept fournisseurs : Fnac, Cartes et chèques, Direct, Produits, Pierre et Vacances, Centrale Voyage, et Sephora. Actuellement, Avantage comprend trois partenaires logistiques : EMC, LeNôtre et CFPE. Les fichiers de commandes en sortie de la base Access sont ensuite déposés sur le Hub d’EMC pour ce dernier, et envoyés par mail pour les autres prestataires logistiques.

b) Suivi des commandes Le destin d’une commande peut être varié. Dans le meilleur des cas, la commande est bien acheminée au client et ce dernier est satisfait, une suite n’a donc pas lieu d’exister dans ce cas. Cependant, il se peut que la commande ne soit pas acheminée (par exemple, le client

19


n’a pas réceptionné son colis parce qu’il est en vacances ou parce qu’il n’est plus à l’adresse indiquée) ou que le client soit mécontent et porte réclamation (par exemple, le produit reçu ne fonctionne pas). Dans ce cas, un suivi est mis en place sur cette commande, concrètement cette commande est ajoutée manuellement dans un fichier de réclamations qui fait la navette entre le SCA et le partenaire correspondant et dans lequel les deux acteurs s’échangent des informations afin de traiter les suivis. Une commande qui fait l’objet d’un suivi peut avoir deux points d’entrée :

• Soit la remontée du suivi arrive d’abord au SCA (par exemple, un client mécontent appelle le SCA) et c’est ce dernier qui alimente le fichier de réclamations correspondant

• Soit la remontée du suivi arrive d’abord chez le prestataire logistique (par exemple, lorsque le colis n’est pas réceptionné par le client, le prestataire logistique en est le premier informé) et c’est ce dernier qui alimente le fichier de réclamations correspondant.

Il se peut qu’une commande soit annulée (parce que le client le souhaite ou parce que le suivi dure depuis trop longtemps), dans ce cas le client doit être re-crédité de ses points. Pour cela, le SCA fait part à EMC des annulations de commandes dont il a connaissance, puis EMC constitue, de façon hebdomadaire, à partir des annulations venant du SCA plus des annulations dont il a connaissance, un fichier ‘crédits de points’ qu’il envoie au Marketing. Le Marketing transfère alors, hebdomadairement, par TFHE, ce fichier de crédits de points dans un répertoire qui est traité en automatique par le SI afin de restituer les points débités du client.

c) Pilotage En plus de la gestion des commandes, l'outil Access permet la saisie d'informations sur l'activité quotidienne des téléconseillers (TC) telles que : réclamations traitées, annulation de commandes, bons de commande reçus par courrier, etc... L'outil produit des statistiques hebdomadaires à destination du Marketing Avantage. Ces informations sont nécessaires pour le contrôle et la validation des factures des différents prestataires chargés de l'acheminement des commandes vers les adhérents. Elles permettent aussi de suivre l'activité du SCA.

2. Inconvénients et faiblesses de la situation actuelle Même s’il est globalement satisfaisant, le programme présente des faiblesses au niveau processus ou SI, qui génèrent des risques opérationnels ou des insatisfactions de clients relatives au traitement des commandes de récompenses extra-bancaires. En effet, de nombreuses actions sont effectuées manuellement par le SCA et reposent sur des outils bureautiques peu évolutifs, et non maintenus, ce qui représente à la fois un risque élevé en termes d’exploitation, mais aussi une perte de productivité. Nous allons détailler ces risques ci-dessous.

20


a) Fiabilité de l’outil Access L’outil Access présente des failles au niveau fiabilité. D’une part, de nombreux plantages ont été constatés entraînant un blocage du poste utilisateur chez les opérateurs du SCA de bordeaux. D’autre part, cet outil a été développé, gracieusement, par une seule personne d’ACL (Accueil Conseil en Ligne) afin de rendre service au SCA, mais la maintenance n’est plus assurée depuis 2011. En effet, elle est la seule à avoir les connaissances pour en assurer la maintenance, mais cela ne fait pas partie de ses responsabilités professionnelles. Ces problèmes j’ai pu les constatés dès le début de mon stage. En effet, le 11 avril des mises à jour informatiques ont été effectuées au SCA de bordeaux, des espaces ont été modifiés, et des répertoires ont changé de noms si bien que l’outil Access n’arrivait plus à récupérer les fichiers de commandes du jour envoyés par le SI. La personne ayant développé la base Access était partie en vacances jusqu’au 16 avril, donc jusqu’au moment où les corrections ont été apportées par cette personne, le Marketing s’était chargé d’effectuer à la main le travail de l’outil Access afin que les fichiers de commandes puissent être envoyés aux partenaires.

b) Evolutivité de l’outil Access L’outil Access présente également des failles au niveau évolutivité, en effet, il a été développé sur mesure pour la situation actuelle et l’ajout et la modification de partenaires n’ont pas été pris en compte dans les développements de cet outil Access. Ce point est important car pour apporter toujours plus de satisfaction aux clients, il est important de renouveler les récompenses et donc les partenaires. D’ailleurs le Marketing établit de nouveaux catalogues de récompenses deux fois par an, et lors du catalogue d’octobre 2012 deux nouveaux partenaires vont faire leur apparition : Action Contre le faim et Mécénat Chirurgie Cardiaque. Il faudra donc palier ce manque d’évolutivité de la base Access.

c) Sécurité

Les systèmes d’échanges et de gestion des fichiers de commandes et de réclamations ne sont pas sécurisés. D’une part, dans le circuit des commandes actuel, les interventions manuelles sont fréquentes par l’ensemble des acteurs tout au long du processus de gestion des commandes, il y a donc un risque de défaillance humaine pouvant aller de l’erreur et de l’oubli à la fraude. Par exemple, les fichiers de commandes en sortie de l’outil Access sont souvent manipulés par le SCA, notamment pour modifier certaines adresses, avant d’être envoyés aux partenaires. Ces actions présentent un risque opérationnel

21


très élevé, car une erreur de manipulation peut fausser le fichier de commandes tout entier. D’autre part, les fichiers de commandes et de réclamations sont envoyés par mail ce qui ne répond pas aux normes de sécurité.

d) Traçabilité des commandes

Aujourd’hui dans le circuit Avantage, il n’y a pas de traçabilité des commandes ce qui pose deux problèmes.

i. Suivi des commandes

D’une part en cas d’incident ou de réclamation du client le SCA dispose de très peu d’informations sur la commande. Lorsqu’un opérateur du SCA souhaite aller consulter la commande d’un client sur l’outil Fidelis, il peut seulement voir qu’elle est au statut « enregistrée » (statut lorsque la commande est saisie via Fidelis) ou « traitée » (statut lorsque la commande alimente les fichiers de commandes après les traitements du SI). Mais si la commande n’a pas été acheminée, l’opérateur du SCA peut difficilement donner des informations au client, il peut éventuellement en trouver dans les fichiers de suivi de réclamations mais ils ne sont pas mis à jour régulièrement et les données sont généralement noyées parmi les autres réclamations (ces fichiers font plusieurs milliers de lignes). Finalement, les réclamations mettent beaucoup de temps à être traitées lorsqu’elles le sont, l’opérateur du SCA ne dispose pas d’informations pour rassurer le client ce qui rend difficile la gestion du mécontentement de ce dernier.

ii. Pilotage du programme Avantage

D’autre part, le deuxième problème de la non traçabilité des commandes est qu’il est difficile d’assurer un vrai pilotage de la gestion des commandes. En effet, comment s’assurer de la facturation des partenaires ? Comment savoir que certaines récompenses ne sont pas à renouveler dans le prochain catalogue car elles entraînent trop de réclamations ? Plus généralement, comment s’assurer de la complétude et de l’intégrité des informations afin que le Pilotage du programme Avantage soit effectué au mieux ?

e) Redondance et perte de temps

Lors de l’apparition des nouveaux catalogues de récompenses, il faut paramétrer les récompenses de manière à fermer les anciennes et à ouvrir les nouvelles. Dans le circuit actuel des commandes, le paramétrage des récompenses est effectué en triple, une fois sur la PSP pour les commandes effectuées sur Internet, une fois dans le SI LCL et une autre fois dans l’Outil Access.

22


En sachant que le volume de ces récompenses est de plusieurs centaines, il est dommage que ce travail long et fastidieux soit à renouveler 3 fois. De plus, les indicateurs de l’activité du SCA sont saisis manuellement dans l’outil Access, cette activité n’a pas de valeur ajoutée et est perçue comme une perte de temps.

3. Objectifs du projet Le but du projet est d’apporter des solutions aux différentes faiblesses vues plus haut car l’objectif est double :

• Un gain financier En effet, des commandes mieux gérées ce sont moins de plis non distribués, moins de réclamations, moins de re-crédits de points erronés et donc une optimisation des coûts pour LCL, au niveau du programme Avantage. • Un gain en termes de fidélisation client En effet, une amélioration de la qualité de service entraînera une augmentation de la satisfaction client et donc un gain en termes de fidélisation.

Le processus ‘cible’ de ce projet est repris dans le schéma ci-dessous dont nous allons expliciter les améliorations qui vont s’orienter autour de trois axes : la fiabilisation de la gestion des commandes, le suivi des réclamations et le pilotage du programme.

23


Figure 8– circuit des commandes Avantage cible

1. Fiabilisation L’un des grands objectifs du projet était de fiabiliser le circuit des commandes Avantage et pour cela l’idée principale a été de centraliser un maximum d’étapes du processus dans le SI LCL. D’ailleurs visuellement, la comparaison entre le schéma du processus actuel et le schéma du processus cible est flagrante, les actions principales qui étaient dispersées, sont re-centrées au niveau du SI LCL.

24


Figure 9– Comparaison circuit des commandes Avantage actuel vs cible

a) Intégrer les fonctions de l’outil Access dans le SI LCL En termes de fiabilisation, reprendre les fonctions de l’outil Access (vues dans la partie II. C. 1) dans le SI LCL présente trois intérêts. Cela permet, d’abord de s’affranchir d’un outil qui n’est plus maintenu depuis 2011 et qui représente un risque important au sein du circuit des commandes. Ensuite, cela représente un gain de sécurité car le traitement des commandes se fera exclusivement au niveau du SI LCL, et ne transitera plus par un outil externe. Enfin, cela permet de réduire les interventions manuelles qui étaient effectuées avec l’outil Access, et donc de diminuer les risques d’erreur, d’oubli ou de fraude.

b) Automatiser et sécuriser les échanges avec les partenaires Toujours pour minimiser les interventions manuelles, un des objectifs est d’automatiser de bout en bout la chaîne de traitements des commandes jusqu’à l’envoi des fichiers de commandes aux partenaires, tout en garantissant les normes de sécurité qui s’imposent lorsque l’on envoie des données client.

c) Rendre flexible l’ajout et la modification de récompenses\partenaires

25


L’idée est d’une part d’éviter le triple paramétrage des récompenses (PSP, SI, Access) qui est une source d’erreur et de perte de temps, en le centralisant au niveau du SI (à l’exception de la PSP qui est hors projet car gérée par un prestataire externe), et d’autre part de prendre en compte dans les développements du SI la possibilité d’ajouts et de modifications de partenaires.

2. Suivi des réclamations et pilotage du programme Pour améliorer le suivi des réclamations et le pilotage du programme, le principe est de permettre de tracer les commandes depuis la création jusqu’à la livraison. En effet, cela permettra de pouvoir donner des informations aux clients lors de réclamations mais aussi de faciliter la gestion et le suivi de facturation des récompenses et frais associés.

C. Avancée du projet jusqu’à mon arrivée

1. Déroulement du projet Le démarrage du projet est une phase d’études marquée par les échanges entre le Marketing et la MOA. D’abord, le Marketing fournie à la MOA une expression de besoins, c’est-à-dire un document qui décrit de manière assez générale les besoins qui se font ressentir dans la situation actuelle et que l’on aimerait satisfaire grâce au projet. Après divers échanges, le Marketing et la MOA définissent ensemble les processus fonctionnels acteurs, c’est-à-dire qui fait quoi, comment et quand pour répondre aux besoins. En tenant compte de l’expression de besoins et des processus fonctionnels acteurs, la MOA rédige un cahier des charges à destination de la MOE, c’est-à-dire un document qui décrit les fonctions qui vont permettre de satisfaire les besoins exprimés par le Marketing. A partir de ce cahier des charges, la MOE réalise un chiffrage, c’est-à-dire combien de jours homme vont coûter les développements pour couvrir les fonctions décrites dans le cahier des charges. Synthétisant tout cela, la MOA monte un dossier d’études pour ce projet, qu’elle présentera en CISI (Comité d’Investissement du Système d’Informations). C’est lors de ce CISI qu’un budget est accordé ou non pour le projet. Dans la positive, celui-ci peut alors débuter, ce fut le cas pour le projet de fiabilisation du circuit des commandes Avantage. Les grandes phases suivantes sont :

26


• La rédaction d’un dossier de conception fonctionnelle (DCF) par la MOA. Ce document est un cahier des charges plus précis et plus fin, où les fonctions du projet vont être découpées en fonctions élémentaires, elles-mêmes découpées en règles de gestion.

• Les développements de la MOE basés sur le DCF • La recette afin de tester si les développements effectués sont bien conformes

aux règles de gestion décrites dans le DCF. • La conduite du changement avec les différents acteurs afin que la transition

avec les nouveautés se fassent au mieux. • La mise en place et le déploiement du projet, de manière progressive. • La généralisation

2. Planning du projet

Le planning prévisionnel tenant compte des phases ci-dessus, était le suivant :

21/08/2012 CSC Animation Programme Avantage N°15

Nov Déc Janv Fév Mars Avril Mai Juin Juillet Août Septembre

Etude

Conception fonctionnelle

Conception applicative

2011 2012

Développements et tests d’intégration

Recette LCL

Mise en place et déploiement

Généralisation

CISI Résultat d’étude

Tests d’intégration avec les partenaires

Recette partenaires

Saisie des récompenses pour l’offre d’Octobre

Figure 10– Planning prévisionnel du projet

Cependant, celui-ci a évolué tout au long du projet car il fallait s’adapter à certaines contraintes et autres imprévus.

3. Solutions retenues Le stage dont ce rapport fait l’objet a débuté le 2 avril, et les développements côté

27


MOE venaient de s’engager. Les grandes lignes des solutions retenues, à ce moment, là étaient les suivantes :

• La conception d’un nouvel opérationnel de gestion des commandes Avantage (GCAV). Celui-ci permettra la saisie de commandes tout en pouvant modifier l’adresse du client (modifier l’adresse de la commande lors de la saisie plutôt que dans les fichiers de commandes diminue grandement le risque opérationnel)et préciser cette dernière par un commentaire, la consultation de commandes, la possibilité de mettre à jour le statut d’une commande et d’y associer un motif de manière à assurer la traçabilité de celles-ci, et enfin, la possibilité d’annuler une commande et de re-créditer les points en temps réel.

• Quotidiennement, les traitements du SI, en automatique, extrairont les commandes d’Internet et de GCAV, produiront des fichiers de commandes pour chacun des fournisseurs, et les déposeront sur une plateforme d’échanges sécurisée, appelée Open-Trust, où chaque partenaire aura un compte.

• Quotidiennement, le SI constituera un fichier des commandes qui ont fait l’objet d’une mise à jour de statut sur GCAV qui sera mis à disposition du SCA pour le suivi des réclamations. Il est envisagé l’utilisation d’un outil collaboratif, appelé eRoom, pour le SCA et les partenaires de manière à ce que tous les intervenants puissent interagir simultanément et en temps réel sur le fichier des réclamations afin de pouvoir les gérer au mieux.

• Mensuellement, le SI produira des comptes-rendus d’inventaire qui reprendront les commandes et les nouvelles récompenses du mois et viendront enrichir un outil d’analyse Marketing appelé SIAM (Système d’Information d’Analyse Marketing) permettant à ce dernier d’assurer le pilotage de la gestion des commandes Avantage.

III. Mon rôle au sein du projet Avantage est un programme qui couvre différentes applications telles que Avantage Jeunes et Parrainage. En intégrant la MOAP Avantage, mes responsabilités allaient au-delà du projet, car en tant que MOAP, nous sommes garants du bon fonctionnement du SI, et de l’assistance utilisateurs de niveau fonctionnel. Cependant, ce rapport est focalisé uniquement sur la partie ‘projet’ qui correspond à la démarche ingénieur attendue, lors de ce stage.

A. Optimisation du processus de saisie et traitement des commandes Avantage

28


1. Développements réalisés par la MOE La MOE a effectué les développements sur la base du DCF de mars à juin. Voici schématiquement les nouveaux traitements de commandes Avantage. Ces traitements sont capables de gérer les saisies effectuées par l’ancien opérationnel (Fidelis) et par le nouveau (GCAV), cela dans le but d’effectuer une bascule progressive de l’ancien opérationnel au nouveau, et de conserver un outil de « back-up».

29


Figure 11– Schéma des développements réalisés dans le SI

Le nouvel opérationnel GCAV de saisie et de gestion des commandes a été conçu, pour illustration, voici la page à laquelle s’effectue la validation de la commande, avec restitution de l’adresse de l’adhérent et possibilité de modification.

Figure 12– Nouvel opérationnel de gestion des commandes Avantage (GCAV)

Les commandes extraites de GCAV et d’Internet alimentent automatiquement les fichiers de commandes du fournisseur correspondant qui sont ensuite déposés, également de manière automatique sur la plateforme d’échanges sécurisé Open-Trust. Ci-dessous, une illustration d’un compte Open-Trust sur lequel les partenaires viennent récupérer leurs fichiers de commandes :

30


Figure 13– Plateforme d’échanges sécurisée Open-Trust

2. Réalisation de la recette à la charge de la MOA Les développements de la MOE ont besoin d’être testés pour vérifier qu’ils sont bien conformes aux attentes décrites dans le DCF. Dans le passé, cette phase de recette était à la charge de la MOA, mais pour plus d’objectivité, elle est désormais, dans l’organisation du LCL, à la charge d’une autre entité appelée Centre de Recette fonctionnelle (CRF) qui possède un regard à la fois neutre et neuf sur le sujet. Cependant, pour le projet de fiabilisation du circuit des commandes, la recette des règles de gestion concernant les traitements de contrôle du paramétrage des récompenses et des partenaires est demeurée dans le champ d’action de la MOA.

a) Conception de plans et cahiers de tests

Pour tester une règle de gestion, il faut d’abord constituer des cas qui permettent d’illustrer tous les aspects de celles-ci. Ils sont regroupés dans un document que l’on appelle cahier de recette ou de tests. Par exemple, voici le début d’une des règles de gestion à tester : Contrôler les paramètres Partenaire Externe ‘Toutes les données sont obligatoires et ne doivent pas être renseignées à blanc. Le code partenaire n'est pas modifiable (clé primaire). Toutes les autres données sont modifiables.

31


Après chargement, réaliser les contrôles suivants : 1- si Code partenaire à blanc, le signaler avec message d’erreur : ‘Code Flux partenaire à blanc’ ; 2- si Libellé partenaire à blanc, le signaler avec message d’erreur : ‘Libellé Flux partenaire à blanc’ ;…etc’

Il faudra donc, a minima, réaliser deux cas. Un cas passant, où l’on ne devra pas obtenir de message d’erreur, et un cas bloquant où l’on devra obtenir les bons messages d’erreur. Pour la rédaction des cahiers de test, il est important de décrire ce que l’on teste, et ce que l’on doit obtenir.

b) Réalisation de la recette Pour la réalisation des recettes, il existe chez LCL un environnement de recette, qui est une extraction de celui de production et qui permet d’exécuter les tests sans impacter réellement les données client. Une fois que les cas de recette sont saisis dans cet environnement par la MOA, la MOE fait tourner les traitements et nous envoie les résultats. L’étape suivante est l’analyse de ces résultats afin de déterminer s’ils sont satisfaisants ou non.

c) Suivi des anomalies Lorsque le résultat obtenu n’est pas conforme au résultat attendu, cela est appelé une anomalie. Une correction est alors à apporter par la MOE, et le cas de recette est rejoué de manière à voir si l’anomalie persiste. Quelques anomalies avaient été détectées lors du premier lot de recette des traitements de contrôle du paramétrage, celles-ci ont toutes été corrigées lors du deuxième.

d) Rédaction du Procès Verbal de recette (PV) Lorsque la MOA estime que les tests de la règle de gestion sont concluants, elle rédige un livrable, appelé Procès Verbal de recette, qui atteste que cette règle a été testée et validée.

32


Figure 14– Procès Verbal de recette

3. Suivi de recette LCL Bien que la grande majorité de la recette du projet ait été déléguée au CRF, la MOA en reste l’entité responsable, c’est elle qui signera le PV de recette. Dans cette optique, le CRF a rédigé un document à valider par la MOA, appelé exigences de recette, qui décrit les cas qui vont être joués pour couvrir les règles de gestion du DCF. Un total de 1235 cas de tests a été exécuté et toutes les anomalies détectées ont été corrigées. Ci-dessous, se trouve le bilan de la recette effectuée, avec le nombre de cas passés pour chaque fonction du DCF.

33


Failed

No Run

Not C

omple

ted

Passe

d

Total

% d

'Exé

cutio

n

% d

e va

lidat

ion

10-Saisir les commandes de récompenses extra-bancaires Avantage 0 0 0 1016 1016 100% 100%11-Gérer les commandes de récompenses extra-bancaires Avantage 0 0 0 17 17 100% 100%12-Traiter les commandes de récompenses extra bancaires Avantage 0 0 0 125 125 100% 100%13-Gérer les mouvements de points Avantage 0 0 0 31 31 100% 100%14-Gérer les comptes de points Avantage 0 0 0 32 32 100% 100%16-Piloter le programme Avantage 0 0 0 6 6 100% 100%17-Gérer les éditions du programme Avantage 0 0 0 3 3 100% 100%24-Nettoyer la base Avantage 0 0 0 5 5 100% 100%Total 0 0 0 1235 1235 100% 100% La MOA était conviée, de manière hebdomadaire, à un point organisé par le CRF afin de suivre l’avancement de la recette. Le PV de recette fut signé par la MOA à la mi-août.

4. Suivi de recette partenaires Les partenaires externes (fournisseurs) du programme Avantage était également dans la nécessité de réaliser une recette, de manière à contrôler si leurs traitements étaient bien opérationnels pour les nouveaux fichiers de commandes. Dans ce contexte, la MOA était leur interlocuteur pour leur fournir des fichiers de commandes de tests adaptés à leurs besoins jusqu’à obtenir leur validation écrite.

5. Mises à jour des règles de gestion Ces différentes recettes permettent, au-delà de tester les développements réalisés, de mettre en évidence quelques problèmes de conception fonctionnelle qui ne sont pas évidents à déceler sur le papier. Par exemple, lorsqu’une adresse à particularité (militaire, NPAI,…) est restituée sur l’opérationnel, l’opérateur a la possibilité de cocher une case ‘adresse vérifiée’ qui permet la validation de la commande. Ainsi, théoriquement, pour une adresse militaire qui a été cochée ‘vérifiée’, la commande devrait passer. Le problème est qu’une autre règle de gestion en place, testait si le code postal était compris entre 1000 et 98000, or pour une adresse militaire le code postal peut être inférieur à 1000. Il y avait donc une incompatibilité entre les règles de gestion et une correction de niveau fonctionnel devait être apportée. Ainsi, nous avons décidé de modifier le contrôle sur le code postal, dans le cas d’une adresse militaire, le contrôle s’étend entre 0 et 98000. C’est pourquoi tout au long du projet, des mises à jour dans le DCF sont à effectuer par la MOA. Au LCL, ces mises à jour et plus généralement les DCF se rédigent via l’application Atelier du progiciel MEGA, voici son interface utilisateur :

34


Figure 15– L’Atelier sous MEGA

B. Optimisation du processus de suivi des réclamations Dans la situation actuelle, les commandes n’étant pas tracées, le suivi des réclamations clients est géré de manière assez désorganisée. Avec la traçabilité des commandes amenée par le projet, le SCA, EMC et LeNôtre espèrent que le processus de suivi des réclamations sera amélioré, car aujourd’hui c’est l’un des points faibles les plus importants du circuit des commandes Avantage en termes de productivité.

1. Recueil du besoin auprès du SCA et des partenaires externes Deux jours après le début du stage, le SCA s’est déplacé à Paris afin d’assister à des réunions de travail organisées par la MOA et planifiées sur deux jours. Le but était, d’une part de lui faire découvrir le nouveau processus de gestion des commandes, et d’autre part, d’analyser, plus précisément, avec lui la situation actuelle du suivi des réclamations, de recueillir son besoin réel, et de débattre des solutions qui avaient été envisagées Aujourd’hui, lorsqu’un opérateur du SCA reçoit une réclamation par téléphone, ou une information concernant une réclamation déjà existante, il la note sur un papier pour qu’elle soit par la suite ajoutée au fichier de réclamations correspondant. En effet, ce dernier est ouvert chez tous les opérateurs en même temps, et seule la personne qui a ouvert le fichier en premier a des droits d’écriture. Il existe un fichier de réclamations entre le SCA et EMC et un autre entre le SCA et LeNôtre.

35


Pour LeNôtre, le volume des réclamations est très faible, et celles-ci ne peuvent avoir qu’un seul point d’entrée : le SCA. Si un client appelle LeNôtre pour effectuer une réclamation, son appel sera transféré au SCA de Bordeaux. Dans le format actuel, les premières colonnes reprennent les informations importantes des commandes, puis une colonne est renseignée par le SCA pour expliquer la nature de la réclamation, et enfin une dernière colonne est réservée à la réponse de LeNôtre. Les procédures d’échanges ne sont pas clairement définies, ne sont pas sécurisées, et la fréquence des réponses de LeNôtre est assez variable, et est supérieure à plusieurs semaines. Pour EMC, le volume des réclamations peut dépasser, en période de pointe, la centaine par jour, et celles-ci peuvent avoir deux points d’entrée : le SCA et EMC. Dans le format actuel, les premières colonnes reprennent les informations importantes des commandes, puis des colonnes ‘statut de la commande’, ‘motif’, ‘action demandée’, ‘informations’ et ‘date de mise à jour’ sont à renseigner par la personne saisissant la réclamation. Le SCA et EMC s’échange ce fichier deux fois par semaine, avec un onglet par prestataire logistique, mais souvent l’action demandée par l’un, n’est pas bien comprise par l’autre, les nouvelles informations sur la réclamation sont ajoutées dans la même cellule au niveau de la colonne ‘informations’ par les deux acteurs, et les autres colonnes peuvent être également modifiées par les deux acteurs, si bien que l’on se perd dans l’évolution de la réclamation. Bien souvent aussi, les mêmes réclamations présentent plusieurs lignes dans le fichier mais le volume est tellement important que certaines sont oubliées. Egalement, après que les deux acteurs aient travaillé parallèlement sur le fichier, apporté des informations et l’aient modifié, EMC est obligé d’analyser manuellement le fichier envoyé par le SCA afin de mettre à jour le sien des nouvelles données apportées par le SCA, ce qui constituera le nouveau fichier de réclamations à jour. De plus pour les deux fichiers de réclamations, aucune protection des données n’est mise en place et des erreurs de manipulation peuvent altérer les lignes de réclamations. Pour résumer, les faiblesses de la situation actuelle sont :

• Le manque de clarté au niveau du contenu • La difficulté à suivre l’évolution d’une réclamation • Une mise à jour des fichiers fastidieuse et différée de plusieurs jours • Aucune protection vis-à-vis des erreurs de manipulations.

La première solution proposée au SCA fut l’outil collaboratif eRoom qui permettait, a priori, à ce dernier et aux partenaires, d’enrichir simultanément les fichiers de réclamations et donc de mettre à jour ces fichiers en temps réel très facilement. En complément de cela, nous proposions un nouveau format de fichier pour gagner en clarté au niveau du contenu. Des colonnes non modifiables reprendraient les données essentielles de la commande, une colonne modifiable réservée au partenaire, et protégée d’un mot de passe dans laquelle il complète les informations qu’il détient sur la réclamation, une colonne modifiable réservée au SCA, et protégée d’un mot de passe dans laquelle il fait de même. De plus les réclamations seraient

36


triées par numéro de commande de manière à ce que si plusieurs lignes sont présentes pour la même réclamation alors elles seront situées les unes en dessous des autres afin de faciliter le suivi de l’évolution d’une réclamation. Sur le principe, cette solution convenait au SCA qui avait choisi la disposition des colonnes du nouveau fichier de réclamations désormais appelé fichier de suivi des réclamations. Après avoir consulté EMC, ce dernier a approuvé le principe des colonnes réservées à chacun, mais souhaitait rester sur le système d’actions et d’informations complémentaires à l’action, associé aux réclamations afin de pouvoir cadrer les procédures de traitement de ces dernières.

2. Etude d’impacts Avant de mettre en place et valider une solution, une étude d’impacts est nécessaire au préalable. Ainsi, il convenait de mener une étude sur l’outil collaboratif eRoom afin de déterminer s’il répondait à notre besoin ou non, à savoir l’écriture en simultané par différents intervenants sur un même fichier. En effet le mode partagé d’un classeur Excel le permet, mais est-ce compatible avec l’eRoom ? Après analyse auprès d’un responsable des outils collaboratifs du Crédit Agricole, lorsqu’un fichier est déposé sur l’eRoom et qu’un acteur cherche à le modifier, celui-ci est automatiquement et exclusivement réservé en écriture à cet acteur, même s’il s’agit d’un classeur Excel partagé. Il était donc clair que cet outil collaboratif ne répondait pas à nos besoins, et qu’il fallait trouver une solution alternative.

3. Analyse et mise en œuvre de solutions Après analyse, voici la solution proposée pour contenter les différents acteurs.

• Les commandes qui ont fait l’objet d’une mise à jour de statut le jour J sur GCAV sont extraites par le SI, alimentent un fichier texte, appelé commandes_en_suivi_jourJ, qui est déposé dans un répertoire du réseau du SCA au soir du jour J. Dans ce fichier texte, les en-têtes de colonnes sont disposés de la manière dont souhaitaient le SCA et EMC.

37


Figure 16– Fichier texte des commandes en suivi

• Au matin du jour J+1, les lignes de ce fichier texte sont ensuite intégrées dans un fichier Excel, appelé suivi des réclamations, par le SCA.

Figure 17– Fichier de suivi des réclamations

Les colonnes jaunes ne sont pas modifiables, les colonnes vertes sont réservées aux prestataires et protégées d’un mot de passe, et les colonnes violettes sont réservées au SCA et protégées également d’un autre mot de passe.

• Le soir du jour J, les deux partenaires EMC et LeNôtre, envoient au SCA leur fichier de suivi des réclamations enrichi de leurs colonnes (colonnes vertes).

• Pour le fichier de suivi des réclamations EMC, les réclamations dont le point d’entrée est EMC sont envoyés au SCA le soir du jour J dans un fichier appelé Retours EMC, puis sont intégrées dans le fichier de suivi des réclamations au matin du jour J+1.

• Pour LeNôtre, il n’y a pas de fichier de Retours LeNôtre, car les appels des

clients arrivant chez LeNôtre, pour effectuer une réclamation, sont transmis directement au SCA.

• Au matin du jour J+1, le SCA intègre les colonnes des partenaires dans le fichier de suivi des réclamations correspondant, de façon à ce qu’il soit mis à jour.

• Toujours au matin du jour J+1, le SCA envoie au partenaire correspondant le

fichier de suivi des réclamations ainsi mis à jour.

• Au cours de la journée J+1, le SCA et les partenaires enrichissent parallèlement les colonnes des fichiers de suivi des réclamations qui leur sont réservées. De plus, lorsqu’une nouvelle réclamation arrive au SCA et plus généralement lorsqu’une commande le nécessite, le statut de cette dernière est modifié dans l’opérationnel, et une ligne viendra enrichir le soir le fichier texte des commandes_en_suivi_jour J+1.

38


• Le processus se poursuit ainsi de suite, de la même manière. La mise à jour de ces fichiers n’est donc pas en temps réel, mais est différée d’une journée, se fait de manière assez simple. De plus, les opérateurs du SCA peuvent travailler tous ensembles sur le même fichier, ce qui est valable pour les opérateurs des partenaires. Enfin, les commandes en réclamation sont tracées car leur statut est mis à jour. Pour illustration, le schéma du processus concernant le suivi des réclamations EMC :

Cdes en suivi – 11/05/2012 Projet Gestion des commandes Avantage Page 4

SCA Hub EMC EMC

Mises à jour de statut sur GCAV

du jour J

Dépôt

Disque commun SCA

Disque commun EMC

suivi EMC du jour Jenrichi des colonnes

SCA du jour J

Suivi EMC du jour J enrichi des colonnes

EMC du jour J

Soirée

jour J

Retours EMC jour J

Retours EMC du jour J


EMC du jour J

Dépôt du fichier

Dépôt du fichier

Figure 18– Etape 1 / processus de suivi des réclamations / soirée jour J

SCA Hub EMC EMC

Disque commun SCA

Disque commun EMC

suivi EMC du jour Jenrichi des colonnes

SCA du jour J


EMC du jour J

Enric

hiss

emen

t co

lonn

es

EMC

du

jour

J




EMC du jour J

Enric

hiss

emen

t lig

nes

reto

urs

EMC

du

jour

JEnrichissement lignes mises à

jour de statut sur GCAV du jour J

=

suivi EMC du jour J+1


du jour J

Figure 19– Etape 2 / processus de suivi des réclamations / matinée jour J+1

39


SCA Hub EMC EMC

Disque commun SCA

Disque commun EMC

suivi EMC du jour J+1 Suivi EMC du jour J enrichi des colonnes

EMC du jour J




EMC du jour J

Dépôt d

u fich

iersuivi EMC du jour J+1


du jour J


SCA Hub EMC EMC

Disque commun SCA

Disque commun EMC




EMC du jour J


Retours EMC du jour J+1


Dépôt du fichier


du jour J

Création du fichier


40


SCA Hub EMC EMC

Disque commun SCA

Disque commun EMC




EMC du jour J


Retours EMC du jour J+1


Saisies des mises à jour de statut du jour J+1 sur GCAV

Enrichissem

ent

Enrichissem

ent

Enrichissem

ent

Enrichissem

ent

Figure 22– Etape 5 / processus de suivi des réclamations / journée jour J+1

4. Rédaction de manuels utilisateurs Comme nous l’avons vu ci-dessus, le processus de suivi des réclamations nécessite des manipulations Excel chez le SCA. Or les opérateurs du SCA ne sont pas tous familiers avec cet outil bureautique, d’autant plus que ce processus nécessite des actions bien spécifiques. C’est pourquoi il était de la responsabilité de la MOA, de fournir des manuels utilisateurs au SCA. Trois manuels ont été écrits pas la MOA :

• Le premier s’appelle « Initialisation » et décrit les manipulations à effectuer côté SCA le premier jour de la mise en place du processus

• Le second s’appelle « Entretien » et décrit les manipulations à effectuer côté SCA à partir du 2ème jour.

• Le dernier s’appelle « Enrichissement » et décrit comment les opérateurs du SCA et les partenaires doivent enrichir les fichiers de suivi des réclamations.

C. Gestion de projet et conduite du changement Tout au long du projet, il était de la responsabilité de la MOA d’assurer le suivi de celui-ci. En effet, de part son rôle, la MOA fait le lien entre les différents acteurs (MOA, SCA, Marketing, Partenaires…) et doit les tenir informés de l’avancement, et les accompagner dans les changements qui vont s’opérer.

41


1. Comités de suivi et de coordination Les comités de suivi et de coordination (CSC) sont des réunions sous la responsabilité de la MOA, rassemblant les acteurs concernés du LCL. Ainsi, mensuellement, était organisé un CSC Avantage, dont le support, l’animation et le compte-rendu était à la charge de la MOA. Ce comité avait pour but de faire le point sur le programme Avantage en général et, par la même occasion, sur l’avancement du projet.

2. Rédaction plannings et feuilles de route Un planning global avait été rédigé par la MOA (partie II/C/2) afin de cadrer les grandes étapes du projet. Cependant, pour la mise en place et le déploiement, un grand nombre d’actions est à effectuer par les différentes entités du projet. C’est pourquoi la MOA a rédigé des feuilles de route dans le but de décrire qui fait quoi et comment. De cette manière, chacun sait ce qu’il a à faire et rien n’est oublié. Deux feuilles de route ont été produites :

• La feuille de route MOA/MOE décrivant les tâches et contrôles techniques à réaliser.

Figure 23– Feuille de route MOA/MOE

42


• La feuille de route MOA/SCA/Marketing/Partenaires détaillant plutôt les aspects organisationnels.

Figure 24– Feuille de route MOA/SCA/Marketing/Partenaires

3. Organisation de répétitions Une des responsabilités de la MOA durant un projet est la conduite du changement, c’est-à-dire qu’elle doit accompagner les différents acteurs impactés de manière à ce que la transition se fasse de façon la plus douce possible. C’est donc pourquoi, la MOA a organisé avant la mise en place du projet des répétitions sur le processus de suivi des réclamations entre le SCA et les partenaires, sur la réception des fichiers de commandes sur le plateforme Open-Trust pour les partenaires, sur des contrôles techniques pour elle et la MOE etc…

D. Plan de continuité d’activité Ce livrable rédigé par la MOA décrit comment maintenir l’activité du circuit des commandes Avantage an cas de sinistres informatiques, opérationnels ou techniques.

1. Analyse d’impacts La première étape pour la rédaction de ce document est de lister les grandes étapes du circuit des commandes et d’analyser l’activité des outils ou des traitements

43


associés. Par exemple, l’activité de l’opérationnel GCAV tourne autour de trois axes :

• La saisie des commandes • La consultation des commandes • La mise à jour du statut des commandes

Il faut ensuite mesurer l’impact d’un sinistre sur l’activité afin de déterminer la solution en mode dégradé la plus appropriée.

2. Solutions en mode dégradé Lors de ce projet, des possibilités « back-up » ont été intégrées lors des développements. Par exemple, la MOE a prévu une branche dans ses traitements qui récupère les fichiers de commandes, avant qu’ils ne soient envoyés, en automatique, aux partenaires. Un autre exemple est la prise en charge des commandes saisies par Fidelis, par les traitements de la MOE, cela permet à Fidelis d’être l’outil de back-up de GCAV pour les parties saisies de commandes et consultations. Les autres solutions, en mode dégradé, se traitent au cas par cas selon l’impact du sinistre sur l’activité.

E. Mise en place et suivi de production

1. Mise à jour des tables récompenses et partenaires Dans le cadre du projet, une nouvelle table de récompenses extra bancaires a été créée, et une table gérant les partenaires a été mise en place. Cela a été fait pour plusieurs raisons :

• Gérer avec plus de souplesse l’ajout et la modification de partenaires. • Pouvoir paramétrer le découpage de fichiers de commandes par

fournisseur lors de l’envoi automatisé. • Associer de nouvelles informations aux récompenses telles que leur

périmètre d’expédition ou leur mode d’expédition. Le paramétrage de ces tables est à la charge de la MOA, et son rôle est de s’assurer que leur contenu est le bon au bon moment. Par exemple, lorsqu’un partenaire bascule vers l’envoi automatisé, la MOA doit modifier le paramétrage correspondant du partenaire afin de le passer de ‘Non’ à ‘Oui’, le jour J, ni avant, ni après.

44


Figure 25– Table des récompenses extra bancaires

Figure 26– Table des partenaires

2. Suivi de production Bien qu’une recette ait été effectuée, la MOA effectue divers contrôles techniques lors de la mise en production car de mauvaises surprises peuvent arriver. Par exemple, lors du démarrage de l’opérationnel, nous avons vérifié ses différentes fonctionnalités. L’une d’entre elles permettait de consulter l’historique des commandes des adhérents, et cette dernière ne fonctionnait pas lors du passage en production. En effet, le temps de réponse de la requête qui allait chercher les

45


commandes qu’avait effectuées un adhérent était trop grand, si bien qu’un message d’erreur s’affichait et bloquait le processus. En recette, ce problème n’avait pas était détecté car les volumes sont beaucoup moins importants et donc la requête était plus rapide. Le problème a donc été pris en charge très tôt, et la mise en production a seulement était décalée de deux heures. Ceci explique pourquoi il est important d’effectuer à nouveaux des contrôles lors du passage en production. Ainsi, nous avons contrôlé tous les nouveaux fichiers produits, nous avons assisté le SCA dans le processus de suivi des réclamations, organisé des points téléphoniques avec les partenaires etc… A noter qu’à ce jour, le stage n’est pas terminé, et que la mise en production se déroule progressivement tout le mois de Septembre, sans trop d’encombre pour le moment.

46


Conclusion Projet Au moment de la rédaction de ce rapport, le stage n’est pas arrivé à son terme et le projet est en phase de mise en place et déploiement. Aucune anomalie de conception ou fonctionnelle n’est à signaler à ce jour sur l’opérationnel ou les traitements. L’opérationnel a connu un très bon accueil de tous les opérateurs du service client Avantage, pour ses qualités d’intuitivité, d’ergonomie et de fonctionnalité. Il est donc possible de conclure que la partie traitement des commandes est une réussite car nous nous sommes affranchis de l’outil Access en reprenant ses fonctions dans le SI, car l’échange des fichiers est désormais sécurisé, et enfin car les interventions manuelles sont réduites à leur minimum. Ainsi, le traitement des commandes Avantage a gagné en fiabilité et sécurité. Les premiers fichiers de suivi de réclamations ont été échangés entre le SCA et les partenaires, il est encore tôt pour dire si ce nouveau processus est un succès, cependant la traçabilité des commandes apporte un plus incontestable au niveau de la gestion des réclamations. Les différents acteurs s’adaptent doucement aux nouveaux modes de fonctionnement et processus, et nous MOA, sommes là pour les accompagner dans ces changements.

47


Conclusion personnelle Ce stage, bien qu’il ne soit pas encore arrivé à son terme, a été une expérience personnelle très enrichissante. Il m’a permis d’une part d’acquérir des compétences fortes en conduite de projet multi acteurs, car en tant que maîtrise d’ouvrage nous faisions le lien entre les partenaires et le SCA, le Marketing et la MOE. D’autre part, j’ai pu développer un savoir-faire fonctionnel, notamment des qualités d’analyse et de conception fonctionnelle, mais aussi d’étude d’impacts et de recette. Enfin, lors de l’optimisation du processus de suivi des réclamations, j’ai pu mettre en œuvre de réelles compétences d’ingénieur, à la fois dans le recueil du besoin, l’analyse de différentes solutions techniques et la mise en œuvre de celle la plus adaptée, en terme de besoin et de budget.

48


Liste des figures

Figure 1– Naissance de Logica....................................................................................... 8 Figure 2– Logica en Europe ............................................................................................ 9 Figure 3– Secteurs d’activité Logica.............................................................................. 10 Figure 4– Organisation Logica ...................................................................................... 11 Figure 5– Organigramme MOAP au LCL...................................................................... 14 Figure 6– Organigramme pôle Comptabilité, Risques, Pilotage de la banque.............. 14 Figure 7– circuit des commandes Avantage actuel....................................................... 17 Figure 8– circuit des commandes Avantage cible......................................................... 23 Figure 9– Comparaison circuit des commandes Avantage actuel vs cible ................... 24 Figure 10– Planning prévisionnel du projet ................................................................... 26 Figure 11– Schéma des développements réalisés dans le SI ...................................... 29 Figure 12– Nouvel opérationnel de gestion des commandes Avantage (GCAV) ......... 29 Figure 13– Plateforme d’échanges sécurisée Open-Trust............................................ 30 Figure 14– Procès Verbal de recette............................................................................. 32 Figure 15– L’Atelier sous MEGA ................................................................................... 34 Figure 16– Fichier texte des commandes en suivi ........................................................ 37 Figure 17– Fichier de suivi des réclamations ................................................................ 37 Figure 18– Etape 1 / processus de suivi des réclamations / soirée jour J..................... 38 Figure 19– Etape 2 / processus de suivi des réclamations / matinée jour J+1 ............. 38 Figure 20– Etape 3 / processus de suivi des réclamations / matinée jour J+1 ............. 39 Figure 21– Etape 4 / processus de suivi des réclamations / matinée jour J+1 ............. 39 Figure 22– Etape 5 / processus de suivi des réclamations / journée jour J+1 .............. 40 Figure 23– Feuille de route MOA/MOE......................................................................... 41 Figure 24– Feuille de route MOA/SCA/Marketing/Partenaires...................................... 42 Figure 25– Table des récompenses extra bancaires .................................................... 44 Figure 26– Table des partenaires.................................................................................. 44

49


Glossaire

• LCL : Le Crédit Lyonnais • MOAP : Maîtrise d’Ouvrage et Processus • MOE : Maîtrise d’œuvre • SCA : Service Client Avantage • SI : Système d’Information • GCAV : Gestion des Commandes Avantage • TFHE : Transfert de Fichiers Hors ELAN • PSP : Plateforme Site Produit • EDB : Expression De Besoins • NR/NPAI : Non Réclamé/N’est Plus à l’Adresse Indiquée • CSC : Comité de Suivi et de Coordination • CISI : Comité d’Investissement du Système d’Information

Documents

Ecole Centrale Marseille Logica LCL France Travail de Fin ... · Mathieu Esposito – Ecole Centrale Marseille – Promo tion 2012 Rapport de Stage Ingénieur de F in d’Etude s