Master Offshoring d'Informatique Appliquée - Systèmes d'Information Avancés (PDF)

UNIVERSITE MOHAMED V –AGDAL FACULTE DES SCIENCES DE RABAT DEPARTEMENT D’INFORMATIQUE MASTER OFFSHORING D’INFORMATIQUE APPLIQUEE MODULE : SYSTEMES D’INFORMATION AVANCES Qu’est-ce qu’un Système d’information (SI)? Les systèmes d’informations sont au cœur de la gestion des entreprises et des organisations. Toute évolution d’une entreprise ou d’une organisation est assujettie à la capacité d’évolution de son SI. Le SI d’une organisation s’articule autour de cinq composantes ayant trait au stockage, traitement et diffusion de l’information, à savoir: - Les acteurs humains, - Les processus, - Les ERP, logiciels et applicatifs, - Les données (référentiels et bases des données) - Le matériel informatique (Serveurs, réseaux ,…etc.). 1 Organisation du module : URBANISAION DES SI (EA). SOA (Service Oriented Architecrure). SIA MSA (Microservices architecture). WS (Web Services). BPM(Business Process Managment). Introduction à l’urbanisation des SI L’urbanisation des SI concerne les SI des organisations (entreprises et administrations) qui manipulent plusieurs bases des données, à travers plusieurs applications et qui échangent plusieurs informations selon une architecture distribuée. L’urbanisation d’un SI désigne une démarche qui consiste à définir un SI cible qui puisse s’adapter et anticiper les différents changements dans l’organisation. Il s’agit de faire en sorte que les SI puissent évoluer au même rythme que la stratégie de l’entreprise. L’urbanisation des SI est l’équivalent francophone de l’approche « Entreprise architecture » enseignée par des universités anglophones ayant trait à la même problématique. L’urbanisation permet entre autres : - l’agilité du SI. - l’alignement du SI sur la stratégie. Urbaniser le SI d’une organisation signifie: 1 : Partitionner le SI (Zones, cartiers , ilots, blocs). 2 : Cartographier le SI (Métier :processus, Fonctions, Applications , infrastructure technique). 2 SOA(Service Oriented Architecture) - SOA est une architecture logicielle qui permet de mettre en œuvre et de concrétiser un projet d’urbanisation de point de vue logiciel. - Les deux concepts de base de SOA sont : - Les services, - Le BPM (Business process Management). - Les services et le BPM permettent d’atteindre les objectifs de réactivité et d’agilité. - SOA permet l’interopérabilité via les services. - Un service est un composant logiciel indépendant de tout système, dont l’interface est connue (publication des fonctionnalités) et qui peut être découvert.. - L’architecture SOA fait intervenir trois acteurs : - Le consommateur de service. (l’application cliente). - Le répertoire des services (publication). - Le fournisseur de service (UDDI). MSA(Les micro-services) Les applications monolithiques sont traditionnellement considérées comme des entités tout-en-un où l'ensemble de l'application est construit, testé et déployé en tant qu’un bloc de code unique (des.war en java). Les utilisateurs accèdent à l'application via l'interface d'application côté client ou la couche de présentation (MVC). Aucune application monolithique n'existe ou ne s'exécute sans dépendances - c'est simplement que la plupart du "travail" spécifique de l'application est effectué au sein d'une seule entité logicielle. Une architecture de micro-services décompose la logique métier (les fonctionnalités) d’une application en une série de services autonomes, à raison d’un micro-service par fonction. L’autonomie implique que chaque micro-service possède sa propre base des données. Les micro-services sont généralement livrés dans des conteneurs (Doker). 3 Chaque micro-service peut être développé et déployé séparément (livraison au fur et à mesure du développement). Les micro-services communiquent via des API-REST(protocole HTTP). Les utilisateurs interagissent avec l'application via une application côté client ou un portail web : l'interface distribue les demandes des clients aux services correspondants et renvoie les résultats à l'utilisateur. Les applications cloud natives (faites pour fonctionner et profiter du cloud) utilisent une architecture de micro-services. Le Web Service : WS - Un web service est un composant au sens POO qui expose des fonctionnalités sur le web en mettant en œuvre un format standard d’échange de messages, généralement XML.. - Le Web service est une technologie d’implémentation d’une SOA. - Le Web service apporte une solution standard pour la communication entre applications hétérogènes déployées sur des systèmes distribués. - Les Web service implémentent les services identifiés lors de la mise en œuvre de SOA. Les Web Service se basent sur les standards: - XML et http, - SOAP(HTTP + XML) , Simple Object Acces Protocole pour le transport des données , ou REST(HTTP , Format quelconque). - WSDL (Web service description langage) pour la description de services en XML. - UDDI Universal Description Descovry and Integration service): annuaire de référencement des services). Echange de messages XML Requête: Exécution d’une méthode. Réponse: Résultat de l’exécution. Message XML transporté via http = SOAP. 4 Outils de développement Pour la doc Bonita: https://documentation.bonitasoft.com/6.x-7.2/ www.bonitasoft.com 5 Procédure d’installation Installer JDK 8 2) Configurer les variables d’environnement JAVA-HOME et CATALINA (clic droit sur le poste de travail…variables d’environnement. 3)Télécharger et copier ECLIPSE XXX( fonctionne correctement avec java 8). 5) Télécharger et copier TOMCAT8 (C:). 6) Télécharger et installer MY SQL. On peu aussi utiliser wamp server s’il est déjà installé. 7) Télécharger AXIS 2 , déployer le.jar dans le répertoire web de TOMCAT. Pas besoin s’il est intégré à Tomcat. 8) Télécharger le pluging qui permet d’afficher tomcat dans la barre d’outil d’Eclipse. Dézipper le pluging dans le répertoire pluging d’Eclipse. 9) Configurer Eclipse pour indiquer le répertoire de tomcat (windows/Préférences/server…) et celui de java. 10) Configurer Eclipse pour indiquer le répertoire d’axis 2: windows/Préférence..). Exemple Web Service UN WEB SERVICE EST UN COMPOSANT QUI EXPOSE UNE PARTIE DE SES FONCTIONNALITES SUR LE WEB Exemple : 6 ECLIPSE Oxygène Php MyAdmin Arborescence du projet sous Eclipse 7 Déclaration des interfaces Implémentation des Interfaces public double chercherPriAch(String nomProduit) { Connection connexion = null; try { Class.forName("com.mysql.jdbc.Driver"); } catch (ClassNotFoundException e) { System.out.println("Driver introuvable"); e.printStackTrace(); } try { connexion = DriverManager.getConnection( "jdbc:mysql://localhost/bdCommerciale", "root", ""); } catch (SQLException e) { e.printStackTrace(); } try { Statement st = connexion.createStatement(); ResultSet rs = st.executeQuery("SELECT * FROM PRODUIT WHERE NOM='" + nomProduit + "'"); rs.next(); 8 double prix = rs.getDouble(3); return prix; } catch (SQLException e) { e.printStackTrace(); return -1; } } @Override public double calculerMTTC(double prix, double QuaCom, double rem, double tva) { double mttc = (double) Math.round((prix * QuaCom * (1-rem) * (1 + tva)) * 100) / 100; return mttc; } // cette méthode ne nécessite pas un accès à la base des données @Override public double calculerTTC(double prix, double tva) { double ttc = (double) Math.round((prix * (1 + tva)) * 100) / 100; return ttc; } } Création du web service(procédure automatique) Programmation coté client Accueil.jsp 9 Insert title here 10 PROJET N° I Service SOAP-Micro-service REST-BPM Objectifs du projet Créer une application de gestion des crédits avec mémorisation des contrats dans une base des données en 5 versions : V1) Les web services SOAP sous JEE -Eclipse. V2) Les micro-services REST sous Spring boot + Doker pour le conteneur. V3) Les Micro-services sous Node.js. V4) Bonita BPM sans les web services. V5) Bonita BPM avec les web services. Formule de calcul des annuités : K désigne le capital objet de l’emprunt. A désigne l’annuité mensuelle. I désigne le taux d’intérêt mensuel. N désigne la durée de l’emprunt exprimée en mois. Le système devrait permettre de: 1) Calculer l’annuité de remboursement connaissant le capital, la durée et le taux d’intérêt. 2) Calculer le capital connaissant l’annuité, le taux d’intérêt et la durée. 3) Calculer la durée connaissant le capital, l’annuité et la durée. 11 Exemple d’interface à produire (à titre indicatif) Les livrables(Version I) 1) Tous les outils de développement installés. 2) Guide complet d’installation. 3) Serveur J2EE, Clients: JSP. 4) Le workspace du projet portant le nom de l’étudiant. 5) Le rapport complet du projet: sous forme d’un tutorial avec code commenté. 6) Le tout « zippé » en format NomEtudiant.rar sur CD. 7) Le rapport en format papier. Date limite pour déposer le projet : Jeudi 10 Novembre 2016. Mode de calcul de la moyenne du module 1) Projets: 33%. 2) Contrôle urbanisation:33%. 3) Contrôle SOA:33%. 12 Partie I Urbanisation des systèmes d’information et Architecture d’Entreprise 1.1 L’informatique spaghetti A quoi on assiste actuellement en matière de SI ? Une volonté croissante d’évoluer au sein des entreprises, entravée par une capacité décroissante des SI d’évoluer. --------------------- 13 Une seule machine pour tout faire (logique métier, base des données, IHM) Un terminal passif On sous traite la partie visualisation au client. Architecture 3 tiers (client, serveur d’applications, serveur de bases des données) 14 Architecture n-tiers (+ Serveurs web) Conséquences - Le Système d’Information est de plus en plus difficile à faire évoluer - Il coûte de plus en plus cher à maintenir - Les équipes informatiques sont de moins en moins réactives Il en résulte, un système d’information monolithique, avec ses programmes et bases d’information entremêlés, interfacés de manière croisée, tel un plat de spaghetti. On ne peut refondre un programme ou changer la modélisation d’une base d’information sans des impacts nombreux, parfois mal définis sur de multiples autres modules. La notion d’informatique spaghetti (ou encore plus familièrement, de plat de nouilles) est apparue spontanément il y a quelques années lorsque les DSI ont demandé qu’on leur fasse une macro-cartographie applicative, c.à.d. un plan des systèmes et des flux. Dans la plupart des grandes entreprises ces cartes présentent un aspect similaire : un très grand nombre de boites qui représentent les applications et un nombre encore plus grand de liens qui vont dans tous les sens. Quelque soit l’ingéniosité de la représentation, les liens vont d’un bout à l’autre de la carte créant un effet visuel de spaghetti très frappant. Le problème vient d’une part du nombre de liens et du fait qu’ils vont dans tous les sens ; et 15 d’autre part du fait que la plupart de ces liens sont ad hoc et hétérogènes, allant de batch de transfert de fichiers jusqu’à des liens synchrones (requête/réponse). Une telle situation comporte de nombreux problèmes Reprise sur incident : la complexité des flux de transfert de données rend la reprise sur incident difficile. Cette difficulté est renforcée lorsque la logique correspondant à des enchainements de liens n’est pas représentée, en dehors du planning d’exploitation. Coût d’évolution : d’une façon générale dans le cas de liens ad-hoc les impacts liés à un changement applicatif se propagent sur les liens. Plus un système est lié plus il va falloir faire des modifications sur ses interfaces avec l’extérieur. Gestion de la complexité : indépendamment des coûts, la complexité des liens et de leur nature devient rapidement un facteur bloquant pour l’évolution. La réponse est souvent l’apparition de nouveaux systèmes et de nouveaux liens. Risque de ralentissement, voir de blocage : une partie des liens crée des couplages forts, en particulier les liens synchrones. Ces couplages rendent délicate la gestion des performances, puisqu’il faut prendre en compte un grand nombre de systèmes pour régler le bon fonctionnement des flux. Figure : l’informatique spaghetti CRM GESTION CLIENT PROVISIONING FIDELISATION FACTURATION LOGISTIQUE FRONTAL WEB RECOUVREMENT DATAWAREHOUSE 16 D’où la nécessité d’une nouvelle approche permettant une maitrise progressive de l’évolution des systèmes d’information à moindre coût ; une approche qui puisse s’adapter et anticiper les changements futurs dans l’entreprise : changement d’organisation, de stratégie...etc.). Une telle démarche est appelée « urbanisme du système d’information ». La mise en œuvre de l’approche est appelée « urbanisation du système d’information ». La réunion de la définition du système cible selon des règles d’urbanisme et la trajectoire à suivre pour atteindre le système cible est appelée plan d’urbanisme. L’approche donne lieu à la naissance d’un nouveau métier : l’urbaniste des systèmes d’information. Les besoins actuels : Faire évoluer le Système d’Information - L’ouvrir à l’extérieur (clients, partenaires, fournisseurs) - Améliorer son évolutivité (technique et organisation) - Améliorer sa fiabilité. Ici le système d’information urbanisé : on y distingue des sous ensembles indépendants (couplage faible) communiquant uniquement à travers leurs interfaces. Dans une telle architecture, on peut envisager la refonte d’un sous système que ce soit pour adopter de nouvelles technologies ou pour répondre à un besoin fonctionnel nouveau. Du moment que les interfaces avec les autres sous-systèmes sont préservés, le périmètre de la refonte est maitrisé. En résumé, les qualités souhaitées d’un SI performant sont : L’adaptabilité : Développer la capacité du SI à être indépendant de l’organisation. L’interopérabilité : Offrir la capacité à échanger des informations en interne et externe. La modularité : Développer la capacité à faire évoluer une partie du système informatique de manière indépendante des autres parties. L’évolutivité : Développer la capacité à faire évoluer les priorités dans la rénovation des SI. La sécurité : Garantir la confidentialité, la disponibilité, l’intégrité, l’auditabilité et la traçabilité. 17 La maintenabilité : Offrir la capacité de maintenir un composant sans bouleverser la conception du SI existant. La capacité d’intégration : Développer la capacité d’intégrer un progiciel, un nouveau système au SI en trouvant le meilleur équilibre entre les besoins exprimés et la solution proposée. La Visibilité en termes de gestion des évolutions : Organiser les travaux de développement au sein de la maitrise d’ouvre. La pérennité : Augmenter la durés de vie du SI sans tout reprendre à chaque changement de technologie. 1.2 Problématique et terminologie de l’urbanisation des SI. Problématique de départ de l’urbanisation des villes : Comment reconstruire, moderniser, comment profiter à bon escient des avancées technologiques sans faire table rase du passé, dans les limites de coûts maitrisés, tout cela en maintenant la vie dans la cité. 18 ETUDE DE CAS : TOUR-OPERATEUR L’organisation du tour opérateur est articulée autour des directions suivantes : - La direction générale ; - La direction financière ; - La direction Marketing ; - La direction organisation - La direction commerciale - La direction d’exploitation ; - La direction des ressources humaines. Enfin, l’organisation inclut le service informatique, rattaché à la direction financière. La direction commerciale s’organise autour d’un réseau d’agences de voyages exclusives. Il existe 211 agences répartis dans le monde entier. Elles ne proposent pas de produits commercialisés par d’autres tour-opérateurs. Il existe en moyenne dix agences par pays concerné dont une agence principale. La direction d’organisation est chargée de concevoir et d’organiser chaque voyage et présente tous ces voyages dans un catalogue. Les voyages sont uniquement vendus aux clients par les agences faisant partie de la direction commerciale. La direction financière est responsable de toute la comptabilité de la société, et gère les paiements échelonnés dans le cas de clients ne désirant pas payer immédiatement. La direction commerciales est chargée de diffuser toutes les opérations promotionnelles auprès des médiats et de la publication des catalogues. Afin de simplifier cette étude de cas, le volet gestion des villages de vacances et/ou des hôtels est exclu du périmètre de l’étude de cas. PRESENTATION GENERALE DES VOAYAGES Les voyages sont organisés dans le monde entier. Il y a trois types de destinations : la mer, la montagne et les villes touristiques. A chaque endroit trois types de logements peuvent être offerts : hôtel, bungalow ou résidence. Il est évident que tous les modes d’hébergement ne sont pas disponibles à chaque endroit. Tous les voyages proposent plusieurs activités. La liste des activités disponibles dans un voyage se limite à l’ensemble ou une partie des activités suivantes : natation, plongée, tennis, golf, voile, ski nautique, escalade, parachutisme en chute libre, ski et vélo tout terrain. La direction d’organisation peut décider d’allonger cette liste. La durée d’un voyage est fixée à une semaine ( toute la semaine au même endroit dans le même hébergement). Un client qui désire rester plus longtemps peut bien sûr réserver plusieurs semaines, mais le prix ne sera pas dégressif pour autant. Le prix comprend le voyage d’un point donné ( qui peut être un aéroport, une gare ferroviaire, une gare routière ) jusqu’au lieu d’hébergement (transport inclus), le prix de la location, les activités libres, le retour du lieu d’hébergement à la gare de départ. 19 Les prix sont adaptés et fixés pour quatre périodes (une par sison : hiver, printemps, été, automne). Il existe un prix de référence à partir duquel le prix réel de chaque voyage est calculé ( un voyage = une semaine pour une personne). Un client peut demander de payer son voyage immédiatement ou par versements échelonnés. LA DIRECTION D’ORGANISATION La direction organisation a deux responsabilités : - La gestion en temps réel du voyage : hébergement disponibles, état actuel des réservations, enregistrement des demandes de réservation, etc. ; - L’organisation générale d’un voyage : création d’un voyage, choix de l’hébergement, organisation des activités ; …etc. et, parallèlement, tous les points de négociation tels que les prix à fixer avec les compagnies aériennes, les hôtels, etc. Chaque agence reçoit de la direction d’organisation chaque jours un Fax indiquant le nombre de places disponibles, ce qui permet aux vendeurs de connaître le nombre de place encore libres lorsqu’ils s’entretiennent avec les clients. Le service dispose d’un système informatique central et d’un standard téléphonique relativement important, composé de 80 personnes. Ces personnes sont capables de répondre aux demandes de toutes les agences, par exemple le nombre de places disponibles en matière d’hébergement pour un voyage proposé à une date donnée, etc. Elles sont également responsables des demandes de préréservations émanant des agences de voyage (réservation temporaire : attribution d’une référence de préréservation), ce qui implique la mise à jour de l’état des réservations et la gestion des places disponibles. Les renseignements nécessaires à l’enregistrement d’une préréservation sont les informations de base à savoir l’identification de l’agence, l’identification des vacances et du lieu (référence de l’hébergement). Tous les détails relatifs à la réservation d’un voyage sont gérés par la direction financière (identification du client, prix, mode paiement, etc.) La direction organisation reçoit de la direction financière la commande permettant de procéder à la réservation définitive. Toutes les vacances sont décrites dans un catalogue édité par la direction marketing, conformément aux informations transmises par la direction organisation. La direction organisation soumet à la direction générale toute proposition visant à étoffer la structure actuelle des vacances : - Ajout de nouveaux pays au catalogue ; - Nouveaux sites dans les pays existants. La direction organisation applique les décisions prises par la direction générale. LA DIRECTION MARKETING 20 Deux fois par an, la direction marketing édite un catalogue présentant les voyages existants. Ce dernier est adressé à chaque agence de voyage et aux clients dont l’adresse est connue du siège du tour-opérateur. Le catalogue offre une description attractive et des photographies de tous les voyages, présente les destinations, l’hébergement et les activités proposées. Un supplément indiquant les prix est publié chaque trimestre. Le catalogue et le supplément tarif peuvent être distribués aux clients ou utilisés par les vendeurs à l’agence de voyage. Selon les informations transmises par la direction organisation, la direction marketing conserve ou non le catalogue en l’état. Par exemple, il peut remanier la description d’un voyage, remplacer une photographie par une autre, ajouter des chambres dans un lieu donné, y organiser de nouvelles activités, etc. LA DIRECTION FINANCIERE A l’exception de la paye des employés, la direction financière gère tous les flux financiers et en particulier les paiements effectués par les clients. Ce service dispose déjà d’un système informatique pour le traitement de ses opérations, mais il n’est pas relié au système de la direction d’organisation. La direction financière dispose aussi d’une liste noire des mauvais payeurs. Ce service est responsable de tous les aspects financiers d’un voyage : - Acceptation de paiements différés et de tous payements analogues ; - Gestion des payements immédiats. Dans le cas d’une demande de payement échelonné, un dossier est transmis par l’agence de voyage, fournissant toutes les informations requises : identification du client, description des références de préréservation, prix, etc. Ensuite la direction financière consulte la liste noire. Si le client remplit les conditions, le payement échelonné est accepté et les informations sont envoyées à la direction organisation afin de procéder à la réservation définitive des vacances. La direction financière dispose d’un délai maximal de huit jours pour donner sa réponse, soit à l’agence de voyage, soit au client directement, à savoir accepter ou refuser sa demande. Un paiement échelonné s’effectue sur six mois quelque soit le montant du voyage. La fin du voyage correspond au début du remboursement. Chaque paiement (immédiat ou échelonné) est associé à une échéance. Dans le cas d’un paiement immédiat il existe deux dates clés : - Acompte pour toute préréservation ; - Solde d’une réservation au plus tard huit jours après versement de l’acompte. Dans le cas d’un paiement échelonné, il existe sept échéances : - La premier lors de l’acompte versé ; 21 - Les six suivants par versement mensuel, à partir du mois suivant la fin des vacances. Chaque échéance donne lieu à une facture adressée au client. En matière d’acompte, la responsabilité en incombe à l’agence de voyage (établissement immédiat de la facture). Dans ce cas le formulaire de réservation sert également de facture. Pour toutes les autres échéances, la direction financière adresse directement la facture au client. Un acompte est encaissé par une agence de voyage ; tout autre type de paiement est recouvré par la direction financière. L’acompte correspond à au moins 10% du prix du voyage. Si le client demande un paiement échelonné mais ne remplit pas les conditions, sa demande est rejetée et il n’a pas d’autres solutions que de payer la totalité du prix. Dans le cas contraire, l’acompte est remboursé au client à l’exception des frais de dossier (2% du prix du voyage) , et la préréservation est annulée ( envoie des informations correspondantes à la direction d’organisation). La même règle s’applique à un paiement immédiat : si le client paie immédiatement (acompte) mais ne règle pas le solde dans un délai de huit jours à compté du versement de l’acompte, ce dernier est remboursé au client, à l’exception des frais de dossier, et la préréservation est annulée (envoie des informations correspondant à la direction organisation). La direction financière est chargée de rembourser les clients. L’AGENCE DE VOYAGE Un vendeur aide un client à choisir son voyage, en consultant le catalogue et en fonction de plusieurs paramètres, à savoir le pays, la saison, le choix de la destination, le type d’hébergement, le niveau de confort, le nombre de personnes, le prix, etc. Une fois que le client a choisi un voyage, il peut demander un devis et/ou une préreservation (réservation temporaire). Pour faire une préreservation, le vendeur doit téléphoner à la direction organisation pour avoir confirmation de la disponibilité du voyage demandé, puis effectuer la préréservation. Cette dernière est enregistrée dés paiement de l’acompte par le client. La réservation devient définitive lorsque le client liquide la totalité due. Le client peut demander de payer ses vacances immédiatement ou par paiement échelonné. Dans le premier cas, il verse d’abord un acompte (au moins 10% du prix total) et paie le solde dans un délai de huit jours, sous peine d’annulation de la préréservation. La réservation définitive est effectuée seulement après le paiement de la totalité. Si un client choisit de demander un paiement échelonné, le vendeur ouvre un dossier correspondant et demande des informations au client ( Adresse, profession, revenu mensuel, copie du dernier bulletin de salaire, etc.) Après paiement de l’acompte, le vendeur envoie le dossier (par poste) à la direction financière. Cette dernière retourne immédiatement une réponse à l’agence ou au client concerné. 22 Dans tous les cas, le client verse directement l’acompte à l’agence de voyage, mais doit envoyer lui-même le solde ou tout autre paiement à la direction financière située au siège social de la société. Il est possible d’effectuer un acompte en utilisant tous les moyens de paiement (liquide, carte bancaire, chèque) mais tous les autres paiements sont effectués par chèque. Un acompte est toujours perçu par l’agence, tous les autres paiements sont toujours perçus par la direction financière. Un formulaire de réservation est donné au client lors du paiement de l’acompte et sert également de facture. Les 211 agences réparties dans 22 pays concernés se répartissent en 22 agences principales et 189 petites agences. Ces agences principales sont dotées de compétences informatiques, ce qui n’est pas le cas des petites agences. Le directeur de l’agence principale de chaque pays effectue de études statistiques sur les ventes dans son pays qu’il transmet régulièrement à la direction financière une fois par semaine. Les horaires d’ouverture des agences sont 9H/12-14h/19 avec une pointe d’activité entre 18h et 19 heures de 20% par rapport aux autres heures de la journée. Le temps consacré par le vendeur à chaque client varie de vingt minutes à une demi-heure. En moyenne 42 demandes client sont traitées par jour en agence principale. LES RESULTATS FINANCIERS Le tour opérateur est l’un des principaux acteurs dans son secteur d’activité. Numéro un il y a deux ans, il se trouve maintenant à la deuxième place et continue à perdre des parts de marché. Les résultats financiers sont résumés dans le tableau suivant : 2004 2005 2006 2007 2008 2009 Chiffre d’affaire (M$) 183 213 259 297 270 250 Nombre de 390 468 565 643 610 580 réservations (en milliers) Bénéfice avant impôt 360 43 51,5 60 57,5 52 Le PDG du tour –opérateur a été interrogé sur les principaux problèmes relatifs au système actuel de réservation. Il nous livre sa réflexion en la matière : A l’heure actuelle, lorsqu’un client entre dans une agence, il fait une réservation dans 68% des cas. Ce taux de transformation des contacts en réservation est faible par rapport à la concurrence. Environ 8% des réservations que nous recevons ne peuvent être satisfaites parce que nous n’avons plus de places pour les voyages demandés. Il serait possible de diminuer ce taux si nous connaissions en temps réel les voyages non réservés, car dans ce cas, nous serions à même d’orienter le choix du client vers un voyage disponible. L’impact de la diminution de ce taux 23 aurait des effets significatifs car nous savons que, lorsqu’une première demande ne peut être satisfaite, il existe une probabilité de 20% pour que les clients quittent l’agence sans faire d’autres choix. Dans l’agence le vendeur est submergé par les tâches administratives (envoie réception de Fax et lettres) ce qui crée des filles d’attente dans l’ensemble de nos bureaux de vente. Cette attente provoque la perte de plusieurs ventes parce que certains clients n’aiment pas du tout attendre. Un vendeur doit appeler le standard de notre direction organisation pour s’informer de la disponibilité des voyages au catalogue et procéder à une préréservation. Ce qui signifie que les agences sont tributaires des jours et des heures d’ouverture du standard central. Une plus grande souplesse est nécessaire, permettant aux agences de choisir leurs heures et jours d’ouverture selon la culture et les nécessités locales. Certains coûts sont très élevés tels ceux des télécommunications. Il serait possible d’améliorer notre image en offrant aux clients comme nos concurrents un accès internet pour notre catalogue. Nous devons également tout en préservant notre réseau d’agences exclusives qui est et restera pendant longtemps notre canal de distribution de base, nous ouvrir à de nouveaux canaux de distribution et faire vendre nos produits par des tiers. Nous devons aussi améliorer notre rentabilité en vendant des produits de tiers complémentaires. Enfin nous pourrions améliorer notre cash-flow si nous accélérions notre facturation. 24 1.3 Le POS : Le Plan d’occupation du SOL En termes d’urbanisation des cités : Il s’agit d’un document d’urbanisme, en général à l’échelle d’une commune, fixant les règles générales d’utilisation du sol qui s’imposent à tous. Dans les nouvelles lois d’urbanisme le terme POS est remplacé par PLU (Plan Local d’Urbanisme). En termes de système d’information : Le POS du système d’information de l’entreprise fixe les règles d’utilisation des espaces du système d’information. En termes d’urbanisation des cités : Il s’agit de définir de façon précise les droits attachés à chaque parcelle, mais aussi d’organiser le tissu urbain en définissant la destination des constructions, les densités et éventuellement les formules applicables ; de localiser les emplacements réservés pour la réalisation d’équipements et de protéger les espaces naturels ou agricoles. En termes de système d’information : Il s’agit de définir de façon aussi précise que possible les services et les responsabilités attachés à chaque sous ensemble, mais aussi d’organiser globalement le SI en définissant : - L’objet, en quelque sorte, la mission des applicatifs le composant ; - Les regroupements d’applicatifs en ensemble cohérents ; - Les périmètres réservés aux futurs applicatifs à construire, notamment pour les applicatifs transversaux. Le POS doit être non seulement compatible, mais être aligné sur la stratégie de l’entreprise (les scénarios les plus probables d’évolution des besoins métiers) 2 Les zones L’urbanisme des villes propose d’abord une décomposition en zones, puis en quartiers et enfin en îlots. Au même titre, l’aspect majeur du POS d’un SI est le découpage du système d’information en zones, quartiers et îlots localisés localement par une cartographie. S’agissant de la décomposition d’un SI en zones, on distingue : - La zone d’échange : qui gère toutes les acquisitions /restitution du système d’information vis-à-vis de l’environnement extérieur. - La zone gisement des données : qui reprend l’ensemble des informations dynamiques et pérennes de l’entreprise ainsi que les services d’accès à ces données et assure la conservation et la valorisation du patrimoine d’information de l’entreprise, garantit sa cohérence et permet son enrichissement dans le temps. - La zone « référentiel des données » de l’entreprise : qui regroupe l’ensemble de toutes les informations communes aux différents éléments du SI dont le cycle de vie est relativement stable. 25 - La zone décisionnelle : qui regroupe les blocs dédiés aux processus de pilotage de l’entreprise ou de l’organisme et d’analyse. - Les zones opérations : En général, on trouve une zone opérations par métier principal de l’entreprise. - Une zone ressources : qui regroupe les systèmes dédiés à la gestion des ressources internes de l’entreprise. 3 Le quartier Le quartier du système d’information est une fraction d’une zone qui est elle-même une fraction du système d’information. Un quartier est un groupement d’îlots et regroupe des composants homogènes quand à la nature de l’information traitée. Un quartier va typiquement correspondre à ce que l’on appelle communément un sous-système. Le quartier du système d’information est donc comme le quartier de la cité, doté d’une physionomie propre et caractérisé par des caractéristiques distinctives lui conférant une certaine unité et certaine individualité (couplage faible et cohérence forte). 4 L’îlot (ou le bloc) En terme d’urbanisme de cité, l’îlot représente la plus petite unité de l’espace urbain, entièrement délimité par des voies (souvent appelé pâté de maisons). En dessous de l’îlot on trouve on trouve des parcelles correspondant à des entités atomiques (terrain nu, maison, immeuble, villa,…etc.). L’îlot est aussi le plus petit niveau de décomposition d’un système d’information (dans le cadre d’un projet d’urbanisation) Entité remplaçable du système informatique susceptible d’être développée ou achetée séparément. Un îlot recouvre une activité, correspond à des traitements et des accès à des données pour cette finalité. Les traitements au sein de l’îlot sont effectués indépendamment du chemin suivi par l’information. Un îlot émet des résultats normalisés exploitables par d’autres îlots. Un îlot va typiquement correspondre à : - Une application ou une grande fonction applicative (développement spécifique) 26 - Un progiciel ou un module du progiciel. 5 Le bloc Selon les auteurs, le terme bloc désigne communément une zone, un cartier, ou un îlot. Exemple I: Cas du SI système d’information d’une banque Zone : Production bancaire Quartier : gestion des crédits Îlot : gestion des crédits immobiliers Bloc : bloc fonctionnel gestion des impayés. Exemple 2 : Cas d’une entreprise commerciale Zone : Gestion des clients Quartier : gestion commerciale Ilot : gestion des commandes Bloc : gestion des commandes urgentes. 27 Exemple II : Identification de Zones Ici, nous avons un ensemble de services qui communiquent les uns avec les autres, et nous constatons tout de suite les problèmes d’échanges de flux et de redondances… La démarche prévoit de séparer ces services et de les regrouper suivant des domaines fonctionnels (Zones). Ainsi, nous obtenons : 28 1.3 Autres aspects de l’urbanisation 1. Règles d’urbanisme Une règle d’urbanisme est une règle à respecter et figurant au POS du système d’information : - Certaines sont des interdictions : par exemple, il est interdit d’accéder à un bloc sans passer par sa prise. - Certaines sont des règles ou des limitations. Par exemple une donnée doit être sous la responsabilité d’un et un seul bloc. - Certaines sont des prescriptions. Par exemple, tout bloc doit comporter une prise. Exemples de règles régissant les blocs: 1) Un bloc encapsule données et traitements dont il est propriétaire. 2) Une donnée ne peut être modifiée que par un bloc. 3) Les blocs communiquent entre eux par des messages via la zone gestion des flux. 4) Un bloc peut évoluer ou être remplacer sans impact sur les autres blocs. 29 Urbanisation et référentiels 2. Procédure d’élaboration du POS Elle comporte typiquement les étapes suivantes : - Elaboration et diffusion d’une note de lancement ; - Rédaction du plan d’assurance qualité de l’étude ; - Réalisation de l’étude ; - Validation du POS par le comité de pilotage de l’étude ; - Validation par le comité de direction du SI. 3. Le contrôle du respect du POS En termes d’urbanisation de la cité, le contrôle du respect du POS repose essentiellement sur deux dispositifs : Le permis de construire, le permis de démolir. Ces deux notions sont utilisées pour contrôler le respect du POS d’un SI. 4. L’infrastructure L’infrastructure désigne l’ensemble des installations réalisées au sol ou en souterrain permettant l’exercice des activités humaines à travers l’espace. Elles comportent notamment : - Les infrastructures de transport : voirie et stationnement, chemin de fer et métro, rivières, canaux, ports, aéroports…etc. - Les réseaux divers (eau, assainissement, électricité, gaz, téléphone) ; - Les espaces collectifs aménagés (parcs, jardin, Terrain de sport…etc.) L’équivalent en SI est l’infrastructure technologique du système d’information qui représente l’ensemble des installations de matériels et de logiciels réalisés pour permettre aux applications informatiques automatisant les processus de s’exécuter dans des conditions satisfaisantes. Elles comportent notamment : 30 - Les réseaux locaux ou longue distance ; - Les plates-formes matérielles ; - Les logiciels de base ; - Etc. 5. La cartographie : un outil de base La cartographie est l’étude intervenant à partir des résultats d’observations ou de l’exploitation de documentation en vue de l’élaboration et de l’établissement de cartes, plans ou autres modèles d’expression, ainsi que de leur utilisation (voir démarche d’urbanisation des SI). Les cartographies sont au cœur de la démarche à suivre pour un projet d’urbanisation d’un système d’information ; elles permettent : - De maitriser et piloter le système d’information, - De modéliser les cibles, - De faciliter les études d’impact, - D’améliorer la maitrise des coûts informatique. Pour construire une cartographie, il faut : - Respecter les notions de zones, quartiers, et blocs. - Respecter les règles de l’urbanisme informatique. 1.3 La démarche d’urbanisation des SI La popularité du concept d’urbanisation a été telle entre 2000 et 2002 qu’il a été fréquent de confondre le concept avec la stratégie informatique. Urbaniser permet de : - Fédérer les briques d’un système d’information existant autour d’une architecture d’ensemble et de principes qui lui permettront d’acquérir la souplesse et la réactivité nécessaire pour s’adapter aux contraintes du marché ou de l’environnement. - Gérer la prise en compte rapide et efficiente par le système d’information ainsi urbanisé des demandes d’évolution critiques, par une approche rationalisée. - Faire porter les efforts de développement sur les nouvelles fonctionnalités à forte valeur ajoutée et de réutiliser en majeur partie le système existant. - La mutualisation des composants fonctionnels et techniques par : la mise en œuvre de référentiels partagés ; le déploiement d’une infrastructure d’échange (l’EAI, le WEB service) ; la mise en œuvre progressive d’une approche orienté services (SOA : Service Oriented Architecture). 31 La démarche d’urbanisation propose de passer d’un système d’information existant à un système cible par paliers successifs correspondant à des états stables. Cette approche peut être mise en opposition avec une approche plus radicale consistant à remplacer un système existant. La démarche se base sur un cadre de référence distinguant quatre visions du système d’information chacune donnant lieu à une architecture. Cartographie urbanisée du SI Stratégie Stratégie : objectifs métier ; objectifs SI Métier : processus, activités ; tâches ; actions Métier Système Fonctionnelle: zone, quartier, îlot, bloc d’information Application : blocs applicatifs Système informatique Technique : infrastructure technique + sys Informatique Technique - La vision métier, avec la cartographie métier qui décrit l’ensemble des activités que le système d’information doit supporter. L’architecture métier qui en résulte est une structuration du SI par les activités métiers de l’entreprise vis-à-vis de ses processus. La description de ces activités peut se faire à partir des processus métiers. De point de vue pratique, la vision métier du SI, se traduit par un ensemble de cartes qui représentent : - La liste des processus métiers, - Le lien entre les processus métiers, - La modélisation des processus. Ces cartes sont établies pour le système existant et le système cible (voir étude de cas) 32 Exemples - La vision fonctionnelle, qui décrit les fonctions du système d’information permettant de supporter les processus métiers. L’architecture fonctionnelle qui en résulte est une structuration du SI en blocs fonctionnels communiquant. Il est important, lors de la cartographie fonctionnelle, de faire apparaitre les liens entre les zones, quartiers, îlots, et les activités métiers qu’ils assurent. De point de vue pratique, la vision fonctionnelle du SI, se traduit par un ensemble de cartes qui représentent : - L’architecture fonctionnelle du SI existant (Zones, quartiers, îlots ou blocs). - L’architecture fonctionnelle du SI cible (Zones, quartiers, îlots ou blocs). Exemples de fonctions (Etude de cas agence bancaire) - Ouverture de compte bancaire en dirhams, - Gestion des comptes bancaires en devise, - Gestion des achats et ventes de devises, - Gestion des traites et effets de commerce, - Gestion des cartes magnétiques, - Gestion des chéquiers, - Gestion des crédits, - Virement bancaire, - Prélèvement automatique, - Gestion des comptes bloqués, - Gestion des comptes courants, - Gestion des comptes d’épargne, - La vision applicative, qui décrit l’ensemble des éléments applicatifs d’un système informatique. L’architecture applicative qui en résulte est une structuration du système d’information en blocs applicatifs communiquant. De point de vue pratique, la vision applicative du SI, se traduit par un ensemble de cartes qui représentent : 33 - L’architecture applicative du SI existant (Zones, quartiers, îlots ou blocs). - L’architecture applicative du SI cible (Zones, quartiers, îlots ou blocs). Exemple : Etude de cas Tour Opérateur Cartographie de l’architecture applicative de l’existant : Cartographie de l’architecture applicative du système cible - La vision technique qui décrit l’ensemble des matériels, logiciels, de base et technologies utilisées. L’architecture technique qui en résulte est une structuration des moyens d’infrastructure technique à mettre en œuvre pour informatiser l’activité de l’entreprise. Remarque : De point de vue pratique, la vision stratégique de l’entreprise se traduit par une cartographie sous forme : - Un diagramme d’Ishikawa des objectifs du système d’information 34 - Un diagramme d’Ishikawa des objectifs stratégiques métiers. - Un diagramme de l’entreprise (Existant et futur). 35 L’opération d’urbanisation va consister à réorganiser un système informatique où les frontières entre blocs ne sont pas effectives, pour rendre ce système informatique modulaire et capable d’évolution. Pour cela on s’appuie sur deux idées forces inspirées de l’orienté objets : - Le concept de macro-objet : un bloc est propriétaire de ses données et de ses traitements, c.à.d. que les structures internes des données et des traitements sont masquées pour les autres blocs. Un bloc ne peut accéder aux données encapsulées dans un autre qu’en faisant appel aux services que propose celui-ci. - L’idée de cohérence forte/couplage faible : il s’agit de définir des blocs pour lesquels les données et les traitements présentent une forte cohérence, c.à.d. des relations fortes (exemple des relations d’intégrité fonctionnelles) et un couplage faible c.à.d. une frontière bien délimité avec les blocs connexes (par exemple les données du bloc propriétaires n’ont aucune relation avec les données des blocs annexes). Une séparation du système d’information en blocs possédant ces caractéristiques permet de : 36 - Limiter la portée des maintenances en cas de changement de structures des données. - Rendre neutre vis-à-vis du système d’information une modification dans les traitements d’un bloc. - Rendre possible une refonte progressive total ou partiel du système d’information. L’urbanisation future consiste à concevoir une architecture applicative (zones, quartiers, îlots ou blocs) supportée par l’architecture technique adaptée (centraux, serveurs, postes, réseaux) et cohérente avec l’architecture métier, elle-même alignée sur la stratégie de l’entreprise. Lors de l’urbanisation d’un SI, il est recommandé de mettre en œuvre les mécanismes d’historisation (conserver une copie des éléments modifiés ou supprimés) et de traçabilité (conserver des traces des motifs qui ont donné lieu à une modification ou une suppression). Un système urbanisé comporte des blocs de plus ou moins grosse maille, dont les frontières sont imperméables et qui communiquent entre eux par échange de messages. Urbaniser un système d’information consiste à : élaborer une cartographie du SI ; établir des règles d’urbanisation, la mise en conformité du système existant ; la gestion des besoins d’évolution. 1.4 La normalisation des échanges (Point à Point, EAI, ESB et WEB service) La normalisation des échanges et des interfaces est fondamentale, le point central de cette normalisation est le modèle des données des échanges. Au lieu d’utiliser pour chaque lien un modèle qui est le dénominateur commun de la paire de systèmes qui sont entrain de faire un échange sur ce lien, l’urbanisation requiert de construire le modèle qui permet d’unifier, de décrire dans un langage commun, l’ensemble des échanges. Ce modèle n’est pas forcement compatible avec l’ensemble des systèmes existant. Au contraire, il doit être le plus pérenne possible et ne pas être modifié lorsqu’un des composants est remplacé par un autre. L’urbanisation repose par ailleurs sur l’urbanisation technique des échanges en introduisant un ou plusieurs bus logiciels. Ces composants de communication contenus dans la plupart des offres EAI, vont prendre en échange les liens entre les composants. L’objectif évident de cette approche est de remplacer pour chaque composant un ensemble de liens par un seul connecteur sur le ou les bus, appelé adaptateur. 1.4.1 De l’intégration « ad hoc » aux ESB Du début des années 90 à aujourd’hui, on peut identifier trois approches d’architecture d’intégration successives : · L’intégration « ad hoc » mettant en œuvre des middlewares (inter logiciel) plus ou moins propriétaire sans approche méthodologique spécifique, 37 · L’approche EAI, apparue à la fin des années 90, basée sur une approche de rationalisation des flux d’information dans l’entreprise a permis l’émergence de l’approche orientée services, mais reposait sur des technologies propriétaires de chaque éditeur qui limitaient l’interopérabilité, · L’approche ESB, qui reprend les principes de l’approche EAI, en se basant sur des standards. 1.4.2 L’architecture point à point Au début des années 1990, les connecteurs et les protocoles de transport n’étaient pas basés sur des standards : ils étaient spécifiques à l’interaction entre deux applications et nécessitaient souvent des développements spécifiques. La plupart des échanges entre applications se faisaient avec des fichiers non structurés, avec tous les risques d’erreurs que cette solution basique peut engendrer. Ce type d’intégration a donné lieu à des architectures dites « accidentelles », résultant d’un amalgame de connexions propriétaires hétérogènes, comparable à un plat de spaghettis, construites au fur et à mesure de l’intégration de nouvelles applications dans le SI. L’évolution d’une telle architecture est évidement très coûteuse. En effet, l’intégration d’une nouvelle application dans ce contexte d’architecture, nécessite la réalisation d’une connexion spécifique pour chaque application interagissant avec cette nouvelle application. De plus, il est très difficile d’avoir une vision, pour un processus métier donné, des flux d’informations qui circulent dans l’entreprise. 1.4.3 La technologie EAI Une architecture d’intégration efficace est une architecture où chaque application est connectée au « système » de façon indépendante et unique, sans avoir de connaissances a 38 priori de la topologie du système d’information global. Une telle application obéit aux ordres du « système », en traitant des tâches et en retournant des informations. Avec ce type d’architecture, le système d’information de l’entreprise devient agile dans le sens où il peut être modulé de façon simple, les ajouts, modifications ou suppressions d’applications n’ayant pas d’impact sur le reste du domaine. C’était la promesse des produits d’EAI apparus au milieu des années 90. Un EAI peut être vu comme un cœur, auquel chaque application se connecte de façon indépendante. Voici un schéma de principe de l’architecture d’un EAI : L’EAI propose les fonctionnalités suivantes : · Transport des données (Couche transport) L’EAI fournit une couche de transport homogène sur laquelle vont pouvoir s’appuyer les applications. Cette couche de transport est généralement un MOM (Message Oriented Middleware) propriétaire. · Connexion entre applications (Couche broker) Chaque application se connecte à l’EAI de façon indépendante, au travers d’un connecteur. L’EAI met en relation les connecteurs de deux applications données de façon interne et transparente. Un connecteur contient toute la logique technique de connexion à l’application. Des connecteurs vers les principaux progiciels du marché sont en général disponibles auprès des éditeurs d’EAI, la réalisation d’une connexion avec une application propriétaire étant à 39 développer spécifiquement. Le connecteur gère généralement l’authentification, les transactions, les droits d’accès, etc. Ainsi, une application n’utilise plus qu’une seule connexion unique avec l’EAI pour communiquer avec le reste des applications. · Transformation des données (Couche broker) Les données transmises d’une application à une autre ne sont pas comprises de la même façon, et n’ont que rarement la même structure. L’adresse d’un client sera par exemple représentée sur un seul champ dans une application, mais sera séparée en plusieurs champs dans une autre (rue, ville, code postal, …). · Orchestration des processus métiers (Couche BPM) Les outils d’EAI sont généralement couplés à des outils de BPM (Business Process Management) qui automatisent les processus de l’entreprise. On définit alors les échanges entre les différents départements de l’entreprise. Par exemple, la prise d’une commande d’un client entraîne une communication entre le service de commande, de gestion des stocks, de facturation, etc. · Autres services techniques L’EAI fournit aussi d’autres services transversaux comme le monitoring des données, un référentiel des applications connectées et des informations manipulées par ces applications. L’EAI simplifie l’architecture du SI d’une entreprise, et fluidifie les échanges d’informations. Cependant, le principal reproche que l’on peut cependant faire aux outils d’EAI est leur aspect propriétaire. La logique d’intégration d’un EAI étant propriétaire, les éléments de l’outil (connecteurs, transformateurs de données, orchestration des processus) ne sont pas standardisés, ce qui lie ’entreprise à l’éditeur qu’elle aura choisi, avec les conséquences que l’on connaît (coût du conseil et des interventions, pérennité de la solution, etc.) Chaque EAI ayant sa propre plateforme d’intégration, la communication entre deux entreprises utilisant des EAI différents repose sur le support de standards d’interopérabilité. De plus en plus, les éditeurs d’EAI offrent des connecteurs standardisés, en utilisant principalement des technologies comme SOAP (Simple Object Access Protocol) ou les services web 2. 40 Bien souvent, les produits d’EAI sont mis en œuvre dans des architectures de type HUB and SPOKE (tous les messages sont transmis via des connecteurs (SPOKE) aux HUB, point central ou ils sont ensuite triés), en centralisant toute la logique d’intégration. Ceci introduit un « single point of failure » dans le système d’information, dans le sens où si la plateforme de l’EAI s’arrête, plus aucune application ne peut communiquer, et tous les processus métiers sont stoppés. Ceci oblige à concevoir des solutions EAI hautement disponibles, avec un coût d’autant plus important. 1.4.4 L’émergence des ESB Les standards J2EE et Web Services ont profondément modifié le paysage de l’intégration. Ainsi, de nouveaux produits basés sur ces standards émergent depuis deux ans sous le nom d’Enterprise Service Bus. Ces produits peuvent être vus comme des supports à une implémentation concrète d’une SOA, et sont basés principalement sur des standards comme XML et les Web Services. Les ESB reprennent les grands principes de l’EAI, mais l’utilisation poussée de standards rend leur coût de licence beaucoup plus abordable. Comme avec les EAI, l’intégration des applications du SI d’une entreprise au bus ESB peut se faire de façon incrémentale. La réalisation de la communication avec les partenaires de l’entreprise en mode B2B (Business to Business) se trouve simplifiée grâce à la mise en œuvre de standards reconnus par tous. Définition Un « Enterprise Service Bus » est une solution d’intégration implémentant une architecture totalement distribuée, et fournissant des services comme la transformation des données ou le routage basé sur le contenu (CBR), ainsi qu’une interopérabilité accrue par l’utilisation systématique des standards comme XML, les Web Services et les normes WS-* (ensemble de normes propres au web service). L’ESB est une solution packagée qui permet de mettre en œuvre la SOA (voir la seconde partie de ce cours). 41 1.4.5 Les Web services L’architecture des services WEB (technologie récente et révolutionnaire initiée par IBM et Microsoft) propose le transport de services et de la réponse, entre un client et un serveur tout deux connectés au WEB. Dans cette architecture le client du service peut être un navigateur WEB (acteur humain) ou bien une application (la demande de service est alors issue d’un programme. Le service WEB, quant à lui est rendu par une application lancée par le serveur Web (Apache, IIS, etc.) ou exécuté sur un serveur d’application J2EE ou.Net. Ce bus de requête/réponses est fondé uniquement sur http (TCP/IP), et XML standardisé par W3C (2002). Intégration et transformation de l’information sont des tâches que les services Web automatisent complètement, aussi bien dans les scénarios EAI (Entreprise Intégration Application) que dans des scénarios de commerce électronique B2C ou B2B. Une application WEB résulte alors de l’assemblage de services WEB, certains développés en interne et d’autres fournis par des partenaires externes. Dans l’architecture des services WEB : Développer, c’est assembler, déployer, c’est publier. Les Web services ont quitté le champ des échanges interentreprises pour s’accaparer celui du référencement et de la mise à disposition des ressources des entreprises. Empiétant en ce sens sur les technologies de type EAI. Par contre la normalisation complète d’une architecture distribuée fondée sur le Web service n’est pour le moment qu’un rêve annoncé chaque année pour l’année suivante. Par ailleurs, ce modèle n’échappe pas à des problèmes de performance : Les données sont transmises en ASCCII dans une encapsulation XML elle- même intégrée dans une enveloppe SOAP puis http. Le concept du Web service est articulé autour des trois acronymes suivants : SOAP (Simple Object Access Protocol) est un protocole d’échange inter-application indépendant de toute plate-forme basé sur le langage XML. Un appel de service SOAP est un flux ASCII encadré dans des balises XML et transporté dans le protocole http. WSDL (Web Service Description Langage) donne la description au format XML des Web services en précisant les méthodes pouvant être invoquées, leur signature et le point d’accès (URL, port, etc.) C’est l’équivalent du langage IDL pour la programmation distribuée CORBA. UDDI (Universal Description, Disccovry and Integration) normalise une solution d’annuaire distribué de Web services permettant à la fois la publication et l’exploration. UDDI se comporte lui-même comme un Web service, permettant à la fois la publication dont les méthodes sont appelées par le protocole SOAP. 42 Figures EAI-Services Nouvel Anciens applicatif Nouveaux logiciels applicatif OO hérités EAI Bus logiciel : flux de messages Web service Anciens applicatif Nouveauprogiciels Anciens logiciel Nouvel s hérités applicatifs OO App. 1 Appl : 2 Appl : 3 Appl : 1 Appl :2 Appl :3 connecteur Bus logiciel Appl : 4 Appl : 5 App l : 5 Appl : 6 Appl : 4 Appl 6 Exemple d’illustration des services Web Requête métier Passerelle Web normalisée : Services Consultation du solde Traitement Métier : Recherche du solde Protocol standard Réponse métier normalisée : Solde Encapsulation des données 43 Ce modèle n’est pas bon car il créent des dépendances très fortes entre les sous systèmes et la base des données donc entre les sous systèmes eux même. Les architectures modernes retiennent le principe d’encapsulation des données. Dans ce modèle, les données de chaque sous service ne peuvent être manipulées ou accédées par d’autres systèmes qu’au moyen des interfaces, des services exposés (voir les services CRUD). Après avoir longuement mûri leurs stratégies de présence en ligne presque toutes les banques offrent aujourd’hui à leurs clients l’accès à la consultation de leurs comptes par une variété de moyens directs : téléphone, site WEB, portable WAP, Minitel. Plutôt que de créer de nouvelles applications pour chacun de ces canaux de diffusion, le département informatique avisé aura mis en œuvre la même application – une application Web- au travers d’un ou plusieurs services Web chargés d’adapter la présentation de l’information au canal de distribution et au profil de l’utilisateur. De plus cette même application peut se décliner suivant d’autres services Web destinés cette fois à être intégrés dans des applications tierces externes (agrégation) comme par exemple, celle de compagnies d’assurances partenaires de la banque de dépôt dans la commercialisation de certains produits financiers auprès des particuliers. 1.5 Les règles d’urbanisme 1.5.1 Règles d’urbanisme pour la modélisation de la stratégie (diagramme d’Ishikawa) RS1 Un même objectif ne figure qu’une seule fois dans le digramme. RS2 : Lorsqu’un objectif est décliné en sous objectifs, la liste des sous objectifs doit être exhaustive pour atteindre l’objectif. 44 RS3 Un objectif de niveau le plus fin doit pouvoir être associé à un ou plusieurs KPI (Key performance Indicator) réaliste et significatif. 1.5.2 Les règles d’urbanisme pour l’architecture métier RAM1 : Une activité d’un processus appartient à un et un seul SI. Une activité d’un processus ne peut donc faire appel aux services que d’un seul SI. RAM2 : Toute transformation des propriétés d’un objet résulte d’une activité, même si c’est simplement l’âge de l’objet qui change, comme dans le cas où on garderait un objet entre deux transactions liées à cet objet. Mais dans un diagramme normalisé, une activité ne peut concerner qu’un seul objet, même s’il peut s’agir d’un objet composé. RAM3 Une activité élémentaire ne peut être interrompue, ce qui signifie qu’une fois qu’un acteur est affecté à une activité, il ne peut être réaffecté avant la fin d’exécution ou l’interruption de celle-ci pour fin anormale. RAM4 La fin d’exécution d’une activité force la fin d’exécution simultanée de toutes les activités appartenant au périmètre d’impact de cet événement, qu’il s’agisse d’impact indirect ou induits. RAM5 Toutes les activités peuvent avoir une fin anormale, mais également des événements temporels ou d’abandon. Chacun de ces événements constitue un événement particulier. 1.5.3 Règles d’urbanisme pour l’architecture fonctionnelle RAF1 : Règle d’unicité des blocs Un îlot appartient à un et un seul quartier, un quartier appartient à une et une seule zone. RAF2 : Règle d’asynchronisme des îlots Après avoir traité un événement, un îlot peut en traiter immédiatement un autre, sans avoir à se préoccuper de ce qu’il advient du compte rendu de traitement de l’événement précédent. RAF3 : Un bloc comporte obligatoirement une prise (interface externe) Elle est capable d’activer les services du bloc et de gérer les communications entrantes et sortantes du bloc. RAF4 : Toute communication entrante ou sortante d’un bloc passe par sa prise. Ces prises présentent les avantages suivants : - Centraliser les appels de service et limiter le nombre d’interfaces ; - Mutualiser les services : un service public et un seul pour répondre à des besoins identiques formulés par des demandeurs différents appartenant le cas échéant à 45 des blocs, quartiers ou zones distincts : ceci traduit également le principe de réutilisation. - Accroitre la modularité ; - Réduire au strict minimum les impacts suite à l’évolution d’un îlot dont les services publics sont sollicités par une diversité de demandeurs. RAF5 : Seules les prises communiquent avec le gestionnaire de flux. Les prise sont seules habilitées à communiquer avec le gestionnaire de flux. RAF6 : Une donnée est sous la responsabilité (quel que soit le type d’accès : création, modification, suppression, visualisation) d’un îlot et d’un seul. RAF7 : Toute architecture fonctionnelle comporte une zone gisement des données. Cette zone reprend l’ensemble de toutes les informations dynamiques et pérenne de l’entreprise ainsi que les services d’accès à ces données. RAF8 Toue architecture fonctionnelle comporte une zone référentiel de données et de règles. Cette zone regroupe l’ensemble de toutes les informations communes aux différents éléments du SI dont le cycle de vie est relativement stable. Un référentiel contient les données de référence concernant les produits et services, les règles de gestion administrative et comptable de la compagnie, ses métiers, son organisation indépendamment d’un client particulier, ainsi que les services d’accès à ces données. RAF9 Toute architecture fonctionnelle comporte une zone pilotage unique. Cette zone regroupe les blocs dédiés aux processus de gouvernance et d’analyse et utilisant des informations globalisées et historisées. RAF10 Toute architecture fonctionnelle comporte une zone (ou un SI) opération par métier principal de l’entreprise. Exemple Le système d’information d’une compagnie exerçant dans le domaine de l’assurance IARD (incendie, accidents, risques divers), de l’assurance vie, et de la banque comportera une zone opération IARD, une zone opération Vie, une zone opération Banque. RAF 11 toute architecture fonctionnelle comporte une zone ou un SI ressources unique. Cette zone regroupe les systèmes dédiés à la gestion des ressources internes à l’entreprise. 46 1.5.4 Les règles d’urbanisme pour l’architecture applicative RAA1 : Les données des gisements de données doivent être historisées. Les données partagées doivent être historisées afin de permettre de rejouer si nécessaire un processus et de garantir la cohérence du contenu et la bonne fin. RAA2 : Les données des gisements de données doivent être accompagnées d’une date de publication de mise à jour. Afin de pouvoir retrouver leur valeur à un instant donné. Les plus anciennes peuvent être déportées dans des modules de gestion de données archivées. RAA3 Les données des référentiels de données doivent être accompagnées d’une date de publication de mise à jour et aussi d’une date d’effet (date de prise en compte (Exp. : date à partir de laquelle une adresse est valable). RAA4 : La duplication des données. Au sein d’un bloc, les données peuvent être dupliquées entre les données de contexte (vues) et les données de gisement de données, car cela correspond à deux niveaux de partage et de cycles de vies bien différents. En effet les données sont isolées et temporaires pour les données de contexte alors qu’elles sont partagées et permanente pour les gisements de données. RAA5 : Le boc offrant un service est le responsable de la qualité du service. RAA6 : Toute architecture applicative comporte une zone ordonnancement qui assure l’interface entre front office (FO : écran de saisie d’une commande), back office (BO : la gestion des stocks) et middle office ( MO : la prise en compte d’une commande). Cette zone assure : - La traduction, l’ordonnancement et le pilotage des demandes du FO. Une demande de service émanant du FO est traduite en un ensemble de services appelés dans un certain ordre au niveau des MO et BO. - Le pilotage des processus interne au SI. - La gestion des priorités. 1.5.4 Les règles d’urbanisation pour l’architecture technique RAT1 : Décomposition des blocs applicatifs en couches. Tout bloc applicatif donne lieu à n paquetages, n étant le nombre de couches logiques de l’architecture technique le concernant. RAT2 : Intégrité transactionnelle des flux sensibles 47 Afin d’assurer l’intégrité transactionnelle des flux sensibles (engageant financièrement ou légalement la société), la communication entre tout les systèmes concernés doit être synchrone durant la phase de stockage mise à jour des gisements de données. C’est le seul cas ou la communication synchrone est obligatoire. RAT3 Intégrité des gisements de données : Toute mise à jour des gisements de données et toute émission vers l’extérieur de flux critiques doivent respecter les principes suivants : - Isolation dans un contexte pendant la transaction ; - Atomicité (tout ou rien) de la mise à jour du contexte des données et dans l’émission des flux ; - Cohérence à tout moment des gisements de données ; - Caractère durable (non réversible automatiquement) de la publication si elle réussit. RAT4 Concurrence batch/TP - Les batchs doivent être construits pour s’exécuter de manière concurrente au processus TP sous le contrôle des transactions avec respect de la règle d’intégrité des gisements de données. RAT5 Source unique Les composants logiciels qui ne nécessitent pas de variantes pour des raisons liées à leur catégorie ne doivent être écrits qu’une seule fois. La possibilité ou l’obligation de les implémenter sur des plates-formes différentes ne justifie nullement une multiplicité des sources. RAT6 Centralisation des gisements de données Les gisements de données doivent être centralisés, c'est-à-dire se trouver sur une plate-forme centrale, sécurisée, accessible depuis toute autre plate-forme. RAT7 : Recommandation de non duplication On ne recourt à la duplication que lorsqu’il y a des contraintes (performance, sécurité, charge de réseau, exploitabilité…etc.). On appelle dans la mesure du possible le composant original. 1.6 LES ETAPES DE LA DEMARCHE ET LE CHOIX DU CYCLE DE VIE 1.6.1 LES ETAPES DE LA DEMARCHE La démarche retenue dans le cas du tour-opérateur est illustrée par le schéma suivant : 48 Figure : Les étapes de la démarche : cas tour opérateur. T0 PLANIFICATION DE L’ETUDE T0 +1S Revue des axes stratégiques T0 +4 Définition de la stratégie Analyse de l’existant Itération 1 T0 +8 Définition de la stratégie Itération 2 Définition de la stratégie T0 +13 1313 Itération 3 Plan de convergence T0 + 16 T0 + 18 PUBLICATION DE LA STRATEGIE 119198 20 T0+19 Dans le cas du tour- opérateur, il s’agit de mener l’étude permettant de définir en moins de vingt semaines la cible (système d’information urbaniser) et la trajectoire de convergence associée, il n’ya donc pas lieu de prévoir de mise à jour de la stratégie en cours d’étude (puisque celle-ci est réitérée de manière régulière). On peut noter un certain parallélisme : - L’analyse de l’existant commence avant la fin de la revue des axes stratégiques. - La définition de la stratégie commence en parallèle avec l’analyse de l’existant, car dans le cas qui nous préoccupe, l’approche consiste à concevoir, au moins 49 dans un premier temps, une cible idéale. Il vaut mieux ne pas attendre la fin de l’analyse de l’existant de manière à ne pas brider la réflexion. - Le plan de convergence peut commencer en parallèle avec la dernière itération de la cible. 1.6.2 Choix de cycle de vie adapté Le cycle de vie est globalement séquentiel (même si plusieurs parallélismes ont été introduits dans la planification), à l’exception de la phase de définition de la stratégie qui est menée de manière itérative. Cette option permet rapidement de : - Développer une première vision de la cible et de la confronter à la critique ; - Familiariser l’ensemble des intervenants à une démarche méthodologique et par fois un mode de pensée jusque-là inconnus. 1.7 URBANISME ET STRATEGIE 1.7.1 LA CAPTATION DE LA STRATEGIE Il s’agit de placer le projet d’urbanisation du système d’information dans le cadre général de la stratégie de l’entreprise de manière à définir une cible pour le système d’information qui soit en phase avec le processus métier, eux même en phase avec la stratégie de l’entreprise. Le recueil et la compréhension de la stratégie sont donc indispensables en amont de toute démarche d’urbanisation de système d’information. L’entreprise est alors visualisée selon cinq points de vue complémentaires : - La mission, qui en fait la raison d’être de l’organisme ; - La vision, constituée par l’ensemble des objectifs de haut niveau de l’entreprise. - La stratégie, qui est le moyen de réaliser la vision et qui s’exprime par un ensemble d’objectifs et de sous objectifs stratégiques. - Le système d’information qui comprend : o Les processus métier qui supportent les objectifs stratégiques, o Le système informatique qui implémente le processus métiers. Figure : Système d’information et système informatique Processus Système métier informatique Mission Vision Stratégie Système d’information 50 La stratégie est modélisée par une hiérarchie d’objectifs qui sont décomposés en sous objectifs. La décomposition d’objectifs en sous objectifs s’arrête lorsque tous les objectifs peuvent être atteint par au moins un processus. Les projets d’urbanisation de systèmes d’information ont leurs origines dans les décisions d’ordre stratégique pour l’entreprise. L’activité de compréhension de la stratégie de l’entreprise est destinée à définir un cadre de référence commun aux dirigeants de l’entreprise, aux responsables informatiques et à l’équipe chargée de l’étude d’urbanisation sur la stratégie générale de l’entreprise. Il s’agit de mettre en évidence les choix stratégiques les plus structurants pour le système d’information. Cette activité permet de comprendre et de valider les différentes orientations stratégiques du système d’information en prenant en compte : - Le point de vue de la direction informatique ; - Le point de vue de la direction ; - Le point de vue des utilisateurs. A partir de ce cadre commun, l’équipe chargée de l’urbanisation pourra clairement définir les limites de l’intervention d’urbanisation. Une fois les limites du champ de l’étude définies et partagées par tous les acteurs, l’équipe chargée de l’urbanisation établira dans les grandes lignes les premières conclusions qu’elle peut tirer de la stratégie de l’entreprise en termes d’aménagement du système d’information. Plus précisément, les objectifs de la captation de la stratégie sont les suivants : - Recueillir et comprendre la politique et la stratégie générale de l’entreprise. - Fournir à l’équipe d’étude une compréhension en profondeur des choix et orientations de l’entreprise. - Amener la direction à formaliser (expliciter) les choix implicites. - Sensibiliser les responsables informatiques sur les choix stratégiques de l’entreprise. - Evaluer leurs conséquences à court, moyen et long terme au niveau de son système d’information et système informatique. - Expliciter la vision à court, moyen et long terme du système d’information. - S’informer sur les dysfonctionnements majeurs de la situation actuelle. La stratégie de l’organisme aura un impact à court, moyen et long terme sur le système d’information et le système informatique. Il ‘est alors important de conserver la distinction entre chaque groupe d’impacts. Cette classification sera utilisée lors de la hiérarchisation des rénovations et de l’ordonnancement de la mise en œuvre de l’urbanisation. 51 Dans cette phase, on mettra aussi en évidence les besoins d’évolution de la stratégie mais provenant des contraintes extérieures, comme par exemple des changements des réglementations du métier étudié (nouvel assujettissement à la TVA, suppression du bonus/malus pour les assurances automobiles…) 1.7.2 LA MODELISATION DE LA STRATEGIE : diagramme d’Ishikawa Le diagramme des objectifs est basé sur le diagramme d’Ishikawa. Ce dernier sert à représenter les causes et leurs effets. Le premier élément est un axe central correspondant à l’effet majeur recherché. Tandis que les causes engendrant cet effet sont représentées sous forme d’axes dirigés vers l’axe central. L’axe indiquant la cause est à son tour considéré comme un effet à obtenir, et les causes induisant cet effet sont représentées par des flèches dirigées vers cet axe de cause/effet…etc. On utilise le diagramme d’ishikawa pour représenter la stratégie de l’entreprise. Dans cette activité, les actions suivantes sont à mener : - Analyse des documents disponibles présentant la stratégie de l’entreprise ; - Préparation d’un guide d’entretien ; - Conduite des entretiens. Les entretiens sont menés auprès : o Des directions (vision stratégiques) o Des responsables des structures informatiques (moyens coûts…etc.) o Les responsables utilisateurs (vision en matière de services rendus) - Analyse des entretiens - Consolidation des résultats ; - Première classification et hiérarchisation des besoins ; le document de synthèse élaboré à l’issue de cette tâche devra comporter des éléments de réponse aux sujets suivants : o Quelles sont les évolutions métiers envisagées. o Quelles sont les évolutions en termes de services informatiques (développements d’applications spécifiques, support aux utilisateurs…) o Quels sont les objectifs de qualité (délai de livraison d’un logiciel, zéro défaut…etc.) o Quels sont les axes d’évolutions envisagées pour l’infrastructure technique (nouvelles méthodes et outils de développement, nouvelle architecture technique …etc.) 52 Figure : Diagramme d’ishikawa (Cas du tour –opérateur) Augmenter le taux de transformation des contacts en réservations Augmenter le nombre de Développer des canaux contacts alternatifs Développer un marketing cible Permettre aux vendeurs de se focaliser plus sur l’acte de vente Faire distribuer les produits par les partenaires Développer une connaissance fine Orienter les contacts vers les produits disponibles des clients Traiter toutes les demandes en temps réel Augmenter la plage d’ouverture de la vente Se positionner dans le e-commerce Diminuer la charge administrative des vendeurs Optimiser les ressources humaines du Redevenir le tour opérateur N° 1. Facturer plus rapidement standard du siège Diminuer les coûts de communication Eliminer les doubles saisis et les erreurs qui en découlent Détecter en temps réel les mauvais payeurs Distribuer des produits de partenaires Améliorer le cash flow Diminuer les coûts de gestion 1.7.3 Objectifs du système d’information Afin de répondre correctement aux objectifs métiers, le SI doit se fixer les objectifs détaillés suivants. Ces objectifs ont été déduits des objectifs métiers. 1. Améliorer la productivité des vendeurs Il s’agit de mettre à disposition des vendeurs situés dans les agences principales un outil informatique leur permettant de s’affranchir de la consultation du fax quotidien sur les disponibilités et de l’appel téléphonique au siège pour vérifier la disponibilité en temps réel et enregistrer les réservations. 53 En outre l’interface homme machine sera particulièrement étudier de manière à orienter le client sur les produits disponibles. Les données concernant un client existant pourront être récupérées de manière à éviter à la fois les pertes de temps et les risques d’erreur. 2. Optimiser la valeur du client Il s’agit de tirer le maximum des clients existants et prospects identifiés. La mise en place d’un programme de fidélisation vise à ce qu’un client dépense la plus grande part de son budget vacance avec des produits de l’entreprise, alors qu’actuellement, il est perçu qu’un client peut partir trois fois par an en vacances en ne passant qu’une seule fois par le tour-opérateur. Il faut donc se donner les moyens d’analyse pour mettre en œuvre un marketing ciblé permettant d’atteindre cet objectif. Il faudrait donc enregistrer tous les contrats et mettre en place un outil de gestion de la relation clientèle parmi les plus performants du marché. 3. Ouvrir à la vente 24h/24, 365 jours par an La concurrence, la nécessité de se positionner dans le e-commerce, mais aussi la position mondiale du tour opérateur entrainent l’ouverture du système à la vente quasiment 24H/24 et 365 jours par an. Cette ouverture concerne essentiellement les référentiels produits et clients et les réservations. 4. permettre la vente directe La vente directe correspond à une demande du marché et permet une diminution significative des coûts de gestion. Elle recouvre : - La vente sur le web ; - La vente via un centre d’appels téléphonique. Pour le web, il s’agit d’ouvrir un portail pour la vente de certains des produits de l’entreprise et de produits de partenaires sous une marque commerciale spécifique. Pour le centre d’appel téléphonique, il s’agit de vendre l’ensemble de produits de l’entreprise sous la marque commerciale habituelle. Il s’agit donc d’une agence supplémentaire mais virtuelle. L’enjeu est aussi de convertir des gestionnaires du service organisation vers un rôle de téléconsillers. 5. Accepter ou refuser en temps réel des paiements échelonnés 54 L’acceptation en temps réel des demandes de paiements échelonnés permettra de ne plus polluer le système avec des préreservations qui sont ensuite annulées et diminuera les coûts de gestion. 6. Intégrer des produits de tiers au catalogue Le système d’information doit permettre la distribution de produits de partenaires complétant l’offre du tour-opérateur et ne nécessitant ni canal particulier ni compétences pointues. 1.7.4 Correspondance objectifs métiers/objectifs systèmes d’information Il s’agit de présenter la vue globale de la contribution des objectifs retenus pour la construction du futur SI aux objectifs stratégiques métiers. Objectifs Augmenter Taux de Développer Diminue les Améliorer métier/objectif le nombre transformation les canaux coûts de les cash SI de contacts contact/contrat alternatifs gestion flow Améliorer la x x productivité du vendeur Optimiser la x x x valeur des clients Ouvrir la vente x x x x 24h/24 Permettre la x x x x vente directe Accepter ou x x refuser en temps réel les demandes de paiements échelonnés Intégrer des x x x x produits de tiers au catalogue 1.7.5 Key performance indicators ( KPI) Il s’agit de mettre au moins un indicateur de performance en face de chaque objectif du SI cible. Ces KPI seront suivis régulièrement pour vérifier si les objectifs fixés sont atteints et donc de mesurer l’efficacité du plan d’évolution du système d’information mis en œuvre pour implémenter la stratégie de l’entreprise. 55 1. Amélioration de la productivité des vendeurs - Nombre de contacts enregistrés par vendeur en agence par période. - Nombre de contacts enregistrés par vendeur en agence principale par période. - Nombre de contacts enregistrés par téléconseiller par période. - Nombre de réservations enregistrées par vendeur en agence par période. - Nombre de réservations enregistrées par téléconseiller par période. - Taux de transformation des contacts par vendeur en agence par période. - Taux de transformation des contacts par vendeur en agence principale par période. - Taux de transformation des contacts par téléconseillers par période. 2. Optimiser la valeur des clients - Nombre de séjours par an par client. - Taux de clients de l’année N-1 également clients l’année N. 3. Ouvrir à la vente 24h/24, 365 jours par an - Disponibilité du système de réservation pour les agences. - Disponibilité du système de réservation pour les agences principales. - Disponibilité du système de réservation pour le centre de la communication. 4. Permettre la vente directe - Nombre de réservations enregistrées par le centre de communication. - Nombre de réservations enregistrées par le portail WEB. 5. Accepter ou refuser les demandes de paiements échelonnés - Nombre de demandes de paiements échelonnés non traités en temps réel. 6. Insérer les produits de tiers au catalogue - Nombre de produits de tiers au catalogue. - CA généré par les produits de tiers. - Marges générées par les produits de tiers. 1.7.6 Le diagramme de l’entreprise 56 Le diagramme de l’entreprise est une vue « aérienne « de l’entreprise faisant apparaître les différentes entités fonctionnelles qui composent l’organisation (vente, commerciale, administration, finance, production, logistique, veille technologique, recherche, marketing…etc.) et détaillant les activités et flux d’informations échangés entre ces entités. On fait également figurer sur ce schéma de synthèse les clients, les fournisseurs et les partenaires ; l’exhaustivité n’est pas nécessairement l’objectif recherché, mais davantage la clarté et la compréhension de l’activité métier de l’entreprise. Il est recommandé de réaliser un tel diagramme lors de la captation de la stratégie et comme démarche préalable au contrôle de cohérence métier- organisation fonctionnelle- diagramme synthétique entreprise-flux-cartographie de processus. Figure digramme de l’entreprise : cas d’une SSII. Figure diagramme de l’entreprise : cas du tour –opérateur. CLIENT Demande Paiement acompte informations Paiement Préres. facture. acompte Catalogu Décision Paiement e Remboursement échelonné Agences Facture Catalogue M Direction e commerciale Direction E

Master Offshoring d'Informatique Appliquée - Systèmes d'Information Avancés (PDF)

Document Details

Tags

Related

Summary

Full Transcript