Docstoc
EXCLUSIVE OFFER FOR DOCSTOC USERS
Try the all-new QuickBooks Online for FREE.  No credit card required.

Schéma_Directeur_Scénario2

Document Sample
Schéma_Directeur_Scénario2 Powered By Docstoc
					Projet De
Conception
Choix d’une architecture
informatique




Schéma directeur
Scénario 2
Baptiste GERARD
Houcem BOULBIT (CdP)
Maricel NUNEZ
Vlad LAPADATESCU

Groupe PC4



12 Décembre 2008

Version 1.5
Choix d’une architecture informatique                                                  GERARD, BOULBIT, NUNEZ, LAPADATESCU


 Sommaire

 I. Options technologiques .........................................................................................................3
 II. Détail du scénario ..................................................................................................................3
    A. Architecture fonctionnelle cible ...........................................................................................3
    B. Architecture technique détaillé............................................................................................6
      a) Principe général ................................................................................................................... 6
      b) Mise en œuvre de la solution .............................................................................................. 7
    C. Architecture physique détaillée .........................................................................................10
      a) Architecture globale .......................................................................................................... 10
      b) Exploitation........................................................................................................................ 10
    D. Plan de mise en œuvre .......................................................................................................11
      a) Déploiement ...................................................................................................................... 11
      b) Financement ...................................................................................................................... 14
    E. Analyse des risques ............................................................................................................17
    F. Politique de changement ...................................................................................................17




                                      Schéma directeur – Scénario 2                                          2
Choix d’une architecture informatique                        GERARD, BOULBIT, NUNEZ, LAPADATESCU




  I.    Options technologiques

    L'un des logiciels les plus complets et utilisés par les entreprises c'est ERP (en français Progiciel
de gestion intégré PGI) puisque permet de gérer l'ensemble des processus opérationnels d'une
entreprise, en intégrant l'ensemble des fonctions de cette dernière comme la gestion des ressources
humaines, la gestion comptable et financière, mais aussi la vente, la distribution,
l'approvisionnement, le commerce électronique.


    ERP dispose de beaucoup de versions, tant privées comme open source. Entre les plus
remarquables et utilisées sur le marché nous pouvons trouver : SAP Business One, PeopleSoft (de
Oracle), Microsoft Dynamics NAV (de Microsoft), Infor, Sage Group, Compiere (Java basé sur des
systèmes ERP) et Openbravo (Java basé sur des systèmes ERP).


    Ensuite nous verrons les caractéristiques principales d'ERP, ainsi que nous montrerons dans
détail, les distinctes technologies avant signalées.


 II.    Détail du scénario

    A. Architecture fonctionnelle cible


    A cet instant l’architecture fonctionnelle de l’entreprise peut se résumer dans ce tableau :
           Domaine                                             Description
 Vente                          Gestion des clients, des offres, des commandes, de facturation, etc.
 Marketing                      Gestion des informations sur la position de l’entreprise
 Approvisionnement              Gestion et suivi des commandes d’achat, des fournisseurs, etc.
 Fabrication                    Gestion des programmes de production, des stocks, matières
                                premières
 Gestion de l’Energie           Suivi des contrats EDF, gestion des plafonds de consommation
 Maintenance                    Gestion du budget de maintenance, des entretiens, etc.
 Transport                      Gestion des opérations de transport amont et aval
 Gestion de ressources
 humaines
 Gestion de ressources
 financières
 Bureautique, Groupware




   La plus part des domaines (et donc des applications qui sont utilisées par ce domaine) vont être
couverts par l’intégration d’un ERP. On envisagera une couverture minimale pour cette solution de
80% des domaines.

                           Schéma directeur – Scénario 2                    3
Choix d’une architecture informatique                      GERARD, BOULBIT, NUNEZ, LAPADATESCU
    En fonction de l’ERP qu’on va choisir on va avoir des domaines fonctionnelles qui vont avoir une
tendance de converger.

   La solution ERP va améliorer :

          Les échanges entre les domaines : On va avoir une communication entre les services
           beaucoup plus rapide qu’avant grâce à un exchange en temps réel entre les domaines,
           une base de données commune, identifiants des tables cohérents sur tous les domaines,
           etc.
          La cohérence des données : En remplaçant le transfert de fichiers en batch la nuit avec
           un mécanisme de communication des données en temps réel, on élimine les possibles
           incohérences entre des bases de données partagées par des différents domaines.
          La façon dont on travail : on va être obligées a adopter une méthode de travail plus
           soignée
          La sécurité : on va pouvoir limiter l’accès aux ERP (et donc aux données) aux personnes
           non autorisées. On va se baser sur une politique des rôles qui est très maintenable.




                         Schéma directeur – Scénario 2                  4
Choix d’une architecture informatique                     GERARD, BOULBIT, NUNEZ, LAPADATESCU

           Technologies annexes aux ERP

Moteur de Workflow


         Le moteur de Workflow qu’on va utiliser, sera l’ERP en lui-même. Un Workflow ERP est une
forme de processus qui peut être mise en relation avec le BPM (Business Process Management), qui
est basé sur un plan d’affaires et sur une automatisation des processus d’entreprise. Un Workflow
nous permet d’avoir un temps de réponse sur des requêtes qui est moins court, tout en augmentant
l’efficience des processus et permettant d’avoir un processus d’analyse et un audit des processus.

       Un Workflow est une exigence dans n’importe quel moteur ERP, donc on ne doit pas
chercher ailleurs pour trouver une autre solution. On a déjà couvert les avantages des moteurs de
Workflows. Pour plus des renseignements, veuillez consulter le document de Veille Technologique.




B2B et Décisionnel


      Aussi, la solution ERP contient dans beaucoup des cas une solution B2B ou ils ont la
   possibilité d’intégrer facilement une.

       Un exemple est l’SAP qui peut intégrer une telle solution : Crossgate B2B 360 Services.

       SAP Business Information Warehouse (qui fait partie de Netweaver) est une grande solution
   de business intelligence (décisionnel), d’analyse et de reporting. Il contient un outil de
   paramétrage de solution décisionnel (Data Warehouse Workbench) avec des possibilités
   étendues analytiques, une suite de logiciels de reporting (Bex) et un outil de simulation et de
   planification avec Integrated Planning (anciennement BPS pour Business Planning and
   Simulation.

       On voit donc qu’une solution ERP apporte beaucoup des avantages et aussi elle peut intégrer
   des solutions B2B ou décisionnels qui normalement on devrait acheter séparée.




                         Schéma directeur – Scénario 2                   5
Choix d’une architecture informatique                       GERARD, BOULBIT, NUNEZ, LAPADATESCU
    B. Architecture technique détaillé

    a) Principe général
   Avant de commencer à parler des pas qu’on doit suivre pour pouvoir adopter une architecture
ERP, on doit tout d’abord essayer de comprendre quels sont les besoins d’une architecture de type
ERP.

    Les applications ERP sont déployées normalement de manière distribuée sur un réseau. On a
d’une part les serveurs, qui font partie d’une architecture centralisée, mais on a aussi les clients qui
sont repartis dans la plupart des cas dans des localisations géographiques différentes (qui font donc
partie d’une architecture distribuée).

    Dans une architecture ERP il y a trois domaines fonctionnels de responsabilité, qui sont repartis
entre les serveurs et les clients :

    1. Composante de base de données: c’est le répertoire central des données qui sont transférées
       depuis et vers les clients.
    2. Les clients : on introduit des données brutes, on envoie des requêtes contenant des données
       qu’on a introduites précédemment et on présente la réponse du/des serveur(s) par rapport
       aux requêtes envoyées.
    3. La composante application qui joue le rôle d’un intermédiaire entre les clients et la base des
       données.

    La localisation physique de ces composantes ainsi que la façon dont les processus sont distribués
, vont varier d’une implémentation à l’autre. Il y a deux architectures qui sont très employées :

        1. L’implémentation 2-Tiers :

         Dans une architecture de type 2-tiers, le serveur a deux rôles : serveur de base de données et
serveur d’applications. Les clients sont responsables de présenter les données et de passer l’entré
des utilisateurs aux serveurs. Même si dans une telle architecture, il peut y avoir plusieurs serveurs,
avec des clients distribués sur une diversité des segments du réseau, le principe de distribution des
responsabilités, reste le même. Voici une architecture de type 2-tiers.



                       Internet


                                                                       Router reseau interne
                                             Serveur BD/Application




                                                                               Client
                      Client




                           Schéma directeur – Scénario 2                   6
Choix d’une architecture informatique                        GERARD, BOULBIT, NUNEZ, LAPADATESCU
        2. L’implémentation 3-Tiers Client/Serveur:

       Dans les architectures de type 3-tiers, les parties base de données et application sont
séparées. Ce type d’architecture est une architecture qui est plus utilisée par les grandes entreprises.
Dans ce scenario, un client est desservi par deux ou plusieurs connexions réseau. Dans un premier
temps le client établit une connexion avec le serveur d’application. Le serveur d’application établit
après une autre connexion avec le serveur de base de données. Les réponses des requêtes vont se
propager dans le sens inverse. Voici une architecture de type 3-tiers.




                                          Serveur
                                            BD




            Internet

                                                              Router reseau interne



                                          Serveur
                                         application




                                                                     Client
           Client


       Vu la taille actuelle, tout en gardant en tête la possibilité                       d’expansion
géographique/d’activité de l’entreprise, nous proposons une architecture 3-tiers.

    b) Mise en œuvre de la solution


         Le problème d’intégration et de mise en œuvre de la solution date presque depuis
l’apparition de l’ERP. Pour adresser ce problème on a plusieurs solutions, chacun ayant ses avantages
et ses limites :

                   Middlewares
                   Outils EAI
                   Connecteurs ERP
                   Utiliser les API des ERP qu’on veut installer pour construire des connecteurs nous-
                    mêmes ou des nouveaux modules pour l’outil ERP qu’on va mettre en place.

       De plus en plus les vendeurs d’ERP vont inclure dans leurs produits une large gamme des API
de bas niveau permettant d’avoir accès aux données. Cette approche API fonctionne très bien quand
                              Schéma directeur – Scénario 2                    7
Choix d’une architecture informatique                   GERARD, BOULBIT, NUNEZ, LAPADATESCU
il s’agit de 2 ou 3 modules ERP mais de plus en plus on veut que les données qu’on modifie, se
propage sur un très grand ensemble de modules et d’applications. Ces API donc, fonctionnent bien
pour permettre l’accès aux données mais ils ne peuvent pas fournir une intégration complète des
processus d’entreprise comme des Workflows, etc. Pour cela on doit chercher d’autres alternatives.

         Quand les API sont insuffisantes ou de trop bas niveau pour les utiliser d’une manière
efficiente, on peut utiliser des outils EAI. Il existe plusieurs outils qui facilitent le transfert de données
entre des modules ERP et les autres applications. Produits comme Transformation Server (Data
Mirror Corporation) nous donne les outils pour extraire et partager les données entre les modules
ERP et les applications.

        Dans le cas de notre entreprise, cette solution semble être la plus pertinente possible. On ne
va donc garder que les applications qui ne sont pas couvertes par les modules d’ERP qu’on va choisir,
et pour ces applications on va utiliser des outils EAI pour faire l’échange d’information entre eux et
les autres modules ERP.


                                                        ERP

                                  Module ERP 1     Module ERP 2            Module ERP n




                                   Outil EAI                                Outil EAI




                                 Application 1                            Application n




                            Schéma directeur – Scénario 2                       8
Choix d’une architecture informatique                         GERARD, BOULBIT, NUNEZ, LAPADATESCU
        Le tableau ci-dessous nous donne les applications qui vont être assimilées par des modules
ERP et les applications qui vont être intégrées à l’aide d’un outil EAI.

         Domaine             Application    Type Integration          Description
 Vente                  Gescom, Gesmad        Module ERP       Gestion des clients, des
                                                               offres, des commandes, de
                                                               facturation, etc.
 Marketing              Gesmkt                Module ERP       Gestion des informations
                                                               sur     la    position   de
                                                               l’entreprise
 Approvisionnement      Gestappmp,            Module ERP       Gestion et suivi des
                        gestapppd                              commandes d’achat, des
                                                               fournisseurs, etc.
 Fabrication            Gesfab                Module ERP       Gestion des programmes
                                                               de production, des stocks,
                                                               matières premières
 Gestion de l’Energie   -                      Outil EAI       Suivi des contrats EDF,
                                                               gestion des plafonds de
                                                               consommation
 Maintenance            Gesmaint              Module ERP       Gestion du budget de
                                                               maintenance,            des
                                                               entretiens, etc.
 Transport              Gestransp             Module ERP       Gestion des opérations de
                                                               transport amont et aval
 Gestion          de Gesindus, Gesper         Module ERP
 ressources humaines
 Gestion          de Sysco, Compsite          Module ERP
 ressources
 financières
 Bureautique,        Lotus/Notes               Outil EAI
 Groupware




                            Schéma directeur – Scénario 2              9
Choix d’une architecture informatique                      GERARD, BOULBIT, NUNEZ, LAPADATESCU



    C. Architecture physique détaillée

    a) Architecture globale

    On peut avoir deux types d’architectures physiques :


Une architecture "2tiers"
     Ce type d’architecture est le plus simple qu’on peut avoir dans le but d’héberger une solution
ERP. On va utiliser plusieurs serveurs qui vont être à la fois serveurs de données et serveurs
d’applications. Cette solution implique des changements minimaux en termes d’architecture, mais on
propose une mise à jour des équipements réseaux passifs, actifs et aussi des serveurs, pour pouvoir
faire face à de nouvelles demandes en termes de puissance, bande passante et hébergement de
données.


Une architecture "3tiers"
   Ce type d’architecture est plus complexe que la précédente. On voit une augmentation dans le
nombre de transactions (a cause des transactions Client > Serveur d’application > Serveur de
données > Serveur d’application > Client). Cette augmentation doit être accompagné d’une
augmentation en terme de puissance de calcul, ainsi que d’une augmentation du débit réseau.

    Pour les deux types d’architectures, on propose un mécanisme QoS (quality of service) qui va
assurer un certain niveau de qualité sur la bande passante et latence du réseau ainsi que pour les
services qui sont offerts. On va définir des SLA (Service Level Agreements) pour chaque service.




    b) Exploitation


    Pour l’exploitation de la nouvelle architecture informatique mise en place, il faut assurer un
minimum de formation aux personnels de la DSI de l’entreprise. La DSI va accompagner une
entreprise tierce pour la mise en œuvre de la solution pendant la phase de déploiement. Une fois la
solution mise en place, elle aura la responsabilité de suivre l’évolution des applications, du nombre
de transaction et la maintenance du système.

   La nouvelle architecture nécessite une formation du personnel car presque tous les applications
vont être remplaces par des modules ERP. Une formation ERP sera nécessaire et elle est envisagée a
couter cher (en termes des heures personnel et cout de formation).




                         Schéma directeur – Scénario 2                  10
Choix d’une architecture informatique                    GERARD, BOULBIT, NUNEZ, LAPADATESCU
   D. Plan de mise en œuvre

       a) Déploiement
Un ERP contient généralement trois environnements de travail :

      Un « environnement de développement » qui permet d’adapter le progiciel standard à des
       besoins spécifiques de l’entreprise.
      Un « environnement de test » qui permet de réaliser des simulations. Ces simulations
       permettent de tester de nouveaux paramétrages et de vérifier le fonctionnement correct du
       progiciel par rapport à un processus de gestion donné (une vente, un achat, une sortie de
       stock, …)
      Un « environnement de production » qui correspond au progiciel utilisé par les gestionnaires
       de l’entreprise au quotidien.

L’implémentation d’un ERP demandant de l’énergie, de l’argent et surtout du temps et afin que le
projet soit géré dans un contexte de qualité, le cycle de vie du projet se découpe en 6 phases
principales. Chaque phase est décomposée à son tour en plusieurs étapes et activités propres. Ces
phases peuvent être représentées de la manière suivante :




                         Schéma directeur – Scénario 2                 11
Choix d’une architecture informatique            GERARD, BOULBIT, NUNEZ, LAPADATESCU




                     Schéma directeur – Scénario 2          12
Choix d’une architecture informatique                     GERARD, BOULBIT, NUNEZ, LAPADATESCU
       Pour mettre en œuvre l’ERP, on évaluera d’abord les besoins de l’entreprise, associé à une
phase de réflexion afin d’appréhender le système et ses différents aspects. La phase de choix pourra
être complétée par un maquettage du produit avant d’être validé.

         Après la phase d’étude, on commence à dimensionner et préparer la plate-forme de
production. Le dimensionnement d'une plate-forme ERP commence par la détermination du nombre
et du type de module à installer, du nombre d'utilisateurs total et par module, et du niveau d'activité
(faible, moyenne ou élevée) de ces utilisateurs.

Après la phase de développement, la migration pourra avoir lieu : d’abord pour les applications qui
ne touchent pas le cœur de métier, puis seulement ensuite la migration des applications métiers.

En effet, l'expérience acquis sur les sites pilotes permettra de mieux préparer les autres
déploiements, de mieux en apprécier la charge, et d'en identifier les difficultés à-priori.

En parallèle de cette phase, devra être commencé la formation des utilisateurs pour qu’ils puissent
s’impliquer dès la migration des applications non métiers.

Enfin une phase de suivie et de maintenance conclura cette implémentation d’un ERP. Ces audits
permettront de corriger les défauts. Ces forfaits de ces journées sont inclus dans le forfait du projet
pendant les six premiers mois. Au delà de cette période de transition, toute évolution sera facturé
aux mêmes titres que du développement supplémentaire.

L’intégration est prévue sur une période de 5 ans.


 2009                 2010              2011              2012           2013             2014




                          Schéma directeur – Scénario 2                   13
Choix d’une architecture informatique                      GERARD, BOULBIT, NUNEZ, LAPADATESCU
        b) Financement
                                COUT D’INVESTISSEMENT
Architecture Applicative
Type                             Coût Unitaire (€)              Quantité                   Coût (€)
ERP                                    2 500 000                       1                 2 500 000
Outils EAI                               700 000                       1                   700 000
Workflow                                 200 000                       1                   200 000
Serveur Web                              350 000                       1                   350 000
SGBD                                     700 000                       1                   700 000
OS (Client)                                   300                   300                     90 000
                                                             SOUS TOTAL                  4 540 000
Architecture Physique
Type                             Coût Unitaire (€)                Quantité                 Coût (€)
Matériels                              2 500 000                                         2 500 000
informatiques
Installation                              500 000                                          500 000
Configuration                             500 000                                          500 000
Réseau                                    300 000                                          300 000
                                                             SOUS TOTAL                  3 800 000
Externalisation
Type                       Coût Unitaire (€)      Quantité                   Coût (€)
Etude/Sélection                           200 000                                         200 000
prestataire
Ressources humains                                            SOUS TOTAL                  200 000
Type                       Coût Unitaire (€)         Quantité            Coût (€)
Coût personnel             7000€/mois*5ans           10                  4 200 000
                                                     SOUS TOTAL          4 200 000
Formation
Type                       Coût Unitaire (€)         Quantité                Coût (€)
Formation ERP              4 000                     600                     2 400 000
Autres Formation           2 000                     600                     1 200 000
                                                     SOUS TOTAL              3 600 000




                 Total cout d’investissement                                   16 340 000 €




                           Schéma directeur – Scénario 2                14
Choix d’une architecture informatique                    GERARD, BOULBIT, NUNEZ, LAPADATESCU




                                   COUT D’EXPLOITATION
 Architecture Applicative
 Type                         Coût Unitaire (€)/an             Quantité                Coût (€)/an
 Administration (*1)            45 000/personne                     23                  1 035 000
 Licences Logicielles                   2 000 000                     1                 2 000 000
                                                            SOUS TOTAL                  3 035 000
 Architecture Physique
 Type                           Coût Unitaire (€)              Quantité                       Coût (€)
 Matériels                                 1 500                   300                        450 000
 Administration                 45 000/personne                     23                      1 035 000
 Abonnement (Net,..)        1000€/mois * 12 mois                      1                        12 000
                                                            SOUS TOTAL                      1 497 000
 Externalisation
 Type                            Coût Unitaire (€)             Quantité                       Coût (€)
 Contrat                               2 500 000                      1                     2 500 000
                                                            SOUS TOTAL                      2 500 000
               TOTAL COUT D’EXPLOITATION                                       7 032 000€

(*1) Administration applicative: 2 personnes pour module ERP (8), 2 personnes par module EAI(2), 3
personnes pour le Workflow

                                 COUT DE MAINTENANCE
 Architecture Applicative
 Type                     Coût Unitaire (€)/an     Quantité                   Coût (€)/an
 Support ERP                        15% valeur ERP                        1                  375 000
 Autres        Support           150 000€/logiciel                        5                  1 200 00
 (SGBD,OS,..)
                                                              SOUS TOTAL                    1 575 000
 Architecture Physique
 Type                              Coût Unitaire (€)             Quantité                     Coût (€)
 Matériels                                 250 000                      5                   1 250 000
                                                              SOUS TOTAL                    1 250 000
 Externalisation
 Type                       Coût Unitaire (€)                    Quantité                     Coût (€)
 Maintenance & Mise 250 000€/développement                              5                   1 250 000
 à jour
                                                              SOUS TOTAL                    1 250 000
              TOTAL COUT DE MAINTENANCE                                        4 075 000€




                            Schéma directeur – Scénario 2             15
Choix d’une architecture informatique                  GERARD, BOULBIT, NUNEZ, LAPADATESCU



                             RETOUR SUR INVESTISSEMENT
 CALCUL
 COUT D’INVESTISSEMENT                                                            16 340 000 €
 Réparti sur 5 ans                                                              3 268 000€/an

 Coûts Actuels                                                                 15 000 000€/an
 COUT D’EXPLOITATION                                                               7 032 000€
 COUT DE MAINTENANCE                                                               4 075 000€
 TOTAL Coût de notre solution                                                  11 107 000€/an
 BENEFICES
 Coûts Actuels – Coût de notre Solution                                         3 893 000€/an



          Données du ROI
                         1            2          3            4            5            6
 Investissements      3 268 000    6 536 000   9 804 000 13 072 000 16 340 000 16 340 000
    Bénéfices                  0   3 893 000   7 786 000 11 679 000 15 572 000 19 465 000




Nous obtenons donc un équilibre au cours de la dernière année et ensuite réalisons des bénéfices
régulier les années qui suivent.


                         Schéma directeur – Scénario 2               16
Choix d’une architecture informatique                       GERARD, BOULBIT, NUNEZ, LAPADATESCU
    E. Analyse des risques
Les risques concernant le choix de l’ERP sont :

       Le coût élevé de l’installation qui pourrait être plus élevé que prévu
       Les délais d’installation qui sont long et qui peut être dépassé.
       L’ERP ne couvre pas toutes les fonctions.
       La lourdeur et la rigidité de la mise en œuvre
       Les difficultés d’apprentissage par le personnel
       Le progiciel est souvent sous-utilisé, son panel fonctionnel est le plus souvent plus grand que
        les besoins de l’entreprise
       L’étendu du projet entre différents interlocuteurs qui demande une bonne coordination
       Les difficultés techniques et d’intégration avec les autres systèmes.

       Le fait tout simplement de changer le système (instabilité, risques de rejet)

    F. Politique de changement
Afin de que le projet se passe au mieux, il est prévu de découper la phase de migration en deux
parties.

D’abord de commencer par la migration des applications non-métiers. Elles sont moins sensibles et
vont servir donc de sites pilotes dans un premier temps. Il faudra donc apporter une grande
attention à leur déploiement et corriger au plus vite les erreurs réalisées. Il est donc aussi important
de prendre le maximum de temps pour réaliser à bien cette tâche.

Puis dans un second temps, on migrera les applications métiers. On se basera bien sûr sur les
résultats de la migration des applications non métiers. On pourra d’abord commencer par une
première migration puis une fois bien réaliser, les effectuer en parallèle. Ainsi le temps important
passé à la bonne réalisation du projet dans les premières migrations, sera rattrapé lors de la
migration en parallèle des autres applications.

Concernant les formations, il sera important de les commencer avant la fin des migrations. D’une
part pour gagner du temps mais aussi pour anticiper tout problème ou questions qui pourraient
survenir.

Les parties de maintenance et de suivie seront très importantes.

Elles permettront d’avoir un retour & avis constant des utilisateurs du système permettant de mettre
à jour et de corriger les erreurs de jeunesse et autres disfonctionnement relevés.

Tout devra donc être mise en œuvre pour corriger ces défauts.




                          Schéma directeur – Scénario 2                    17

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:20
posted:6/23/2011
language:French
pages:17