PPT_FINAL(1)

33 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
33
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Monsieur le président du jury, Messieurs les jurés, Honorables invités, Permettez-nous de vous bruler un cierge pour l’importance, témoignée par votre présence, que vous accordez à ce jour solennel, qui voit le couronnement d’un travail ardemment abattu durant 03 années.
  • Il est en effet notoire, que notre présence ici ce matin, s’inscrive dans le cadre de la soutenance de notre mémoire de fin de cycle car l’Ecole Supérieure d’industrie, l’une des 08 grandes écoles que recèle l’INP-HB, s’inscrivant dans la vision de cette dernière, qui est d’assurer une formation de qualité à ses étudiants, organise à l’intention de iceux en fin de cycle, des stages pratiques en entreprise en vue de fignoler leur formation par le truchement d’une confrontation des connaissances générales acquises durant leurs parcours académiques aux réalités du monde socio-professionnel.
     
    Ces stages pratiques induisent la production d’un mémoire amené à être soutenu devant un jury et c’est dans ce contexte que nous fûmes accueillis à la Société Générale de Banques en Côte d’Ivoire du 12 avril au 24 juin 2016, où il nous fut soumis le thème suivant 
  • : « Conception et implémentation d’un système décisionnel web pour l’optimisation du processus du pilotage ».
     
  • Très cher auditoire, Nous pensons qu’avant de poursuivre cette danse de vocables, il faille nous présenter : Ainsi suis-je KOUASSI Béyégbin Baudouin Venceslas, élève technicien supérieur en Informatique 3ème année.
     
    Afin de mieux appréhender le thème à nous assigné, il nous est apparu opportun de faire orbiter notre présentation autour de trois grands nœuds essentiels : De prime abord, un tour d’horizon sur l’environnement du thème au travers des généralités. Ensuite, puisque toute œuvre humaine qui se respecte requiert une phase conceptuelle, ainsi en sera-t-il pour la nôtre au travers de la seconde partie, en l’occurrence l’Analyse et la conception globale du système. Enfin, n’étant pas à cette chaire pour du verbiage creux, nous présenterons la mise en œuvre de notre système au travers de la dernière partie intitulée : Réalisation.
     
    Alors pieds joints, et sans hésitations aucunes, nous sautons dans la marmite !
  • La gestion efficace des entreprises et la quête perpétuelle de la productivité, ont toujours été les contestables les plus plébiscitées dans les programmes de développement de toutes les entreprises, y compris celles présentes dans l’écosystème économique ivoirien.
     
    Les besoins d’anticipation en vue de faire face à la concurrence et les besoins en services de plus en plus complexes, ouvrent la voie à l’utilisation des technologies de l’information dont l’évolution constante depuis plusieurs années, allant des systèmes opérationnels de base aux systèmes actuels de traitement des grandes masses de données ou Big Data, couplée à la diversité des perspectives offertes aux entreprises, laisse plus d’un sans mots.
     
    Ainsi conscient des possibilités offertes par ces nouvelles technologies pour une gestion efficace de ses activités telles que le pilotage ressources humaines et le pilotage financier, le Centre de Services Mutualisées Systèmes d’Informations de la SGBCI décide – t – il d’en profiter, en informatisant ses activités précédemment énumérées.
  • Afin de mieux cerner ces propos, il s’impose de connaitre notre structure d’accueil au travers des généralités.
  • Suite à une reconversion profonde de l’activité de sa succursale ivoirienne ouverte depuis 1941, le Groupe Société Générale, renforce ses moyens en la dotant des trois (3) guichets exploités par la Banque Commerciale Africaine qu’elle a racheté le 15 juillet 1962. L’ensemble est apporté à une entité nouvelle, la SGBCI, le 23 Novembre 1962.
    Plusieurs objectifs et missions sont l’apanage de la Société Générale au nombre desquels figure la Banque au quotidien.
  • Le centre de services Mutualisés Systèmes d’Informations, en abrégé CSMSI est une entité rattachée à la Société Générale. Sorti des fonds baptismaux en 2010, il a pour mission de gérer les systèmes d’informations des filiales d’Afrique subsaharienne, de la Société générale, qui siège en France. Ce dernier compte plusieurs services au nombre desquels figure le pole « Pilotage et Transformation. » destiné à assurer sa gestion administrative. C’est par ailleurs ce dernier qui nous abrita durant toute notre période de stage.
     
    A présent, présentons les raisons de notre séjour à la Société Générale.
  • Le Service « Pilotage et Transformation » gère plusieurs activités dont les pilotages RH et Financier.
    Le premier consiste à générer mensuellement des indicateurs de performances via une extraction de données de sources hétérogènes, une consolidation de ces données, la génération et la diffusion des indicateurs.
    Le pilotage Financier gère le suivi des opérations financières, notamment la gestion des engagements des dépenses, dont le workflow est ci-contre illustré.
    Ainsi était – il question pour nous d’auditer ces deux activités afin d’en déceler les principales insuffisances et proposer des palliatifs.
     
  • L’analyse menée nous permit de constater que les différents processus recelaient plusieurs défections au nombre desquelles une absence de gestion automatisée.
  • La compilation des insuffisances constatées et des souhaits exprimés, lors de différentes interviews avec les responsables du pilotage, nous permit de proposer deux axes d’améliorations:
     
    Pour le pilotage RH : la mise en place d’une plate-forme de reporting mensuel des indicateurs.
    Et pour le pilotage Financer : la mise en place d’un outil de gestion automatisée et centralisée de demandes de dépenses issues des trois sites du CSMSI.
     
    Nos objectifs se résumaient alors à concevoir une plate-forme web intégrant deux applications spécifiques, en l’occurrence une application métier de gestion des engagements des dépenses, et une application Business Intelligence intégrant toute la chaine décisionnelle. Les deux applications étant liées par le fait que la base de données de la première fasse partie des sources de données de la seconde.
     
    Pour se faire, il nous fallut adjoindre à la démarche de conception classique des applications métiers, les haltes de la conception d’un système décisionnel.
     
    Aussi la conduite du projet fut – t- elle assurée par une méthodologie agile notamment SCRUM afin de bien gérer la transition entre les deux applications à concevoir.
     
    Afin de comprendre la suite de notre projet, il est utile de définir les bases de la Business intelligence.
  • La BI appelé décisionnel en français, est un processus permettant aux entreprises de prendre de bonnes décisions sur la base de données analytiques.
     
    L’architecture générale d’un SID consiste à extraire des données des applications opérationnelles, puis transformer et intégrer ces données par le biais du processus E.T.L dans le Datawarehouse et enfin à en extraire des informations par le biais d’analyses.
  • La modélisation des systèmes décisionnels diffère de celle des systèmes transactionnels. L’on parle ici de modélisation dimensionnelle et cette dernière est caractérisée par plusieurs concepts.
    Nous avons le fait qui constitue l’indicateur de performance,
    la dimension qui est l’axe d’analyse du fait,
    le grain qui constitue le plus fin niveau de détail et
    le cube qui est le nom donné à un modèle dimensionnel dans lequel l’on trouve au moins trois dimensions.
    Par ailleurs, de même que nous avons les diagrammes de classes en UML, et le MCD en Merise, la modélisation dimensionnelle dispose de 2 modèles de données principales dont :
    le modèle en étoile et
    le modèle en flocon de neige
  • A présent il nous incombe de préluder la conception de notre système par une étude préliminaire.
  • Afin de concevoir un système informatique, il s’impose d’opter pour une méthode d’analyse adéquate. Il en existe plusieurs mais pour notre part, le Processus Unifié dans sa variante 2TUP pour Two Track Unified Process, nous a le plus séduit du fait de son adaptabilité aux réalités de notre projet.
  • Par ailleurs, le monde décisionnel étant différent du transactionnel, il nous fallait une autre méthode de conception pour notre entrepôt de données. Ainsi avons-nous opté pour une approche mixant celle des pères du décisionnels, notamment Ralph Kimball avec son « approche par besoins d’analyses » et Bill INMON avec la sienne « par les sources de données », afin de profiter au mieux des perspectives offertes par leur deux méthodes en question et d’en mitiger les difformités.
     
  • L’étude préliminaire débouche sur la conception de notre système et nous commençons par le volet opérationnel
     
    Au niveau de la conception du volet opérationnel, la capture des besoins fonctionnels nous a permis d’avoir plusieurs acteurs, cas d’utilisation et packages.
    Un acteur représente l’abstraction d’un rôle joué par des entités externes qui interagissent directement avec le système étudié.
    Un cas d’utilisation est une fonctionnalité du système futur et
    Un package de cas d’utilisation en est un regroupement.
     
    Le diagramme ci – contre montre le diagramme de cas d’utilisation du package  « Gestion de la finalisation des dépenses ».
     
    « Décrire les relations »
  • Le modèle dynamique inclut plusieurs diagrammes dont le diagramme de séquences. Ce dernier met l’accent sur la chronologie des échanges qui ont lieu dans le système.
    Dans notre cas, nous avons utilisé le modèle des classes d’analyse de Jacobson qui recommande l’utilisation d’objets Boundary, Control, et Entity. Le premier constitue l’interface graphique, le second les traitements et le dernier, le modèle de données interagissant avec notre base de données.
    Ci-contre, nous avons le diagramme de séquence du cas d’utilisation Gérer budget et Compte.
     
    « Décrire les types de messages ».
  • Le modèle statique est illustré par le diagramme de classes du package « Gestion des engagements des dépenses. ».
    Une classe est le regroupement de plusieurs objets ayant des caractères communs.
    A ce niveau, nous avons respecté l’un des principes phares de la conception d’applications dans le domaine bancaire, à savoir : l’historisation. C’est ce qui est matérialisé par la classe statut. Un objet supprimé voit simplement son statut changer, mais il demeure dans la base pour des restaurations éventuelles et pour assurer la traçabilité des traitements effectués.
     
  • Au niveau des besoins techniques, nous avons choisi ASP.NET MVC pour répondre au besoin de séparation en couches logicielles de notre application.
  • Ci-contre figure l’architecture technique de notre application métier.
     
    « Décrire le Data flow».
     
    Passons à présent à la conception de notre application Business Intelligence.
     
  • Tout projet BI suit un processus bien défini appelé chaine décisionnelle et la figure ci-contre en illustre le nôtre.
    Les données extraites des systèmes sources sont harmonisés au niveau du serveur E.T.L, puis chargées dans le Datawarehouse.
    Ensuite, le modèle de données du Datawarehouse est séparé d’un point de vue métier, sous forme de cubes.
    Enfin, les données issues de ces cubes sont transmises à l’application de reporting qui se charge de diffuser les indicateurs et tableaux de bords.
     
  • La modélisation dimensionnelle suit plusieurs étapes dont :
    Le choix de l’activité à modéliser. A ce niveau, il est d’usage d’utiliser la matrice de priorité de KIMBALL afin de déterminer l’activité à modéliser en premier lieu.
    Ensuite il faut définir la granularité de l’activité,
    Trouver les dimensions participantes du modèle dimensionnel,
    Et Définir les mesurables du fait.
  • Dans notre cas d’espèce, nous avions 5 activités à modéliser et le graphe d’analyse des priorités nous a permis de choisir en premier lieu, l’activité « Suivi des CRA et Absences ».
  • La figure ci-contre illustre le modèle dimensionnel en flocon de l’activité «  Suivi des CRA et Absences ».
     
    Ici nous voyons la table de faits en jaune contenant les indicateurs et des clés étrangères qui sont en fait les clés primaires des tables de dimensions.
     
  • Après avoir conçu le modèle de donnée d’entreposage, il faut mettre en place le processus d’alimentation de ce dernier.
    La figure ci—contre illustre le processus d’alimentation de notre datawarehouse.
     
    Les données sont extraites de 2 bases de données et de plusieurs fichiers Excel.
    Ces données subissent par la suite des transformations, puis sont préparées dans la zone « stagging area » pour le chargement final dans l’entrepôt de données.
  • Les responsables du pole ont besoin de suivre mensuellement les indicateurs selon plusieurs contextes. Par exemple, les absences, les heures supplémentaires et les consommations téléphoniques, pour ne citer que ceux – là.
    Le principe des cubes dimensionnels répond à cela.
    Ainsi avons-nous obtenu plusieurs cubes et la figure ci-contre montre le cube « Suivi des dépenses » modélisé en étoile.
  • Au niveau de l’architecture du volet décisionnel de notre système, nous avons utilisé la suite BI de Microsoft ;

  • Très cher auditoire, nous ne sommes pas sans savoir que cette soutenance ne soit pas un traité d’art contemporain. Ainsi urge-t-il de présenter à présent, les différents livrables obtenus.
     
    Au niveau de la réalisation, il s’est agi d’implémenter au préalable l’application métier, puis l’application BI avant de terminer par leur intégration dans la plate-forme web commune.

     
  • Ainsi estimons-nous, après sommation de la taille des différentes tables majorées de 30%, la taille de notre datawarehouse à 20,056 Mo /An.
    La figure suivante illustre l’implémentation du processus E.T.L pour l’une des tables de la dimension activité.
    Ici l’on peut voir que le fichier Excel source subit plusieurs transformations,
    Puis les données obtenues sont chargées dans la zone de stockage de destination.
    Nous constatons donc que l’exécution de ce package a réussi, avec le nombre d’enregistrements chargés.
  • Afin d’implémenter notre système final, il s’impose de définir clairement son architecture technique. La figure ci-contre corrobore nos précédents dires.
     
    « Décrire le data flow »
     
  • Le modèle COCOMO (Constructive Cost Model) nous a permis d’évaluer financièrement notre système à 9 000 000 de FCA.
    Aussi la figure suivante en présente – elle la page d’accueil générale.
    Ici nous avons la page d’authentification dont le coin supérieur droit montre que notre application intègre le responsive Design.
    Enfin nous avons le menu d’accueil d’un agent du CSMSI.
     
    Alors, Les dernières minutes étant avalées par l’écoulement effréné du temps qui s’affiche à l’horizon, il s’impose de conclure notre présentation afin de respecter le délai à nous imparti.
  • Retenons en somme que le stage effectué à la SGBCI, du 12 avril au 24 juin 2016, avait pour but de faire une analyse critique de deux activités du processus de pilotage du CSMSI, notamment les pilotages financier et RH, afin d’en déceler les difficultés et de proposer des solutions informatiques en guise de palliatifs.
    Notre travail consistait donc à mettre en œuvre deux applications spécifiques, dont l’une générique et l’autre, intégrant la chaine décisionnelle, puis à les intégrer en une plate-forme web commune.
    L’analyse du cahier des charges et des différentes interviews menées, nous a permis l’utilisation d’une méthodologie agile, notamment SCRUM, de la déclinaison 2TUP du processus unifié et de la modélisation dimensionnelle pour la gestion, l’analyse et la conception du projet.
    L’outil réalisé se présente comme une solution pour une amélioration de la productivité des responsables du pôle pilotage du CSMSI, dans la mesure où elle permettra la centralisation et l’automatisation de processus, auparavant manuels.
    De ce stage, nous sortons comblés car nous avons pu mettre en pratique les connaissances théoriques acquises pendant notre formation et découvrir de nouveaux horizons, en l’occurrence les méthodes agiles et la Business Intelligence appliquées au milieu bancaire.
  • Alors pouvons – nous de mèche avec Antoine de Saint-Exupéry dire que « la perfection est atteinte non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer », afin de signifier que nous encourageons tout apport correctif ou suggestif, pour le peaufinage de notre ouvrage.  

    Et C’est justement pour cette raison, honorables jurés, que nous vous rétrocédons le flambeau, afin d’élucider les éventuels nuages de préoccupations qui vous embrasent actuellement l’esprit, prendre en compte vos éventuelles critiques et bien attendues suggestions.
     
    Merci pour votre attention !
  • PPT_FINAL(1)

    1. 1. « Deviens qui tu es, Fais ce que toi seul peut faire » Friedrich Nietzsche
    2. 2. Soutenance de Projet de Fin d’Etudes CONCEPTION ET IMPLÉMENTATION D’UN SYSTÈME DÉCISIONNEL WEB POUR L’OPTIMISATION DU PROCESSUS DE PILOTAGE : CAS DU CSMSI – Société Générale Dr KOUAME Kouakou Enseignant – Chercheur à l’INP-HB M. BOUA Wilfried Responsable Architecture et Stratégie SI au CSMSI Kouassi Béyégbin Baudouin Venceslas Présenté Par Thème Année Académique : 2015-2016 Elève Technicien Supérieur Informatique 3ème Année Encadreur Pédagogique Maitre de Stage
    3. 3. Conception et Implémentation d’un Système Décisionnel Web pour l’Optimisation du Processus de Pilotage : Cas du CSMSI – Société Générale 3 Thème
    4. 4. 4 Introduction Partie 1 : Généralités Partie 2 : Analyse et Conception globale du Système Partie 3 : Réalisation Conclusion Sommaire
    5. 5. 5 Quêtes perpétuelles de productivité Besoin d’anticipation du fait de la concurrence Diversité des perspectives offertes par les TIC Introduction Recours aux TIC pour la gestion efficace des entreprises
    6. 6. 6 Généralités Première Partie
    7. 7. 7 Présentation de la Structure d’accueil Historique • Succursale ivoirienne ouverte depuis 1941. • Création de la SGBCI le 23 Novembre 1962. Missions et Objectifs • Banque au quotidien ; • Prêts et financements ; • Epargne et placements • Assurance et prévoyance. Infrastructures informatiques • Ordinateurs • Serveurs  Cadre de référence général : SGBCI
    8. 8. 8 Présentation de la Structure d’accueil Missions • gestion des SI des filiales d’Afrique Sub- saharienne, de la Société Générale Organisation • Répartition par site (Dakar, Douala et Abidjan) • 2 Départements subdivisés en 11 services Service « Pilotage et Transformation » • Assurer la gestion administrative du CSMSI • Mesurer la performance du CSMSI • Elaborer le budget du CSMSI  Cadre de référence spécifique : CSMSI
    9. 9. 9 Présentation et Cadrage du Projet  Etude de l’existant Reporting mensuel KPI et TDB Extraction manuelle des données à partir de plusieurs sources Consolidation des données des fichiers Excel Génération manuelle des indicateurs Diffusion des indicateurs Gestion des engagements des dépenses Initiation des engagements des dépenses Validation des engagements des dépenses Finalisation des engagements des dépenses Reporting mensuel et Chargement historique des comptes.
    10. 10. 10 Présentation et Cadrage du Projet  Analyse de l’existant Forces Clarté des procédures KPI bien définis Bonne circulation de données dans le Workflow Faiblesses Processus répétitif et fastidieux Des risques d’erreurs Aucun outil de gestion automatisée Redondances et aucune BD de GED
    11. 11. 11 Présentation et Cadrage du Projet  Solutions proposées • Mise en place d’un outil de gestion centralisée des demandes d’engagement de dépenses provenant des trois sites du CSMSI (Dakar, Douala, Abidjan) PILOTAGE RH • Mise en place d’une plateforme de Reporting permettant de générer les tableaux de bords mensuels. PILOTAGE FINANCIER  Conduite de Projet : SCRUM
    12. 12. 12 Notions fondamentales de la BI o Processus visant à transformer les données en informations et, par l'intermédiaire d'interrogations successives, transformer ces informations en connaissances. o Collection de données orientées sujet, intégrées, non volatiles et évolutives dans le temps, organisées pour le support d’un processus d’aide à la décision.  Datawarehouse ou Entrepôt de données  Business Intelligence  Processus E.T.L ( Extract – Transform - Load) o Consiste à extraire les données des sources(BD, fichiers plats, ERP, CRM…), les transformer via des corrections et/ou harmonisations, et les stocker dans le DW.
    13. 13. 13 Notions fondamentales de la BI  Concepts de la Modélisation dimensionnelle Concept de fait • Mesures ou Indicateurs de performances Concept de dimension • Axes d’analyse d’un fait Concept de granularité • Le niveau de détail le plus fin de la table de fait. Concept de cube • un fait analysé selon trois dimensions. Concept d’Hyper- cube • Un fait analysé selon plus de trois dimensions  Types de modèles dimensionnels Modèle en étoile • se présente comme une étoile dont le centre n’est autre que la table des faits et les branches sont les tables de dimension. Modèle en flocon • Identique au modèle en étoile, sauf que ses branches sont éclatées en hiérarchies Modèle en constellation • Plusieurs modèles en étoiles liés par des dimensions communes
    14. 14. 14 Analyse et Conception Globale du Système Deuxième Partie
    15. 15. 15 Etudes Préliminaires Petit, moyen et grand projet mais limité Approche systémique Bonne représentation de l’existant MERISE Très grand projets avec réalisation par étapes Approche orientée objet Langage précis qui cadre l’existant PU/UML  Méthode d’Analyse et de Conception du système global
    16. 16. Etudes Préliminaires Le contenu du Data Warehouse sera déterminé selon les besoins de l’utilisateur final Approche « Besoin d’analyse » Le contenu du Data Warehouse est déterminé selon les sources de données Approche « Sources de données » Une combinaison des deux approches appelée hybride ou mixte peut s’avérer efficace. Prend en considération les sources de données et les besoins des utilisateurs Approche mixte  Méthode de Conception du Datawarehouse 16
    17. 17. 17 Analyse et Conception du Volet Opérationnel  Capture des besoins fonctionnels  Package: « Gestion de la finalisation des dépenses »
    18. 18. 18 Analyse et Conception du Volet Opérationnel  Modèle dynamique : Diagramme de séquence  Cas d’utilisation : « Gérer budget et Compte d’Imputation »
    19. 19. 19 Analyse et Conception du Volet Opérationnel  Modèle Statique : Diagramme de classes  Package: « Gestion des engagements des dépenses» 0..1 0..* 0..1 0..* 0..1 0..* 0..1 0..* 0..1 0..* 1..* 0..* 0..* 1 1..* 1 0..* 1..* 1..* 1 1..* 0..* 0..1 0..* Agent - - - - - - - AgentID AgentPrenom AgentMotDePasse AgentNom AgentAdresse AgentTéléphone AgentStatut : String : String : String : String : String : Text : String + + + + + + + + + + + + + authentifier () consulterDemande () editerDépense () creerDépense () validerDépense () imprimerDépense () rejeterDépense () selectionDépense () telechargerDépense () finaliserDépense () rechercherAgent () creerSession () creerDétailSession () : void : void : void : void : void : void : void : void : void : void : void : void : void Article - - - - articleID articleDescription articleNom articleStatut : String : String : String : int Chapitre - - - chapitreID chapitreLibellé chapitreStatut : String : String : Statut Exercice - - - - exerciceID exerciceDateDebut exerciceDateFin exerciceStatut : String : Date : Date : Statut Dépense - - - dépenseID dépenseEtat dépenseStatut : String : EtatDépense : String + + + + calculerMontantDépense () deplacerDépense () modifierDépense () rechercheAfficherDépense () : double : void : void : void Compte - - - compteID compteStatut compteNuméro : String : Statut : String + + + + selectionCompte () calculerSolde () modifierCompte () rechercheAfficherCompte () : boolean : double : void : void Budget - - - budgetID estimé BudgetStatut : String : double : Statut + calculerTauxExecution () : double EngagementDépense - - - - engagementDate engagementObservation engagementRéponseValidation engagementPiecesJustificatif : Date : String : boolean : String + verifierRéponseValidation () : boolean ExecutionBudget - - reestimé réalisé : double : double + calculerTauxExecution () : double Action - - actionID actionNom : String : String Historique - - HistoriqueDate HistoriqueDescriptionAction : Date : String 0..1 0..* 0..1 0..* Statut - - - StatutID StatutNom StatutDescription : int : String : String StatutAgent - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int StatutDépense - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int StatutCompte - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int StatutChapitre - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int StatutBudget - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int StatutExercice - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int StatutArticle - - - DateDebutStatut DateFinStatut Commentaires : Date : Date : int
    20. 20. 20 Analyse et Conception du Volet Opérationnel  Capture des besoins techniques Plateforme de développement .NET 4.5 Langage coté serveur ASP.NET MVC 6 Langage de script C#.NET ORM Entity Framework 6 Architecture 3 tiers IDE Visual Studio 2013 Serveur d’application Internet Information Services (IIS) Système serveur Windows Server 2003 SGBD SQL Server 2014
    21. 21. 21 Analyse et Conception du Volet Opérationnel  Architecture technique
    22. 22. 22  Les Composantes du volet décisionnel du Système Analyse et Conception du Volet Décisionnel Données Sources Serveur E.T.L Datawarehouse Cube OLAP Application de reporting Stockage des données traitées Extraction, Transformation et Chargement des données dans le DW Modèles pour la visualisation des données Application diffusant les TDBs et KPIs
    23. 23. 23  Conception de la zone d’entreposage du Datawarehouse Processus de modélisation dimensionnelle Choisir l’activité à modéliser Définir l’activité et choisir son grain Trouver les dimensions Définir les indicateurs  Les étapes de la modélisation dimensionnelle Analyse et Conception du Volet Décisionnel
    24. 24. 24  Conception de la zone d’entreposage du Datawarehouse 0 2 4 6 8 10 12 14 SUIVI DES DEPENSES SUIVI DES SAISIES DE CRA SUIVI DES ABSENCES ET CRA SUIVI DU BUDGET SUIVI CONSO. TELEPHONIQUE Facilité Intérêt  Choix de l’activité : Matrice d’analyse de priorités de R. KIMBALL Analyse et Conception du Volet Décisionnel
    25. 25. 25 Analyse et Conception du Volet Décisionnel  Conception de la zone d’entreposage du Datawarehouse DIM TYPE_AGENT <<PK>> code_DIM_Type_Agent nom_Type_Agent DIM SITE_DEPARTEMENT <<PK>> <<FK>> <<FK>> code_DIM_SiteDépartement code_DIM_Département code_DIM_Site nom_Site_Département DIM SITE <<PK>> code_DIM_Site nom_Site DIM DEPARTEMENT <<PK>> code_DIM_Département nom_Département DIM SERVICE <<PK>> <<FK>> code_DIM_Service code_DIM_SiteDépartement nom_Service FAIT SUIVI_CRA_ABSENCES <<PK>> <<FK>> <<FK>> <<FK>> code_FAIT_CRA_Absences Code_Calendrier code_DIM_Tache code_DIM_Agent Nombre_Absences_Agent Nombre_Absnces_Motif Total_Absneces_Motif Total_Absences_Motif Ratio_Absence_Agent Ratio_Absences_Motif Taux_Absenteisme Taux_JHC_Agent Taux_JHC_Activité Nombre_CRA_Agent Nombre_CRA_Activité Taux_JHC_Agent_Activité DIM CALENDRIER <<PK>> Code_Calendrier date jour mois année année_Mois jour_semaine semaine_mois DIM AGENT <<PK>> <<FK>> <<FK>> code_DIM_Agent code_DIM_Type_Agent code_DIM_Service nom_Agent prénom_Agent Adresse_Agent Nombre_Jour_Ouvrés Tél_Agent DIM TACHE <<PK>> <<FK>> code_DIM_Tache code_Phase_Activité nom_Tache détails_Tache charge_Jour_Homme DIM PHASE_ACTIVITE <<PK>> <<FK>> <<FK>> code_Phase_Activité code_DIM_Phase code_DIM_Activité commentaires_phase DIM ACTIVITE <<PK>> <<FK>> code_DIM_Activité code_DIM_Type_Activité nom_Activité DIM PHASE <<PK>> code_DIM_Phase nom_Phase DIM TYPE_ACTIVITE <<PK>> code_DIM_Type_Activité nom_Type_Activité correspondre5 correspondre4 contenir correspondre3 correspondre12 avoir000 avoir00 contenir6contenir8 lier7 lier10 lier8  Modèle en flocon de l’activité « Suivi des CRA et Absences »
    26. 26. 26 Analyse et Conception du Volet Décisionnel  Conception de la zone d’alimentation du Datawarehouse  Architecture du processus E. T. L Transformation Transformation Transformation Serveur ETL SSIS BD AGENT Data Warehouse BD GED Staging Fichiers Excel Staging Staging
    27. 27. 27 Analyse et Conception du Volet Décisionnel  Conception des cubes : Cube « Suivi des dépenses » DIM ARTICLE DIM CHAPITRE code_DIM_Chapitre nom_Chapitre description_Chapitre DIM COMPTE code_DIM_Compte DIM COMPTE code_DIM_Chapitre numero_Compte nom_Compte etat_Compte code_DIM_Article DIM ARTICLE code_DIM_Compte nom_Article description_Article <h1:1> <h1:2> <h1:3> Hierarchy_1 Hierarchy_2 <Default> <h1> <h2> Cube_Suivi_Dépense Nombre_dépense_par_Agent nombre_dépense_par_site nombre_Article_dépense FAIT_SUIVI_DEPENSE DIM DEPENSE code_DIM_Dépense etat_Dépense <h:1> Hierarchy_1 <Default> <h> DIM AGENT DIM TYPE_AGENT code_DIM_Type_Agent nom_Type_Agent code_DIM_Agent DIM AGENT code_DIM_Type_Agent code_DIM_Service DIM_code_DIM_Service nom_Agent prénom_Agent Adresse_Agent Nombre_Jour_Ouvrés Tél_Agent <h:1> <h:2> Hierarchy_1 <Default> <h> DIM CALENDRIER Code_Calendrier date jour mois année année_Mois jour_semaine semaine_mois <h:1> Hierarchy_1 <Default> <h> Cube_Suivi_Dépense - DIM DEPENSE FAIT SUIVI_DEPENSE - DIM AGENT FAIT SUIVI_DEPENSE - DIM CALENDRIER FAIT SUIVI_DEPENSE - DIM ARTICLE
    28. 28. 28 Analyse et Conception du Volet Décisionnel • Sql Server Analysis Service (SSAS) • Application de reporting • API REST de MS Power BI • Sql Server Integration Service (SSIS) • MS SQL Server Zone de stockage Zone d'alimentat ion Serveur OLAP Outil de reporting  Architecture générale
    29. 29. 29 Réalisation Troisième Partie
    30. 30. 30 Implémentation du Volet Décisionnel  Implémentation E.T.L Taille du DW 20,056 Mo/An
    31. 31. 31 Déploiement et Présentation du Système final  Architecture technique du système final <<device>> Poste de travail <<HTTPS>> Navigateur Web <<device>> Serveur d'application <<ExecutionEnvironment>> Serveur Web <<HTTPS>> IIS <<ExecutionEnvironment>> Application SDOPP Module GED Module Reporting BI <<device>> Serveur de visualisation <<REST>> MS Power BI <<ExecutionEnvironment>> Serveur ETL MS SSIS<<ExecutionEnvironment>> Serveur OLAP <<REST>> MS SSAS <<ExecutionEnvironment>> SGBD SQL Server BD GED Data warehouse <<ExecutionEnvironment>> Dossiers sur disque fichiers Excel <<ExecutionEnvironment>> SGBD ACCESS BD AGENT <<HTTPS>> <<REST>> Navigateur Web IIS Module GED Module Reporting BI MS Power BI MS SSIS MS SSAS BD GED Data warehouse fichiers Excel BD AGENT
    32. 32. 32 Déploiement et Présentation du Système final  Evaluation financière Sprints Temps (Homme /jour) Prix Unitaire (FCFA) Total (FCFA) Cadrage 40 50 000 2000 000 Analyse et Conception 30 100 000 3 000 000 Réalisation 30 100 000 3 000 000 Tests de validation 10 40 000 400 000 Déploiement et Maintenance 15 40 000 600 000 Total 125 - 9 000 000  Quelques écrans
    33. 33. 33 Conclusion Conclusion Conception et Implémentation d’un Système Décisionnel Web pour l’Optimisation du Processus du Pilotage : Cas du CSMSI – Société Générale
    34. 34. 34 A Vous l’ Honneur Questions Critiques Suggestions « La perfection est atteinte non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retrancher » Antoine de Saint - Exupéry

    ×