Conception : Étude Préalable

L’étude préalable consiste à définir le cadre général du projet, les fonctionnalités attendues, les contraintes techniques et budgétaires, les risques, ainsi que les différentes solutions possibles pour répondre aux exigences du projet. À la fin de l’étude préalable, dans un cadre théorique idéal, une proposition de solution est présentée aux parties prenantes du projet. Cette proposition inclut une description détaillée du projet, une estimation des coûts et des délais, ainsi qu’un plan d’action pour la réalisation du projet. En réalité les choses sont parfois quelque peu différentes, nous le verrons plus loin.

Mais revenons donc pour l’instant aux fondations de ce projet décisionnel, à savoir sur le besoin exprimé initialement par la direction commerciale : « Doter la Direction Commerciale d’un outil d’aide à la décision lui permettant d’analyser, sous forme de quelques rapports, les prospects, les rendez-vous et les réservataires ». L’idée globale, au départ du projet, était donc de disposer de quelques indicateurs permettant de suivre « l’efficacité des campagnes de communication », en analysant pour cela les origines des prospects ainsi que les appels téléphoniques reçus et émis, d’une part et de « suivre les réservataires », en affichant dans un même tableau les données issues du logiciel de Gestion de la Relation Client (CRM : pour Customer Relationship Management) et celles du progiciel métier. Le directeur commercial (qui était en même temps l’un des actionnaires principaux de l’entreprise), commanditaire de ce projet auprès de la DSI, était animé par le désir de « savoir ce qu’il était possible de faire en interne ». Il n’y a eu aucun écrit, aucun délai, aucun budget réellement alloué à ce projet. 

Ainsi, afin de « « voir ce qu’il était possible de faire » et de pouvoir avancer sur le l’élaboration des différentes hypothèses de réponse à ce besoin il a été essentiel tout d’abord pour la DSI de Pythagore d’analyser de manière plus approfondie le système d’information (SI) métier de l’entreprise.

1.1.1.1      Analyse du système d’information « métier » : un SI intégré

Au lancement du projet le système d’information de l’entreprise repose, dans sa dimension « gestion », sur 3 principaux logiciels. Un progiciel métier, un outil de GRC (CRM) ainsi qu’une solution de comptabilité multibase (une base de données SQL Server par société gérée). Tout au long de ces  10 années de projet certaines de ces applications évolueront ; c’est le cas du CRM qui sera migré une fois et du logiciel comptable qui connaîtra 2 migrations successives. 

De très nombreuses autres applications viendront progressivement couvrir les différents domaines fonctionnels (un outil pour la gestion des réserves, un autre pour les appels d’offre, etc…). Il serait extrêmement long et assez hors sujet de décrire ici de manière détaillée les interactions applicatives et les différentes interfaces existantes au sein du SI.  Aussi nous allons nous concentrer sur le cœur du projet initial. En analysant plus en détail cette dimension du SI de Pythagore nous voyons apparaitre rapidement une dépendance extrêmement forte entre l’outil de gestion de la relation client et le progiciel métier de l’entreprise. Dépendance qui, dans les faits, est une intégration forte, par webservices, entre les deux applications.

En synthèse nous pouvons dire que le CRM est la base de référence pour la création des prospects mais il est également le réceptacle des programmes immobiliers et lots (appartements / commerces) en provenance du progiciel métier. Le cycle de commercialisation (pose d’options, réservations, désistements) se fait dans le CRM, les ventes (signatures d’actes notariés), les appels de fonds et les livraisons sont enregistrés dans l’outil de gestion. L’ensemble de ces mouvements sont synchronisés afin qu’à tout moment les informations stockées dans les deux applications soient cohérentes. Cette synchronisation bidirectionnelle est le point central du système d’information « métier » de l’entreprise.

Nous sommes donc ici face à un SI métier dont les deux poumons sont le progiciel métier et le CRM. Le besoin d’outil de restitution, exprimé dans ce projet, porte essentiellement sur la dimension commerciale (commerce / communication / marketing) cette partie du SI ne dispose d’aucun outil de pilotage en revanche la restitution de la dimension
gestion est d’ores et déjà assurée par la suite Business Object.

Compte tenu de ce contexte en matière de BI, compte tenu de l’intégration très forte entre les deux logiciels il semble naturel à la maitrise d’œuvre (DSI) de proposer à la direction commerciale une solution reposant sur le même outil (BO). 

1.1.1.2      L’hypothèse Business Object 

Business Object dans sa version XI 3.1 R3 (version en place au lancement du projet) est effectivement largement utilisé au sein de Pythagore au moment où la direction commerciale se penche sur son projet. Cette solution repose sur plusieurs briques
« managées » via la console centrale d’administration.

Mais commençons par la source (de données). En effet pour que la conception des rapports décisionnels soit envisageable dans l’environnement Business Object, il convient tout d’abord de structurer les données et les rendre intelligibles. Cette structuration des données se fait dans le module Univers Designer. Il s’agit du composant qui permet de donner une représentation métier des données contenues dans le système d’Information de l’entreprise. Designer couvre d’une certaine manière les dimension « Extract » et « Transform » d’un outil « ETL ». Cette « traduction des données pour les besoins métier » se fait via la structure principale du système BO : l’Univers. Un univers Business Object est composé de classes et d’objets de divers types.

L’une des fonctions de l’univers est donc de présenter les données sous une forme intelligible par l’utilisateur final afin de permettre à celui-ci de construire lui-même ses rapports. Cette construction des rapports se fait dans le composant Desktop Intelligence.

Desktop Intelligence doit être considéré avant tout comme l’outil de conception des rapports. En effet même si le logiciel permet d’actualiser (rafraichir) les données ce n’est pas ça fonction principale. L’idée est ici de concevoir des rapports avec les données fournies par l’univers conçu avec Univers Designer. La sélection des objets nécessaires à la réalisation du rapport se fait vie le « fournisseur de données » Le « fournisseur de données » permet, en plus de la sélection des données de positionner des conditions qui vont s’appliquer aux données ciblées. Ces conditions peuvent être de différentes natures (invites, constantes, listes de valeurs…) ou peuvent reposer sur des « contextes » correspondant à des filtres préétablis. Une fois les données sélectionnées, Desktop Intelligence permet une grande souplesse dans la structuration et la présentation des données dans le rapport. De nouvelles variables calculées ou conditionnelles peuvent être ajoutées, des mises en forme conditionnelles sont possibles, des filtres peuvent être appliqués aux tableaux ou au rapport en lui-même. Dans cette hypothèse « BO » l’objectif pour la DSI était de construire les nouveaux rapports avec Desktop Intelligence et de permettre aux utilisateurs de les consulter grâce au portail de visualisation Infoview.

Infoview, la partie visible pour les utilisateurs finaux de « l’iceberg Business Object », est le portail de publication des rapports conçus avec Desktop Intelligence. Pour être visibles et « actualisables » les rapports construits dans Desktop Intelligence doivent être « Exportés vers le référentiel [1]».

En fonction des autorisations et des habilitations, l’utilisateur final peut ainsi accéder à certains documents, actualiser les indicateurs présents dans le document et éventuellement, s’il le souhaite, enregistrer le document au format excel ou pdf sur son ordinateur. Certains rapports peuvent contenir des « invites ». Les invites rendent la consultation du document plus
interactive étant donné que grâce aux invites le salarié peut mieux cibler le périmètre de son analyse. Il peut par exemple choisir la période d’analyse, un secteur géographique, une agence, etc…

Considérant les profils, très orientés vers les technologies « web », il semblait primordial, dans le cadre de ce projet, de ne pas sous-estimer le volet « consultation » de celui-ci.  L’objectif pour la MO était donc de mettre en avant ce mode de consultation des indicateurs. Cependant en prenant en considération la culture de « consommation des informations » de Pythagore, d’avantage orientée vers l’information poussée (plus « push » que « pull » donc), la consultation dynamique via Infoview trouvait son complément dans l’information poussée via la Console centrale d’administration et son planificateur. En fin de compte la stratégie était donc d’associer la consultation interactive en mode web proposée par Infoview à la génération des
rapports depuis la console de gestion centralisée.

Après une première démonstration de cette architecture au groupe projet celle-ci n’a pas été retenue. D’une part la version de BO installée chez Pythagore ne permettait pas la construction d’univers multi-source (NB : il faudra, pour cela, attendre la version 4.1) alors qu’un accès multi-source apparait comme indispensable dans le cadre de l’étude préalable, d’autre part le volet « consultation » fut jugé trop figé et trop archaïque. Le souhait de la direction commerciale était de disposer d’un outil permettant une « interactivité plus grande » lors de la consultation.

1.1.1.3      L’hypothèse du portail de restitution en mode web

Après l’accueil très mitigé de la solution Business Object et son rejet par la maitrise d’ouvrage l’hypothèse Pentaho, une suite logicielle Open Source dédiée à l’informatique décisionnelle a été promptement évoquée mais souhait était avant tout d’avancer rapidement sur ce projet « en temps masqué », l’étude s’est alors focalisée sur la pise d’un portail de restitution de
données en mode web (PHP / Sql Server) développé spécifiquement pour Pythagore. Une infrastructure technologique maitrisée par le DSI. 

En effet avant son arrivée chez Pythagore, celui-ci a eu pour mission principale sur son précédent poste de RSI, de participer à l’analyse puis de conduire un projet de migration logicielle d’une coopérative de 150 salariés. Aprèsplusieurs années de partenariat et de co-construction de l’application sous Forms (Oracle) avec un éditeur de logiciels métier la migration a débuté par les modules dédiés à la production et s’est poursuivie avec ceux destinés à la commercialisation, la gestion de la préparation des commandes, la gestion des expéditions etc …

Un projet très complet d’un point de vue fonctionnel, managérial et technique mais un projet surtout qui se soldera par la mise en œuvre d’une première architecture n-tiers destinée à la restitution de données.

En effet, après le déploiement de la solution, les différents retours négatifs des salariés portaient systématiquement sur la consultation, sur la restitution trop figée des données saisies dans le système et non sur l’utilisation, en elle-même, de l’application nouvellement déployée. L’objectif du RSI fut donc de trouver une solution de restitution de données totalement
intégrée au système d’information applicatif.

Durant cette période les technologies web étaient en pleine expansion, il a donc décidé d’associer le serveur web Apache à la base de données sous Oracle et grâce au langage PHP il a ainsi construit son premier système de restitution de données en phase avec les besoins des salariés.

Cette solution de contournement lui a fait entrevoir une autre possibilité de présenter les informations aux salariés. Des pages web qui parcourent les données du système applicatif et qui les présentent de manière « conviviale » et dynamique aux utilisateurs.

C’est dans un objectif de capitalisation et de rétroingénierie que le choix sera donc finalement fait de proposer à la direction commerciale un portail de restitution de données en mode web. Un choix qui débutera par la mise en œuvre d’un environnement de démonstration, un prototype, reposant sur la plateforme WAMP (Windows Apache MySQL PHP). 

1.1.1.3.1     Environnement WAMP

La plateforme WAMP présente l’avantage de reproduire en local, c’est-à-dire sur un simple ordinateur, une architecture n-tiers plus complexe. En d’autres termes il s’agit d’un environnement de simulation et de démonstration intégrant les différents serveurs nécessaires au déploiement d’une architecture web complète.

Ce prototype doit permettre d’évaluer l’adéquation potentielle entre le « besoin global exprimé » et les possibilités de restitution de ce type de systèmes et de démontrer, en même temps, que ce système peut répondre aux différentes problématiques de restitution rencontrées dans le CRM (manque de totaux dans les rapports, données multi-source indisponibles, etc.).

Cet environnement de démonstration repose sur deux rapports construit autour de deux pages chacun : la première page permet de définir les critères de sélection puis, à la validation des critères de sélection, une deuxième page présente les résultats correspondant à ces critères.

L’un des objectifs principaux de ce prototype était de mettre en évidence la consultation multibases. C’est la synchronisation des clients et des réservations entre le CRM et le progiciel métier, évoqués dans l’analyse du SI, qui me permet d’établir ce lien.

Grace à ce lien il devient ainsi possible de lister, dans un des rapports produits, les réservations issues de l’application métier et de compléter les informations de chaque ligne avec des information qui proviennent du CRM. Les informations issues du CRM sont par exemple celles relatives à « l’origine » du prospect, soit le canal par lequel celui-ci est arrivé dans le système d’information de Pythagore (nous reviendrons régulièrement sur cette donnée), son courriel ou encore sa date de création.

L’objectif du deuxième rapport produit dans le cadre de ce prototype sera de mettre en évidence les totaux, les mises en page spécifiques etc.

 Ø  Résultat dela démonstration

L’enjeu majeur de cette démonstration était de montrer qu’un autre système que Business Object était envisageable et que ce système pouvait offrir la souplesse attendue en termes de présentation des données restituées mais aussi en matière d’interrogation de celles-ci. La présentation articulée autour des 2 modules susmentionnés a convaincu le groupe projet. Les salariés ont rapidement compris que l’outil présenté pouvait répondre de manière précise aux besoins très spécifiques en matière de restitution au sein de l’entreprise.

Nous verrons que ces besoins iront bien au-delà de ce qui était exprimé au départ de ce projet.

Tout restait à réaliser, mais en même temps le fait d’avoir pu produire un environnement de démonstration complet laissait envisager une proactivité et une réactivité forte en matière de développement. Au fur et à mesure de la présentation des idées naissaient, chaque membre du groupe projet semblait séduit par les perspectives et la capacité du système à restituer les données en mode web avec des sources multiples.

Le paramètre « coût » (inexistant en termes d’investissement et de coûts directs) de cette potentielle solution d’informatique décisionnelle a été bien évidemment, peut-être pas déterminant mais en tout cas, très remarqué. Suffisamment remarqué pour que dans un climat d’enthousiasme général le projet (pouvons-nous vraiment parler de
projet ?) soit validé par un « Ok, on y va ! » venu du directeur commercial, actionnaire et sponsor de cette « aventure » …