Upload
dinhdien
View
236
Download
0
Embed Size (px)
Citation preview
Rapport de stage
Développement et déploiement d’une GRC
Cyril DEFAUT Maître de stage : Rodolphe ALBEROLA -‐ Tuteur de stage : Isabelle JACQUES
Stage au sein d’Avenir Bureautique (Besançon)
du 5 Mars au 8 Juin 2012
LICENCE PROFESSIONNELLE Systèmes Informatiques et Logiciels spécialité Conception et Développement Orientés Objet d'Applications Multi-‐tiers Année universitaire 2011-‐2012
Rapport de stage
Programmation d'un logiciel chargé de piloterun banc d'encodage de cartes magnétiques
et de gérer les mappings de cartes
Romain DÉOUX
Maître de stage : Christian PERROTTutrice enseignante : Isabelle JACQUES
Licence professionnelle C.D.O.A.M.Conception et Développement Orientés Objets d’Applications Multi-tiers
Université de Franche-Comté – L.I.F.C.
Année universitaire 2009 / 2010
1/46
Développement et déploiement d’une GRC
-‐ 1 -‐
Sommaire
Sommaire 1
Remerciements 3
Introduction 4
1-‐Avenir Bureautique 5 1.1-‐Présentation de l’entreprise 5 1.2-‐Historique 5 1.3-‐Quelques chiffres 6 1.4-‐Sigec 6 1.5-‐Environnement de travail 7
2-‐Sage CRM Vente Partner 8 2.1-‐GRC : définition 8 2.2-‐Vente Partner : son histoire 8 2.3-‐Son arrivée chez Avenir Bureautique 9
3-‐L’existant 11 3.1-‐Définitions 11
3.1.1-‐Vue 11 3.1.2-‐Famille 11 3.1.3-‐Fiche 11
3.2-‐Base de données 12 3.3-‐Diagramme de classes 13
4-‐Le développement 15 4.1-‐Cahier des charges 15 4.2-‐Premiers jours de stage 15 4.3-‐Consolidations 16 4.4-‐Groupes d’accès et utilisateurs 17 4.5-‐Vues 18
4.5.1-‐Objet saisie 19 4.5.2-‐Bouton action 20 4.5.3-‐Objet externe 20
4.6-‐Agenda 20 4.7-‐Traitements 22
4.7.1-‐Listes de travail 23 4.7.2-‐Editions 24 4.7.3-‐Dossiers 25 4.7.4-‐Exports 26 4.7.5-‐Graphiques 26
Développement et déploiement d’une GRC
-‐ 2 -‐
4.7.6-‐Etiquettes 27 4.8-‐Relooking 28 4.9-‐Tâches annexes 28
Conclusion 29
Glossaire 30
Webographie 31
Annexes 32 Annexe A : L’ancienne mouture de la GRC 32 Annexe B : Le cahier des charges 39 Annexe C : La nouvelle mouture de la GRC 44 Annexe D : Exemple d’éditions 50
Résumé 53
Abstract 53
Développement et déploiement d’une GRC
-‐ 3 -‐
Remerciements
Je souhaite tout d’abord exprimer ma reconnaissance envers Mr Rodolphe ALBEROLA pour m’avoir accueilli au sein d’Avenir Bureautique, pour m’avoir fait confiance durant le déroulement du stage et pour avoir toujours su répondre à mes diverses questions.
Mes remerciements vont aussi à : -‐ Mr Frédéric CHARANSOL, directeur commercial de Sigec et administrateur
d’Avenir Bureautique et de Sigec, pour sa participation à l’étude de la GRC et pour avoir servi de lien entre les 2 sociétés ;
-‐ Mr Yannick DEROUBAIX, technicien de Sigec, pour le partage de son expérience sur Vente Partner et son aide pour le déploiement ;
-‐ Mr Bertrand ELINEAU, technicien de Technomade, pour son aide précieuse lors des problèmes survenus durant le développement de la GRC ;
-‐ aux équipes commerciales qui ont toujours été là pour satisfaire à mes différentes demandes, soumettre leurs doléances et remonter les problèmes rencontrés sur la GRC modifiée.
Je tiens aussi à remercier l’ensemble des salariés de l’entreprise pour leur amabilité
et l’accueil agréable qu’ils m’ont réservé et qui m’ont permis de m’adapter rapidement à ce nouveau cadre de travail.
Enfin, j’exprime ma gratitude envers Mr Jacques THIBAULT, directeur général
d’Avenir Bureautique et de Sigec, pour m’avoir offert l’opportunité d’intégrer à l’issue du stage la société Axess Vision.
Développement et déploiement d’une GRC
-‐ 4 -‐
Introduction Dans le cadre d’un départ de l’Armée de l’Air, après y avoir passé 16 années en tant
qu’informaticien, et afin de me préparer à un retour à la vie civile, j’ai décidé d’effectuer une reconversion en reprenant mes études. Mon choix s’est porté sur la licence professionnelle « Systèmes Informatiques et Logiciels spécialité Conception et Développement Orientés Objet d'Applications Multi-‐tiers »
Ce cursus, dispensé à l’Université de Franche-‐Comté de Besançon durant une année
universitaire, est validé par l’intermédiaire d’un stage en entreprise d’une durée de 14 semaines.
Ce stage a été réalisé au sein d’Avenir Bureautique à Besançon. Cette entreprise,
spécialisée dans les systèmes de reproduction et de communication, m’a accueilli dans le cadre d’un projet de développement d’une nouvelle GRC en remplacement d’une ancienne devenue obsolète et inadéquate. A l’heure où la concurrence est rude pour obtenir des contrats, les commerciaux se devaient d’avoir un outil performant afin de suivre au plus près les engagements pris auprès de leurs clients et de répondre rapidement et précisément à leurs besoins.
Ce rapport expose le déroulement de mon stage. Tout d’abord, je présente
l’entreprise et la GRC existante qui sert de base à la nouvelle version. Ensuite, je décris le cahier des charges et je détaille les différentes étapes du développement accompli ainsi que les problèmes rencontrés. Enfin, j’effectue un bilan, tant sur le plan des connaissances utilisées que sur celles qui m’ont été apportées par l’entreprise.
Développement et déploiement d’une GRC
-‐ 5 -‐
1-‐Avenir Bureautique
1.1-‐Présentation de l’entreprise Avenir Bureautique est spécialisé dans la diffusion et la maintenance de matériels
bureautiques et solutions réseaux. Une large gamme de fax, imprimantes, multifonctions et photocopieurs est proposée
en achat ou en location. 2 marques sont proposées : -‐ Konica Minolta (Avenir Bureautique est un distributeur national agréé) pour des
imprimantes et multifonctions ; -‐ Oki pour des imprimantes. Les appareils en fin ou en cours de location (provenant de chez Avenir Bureautique
ou d’un de ses concurrents) sont repris régulièrement afin de permettre aux clients (ou futurs clients) d’évoluer selon leurs nécessités sur des équipements plus récents, plus performants et donc plus appropriés. La formation du personnel sur les nouvelles machines est effectuée par les commerciaux tandis que les techniciens s’occupent de l’installation et de la connexion des matériels sur le site de déploiement des entreprises bénéficiaires. En outre, la gestion des consommables est intégrée à tout contrat de maintenance : les sociétés clientes doivent seulement faire part de leurs besoins auprès de la centrale d’accueil d’Avenir Bureautique et un technicien se déplacera rapidement pour délivrer la commande.
1.2-‐Historique
1979 : création d’Avenir Bureautique à Granvelle (70) par Mr Raymond CLADE 1981 : implantation de la société à Besançon (25)
Fig. 1 : Siège social à Besançon
Développement et déploiement d’une GRC
-‐ 6 -‐
1995 : l’entreprise est rachetée par Mrs Jacques THIBAULT, Frédéric CHARANSOL et Rodolphe ALBEROLA 1996 : création d’une agence à Montbéliard (25) 1997 : création d’une agence à Dijon (21)
Les différentes agences couvrent toute la Franche-‐Comté ainsi que la Côte d’Or.
Fig. 2 : Emplacement des agences
1.3-‐Quelques chiffres Le personnel de la société (agences comprises) est constitué de 35 collaborateurs : -‐ 12 commerciaux (3+ 1 chef de vente par site) ayant chacun son propre secteur ; -‐ 17 personnes affectées au service de maintenance et réparties géographiquement
sur l’ensemble des sites. 6000 interventions techniques sont effectuées par an pour un parc de 2700
machines sous contrat d’entretien localisées en Franche-‐Comté et en Côte d’Or. 500 autres machines sont placées par an dans le même périmètre. Le chiffre d’affaire d’Avenir Bureautique, toujours en constante progression, a été de
4,5 millions d’euros en 2009 puis de 5,5 millions d’euros en 2010 pour finalement tourner autour des 6 millions d’euros pour l’année 2011.
1.4-‐Sigec Puisque j’ai introduit Avenir Bureautique, je me dois aussi de présenter brièvement
la société Sigec. Pourquoi cette démarche ? La GRC développée au sein d’Avenir Bureautique est autant utile pour cette dernière
que pour Sigec dans la mesure où ces 2 entités font partie du même groupe et emploient l’ancienne version pour les mêmes raisons commerciales.
Développement et déploiement d’une GRC
-‐ 7 -‐
Sigec est la contraction de Service Informatique de GEstion et Conseil. Cette
entreprise est implantée sur Besançon depuis plusieurs décennies. A l’instar d’Avenir Bureautique, elle offre des solutions d’impressions par le biais de
plusieurs marques : -‐ Ricoh pour les multifonctions et photocopieurs ; -‐ Riso pour les dupli copieurs ; -‐ Oki pour les imprimantes.
[NOTA : un dupli copieur est un copieur employé pour des besoins d’impression de documents en grand nombre comme des tracts par exemple]
Toutefois, ce n’est pas là son seul domaine de vente. Elle propose également ses compétences en :
-‐ matériels informatiques et logiciels de gestion ; -‐ biométrie (reconnaissance et identification de personnes, contrôle et gestion des
accès, gestion du temps de travail et des horaires, etc.) ; -‐ mobilier de bureau.
En plus de l’agence (et siège social) de Besançon, Sigec possède plusieurs
succursales : -‐ à Audincourt (25) ; -‐ à Sennecey-‐les-‐Dijon (21) ; -‐ à Chaumont (52) ; -‐ et récemment à Puget-‐sur-‐Argens (83). Les différentes agences couvrent toute la Franche-‐Comté ainsi que la Côte d’Or et la
Haute-‐Marne.
1.5-‐Environnement de travail Avenir Bureautique ne possédant pas de service informatique, je dépendais
directement du directeur commercial et responsable du stage, Mr Rodolphe ALBEROLA. Ensemble, nous avons échangé des avis et visualisé les étapes de l’évolution de la GRC lors de réunions quasi quotidiennes.
J’ai eu aussi l’opportunité d’aller plusieurs fois sur les sites de Dijon et de Montbéliard afin d’en connaître le personnel et de pouvoir aussi partager des idées sur le futur logiciel.
J’étais installé dans le bureau des commerciaux ce qui me permettait d’avoir des avis et des retours d’informations sur les différentes phases de développement et de déploiement.
Développement et déploiement d’une GRC
-‐ 8 -‐
2-‐Sage CRM Vente Partner
2.1-‐GRC : définition GRC signifie Gestion de la Relation Clients (elle est connue aussi sous le nom de CRM
pour Customer Relationship Management). [NOTA : pendant la durée du stage, moi-‐même et mes interlocuteurs avons toujours
employé le terme CRM et non pas GRC] La GRC est une application informatique de type progiciel permettant de renseigner,
traiter et analyser des informations relatives aux clients et aux prospects dans le but de renforcer la communication entre eux et l’entreprise détentrice de la GRC et d’aider à les fidéliser en leur offrant les meilleurs services possibles.
Ces objectifs sont réalisés en automatisant les différentes composantes de la relation client telles que :
-‐ l’avant-‐vente (en analysant et en anticipant les besoins futurs des clients et de démarcher les prospects) ;
-‐ la vente (en apportant aux commerciaux des outils afin de les assister dans leurs démarches de prospection comme la gestion des contacts, des rendez-‐vous ou des relances) ;
-‐ la gestion du service clientèle (en faisant apparaître l’historique d’un client à chaque prise de contact de celui-‐ci avec l’entreprise propriétaire de la GRC) ;
-‐ l’après-‐vente (en fournissant une assistance au client via un centre d’appel ou des techniciens grâce au partage des données le concernant).
En conclusion, un projet de GRC consiste à permettre à chaque intervenant de
différents secteurs d’une entreprise d’accéder à un système d’informations pour être en mesure d’améliorer la connaissance du client et de lui fournir des produits ou services répondant au mieux à ses attentes.
2.2-‐Vente Partner : son histoire Vente Partner est un logiciel conçu afin d’intégrer en standard l’ensemble des
fonctions requises par la GRC. Il a été créé au début des années 1990 par KDP Informatique, un éditeur français de
solutions de GRC.
Développement et déploiement d’une GRC
-‐ 9 -‐
[NOTA : pendant la durée du stage, pratiquement tous mes interlocuteurs
nommaient le logiciel KDP plutôt que Vente Partner] Celui-‐ci a été très bien accueilli par les sociétés ou groupes nationaux et étrangers
installés en France. Ainsi, KDP Informatique a eu des clients prestigieux tels que : -‐ Alstom ; -‐ Colas ; -‐ Facom ; -‐ Groupe Aoste ; -‐ La Redoute ; -‐ Outils Wolf ; -‐ Parc du Futuroscope ; -‐ Smoby ; -‐ Stoeffler ; -‐ TPS ; -‐ Tetra Pak Service ; -‐ Total France. En septembre 2007, cet éditeur est racheté puis absorbé par Sage Group, une
entreprise britannique éditrice de logiciels et spécialisée aussi dans les logiciels de GRC, dans le cadre d’une politique forte d’acquisition en France.
Après cette prise de contrôle, Vente Partner est rebaptisé Sage CRM Vente Partner.
Le logiciel continue son évolution au fil du temps par le biais de différentes versions grâce à l’expérience et à l’innovation de Sage Group, actuellement troisième fournisseur mondial de progiciels de gestion intégrés.
La version 12.0, dernière et ultime version, est sortie début 2012.
2.3-‐Son arrivée chez Avenir Bureautique Avenir Bureautique et Sigec décidèrent d’acheter ensemble une solution GRC pour
leurs activités commerciales communes de revendeur de solutions d’impressions. Leur choix se porta sur Vente Partner car, outre ses fonctions de gestion, il est possible d’en modifier facilement l’environnement afin de réaliser une application sur mesure.
Le développement a été effectué par Mr Jean NORBET, technicien de KDP
Informatique, selon un cahier des charges fourni par les 2 entreprises. En 1998, le logiciel est déployé au sein de ces 2 entreprises : il est basé sur la version
4.0.Il s’agit d’une version client/serveur développée en langage orienté objet C++, associé à un SGBD relationnel ; les accès et récupération des données se font par des requêtes soit de type QBE soit de type SQL.
Développement et déploiement d’une GRC
-‐ 10 -‐
Puis, en 2002, la version 5.0 est installée pour accompagner le passage à la monnaie
unique. Aucun changement de version ou rectification du contenu n’a été exécuté depuis sur
Vente Partner. En 2011, cet outil étant devenu vieillissant et inadéquat pour les besoins des 2
sociétés, il fut décidé de passer à la version la plus récente du logiciel et d’améliorer son interface. KDP Informatique n’existant plus, c’est Technomade, entreprise bordelaise revendeuse agréée Sage, qui installa la version 12.0 à la mi-‐février 2012 chez Avenir Bureautique et Sigec.
Concernant la partie développement, le travail fut fourni à un programmeur : c’est là
que j’interviens et que commence mon stage.
Développement et déploiement d’une GRC
-‐ 11 -‐
3-‐L’existant Le but de mon stage n’étant pas de concevoir une nouvelle application mais
d’améliorer l’interface d’une GRC en repartant de ce qui existait déjà, il est nécessaire d’expliquer dans un premier temps le mode de fonctionnement de la base de données et d’en détailler le contenu.
3.1-‐Définitions La base de données associée à Vente Partner fonctionne via 3 éléments nécessaires :
la vue, la famille et la fiche.
3.1.1-‐Vue Une vue équivaut à une fenêtre de saisie. Elle regroupe un certain nombre
d’informations comme des zones de saisie, des boutons radio ou des cases à cocher. Chaque vue est référencée par un nom unique. Sa taille est variable mais elle ne peut
pas dépasser la résolution d’un écran. Ainsi, pour une meilleure visualisation, plusieurs vues peuvent être ajustées côte à côte.
3.1.2-‐Famille Une famille correspond à une table. Elle est le plus souvent constituée d’une seule
vue mais il est possible d’y associer un nombre illimité. Il existe 2 cas particuliers de famille : -‐ famille ancêtre : c’est une famille située à un niveau supérieur par rapport à une
autre famille ; -‐ famille principale : c’est une famille de premier niveau donc n’ayant pas d’ancêtre ;
elle comporte en général des informations uniques.
3.1.3-‐Fiche Une fiche équivaut à une ligne d’une table. L’affichage de la fiche (ou d’une partie de
celle-‐ci) se fait au travers d’une vue. Chaque fiche a une clé unique, une clé primaire, appelé « sys-‐id » : elle est créée par
Vente Partner.
Développement et déploiement d’une GRC
-‐ 12 -‐
3.2-‐Base de données La base de données de la version à modifier de la GRC a la même architecture chez
Avenir Bureautique et Sigec. Chaque famille est liée à une seule vue, à l’exception des familles « Menu » (8 vues)
et « Société » (5 vues). La famille « Menu » est un ensemble de vues permettant soit d’aller vers une ou
plusieurs autres vues soit de lancer des traitements comme des éditions ou des exports de données : il ne s’agit donc pas stricto sensu d’une vraie table.
En revanche, dans la mesure où la famille « Société » est une table englobant de nombreux champs d’information, il ne faut pas tous les disposer dans une seule vue au risque de la rendre illisible. Ainsi, cette famille a été scindée en plusieurs vues dont les plus importantes sont :
-‐ vue « Identification » contenant les renseignements les plus significatifs d’une entreprise comme sa raison sociale, son adresse et son numéro de téléphone ;
-‐ vue « Autres informations Société » intégrant des éléments administratifs d’une société comme le numéro SIRET, le code NAF, la forme juridique ou le chiffre d’affaire.
L’arborescence ci-‐dessous (Figure 3) montre l’architecture des familles sur 3
niveaux mais il peut y en avoir plus. Celle-‐ci respecte un protocole « père/fils/petit-‐fils ». Dans la base de données actuelle, la table « Société » est le père, la table « Parc » est à la fois fils et père, et la table « Relance » est à la fois fils et petit-‐fils.
Quelle est la justification d’une telle organisation ? En fait, être à l’intérieur d’une vue ou d’un traitement donne l’autorisation d’aller
récupérer des champs dans une autre vue sans passer par d’autres fonctionnalités. Toutefois, ce système a des limites. En effet, un fils peut « voir » un père mais pas l’inverse. Ainsi, la vue « Relance » peut accéder aux champs des vues « Parc » et « Identification » tandis que « Parc » ne peut accéder qu’à ceux de « Société ». De même, il est impossible à 2 vues ou familles de même niveau hiérarchique d’atteindre leurs zones de données respectives : pour y arriver, elles doivent passer par une jointure. La jointure se fait grâce à la présence dans l’une des 2 d’un champ commun équivalent à une clé étrangère.
Développement et déploiement d’une GRC
-‐ 13 -‐
Fig. 3 : Arborescence des familles
3.3-‐Diagramme de classes Le diagramme de classes, détaillé ci-‐dessous (Figure 4), est basé sur les familles
employées par les différents utilisateurs d’Avenir Bureautique et Sigec qui sont : -‐ « Société » ; -‐ « Action » ; -‐ « Affaire » ; -‐ « Contact » ; -‐ « Parc ». La famille « Société » est à la fois une famille ancêtre et une famille principale donc
les 4 autres familles sont directement liées à elle. La vue « Action » peut se rapporter : -‐ soit aux vues « Contact » et « Action » ; -‐ soit à l’une des 2 ; -‐ soit à aucune des 2. De même, la vue « Affaire » peut concerner la vue « Contact » ou non.
Développement et déploiement d’une GRC
-‐ 14 -‐
En revanche, la vue « Commercial » doit toujours être associée aux vues « Affaire » et
« Action ».
Fig. 4 : Diagramme de classes de l’existant
Développement et déploiement d’une GRC
-‐ 15 -‐
4-‐Le développement Dans cette partie, je détaille chronologiquement les différentes actions entreprises
au niveau du développement de la GRC.
4.1-‐Cahier des charges Le cahier des charges a été pensé et constitué par Mrs Rodolphe ALBEROLA et
Fredéric CHARANSOL afin qu’il soit commun aux 2 sociétés. La première étape consiste à modifier plus ou moins profondément les différentes
vues employées par les commerciaux pour leur travail quotidien. Cela concerne les vues :
-‐ « Identification » ; -‐ « Autres informations Société » ; -‐ « Action » ; -‐ « Affaire » ; -‐ « Contact » ; -‐ « Parc ». En second lieu, il s’agit de trier les traitements existants (liste de travail, éditions,
exports, graphiques,…) afin de garder ceux nécessaires et donc les remanier selon les changements apportés aux vues qui leur sont liées.
Enfin, la dernière étape passe par un relooking de l’interface jugée trop terne et ayant un design des années 1990.
Dans la logique de travail des 2 sociétés, beaucoup de réunions se font à l’aide de
documents Word ou Excel qui sont composés d’informations piochées dans les différentes vues de Vente Partner : la mise à jour des vues et des traitements doit permettre de toujours passer par la GRC uniquement.
4.2-‐Premiers jours de stage Avant de commencer à détailler ma phase de développement, il convient de fournir
des informations sur mes premiers jours du stage. Outre la visite du siège social et ma présentation au personnel, j’ai reçu une
formation condensée de développeur/administrateur sur Vente Partner de la part de Mr Bertrand ELINEAU de Technomade durant 3 jours pour me familiariser avec la GRC.
Développement et déploiement d’une GRC
-‐ 16 -‐
Ensuite, afin que toutes les agences d’Avenir Bureautique puissent avoir la même
base de données, il a été nécessaire d’intégrer des bases de données qui étaient employées à part via des imports.
De plus, il a fallu installer la version 12.0 du logiciel sur tous les postes existants ainsi que sur les nouveaux.
Enfin, il fut décidé, en accord avec Mr Rodolphe ALBEROLA, que le développement se ferait graduellement par plusieurs mises à jour de la GRC au sein d’Avenir Bureautique afin d’habituer les commerciaux au maniement de ce nouvel outil et d’avoir des retours de son emploi.
4.3-‐Consolidations Il est primordial d’expliquer ce qu’est une consolidation. Chaque agence d’Avenir Bureautique possède son propre serveur où chaque poste
est connecté pour accéder à la base de données de Vente Partner, le serveur de Besançon faisant office de serveur central (il en est de même pour Sigec). Comme la base de données doit être identique sur chaque serveur, il faut que des consolidations s’effectuent entre chaque site.
Une consolidation donne la possibilité d’échanger des données entre serveurs par
des transferts de fichiers en protocole FTP. Un script permet, sur chaque serveur, de récupérer, pour chaque famille, les fiches qui ont été créées, modifiées ou supprimées durant les 3 derniers jours en les intégrant dans un fichier. Ainsi, le serveur central de Besançon doit constituer 3 fichiers à chaque consolidation pour le site de Dijon, celui de Montbéliard et un portable en licence monoposte c’est-‐à-‐dire ayant sa propre base de données (comme celui que j’ai employé pour le développement). Chaque fichier de consolidation élaboré est déposé dans un répertoire de destination avant d’être envoyé (ce fichier arrive dans un répertoire de destination). Ce même script (ou un autre) s’occupe de la réception en faisant l’inverse de ce qui vient d’être détaillé. Les consolidations s’effectuent 2 fois par jour : la période du déjeuner et le soir. Ces consolidations sont appelées consolidation de données.
Développement et déploiement d’une GRC
-‐ 17 -‐
Fig. 5 : Description de la consolidation de données
Il existe également la consolidation système : il s’agit d’une consolidation de
données à laquelle a été ajouté l’environnement système de la GRC. Ainsi, je passais toujours par celle-‐ci pour transférer sur les autres sites les mises à jour déployées sur le serveur de Besançon. En revanche, cela devait toujours se faire après une consolidation de données.
Le principe des consolidations occasionne plusieurs problèmes. Le débit internet
des sites de Dijon et de Montbéliard étant assez faible et variable, un fichier de consolidation pouvait toujours être en train d’être expédié alors que le script de réception à Besançon s’était déjà achevé ce qui occasionne un retard de mise à jour de la base de données. Ce problème est identique pour des consolidations de grande taille. De plus, celles qui s’effectuent durant la période du déjeuner gênent les commerciaux car Vente Partner ne doit pas être employé. Finalement, la solution à ces ennuis sera très vraisemblablement de supprimer la consolidation de mi-‐journée et de profiter pleinement de la nuit pour actualiser les bases de données.
4.4-‐Groupes d’accès et utilisateurs Par souci de sécurité et de rationalisation, il a été nécessaire de revoir les noms
d’utilisateur des usagers de la GRC ainsi que les groupes d’accès. Chaque nom d’utilisateur est défini sur 3 chiffres, le premier désignant le site (chez
Avenir Bureautique, 6xx pour Besançon, 7xx pour Dijon et 8xx pour Montbéliard). Un groupe d’accès contient 1 ou plusieurs utilisateurs. Il permet d’autoriser ou non
l’accès à des champs de saisie, des vues ou des traitements ainsi que l’ajout, la création et la modification. Par exemple, seuls les groupes « Administrateurs », « Chefs vente » et « Superviseurs » ont le droit de modifier le contenu de la liste d’aide du champ de saisie
Développement et déploiement d’une GRC
-‐ 18 -‐
« Fournisseur en place » dans la vue « Parc » ce qui permet d’avoir des données uniques et compréhensibles pouvant servir comme critère de tri sinon un même fournisseur pourrait avoir de nombreuses orthographes différentes.
L’application « Outils » livrée avec Vente Partner a été employée pour effectuer ces changements.
4.5-‐Vues La vue est la pierre angulaire de l’emploi de la GRC et donc la partie la plus
importante du développement. Toutes les créations ou modifications de vue se font via l’application « Ecrans »
fournie avec Vente Partner. Comme expliqué plus en avant du rapport, une vue est une fenêtre regroupant des
zones d’information ou de saisie. Il existe un certain nombre de ces zones sous « Ecrans ». En mettant de côté les plus communes à tout autre logiciel comme les libellés, cases à cocher, bouton radio et mémo, je vais m’attarder sur celles qui furent très importantes dans le processus de mise en forme de chaque vue.
Fig. 6 : Descriptif de zones sur la vue « Affaire »
Développement et déploiement d’une GRC
-‐ 19 -‐
4.5.1-‐Objet saisie L’objet saisie est une zone de saisie ou éventuellement une zone d’information de
taille fixe. Chaque objet saisie d’une vue doit porter un nom unique et possède un type de zone comme l’alphanumérique par exemple. En revanche, le type de zone est définitif à sa création.
Il est possible d’interdire la saisie (la zone se transforme alors en information), de l’autoriser sous certains facteurs et d’en vérifier le contenu sous plusieurs conditions. Le contenu de champ de saisie peut être initialisé selon certains critères ou via une formule. Cette formule est composée, soit d’une ou plusieurs autres zones provenant de la même vue (et/ou de sa vue « père »), soit d’une ou plusieurs fonctions prédéfinies de Vente Partner, soit d’un amalgame des 2. Toutefois, le peu de maniabilité de ces fonctions et l’impossibilité d’accéder à d’autres vues rendent ardu le choix des formules. Il est à noter que le système des formules fonctionne aussi pour l’autorisation d’atteindre une zone.
Enfin, un objet peut être visible ou caché. Il existe une option à l’objet saisie : c’est la liste d’aide. La liste d’aide est un
ensemble de données fournissant un choix de sélection. Si le champ est interdit en saisie, l’utilisateur pourra et peut-‐être devra y piocher dedans pour remplir la zone. Si elles ne sont pas saisies manuellement, les informations à l’intérieur d’une liste d’aide proviennent soit d’une autre vue soit d’une autre liste d’aide. L’affichage du contenu de la liste peut révéler un ou plusieurs champs. De même, le résultat de la sélection se trouvant maintenant dans l’objet saisi peut être une concaténation de plusieurs champs. De plus, le choix réalisé par l’utilisateur peut très bien faire afficher des valeurs d’autres champs de cette même liste dans d’autres zones de la même vue.
Comme il était demandé dans le cahier des charges, de nombreuses listes d’aides ont
été intégrées à des objets saisie. Celles-‐ci sont protégées de façon à ce que personne, hormis les groupes d’accès autorisés, ne puisse en modifier le contenu. En outre, les zones de saisie des objets qui leurs sont associées sont verrouillées en écriture dans le but d’avoir seulement les vraies données utiles pour des traitements.
Cependant, plusieurs problèmes sont apparus. D’une part, les changements dans une liste d’aide dont le contenu ne provient pas d’une vue ne seront effectifs que sur le serveur où elle se trouve. Pour que ces modifications soient prises en compte sur les autres serveurs, il faut à chaque fois exécuter une consolidation système. D’autre part, il apparaît que la même liste d’aide peut se retrouver sur 2 vues différentes. Pour palier ces difficultés, il a été décidé de transformer ces listes d’aide en nouvelles vues facilitant ainsi une mise à jour rapide des données sur chaque site et évitant les duplicatas. Par exemple, la liste d’aide des fournisseurs présente dans la vue « Parc » était identique à la liste des concurrents dans la vue « Affaire » : cette liste est devenue la vue « Entreprise
Développement et déploiement d’une GRC
-‐ 20 -‐
concurrente ». De même, les modèles d’une marque changeant fréquemment, une vue « Modèle » a été créée également.
4.5.2-‐Bouton action Un bouton action, tout comme un objet saisie, porte un nom unique et son accès
peut être autorisé ou non à certaines catégories de personnel. Il peut aussi intégrer du texte et/ou une image comme représentation visuelle. Il permet, entre autre, de déclencher un traitement, d’exécuter une application externe comme accéder à un site internet, de naviguer vers une autre vue ou d’exécuter un enchainement (par exemple, effectuer un export de données et l’ouvrir avec Microsoft Excel).
Les boutons existants aidaient déjà à réaliser ces fonctions. Le bouton de recherche
symbolisé par une paire de jumelles et ceux de déplacement d’une fiche à un autre ont été généralisés sur toutes les vues les plus importantes. Plusieurs boutons ont été conçus dans le but de rentrer sur des sites internet ou sur des applications réseau. Dans le cas des liens avec des sites internet, des scripts ont été élaborés incluant l’url du site.
4.5.3-‐Objet externe L’objet externe reprend les mêmes principes que le bouton action sauf qu’il permet
de stocker des fichiers dans une fiche d’une vue. Néanmoins, seule une copie du fichier a été faite : il ne s’agit en aucune façon d’un raccourci vers celui-‐ci.
Des boutons de dépôt de pièces jointes ont été conçus et positionnés dans les vues
« Identification », « Affaire » (les devis par exemple) et « Action » (les comptes-‐rendus de visite par exemple). Il a été fortement conseillé aux utilisateurs de ne déposer que des documents au format PDF pour éviter de trop alourdir la base de données et d’augmenter le temps de transfert du fichier de consolidation de données d’un site vers un autre.
4.6-‐Agenda L’agenda est une fonction propre à Vente Partner permettant à un utilisateur de
composer son propre emploi du temps. Pour fonctionner, l’agenda doit obligatoirement être associé à une vue : ici, il est liée à la vue « Action ». Ainsi, tout ce qui est réalisé dans la vue « Action » se retrouve dans l’agenda et vice versa. De fait, seules certaines données nécessaires à la création et à l’affichage apparaissent dans l’agenda : celles-‐ci ont été associées à certains champs de la vue « Action » dans l’application « Ecrans ».
Développement et déploiement d’une GRC
-‐ 21 -‐
Il convient de différencier 2 types d’élément nécessaire pour qu’une action se
retrouve dans l’agenda : -‐ la tâche : c’est une action dans le temps qui apparaîtra toujours en information
jusqu’à sa date d’échéance ; -‐ l’évènement : c’est une action ponctuelle qui a une date et une heure de début, et
une date et une heure de fin (par exemple, un rendez-‐vous). Chaque utilisateur de l’agenda a la possibilité de : -‐ définir des horaires de travail (affichés en couleur bleu ciel) ; -‐ définir l’affichage de ses évènements (jour, semaine, mois, …) ; -‐ définir des plages horaires de 15 minutes à 4 heures.
Fig. 7 : Exemple de l’agenda d’un commercial
Enfin, l’agenda planifié sous Vente Partner peut se retrouver dans Microsoft
Outlook. Lors de l’installation de la version 12.0 du logiciel, 2 options ont été installées afin
de faire le lien entre l’agenda et Microsoft Outlook : -‐ un plug-‐in pour Outlook;
Développement et déploiement d’une GRC
-‐ 22 -‐
-‐ une synchronisation entre Outlook et l’agenda. Cependant, il convient de noter que seules les données venant de l’agenda iront vers Outlook et non l’inverse.
Suite aux modifications apportées dans la vue « Action », il a fallu que je refasse le
lien entre les champs de cette vue et les champs obligatoires pour l’agenda. Certains champs concernant le contact n’étaient pas employés : comme un contact peut être intégré dans une action, j’y ai ajouté les champs nécessaires (champs « Civilité », « Nom » et « Prénom » de la vue « Action »). En outre, il a fallu aussi redéfinir les différentes catégories afin de les faire coïncider avec les données de la liste d’aide du champ « Type » de la vue « Action ».
Enfin, certains types d’action, jugés plus importantes que les autres, furent dotés
d’un code couleur dans le but de les faire ressortir dans l’agenda.
4.7-‐Traitements Les traitements sont des procédés de manipulation du contenu d’une ou plusieurs
tables pour afficher ou échanger des données. L’application « Traitements », livrée avec Vente Partner, permet de les gérer.
Bien qu’il y en ait un certain nombre, la nouvelle mouture de la GRC emploie surtout :
-‐ les listes de travail ; -‐ les éditions ; -‐ les dossiers ; -‐ les exports ; -‐ les graphiques ; -‐ les étiquettes. Comme je l’ai expliqué dans le chapitre précédent, le problème réside toujours en
cette hiérarchie des familles n’autorisant pas l’amalgame de plusieurs vues ou familles en une seule somme. Cette difficulté apparaît encore plus dans les traitements. Ainsi, des choix ont du être effectués pour palier ce problème, soit par l’ajout d’un champ de type clé étrangère dans une vue pour accéder aux informations d’une autre, soit par la restriction des informations visibles lors du résultat. Il est toutefois utile de noter que tous les traitements ont un point commun : la possibilité d’insérer des critères de tri afin de filtrer les valeurs d’une ou plusieurs vues.
Développement et déploiement d’une GRC
-‐ 23 -‐
Fig. 8 : Création des critères tri et visualisation de ceux-‐ci
4.7.1-‐Listes de travail La liste de travail est le résultat d’une recherche affichée sous le format d’une liste.
Un simple clic sur une ligne de celle-‐ci permet d’accéder directement à la vue associée, la liste se refermant temporairement en une icône. Les champs de visualisation de la liste sont définis lors de sa création mais peuvent être changés à tout moment car la liste a été créée à partir d’une vue.
Toutes les listes de travail ont été supprimées car elles ne répondaient pas aux
attentes des personnels d’Avenir Bureautique et Sigec et donc seules des nouvelles apparaissent dans la nouvelle mouture de la GRC.
Développement et déploiement d’une GRC
-‐ 24 -‐
Fig. 9 : Exemple de liste de travail
4.7.2-‐Editions L’édition est le résultat d’une recherche par critères de tri sur une ou plusieurs vues
pouvant être imprimé. Elle est constituée d’un amalgame d’une ou plusieurs des parties suivantes : -‐ entête ; -‐ haut page ; -‐ rupture haut ; -‐ corps ; -‐ rupture bas ; -‐ bas page ; -‐ pied ; -‐ graphique. L’entête n’apparaît qu’une seule fois au tout début de la première page. Le haut de
page sera présent en haut de chaque page, le bas de page en bas de chaque page et le
Développement et déploiement d’une GRC
-‐ 25 -‐
corps toujours au centre de chaque page. Le pied permet de faire la somme totale des différents champs numériques présents dans les autres parties. Le graphique est un graphe. Les ruptures n’existent que si les données des champs servant pour des critères de tri sont classées de façon ascendante ou descendante. Elles permettent de faire la séparation entre chaque groupe de données disposé dans le corps. Par exemple, pour une édition du parc machine, la rupture peut être faite sur une société.
Fig. 10 : Exemple de disposition dans une édition
De nombreuses éditions ont été remaniées ou crées, les autres étant laissées de côté.
Le seul problème est venu du système de rupture qui n’autorisait pas de pouvoir faire plus que 2 critères de tri ascendant ou descendant : des projets d’éditions plus sophistiquées et détaillées ont dû être abandonnés.
4.7.3-‐Dossiers Le dossier regroupe un ensemble d’éditions. Il intègre aussi une édition contenant
un haut de page et un bas de page qui se transforme en bloc de haut de page et bloc bas de page, ces 2 blocs s’affichant toujours en haut de page et bas de page de chaque édition constituant le dossier.
Développement et déploiement d’une GRC
-‐ 26 -‐
Fig. 11 : Exemple de définition d’un dossier
Les dossiers existants ont été remaniés de façon à intégrer les nouvelles éditions
réalisées.
4.7.4-‐Exports L’export est la récupération des valeurs d’une ou plusieurs vues sous le format d’un
fichier exploitable par des applications sous Microsoft Windows. Les valeurs sont regroupées par champ.
Plusieurs exports ont été conçus et intégrés dans des boutons de type action dans la
vue « Menu ». Chacun de ces boutons effectue aussi, après la création de l’export, le lancement du logiciel Microsoft Excel.
4.7.5-‐Graphiques Le graphique est une représentation sous forme de graphe d’une zone numérique
provenant soit d’un champ au format numérique d’une vue soit d’un calcul. Il est ajouté
Développement et déploiement d’une GRC
-‐ 27 -‐
dans une édition : ce sont les informations de cette dernière qui sont employées pour celui-‐ci.
Plusieurs représentations sont disponibles : -‐ par colonne ; -‐ par courbe ; -‐ par aire ; -‐ par barre ; -‐ par secteur. Seul un seul graphique de type secteur a été conçu.
4.7.6-‐Etiquettes
L’étiquette est une édition simple (sans entête, corps, rupture ou bas de page) prévue pour un format de feuille précis portant des étiquettes autocollantes prédécoupées. Chaque résultat des critères de tri associés est imprimé sur une de ces zones prédécoupées. Plusieurs formats prédéfinis sont intégrés mais il est tout à fait possible d’en personnaliser un autre.
Fig. 12 : Définition d’une étiquette
Il existait une édition simple de type étiquette qui a été gardée, seuls de nouveaux
critères de tri y ont été ajoutés. Pour information, le format employé chez Avenir Bureautique et Sigec n’apparaissant pas dans les formats prédéfinis de Vente Partner, il avait été personnalisé (étiquette largeur 70mm, hauteur 37mm, 8 rangées pour 3 colonnes).
Développement et déploiement d’une GRC
-‐ 28 -‐
4.8-‐Relooking Le relooking s’est surtout concentré sur le remplacement des icônes et images trop
vieillottes et trop pixélisées. De même, les fonds gris terne des vues ont été remplacés par une texture de fond unique pour toutes. Tous les boutons permettant d’accéder aux vues ou à des traitements ne servant plus ont été cachés.
4.9-‐Tâches annexes Tous les commerciaux se retrouvent une fois par mois au siège social dans le but de
procéder à une relance groupée sur les prospects. Cette relance s’effectue via des éditions contenant un minimum d’informations.
La solution serait de mettre un commercial devant chaque ordinateur équipé de Vente Partner pour avoir tous les renseignements d’une société à disposition mais peu de postes sont libres pour doter chacun. Finalement, il a été décidé de procurer à chaque commercial des sites de Dijon et Montbéliard un ordinateur portable pouvant se connecter aussi bien à la base de données de son agence que celle de Besançon. D’une part, un technicien de Technomade a dû intervenir à distance de façon à ce que le nombre maximum d’ordinateurs connectés ensemble au serveur passe de 6 à 9. D’autre part, j’ai installé la GRC sur ces nouveaux matériels ainsi que 2 petits scripts. Chacun de ces scripts permet d’accéder au serveur d’un site bien particulier. Selon le lieu où se trouve la machine, l’utilisateur devra exécuter le bon script avant le lancement du logiciel.
Développement et déploiement d’une GRC
-‐ 29 -‐
Conclusion N’ayant toujours connu que le monde militaire, j’éprouvais une certaine
appréhension à effectuer un stage dans une entreprise. Toutefois, le thème fort intéressant du projet à réaliser et l’accueil chaleureux du personnel d’Avenir Bureautique m’ont totalement rassuré et m’ont permis de m’intégrer très facilement au sein de la société.
A l’issue de ces 14 semaines intenses et riches en expériences, je peux faire un bilan
très positif de cette immersion dans le monde du travail. D’un point de vue humain, je suis pleinement satisfait d’avoir évolué au sein
d’Avenir Bureautique qui est une entreprise très structurée et d’y ressentir un esprit de compétitivité permanent lui permettant de pérenniser sa position d’important acteur régional dans son secteur d’activité tout en conservant une ambiance de travail d’équipe conviviale. De plus, l’échange d’idées et d’informations s’est toujours bien passé entre moi et d’une part, les différents acteurs prenant part au développement de l’application et d’autre part, les utilisateurs de cette nouvelle mouture.
D’un point de vue technique, ce séjour m’a permis de découvrir un environnement logiciel qui m’était totalement inconnu jusqu’à ce jour : la GRC. Bien qu’ayant eu des débuts difficiles malgré une formation succincte et accélérée, j’ai réussi à me l’approprier et à en connaître les principaux rouages me permettant ainsi de réaliser un outil performant au service de la chaine commerciale de la société. Il offre maintenant des renseignements très détaillés et très précis sur les clients ou les prospects. Certes, elle aurait eu besoin d’autres améliorations mais elle a été suffisamment actualisée pour rester en service encore plusieurs années.
Finalement, ce stage au sein d’Avenir Bureautique aura été une aventure très
enrichissante aussi bien sur le plan humain que sur le plan technique. Cette aventure se termine donc mais une autre commence. En effet, la semaine suivante la fin du stage, j’intégrerai une équipe de développement au sein d’Axess Vision, toujours à Besançon, afin de concevoir une GED pouvant ensuite être proposée à leurs clients par les commerciaux d’Avenir Bureautique et Sigec.
Développement et déploiement d’une GRC
-‐ 30 -‐
Glossaire FTP (sigle pour File Transfer Protocol) C’est un protocole de communication destiné à l’échange informatique de fichiers sur un réseau TCP/IP.
NAF (sigle pour Nomenclature d’Activités Françaises) Elle représente, par un code, l’activité principale exercée dans une entreprise ou une association.
QBE (sigle pour Query By Example) En français, cela se traduit par interrogation par l’exemple. Son principe est que l’utilisateur présente un exemple du résultat de recherche attendu puis le soumet au SGBD.
SGBD (sigle pour Système de Gestion de Base de Données) En informatique, c’est un logiciel système destiné à stocker et à partager des informations dans une base de données qui est un ensemble d’informations stockées dans un dispositif informatique.
SIRET (sigle pour Système d’Identification du Répertoire des Etablissements) Il s’agit d’un identifiant géographique d’un établissement ou d’un entreprise codé sur 14 chiffres.
SQL (sigle pour Structured Query Language) C’est un langage informatique normalisé servant à effectuer des recherches, des ajouts, des modifications ou des suppressions de données dans une base de données.
Développement et déploiement d’une GRC
-‐ 31 -‐
Webographie
Avenir Bureautique http://www.avenirbureautique.fr/ KDP Informatique http://www.kdp-‐info.com
Sage Group http://www.sage.fr/
Sigec http://www.sigec-‐bureautique.com/
Technomade http://www.technomade.com/
Wikipédia http://fr.wikipedia.org
Développement et déploiement d’une GRC
-‐ 32 -‐
Annexes
Annexe A : L’ancienne mouture de la GRC
Page d’accueil de Vente Partner composée de la vue « Menu »
Développement et déploiement d’une GRC
-‐ 33 -‐
Vue « Menu relances » accessible depuis la vue « Menu »
Vue « Editions » accessible depuis la vue « Menu »
Développement et déploiement d’une GRC
-‐ 34 -‐
Vue « Tables des paramètres » accessible depuis la vue « Menu »
Vue « Commercial » accessible depuis la vue précédente
Développement et déploiement d’une GRC
-‐ 35 -‐
Vue « Identification » accessible depuis la vue « Menu »
Vue « Autres informations Société » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 36 -‐
Vue « Heures de visite » accessible depuis la vue « Identification »
Vue « Contact » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 37 -‐
Vue « Action » accessible depuis la vue « Identification »
Vue « Affaire » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 38 -‐
Vue « Offre » accessible depuis la vue « Identification »
(vue non modifiée)
Vue « Parc » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 39 -‐
Annexe B : Le cahier des charges
Nouvelle vue « Identification »
Nouvelle vue « Contact »
Développement et déploiement d’une GRC
-‐ 42 -‐
Exemple de future liste d’aide pour la nouvelle vue « Identification »
Développement et déploiement d’une GRC
-‐ 43 -‐
Exemple de future liste d’aide pour la nouvelle vue « Identification »
Développement et déploiement d’une GRC
-‐ 44 -‐
Annexe C : La nouvelle mouture de la GRC
Page d’accueil de VenteParter composée de la vue « Menu »
Vue « Tables de paramètres » accessible depuis la vue « Menu »
Développement et déploiement d’une GRC
-‐ 45 -‐
Vue « Identification » accessible depuis la vue « Menu »
Vue « Autres informations Société » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 46 -‐
Vue « Heures de visite » accessible depuis la vue « Identification »
Vue « Contact » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 47 -‐
Vue « Action » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 48 -‐
Vue « Affaire » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 49 -‐
Vue « Parc » accessible depuis la vue « Identification »
Développement et déploiement d’une GRC
-‐ 53 -‐
Résumé La licence professionnelle « Systèmes Informatiques et Logiciels spécialité
Conception et Développement Orientés Objet d'Applications Multi-‐tiers »dispensé à l’Université de Franche-‐Comté de Besançon durant une année universitaire est validée par l’intermédiaire d’un stage en entreprise d’une durée de 14 semaines.
Ce stage a été effectué au sein d’Avenir Bureautique à Besançon. Cette entreprise,
spécialisée dans les systèmes de reproduction et de communication, m’a accueilli dans le cadre d’un projet de développement d’une nouvelle GRC (Gestion de la Relation Clients) en remplacement d’une ancienne devenue obsolète et inadéquate. La nouvelle mouture est conçue sur le logiciel Vente Partner d’après un cahier des charges où je devais modifier des fenêtres de saisie et des traitements de données tout en relooking de tout l’ensemble. Mots clés
FTP, GRC, langage orienté objet C++, requête QBE, requête SQL, SGBD
Abstract The professional degree of Computer Science proposed by the Université de
Franche-‐Comté (Besançon, France) during a year is validated through an apprenticeship in a company for a period of 14 weeks.
This apprenticeship has been done in Avenir Bureautique in Besançon. This
company is specialized in systems of reproduction and communication. The project consisted in developing a new CRM (Customer Relationship Management) to replace an old version that had become obsolete and inadequate. The new version is conceived based on the software Vente Partner following a scope statement in which I had to modify all type-‐in windows and data analysis and perform a relooking of all the software. Key words
CRM, FTP, Object-‐oriented language C++, QBE request, SQL request, DBMS