Mise en oeuvre d’une application de télé marketing au sein du système d’informations d’Euler Hermes

(1)

HAL Id: dumas-01684436

https://dumas.ccsd.cnrs.fr/dumas-01684436

Submitted on 15 Jan 2018

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Mise en oeuvre d’une application de télé marketing au

sein du système d’informations d’Euler Hermes

Olivier Léger

To cite this version:

Olivier Léger. Mise en oeuvre d’une application de télé marketing au sein du système d’informations d’Euler Hermes. Ingénierie, finance et science [cs.CE]. 2015. �dumas-01684436�

(2)

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

CENTRE DE PARIS

________________________________

MEMOIRE

présenté en vue d’obtenir le

DIPLOME D’INGENIEUR CNAM

SPECIALITE : Informatique

OPTION : Architecture et Ingénierie des Systèmes et des Logiciels (AISL) par

LEGER Olivier

________________________________

Mise en œuvre d’une Application de Télé Marketing au sein du Système

d’Informations d’Euler Hermes.

Soutenu le mardi 08 septembre 2015 ________________________________ Président du Jury

Yann Pollet, Professeur CNAM Titulaire de la Chaire d'Intégration des systèmes Membres du Jury

Jean-Michel Douin, Maitre de conférences CNAM Yves Laloum, Professeur associé CNAM

(3)

RESUME

Euler Hermes est une société d’assurance-crédit fondée il y a plus de quatre-vingt ans. Elle fournit des services financiers pour ses clients, est experte en analyse de données financières et est le leader mondial de la gestion et couverture de risques client.

Afin de conserver cette place, elle doit continuer sa croissance et gagner de plus en plus de parts de marché face à ces concurrents. Dans ce cadre, la direction opérationnelle met en œuvre un nouveau processus métier de télé marketing afin de cibler et de qualifier d’éventuels prospects. L’évolution du système d’information est impérative afin de supporter ce processus et de lui faire bénéficier des avantages de l’informatisation.

Mots-clés: télé marketing, Salesforce.com, informatique en nuage.

SUMMARY

Euler Hermes is a credit insurance company created more than eighty years ago. She address the customers by providing financial services. Also, she’s an expert in financial data analysis and the world leader for the risk & coverage management.

In order to keep her position, she needs to grow up and more and more to gain market share against its competitors. The operational management implement a new telemarketing business process in order to target and qualify leads. The information system should evolve to support this process and to provide benefits bound to the information technology.

(4)

REMERCIEMENTS

Je remercie monsieur Yann POLLET, responsable national du diplôme d’ingénieur en Architecture et Ingénierie des systèmes et des logiciels, pour le partage de ses connaissances et ses précieux conseils.

Je tiens à remercier l’école d’ingénieurs du CNAM pour la qualité de son enseignement et les moyens qu’elle met en œuvre pour y parvenir.

Merci au CNAM, qui rend accessible une formation de qualité grâce à des modalités d’enseignements adaptées aux personnes insérées dans la vie active et désireuses d’apprendre.

(5)

LISTE DES ABREVIATIONS

AGF Assurances Générales de France API Application Programming Interface BIM Business Information Management BPM Business Process Management BU Business Unit

CAP Centre d'Analyse et de Programmation CNAM Conservatoire National des Arts et Métiers CRM Customer Relationship Management CRUD Create Retrieve Update Delete CSS Cascading Style Sheet

CTI Computer Telephony Integration DIT Development, Integration and Testing

DITM Development, Integration and Testing for Maintenance DITR Development, Integration and Testing for Release DML Database Manipulation Language

DSI Direction des Systèmes d'Informations DTS Digital Transformation Services

EHID Euler Hermes ID ESB Enterprise Service Bus

ESN Entreprise de Services du Numérique ETL Extract Transform Load

GGS GrapeCity Global Services

HP ALM Hewlett-Packard Application Lifecycle Management HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IDE Integrated Development Environment IRP Système de gestion des polices d'assurance IT Information Technology

JH Jour / Homme

MOA Maîtrise d'ouvrage MOE Maîtrise d'œuvre MVC Model View Controller

(6)

OADM Système de gestion des adresses de compte et de contact PaaS Platform as a Service

PAD Parallel Development PDG Président Directeur Général

PMBOK Project Management Body of Knowledge PME Petites et Moyennes Entreprises

RFC Request For Change

RIDA Relevé d'Informations Décisions et Actions ROI Return On Invest

SaaS Software as a Service SF Salesforce

SF1 Salesforce1

SFAC Société Française d'Assurance-crédit SGBD Système de Gestion de Base de Données SI Système d'Information

SOAP Simple Object Access Protocol SoQL Structured Object Query Language SoSL Structured Object Search Language

SWOT Strengths Weaknesses Opportunities Threats TMA Tierce Maintenance Applicative

TMK Telemarketing TTM Time to Market

UAT User Acceptance Testing

UATM User Acceptance Testing for Maintenance UATR User Acceptance Testing for Release UML Unified Modeling Language

USA United States of America WBS Work Breakdown Structure XML Extensible Markup Language XSD XML Schema Definition

(7)

SOMMAIRE

RESUME ... 2

REMERCIEMENTS ... 3

LISTE DES ABREVIATIONS ... 4

SOMMAIRE ... 6

PARTIE I : PRESENTATION DU PROJET ... 8

1.Introduction ... 8

2.Contexte ... 9

2.1. Capgemini ... 10

2.2. Euler Hermes ... 11

2.2.1. Présentation d’Euler Hermes ... 11

2.2.2. Hiérarchie ... 13

2.3. Interlocuteurs clés ... 14

2.4. Système de gestion de la relation client ... 15

2.4.1. Cartographie fonctionnelle ... 15

2.4.2. Cartographie technique ... 18

2.4.3. Cartographie des flux associés au système CRM ... 20

2.5. Cycle de vie des versions... 23

2.6. Détails des environnements ... 25

PARTIE II : CADRAGE ET MISE EN OEUVRE ... 28

1.Préambule ... 28

2.Besoins métiers ... 28

3.Étude de solutions ... 29

3.1. Préparation de l’étude ... 29

3.2. Contraintes et hypothèses ... 31

3.3. Identification des candidats ... 33

3.3.1. Exploration du SI Euler Hermes ... 33

3.3.2. Le module télémarketing de Salesforce.com ... 34

3.3.3. L’application GrapeCity ... 35

3.3.4. Les développements spécifiques... 36

3.4. Synthèse de couverture fonctionnelle ... 36

3.5. Estimations... 37

3.5.1. Estimation du module télémarketing de Salesforce.com ... 39

3.5.2. Estimation de l’application GrapeCity ... 41

3.5.3. Estimation des développements spécifiques ... 42

3.6. Synthèse des estimations ... 43

3.7. Prise de décision ... 44

4.Implémentation de la solution ... 47

4.1. Mise en place de l’organisation ... 47

4.1.1. Planification ... 47

4.1.2. Répartition des tâches... 52

4.2. Spécifications fonctionnelles ... 52

4.2.1. Créer un utilisateur télémarketing (UC-001) ... 54

4.2.2. Créer une équipe télémarketing (UC-002) ... 55

4.2.3. Définir les paramètres de l’application télémarketing (UC-003) ... 56

4.2.4. Créer une campagne télémarketing (UC-004) ... 57

4.2.5. Gérer les prospects de la campagne (UC-005) ... 58

4.2.6. Marquer un compte dans une campagne (UC-006) ... 60

4.2.7. Visualiser les prospects à appeler (UC-007) ... 61

4.2.8. Gérer un appel (UC-008) ... 62

4.2.9. Convertir un prospect (UC-009) ... 65

4.2.10. Critères non fonctionnels (droits, visibilité des données) ... 65

4.2.11. Spécifications fonctionnelles ... 68

4.3. Développements et paramétrages ... 76

4.3.1. Rappel sur l’organisation des développements ... 76

(8)

4.3.3. Outils de développement ... 87

4.4. Validation interne et Recette ... 89

4.4.1. Première livraison ... 89

4.4.2. Deuxième livraison ... 90

4.4.3. Troisième livraison ... 91

4.5. Mise en production ... 91

4.6. Évolutions ... 92

4.6.1. Option de recherche dans la liste des prospects ... 93

4.6.2. Lien vers le compte depuis un prospect ... 94

4.6.3. Gestion des prospects par les managers ... 95

4.6.4. Nouveaux types d’utilisateurs ... 96

4.6.5. « Marquer un compte dans une campagne » pour les agents ... 96

4.6.6. Autres évolutions ... 97

PARTIE III : RETOUR D’EXPERIENCE ET CONCLUSION ... 99

1.Retour d’expérience sur la solution SaaS Salesforce.com ... 99

1.1. Délais ... 99

1.2. Technique ... 99

1.3. Travail en équipe ... 100

2.Conclusion ... 100

ANNEXES ... 103

Annexe 1 : Planning des versions ... 104

Annexe 2 : Lettre d’informations ... 105

BIBLIOGRAPHIE ... 106

TABLEAUX ET FIGURES ... 107

1.Liste des tableaux ... 107

(9)

PARTIE I : PRESENTATION DU PROJET

Introduction

PARTIE I : PRESENTATION DU PROJET

1. Introduction

Je suis architecte de solution chez Capgemini dans l’entité « Financial Services ». Au quotidien, je suis amené à travailler sur des projets informatiques pour nos clients du domaine de la finance (finance, banque, assurance).

Depuis mai 2013 je suis en mission sur un projet de maintenance applicative chez notre client Euler Hermes, spécialiste de l’assurance-crédit, concernant le système de gestion de la relation client. Lors de l’expression de besoins de l’équipe métier je joue le rôle de consultant maîtrise d’ouvrage (MOA) en reformulant et en étayant le besoin pour des solutions adéquat. Lorsque les solutions sont choisies, je joue le rôle de consultant maîtrise d’œuvre (MOE) et participe à la mise en œuvre dans le système CRM.

Ce système est composé de plusieurs applications : gestion de la relation client, gestion des incidents, applications pour la synchronisation des systèmes entre eux et vis-à-vis du système d’information.

L’application de gestion de la relation client (CRM - Customer Relationship Management -) est une application groupe utilisée par plus de 1 800 utilisateurs dans 35 pays à travers le monde. Elle est traduite en 4 langues et contient plus de 8 millions de données métiers dont elle est la source dans le système d’information (3,5 millions de comptes, 3,5 millions de contacts, 500 000 souscriptions de contrats).

Cette application intervient au tout début du processus de souscription des produits d’assurance, de la création de prospects à la transformation de ces derniers en clients associés à des propositions de contrats.

En juin 2013, l’équipe métier dédiée à la relation client a défini une stratégie visant à atteindre des objectifs de l’entreprise en termes d’acquisition de nouveaux clients et de nouvelles souscriptions de contrats d’assurances, le but étant d’augmenter le chiffre d’affaires de l’entreprise.

L’application de cette stratégie a conduit à la création d’un nouveau processus d’entreprise pour la souscription de contrat: celui-ci démarre par une phase de prospection téléphonique

(10)

Contexte

et termine par la création d’une opportunité de vente, tout en réduisant le nombre d’étapes nécessaires par rapport au processus classique.

Mon mémoire d’ingénieur CNAM en Architecture et Ingénierie des Systèmes et des Logiciels détaille les différentes étapes de la mise en œuvre d’un système informatique permettant de supporter ce processus, de la phase d’expression de besoins métiers initiale, en passant par la définition de la solution (technologies, fonctionnements, contraintes), jusqu’à la mise en production et la phase de maintenance.

2. Contexte

Début 2013, la direction « Group IT Development » d’Euler Hermes a lancé un appel d’offre pour le renforcement de son équipe de maintenance du CRM Salesforce.com. Cette équipe prend en charge les demandes d’évolutions émanant de l’équipe métier et également les corrections d’anomalies issues de la recette ou de la production. Elle est composée de deux personnes et ne permet pas d’absorber la charge de travail liée d’une part à la maintenance corrective (corrections d’anomalies) et d’autre part à la maintenance évolutive (mise en œuvre des évolutions des besoins métiers).

Cet appel d’offre fut remporté par Capgemini et c’est début mai 2013 que notre équipe a rejoint le projet, elle fut initialement composée d’un responsable de projet, d’un responsable technique et de deux développeurs juniors.

Dans mon rôle de responsable technique sur le projet, je travaille sur plusieurs périmètres de responsabilités :

 Expertise sur le CRM Salesforce vis à vis de notre client direct (Group IT) et de l’équipe métier (Core Business);

 Définition des principes et choix d’architecture, de conception;  Définition de solutions, estimations;

 Encadrement des consultants juniors;

(11)

Contexte

Dès le démarrage de l’activité, il m’a été confié l’étude et la mise en œuvre d’une solution de télémarketing au sein du système IT CRM d’Euler Hermes.

2.1. Capgemini

Capgemini est une société de conseils, d’intégration et d’infogérance, classée comme Entreprise de Services du Numérique (ESN), fondée en 1967 par Serge Kampf. A cette époque, elle portait le nom de Sogeti, qui existe toujours aujourd’hui et qui fait partie du groupe Capgemini.

En 1973, Serge Kampf rachète des parts de la société CAP (Centre d’Analyse et de Programmation) et en 1974, CAP et Sogeti fusionnent pour devenir Cap Sogeti. La même année, la société acquiert Gemini Computer Systems et donne naissance, en 1975 à Cap Gemini Sogeti.

En 1996, le groupe change de nom pour s’appeler Cap Gemini, puis, en 2004, adopte définitivement le nom de Capgemini.

Aujourd’hui, Capgemini est un groupe qui emploie plus de 130 000 personnes dans le monde et qui réalise un chiffre d’affaire d’environ 10 000 millions d’euros.

Son offre de services se répartit selon quatre métiers :  Conseil, réalisé par la filiale Capgemini Consulting;

 Intégration de systèmes, réalisé par la filiale Capgemini Technology Services;  L’infogérance, réalisée par la filiale Capgemini Outsourcing Services;

 L’assistance technique et les services aux PME, réalisés par la filiale Sogeti.

Je suis employé chez Capgemini depuis janvier 2012, au sein de l’entité Digital Transformation Solution de la Business Unit Financial Services de la filiale Capgemini Technology Services.

Cette BU est divisé en entités selon trois types d’activités :

 TIM Solutions, en charge de la transformation et de la modernisation des systèmes d’informations;

(12)

Contexte

 Domains & BIM Solutions, en charge du traitement de l’information et de l’intelligence liée à celle-ci;

 Digital Transformation Solutions (DTS), en charge de la transformation digitale des systèmes d’informations (CRM, BPM…).

2.2. Euler Hermes

2.2.1. Présentation d’Euler Hermes

Euler Hermes est un établissement d’assurance-crédit qui participe au développement commercial des entreprises quelle que soit leur taille, leur secteur d’activité ou leur nationalité. A partir de ce cœur de métier, Euler Hermes a développé une offre complète de services pour la gestion du poste clients des entreprises. Ses clients bénéficient de sa connaissance des risques d’entreprises acquise par ses experts situés au plus près des acheteurs, partout dans le monde.

De son offre historique d’assurance-crédit à son offre de caution, Euler Hermes est le leader mondial de la gestion et de la couverture des risques clients.

En 1927, la Société Française d’Assurance-crédit (SFAC) est fondée en France. En 1992 est signé le premier accord entre SFAC et Hermes, société d’assurance-crédit allemande créée en 1917. En 1996, la société AGF (Assurances Générales de France, créée en 1818) devient actionnaire majoritaire de SFAC qui s’appelle alors Euler, dans le même temps, la société Allianz (société allemande créée en 1890) acquiert Hermes. Peu de temps après, Allianz devient actionnaire majoritaire d’AGF. En 2002, Euler acquiert Hermes et devient Euler Hermes.

Depuis 2009 son chiffre d’affaire croît et atteint les 2 400 millions d’euros en 2012. Elle emploie plus de 6000 personnes à travers le monde et est présente dans plus de 50 pays. Très récemment, en 2013, elle s’est associée avec la société MAPFRE (société d’assurance espagnole créée en 1933) pour créer la joint-venture Solunion et être présente sur les marchés d’Amérique latine, répondant à COFACE, son principal concurrent, qui a également

(13)

Contexte

Euler Hermes répartit son activité commerciale selon trois offres :  L’assurance-crédit ;

 Le recouvrement ;  La caution.

L’assurance-crédit est une assurance qui protège les entreprises contre le risque d'impayés en leur permettant d’être couvertes et indemnisées en cas de non-paiement de leurs créances commerciales, sur leur marché domestique comme à l'export (on parle alors d'assurance-crédit export). Elle assure le fournisseur contre le risque d'impayés des biens livrés ou des services fournis à son client. En outre, l'assureur-crédit informe le fournisseur sur la solvabilité de ses clients.

Le recouvrement de créances commerciales constitue l'un des services essentiels du contrat d'assurance-crédit, c'est aussi une activité à part entière qui concourt à préserver la rentabilité de l'entreprise sur son marché domestique comme à l'export.

Le recouvrement amiable vise à recouvrir les créances au travers de relances efficaces par courrier, téléphone ou en rendant directement visite au débiteur.

Le recouvrement judiciaire consiste à mettre en œuvre des procédures judiciaires nécessaires à l'obtention du paiement des sommes dues. Euler Hermes choisit la procédure la mieux adaptée selon le montant de la créance, les motifs de non règlement et les spécificités du pays de l’acheteur.

La caution (ou garantie) financière est un engagement par signature pris par un établissement financier qui permet, en cas de défaillance contractuelle de l’entreprise débitrice, de couvrir le bénéficiaire de la caution et ainsi de sécuriser son environnement commercial dans le cadre de la réalisation d’un contrat.

Il existe :

 Les cautions de marché dites contractuelles : cautions de soumissions, cautions retenues de garanties, cautions de remboursement d'avance, cautions de bonne fin;  Les cautions dites légales : cautions douanières, cautions de sous-traitance, cautions

(14)

PARTIE I : PRESENTATION DU PROJET Contexte

installations classées « Seveso », sites de stockage de déchets non dangereux et toutes autres installations susceptibles de porter atteinte à l’environnement).

2.2.2. Hiérarchie

Le diagramme hiérarchique d’Euler Hermes est présenté ci-dessous. Celui-ci est focalisé sur les personnes intervenantes sur le projet ainsi que leurs supérieurs hiérarchiques.

Figure 1. Diagramme hiérarchique d’Euler Hermes.

Le PDG d’Euler Hermes est Wilfried VERSTRAETE. La DSI groupe est dirigée par Florence LECOUTRE et est intégrée à la branche « Opérations », dirigée par Dirk OEVERMANN, également membre du conseil d’administration.

La DSI est divisée en 2 branches : la partie production (en charge des équipements physiques qui constituent le SI et de leurs maintient en conditions opérationnelles) et la partie développements (en charge de la maintenance des applications du SI).

Le directeur de la branche développements est Thierry LAMOTTE, celui-ci est aidé par Olivier LEHE, directeur de programme. Le système CRM est géré par Bruno CADOT, aidé de

(15)

Contexte

La direction marketing gérée par Isabelle DELORME est intégrée à la branche « Gestion des Marchés » dirigée par Paul OVEREEM, membre du conseil d’administration. Aurélie GIARD est la directrice marketing opérationnelle.

La direction des ventes et distributions est gérée par Elisabeth PERIE, cette direction est également intégrée à la branche « Gestion des Marchés ». Edouard NICOLAS est responsable de projet relation client, il dépend de Yann LE GOFF, directeur de la relation client.

2.3. Interlocuteurs clés

On distingue deux types d’interlocuteurs ayant directement un lien avec le système CRM: l’équipe métier et l’équipe informatique.

L’équipe métier, nommée CRM Core Business ou plus simplement Core Business, s’occupe de récolter les besoins des utilisateurs, de les qualifier, de les synthétiser et, si besoin, de les traduire en demandes de changements. Elle est également en charge de l’amélioration des processus métiers liés à la relation client et au marketing.

Cette équipe métier est constituée de membres appartenant à la branche « Gestion des Marchés ».

L’équipe informatique nommée CRM IT Maintenance, s’occupe d’une part de la conception de solutions en réponses aux besoins métiers sur le périmètre de la relation client et du marketing jusqu’à leurs mises en œuvres, et, d’autre part, de la maintenance corrective sur le système en production (correction d’anomalies).

Cette équipe informatique est constituée de membres appartenant à la branche « Opérations ».

Côté métier, pour le projet de relation client et marketing :  Yann LEGOFF, Directeur de la Relation Client ;  Aurélie GIARD, Directrice Marketing Opérationnel ;  Edouard NICOLAS, Responsable de projet Relation Client ;

 Sylvain DAVRIL, Responsable de projet Relation Client, en prestation pour Edouard NICOLAS ;

(16)

Contexte

 Jocelyne ASSOGBA, Responsable de projet Relation Client, en prestation pour Edouard NICOLAS ;

 Charlotte SEVENET, chargée d’étude, en prestation pour Edouard NICOLAS. Côté informatique, pour le projet de maintenance évolutive du CRM :

 Bruno CADOT, Responsable de projet CRM ;  Brice JONCQUEZ, Responsable CRM ;

 Mohammed NAZZAL, Responsable CRM, en prestation pour Bruno CADOT ;

 Olivier LEGER, Responsable technique de solution Salesforce, en prestation pour Bruno CADOT ;

 Andry RAMARIJAONA, Développeur senior Salesforce, en prestation pour Bruno CADOT.

2.4. Système de gestion de la relation client

2.4.1. Cartographie fonctionnelle

(17)

Contexte

(18)

Les blocs fonctionnels correspondant à l’activité de gestion de la relation client sont les suivants :

Figure 3. Blocs fonctionnels pour la gestion de la relation client.

Le domaine de la relation client (Customer Relationship Management) est composé d’un sous domaine de gestion des interactions (Interaction Management) lui-même composé des grandes fonctions de gestion des demandes et gestion des plaintes (Customer Request et Complains).

Le domaine de la gestion des comptes (Account) est composé d’un sous domaine de gestion des comptes opérationnels (Operational Account Management), c’est à dire, les comptes liés à des devis ou contrats, et dans lequel on trouve les grandes fonctions de gestion des clients (Client Management) et de gestion des intermédiaires de vente (Intermediaries Management). Dans un autre sous domaine, gestion des contacts (Contact Management), on trouve les grandes fonctions associés à la gestion des contacts.

Le domaine commercial (Commercial) regroupe les fonctions de gestion des affaires, ce dernier est composé d’un sous domaine vente (Sales) composé des fonctions liées au cycle de vente (Sales Cycle).

(19)

Contexte

Le domaine marketing (Marketing) regroupe les activités de marketing, le sous domaine prospection (Prospecting) est composé de fonctions associées à la gestion des campagnes marketing (Campaign Management).

2.4.2. Cartographie technique

Les différents domaines fonctionnels permettant la gestion de la relation client sont supportés par quatre applications au sein du SI Euler Hermes :

 Group Ticketing, une application réalisée en développements spécifiques permettant la gestion des incidents des clients :

o Sous domaine fonctionnel Interaction Management du domaine Customer Relationship Management.

 Copernicus, une application de gestion de la relation client basée sur la solution vendeur Salesforce.com et hébergée dans le cloud (SaaS) :

o Sous domaine fonctionnel Prospecting du domaine Marketing ;

o Sous domaine fonctionnel Operational Account Management du domaine Account ;

o Sous domaine fonctionnel Sales du domaine Commercial.

 OADM, une application réalisée en développements spécifiques basée les technologies J2EE et DB2 pour la mise à disposition des données de contacts :

o Sous domaine Contact Management du domaine Account.

(20)

Figure 4. Diagramme d’architecture technique CRM.

Ce diagramme fait apparaître des éléments qui n’ont pas vocation à supporter des fonctionnalités métiers mais qui servent à faciliter les relations entre les applications au sein du SI. Il s’agit de : ● DataPower ; ● ESB ; ● Smart Link ; ● Exchange Platform.

Le DataPower est un équipement matériel d’IBM chargé d’une part de centraliser les flux qui sont à l’initiative de l’application Copernicus vers une des applications du SI Euler Hermes, et d’autre part de centraliser les flux qui sont à l’origine du SI vers Copernicus (mais ne se limite pas à Copernicus). Techniquement, il s’agit d’un équipement proxy / reverse proxy en charge du routage des requêtes HTTP entrantes et sortantes du SI pour masquer celui-ci du

ESB

Group Ticketing OADM Exchange Platform

SmartLink

DataPower Copernicus

(21)

Contexte

réseau internet. Il réalise également la validation des flux HTTP qui le traverse par rapport à une description (validation XSD).

En synthèse, le DataPower est le point de passage incontournable pour l’accès à internet par une application depuis le réseau Euler Hermes. C’est également le cas pour le fonctionnement inverse, lorsqu’une application sur internet ou un autre réseau privé souhaite accéder au réseau Euler Hermes.

Du fait que Copernicus soit basée sur la solution SaaS de Salesforce.com, hébergée dans le cloud, le recours à cet équipement est indispensable.

L’ESB (Enterprise Service Bus) de l’éditeur Tibco est un système de communication transverse entre applications du SI. Il est connecté à quasiment toutes les applications et permet de relier des systèmes entre eux (centralisation des flux) au lieu que les applications soient reliées directement les unes aux autres (évitant ainsi le modèle de SI dit « spaghetti » avec un couplage fort entre les systèmes). Il est utilisé principalement pour les échanges de données synchrones, c’est à dire, lorsqu’une application A a un besoin immédiat d’informations ou doit déclencher un traitement dans une application B.

Exchange Platform est un ETL (Extract Transform Load) qui permet le chargement et la lecture de données en masse dans l’application Copernicus. Il s’agit d’un composant entièrement réalisé en développements spécifiques.

Généralement, ce système fonctionne de manière asynchrone et se déclenche en fonction de tâches planifiées (par exemple, extraction des données de compte chaque nuit).

Smart Link est un ESB réalisé en développements spécifiques dédié à l’application IRP qui est le système en charge de la gestion des polices d’assurances du SI, il est utilisé par Copernicus en mode synchrone dans certains cas.

2.4.3. Cartographie des flux associés au système CRM

Le diagramme de flux suivant représente l’éco système du CRM et les relations entre les systèmes internes d’une part (présentés à la rubrique précédente), et les systèmes externes d’autre part.

(22)

Contexte

Les systèmes internes sont représentés en bleu, les systèmes externes sont représentés en blanc dans un cadre violet.

(23)

Contexte

(24)

Contexte

Ce diagramme représente les différents échanges qui existent et permet de voir le nombre de relation entre les systèmes.

De manière générale, le fonctionnement des échanges inter-applicatifs est le suivant :

 Les échanges synchrones sont réalisés par des web services de type SOAP et transitent obligatoirement par l’ESB ;

 Les échanges asynchrones sont réalisés par des files de messages et transitent obligatoirement par l’Exchange Platform.

2.5. Cycle de vie des versions

Les règles de gouvernance du système d’information Euler Hermes définissent trois mises à jour majeures par an ainsi que trois mises à jour mineures par an.

Cela signifie que l’ensemble des nouvelles versions des applicatifs sont mis en production en même temps à date fixe, selon un planning défini par les directeurs de domaines applicatifs. Une version majeure est une version qui apporte un ensemble de fonctionnalités nouvelles sur une ou plusieurs applications. Il est important que toutes les applications évoluent en même temps pour conserver l’intégrité des données et des processus transverses (processus métier qui utilisent plusieurs applications).

Une version mineure est une version qui apporte un ensemble de correctifs sur les applications du système d’information en production. Sauf cas exceptionnel, il n’y a pas de nouvelles fonctionnalités dans une version mineure, il s’agit uniquement de corriger les anomalies.

Le nommage d’une version est défini comme suit :

année . version de l’année . numéro de révision mineure Le planning des versions de l’année 2013 est le suivant :

(25)

Contexte

Tableau I. Planning des versions 2013.

Type de version Numéro Date de mise en production

Mineure 12.3.1 01/02/2013 Majeure 13.1.0 23/03/2013 Mineure 13.1.1 25/05/2013 Majeure 13.2.0 29/06/2013 Mineure 13.2.1 07/09/2013 Majeure 13.3.0 12/10/2013

Chaque montée de version du SI est planifiée environ un an à l’avance. Un planning est défini pour chaque intervenant de la chaîne : les équipes de développements, les équipes de tests et les équipes métiers.

Chaque période de temps allouée à une version est découpée en plusieurs parties (appelée Package), servant de lots intermédiaires pour la construction de la nouvelle version.

Ce découpage existe pour permettre à la DSI et aux équipes métiers une meilleur organisation, une meilleure répartition de l’activité et une meilleure mobilisation des ressources, ainsi par exemple les équipes de tests n’ont pas besoin d’attendre les versions finales de tous les applicatifs du SI pour réaliser les validations (autrement la charge de travail serait trop lourde).

Par exemple, pour la version majeure 13.2.0 de l’année 2013, le planning est le suivant : ● Partie 1 :

o Du 25/02 au 08/03 : spécifications ;

o Du 11/03 au 28/03 : développements et tests unitaires ; o Du 03/04 au 19/04 : tests de validation ;

o Du 15/04 au 10/05 : tests de recette. ● Partie 2 :

(26)

Contexte

● Go / No go : 14/06 ;

● Mise en production : 29/06.

Le fichier original est disponible en annexe.

Les projets participant à une montée de version sont réalisés à l’aide d’un cycle en V mis en œuvre pour chaque partie : d’abord une phase de spécification fonctionnelle et technique, puis une phase de développement avec tests unitaires, enfin, une phase de validation avant livraison aux équipes métiers pour la phase de recette.

Lorsque toutes les parties sont terminées, l’équipe de tests réalise des tests de non régression pour s’assurer qu’il n’y a pas eu de modifications fonctionnelles involontaires sur les applications, par involontaire j’entends non prévue par une demande de changement. Ces tests de non régression sont clôturés par une phase de Go / No go qui consiste en un arbitrage entre les équipes pour décider si les applications en nouvelle version correspondent bien à ce qui est attendu, qu’il n’y a pas d’anomalies bloquantes et pas de régression.

Si jamais ce n’est pas le cas, l’application concernée doit impérativement annuler toutes ses évolutions et revenir en arrière, comme si rien ne s’était passé, on parle alors de roll back. Ceci peut être problématique lorsqu’une application qui participe à un processus transverse doit revenir en arrière, c’est alors l’ensemble des applications qui supportent le processus qui doivent revenir à leur version précédente, demandant un effort de mise en œuvre dans un temps très court.

2.6. Détails des environnements

La mise en œuvre de différentes versions du SI oblige à séparer celles-ci dans différents environnements pour qu’elles n’entrent pas en concurrence les unes avec les autres.

On trouve donc deux types de version :

(27)

Ce découpage est nécessaire car il permet de garder une cohérence entre les différents systèmes composant le SI, notamment lorsque différents systèmes échangent de l’information (cet échange étant conforme à la version où il est apparu).

Pour chaque version il existe différents environnements : ● Développements, tests de validation et d’intégration ; ● Tests de recette.

La définition de différents environnements permet de conserver l’intégrité des données pour un environnement entier. Par exemple, lorsqu’un compte est créé dans Copernicus, celui-ci est créé dans OADM qui, en retour, donne un numéro unique de compte. Ce numéro est propre au compte en question et pour l’environnement concerné, il pourrait correspondre à un tout autre compte dans un autre environnement, voire il pourrait ne pas exister.

On imagine alors facilement que si un environnement Copernicus de développement est connecté à un environnement OADM de tests, les données ne sont plus fiables et toutes les applications qui sont reliées à celles-ci sont impactées.

(28)

Contexte

Les environnements de développements DIT (Development, Integration & Testing) sont dédiés à la construction des applications du SI. L’environnement DITR est ainsi dédié aux développements d’évolutions (Release), l’environnement DITM est dédié aux développements de correction d’anomalie (Maintenance). Ces environnements accueillent également les tests MOE (tests unitaires, tests d’intégration, tests de validation).

Les environnements UAT (User Acceptance Testing) sont dédiés aux tests de recette par les équipes métiers.

Ainsi, UATR est spécifique à la recette des versions majeures et UATM est spécifique à la recette des versions mineures.

Toutes les applications qui ont passé le Go / No go avec succès sont déployées en environnement de production. Cet environnement est dédié aux utilisateurs finaux des systèmes composants le SI Euler Hermes.

(29)

PARTIE II : CADRAGE ET MISE EN OEUVRE

Préambule

PARTIE II : CADRAGE ET MISE EN OEUVRE

1. Préambule

La stratégie d’entreprise visant à augmenter le nombre d’acquisitions de clients et de souscriptions de contrats a donné lieu à la création d’un nouveau processus métier qui démarre par une phase de prospection téléphonique. A cette date il n’existe pas de système informatique permettant la réalisation de ce métier dans le système d’information d’Euler Hermes.

Lors de mon arrivée sur le projet CRM en 2013, il m’a été confié le travail d’étude et de réalisation d’une solution télémarketing répondant aux besoins métiers. Cette partie décrit l’ensemble des étapes de la mise en œuvre au sein du SI.

2. Besoins métiers

La stratégie d’Euler Hermes pour l’année 2014 vise à accroître le nombre de pistes commerciales à transformer en contrat de souscription d’assurance. Pour ce faire, l’équipe métier d’Euler Hermes a conçu un nouveau processus métier de prospection téléphonique, aussi appelé télémarketing.

Tout d’abord, un responsable construit une campagne télémarketing. Cela consiste principalement en l’ajout d’un nombre de candidat à l’appel à une campagne. Il paramètre ensuite les affectations de ces prospects à son équipe constituée d’agent télémarketing. L’affectation peut aussi bien se faire personnellement (d’un prospect à un agent) que par équipe (un volume de prospect dédié à une équipe).

Enfin, le responsable peut démarrer sa campagne : cela a pour effet d’autoriser les agents à appeler les prospects.

L’agent télémarketing utilise le système pour contacter un à un les prospects qui lui sont disponibles (soit par assignation personnelle, soit pas assignation d’équipe). Selon le résultat de l’appel, le statut du prospect évolue : tout ce qui ne consiste pas en un appel direct (sonnerie occupée, messagerie, standard, etc.) ne permet pas de faire avancer le processus.

(30)

Étude de solutions

Par exemple, le prospect peut être abandonné pour cause de faux numéro. Autre exemple, le numéro sonne occupé, le prospect est alors maintenu dans la liste des prospects à appeler.

A l’inverse, un contact direct avec le prospect permet de faire avancer le processus et consiste à collecter de l’information dans le but de vendre des produits.

Lorsque le prospect répond favorablement aux sollicitations de l’agent et qu’il est intéressé par un ou plusieurs produits du catalogue d’Euler Hermes, un rendez-vous est planifié afin qu’un agent commercial puisse visiter le futur client et mener un entretien.

Ces besoins sont détaillés dans une RFC (Request For Change) sous le numéro 43234, enregistré dans un système de gestion des cycles de vie des logiciels (HP ALM) le 16 mai 2013.

Ce système permet de tracer les demandes de nouvelles fonctionnalités / changements, en partant de l’expression de besoin métier à la mise en production si le besoin est accepté et pris en charge par la DSI.

3. Étude de solutions

3.1. Préparation de l’étude

Pour procéder à la conception de solutions pour ces besoins, j’ai choisis de regrouper les fonctionnalités attendues en 3 ensembles logiques : les fonctionnalités liées à la configuration du système de télémarketing, celles liées aux paramétrages des campagnes et les fonctionnalités relatives à l'exécution d’une campagne.

Ce découpage permet d’affecter des fonctionnalités aux différentes solutions possibles pour ainsi voir laquelle couvre le plus les besoins, laquelle les couvres le moins, quels sont les efforts à fournir pour ajouter les fonctionnalités manquantes à une solution incomplète (coûts, délais).

(31)

Étude de solutions

 Configuration du système télémarketing : créer un utilisateur, créer une équipe, paramétrer les valeurs par défaut;

 Paramétrage d’une campagne : créer une campagne, ajouter des prospects, assigner les prospects à une équipe ou un utilisateur, marquer un compte en tant que prospect;

 Déroulement d’une campagne : visualiser les prospects à appeler, enregistrer un appel, convertir un prospect en opportunité, planifier un rendez-vous.

Ces fonctionnalités sont regroupées dans une matrice, plus facile à manipuler : Tableau II. Liste des fonctionnalités.

Fonctionnalités Solution

Configuration du système 1. Créer un utilisateur 2. Créer une équipe

3. Paramétrer les valeurs par défaut Paramétrage d’une campagne 5. Créer une campagne

6. Ajouter des prospects 7. Assigner les prospects

8. Marquer un compte en tant que prospect Déroulement d’une campagne

9. Visualiser les prospects à appeler 10. Enregistrer un appel

(32)

Étude de solutions

12. Planifier un rendez-vous

3.2. Contraintes et hypothèses

Afin de proposer des solutions en adéquation avec les attentes de l’équipe Core Business et les règles de gouvernance du SI Euler Hermes, j’ai dû collecter les éléments qui pourraient avoir une incidence sur l’orientation technologique ou fonctionnelle de mes propositions et donc in fine sur la charge de travail et le coût.

Du point de vue technique, il n’est pas envisagé l’achat de nouveau matériel tel qu’un serveur pour supporter l’exécution d’une application de serveur web ou autre. Il est par contre envisageable d’exploiter du matériel existant en profitant des technologies de virtualisation mises en place dans le SI : exécution de plusieurs systèmes d’exploitation serveur sur un même matériel.

Figure 6. Technologie de virtualisation de serveur.

Il faut cependant garder à l’esprit qu’il existe cinq environnements différents (production, UAT release, UAT maintenance, DIT release, DIT maintenance) et que cela demandera donc du temps pour les configurer impactant alors le niveau de la charge de travail.

(33)

Étude de solutions

La solution télémarketing étant un outil lié à la relation client, il doit rester dans le périmètre de compétences présentes dans l’équipe CRM pour pouvoir être maintenue sans besoin de ressources supplémentaires ou de qualifications particulières qui nécessiteraient le recours à un nouveau prestataire.

Les compétences techniques présentes dans l’équipe sont les suivantes : Java/J2EE, Db2, Salesforce.com.

Du point de vue métier, l’équipe Core Business a pu effectuer une démonstration de l’application GrapeCity, une application de télémarketing installée sous forme de complément à l’application CRM Salesforce.com en place. Conquise, elle a fortement poussé cette solution lors de la définition des besoins dans la RFC, il m’a donc fallu la considérer parmi les solutions proposées.

Figure 8. Copie d’écran de la solution GrapeCity pour Salesforce.com.

De plus, les utilisateurs du système de télémarketing ont déjà été identifiés par l’équipe Core Business. La liste des utilisateurs révèlent qu’ils sont également tous utilisateurs du CRM et qu’il y aura une forte corrélation entre l’application CRM et le système télémarketing (partage de données communes, passage d’une application à une autre). Il en ressort une moyenne de vingt utilisateurs par Business Unit. Ceci est une bonne opportunité de conserver ce principe de complément au CRM Salesforce.com.

Cela aura eu comme impact immédiat une modification de mon approche car, au lieu de m’orienter sur un système à part entière, j’ai décidé de prendre en compte les modules qui

(34)

Étude de solutions

pourraient venir compléter l’application CRM (comme le fait le module télémarketing de Salesforce).

De la sorte, je pourrais proposer une mise en œuvre particulièrement rapide de la solution, s’appuyant sur des briques existantes, nécessitant aucun coût d’infrastructure car elle n’a pas besoin d’évoluer, permettant l’exploitation des données du CRM en réduisant à zéro les coûts d’interfaces du système avec le SI Euler Hermes.

De plus, les utilisateurs du système de télémarketing étant déjà utilisateur de Salesforce.com, aucun coût de licence Salesforce.com supplémentaire n’est requis.

Enfin, j’ai dû considérer un élément inconnu comme hypothèse, cette dernière a été présentée au Core Business qui a pu la valider : le nombre de Business Unit concernée par le nouveau système est de deux, une BU américaine (USA) et une BU allemande. La solution devra donc être traduite en anglais et allemand.

3.3. Identification des candidats

3.3.1. Exploration du SI Euler Hermes

J’ai choisis de conduire mon étude en suivant la bonne pratique d’architecture : « Re-use before Buy before Build ». Ce principe vise à privilégier la réutilisation d’une solution existante au sein du système d’information Euler Hermes, qui serait moins coûteuse qu’une solution à acquérir ou à développer et plus rapide à mettre en œuvre. J’ai alors contacté la cellule Architecture d’Entreprise pour récolter des informations à ce sujet.

La DSI d’Euler Hermes est une DSI groupe, les choix de solutions doivent être validés par l’équipe d’architecture du SI (Group IT Transveral Architecture) composée actuellement de 6 personnes (Enterprise Architect).

Malheureusement, ni au niveau du système d’information groupe, ni au niveau des systèmes d’information des Business Unit, il n’existe de telle solution. De plus, les règles de gouvernance n’autorisent pas, pour le moment, à consulter la DSI groupe d’Allianz, maison mère d’Euler Hermes, pour ce genre de requête.

(35)

Étude de solutions

3.3.2. Le module télémarketing de Salesforce.com

Suivant la bonne pratique, j’explore à présent les solutions vendeurs (clés en main) pour les fonctions attendues.

Une première solution intéressante est proposée par l’éditeur Salesforce.com, déjà éditeur de la solution CRM Copernicus en place dans le SI. Cet éditeur propose d’activer des modules pour compléter l’application SaaS Sales Cloud (CRM en place) et ainsi supporter un processus de télémarketing.

Figure 9. Copie d’écran de la solution télémarketing de Salesforce.com

Les avantages sont immédiats : réutilisation de la plate-forme Force.com (modèle de données existant, gestion des utilisateurs déjà existante), utilisation des données existantes (compte, contact…).

Je relève en inconvénient qu’une partie des fonctionnalités importantes n’existe pas en natif et ne peut être complétée par des développements spécifiques (paramétrage des valeurs par défaut tel que le temps de verrouillage d’un prospect, création d’équipe, ajout de compte en tant que prospect, assignation personnelle des prospects).

(36)

Étude de solutions

3.3.3. L’application GrapeCity

Ainsi, j’ai exploré l’AppExchange (place de marché des applications pour Salesforce.com) et trouvé que l’application GrapeCity était un bon candidat possible.

L’application GrapeCity pour Salesforce permet l’administration de l’application télémarketing : gestion des utilisateurs et des équipes, paramétrage des valeurs par défaut. Elle permet également la gestion des campagnes (création, démarrage, arrêt, pause), la recherche de contact ou compte en vue de les assigner à des équipes ou utilisateurs.

Point de vue de l’agent, elle permet de visualiser la liste des prospects à contacter, elle propose une interface utilisateur pour passer un appel et enregistrer des informations lorsque l’appel abouti.

Figure 10. Copie d’écran de la solution GrapeCity lors du passage d’un appel.

Les avantages de cette application sont une large couverture fonctionnelle, une utilisation de la plate-forme et des données CRM.

Les inconvénients de cette application sont qu'il n’y pas de solution intégrée à l’application pour planifier un rendez-vous, l’application est livrée sous forme de package « boîte noire » et n’est malheureusement plus maintenue par l’éditeur. Ceci signifie que les anomalies rencontrées ne seront jamais corrigées et qu’il sera impossible pour l’équipe de développement de faire évoluer le code source car ce dernier n’est pas accessible.

(37)

Étude de solutions

3.3.4. Les développements spécifiques

Pour conclure mon étude, je décide d’évaluer la mise en œuvre de l’application télémarketing via des développements spécifiques.

La solution imaginée repose sur la plate-forme CRM Salesforce.com, comme pour les deux choix précédents. Ce choix nous permet de bénéficier de l’architecture technique existante et toutes les facilités qu’elle propose, de plus cela permet de rationaliser des ressources de développements Salesforce.com déjà présentes sur le projet de TMA du CRM, qui aujourd’hui ne sont pas à une charge de 100%.

De cette manière, je suis capable de proposer une solution avec une couverture fonctionnelle complète et évolutive, ce que ne propose ni le module Salesforce.com, ni l’application GrapeCity.

Les avantages :

 Une couverture fonctionnelle complète ;  Une solution évolutive ;

 Plate-forme Salesforce.com permettant une mise en œuvre rapide. Les inconvénients :

 Coûts plus élevés ;

 Délais plus long qu’une solution sur étagère.

3.4. Synthèse de couverture fonctionnelle

Suite à cette étude, j’ai mis à jour la matrice de couverture fonctionnelle pour chaque solution étudiée :

Tableau III. Liste des fonctionnalités par solution. Fonctionnalités télémarketing Module

Salesforce.com

GrapeCity Dév. spécifique

Configuration du système

(38)

Étude de solutions

2. Créer une équipe - o f()

3. Paramétrer les valeurs par défaut - o f()

Paramétrage d’une campagne

5. Créer une campagne o o f()

6. Ajouter des prospects o o f()

7. Assigner les prospects - o f()

8. Marquer un compte en tant que prospect

- - f()

Déroulement d’une campagne

9. Visualiser les prospects à appeler o o f()

10. Enregistrer un appel o o f() 11. Convertir un prospect en opportunité o o f() 12. Planifier un rendez-vous o f() f() Légende :

 Un point « o » indique une couverture fonctionnelle complète ;

 Une fonction « f() » indique une couverture fonctionnelle qui doit être mise en œuvre par des développements spécifiques ;

 Un tiret « - » indique une absence de couverture avec une impossibilité de la réaliser en développement spécifique.

3.5. Estimations

Les coûts et les délais sont deux des critères les plus importants dans la prise de décision de l’équipe métier, à ces fins, j’ai mis en place une matrice qui synthétise le travail d’estimation

(39)

Étude de solutions

Préalablement aux chiffrages des solutions possibles, j’ai mis en œuvre une matrice d'estimation qui, pour chaque tâche à réaliser sur la plate-forme, permet de connaître son coût d’implémentation unitaire (charge évaluée en heure). Ce choix est délibéré car, travaillant sur une solution cloud de type PaaS, certaines capacités technologiques permettent d’accélérer considérablement le temps d’implémentation et il faut une granularité adaptée.

Par exemple, la création d’un nouvel objet du modèle de données requiert une heure de travail, la création d’une règle de contrôle requiert trente minutes, etc.

Un extrait de ce fichier de chiffrage est présenté ci-dessous :

Figure 11. Extrait du fichier d’estimations.

Les trois premières colonnes permettent d’organiser les estimations par besoin (numéro, description, composants ou actions). Les colonnes suivantes listent les différentes actions possibles sur d’une part les activités d’administration et de paramétrage (allant de 15 minutes à 1 jour de travail), et d’autre part les activités de développement (de 1 à 4 jours de travail).

(40)

Étude de solutions

Parmi les dernières colonnes on trouve en synthèse pour une fonctionnalité une colonne de chiffrage pour le développement/paramétrage et tests unitaires brut, le même chiffrage mais avec une part de risque de 20% supplémentaire, la charge de spécifications fonctionnelles et la charge de tests.

La part des développements et tests unitaires avec risque représente 40% du temps total d’implémentation, le travail de spécification représente 30% et le travail de test représente également 30%.

L’avantage d’un tel fichier est multiple :  Être précis dans les estimations;  Justifier le chiffrage;

 Identifier quels cas d’utilisations sont consommateurs de forte charge afin de les alléger ou en vue d’arbitrer;

 Être réutilisable lors des prochaines demandes.

3.5.1. Estimation du module télémarketing de Salesforce.com

Le module télémarketing de Salesforce.com n’est pas personnalisable et ne peut pas être complété par des développements spécifiques (impossible de modifier les écrans, les routages entre les actions, etc.), il n’y a donc pas de charge de travail liée à l’adaptation du composant sur la plate-forme.

En revanche, son intégration requiert une charge de paramétrage afin que les utilisateurs puissent y accéder.

Il s’agit, entre autre, de :

 Installer l’application sur la plate-forme;

 Paramétrer de nouveaux profils sur la plate-forme afin d’autoriser l’accès à l’application (2 nouveaux profils identifiés en phase d’expression de besoins);

 Autoriser ces profils à accéder aux objets utilisés par le module (Contact, Lead, Campaign…);

(41)

Étude de solutions

 Revoir la hiérarchie des rôles afin de modifier la visibilité des données pour les utilisateurs de l’application (1 nouveau rôle identifié en phase d’expression de besoin).

Sur la plate-forme Force.com (SF1 platform), la visibilité des données est réduite à celui qui les a créées ainsi qu’à tous ses supérieurs hiérarchique. Ceci est défini par la hiérarchie des rôles, il s’agit d’une hiérarchie verticale.

Les utilisateurs de type télémarketing ont besoins de travailler sur toutes les données créées par les agents commerciaux, ils doivent donc bénéficier d’une large visibilité.

Concernant l’affectation des utilisateurs à ces profils, j’ai retenu comme hypothèse qu’il y aurait 20 utilisateurs par BU avec un nombre de BU fixé à 2 pour la phase pilote.

Étant donné que le module télémarketing de Salesforce.com est gratuitement activé sur demande, il n'inclut pas de coût de licences supplémentaires par rapport à la plate-forme et au module Sales Cloud déjà en place.

La charge de travail est ainsi évaluée :

Tableau IV. Charge d’intégration du module télémarketing de Salesforce.com.

Travaux Charge, en jours / homme

Spécifications 7

Implémentation : 10

Installation 2,5

Paramétrage des profils 2,5

Paramétrage des rôles 1

Affectation des utilisateurs 4

Tests 7

(42)

Étude de solutions

3.5.2. Estimation de l’application GrapeCity

L’application GrapeCity consiste en un ensemble de fonctionnalités implémentées en boîte noire et mises à dispositions de « l’acheteur » sous forme de package à installer sur la plate-forme.

Comme pour le module télémarketing de Salesforce.com, son intégration requiert une charge de paramétrage afin que les utilisateurs puissent y accéder (installation, paramétrage des profils, affectation des utilisateurs, hiérarchie des rôles).

De plus, la fonctionnalité de prise de rendez-vous doit être implémentée par des développements spécifiques afin de faire le lien entre GrapeCity et la fonctionnalité de rendez-vous globale de Salesforce.com.

Enfin, l’application GrapeCity est distribuée gratuitement par l’éditeur GGS (GrapeCity Global Services), en revanche elle n’est pas maintenable car les fichiers sources ne sont pas accessibles.

La charge évaluée est la suivante :

Tableau V. Charge d’intégration de l’application GrapeCity.

Spécifications 8,5

Implémentation : 14

Installation 2,5

Paramétrage des profils 2,5

Paramétrage des rôles 1

Affectation des utilisateurs 4 Implémentation « Planifier un RDV » 4

Tests 8,5

(43)

Étude de solutions

3.5.3. Estimation des développements spécifiques

La mise en œuvre de développements spécifiques pour couvrir le besoin permet d’établir une couverture fonctionnelle complète, cependant de par la nature de la solution cela requiert plus de temps de mise en œuvre qu’une solution prête à être installée.

Pour cette estimation, on distingue trois phases (que l’on retrouve également pour les deux solutions précédentes) : spécifications (générales et détaillées), implémentation (développements, tests unitaires, tests d’intégration) et tests (validation interne avant recette utilisateur).

La phase d’implémentation couvre différents sujets : l’implémentation des fonctionnalités (découpées en cas d’utilisations), le paramétrage des profils utilisateurs, la définition de la hiérarchie de rôles, l’affectation des profils et rôles aux utilisateurs.

J’ai ensuite décomposé chaque cas d’utilisation en :  Nombre d’écrans probables ;

 Nombre d’actions probables ;  Nombre de règles probables.

Chaque écran, action ou règle est identifié par un numéro et est rattaché à un cas d’utilisation. Chaque cas d’utilisation est identifié par un numéro.

Par exemple, le premier cas d’utilisation est identifié par UC-001, le premier écran de ce cas est identifié par SC-001.

Ce découpage m’a permis de réaliser une estimation fine de chaque élément à mettre en œuvre pour couvrir chaque cas et ainsi arriver à l’ensemble des fonctionnalités qui constituent la solution.

Ainsi, la charge évaluée est la suivante :

Tableau VI. Charge d’implémentation en développements spécifiques.

Spécifications 32

(44)

Étude de solutions

Configuration (profils, rôles, utilisateurs…) 9

Cas d’utilisation numéro 1 0,5

Cas d’utilisation numéro 2 1

Tests 32

La charge de travail est de 117 jours / homme.

3.6. Synthèse des estimations

La matrice suivante synthétise les charges et les coûts pour chacune des solutions envisagées.

Tableau VII. Synthèse des estimations.

Charge de travail Coût de licence Coût d’intégration

Module Salesforce.com 24 0 ~13,7k€ GrapeCity 31 0 ~17,7k€ Développements spécifiques 117 0 ~66,7k€ Légende :

 La charge de travail est évaluée en jour / homme, soit un jour de travail pour une personne ;

 Les coûts de licence sont évalués en euros ;

(45)

Étude de solutions

3.7. Prise de décision

Après avoir terminé les estimations des différentes solutions, j’ai établi une synthèse globale des choix possibles qui s’offre à l’équipe Core Business afin de faciliter sa prise de décision en s’appuyant sur les informations clés à retenir.

J’ai choisi d’utiliser une matrice SWOT (Strengths, Weaknesses, Opportunities, Threats -Force, Faiblesses, Opportunités, Menaces) pour chaque solutions.

Cette matrice me semble idéale dans mon cas car elle permet d’identifier rapidement les points les plus importants, sans plonger dans des détails techniques qui ne concernent pas l’équipe métier (on présente les solutions dans un « langage » connu de l’interlocuteur, abordant les aspects coûts, délais, fonctionnalités et pérennité).

Ma préconisation pour la mise en œuvre d’une solution en réponse aux besoins métier est la suivante :

1. Module télémarketing de Salesforce.com.

Cette solution est proposée par l’éditeur Salesforce.com, ce qui est un gage de qualité à la vue de l’application Sales Cloud déjà en place. Ce module ne requiert pas de coût de licence supplémentaire, il s’intègre parfaitement à la plate-forme, l’apparence de l’application est identique à l’application Sales, les utilisateurs ne seront pas perdus. Son installation est relativement aisée et se fait par paramétrage, de plus, on profite du support Salesforce.com au même titre que pour l’application Sales.

Enfin, c’est la solution la plus rapide et la moins chère à mettre en œuvre, on profite ainsi d’un TTM (Time To Market) très court et, selon les prévisions de l’équipe métier, ils peuvent espérer un ROI (Return On Invest) assez rapide.

Tableau VIII. Analyse SWOT du module télémarketing de Salesforce.com.

Forces Faiblesses

 Editeur Salesforce.com ;  Intégration parfaite ;

(46)

Étude de solutions

 Coût : 13,7 k€ (ROI plus accessible) ;

 Charge : 24 jrs (TTM très rapide).

Opportunités Menaces

 Adopt before Adapt, challenger les équipes pour rester au maximum sur le standard et profiter ainsi des évolutions de la plate-forme sans actions de l’IT.

 Impossible de compléter la couverture fonctionnelle avec des développements spécifiques.

2. Les développements spécifiques.

A défaut de partir sur la solution Salesforce.com, la solution « développements spécifiques » se positionne en choix acceptable : les utilisateurs profiterons d’une application répondant parfaitement à leurs besoins et capable d’évoluer précisément par rapport à leurs demandes.

Tableau IX. Analyse SWOT des développements spécifiques.

Forces Faiblesses

 Couverture fonctionnelle à 100% ;  Dans un premier temps, possibilité de se

concentrer sur les UC à fortes valeurs pour accélérer le ROI et le TTM.

 Coût : 66,7 k€ ;  Charge : 117 jrs.

 Evolutivité ;  Maintenabilité.

 Les ressources spécialisées sur Salesforce.com sont difficiles à trouver.

3. L’application GrapeCity.

Ce choix me semble définitivement comme celui à abandonner, principalement en raison de son mode de commercialisation (package en boîte noire avec code source non accessible et non évolutif) incompatible avec l’abandon de sa maintenance par l’éditeur : on serait alors

(47)

Étude de solutions

Tableau X. Analyse SWOT de la solution GrapeCity.

Forces Faiblesses

 Large couverture fonctionnelle ;  Coût : 17,7 k€ ;

 Charge : 24 jrs.

 Tributaire des choix de l’éditeur.

 Challenger le métier pour adopter l’application.

 Fichiers sources non maintenable ;  Fichiers sources non évolutifs ;  Produit abandonné par l’éditeur.

Chez Euler Hermes, le processus de prise de décision est défini ainsi :  Présentation des solutions à l’équipe métier;

 Période de réflexion, échanges par email ou ateliers de questions / réponses au besoin;

 Formalisation du choix.

Suite à la formalisation du choix, la RFC est planifiée dans la prochaine version majeure du SI Euler Hermes. Elle est ensuite découpée en lots, en fonction de la charge de travail à accomplir corrélée à la disponibilité de l’équipe sur les mois à venir.

Le 22 mai 2013, l’équipe métier choisit la solution « Développements spécifiques », favorisée pour sa flexibilité au regard des besoins futurs qui dépendront de la réussite de la mise en œuvre du nouveau processus.

(48)

Implémentation de la solution

4. Implémentation de la solution

4.1. Mise en place de l’organisation

Avant de démarrer un cycle en V pour la fabrication à proprement parler du système de télémarketing, il a fallu réaliser quelques travaux nécessaires à l’organisation du projet en vue de le mener à bien.

4.1.1. Planification

Le système devant être livré pour la version majeure 13.3.0, le premier travail a consisté à s’informer du planning mise en place (tel que défini à la rubrique 1.2.5 « Cycle de vie des versions ») pour en extraire les différentes parties et les différentes périodes de réalisation allouées à chaque phase de ces parties.

La version 13.3.0 est divisée en 4 Package :  Package 1 (P1) :

o Du 22/07 au 16/08 : tests de recette.  Package 2 (P2) :