La Business Intelligence au sein du système d informatique financier d Airbus

Dimension: px
Commencer à balayer dès la page:

Download "La Business Intelligence au sein du système d informatique financier d Airbus"

Transcription

1 Master 2 MIAGE La Business Intelligence au sein du système d informatique financier d Airbus MÉMOIRE DE STAGE DE FIN D ETUDES Mémoire soutenu à l Université le 27 Mai 2013 Encadrant : GOMEZ Anne Tuteur : PUJOLLE Geneviève

2 2

3 Remerciements Avant de commencer ce rapport marquant la fin de mes études, je tiens à remercier toutes les personnes qui tout au long de mon stage m ont orientées dans la mission qui m a été confiée. Je tiens à remercier tout d'abord Eric d Arco, qui m'a donné l'opportunité de réaliser mon projet de fin d'étude dans le bundle FBI au sein de Sopra group Midi-Pyrénées. Mes remerciements s'adressent aussi à Anne Gomez, ma tutrice de stage, qui s'est montrée disponible tout au long du stage pour m aider et me donner les conseils nécessaires. Je tiens à remercier Myriam Serrano, ma chef de projet, et toute l équipe One Report, Vincent Lesiourd, Pablo Aguilar, Myriam Serres et Daheyna Paleatchy pour m avoir aidé à bien m intégrer au projet et m accompagner dans mes tâches. Merci pour leurs réponses à toutes mes questions. Je remercie également tous les membres du domaine FI BI pour leurs aides et leur accueil sympathique. Merci pour l ambiance plein d humour et d amitié que tout le monde a créé à chaque jour de mon stage. J exprime mes remerciements à Madame Geneviève Pujolle, ma tutrice universitaire et l équipe enseignante de la formation MIAGE. Enfin, tous mes remerciements à mes parents et mes amis, qui m ont écouté, soutenu tout au long de mon stage et de mes études. Merci d être à côté de moi et de me donner les conseils quand j en ai besoin. 3

4 4

5 Résumé Dans le cadre de ma dernière année d étude de la formation MIAGE, j ai effectué un stage de 6 mois (de décembre 2012 à mai 2013) au sein de Sopra Group Midi-Pyrénées. Ce stage s est déroulé dans le bundle FBI de l agence 101 Aérospatiale, et s inscrit dans le cadre de l évolution d une partie du système d information financière d Airbus. Au cours de mon stage, j ai pu aborder la mise en œuvre d un projet dans un contexte industriel. J ai participé avec l équipe de projet à toutes les phases : l analyse du besoin utilisateur, la conception d une solution en rapport avec les exigences utilisateurs, l implémentation de la solution, les tests de l application et la mise à disposition de l application aux utilisateurs. Cette expérience m a donné l opportunité de travailler sur différents aspects du système d information complexe d Airbus, avec le progiciel SAP R/3 et SAP BW. J ai eu l occasion de découvrir des méthodologies de travail d Airbus et Sopra, d observer le pilotage d un projet dans un contexte difficile. Ce stage m a permis d avoir des premiers pas dans ma carrière professionnelle. Abstract For my final year in MIAGE, I did an internship for 6 months (December 2012-May 2013) in the bundle FBI of Sopra Group Midi-Pyrenees. My task was to realize a reporting application in the financial information system of Airbus. During my internship, I was able to get into a project in an industrial context. I participated with the project team in all phases: Business requirement analysis, solution design in relation to user requirements, implementation of the solution, tests and delivery of the application to users. This experience gave me a chance to work on different aspects of complex information system with the SAP R/3 and SAP BW technologies. I had an opportunity to discover Airbus and Sopra methodologies, to observe a project piloting in a difficult condition. This internship allowed me to have a first step in my professional career. 5

6 6

7 Sommaires Remerciements... 3 Résumé... 5 Abstract... 5 Sommaires L environnement de stage Sopra Group Historique Activités et marchés Chiffres clés Implantation France et International Division Midi Pyrénées Le Bundle FBI Synthèse des travaux L informatique décisionnelle dans le domaine financier d Airbus Projet One Report Présentation du projet Le projet ARP One Report, le projet reporting financier d ARP L organisation du projet Les méthodes de gestion de projet : GPP et e-media Airbus GPP Toolkits Sopra e-media L environnement technique Le système d information décisionnelle d Airbus La solution BI de SAP La validation de l application avec HPQC Les travaux réalisés Validation Test d intégration Gestion des anomalies Spécification Spécification générale Spécification détaillée Développement Livrables Sujet de réflexion : L offshoring d un projet informatique Introduction Choix du sujet Définition Le marché offshore international Les pays de services offshore

8 Les géants des sociétés offshore Les enjeux Les bénéfices Les points critiques L offshoring : stratégie incontournable de Sopra Offshore à SopraGroup SopraGroup India Madrid Casablanca Modèle «Soprasien» : Xshore L approche basée sur l évaluation des risques L offshore dans le contexte du projet One Report Organisation des équipes FO-BO Les premiers retours d expériences Une solution pour l offshore : les méthodes agiles Amélioration du plan de communication Mobiliser des ressources humaines Gérer les problèmes interculturels Utiliser des bonnes méthodes de communication Amélioration du plan qualité Réduire les risques d incompréhension Faire valider régulièrement le travail Répartir les équipes selon en fonction des modules développés Produire efficacement des documents Conclusion Bilan Bilan de compétences Compétences techniques Compétences fonctionnelles du métier Compétences de management Bilan professionnel Bilan personnel Difficultés Conclusion Glossaires Bibliographies Annexes Planning de stage

9 1. L environnement de stage 1.1. Sopra Group Historique Sopra Group a été créé en janvier 1968 à Annecy, par ses fondateurs Pierre Pasquier, François Odin et Léo Gantelet. Cette société, une des plus anciennes SSII européennes et top 10 des sociétés européennes de Conseil et de Services informatiques, s est rapidement imposée nationalement et internationalement à partir de la création de sa première filiale internationale à Genève en Grâce à la réussite et à la croissance considérables, Sopra Group est entrée à la Bourse de Paris avec succès en Aujourd hui, l acquisition des différentes sociétés (SG2 Ingénierie, Orga Consultant, Infosud ingénierie de Crédit Agricole, Valoris et HR Access ) permet au groupe de renforcer et d élargir ses services proposés (conseil et services informatiques, solutions bancaires et business intelligence ) Activités et marchés L activité principale de Sopra est d accompagner ses clients dans l évolution de leur organisation et de leurs systèmes d information. Elle se compose de : - Consulting (12% chiffre d affaires) - Intégration de Systèmes&Outsourcing applicatif (60% chiffre d affaires) - Solutions applicatives (13% chiffre d affaires) - Filiale Axway, leader mondial dans le domaine des Collaborative Business Solutions (15% chiffre d affaires) La répartition de ces activités sur les marchés principaux (services financiers, services transport et utilities, industrie, secteur public, télécoms & médias, distribution) selon leur chiffre d affaires est stable (voir schéma ci-dessous). Fig 1 La répartition de ces activités de Sopra Group 9

10 Chiffres clés Fig 2 - Les résultats financiers de Sopra des années En 2012, le chiffre d affaire réalisé par le groupe a été 1,217 milliards d euros avec une croissance organique de 2%. Il compte jusqu aujourd hui un effectif supérieur à collaborateurs (1 er trimestre 2013). Malgré une situation difficile de l économie européenne et mondiale, Sopra conserve encore sa position et sa progression, ses résultats nets restent encore optimistes Implantation France et International Fig 3 L implantation internationale de Sopra Pour son implantation nationale, Sopra a construit une large couverture avec 25 sites en France. Le groupe a aussi des implantations en Europe (Espagne, Royaume-Uni, Italie, Benelux, 10

11 Suisse ). Au niveau international, Sopra a développé des centres de services dans les positions stratégiques comme Inde, Maroc pour profiter les avantages de ces pays Division Midi Pyrénées La division Midi-Pyrénées de Sopra a été créée en Aujourd hui, la division compte plus de 1000 collaborateurs travaillant sur 5 agences selon les projets sur différents secteurs : l aérospatiale, l industrie / public / tertiaire, STIE (Scientifique Technique Industriel Embarqué) et le business consulting Le Bundle FBI Fig 4 L organisation de la division Sopra Midi Pyrénées Le bundle FBI est un pôle de l agence Aerospace 1, se situe au site Sopra Colomiers 1. Le terme «Bundle» est utilisé par Airbus pour désigner un ensemble de projets d un même domaine. En réalité, les activités du Bundle FBI (Finance et Business Intelligence) ont été démarrées en Avril Ce bundle fournit des services d application aux projets du domaine Finance et BI d Airbus, pour un contrat de 3 ans et un budget de 5 millions d euros. Fig 5 L organisation du bundle FBI 11

12 Le bundle est organisé en 4 domaines. Deux domaines opérationnels BI et BI-Finance contiennent des équipes travaillant directement sur les projets d Airbus. L équipe du domaine d AS (Application Services) reçoit les projets finalisés par les domaines BI, BI-FI et s occupe du support et de la maintenance des applications. Enfin, une équipe du centre de compétences s occupe des tâches transversales : la validation des livrables avant de les transférer aux clients, l étude sur la stratégie du bundle, la sélection des benchmarks, des outils et le support du business dans la phase d expression des besoins (facilitateur). Du côté opérationnel, le bundle contient des chefs de projets (PM), des facilitateurs (ISPL), des seniors analystes (architectes), des juniors analystes (designers), des développeurs et des testeurs. Le projet où je travaille pendant mon stage est un projet du domaine BI-Finance. Ce projet consiste à développer une application de reporting dans le système d information financier d Airbus. 12

13 2. Synthèse des travaux 2.1. L informatique décisionnelle dans le domaine financier d Airbus L informatique décisionnelle (aussi connue par le terme Business Intelligence) est un ensemble de méthodes, d architectures, de technologies et d applications qui consistent à récupérer et transformer des données sources, les organiser en informations utiles afin de les présenter clairement pour aider à la prise de décision. Autrement dit, l informatique décisionnelle fournit à l entreprise des solutions de gestion des données volumineuses, variées, difficiles à gérer, sur lesquelles l entreprise peut déduire des décisions stratégiques efficaces. La BI permet aussi d avoir une vision globale sur les activités passées, actuelles et à venir ; elle aide aussi au processus d analyse des activités, de recherche de données Ce domaine devient aujourd hui source de la compétitivité de l entreprise. La fonction finance est un des principaux enjeux de la compétitivité et la transformation de l entreprise. Aujourd hui, en période de crise, la finance n est plus qu une fonction support mais un élément majeur dans le pilotage et la stratégie de l entreprise, comme disait le Baromètre Decideo, «la Finance est le domaine le plus consommateur en applications décisionnelles» (Les tendances du décisionnel en 2010). Bien évidemment, un système de comptabilité, de gestion de trésorerie performante permet à l entreprise d augmenter sa capacité financière et de mieux déployer sa stratégie choisie. Ces raisons montrent que pour un grand business (leader de construction des avions) comme Airbus le système d information décisionnel financier est primordial pour répondre aux questions de budgets, de coûts et de planifications financières. Le système BI permet à toute société de mieux gérer son compte de résultats, faciliter la comptabilité en s accordant aux exigences légales imposées par les instances de régulation. Il permet aussi de mesurer la performance de l entreprise, l efficacité de ses activités, la rentabilité de ses projets et préparer des actions en regardant des opportunités du marché. Enfin, à partir de ces informations, il aide les décideurs d Airbus à prendre des décisions financières (investissement, endettement ) pour lesquelles on doit être très prudent dans cette période de crise Projet One Report Présentation du projet Le projet ARP Airbus, leader du monde de constructeur aéronautique, a un système d information énorme et très compliqué à gérer. Au début, chaque implantation principale de la société (France, Allemagne, Royaume-Uni, Espagne) dispose son système ERP pour gérer tous ses processus d achat, de production, de ressources humaines, de relation clients En conséquence, ces processus et des règles de gestion de chaque système ne sont pas toujours communs et causent des difficultés dans leurs interactions. C est pourquoi le projet ARP (Airbus Ressources Planning) a été lancé dans le but 13

14 d harmoniser tous les différents systèmes SAP d Airbus. Grâce à ce projet, tous les processus métiers clés d Airbus deviennent uniformes et les activités sont désormais gérées de façon unique et globale. En 2006, les processus d assemblage de l A380 ont été les premiers harmonisés grâce à ARP. En 2008, les deux sites de Toulouse et de Hambourg ont réussi à fonctionner ensemble et à livrer le premier avion dont l assemblage utilisait le seul système d information ARP. Aujourd hui, les autres processus d Airbus ont aussi migré au fur et à mesure vers ce système ARP. Bien évidemment, le domaine de la finance est une partie importante de ce projet important. Pour la migration des systèmes d information financiers des quatre pays, Airbus a fait appel aux différents SSII, où la partie BI de la finance a été confiée à Sopra, plus précisément au Bundle FBI. C est dans ce contexte que One Report a été mis en place One Report, le projet reporting financier d ARP One Report est un élément majeur dans l ensemble du projet du domaine financier d ARP, il consiste à réaliser une application de reporting dans le système d information financier d ARP. Le but de One Report, comme toutes les autres applications BI, est de fournir les informations financières sur les stocks utiles sous forme des reportings aux décideurs. Les fonctions principales de cette application sont séparées en 3 BSD où chacune est considérée comme une itération de développement. Le BSD1 «Gross Value & provisioning» se focalise sur le calcul de la dépréciation des matériels. Le BSD2 «Material stock per location» se focalise sur l inventaire des stocks au niveau des emplacements de stockage Airbus. Le BSD3 «Material flow» se focalise sur les flux des matériels (l analyse de la quantité, la valeur et la raison des entrées-sorties de stock). Fig 6 - Le processus de reporting One Report. 14

15 Au premier jour ouvré de chaque mois, les données financières des systèmes SAP Finance et Logistiques doivent être chargées dans le au système BI. A partir de ces données brutes, One Report identifie la variance comptabilité (l écart entre les valeurs finances FI et logistiques-finances MM-FI) et calcule la provision de ces articles selon les différentes valeurs fiscales. Ce calcul doit être terminé au plus tard le D+4 (4 e jour ouvré du mois). Ces données sont ensuite utilisées avec les valeurs venant des systèmes logistiques (SAP MM) pour calculer la variance logistique (entre MM et MM-FI) des matériels et un report d inventaire de stock doit être produit au plus tard à 12h du D+4. Enfin, un report sur les flux des articles permettent aux contrôleurs de gestion, des comptables une analyse détaillée sur les mouvements de stock. Fig 7 - Les différents systèmes SAP d Airbus Les données financières sont extraites depuis les systèmes SAP R/3 des pays (PDA pour l Allemagne, PGI pour la France, SPA pour l Espagne, APD pour le Royaume-Uni et PEA pour le système harmonisé ARP) vers le système SAP BW unique d ARP PBA. Le planning a été défini de telle manière à développer un premier lot qui ne gère que les données allemande. Ceci permettra de valider la solution et d ensuite la généraliser aux autres pays (system back end)... La migration sera continuée avec ARP dans un second temps et terminera avec les 3 autres pays (PGI, SPA, APD) L organisation du projet L équipe de projet est composée par 2 sous-équipes : une équipe de front office en France de 4-5 personnes (donc 1 ou 2 architectes généraux, 2 consultants confirmés et moi-même) et une équipe de back office en Inde (donc un responsable, 2 développeurs BW et 2 développeurs ABAP). Une équipe testing indienne de 2 personnes intervient à la phase de test. Le chef de projet Sopra gère et anime les deux équipes. Sur la partie MOA, des besoins fonctionnels sont exprimés par le chef de produit. Un responsable de projet côté Airbus avec plus de connaissances techniques s occupe ensuite l alignement des exigences sur les techniques de SAP BW 15

16 et la validation des livrables. Entre l équipe MOA et l équipe MOE du projet, un facilitateur d une autre société (Akka) intervient pour l explication des besoins et des règles fonctionnelles. L ISPL joue le rôle d interface entre Airbus et l équipe de projet, il participe à la phase d expression des besoins, assure le suivi de l avancement du projet et reporte les problèmes au responsable de projet. En général, pour garder une visibilité totale sur l état du projet, l ISPL et l équipe de projet ne doivent pas être de la même société. Les activités de supports sont assurées par les équipes AS et FBICC de Sopra. L AS intervient à la phase de maintenance de l application et le centre de compétence FBI participe à la validation des livrables avant de les fournir aux clients. L organigramme de One Report est présenté sous forme du schéma ci-dessous. Fig 8 - L organigramme du projet One Report Les méthodes de gestion de projet : GPP et e-media One Report, comme les autres projets du Bundle, est soumis à deux méthodes différentes de pilotage de projet, une du client Airbus et une de Sopra. 16

17 Airbus GPP Toolkits Fig 9 Le processus de GPP Toolkits Airbus, pour le pilotage de ces projets, utilise GPP Toolkits. C est un modèle générique, adapté en fonction des caractéristiques spécifiques de chaque domaine, technologie, programme ou projet. L instruction de GPP introduit le cycle de vie, l organisation et les règles s appliquant aux projets du système information. Le cycle de vie de GPP a une forme qui se ressemble au cycle de vie en V, il se compose de phases, de jalons et de portes de qualité. Phase : 7 phases : chacune peut être divisée en sous-phases. Chaque phase doit être accomplie dans l'ordre chronologique afin de s'assurer que ses principaux objectifs sont atteints avant de passer à la suivante. Les 7 phases principales de GPP dans l ordre chronologique sont : Étude de l opportunité (M1-M3), Conception (M3-M5), Définition de la solution (M5-M7), Développement de la solution (M7-M9), Test d acceptation (M9-M11), Déploiement (M11-M13), Utilisation opérationnelle (M14). Sopra intervient au projet One Report à partir de la phase M5-M7 jusqu à la fin du cycle, où l équipe de projet s occupe de la spécification, du développement, du test et de la mise en production. L équipe AS (Application Service) de Sopra s occupe éventuellement de la phase de maintenance. Jalons (Milestones) : 14 jalons pour marquer les points de contrôle importants : les jalons en rouge (M3, M5, M11, M12) sont des étapes de GO / NO GO qui impliquent une décision du comité de pilotage. Chaque jalon permet de faire une estimation sur l état actuel du projet, d assurer que les décisions-clés relatives à l avancement du projet sont effectuées, d évaluer si le projet est prêt à avancer à la prochaine phase, le non atteint des objectifs peut conduire à retravailler sur la phase actuelle ou même à abandonner du projet. Il y a 11 jalons principaux dont 4 GO / NO GO. Étapes qualité (Quality Gates) : pour l'évaluation des livrables-clés. Ce processus est réalisé en 2 étapes. La première étape est la mise en place de l accord du processus pour déterminer les fonctions des acteurs et les livrables impliqués, les critères d acceptation et le chemin restant. La 2 e étape est l évaluation des livrables en se basant sur les critères d acceptation. One Report débute par la réception de la BSD (Business Specification Dossier) 17

18 d Airbus contenant toutes les exigences et les règles fonctionnelles de l application. Ensuite, les documents de spécification et de test devront être livrés par l équipe de projet Sopra. Ces livrables font partie de mes travaux durant le stage. Durant le stage en licence 3 chez Airbus, je travaillais dans le service de définition des applications liées au système d information. Cette occasion m a permis de me familiariser avec cette méthodologie. C est pourquoi, au début, des notions et des termes utilisés par GPP Toolkits ne m ont pas posé des problèmes d incompréhension durant les discussions et les réunions Sopra e-media Si les jalons et les phases principales du projet sont imposés par Airbus, Sopra applique aussi sa propre méthode de pilotage de projet e-media. A la phase M5-M7, dès la réception du BSD d Airbus, une phase d initialisation est lancée au côté de Sopra, où les acteurs de pilotage font un plan sur les tâches principales, l équipe et le budget du projet. Une équipe de projet Sopra est construite en composant d un chef de projet, des architectes générales, des designers, des développeurs et des testeurs. Ensuite, des documents d initialisation doivent être produits (plan de management et plan de développement). Sopra doit fournir aussi le chiffrage et la planification du projet au client. Une fois tous ces documents validés par le client, la réalisation du projet est lancée. E-Media définit aussi 4 niveaux de réunions : la V1, V2, V3 et V4 (V pour visibilité). La V1 est une réunion hebdomadaire faite au sein de l équipe de projet pour communiquer l avancement des tâches. La V2, au niveau supérieur, est planifiée chaque mois entre les chefs de projets et le manager du domaine pour avoir une vision globale sur l état de l ensemble des projets. Les réunions de type V3 et V4 interviennent rarement au déroulement d un projet. Les V3 sont les réunions annuelles ou biannuelles pour la planification financière et les V4 identifient la stratégie globale à long terme (plusieurs années). Le chef de projet doit organiser et animer les V1, il rédige aussi un compte-rendu de la réunion et le fait diffuser à l équipe. Pour One Report, chaque semaine, la V1 de l équipe front office est planifiée mardi après-midi. Une réunion de ce type est aussi faite avec l équipe indienne par conférence téléphonique. Dans la période où One Report recevait des alertes de retard, la V1 avec les développeurs offshore a été passée en mode journalier pour augmenter un niveau de suivi. A côté des réunions officielles, les petites réunions et discussions informelles sont souvent faites entre les membres de l équipe pour clarifier un problème ou faire un point sur les tâches à faire. 18

19 L environnement technique Le système d information décisionnelle d Airbus Le rôle principal du décisionnel est de mettre à la disposition des utilisateurs des données bien structurées afin de faciliter la prise de décision. Un système BI se distingue des systèmes opérationnels (comme dans le cas d ARP, on distingue le système BW PBA et le système R/3 PEA). Le décisionnel se base sur un moteur OLAP (analytique) plutôt qu un moteur OLTP (transactionnel). Il permet de transformer les données brutes en informations utiles. Un flux de données décisionnelles est : - L extraction des données opérationnelles des systèmes de production. - Le stockage des données transactionnelles dans l entrepôt de données (dans le système BW Airbus, cette couche est appelée Integrated Layer). Ces données sont ensuite transformées en tenant compte des règles de gestions métiers et transportées aux magasins de données (Datamart layer). - La restitution des données décisionnelles des magasins de données et la présentation de ces informations sous forme des requêtes de reporting. Ces reports vont servir à l analyse et la prise de décision des utilisateurs finaux. Fig 10 - Le processus de l informatique décisionnelle Pour mieux gérer son système BI, Airbus impose ses propres règles d administration rédigées dans le document «Norm&Method». Les objets de la couche X (Integrated Layer) sont utilisés par l ensemble des projets. Les données dans cette couche sont extraites directement à partir des systèmes opérationnels, sans aucune transformation spécifique. Ces données sont gérées par l équipe de centre de compétences BW (BICC. Par contre, dans la couche H (Datamart Layer), sachant que les vues métiers sont différentes suivant les domaines chaque projet dispose de ses propres 19

20 objets et ne peut utiliser que les siens. Cette règle permet d éviter les problèmes d inter-blocage entre les différents projets en utilisant les mêmes objets Les données décisionnelles utilisées dans la BI sont classifiées en 2 types : des données de bases et des données transactionnelles. Les données de base, appelées par les Master Data, sont les informations stables et inchangées pendant une longue durée (le code de fournisseur, de matériel ) et elles sont utilisées par tous les processus. Les données transactionnelles sont spécifiques au processus, elles permettent de relier les données de base (par exemple une commande est composée d un fournisseur et d un matériel) La solution BI de SAP SAP propose un ensemble de solution permettant de construire un système BI. Un flux de données de BW contient tous les étapes de l extraction des données brutes jusqu à la présentation des informations dans les reports. Les objets stockage de BW sont de 2 types : des info-objects et des info-providers. Les infoobjects sont les plus petites unités d information de BW, ils peuvent être des caractéristiques, des ratios, des unités, des caractéristiques de temps ou des caractéristiques techniques. Ces info-objects sont contenus dans différents types d info-provider selon leur utilisation : DSO (Data Store Object) pour stocker les données transactionnelles, Master Data pour les dimensions d analyse données de base, InfoCube pour les données transactionnelles dans les reports. Fig 11 - Les flux de données SAP BW 20

21 Les données des systèmes de production R/3 ou des fichiers plats sont extraites vers les data sources du système BW par des infopackages ou des modules fonctionnels (développé en ABAP). Dans le système BW, ces données sont stockées dans les DSO (pour les données transactionnelles) et des Master Data (pour les données de base). L alimentation des données entre les objets est assurée par les transformations et les DTP (Data Transport Package). Les cubes de données sont créés dans la couche de Datamart sous forme des InfoCubes. En général, toutes les règles de gestion sont déjà intégrées au niveau des cubes, car c est principalement les informations dans les InfoCubes qui sont utilisées dans les reports. Enfin, SAP BW dispose des outils de développement des reports : Query Designer pour les reports Excel, Report Designer pour les reports en PDF et Web Application Designer pour les reports en Web Template. One Report, comme tous les autres projets BI Airbus, travaille sur 4 environnements différents selon les différentes phases. Le transport des objets entre les environnements est assuré par les Ordres de transport (OT) de SAP. Fig 12 - Les environnements d ARP BW L environnement de développement (EBA) : destiné à la phase de développement. C est le seul environnement où les créations, modifications et suppressions manuelles des objets BW (DSO, Cube, Master Data ) sont autorisées. Les objets dans cet environnement ne contiennent pas forcément des données. Une fois finis, les objets sont passés les environnements d intégration. L environnement de test d intégration (TBA) : destiné aux tests d intégration de l équipe de projet. Dans TBA, il est important que cet environnement contienne des données significatives afin de pouvoir effectuer tous les cas de test. L environnement de qualification (QBA) : destiné aux recettes (test d utilisateurs). Les données de test en QBA doivent être une copie des données de production. A la fin de la phase de validation, les objets sont transportés en PBA pour la mise en production. L environnement de production (PBA) : destiné au déploiement de l application. Déjà développés et testés, l application y est utilisée par les utilisateurs finaux. 21

22 La validation de l application avec HPQC HP Quality Center (HPQC) est le leader logiciel dans la gestion de qualité informatique. Dans One Report, HPQC est utilisé sous forme d un SaaS (software as a service c est-à-dire une application client légère déployée via un navigateur d Internet) dans la phase de test pour rédiger des scénarios, des cas de test et gérer les anomalies de l application testée. Ce logiciel permet aussi de vérifier la traçabilité entre les exigences de l application et les cas de test afin d assurer une couverture totale des cas de test sur l ensemble des cas d utilisation. Avec l historisation des résultats de test, les testeurs peuvent suivre tout le cycle de vie d une anomalie détectée durant ces tests afin de décider des actions correctives nécessaires. Enfin, travaillant sur un système de qualification unique, l équipe de projet peut avoir une vision commune sur l état des tests et mieux communiquer des problèmes. La participation à la phase de vérification et de validation des applications dans le cadre de mon dernier stage chez Airbus m a été utile et a faciliter l utilisation de ce logiciel sur les activités de test de One Report Les travaux réalisés Durant le stage, j ai eu l occasion de participer à toutes les phases du projet dans le contexte industriel, depuis la réception du cahier des charges (le BSD) jusqu au test utilisateurs. Pourtant, mon intervention n a pas suivi l ordre classique des phases d un projet. Au moment où je suis arrivé au projet (Décembre 2012), la phase de spécification de l itération 1 a été finalisée et le développement était en train d être réalisé par l équipe indienne. C est pourquoi mes premières tâches étaient des tests de validation des objets livrées par les équipes offshore en Inde. En réalité, suite aux différentes difficultés, cette phase a dû prendre plus de temps que prévu. Elle m a permis de monter en compétences sur les techniques de SAP BW et ABAP. Dans un second temps, dès le lancement de la deuxième itération, j ai travaillé sur la spécification et le développement des objets BW. Ce travail a consistée à spécifier les objets BW, les règles de calcul et à développer des chaines de processus des données (process chain). Mes travaux réalisés sont détaillés dans les parties suivantes Validation Test d intégration La phase de test d intégration a été lancée après le développement. En réalité, pour mieux comprendre les règles spécifiées de One Report, j ai commencé par la rédaction des scénarios de test. Les scénario sont écrits en se basant sur la matrice de compliance élément capital du projet qui permet de valider que tous les besoins sont couverts et tester. Les cas de test d intégration sont basés sur les objets BW (un cas de test par DSO, Cube ou Report créé) et la couverture des objets BW sur l ensemble des exigences est précisée dans la matrice de compliance produite par les analystes durant la spécification. 22

23 J ai commencé par le test de certain objet de la fonctionnalité dépréciation de One Report (cf. figure 6), notamment le DSO HFIAX801 (cf. Annexe Architecture technique détaillée) contenant les données sur les valeurs brutes et les quantités MM-FI des matériels agrégées par centre de profit et par évaluation harmonisée. C est un des 3 DSO de base de One Report (HFIAX801, HFIAX802 et HFIAX803) contenant plus de 30 règles de calcul, d extraction et de transformation. Puisque tous les reports et les autres objets de la couche Datamart de l itération 1 doivent se baser sur son contenu, le test de HFIAX801 est important et primordial. Les cas de test sont rédigés dans le test plan de HPQC. Un cas de test est composé de plusieurs étapes. Pour chaque étape, j ai défini la description des actions de test et le résultat attendu. Dans le cas de HFIAX801, il s agit de saisir les données en entrée et de vérifier si les données existent dans ce DSO et correspondent bien aux règles de calcul. Le calcul de ces résultats attendus doit être fait par moi-même à partir des données sources. Cette tâche a nécessité que je travaille avec les analystes du projet de manière à ce qu ils m expliquent les règles fonctionnelles. Ce travail préliminaire est absolument nécessaire pour assurer une qualité des cas de tests. Fig 13 - Un scénario de test rédigé sur HPQC Les tests sont ensuite réalisés sur le test lab de HPQC. Pour chaque cas de test, le réalisateur doit suivre la description de chaque étape et vérifie la cohérence entre les résultats attendus et les résultats réels. Dans le cas de problèmes, des anomalies sont créées avec une description attachée. Dans One Report, des copies d écran de test sont obligatoires afin d assurer la traçabilité vis à vis du client, des tests réalisés mais aussi pour permettre au développeur de mieux comprendre l anomalie. 23

24 Fig 14 - La réalisation d un test sur HPQC Durant le test, la difficulté majeure que j ai rencontrée était le manque des données de test parce que tous les objets n ont pas été chargés et les données n ont pas été fournies par le business. De ce fait je n ai pas pu réaliser l intégralité du périmètre de mes tests. Plusieurs solutions sont possibles dans le cas de manque de données : 1 Création manuelle de données. Ceci n est pas possible dans l environnement de test à ma disposition du fait de la définition des droits dans cet environnement. 2- Vérification partielle en faisant une relecture de code. Bien évidemment, cette façon de tester ne peut pas assurer une qualité du développement mais elle permet de réduire les risques Gestion des anomalies Lors de mon retour à l entreprise, suite aux 2 semaines de cours à l université, presque tous les tests avaient été réalisés. J ai alors été chargé de la gestion des anomalies. Une anomalie est créée durant le test lorsque le résultat ne correspond pas au scénario prévu. Pour une anomalie, il faut définir son type (défaut, amélioration, observation, question), sa classification (fonctionnelle ou technique), son niveau d impact (bloquant, majeur, mineur), sa reproductibilité, sa description et communiquer ensuite l anomalie au correcteur correspondant (par mail et par fichier de communication). Une fois créée, l anomalie est enregistrée dans le centre des défauts de HPQC avec un statut «New». La réception de l anomalie est confirmée par le passage en état «Open» par le Chef de projet qui valide toutes les anomalies. Les actions analytiques et correctives sont ensuite mises en place pour détecter la cause du problème et sa solution (soit la modification de la spécification, soit la correction du code, soit la remise en question les règles fonctionnelles). Après avoir résolu le 24

25 problème, le correcteur passe l anomalie en statut «Fixed». Cette anomalie doit être re-testée et clôturée par le détecteur. Fig 15 Le suivi d une anomalie sur HPQC Quand je suis rentré de l université, dans HPQC, le nombre d anomalies était plus de 70 et la plupart entre elles n ont pas été clôturées. Dans un premier temps, j ai pris le temps pour analyser tout l ensemble de ces anomalies et définir la priorité de chacune selon la sévérité, la date de création J ai commencé par les problèmes bloquants, puis les majeurs et les mineurs. Pour une anomalie technique, il me fallait vérifier si elle était bien corrigée sur l environnement de développement (EBA) et transportée à l environnement de test (TBA). Ensuite je devais relancer le cas de test correspondant sur TBA et vérifier si le problème se reproduisait ou non. Il fallait aussi que je m assure de la correcte modification des spécifications dans le cas d un bug fonctionnel. Cette modification doit ensuite être développée par les équipes offshore. Je devais alors valider que le développement était correcte. Si le problème a été bien réglé, je le clôturais et communiquais au correcteur. Bien évidemment il y avait certains défauts que je n étais pas capable de re-tester et clôturer à cause du manque de connaissances (surtout des défauts remontés par le BICC). Dans ce cas, il m a fallu adresser au détecteur de l anomalie pour demander son avis. Enfin, la gestion de ces anomalies m a permis d avoir une vision globale sur les objets One Report, de mieux appréhender les normes et les exigences de développement d une application. 25

26 Spécification Spécification générale Fig 16 - Le schéma étoile général One Report Une fois la phase de test terminée, la deuxième itération a commencée par une phase de spécification. Cette phase est basée sur le BSD (Business solution dossier) qui nous sert de cahier des charges. Ce document contient l explication des fonctionnalités de l application One Report, des règles de gestion du domaine financier d Airbus, un dictionnaire des données utilisées et une liste des exigences obligatoires et optionnelles précisées par le client. Airbus a aussi fourni à l équipe Sopra un schéma étoile des données afin de préciser les données principales à remonter. Une première version de l architecture de l application décrite dans un ARD (Application Architecte Overview) a été aussi étudiée par l ISPL chez Akka (SSII concurrent de Sopra). Il s agit d un document décrivant l architecture générale de tous les flux de données (depuis les datasources jusqu aux infocubes) développés dans l application. A partir du cahier des charges et l ARD initiale, dans un premier temps, l équipe front office One Report travaillait sur l architecture générale de l application, afin de compléter cet ARD. (cf. annexe) Une liste des objets (Master Data, DSO, Cube ) utilisant cet ARD devait être définie, ces objets peuvent être existants (fournis par le BICC) ou nouveaux (créés par l équipe). En général, chaque dimension du cube dans le schéma de l étoile est associée à un DSO ou un Master Data. Les données sources sont extraites depuis les systèmes SAP R/3 par les datasources et sont stockées dans l entrepôt de données (couche X). Ces données sont quasiment brutes car il y a rarement des 26

27 transformations au cours de l extraction. Elles sont ensuite montées au magasin de données (couche H) où les règles de calcul et de transformation sont mises en place. Selon la norme d Airbus, tous les objets de la couche H doivent être propres au projet One Report et créés par nous-mêmes. Pour les objets de la couche, toutes les modifications ou créations doivent être validées par le centre de compétences BI Airbus. Une fois mise à la disposition à une équipe de projet, l objet de la couche X ne peut pas être travaillé par un autre projet tout au long du projet affecté. Ensuite, nous devions aussi préciser dans l ARD le mode de chargement (full, delta), la fréquence (mensuel, journalier ou à demande) et l ordre de chargement des objets. Ces informations serviront à la spécification des chaines de processus de données (process chains). Je me suis occupé de compléter l ARD de tous les pays. En se basant sur les flux de données de l Allemagne spécifiés dans la première itération, j ai ajouté d autres flux similaires de la France, de l Espagne et du Royaume-Uni en tenant compte des règles spécifiques de chaque pays. Fig 17 Les flux de données One Report Provision d Allemagne (à gauche) et des autres pays(à droite) (Extrait de l ARD One Report) Cette phase s est terminée par la définition des règles de spécification générale. Pour ce faire, un AGD (Application General Dossier) a été créé. Ce document est une version détaillée de l ARD en précisant toutes les règles de spécification correspondant à chaque flux de données (les champs à remonter, les filtres, les transformations générales ). Nous devions aussi défini dans l AGD les environnements du système (les systèmes sources et cibles de l application), tous les objets utilisés par l application, une description détaillée des flux de données, des variables globales, des impacts sur les autres projets interdépendants 27

28 Fig 18 - Le schéma étoile mis dans l AGD Une matrice de couverture a été étudiée en parallèle pour assurer la cohérence entre ces règles et les exigences du client. Chaque objet BW (DSO, module fonction, programme, report ou chaine de chargement) créé doit répondre à au moins une exigence et toutes les exigences de type obligatoire présentées dans le cahier des charges doivent être associées à une règle de spécification. Les derniers documents à produire durant cette phase sont des SD (spécification dossier). C est une version officielle de la matrice de couverture. Je me suis chargé de mettre à jour cette matrice en ajoutant les règles de spécifications de l itération 2 et rédiger les SD correspondants. Pour cette tâche, j ai dû analyser le BSD et l AGD pour comprendre des exigences et des règles de spécification. Finalement, avec l aide de l ISPL et de l équipe One Report, j ai pu compléter la matrice et livrer les SD aux clients. La spécification générale permet d avoir une vision globale sur l application. Elle nous a aussi permis d identifier les points d incompréhension et de les discuter au cours des workshops organisés avec le business et le responsable de projet. A la fin de cette phase, un prototype de la solution finale a été montré et validé par le client afin d éviter des changements de spécification majeurs dans les phases suivantes Spécification détaillée Après avoir défini une solution générale, la spécification détaillée est commencée et elle sera destinée aux développeurs. C est pourquoi, dans cette phase, les règles sont spécifiées de façon plus détaillées et les aspects techniques SAP BW sont ajoutés. 28

29 L extraction et la restitution des données La partie importante de la BI est l extraction et la restitution des données en tenant compte les règles de gestion pour obtenir des informations décisionnelles utiles. Le document spécifique à cette partie est le Dataflow. Selon mon observation, le Dataflow est le document central du projet, qui contient presque toutes les spécifications principales d un objet de l application. C est aussi la partie de la spécification où l équipe de projet devait passer plus de temps. Fig 19 - Le dataflow du DSO HFIAX801 Chaque objet BW (DSO, Master Data, Cube) est associé à un seul Dataflow. Ce dossier spécifie tous les flux de données alimentant l objet en sujet. Pour chaque flux, nous identifiions les champs sources à remonter et les champs correspondants dans l objet cible ainsi que l objet source, le système source et le format du champ (chaine de caractères, unité, nombre entier, date ). Il nous a été demandé aussi d intégrer la partie de l ARD concernant cet objet dans ce document. Entre les données sources et les données cibles, les règles de transformation devaient aussi être définies. Les règles sont catégorisées en différents types soit une jointure, un module fonction, une extraction, une transformation ou une routine (l ensemble de règles consécutives). Une règle doit être expliquée fonctionnellement, c est-à-dire qu il nous fallait éviter d utiliser directement le code afin de faciliter la validation du client. L exemple d une règle que je peux citer est la restitution de la quantité du stock dans une location à partir du DSO «Mouvement de stock». Ce champ est contenu dans le DSO HFIAX802 qui servira à faire l inventaire de stock. Pour chaque mouvement de stock, il faut déterminer s il s agit d'une entrée ou d'une sortie en se basant sur la clé spécifiée par SAP BW. o Si la clé est 100, 101, 104, 105, 106, 110 et le composant est MM (module SAP matériel management) alors il s agit d une sortie de stock. o Sinon si la compagnie est Airbus France, la clé est 412, le type du matériel est CMSE alors il s agit d une sortie de stock (cette règle est spécifiée pour le système France). 29

30 o Sinon si la clé est 000, 001, 004, 005, 006, 010 et le composant est MM (module SAP matériel management) alors il s agit d'une entrée de stock. S'il s agit d une entrée de stock, alors stock actuel = stock actuel + quantité entrée. Dans l autre cas, stock actuel = stock actuel quantité sortie. Pour les règles plus compliquées, nous spécifiions dans une SAP Analysis à part et mentionnée dans le Dataflow correspondant. Elle sert à spécifier toutes les règles ou les fonctions complexes qui ne peuvent pas être détaillées dans le Dataflow sous forme d un algorithme de langage pseudo-code. La SAP Analysis, contrairement aux autres livrables, n est pas imposée par un template particulier. C est pourquoi pour certains projets, un seul SAP Analysis a été produit. Dans One Report, nous avons décidé de produire un SAP Analysis pour chaque objet ou chaque module fonction. Voici l extrait de la SAP Analysis de la fonction ZFI_GET_LOCAL_UNIT écrite par moi-même. Il s agit d une fonction restituant l unité de mesure d un matériel du système source local étant donné l unité harmonisée dans le système ARP, le numéro identifiant du matériel, le système source et le pays du système local. L algorithme de cette fonction : Les paramètres d entrée : - Le système source (ARP, Allemagne, France, Royaume-Uni, Espagne) - L unité harmonisée (utilisée dans le système ARP) - Le numéro du matériel - Le pays local. (France, Royaume-Uni, Allemagne, Espagne) Le paramètre de sortie : - L unité locale (utilisée dans le système local). 1. Chercher dans le DSO XPPT0061 (contenant des unités de mesure) pour récupérer les systèmes source, les unités locales et les harmonisées correspondantes. 2. Calculer l unité du système local : Regarder si les unités locales correspondent à l unité harmonisée en entrée. o Si une seule unité locale correspond à l unité harmonisée, le résultat est cette unité locale. o Si plusieurs unités locales correspondent à l unité harmonisée, il faut regarder dans la Master Data XMATERIAL et vérifier le système source en entrée. Si ce système source n est pas ARP (donc FR, GE, UK, ES), il est suffisant de récupérer l unité locale correspondante au système source et au numéro matériel en entrée. Cette unité est le résultat du calcul. 30

31 Si ce système source est ARP, il faut récupérer l unité locale ayant le système source local correspondant au pays entré. Cette unité est le résultat du calcul. L extrait de la SAP Analysis de cette fonction. Description : Input Source system: I_XSOURSYST TYPE: XSOURSYST Unit of measurement ARP I_XUNTRF TYPE: XBASE_UOM Material number I_XMATERIAL TYPE: XMATERIAL Country INPUT I_HCOUNTRY TYPE: HCOUNTRY Output Local unit measure O_BASE_UOM TYPE: XBASE_UOM Treatment : Read XPPT0061 in order to retrieve XSOURSYST, XBASE_UOM, XUNTRF. Data will be put into the internal table T01. /*Management of duplicate rows Move all of duplicate rows to another internal table (T02, those rows are deleted from T01. /*Calcul of Local unit of measure*/ Read the table T02 With key Source system = I_XSOURSYST Base unit of measure ARP = I_XUNTRF If found /*Input unit of measure ARP corresponds to many local unit of measure Check I_XSOURSYST: If I_XSOURSYST = XEA, /*Input material is harmonized Check the I_HCOUNTRY: If I_HCOUNTRY = FR then LW_SOURSYST = XGI If I_HCOUNTRY = DE then LW_SOURSYST = XDA If I_HCOUNTRY = GB then LW_SOURSYST = APD If I_HCOUNTRY = ES then LW_SOURSYST = SPA Look up into XMATERIAL in order to get Base unit of measure (BASE_UOM), selection fields: XHM_NB = I_XSOURSYST XSOURSYST = LW_SOURSYST O_BASE_UOM = BASE_UOM Else /*Input material is local Look up into XMATERIAL in order to get Base unit of measure (BASE_UOM), selection fields: XMATERIAL = I_XMATERIAL XSOURSYST = I_XSOURSYST O_BASE_UOM = BASE_UOM End if. If no data found then raise exception NO_DATA_FOUND Else /*Input unit of measure ARP corresponds to only 1 local unit of measure Read the table T01 (which contains no duplicate rows from XPPT0061) in order to retrieve base unit of measurement Natco (XBASE_UOM), With key XSOURSYST = I_XSOURSYST 31

32 XUNTRF = I_XUNTRF O_BASE_UOM = XBASE_UOM End if. Le chargement des données Une fois la structure des objets avec toutes les règles de calcul et de restitution bien spécifiées, il reste à définir des process chains qui permettront le lancement de l application en production suivant une schedule précis... Selon les exigences exprimées par le client, au premier jour de chaque mois, les données financières et logistiques des systèmes de production doivent être remontées dans le système décisionnel. Au 4 e jour du mois, toutes les données doivent être calculées et chargées dans tous les objets et l utilisateur peut lancer les requêtes de reporting sur ces informations. Pour ce faire, SAP BW met en place des chaines de processus automatisées. Il s agit d une suite d opérations «simples» (chargement ou déchargement d un objet, l activation des données, lancement d un programme, appel d une fonction ) liées les unes aux autres par les liens logiques (si succès, si échec, ET, OU ) ou les étapes de décision. Elle est généralement utilisée pour les actions sans intervention humaine (chargements nocturnes ) ou de sauvegarder mes actions exécutées manuellement souvent répétées. Tous les process chains sont spécifiés dans un document DLS unique (Data Loading Sequency). Pour chaque process chain, nous avons défini la condition de démarrage, l objet chargé ou éventuellement les sous-chaînes. Il est interdit de lancer deux chargements sur un même objet. De plus, les chargements sont interdépendants entre eux (par exemple, pour charger un champ de l objet A, il faut aller consulter les données dans les objets B et C, donc il est obligatoire que ces objets aient été chargés). Pour ces raisons, il nous fallait définir des événements afin de faire communiquer les process chains. Une process chain, avant de charger un objet ou d aller consulter un autre objet, doit vérifier dans la liste des événements pour savoir si le chargement de l objet en question a été fini ou non. Si oui, cette process chain est interrompue jusqu à ce qu elle reçoive un événement marquant la fin du chargement bloquant. Fig 20 Le Data Loading Sequency One Report 32

33 La présentation des données sous forme des reports Lorsque toutes les données sont transformées en informations décisionnelles dans le système BI, nous avons décrit la présentation des données sous forme des reports. SAP BW fournit trois formats pour les reports : Excel, PDF et en Web. Dans ce cadre de One Report, seuls les reports en Excel sont demandés. Le contenu des reports (les données représentées) est précisé dans le BRD. La spécification d un report est réalisée à l aide du Data Access. Dans ce Data Access, nous devions indiquer les caractéristiques et leurs types (fixés ou libres les attributs non affichés par défaut mais peuvent être ajoutés dans le tableau reporting par la fonction drill-down), les ratios, les autorisations (par exemple des comptables françaises ne peuvent que consulter les données du système d Airbus France) et les critères de sélection des données. Au niveau des Data Access, les règles de restitution sont rarement définies. En fait, nous n avons précisé que les petits calculs des ratios ainsi que des règles spécifiques de présentation (couleur, graphique ). Un exemple du report doit être joint à la fin du Data Access pour assurer une bonne compréhension des développeurs Développement Les tâches de développement sont généralement réalisées par l équipe Sopra India. Pourtant, dans le but de participer à tous les phases du projet, le développement des process chains m a été confié. Le développement des process chains sur SAP BW utilise une interface graphique simple et efficace. Je me suis chargé de développer les process chains de chargement des objets de couche X et quelques objets de la couche H. Dans la couche X les objets utilisés par One Report peuvent être existants ou créés par l équipe de projet. Pour cela, il m a fallu créer des process chains de chargement des nouveaux objets et modifier les process chains existants. Voici un exemple sur un process chaine typique que j ai développé : le chargement du Cube HFIAX80C7. Les étapes de cette process chaine sont : 1. Démarrer de la chaine. 2. Attendre des événements XFI_E067 (fin de chargement de XFICTRL1), HFI_E020 (fin de chargement de HFIAX801), XFIMBEW1_DE (fin de chargement de XFIMBEW1) 3. Étape de décision : a. Si la date du jour est le 3 e jour du mois, continuer la process chain b. Sinon, si l heure actuelle est >23h50 ou <14h, continuer la process chain c. Sinon, attendre jusqu à 23h50 pour continuer la process chain (dans ce cas, j ai développé un programme bloquant la chaine jusqu à 23h50). 4. Supprimer les indexes du cube HFIAX80C7 5. Lancer le DTP de chargement du cube HFIAX80C7 6. Recréer l index du cube HFIAX80C7 33

34 7. Calculer les statistiques de données du cube (pour les raisons de performance). Cette chaine a été développée et testée unitairement sur EBA par moi-même. Elle est ensuite transportée et testée sur TBA par l équipe testing. Fig 21 - La process chain de chargement du cube HFIAX80C7 34

35 Livrables En plus des documents techniques, Airbus impose aussi la livraison d autres documents. Ces documents ne sont pas destinés aux développeurs, ils contiennent des informations nécessaires pour préparer la mise en production de l application. Le RAD (Roles&Authorizations Dosser) définit des rôles pour les développeurs, les testeurs et les utilisateurs de l application. Pour chaque acteur, une liste des activités autorisées est définie (manager les objets, lancer les requêtes ). Dans One Report, 4 groupes d utilisateurs sont définis : Data admin : autorisation de toutes les actions sur les objets de données BW (DSO, Cube ). Query designer : autorisation de toutes les actions sur tous les reports One Report. Delegated admin : autorisation de l attribution des rôles aux utilisateurs One Report. End user : autorisation de lancement des reports. Ce document est destiné aux SAP Rights (le service de gestion des rôles des systèmes SAP Airbus). En effet ce n est pas le projet qui crée directement les rôles associé. Toute la gestion des rôles est centralisée selon les exigences d Airbus). Le Data Sizing est un document contenant toutes les informations techniques de tous les objets de l application. Ce document est nécessaire pour mesurer le volume des données et la performance de One Report. Dans le Data Sizing, l équipe de projet doit préciser pour chaque objet le nombre de données chargées, la fréquence de chargement de données, la taille et le partitionnement des objets. Grâce à ce document, nous pouvons estimer le volume de données du projet et assurer une bonne intégration dans le plan de production. Le MIV/MIP (mise en validation et mise en production) est un document contenant la description et le détail de tous les ordres de transport de l application sur le système SAP R/3 et SAP BW. Comme l application sera transportée vers l environnement de production PBA durant la phase de déploiement, ce document doit définir le planning et le scénario des processus de transport ainsi que les codes de retours et les ordres de corrections. Ces documents sont uniques pour toutes les itérations et ne seront livrés qu à la dernière itération pour la mise en production de One Report. Comme One Report n est pas encore passé à la production, ils ne sont pas finalisés pour le moment. Les seuls livrables non produits pas l équipe front-office sont les dossiers de test. Bien évidemment, ils sont rédigés par l équipe testing. Voici un bilan sur les livrables du projet One Report selon chaque phase : Spécification (M5-M7) : ARD : Validé par ISPL, BICC (couche X), IMSB (responsable de production Airbus) AGD : Validé par ISPL, BICC (couche X) 35

36 Dataflows : Validé par ISPL Data Sizing (init) : Validé par ISPL, IMSI (administrateur système Airbus) Data Access : Validé par ISPL, IMSB RAD (init) : Validé par ISPL, SAP Rights Développement (M7-M9) : Dataflows (mise à jour) : Validé par ISPL, BICC (couche X) MIV : Validé par IMSI (couche X) DLS (init) : Validé par IMSB Intégration (M9-M10) DLS : Validé par ISPL, IMSB Dataflows (mise à jour) : Validé par BICC (couche X) RAD : Validé par SAP Rights Validation (M10-M11) MIV : Validé par IMSI MIP : Validé par IMSI Data Sizing (finalisé) : Validé par IMSI Test dossier : Validé par IMSB DLS (finalisé) : Validé par IMSB Production (M11-M15) Tous les documents : Validés par ISPL Back up procedure : Validé par IMSB Incident report : Validé par IMSB Knowledge transfer : Validé par IMSB 36

37 3. Sujet de réflexion : L offshoring d un projet informatique Introduction Choix du sujet L offshoring, le nearshoring, l onshoring Nous entendons parler de ces termes chaque jour comme une des stratégies incontournables des SSII françaises et internationales. Chaque année, des centres de services sont ouverts aux quatre coins du monde : Malaisie, Vietnam, République Tchèque, Maroc Ces tendances de délocalisation des ressources sont aussi la source de nombreux débats, sur leurs bénéfices et leurs impacts sur le plan macroéconomique. Malgré tout, cette stratégie ne semble jamais démodée pour les entreprises voulant trouver une solution pour augmenter l efficacité de leur production. Même si ce n est pas toujours le cas Durant mon stage, j ai eu l occasion de participer à un projet offshoring, One Report, qui est composé de 2 équipes, une équipe front office en France, une back office en Inde. Étant à la fois observateur et acteur de ce projet, j ai décidé de choisir l offshoring comme sujet de réflexion. Dans un premier temps, je vais vous parler de l offshoring, sa définition, ses enjeux et la situation actuelle des entreprises dans ce phénomène... Ensuite, je vais présenter le point de vue de Sopra Group, un des acteurs majeurs déployant cette stratégie, sa méthode de mise en œuvre ainsi que les expériences que j ai pu retenir du projet offshore One Report. Je terminerai par une analyse globale de l application des méthodes agiles dans un contexte d offshoring, une des solutions récentes pour réduire les risques autour de la délocalisation des projets informatiques Définition L offshoring désigne la délocalisation des activités de service ou de production de certaines entreprises vers des pays à bas salaire. Il se compose de 2 catégories différentes : l offshoring informatique, et l offshoring des business process (les processus métiers). Le premier, présent dans les activités des SSII (IBM, Accenture, Capgemini, HP-EDS, Sopra Group ), consiste dans la plupart des cas à externaliser une partie des activités de l entreprise, le développement, le test et la maintenance d un système d information. Mais pour d autres sociétés, dans les domaines comme l aéronautique Airbus ou Boeing - ou les grands groupes technologiques comme Samsung, LG, HTC, Apple, l offshoring consiste à ouvrir des sites de fabrication dans différents pays pour pouvoir profiter de la variété des ressources ou élargir leurs marchés. Le BPO (business process offshoring) concerne la délocalisation des autres services de l entreprise comme les activités financières, de ressources humaines et de marketing Dans le cadre de ce sujet, je vais analyser le cas d offshoring des projets informatiques. Les bénéfices connus de l offshoring sont une réduction des coûts, une meilleure disponibilité du personnel qualifié et un travail plus efficace. Mais ce service est aussi critiqué à cause du transfert de l emploi vers les autres pays ainsi que des risques géopolitiques, de la communication inefficace et des conflits culturels. Il faut bien distinguer l offshoring de l outsourcing. Nous pouvons trouver dans certains documents l utilisation de l offshoring et de l outsourcing pour désigner la même chose. En fait, ces 37

38 deux termes ne sont pas tout à fait synonymes. L outsourcing est un contrat passé entre 2 entreprises. L externalisation dans ce cas revient à confier à la société tierce tout ou partie d une fonction de l entreprise, la relation est de type client et prestataire de services externe. Ce contrat est utilisé habituellement pour bénéficier des compétences spécialisées, des économies de coût et de main d œuvre. Contrairement à l offshoring, l outsourcing fait courir le risque à l entreprise cliente d une dépendance au prestataire à cause du manque de connaissances et de ressources internes. Nous pouvons dire aussi que l offshoring est un cas particulier d outsourcing, où le client et le prestataire travaillent pour une même entreprise, mais implanté dans différents pays. Fig 22 Le business modèle des services outsourcing et offshoring 1 Le schéma ci-dessus résume la relation entre ces 2 concepts clés d externalisation. L offshoring est basé plutôt sur la notion de la localisation géographique (soit au pays domicile soit à l étranger) tandis que l outsourcing est défini selon l utilisation des ressources internes ou externes. Le marché global définit 5 catégories de services en se basant sur ces deux dimensions. Nous pouvons trouver les différents scénarios. L entreprise décide d «outsourcer» (utiliser les ressources externes) ses services à un prestataire local (cas 1). C est le cas des projets dans le domaine aéronautique dans la région Midi-Pyrénées, où EADS, ou sa composante Airbus, décide de sous-traiter ses projets à plusieurs prestataires de services (Labinal, Safran, les SSII Sopra, Sogeti, AKKA, Cap Gemini ). Elle peut aussi choisir des prestataires étrangers (cas 2 et 3). L entreprise peut aussi décider d ouvrir ellemême son centre de services à l étranger, déléguer la partie développement (cas 4) ou les activités pilotage du projet (cas 5). Ce dernier cas se produit souvent entre une filiale de l entreprise à l étranger et un fournisseur tiers. De nos jours, l offshore des services informatiques est une pratique de plus en plus dominante dans le business global. Le chiffre d affaires de ce type était de 250 millions de dollars à la fin des années Aujourd hui on annonce, selon les recherches de Dubaï Outsource Zone, que le 1 Sako, Mari. (2005). "Outsourcing and Offshoring: Key Trends and Issues". Livre présenté au Forum des marchés émergents. Oxford, Royaume-Uni. 38

39 marché mondial de l offshoring pourrait atteindre les 479 milliards de dollars en Cette croissance des services offshoring informatiques est liée à la disponibilité de grandes quantités d infrastructure de communication qui se sont développées grâce aux technologies d Internet et de télécommunications. Il existe aussi le terme de nearshoring, l implantation d une activité dans un pays proche de l entreprise (pour une société française, ce sont les pays d Europe ou du Maghreb), et l inshoring le fait d utiliser une filiale à l intérieur de son groupe afin de réaliser une prestation informatique Le marché offshore international Fig 23 - Le nombre des centres offshore dans les pays du monde L offshoring est actuellement une des stratégies principales des SSII internationales et françaises, qui leur permet d augmenter la productivité et la rentabilité 3. Chaque année, malgré la crise économique, ces entreprises investissent de plus en plus dans la construction de leurs centres offshore. Aujourd hui, les pays les plus attractifs du monde offshoring, en dehors de l Inde, sont la Chine, le Vietnam, les Philippines, la Roumanie, la République Tchèque et les pays d'amérique Latine Les pays de services offshore Selon une analyse de Gartner Group, en 2011, les 30 pays les plus dynamiques et intéressants pour la délocalisation de services informatiques sont 4 : Amériques: Argentine, Brésil, Chili, Colombie, Costa Rica, Mexique, Panama et Pérou. 2 Michael Byrne. Global outsourcing market to touch USD 479 billion by Industry Watch, News. Publié le 7 juin Dominique Filipponne. «Dix SSII reines de l'offshore». Article sur JournalDuNet. Publié le 24 Octobre Gartner Group. Eight New Countries Moved into the Top 30. Egham, UK, December 20,

40 Asie / Pacifique: Bangladesh, Chine, Inde, Indonésie, Malaisie, Philippines, Sri Lanka, Thaïlande et Vietnam. L'Europe, le Moyen-Orient et Afrique: Bulgarie, République Tchèque, Égypte, Hongrie, Maroc, Ile Maurice, Pologne, Roumanie, Russie, Slovaquie, Afrique du Sud, Turquie et Ukraine. Avec de nombreux effectifs travaillant dans le domaine de l informatique (25% des travaux professionnels en Inde sont liés à l informatique) et nouveaux ingénieurs sortant des universités chaque année, l Inde est considérée comme un pays offshore incontournable. Les grandes SSII indiennes aujourd hui ont un chiffre d affaires annuel de 28,7 milliards dollars. Les autres pays «low-cost» européens ou d Afrique du Nord ont aussi compris les avantages qu ils peuvent en tirer. Selon le directeur international d Akka Technologies, qui a implanté un centre offshore en Roumanie, Stéphane Descos, les Pays les plus proches de la France géographiquement et culturellement parlant, comme la Roumanie et le Maroc, demandent moins d'encadrement, et dégagent souvent une meilleure productivité. En Asie, malgré une différence de culture forte et souvent difficile à franchir, les chiffres du marché offshore ont sans cesse atteint des plafonds. A côté du géant indien, les entreprises occidentales passent aujourd hui aux pays du Pacifique. Capgemini est un pionnier sur ce chemin, en ouvrant des filiales en Chine (1037 personnes), aux Philippines (182 personnes) et au Vietnam (139 personnes). La Chine, avec des caractéristiques similaires à son voisin indien, est considérée aujourd hui comme étant une nouvelle destination offshore majeure Les géants des sociétés offshore IBM est actuellement le leader mondial dans le domaine de l informatique, et dans l offshoring, cette géante «Big Blue» (telle qu on appelle cette entreprise) est aussi la pionnière. Sa première délocalisation est commencée en 2004 par l achat de l indien Daksh e-services, spécialisé dans les centres d appels. A la fin de 2009, le nombre d effectifs global d IBM s élève à collaborateurs avec seulement 25% localisés aux États-Unis contre 33% en Inde! 5 Accenture, un autre acteur majeur du monde informatique, est connu par son réseau de centre offshore. En septembre 2012, Accenture comptait employés dans plus de 120 pays dont en Inde. Une forte stratégie de délocalisation permet à cette société de fournir une grande variété de services. Aujourd hui, la liste des clients d Accenture est à plus de 75% de Fortune Global 500 (les 500 entreprises mondiales classées selon l'importance de leur chiffre d'affaires) et 94% du top 100 de cette liste. Le leader des SSII français dans le domaine offshore est Capgemini qui a commencé par acheter la SSII indienne Kanbay pour 1,25 milliards de dollars en Elle comptait employés 5 Working America & AFL-CIO. Sending jobs overseas: The cost to America s economy and working families. Washington, DC

41 offshore en 2010 sur un total d'effectifs de , dont en Inde. En 2012, Capgemini a recruté encore ingénieurs en Inde et presque 3000 dans les autres locations offshores. La stratégie de cette société est de devenir un acteur majeur mondial du monde informatique comme IBM et Accenture et d élargir encore sa base clientèle avec un nombre de salariés offshore prévu (soit le double de celui en 2010). Les SSII indiens TCS (Tata Consultancy Services), Infosys technologies et Wipro technologies apparaissent aussi dans le top 11 des meilleurs fournisseurs des services offshore mondial. Le leader TCS de services informatiques indiens aujourd hui compte investir dans la politique de développement vers l extérieur avec l acquisition de la société française Alti pour 75 millions. Aujourd hui, la société réalise un chiffre d affaires de 100 millions grâce aux gros contrats signés avec SFR et Michelin. Infosys, présent en France depuis 2001, a obtenu en 2009 un résultat de 45 millions en chiffre d affaires selon une estimation du cabinet Pierre Audoin Consultants (PAC). Le dernier SSII indien présenté dans le top, Wipro, après une dizaine d années en France, compte 300 employés avec un chiffre d affaires annuel de 300 millions en 2011, soit 10 fois plus élevés qu en Aujourd hui, ces sociétés indiennes continuent de consolider leurs images et leurs positions sur le marché international, d'augmenter la confiance des clients et de renforcer leur niveau de compétitivité Les enjeux Les bénéfices Le phénomène offshoring semble évident. Mais pourquoi les entreprises le considèrent comme incontournable? Pourquoi presque toutes les grandes sociétés dans le monde des services informatiques ont déployé cette stratégie? Quels sont les bénéfices? Un premier avantage qu apporte l offshoring est sur le plan financier. La délocalisation, permet à l entreprise, avant tout, de réduire ses coûts de production. Cette réduction est le résultat de plusieurs facteurs, notamment la réduction du coût des ressources Pour en avoir une vision précise, voici la table de comparaison de charges des salariés américain et indien dans le secteur informatique : États-Unis Inde Salaire brut annuel 42,927 USD 6,179 USD Coût G&A 8,571 USD 1,000 USD Télécom 1,500 USD 2,328 USD Dépréciation 3,000 USD 1,500 USD Montant total 58,598 USD 11,854 USD Ce tableau montre la différence de charge que l entreprise doit supporter pour un informaticien américain et un informaticien indien (plus de USD par personne par an). Cette différence est due à l écart du salaire à temps plein, des coûts généraux et administratifs (coût de déplacement, des charges sociales ), etc. L entreprise peut encore bénéficier cet écart de charges 41

42 dans d'autres pays comme la Chine (3000 USD), la Thaïlande (4500 USD), le Vietnam (2500 USD) 6 Bien sur, dans ces pays, les coûts administratifs sont beaucoup moins élevés. Nous pouvons constater que la délocalisation en Inde, par exemple, permet à l entreprise de réduire jusqu à 80% son coût du personnel (!), et que la charge d un informaticien américain est équivalente à celle de 5 informaticiens indiens! C est surtout cette raison qui motive les entreprises d entrer dans le monde offshore. A côté des avantages de charges du personnel, la délocalisation dans les pays «low-cost» permet aussi de bénéficier des avantages fiscaux. Chaque pays, selon leur politique, adopte des droits d imposition différents. Dans certains états, les impôts sur le revenu et les impôts sur les bénéfices des sociétés sont plutôt faibles voire inexistants, il peut ne pas y avoir d impôt sur le revenu du capital. Comme pour les impôts, les différentes taxes, en particulier la TVA, sont généralement moins élevées ou supprimées. La délocalisation des grands entreprises doit tenir compte ces informations avant de choisir la location d implantation de leur centre de services offshore ou nearshore. Aux États-Unis, le taux le plus élevé d impôt marginal fédéral sur les sociétés ayant des revenus supérieurs à 18,3 millions USD est de 40 %. En France, depuis 1993, l impôt sur les sociétés est à un taux de 33,33%, auquel se rajoute la contribution sociale sur la société 3,3%, donc le taux global est de 34,43%. Au Royaume-Uni, le principal impôt sur les sociétés est de 28%. Tandis qu en Irlande, le taux de l impôt est de seulement 12,5%. Ce taux est légèrement plus bas qu en Lituanie (15%), qu en Roumanie (16%) et qu en République Tchèque (19%). 7 8 Les pays offshore dans les continents plus lointains ont aussi des fiscalités intéressantes : 15% au Hong Kong, 17% au Singapour Cela peut montrer que, avec les centres de services nearshore ou offshore implantés dans les «paradis fiscaux», l entreprise bénéfice d'un taux de 2 à 3 fois moindre qu au pays onshore, comme indiquait Lord Upsohn (Chambre des Lords, 1976) : «Aucun homme d affaires en possession de ses facultés intellectuelles n entreprendra des relations d affaires sur une base autre quelle celle consistant à payer la plus petite imposition possible». En plus, aujourd hui, dans les pays en développement, pour attirer les investissements étrangers, le gouvernement décide d offrir aux investisseurs des avantages fiscaux. Au Vietnam, le gouvernement a décidé d abolir les impôts sur le rapatriement des bénéfices pour les investisseurs étrangers. Les investisseurs sont aussi autorisés de remettre leurs profits annuels à la fin de l année financière. Le ministre des finances du Vietnam annonce pour l année 2013 des réductions de charges fiscales pour les entreprises à capitaux étrangers qui s engagent dans des projets 6 Worldsalaries.org. Programmer Salaries - International Comparison. Site : Consulté en avril Fresh Air. How offshore tax heaven save companies billions. Talk show. NPR Site : Consulté en avril Wikipédia. Fiscalité en Europe. Site : Consulté le 13 avril

43 d'expansion pour les investissements existants 9. Cette nouvelle politique motive les grandes entreprises dans leur délocalisation vers ce pays. En effet, Cap Gemini y a déjà créé un centre de développement. L année 2013 sera l entrée d'autres sociétés françaises comme Renault, Peugeot A côté des gains d impôts sur le revenu, l offshore permet aussi aux entreprises d économiser les autres coûts liés aux activités fiscaux onshore comme les coûts de comptabilité, des activités d audit, les coûts liés à la maintenance des données fiscales Grâce à la combinaison de ces réductions, la marge d un projet offshore est espérée atteindre jusqu à 40% de son budget total. Pourtant, l offshore n a pas comme seul intérêt un bénéfice financier à court terme. Sur le plan des stratégies à long terme, la délocalisation est aussi considérée comme un investissement pour les entreprises. Grâce à l ouverture des centres de services, l entreprise peut ensuite entrer dans le marché des pays, qui sont souvent en dessous du niveau de leur potentiel. La globalisation permet à l entreprise d élargir leur part de marché, de consolider leur position sur le marché international. Car en profitant de la variété des ressources et des compétences, l entreprise peut très bien augmenter la compétitivité de prix et de qualité, donc être plus dynamique face aux concurrents. Sur le plan macroéconomique, la délocalisation présente aussi un avantage non seulement pour l industrie des pays onshore mais aussi des pays offshore. Ces pays bénéficient du transfert des connaissances et des compétences de l entreprise mère aux filiales offshore. L apparition des entreprises internationales augmente la concurrence du domaine, oblige des entreprises locales à se développer pour éviter d être exclues du marché. Ces centres de services aident aussi ces pays à créer des emplois, réduire le taux de chômage et former des ressources qualifiées. Le tableau cidessous montre les chiffres liés à l offshoring des Philippines, un des pays les plus dynamiques dans ce domaine Croissance annuelle du PIB 6.10% 5.10% 5.40% 7.10% 3.80% 0.90% Chiffre d affaires de l industrie des services offshore (Milliards USD) Taux de croissance du CA des services 47% 50% 48% 24% 18% offshore Nombre d emplois du domaine 101,00 163, , , , ,000 offshore Taux de croissance d emplois du domaine offshore 61% 45% 27% 24% 19% Table 1 - Philippines IT BPO Industry, Source: National Statistical Coordination Board; Business Processing Association of the Philippines 9 Vietnam Briefing. Vietnam Set to Lower Corporate Income Tax. Magazine. Publié le 20 décembre

44 Nous pouvons constater sur ce tableau que, même si l économie du pays est dans une situation difficile, où le taux de croissance du PIB a baissé en 2007 de 7,1% à 3,8% et a chuté jusqu à 0,9% en 2008, la croissance du domaine offshore est plutôt stable (avec une augmentation de 20%- 50% durant cette période), malgré une baisse de taux de croissance vers la fin 2009 en raison de l apparition des nouveaux concurrents offshore dans la région. Un autre exemple est le cas de l Inde, le champion des pays d accueil de l offshore, et aussi le pays qui a le plus bénéficié de ce phénomène. Ayant été considéré comme la meilleure destination pour l ouverture des centres offshores, l Inde profite bien des fruits du transfert de connaissances et des autres effets. Les grands SSII indiens comme TCS, Wipro, Infosys, HCL Technologies ont aujourd hui des collaborateurs de bon niveau et des méthodes de travail certifiées. Ayant leur centre de services en Europe et aux États-Unis pour approcher leurs clients grandes comptes, ces grandes entreprises indiennes ne sont plus juste des sous-traitants de services informatiques, elles sont aujourd hui en concurrence directe avec les SSII étrangers et sur leurs territoires Les points critiques Malgré les avantages présentés, le phénomène offshore reste encore un sujet critique de nombreux débats. La délocalisation est considérée comme un bénéfice pour le pays offshore, mais elle présente des risques pour l économie des pays onshore, notamment l augmentation du taux de chômage. Les États-Unis, pionnier des activités offshoring, ont passé une période difficile due à cette stratégie. En Iowa, entre les années 2000 et 2003, postes ont été supprimés. Et ce chiffre est estimé à 3,3 millions sur l ensemble des états dans les 10 prochaines années. C'est la raison pour laquelle les américains considèrent l'offshore comme la cause de la disparition des postes. Selon une étude de Program on International Policy Attitudes, 72% des personnes enquêtées constatent que l offshore est une mauvaise tendance car cela fait perdre du travail aux employés américains. Les salariés américains, étant en concurrence plus ou moins directe avec leurs collègues dans les pays low-cost, pensent que la délocalisation amènera à réduire leur salaire. La suppression des postes n est pas le seul mauvais impact de l offshore. Les américains considèrent que les bénéfices de l offshore ne profitent qu'aux patrons des entreprises, et que l argent gagné par les SSII est lié aux diminutions du nombre de salariés. 64% des américains, dans la même enquête, considèrent que l offshore élargit la distance entre les riches et les pauvres du pays. Sur le plan macroéconomique du pays, l offshore présente aussi des risques de crise économique. Comme le revenu des salariés est réduit, ces derniers sont forcés de réduire leur niveau de vie en réduisant leur consommation, ce qui est dangereux pour la santé économique du pays. La délocalisation permet à l entreprise de bénéficier des «paradis fiscaux», inversement, elle fait perdre au pays un montant lié à l impôt que l entreprise aurait dû payer si elle s y implante. Accenture, lors de sa délocalisation, localise son siège social à Dublin, Irlande, depuis 2009 pour profiter de meilleurs taux fiscaux. Selon une étude d US PIRG, chaque année, les États-Unis comptent une perte de 150 milliards dollars d impôts à cause de ce phénomène 10 alors que ce montant aurait 10 U.S. PRIG (Education Fund). What America Could Do with $150 Billion Lost to Offshore Tax Heavens? 44

45 dû être investi dans l éducation, la santé, l économie, les transports et autres projets. Une étude d Unilog et IDC, réalisée en 2004 auprès de 200 entreprises en France, en Allemagne et au Royaume-Uni, montre que 36% des entreprises enquêtées ont mal évalué les économies réalisées dans la délocalisation des services. Les calculs montrent que dans certains projets, les gains ne sont pas aussi importants que ce qui était estimé au début. Les entreprises espéraient pouvoir gagner jusqu à 40% du coût total du projet, mais en réalité, ils sont souvent autour de 10-15%. Il faut aussi noter que le projet offshore présente plein de risques pour l entreprise adoptant cette stratégie. La collabora on à distance nécessite des connexions de qualité, une documentation bien soignée. Il faut aussi avoir des normes et des standards de sécurisation des données. La protection, la confidentialité des données et la gestion des licences d utilisation des logiciels dans le contexte offshore deviennent compliquées. Concernant les ressources offshores, même si l entreprise bénéficie de la variété et des gains sur le coût de ces ressources, elle peut aussi avoir des risques. L offshore permet aux employés d augmenter leurs compétences, et en conséquence, leur permet d avoir des droits de demander un salaire plus élevé, ce qui augmente le coût de ces ressources pour l entreprise. Dans le domaine de l informatique, le taux de turnover est déjà élevé, et l offshore a tendance à l accroître encore L offshoring : stratégie incontournable de Sopra Offshore à SopraGroup Fig 24 Les centres de service nearshore-offshore de Sopra Site (consulté en avril 2013) 45

46 Aujourd hui, l offshoring à SopraGroup est considéré comme un élément important dans ses stratégies commerciales pour plusieurs raisons : les freins à l offshoring ont quasiment disparu sur son marché qui est celui de l accompagnement de ses clients dans l évolution de leur système d information. Ce choix de stratégie est influencé par des clients (l approche «sourcing» de la plupart des grands clients de SopraGroup inclut l offshoring) et aussi par des concurrents (comme indiqué dans la partie «Situation des SSII en France et à l'international», presque toutes les grandes SSII sont déjà entrées dans le monde d offshoring). En 2012, selon le rapport financier du groupe, 32% du chiffre d affaires est réalisé par les centres de services hors de France, soit un montant de 389,44 millions avec un effectif de 4760 (juin 2012), soit 33.5% de l'effectif total du groupe SopraGroup India Madrid Casablanca Sopra Group India est considéré comme le centre de Services offshore. Cette filiale 100% Sopra Group est localisé à New Delhi et comprend plus de 1000 ingénieurs impliqués dans des projets de développement au forfait, des TMA ou des activités de Global Testing, ainsi que la R&D (recherche & développement) et le support technique. Comme tous les autres centres d offshore en Inde, ce centre de services couvre un large éventail technique comme ERP (SAP, Oracle, ebusiness ), Web/Portail (Java,.NET ), IMB mainframe, iseries, EAI (Axway, WM ), BI (Datastage, Informatica, Microsoft, Cognos, BIW ) et des processus de Développement industriels sont certifiés SEI CMMI niveau 5 et ISO 9001:2000. Pour ces raisons, Sopra Group India devient le cœur de la stratégie et des offres du groupe, ce qui permet d atteindre le meilleur ratio Qualité Réactivité Coût Fig 25 - Sopra India Pour le côté Nearshore, Sopra a choisi en 2003 Madrid comme site nearshore afin de servir ses clients français et européens. Ensuite, une extension à Casablanca (Maroc) a été mise en place début Ces sites bénéficient à la fois des avantages du nearshore : même fuseau horaire, une proximité culturelle et géographique (la langue de travail n est pas obligatoirement l anglais, le français est aussi utilisé) et des avantages en local : connaissance du marché local et capacité de recrutement rapide. Aujourd hui, avec 1200 ingénieurs formés aux technologies actuelles, ces centres nearshore permettent d assurer un niveau de production efficace et de services de qualité. 46

47 Modèle «Soprasien» : Xshore Alors, comment s organise Sopra Group pour réussir cette stratégie? Dans la stratégie de Sopra, un projet «XShore» est composé de 2 sous- projets, un projet «onshore» proche du client et un projet «offshore» ou «nearshore» développé dans un Centre de Services. L onshore peut être localisé sur 2 sites, soit sur le site du client (onsite), soit sur le site Sopra (offsite), soit réparti sur les 2. Le projet One Report auquel j ai participé est un projet de type Onshore-Offshore, avec une équipe onshore à Sopra Group Midi Pyrénées qui travaille directement avec le client (Airbus) et une équipe offshore à Sopra Group India (localisé à Noida, New Delhi). La répartition des responsabilités et des activités des équipes sera détaillée dans la partie suivante. Fig 26 L oganisation d un projet offshore de Sopra Ce modèle présente différents niveaux de répartition des activités entre l onshore et l offshore. En général, il existe 4 niveaux de répartition des activités. Si un projet est au niveau 1, l'offshore n est qu un centre de développement. Par contre, si un projet est au niveau 4, l offshore gère la totalité du projet. L onshore dans ce cas assure le suivi commercial et le pilotage global du projet. Le choix d appliquer un niveau sur un projet doit tenir compte du type de projet, du moment du projet et des risques One Report est un projet de niveau 1. Un projet informatique en général est souvent au niveau 1 ou 2, c est-à-dire que l équipe onshore s occupe de la partie fonctionnelle et du design et l équipe offshore réalise le développement, car un projet nécessite souvent des ressources onshore afin d assurer la communication directe avec le client. Les niveaux 3 et 4 sont souvent conseillés pour les TMA (Tierce Maintenance Applicative - la maintenance appliquée à un logiciel) qui ne demande pas forcément une communication permanente et directe avec le client L approche basée sur l évaluation des risques L application de l offshoring à un projet informatique n est pas tout à fait automatique. Comme indiqué précédemment, même si l offshore rapporte à l entreprise des avantages indéniables, il présente des risques, surtout dans la communication, la qualité de la livraison et l efficacité de la production Ces risques, venant d une gestion de projet insuffisante ou du fait de ne 47

48 pas avoir effectué une étude d opportunité préalable, peuvent conduire le projet à l échec et donc l entreprise à des pertes importantes sur le plan financier et sur son image. C est pourquoi, l application de l offshoring doit être implémentée suivant une démarche prudente. Pour ces raisons, Sopra Group a décidé d implémenter une stratégie d évaluation d opportunité des projets offshore basée sur une méthodologie d étude rigoureuse et soignée. Pour les livraisons de ses projets informatiques, Sopra Group, depuis 1998, adopte le modèle de livraison globale (Global Delivery Model). Ce modèle permet de déterminer les projets ou les phases d un projet qui conviennent le mieux à l'offshoring et des stratégies de gestion des risques spécifiques sont déployées afin d assurer une livraison efficace. Ce modèle s applique aux projets de développement d applications, des programmes de gestion d applications et des services de test Fig 26 Le processus d évaluation des risques La détermination de l applicabilité de l offshore sur un projet est basée sur une méthodologie d évaluation. L étude de cette méthodologie se compose de 4 étapes : développement des critères, des facteurs et des benchmarks utilisés ; évaluation du projet ou du service en question suivant les facteurs précédents ; développement de la migration des stratégies du projet afin d atteindre les objectifs, amélioration du processus selon les retours d expériences du projet. Ces étapes forment un cycle de développement continu, afin d optimiser l efficacité de la méthodologie ainsi que son domaine d application. La première étape d évaluation d opportunité de l offshore est de développer des critères et des facteurs afin d'identifier les risques de chaque projet et leurs impacts. Ces critères peuvent couvrir des besoins d utilisateurs, des plateformes, des interfaces, des parties intéressées, de l architecte du projet Les facteurs d évaluation sont aussi liés à l organisation du client : la maturité du client doit être suffisante pour appréhender les activités multi-géographiques, les licences spécifiques et les considérations juridiques peuvent avoir un impact sur la capacité d offshoring. Une fois les critères bien définis, une matrice d évaluation des risques est construite. Dans cette matrice, pour chaque risque, un niveau d impact est défini et des valeurs de probabilité du risque sont déterminées à chaque phase du projet. Enfin, une valeur de risque global est calculée en 48

49 prenant la somme des produits entre le niveau de l impact et sa valeur. Cette valeur finale permet de choisir une bonne stratégie de gestion qui devra être adoptée par le pilotage afin d assurer le bon déroulement du projet. Selon ce choix, les actions nécessaires seront mises en place (choix du niveau de modèle onshore-offshore, définition des responsabilités des acteurs, le transfert de connaissances ) Fig 27 La matrice d évaluation de risques Les résultats de l étude initiale des risques peuvent conduire à modifier ou supprimer des projets à valeur importante de risques. Le processus d amélioration peut varier selon les besoins du client et les risques à réduire. Les stratégies déployées peuvent être : L utilisation d un spécialiste de validation des besoins clients en termes de faisabilité technique qui s assurera de l alignement des exigences techniques avec la capacité du système. Cette action permet de réduire des problèmes venant des besoins instables durant la phase de développement du projet. Le développement d une stratégie de transfert de connaissances fonctionnelles avec le client dans les projets onsite. Ce workshop doit permettre à l équipe offshore d avoir des connaissances métiers et une communication efficace car souvent la distance géographique provoque une barrière dans la communication, particulièrement dans l expression des besoins fonctionnels. Des outils et des règles de communication doivent être appliqués afin d avoir une meilleure transparence entre l équipe business, l équipe onshore et l équipe offshore. L application des méthodes de développement agile où les phases de projet sont organisées en itérations. Les méthodes de développement agile, souvent utilisées pour travailler plus rapidement et plus efficacement, sont tout à fait applicables aux projets offshore. Le fait de dispatcher le projet en plusieurs cycles permet à l équipe offshore d avoir la visibilité fonctionnelle très tôt. Toutefois, la prise de décision sur la méthode doit avoir la validation côté client. Dans certain cas, le schéma directeur informatique du client impose la méthode de travail (Airbus, pour les projets de niveau d importance élevé, impose la méthode du cycle en V). Les détails de l utilisation seront présentés dans la prochaine partie. 49

50 Après la mise en place des actions nécessaires pour réduire les risques du projet, les retours d expériences sont pris en compte dans les pratiques standard dans le but d améliorer l évaluation des projets suivants L offshore dans le contexte du projet One Report Organisation des équipes FO-BO One Report, comme la plupart des projets du pôle FBI, est réalisé dans le contexte offshore, donc avec une équipe front-office en France et une équipe back-office en Inde. La répartition des tâches du projet est et le mode de fonctionnement est plutôt classique. L équipe front office, composé de 2 senior architectes, 2 analystes et un chef de projet s occupe de la spécification (l architecture générale et le design détaillé) tandis que l équipe back-office composée de 3 développeurs BW et 2 développeurs ABAP, réalise le développement. Il y a aussi une équipe de testing offshore de 2 testeurs indépendants de l équipe de projet, qui intervient dans le projet durant les phases de test Les premiers retours d expériences Par ciper à ce projet durant mon stage m a permis de vivre des expériences dans le contexte offshore. La gestion dans ce contexte est plus difficile parce qu il faut prendre en compte la distance géographique et culturelle importante entre les deux sites offshore. Voici les premiers retours d expériences que j ai pu retenir dans le contexte de One Report. La communication est une des activités principales du management d un projet et le contexte offshore la rend plus compliquée à gérer. Pour remplacer la communication physique face à face, différents outils de télécommunication ont été mis en place. Chaque jour, une conférence téléphonique est planifiée entre le chef de projet front-office et le responsable de l équipe backoffice pour discuter de l avancement des tâches de la journée. Les autres échanges peuvent être réalisés via les mails ou l outil de messagerie instantanée entre tous les membres des équipes ainsi que des fichiers communication sur le réseau interne pour assurer la transparence et la pérennité de l information. Malgré le temps que l équipe a consacré à la communication, il subsiste des problèmes d incompréhension. En effet, comme One Report est un projet de type classique, la conception est faite uniquement onshore et le développement à l offshore. Cette distinction amène inévitablement à des difficultés de compréhension par les développeurs indiens des spécifications fonctionnelles établies par les analystes français. Ces difficultés ont causé un nombre important de défauts du développement livré par les développeurs et la correction de ces défauts a pris beaucoup de temps pendant la phase de qualification. C est pourquoi, des actions de validation ont été mises en place dès réception du développement, avant la phase de qualification, pour éviter ce problème. Un autre problème lié à la communication est la gestion des versions des documents, notamment la synchronisation des documents de spécifications. Dans certains cas l équipe offshore ne développe pas la dernière version de la spécification ou ne prend pas en compte une évolution de 50

51 la spécification. Pour résoudre ce problème, un fichier de communication a été mis en place où toutes les évolutions sont communiquées à l ensemble de l équipe. Une autre difficulté de One Report est la volatilité du marché de services informatiques en Inde. Comme précisé précédemment dans la partie des points critiques de l offshore, l évolution du marché offshore en Inde fait augmenter le phénomène de turnover où les développeurs, ayant acquis un certain niveau d expérience, ont tendance à aller chercher un autre poste avec plus de responsabilité et de rémunération. Cette situation n est pas favorable pour un projet de longue durée comme One Report qui demande une stabilisation de l équipe. Un impact de la différence culturelle dans One Report est la distance hiérarchique. En Inde, où cette distance est importante, les employés ont tendance à attendre de leurs supérieurs les tâches à faire. Par contre, les Français n ont pas cette distance dans leur culture de travail: l'organisation du travail se fait de manière conviviale et non autoritaire entre employés et managers. Cette différence présente des difficultés dans la communication, dans la mesure où les développeurs offshore ne remettent pas en question les tâches qui leur ont été confiées et suivent passivement les ordres. Pour conclure, les vrais challenges de One Report est d optimiser la communication et la validation du développement. Pour le plan de la communication, différents outils, fichiers de communication, de recapitalisation ont été mis en place. Pour faciliter la validation par les analystes, les développeurs sont requis de réaliser eux-mêmes les tests unitaires avant de livrer leur travail 3.4. Une solution pour l offshore : les méthodes agiles Je profite du contexte du sujet de réflexion pour ouvrir une parenthèse sur la relation entre ce sujet et les méthodes de gestion de projet. Il existe à nos jours, plusieurs méthodes de gestion de projet informatique où chacune a ses avantages particuliers propres. Quelle serait la méthode de gestion de projet la plus favorable pour les projets offshoring où existent de nombreux risques notamment sur la communication et la compréhension des besoins fonctionnels du client? Aujourd hui, les méthodes agiles font partie des méthodes les plus adéquates. En se basant sur les retours d expériences et mes connaissances, je vais montrer une petite analyse de l application des méthodes agiles dans le contexte offshore et comment ces méthodes pourraient en réduire les risques. Les méthodes agiles sont apparues pour la première fois en 2001 en tant que méthodes de développement informatique. Elles divisent le projet en plusieurs petites itérations, avec l évolution des besoins et des solutions durant la réalisation du projet avec une équipe souple et flexible. Ces méthodes sont utilisées dans le cas où le projet nécessite des travaux rapides tout en garantissant la qualité. Les 3 méthodes les plus connues et utilisées sont XP (extreming Programing), RAD (Rapid Application Development) et Scrum. Un des points fondamentaux des méthodes agiles est la communication. Les échanges entre les acteurs (le client, le chef de projet, les membres de l équipe) jouent un des rôles les plus importants dans le succès du projet. Ensuite, un autre risque de l offshoring est le manque d information et de connaissance des spécifications fonctionnelles de l équipe offshore. Les 51

52 méthodes agiles, souvent appliquées dans le cas de manque d expression des besoins clients, permettent de résoudre ce problème. Mais l application des méthodes agiles dans les projets offshoring n est pas toujours facile. Premièrement, la communication dans les méthodes agiles doit être plus «proche» possible, c est-àdire jusqu au niveau des échanges physiques. Dans la méthode XP, les membres de l équipe doivent travailler en binôme, l un à côté de l autre. Dans la méthode RAD, chaque jour, une petite réunion entre tous les membres de l équipe doit être planifiée au début de la journée de travail, au cours de laquelle chacun communique son travail. Ces actions sont particulièrement difficiles à mettre en œuvre dans l offshoring à cause de la distance géographique. Ensuite, certaines entreprises préfèrent la démarche classique, où les besoins et les spécifications doivent être complètement exprimés avant d être envoyés au développement dans les centres de services dans les pays étrangers. Cette démarche n est pas compatible avec les méthodes agiles, où les changements des besoins du client sont acceptés et le retour à l étape précédent ne pose pas de problème au déroulement du projet. C est pourquoi la question posée pour cette partie est: comment adapter les méthodes agiles aux projets offshoring pour bénéficier de leurs avantages? Amélioration du plan de communication Comme précisé précédemment, l une des difficultés de l offshore est la communication. Comment une communication à distance peut garantir la qualité des échanges physiques? Mobiliser des ressources humaines Une première solution proposée est la présence d une personne sur le site onshore. Si l équipe offshore ne peut pas être «en colocation» avec l équipe onshore, le fait d envoyer une personne sur le site onshore peut aider beaucoup à faciliter la communication. Cette solution permet d assurer la communication physique, ce qui est idéal pour tous les projets. La communication au sein de l équipe de projet ne se limite pas aux réunions hebdomadaires, les discussions informelles sont aussi intéressantes et importantes. Les méthodes agiles privilégient ces genres de discussions, car elles permettent d avoir un maximum d information sans y passer beaucoup de temps, d assurer la transparence de l information au sein de l équipe, de détecter et de faire monter les problèmes le plus tôt possible. Le choix de la personne pour la mission est aussi important. Cette personne doit être l intermédiaire entre 2 équipes, c est-à-dire elle doit avoir les connaissances de base des 2 équipes (notamment des connaissances métiers et techniques), ainsi que des compétences de communication pour relier des personnes de différentes cultures, gérer les conflits, les risques d incompréhension, etc. C est pourquoi dans la plupart des cas, les personnes choisies sont des personnes d'expérience ayant une certaine responsabilité. Pourtant il faut aussi prendre en compte les besoins et les préférences individuels de la personne en question. Travailler à des milliers de kilomètres loin de sa famille pour une durée de plusieurs mois n est pas toujours facile. Dans la plupart des cas, les personnes sont envoyées onshore seulement dans les phases estimées importantes du projet (souvent les phases initiales pour participer au travail avec le client) et qui 52

53 durent quelques semaines ou quelques mois au plus. Même si cette solution a beaucoup d avantages, elle n est pas utilisée pour tous les projets pour des raisons de coût d'envoi de la personne. Dans One Report, cette solution n est pas appliquée mais dans certains projets, il y avait des déplacements d'une personne de Sopra Group India en France pour participer à certaines phases. L envoi de la personne à l onshore n est pas la seule solution possible. Dans certains cas, selon le contexte du projet, c est la partie onshore qui envoie ses personnes à l offshore, par exemple le client et le manager onshore peuvent être envoyés à l offshore pour produire le plan de production initial du projet. L envoi des ressources à l autre équipe est aussi une solution pour équilibrer les compétences et les connaissances entre les équipes. Nous pouvons trouver un analyste offshore sur le site onshore dans les sessions initiales de spécifications pour mieux comprendre les règles de gestion. Ou un développeur onshore sur le site offshore dans le développement de la première itération pour participer à l initialisation du code de base. L importance de cette action n est pas d'exécuter des tâches du projet (même si cela est intéressant), mais de construire une relation réelle, basée sur l échange direct face à face. Cette relation facilite la communication à distance dans les phases suivantes du projet. Et cette action, pour pouvoir profiter de ses avantages, doit être toujours réalisée dans les phases initiales du projet Gérer les problèmes interculturels Un problème pouvant empêcher la mise en place des méthodes agiles dans le contexte offshore est la différence culturelle entre les équipes. Les centres de service offshore sont souvent localisés dans des pays situés à grande distance géographique et culturelle, ce qui entraîne des difficultés dans l application des méthodes agiles des entreprises. Le principe des méthodes agiles est le travail autonome avec des décisions prises de façon collective, sans aucun effet venant de la hiérarchie. Pourtant, dans certains pays comme l Inde, la Chine, le Vietnam la distance hiérarchique est considérée comme indispensable dans la culture d entreprise. La prise de décision dépend forcément des supérieurs et les personnes de niveau hiérarchique plus bas ont l'habitude d attendre des ordres ou des tâches de leurs chefs. Pour ces pays, le management est défini comme «l art du contrôle». Cette notion de hiérarchie peut nuire à la communication dans l équipe, ce qui devient mono-sens : des seniors aux juniors. Ce phénomène est moins évident dans les pays onshore (des pays de l Ouest). Il existe des cas où l équipe offshore accepte passivement des informations venant de l onshore sans discussion, pourtant rien ne peut garantir que les spécifications dans ces cas soient bien exprimées et prises en compte par l équipe offshore. Dans One Report, la différence des distances hiérarchiques pose aussi des problèmes. L équipe indienne, influencée par le mode de travail patron-employé, a des difficultés dans la prise de décision de certaines tâches. Un exemple que j ai pu observer est le développement des chaines de chargement où les développeurs attendaient toujours d avoir les spécifications détaillées et développent (sans aucune remise en question) la conception livrée par les analystes, tandis que les analystes voulaient fournir des spécifications générales et laisser aux développeurs le choix de 53

54 décider plus librement au niveau d architecture plus détaillé. Le changement de culture est difficile et faire que les personnes habituées à un style de contrôle expriment leurs opinions et prennent l initiative va prendre beaucoup de temps et peut ne pas se faire en un seul projet. Mais cette action très importante ne doit pas être sous-estimée pour assurer une bonne communication et donc le succès du projet, car une fois que les équipes offshore ont pris l habitude de prendre des décisions avec une meilleure responsabilité, les membres seront plus motivés et autonomes Utiliser des bonnes méthodes de communication Une autre solution qui peut réduire les risques de manque d information est de construire un centre de documentation interne. J ai pu observer ce cas dans le cadre de mon stage. Sopra Group a mis en place un portail de connaissances du groupe sur l intranet contenant tous les retours d expériences, des études et des analyses faites et partagées par tous les collaborateurs dans différents domaines. Ensuite, au niveau du pôle FBI, il existe aussi un serveur commun où tout le monde peut trouver des guides d utilisation, des tutoriels BW, des normes et méthodes de développement Chaque employé dispose ensuite d'un répertoire sur le serveur de chaque division pour partager les documents. Au niveau de chaque équipe de projet, les documents contenant des informations communes (les dossiers de spécification, de test, le planning ) sont synchronisés et gérés par l outil SVN. Ces outils de partage de connaissances et d information doivent être simples à installer et déployer. La base des documents doit être bien structurée et gérée avec des droits d accès précis et des contrôles réguliers, afin de permettre un transfert de l information efficace. Ces «bibliothèques électroniques» sont pour moi une pratique intéressante. Au niveau des réunions, les méthodes agiles privilégient des meetings informels et efficaces (les scrums dans Scrum ou les stand-up meetings dans XP). Dans les projets offshore, il n est pas toujours facile de faire des réunions à distance avec toute l équipe de projet à cause du décalage horaire (4h30 d écart entre la France et l'inde, mais pour les entreprises américaines, l écart est de 11h30). Une solution à ce problème est de réduire le nombre de conférences, seules les réunions vraiment nécessaires sont mises en place et entre seulement des personnes concernées, souvent des personnes s occupant de la communication au sein de l équipe, notamment des managers. Les autres discussions informelles sont assurées par l outil de messagerie instantanée. Dans One Report et les autres projets offshore de Sopra, une réunion par semaine suffit, à condition que d'autres actions aient été mises en place (l envoi des ressources à l autre équipe ou la mise en place du wiki ) et que le projet soit en bon état. Seulement dans la période où le projet est en situation de crise, les réunions sont passées en mode journalier pour assurer le suivi et pilotage. A côté des problèmes de décalage horaire, il faut aussi prendre en compte les écarts entre les jours de congés et les jours fériés des différents pays dans la planification du projet. Il ne faut pas forcer les Français dans leur Toussaint et les Indiens pendant leurs jours de fêtes hindoues. A Sopra, les informations concernant des jours fériés de tous les pays où est implanté le Groupe sont accessibles sur le site intranet et la planification doit toujours prendre en compte ces calendriers. La communication à distance, pour moi, est un peu «fragile». Comme les problèmes techniques sont hasardeux et variés, rien ne peut nous assurer une communication permanente tout 54

55 au long du projet. C est pourquoi il est nécessaire d avoir plusieurs moyens de communication afin d éviter le risque que le projet soit bloqué à cause de problèmes majeurs pouvant survenir à ces moyens. De plus, les différents modes de télécommunication doivent être utilisés pour des besoins leur correspondant bien, c est-à-dire au bon moment et pour résoudre le bon problème. En réalité, dans One Report, les équipes de projet disposent d'un wiki interne, d'un outil «instant messaging», d' s, de documents de communications et de connections téléphoniques. L outil de messagerie instantané développé par Sopra (appelé Spark) est favorable aux messages courts, mais permet aussi de savoir si la personne est à son bureau ou si elle est disponible pour répondre à des questions. Si la résolution du problème dépasse la limite des quelques messages, l échange par téléphone devra être utilisé pour économiser du temps et réduire les risques d incompréhension Enfin, il faut penser à concevoir un plan d action dans le cas de problème des outils de communication et aussi une maintenance régulière afin d éviter tous les risques possibles Amélioration du plan qualité Le succès du projet dépend certainement de l efficacité de la communication au sein de l équipe. Pourtant, cette solution n est pas suffisante pour assurer la qualité de la production. L échange des informations internes est nécessaire, mais une bonne méthode de travail est aussi importante pour produire rapidement, avec de la bonne qualité et avec moins de coût Réduire les risques d incompréhension Une première solution pour réduire les risques d incompréhension est de raccourcir les itérations. Dans les méthodes agiles, les itérations durent souvent de 6 à 8 semaines. Mais rien n empêche de construire des itérations encore plus courtes, contenant un niveau plus simple de règles de gestion. La spécification devient plus facile à comprendre. Certains projets appliquent des itérations de 2 semaines. La réduction de taille de chaque itération permet de détecter les problèmes au plus tôt possible et de les corriger avant qu ils ne se compliquent. Ces problèmes peuvent venir de la compréhension des règles fonctionnelles ou du niveau des stratégies déployées (plan de production trop serré, manque de ressources, communication inefficace et même taille de chaque itération ). Pourtant, le découpage du projet en plusieurs parties dépend du contexte de chaque projet. Dans One Report, il est difficile d avoir des itérations courtes à cause des contraintes liées au mécanisme de SAP BW (une itération de One Report dure 3-4 mois). Puisque les flux d information décisionnelle doivent être travaillés de façon complète des systèmes sources aux outils de reporting et que l utilisateur ne teste que les reports finaux, il est compliqué de développer un flux d information en plusieurs itérations. Une itération longue implique un décalage entre la conception et le test de One Report. En réalité, il y a des difficultés dans la phase de test à cause de nombreux défauts détectés. Dans les projets offshores, l incompréhension des besoins clients du côté offshore est souvent un problème difficile à gérer. Effectivement, les méthodes agiles, comme XP, sont particulièrement utilisées pour les projets où les besoins utilisateurs sont incomplètement définis. Dans ce cas, les cas d utilisation (users stories) dans XP sont utilisés et ils doivent être rédigés par les 55

56 analystes et les utilisateurs eux-mêmes dans la phase d expression des besoins. Ces users stories sont les petites descriptions des besoins et de leurs scénarios de test d utilisateurs. Elles sont transférées ensuite à l équipe offshore en même temps que la spécification et permettent aux développeurs d avoir une vision concrète de ce qu'ils doivent faire. Cette façon va faciliter le travail de toute l équipe de projet : les analystes doivent forcément comprendre les règles fonctionnelles pour pouvoir rédiger les cas de tests et remonter leurs questions au plus tôt possible aux clients, les développeurs peuvent aussi lancer des tests de leur côté, prévoir les problèmes et les questions éventuels sur les cas de test. Un problème qui peut apparaitre dans cette solution est l engagement du client, plutôt dans la rédaction des cas de tests utilisateur. C est le cas de One Report. Au moment où Sopra commence à intervenir dans le projet (au début de la phase de spécification), toutes les règles de gestion ne sont pas encore précisées par le client. Ce problème cause beaucoup de difficultés à l équipe de projet car les architectes et les développeurs n ont pas une vision claire de l ensemble des règles fonctionnelles. C est pourquoi, les méthodes agiles soulignent l implication du client dans le projet comme un principe de base Faire valider régulièrement le travail Dans les méthodes agiles, pour assurer la qualité de la livraison du produit, il faut faire valider le travail par le client au plus tôt et le plus fréquemment possible. Dans Scrum, les prototypes sont souvent utilisés pour montrer plus rapidement la solution proposée au client par l équipe projet. Le contexte offshore ne permet pas de faire régulièrement la démonstration de la solution directement au client. Mais nous pouvons procéder différemment, par exemple faire valider le développement par les analystes qui connaissent déjà les règles fonctionnelles. Dans One Report, l équipe front-office et back-office travaillent sur les mêmes environnements de développement, de test, d intégration et de production. Ces environnements permettent aux analystes et clients d avoir une meilleure vision sur le produit développé par l équipe offshore. Les mécanismes de ces systèmes sont bien adaptés pour cette façon de travailler. Les développements de l équipe offshore une fois finalisés doivent être validés par les analystes du côté français avant d'être transférés dans les environnements de test. Cela permet de faire une première revue sur le produit développé, afin d éviter les problèmes d incompréhension entre les équipes. Un problème éventuel pour cette solution que j ai pu observer dans mon projet est un de définition des tâches de chaque équipe. Les développeurs indiens ont un peu négligé les tests unitaires avant de livrer le code aux analystes, en pensant que leur travail sera en tout cas vérifié. Il est nécessaire que les développeurs aient conscience que leurs tests permettent de réduire le temps de validation par les analystes, donc d assurer l efficacité du travail collectif. Quant à la spécification, comme les utilisateurs finaux d Airbus n interviennent qu à la phase de recette, les documents d architecture générale doivent toujours être validés par les acteurs intermédiaires (l ISPL le facilitateur de projet entre Airbus et Sopra, le centre de compétence BI Sopra et Airbus) avant de passer au niveau de design plus détaillé. 56

57 Répartir les équipes selon en fonction des modules développés Une autre habitude que nous pouvons trouver dans les projets offshore est la répartition des équipes selon leurs activités. Souvent dans ces projets, l équipe onshore s occupe de la spécification des besoins grâce au contact plus proche avec le client tandis que l équipe offshore réalise le développement. Cette méthode est proche du modèle en cascade, qui consiste à réaliser le projet successivement par étapes, où le passage à l étape suivante est fait qu à condition que l étape courante soit complètement terminée. Par contre, travailler en méthodes agiles avec les itérations ne favorise pas ce mode de séparation. Il serait intéressant de ne pas limiter l équipe offshore au développement, cette équipe peut aussi s occuper d'activités liées à l analyse et la conception du produit, sous réserve que ces activités soient en provenance de l onshore. Nous pouvons découper le projet en plusieurs modules et construire des équipes en fonction du domaine de fonctionnalités, pour que chaque équipe puisse prendre en charge quelques modules. Dans ce type d organisation du travail, le côté offshore peut avoir des connaissances fonctionnelles du projet. Et l existence des analystes offshore permet aussi de gagner du temps en diminuant la charge sur la communication. Les développeurs offshore n ont pas besoin d attendre toujours les réponses de côté onshore, ce qui pourrait les bloquer pendant un certain temps, du fait qu'ils peuvent recevoir des réponses des analystes locaux. Ce cas de blocage est apparu dans One Report, où l équipe offshore ne prend en charge que la partie de développement et n a pas été capable de remettre en question les erreurs dans les spécifications fournies par les analystes. Pour cette raison, la montée en compétence fonctionnelle des analystes offshore est importante et cette action peut nécessiter l envoi de ces ressources à l onshore dans les phases initiales communes Produire efficacement des documents Les documents font certainement partie de la qualité du projet, mais dans l application des méthodes agiles dans l offshoring, ce point provoque un dilemme. Selon les méthodes agiles, les documents ne sont produits qu en cas de nécessité, et des prototypes jetables, des courtes discussions sont plus favorables. Par contre, le contexte offshore nécessite de la documentation, cette activité est inévitable et non négligeable pour remplacer la communication face à face. Le temps que l équipe consacre à cette activité aide à réduire les risques de mauvaise compréhension, de maintenance La question qui reste est comment pouvons-nous optimiser la documentation, jusqu à quel niveau produit-on les documents? La documentation est incontournable, mais il est aussi déconseillé de passer trop de temps à rédiger les documents inutiles. Un wiki avec les documents de support réutilisable (des bilans des anciens projets, des retours d expériences, des guides ) serait intéressant, ainsi que d'autres outils de tracking... Certes, il faut produire «juste suffisamment» de documents, mais ce niveau de «suffisamment» dépend vraiment du projet et du contexte réel. Le fait de travailler en plusieurs itérations permet à l équipe de projet d acquérir l expérience et de définir au fur et à mesure le niveau de documentation nécessaire. 57

58 Dans le projet One Report, la structure des documents a changé au cours des itérations, avec l arrivée de l expérience. Au début, les documents sont répertoriés en fonction des itérations, mais dans un deuxième temps, ils sont placés selon l architecture du projet puisque les itérations utilisent des objets communs. Par contre, la plupart des documents produits sont imposés par Airbus. Pour les autres documents, l équipe ne produit que les fichiers internes nécessaires : tableau de bord des travaux, fiches de question, fichier de communication, rapport d activité individuel (pour le pilotage du projet) Conclusion L offshore est actuellement une tendance des SSII mais les problématiques de gestion des projets dans ce contexte restent encore le sujet de nombreux débats car les causes d échec viennent principalement des problèmes de management. Les méthodes agiles, considérées comme récentes, flexibles et certainement évolutives dans le futur, sont adaptables à ce challenge offshore. Ce qui précède fournit une première analyse de l application de ces méthodes à l offshoring. Certes, il en existe d'autres plus adaptées, en fonction de chaque projet. Le point principal à prendre en compte est que les méthodes de gestion de projet ne sont qu une boîte de bonnes pratiques. Il n y a pas de normes et de standards dans la gestion de projet, ni de méthode meilleure ou plus mauvaise. La gestion de projet nécessite un esprit flexible et proactif où dans tous les cas, il ne faut pas être attaché à une seule méthode. Le gestionnaire de projet doit savoir réagir et prendre des décisions au plus vite possible, selon ses connaissances de ces bonnes pratiques, pour assurer le bon déroulement du projet et donc l efficacité et la qualité du travail de son équipe. 58

59 4. Bilan Le but du stage est d apporter à l étudiant des expériences dans le contexte professionnel. C est la deuxième fois que j effectue un stage durant mes études. Lors du dernier stage en Licence 3, je travaillais avec l équipe des chefs de produits d Airbus (des Maîtrises d Ouvrage) et j avais participé à la phase d étude de l opportunité, de définition des besoins et de validation de l application livrée par le prestataire de service. Cette fois, j ai été intégré à l équipe de projet du client Airbus mais du côté Maîtrise d œuvre, pour réaliser les phases de définition de la solution finale, de développement de cette solution et de test d intégration. Finalement, ces deux stages m ont permis de participer à tout le cycle de réalisation d un produit informatique, d observer et d exercer des activités des deux côtés MOA et MOE. Ces expériences ont été pour moi très enrichissantes et intéressantes. Pour cette dernière partie du mémoire, je vais présenter dans un premier temps mes bilans sur les compétences que j ai pu acquérir pendant mon stage, qu elles soient techniques, professionnelles ou fonctionnelles. Ensuite, j aborderai les apports du stage sur le plan professionnel et personnel. Je terminerai par un bilan des difficultés rencontrées durant le stage sur mes tâches confiées et comment j ai résolu ces problèmes Bilan de compétences Tout d abord, je vais présenter les apports du stage à mes domaines de compétences. Le stage m a permis d un côté de consolider mes connaissances existantes, c est-à-dire d appliquer et prendre du recul par rapport à ce que j ai pu acquérir de la formation MIAGE et de mes anciennes expériences ; et de l autre côté d enrichir mon portefeuille de compétences pour pouvoir évoluer dans ma carrière professionnelle. Ces compétences ne sont pas seulement de nouveaux langages de développement, mais aussi des méthodes de travail, la gestion de projet et l ensemble des savoirfaire Compétences techniques Premièrement, je veux insister sur mon entrée dans le domaine de SAP BW, le système Business Intelligence de SAP. Les cours à l université m ont donné une première idée du système ERP et SAP, un des sujets émergents de l informatique de gestion, mais cela restait encore une vision abstraite. C est la raison pour laquelle mon choix de stage était orienté vers les postes permettant d obtenir une première expérience sur ce domaine. Finalement, j ai eu l occasion d atteindre cet objectif en étant retenu pour ce stage, proposé par le pôle FBI de Sopra Group. Deux formations (SAP BW et langage ABAP) données par l équipe de Sopra Academy et 6 mois de travail sur un projet important de reporting financier m ont permis d avoir une perception du système ERP et son progiciel dominant sur le marché SAP. 59

60 Ensuite, mon entrée dans le domaine de l informatique décisionnelle a eu lieu de deux façons : la formation de Sopra Academy dans un premier temps, et les cours donnés par les enseignants de la MIAGE durant la période de retour à l université. Effectivement, ces deux façons ne sont pas totalement similaires. La formation dans l environnement professionnel s oriente vers les notions et pratiques de SAP BW. Elle est plus précise mais aussi un peu limitée car son objectif est d acquérir un savoir-faire du système SAP BW tout en respectant des méthodes de développement Sopra et des normes imposées par le client Airbus. De l autre côté, le but des cours de l entrepôt de données à la MIAGE est de faire une présentation globale sur la Business Intelligence grâce aux définitions théoriques et générales, et ses différents outils sur le marché Cette approche particulière m a permis de voir la relation entre des connaissances acquises académiquement et celles requises par le contexte professionnel et comment appliquer les acquis universitaires à la vie professionnelle et inversement. Pour toutes ces raisons, mon objectif d acquisition d une bonne première expérience sur SAP a été atteint. Ce stage m a aussi permis d appliquer les savoir-faire obtenus lors de mes anciens projets professionnels. Dans le cadre du stage en Licence 3, j avais pu participer à la phase de vérification et de validation d une application avec des chefs de produit informatique d Airbus. Ces expériences m ont familiarisé avec le logiciel de test HPQC et les activités de validation (rédaction des cas de test, suivi des anomalies ) que j ai appliqué dans ce stage. Ce cas m a montré l apport des projets de professionnalisation sur les connaissances des progiciels et des processus d entreprise. Ces connaissances ne sont pas forcément obtenues dans le cadre des enseignements universitaires mais elles sont aussi très utiles pour ma carrière professionnelle Compétences fonctionnelles du métier Travaillant dans un projet lié au système d information financier d Airbus, j ai pu également avoir l occasion de découvrir le monde de la finance. En vérité, les notions financières utilisées dans One Report n ont pas beaucoup de relation avec les cours de gestion financière à la MIAGE. Ce fait me parait naturel vu que la MIAGE n est pas une formation orientée vers les compétences du domaine de la finance. Néanmoins, mon travail de spécification demande des connaissances des règles de gestion financière d Airbus, donc il m a fallu acquérir ces notions. Mon entrée dans ce nouveau domaine n a pas été tout à fait facile comme dans celui de la BI. Au début, le manque de connaissance m a posé des difficultés dans la lecture du cahier des charges et à l analyse des règles de gestion, notamment à la compréhension des vocabulaires du métier (des types de comptes financiers, de prix du matériel, des niveaux d agrégation des données ). Effectivement, des sessions de transfert de connaissances, des réunions d expression des besoins du client Airbus, des discussions avec mes collègues (souvent des personnes diplômées de l IAE finance à Toulouse) m ont aidé à monter en compétences et à comprendre la partie fonctionnelle de l application One Report. 60

61 En tout cas, ces expériences ont été intéressantes. Avec des connaissances dans un domaine autre que l informatique de gestion (dans ce cas ce sont les connaissances de la finance, même si cela est limité dans le cadre de One Report), je pourrais avoir plus de piste pour mon projet professionnel Compétences de management L objectif de la MIAGE est de former le futur chef de projet informatique. Ce métier nécessite trois branches de compétences : les compétences technique, les compétences métier et enfin les compétences management. Bien que le sujet de mon stage ne soit pas directement attaché à la gestion de projet, j ai aussi acquis les expériences dans ce domaine, en observant les activités de pilotage sur One Report et en appliquant mes savoir-faire d organisation ou de planification dans mon projet de stage. Participant à One Report, chaque jour, je pouvais observer les actions de ma chef de projet et des responsables du domaine FBI quand le projet s est situé dans le contexte de crise. One Report a connu les difficultés au cours de son déroulement pour différentes raisons. Rapidement, l équipe de pilotage FBI a mis en place un plan d action pour identifier et analyser la source du problème (renforcer la communication et le suivi de l équipe de projet, affecter des ressources manquantes ). Ce cas particulier a été pour moi très intéressant car il m a donné des idées sur les actions à mettre en œuvre dans le cas où le projet ne se déroulerait pas dans de bonnes conditions. J ai pu aussi dans le cadre de mon stage découvrir deux méthodes de gestion de projet différentes : emedia de Sopra et GPP Toolkits de Airbus, de voir comment deux sociétés peuvent collaborer et harmoniser leurs différents modes de travail (cette analyse a été présentée dans la partie de ce mémoire de stage) Bilan professionnel L apport du stage n est pas seulement des acquis de compétences, c est aussi une occasion pour l étudiant de «se plonger» dans le contexte industriel, de développer des aptitudes d'adaptabilité ainsi qu'un véritable sens du service permettant d'évoluer dans un environnement professionnel. Concernant mon projet de stage, comme tous les autres projets, j ai défini les grands objectifs à atteindre et ai créé un planning prévisionnel. Au cours du stage, ma gestion du temps a globalement tenu la route, même si le planning réel n a pas suivi exactement ce qui était prévu en raison d une forte dépendance du planning One Report, le projet où je travaillais. Il m est arrivé des périodes non prévues de baisse ou de surcharge d activités et je ne me suis pas bien organisé pour me débrouiller pendant ces périodes. C est pourquoi vers la fin de mon stage, je me suis trouvé dans un planning légèrement serré à cause du retard de la rédaction de ce mémoire de stage. Ces expériences m ont montré qu une bonne gestion de temps nécessite vraiment une flexibilité de la réalisation des tâches, il faut aussi bien définir la priorité des tâches et prévoir tous les problèmes possibles. 61

62 Durant mon stage, j ai participé aux différentes réunions : des réunions hebdomadaires de l équipe où j ai dû communiquer l avancement de mon travail, des conférences avec l équipe offshore en Inde pour échanger des informations J ai eu aussi l occasion de joindre des sessions de transfert de connaissance : des workshops internes de l équipe ou du bundle FBI ou avec le client Airbus. Au cours de ces réunions, mis à part l acquisition des connaissances du métier et de la technique, j ai pu pratiquer mes capacités d analyse, de synthèse et d écoute active afin de maintenir une communication efficace. Étant naturellement timide et fermé, la communication était une difficulté pour moi. En plus, le contexte offshore de One Report nécessite une bonne maîtrise de l Anglais. C est une qualité indispensable au métier de chef de projet. Au cours de mon stage, j ai essayé d appliquer les notions vues en cours de communication à la MIAGE (écoute active, construction d argument, communication multiculturelle ). Finalement, j ai réussi à être à l aise dans la communication avec mes collègues français et indiens, même s il me reste beaucoup de choses à améliorer notamment sur l esprit d ouverture aux autres et l expression de mes idées. Enfin, je veux ouvrir une parenthèse sur mon observation de mon métier préféré : chef de projet. Dans un projet en situation de crise comme One Report, le chef de projet devait assurer la communication, augmenter le suivi et le pilotage de l équipe indienne et aussi supporter les membres de l équipe sur leurs tâches Ensuite, être un chef de projet nécessite une capacité d analyse et de résolution du problème. Comme le planning de One Report a été serré, il a fallu réagir le plus rapidement possible pour ne pas perdre trop de temps sur un incident. Enfin, la communication est un vrai challenge pour le chef de projet. Il doit toujours avoir une vision optimiste et être le plus motivé afin de pouvoir animer et motiver son équipe. Avec une grosse charge de travail et aussi des pressions, le métier de chef de projet demande vraiment une passion et un goût de travailler en équipe avec des contacts humains. Le succès d un projet dépend vraiment de la qualité de son manager Bilan personnel Durant cette deuxième expérience de stage, j ai aussi amélioré mes capacités d adaptation et d intégration. Au début du stage, le manque de connaissances m a fait douter de mes capacités à effectuer les travaux demandés. Le fait d être nouveau dans un milieu inconnu m'a aussi rendu un peu timide. En plus, le statut difficile de One Report nécessite des qualités d expertise et le manque de compétences m a fait hésiter à participer aux tâches que je jugeais «critiques». Pourtant, grâce au soutien de mes collègues, j ai pu de temps en temps acquérir l autonomie dans mon travail. Durant le stage, j ai participé à la réunion annuelle d agence où j ai reçu des informations de Sopra groupe. Cette participation m a donné le sentiment d être un vrai collaborateur du groupe. Je suis aussi invité au petit déjeuner d accueil des nouveaux stagiaires avec des responsables de la division qui m ont donné des conseils intéressants sur l orientation de ma vie professionnelle. 62

63 Durant le stage, j ai aussi participé à un «workshop» des jeux de société créés par les salariés de Sopra. Chaque jeudi midi, j ai eu l occasion de découvrir les nouveaux jeux dans une ambiance conviviale avec le groupe des soprasiens passionnés par «Gynkopolis», «Sevenwonder», «Smallworld, «GalaxyRace» Ces sessions de jeux m ont apporté de bons souvenirs. Ils m ont montré que la vie professionnelle n est pas constituée uniquement de travail mais aussi de relations humaines et de découvertes intéressantes. Sur mon projet professionnel, ce stage m a permis d entrer dans un nouveau domaine, la BI. Intéressé par les technologies liées à la base de données, je suis arrivé rapidement à trouver le plaisir de découvrir ce domaine, surtout le système SAP BW. Après le stage, je souhaite continuer sur un poste lié à SAP pour progresser et évoluer dans ce domaine Difficultés Durant ce stage, j'ai dû faire face à plusieurs difficultés, qu'elles soient organisationnelles ou techniques. Le premier challenge que j ai rencontré est l adaptation au contexte de production d Airbus. Comme One Report fait partie de l ensemble des projets d ARP, sa réalisation doit s effectuer dans les mêmes environnements que les autres projets (l environnement SAP BW d ARP). Airbus, pour administrer les activités sur ces environnements, a mis en place des normes et des méthodes de nommage, de développement, d autorisations... Parfois, les procédures de demande de droit d autorisation ou de création des vues pour l extraction des données des systèmes R/3 au SAP Rights et au BICC (centre de compétences d Airbus) m ont pris du temps et m ont bloqué dans certaines tâches. En réalité, comme je ne maîtrisais pas ces normes et ces méthodes, la validation des documents par le BICC m a pris du temps et m a obligé de retravailler plusieurs fois sur les livrables. Ensuite, les travaux de One Report ont été réalisés sur des environnements interdépendants qui n étaient pas toujours stables. Quelquefois, j ai reçu des anomalies dans l extraction des données venues du système SAP R/3. Il y avait aussi des périodes de blocage des environnements dû aux actions de maintenance ou aux incidents de surcharge du système. Ces problèmes, qui n étaient pas sous la responsabilité de One Report, m ont parfois bloqué dans l avancement des tâches, il me fallait m adapter à ce contexte et trouver rapidement des solutions pour les régler (basculer à une autre tâche ou demander l aide d une personne concernée). Enfin, une autre difficulté est le manque de connaissances du métier dans le domaine de la finance et un planning serré dans la rédaction du mémoire de stage que j ai précisé dans les parties précédentes. Malgré les diverses difficultés rencontrées, mon stage s est déroulé dans d excellentes conditions. Mon équipe, ma chef de projet et ma tutrice professionnelle m ont suivi dans l avancement des tâches, ont répondu à toutes mes questions et m ont donnée des bons conseils afin de me permettre de surmonter ces difficultés et d accomplir mes tâches dans les délais qui m étaient impartis. 63

64 4.5. Conclusion Mon sujet de stage est intéressant, il m a permis de découvrir la BI qui devrait devenir ensuite mon domaine préféré. A côté des apports techniques et organisationnels, le stage m a aussi permis de mettre en application des acquis théoriques. De plus, j ai pu développer des aptitudes d'adaptabilité ainsi qu'un véritable sens du service me permettant d'évoluer dans un environnement professionnel. Enfin, le stage m a aidé à avoir une vision plus claire sur ma future carrière professionnelle. 64

65 Glossaires ARD AGD BI BICC BRD BSD CP DSO ETL FBI GPP IMSB IMSI ISPL KPI MD MIV/MIP NatCos PSA RAD SD SI TD Architecture Dossier Application general design Business Intelligence Business Intelligence Competence Center Business Requirement Dossier Business Specification Dossier Chef de projet Data Store Object Extract, Transform, Load Finance Business Intellingence Generic Project Process Responsable de production Airbus (assurer la MIP) Administrateur système Airbus (infrastructures) Information System Project Leader Key Performance Indicator Master data Mise en validation, mise en production National Companies Persistent Staging Area Roles & Authorizations Dosser Specification Dossier Système d Information Test Dossier 65

66 66

67 Bibliographies Documents consultés pour la partie «présentation d entreprise» et «synthèse des travaux» SOPRA GROUP. Livret d accueil. Document interne. SOPRA GROUP. Livret d accueil Bundle FBI. Document interne. SOPRA GROUP. Livret de formation SAP BW. Document interne. RAVAT F. et TESTE O., Cours de Datawarehouse, MIAGE ZURFLUH G. et PUJOLLE G., Cours de gestion de projet, MIAGE Documents consultés pour le sujet de réflexion : MARTINS CAMBAO Carlos, MALIK Douma, et al. (2002), LES SOLUTIONS ERP. Brique E-Mage, Mars CB RICHARD ELLIS, Outsourcing and the Rise of India. Journal en ligne. Q1, AGN INTERNATIONAL ASIA PACIFIC, Tax card 2011, General Guide to Asia Pacific Countries Tax Fact, Août KPMG International Cooperative, Asia Pacific Taxation, Singapore, 2012 Edition. Mars ENDRES Dieter, FUEST Clemens, SPENGE Christoph, Company Taxation in the Asia-pacific Region, India, and Russia. ISPN , Springer, BOIRON Pascal, «Services informatiques : pourquoi l offshore ne prend pas en France». Magazine ITPartners. Publié le 3 Novembre CHINA BRIEFING. China, India and Emerging Asia Tax Rates Compared. Asia Briefing Bookstore. 9 Décembre, 2011 SEXTANT EXPRETISE, «LE MARCHÉ INFORMATIQUE : SERVICES, LOGICIELS ET MATÉRIEL». Publication sur le site Septembre GOASDUFF Laurence (Gartner Group). «Many Outsourcers Will Disappear, but Which Ones and How Fast? Article publié par Gartner Group. Egham UK, February 25, FILIPPONE Dominique, «OFFSHORE IT : LE TERRAIN DE JEU MONDIAL DES SSII FRANÇAISES». Article sur JournalDuNet. 08 Juillet VANDER WEERDT Gwyn, «Analyzing the Debate over Offshore Oursourcing in the Service Industry : Is there a Reason for Concern?». Major Themes in Economics, Spring

68 WORKING AMERICA & AFL-CIO. Sending jobs overseas: The cost to America s economy and working families. Washington, DC SOPRA GROUP. «Projets en Xshore. Les clés de la réussite». Document interne Sopra. Juin SOPRA GROUP. «Risk Based Approach to Offshore Delivery». Livre blanc. GEREFFI Gary, FERNADEZ-STARK Karina. The Offshore Services Value Chain. Developing Countries and the Crisis. Center on Globalization, Governance & Competitiveness Duke University. Avril AUNDHE M.D., MATHEW S.K.., Risks in offshore IT outsourcing: A service provider perspective, European Management Journal (2009), doi: /j.emj ROUHIER Stéphane, «EXEMPLES D OFFSHORING : Retours d expérience et leçons apprises au sein de grandes entreprises», CIGREF HUGON Jean-Christophe, LOUPY Hugon Fabien. «Les sociétés françaises et l externalisation offshore». Mémoire de thèse. Mai LE GO Patrick, «Agile & offshore : retour d expérience en milieu bancaire». Valtech. Octobre ANDERSEN Per. IT Trends For The Future. IDC Nordic. 29 Novembre, SAKO Mari. (2005). "Outsourcing and Offshoring: Key Trends and Issues". Livre présenté au Forum des marchés émergents. Oxford, Royaume-Uni. BYRNE Michael. Global outsourcing market to touch USD 479 billion by Industry Watch, News. Publié le 7 juin FILIPPONE Dominique. «Dix SSII reines de l'offshore». Article sur JournalDuNet. Publié le 24 Octobre GARTNER Group. Eight New Countries Moved into the Top 30. Egham, UK, December 20, WORLDSALARIES. Programmer Salaries - International Comparison. Consulté en avril Fresh Air. How offshore tax heaven save companies billions. Talk show. NPR Consulté en avril Wikipédia. Fiscalité en Europe. Consulté le 13 avril VIETNAM BRIEFING. Vietnam Set to Lower Corporate Income Tax. Magazine. Publié le 20 décembre

69 U.S. PRIG (Education Fund). What America Could Do with $150 Billion Lost to Offshore Tax Havens. (consulté en avril 2013). 69

70 70

71 Annexes L architecture générale détaillée One Report Afin de mieux présenter l application One Report et donner une meilleure vision sur l ensemble des objets stockage de données du projet, dans cette partie, j intègre l architecture générale One Report, pour les flux de données transactionnelles venant du système allemand, dans le cadre des deux premières itérations (la spécification de la 3 e itération n est pas encore finalisée). Pour la première itération : One Report Gross Value & Provision Les données fonctionnelles du module FI sont remontées dans le DSO XFIPEIG1 de la couche X qui alimente le DSO HFIAX801 (le DSO de base de la première itération). 71

72 HFIAX801 va ensuite alimenter le DSO HFIAX80H pour historiser les données et le DSO HFIAX804 pour calculer la réconciliation entre les données FI et les données MMFI. Ces données sont ensuite utilisées pour alimenter les cubes et les multi-cubes : Le multi-cube HFIAX80M1 est utilisé pour les reports de provisions. Le multi-cube HFIAX80M3 est utilisé pour les reports des montants fiscaux et la dépréciation. 72

73 Pour la deuxième itération : One Report Material Stock by Location Les données MM sont remontées du système R/3 et stockées dans le DSO XPPH3202. Ce flux est déjà existé et utilisé par les autres projets. One Report prend ces données et stocké dans le DSO HFIAX802 (pour 1 mois) et le DSO HFIAX803 (la consommation détaillée des 12 derniers mois). 73

74 HFIAX802 alimente le DSO HFIAX80K pour réconcilier des écarts entre les données MM et MMFI (venant du HFIAX801) et le cube HFIAX80C5. Le multi-cube HFIAX80M4 est une vue des données de différents cube (le niveau de stock dans HFIAX80C5, la provision dans HFIAX80C4 et les cibles d inventaire dans HPPH320CG, un cube existant). 74

75 Le cube HFIAX80C6 va prendre les données d inventaire de HFIAX80M4 en convertissant les montants en devise locale. Le report d inventaire de stock est basé sur le multi-cube HFIAX80M5 qui est une vue de HFIAX80C6. 75

76 Le report des prix MAP et standard est basé sur le multi-cube HFIAX80M7 alimenté par HFIAX

77 Le report des stocks VMI est basé sur le multi-cube HFIAX80C8 alimenté par HFIAX

[ Hornet ] Charte de méthodologie

[ Hornet ] Charte de méthodologie [ Hornet ] Hornet Cette création est mise à disposition selon le Contrat Paternité - Pas d'utilisation Commerciale - Partage des Conditions Initiales à l'identique disponible en ligne http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Plus en détail

Entrepôt de données avec SAP BW

Entrepôt de données avec SAP BW Entrepôt de données avec SAP BW Etudiant : David ROUSSE Maître de stage : Christophe BIZET Tuteurs de stage : Claude CHRISMENT et Gilles ZURFLUH 23/12/2003 1/21 Page 1 Introduction Gestion comptabilité

Plus en détail

ACube. Charte méthodologique. Version 1.2 du 22/02/2010. Etat : Validé

ACube. Charte méthodologique. Version 1.2 du 22/02/2010. Etat : Validé Charte méthodologique Version 1.2 du 22/02/2010 Etat : Validé Communauté Adullact Projet SUIVI DES MODIFICATIONS Version Rédaction Description Vérification Date 1.0 S. Péguet Initialisation 20/03/07 1.1

Plus en détail

Le terme «ERP» provient du nom de la méthode MRP (Manufacturing Ressource Planning) utilisée dans les années 70 pour la gestion et la planification

Le terme «ERP» provient du nom de la méthode MRP (Manufacturing Ressource Planning) utilisée dans les années 70 pour la gestion et la planification Séminaire national Alger 12 Mars 2008 «L Entreprise algérienne face au défi du numérique : État et perspectives» CRM et ERP Impact(s) sur l entreprise en tant qu outils de gestion Historique des ERP Le

Plus en détail

Nouveautés SAP NetWeaver 2004S BI Business Warehouse 7.0

Nouveautés SAP NetWeaver 2004S BI Business Warehouse 7.0 Nouveautés SAP NetWeaver 2004S BI Business Warehouse 7.0 Artens SAP AG and / or America Inc. 2000 / 1 Les nouveautés SAP BW 7.0 (SAP NW 2004S) La nouvelle version de Business Warehouse apporte des améliorations

Plus en détail

Système d information VERSION : 4.00

Système d information VERSION : 4.00 METHODE ET ORGANISATION VERSION : 4.00 Jean-Michel Grandclément Confidentiel Reproduction Interdite Page 1 sur 21 Auteur Jean-Michel Grandclément Version / Date Version : 4.0 Date : 04/04/04 E-mail jean-michel.grandclement@grandclement.fr

Plus en détail

CONSULTANT FONCTIONNEL SENIOR SAP FI-CO

CONSULTANT FONCTIONNEL SENIOR SAP FI-CO Stéphane GUILLET Né le 24/09/1973 Nationalité : FR 62219 LONGUENESSE FRANCE stephane.guillet@hotmail.fr tel : +33 (0)6 83 73 62 50 CONSULTANT FONCTIONNEL SENIOR SAP FI-CO Membre de l ISAP Nord : http://www.federation-isap.com

Plus en détail

CONSULTANT FONCTIONNEL SENIOR SAP FI-CO

CONSULTANT FONCTIONNEL SENIOR SAP FI-CO Stéphane GUILLET Né le 24/09/1973 Nationalité : FR 62219 LONGUENESSE FRANCE stephane.guillet@hotmail.fr tel : +33 (0)6 83 73 62 50 CONSULTANT FONCTIONNEL SENIOR SAP FI-CO Membre de l ISAP Nord : http://www.federation-isap.com

Plus en détail

CONSULTANT(E) SAP ERP

CONSULTANT(E) SAP ERP Formation conventionnée par le Conseil Régional Midi-Pyrénées CONSULTANT(E) SAP ERP De novembre 2013 à juillet 2014* Modalités pratiques Durée : 450 h (12 semaines) en présentiel + 560 h (16 semaines)

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

Introduction à la B.I. Avec SQL Server 2008

Introduction à la B.I. Avec SQL Server 2008 Introduction à la B.I. Avec SQL Server 2008 Version 1.0 VALENTIN Pauline 2 Introduction à la B.I. avec SQL Server 2008 Sommaire 1 Présentation de la B.I. et SQL Server 2008... 3 1.1 Présentation rapide

Plus en détail

Consultant Senior SAP Business Intelligence (Chef de projet / MOE / MOA)

Consultant Senior SAP Business Intelligence (Chef de projet / MOE / MOA) Fabrice CATIER 36 ans 31000 TOULOUSE + 33 660 234 878 fabrice.catier@conexis.fr (2 ans Contrôle de Gestion et 9 ans Décisionnel) www.conexis.fr Consultant Senior SAP Business Intelligence (Chef de projet

Plus en détail

Skills Technology Software PARTENAIRE TECHNOLOGIQUE DE VOTRE DÉVELOPPEMENT

Skills Technology Software PARTENAIRE TECHNOLOGIQUE DE VOTRE DÉVELOPPEMENT Skills Technology Software w w w.s PARTENAIRE TECHNOLOGIQUE DE VOTRE DÉVELOPPEMENT ka ty s. co m E U OG ION L TA AT A C RM FO Accélérateur de votre RÉUSSITE 2 Formation Aujourd hui, la formation constitue

Plus en détail

Bases de Données Avancées

Bases de Données Avancées 1/26 Bases de Données Avancées DataWareHouse Thierry Hamon Bureau H202 - Institut Galilée Tél. : 33 1.48.38.35.53 Bureau 150 LIM&BIO EA 3969 Université Paris 13 - UFR Léonard de Vinci 74, rue Marcel Cachin,

Plus en détail

Supply chain management

Supply chain management áå ΩINSTITUT SUPERIEUR DU MANAGEMENT Supply chain management Les Rois de la Supply Chain 2010 Cabinet ISM Abidjan, Cocody,Bvd F. Mitterand, Riviera Bonoumin, Immeuble La Paix 22 BP 876 Abidjan 22 Tél:

Plus en détail

SOMMAIRE. I. Introduction 02. II. Glossaire 03 a. Glossaire technique 03 b. Glossaire fonctionnel 04

SOMMAIRE. I. Introduction 02. II. Glossaire 03 a. Glossaire technique 03 b. Glossaire fonctionnel 04 SOMMAIRE I. Introduction 02 II. Glossaire 03 a. Glossaire technique 03 b. Glossaire fonctionnel 04 III. Présentation de l'association 05 a. Présentation juridique et géographique 05 b. Présentation de

Plus en détail

En un coup d œil le descriptif de la solution OpenERP

En un coup d œil le descriptif de la solution OpenERP En un coup d œil le descriptif de la solution OpenERP OpenERP est une suite complète d'applications business. Elle permet entre autre de gérer les ventes, le CRM, les projets, le ou les entrepôt(s), les

Plus en détail

En route vers SAP BusinessObjects 4.0 Intervenant : Xavier OLIEL, Directeur Associé, Twin Solutions Moderateur : Thierry PIERRE, SAP

En route vers SAP BusinessObjects 4.0 Intervenant : Xavier OLIEL, Directeur Associé, Twin Solutions Moderateur : Thierry PIERRE, SAP En route vers SAP BusinessObjects 4.0 Intervenant : Xavier OLIEL, Directeur Associé, Twin Solutions Moderateur : Thierry PIERRE, SAP Sources d information Quelles sont les sources d information de cette

Plus en détail

Tout ce que vous avez toujours voulu savoir sur SAP HANA. Sans avoir jamais osé le demander

Tout ce que vous avez toujours voulu savoir sur SAP HANA. Sans avoir jamais osé le demander Tout ce que vous avez toujours voulu savoir sur SAP HANA Sans avoir jamais osé le demander Agenda Pourquoi SAP HANA? Qu est-ce que SAP HANA? SAP HANA pour l intelligence d affaires SAP HANA pour l analyse

Plus en détail

1 - SAP : Une solution intégrée 2 - Notre offre SAP d un point de vue TECHNIQUE 3 - Notre offre SAP d un point de vue FONCTIONNEL 4 - Nos REFERENCES

1 - SAP : Une solution intégrée 2 - Notre offre SAP d un point de vue TECHNIQUE 3 - Notre offre SAP d un point de vue FONCTIONNEL 4 - Nos REFERENCES Notre Offre SAP 1 - SAP : Une solution intégrée 2 - Notre offre SAP d un point de vue TECHNIQUE 3 - Notre offre SAP d un point de vue FONCTIONNEL 4 - Nos REFERENCES Quadra Informatique 1 SAP : Une solution

Plus en détail

Evry - M2 MIAGE Entrepôt de données

Evry - M2 MIAGE Entrepôt de données Evry - M2 MIAGE Entrepôt de données Introduction D. Ploix - M2 Miage - EDD - Introduction 1 Plan Positionnement du BI dans l entreprise Déclinaison fonctionnelle du décisionnel dans l entreprise Intégration

Plus en détail

BUSINESS INTELLIGENCE. Une vision cockpit : utilité et apport pour l'entreprise

BUSINESS INTELLIGENCE. Une vision cockpit : utilité et apport pour l'entreprise BUSINESS INTELLIGENCE Une vision cockpit : utilité et apport pour l'entreprise 1 Présentation PIERRE-YVES BONVIN, SOLVAXIS BERNARD BOIL, RESP. SI, GROUPE OROLUX 2 AGENDA Définitions Positionnement de la

Plus en détail

X2BIRT : Mettez de l interactivité dans vos archives

X2BIRT : Mettez de l interactivité dans vos archives Présentation Produit Présentation Produit X2BIRT : Mettez de l interactivité dans vos archives L accès à l information est capital pour les affaires. X2BIRT, la dernière innovation d Actuate, prend le

Plus en détail

Méthodologie de conceptualisation BI

Méthodologie de conceptualisation BI Méthodologie de conceptualisation BI Business Intelligence (BI) La Business intelligence est un outil décisionnel incontournable à la gestion stratégique et quotidienne des entités. Il fournit de l information

Plus en détail

3 ème. 280 000 salariés gérés. collaborateurs. de bulletins produits par mois. partenaires. en france. acteur de. distributeurs

3 ème. 280 000 salariés gérés. collaborateurs. de bulletins produits par mois. partenaires. en france. acteur de. distributeurs Intelligence RH 1 Yourcegid Ressources Humaines Spécialiste des logiciels de gestion de la Paie et des Ressources Humaines, Cegid répond aux exigences de l entreprise d aujourd hui, quel que soit le secteur

Plus en détail

Sopra Group Carte de visite

Sopra Group Carte de visite Sopra Group Carte de visite La mise à jour des chiffres clés se fait après chaque publication Groupe Version à utiliser avec Office 2003 Laurent COUSSONNET Directeur T A L E N T E D T O G E T H E R Unissons

Plus en détail

Je découvre Lina Maintenance

Je découvre Lina Maintenance Je découvre Lina Maintenance Une interface simple et ergonomique pour optimiser la maintenance de vos équipements 1 Sommaire Présentation 4 La plateforme Lina 5 Référentiel 6 Agenda et données personnelles

Plus en détail

LIVRE BLANC. Dématérialisation des factures fournisseurs

LIVRE BLANC. Dématérialisation des factures fournisseurs LIVRE BLANC 25/03/2014 Dématérialisation des factures fournisseurs Ce livre blanc a été réalisé par la société KALPA Conseils, société créée en février 2003 par des managers issus de grandes entreprises

Plus en détail

Directeur de projets Maîtrise d ouvrage

Directeur de projets Maîtrise d ouvrage Charbel ACHKAR e-mail Téléphone Adresse pro@charbelachkar.com 06 52 95 22 96 2 Allée Bienville 78420 Carrières Sur Seine France Marié, 2 enfants Né le 23 février 1966 FORMATION Directeur de projets Maîtrise

Plus en détail

Simplification des processus financiers avec la nouvelle application «Simple Finance» de SAP

Simplification des processus financiers avec la nouvelle application «Simple Finance» de SAP Simplification des processus financiers avec la nouvelle application «Simple Finance» de SAP Chantal Rivard, Consultante de Solution SAP Canada 26 novembre 2014 L énigme du temps, de l énergie et de l

Plus en détail

Urbanisation des Systèmes d'information

Urbanisation des Systèmes d'information Urbanisation des Systèmes d'information Les Audits de Systèmes d Information et leurs méthodes 1 Gouvernance de Système d Information Trois standards de référence pour trois processus du Système d Information

Plus en détail

SUPPLY CHAIN MANAGEMENT Eléa 30 mars 2011

SUPPLY CHAIN MANAGEMENT Eléa 30 mars 2011 SUPPLY CHAIN MANAGEMENT Eléa 30 mars 2011 Agenda Généralités sur les systèmes d information logistique Les opérations logistiques Les SI logistiques, du pilotage (long terme) à l informatique industrielle

Plus en détail

Business Project Management : Cycle de vie des documents et workflow

Business Project Management : Cycle de vie des documents et workflow Business Project Management : Cycle de vie des documents et workflow Iut de Tours Département Information-Communication Option Gestion de l Information et du Document dans les Organisations Page 1 sur

Plus en détail

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL 31 août 2004 Plate-Forme Opérationnelle de modélisation INRA ACTA ICTA http://www.modelia.org FICHE DU DOCUMENT 10 mai 04 N.Rousse - : Création : version de

Plus en détail

Ici, le titre de la. Tableaux de bords de conférence

Ici, le titre de la. Tableaux de bords de conférence Ici, le titre de la Tableaux de bords de conférence pilotage d entreprise, indicateurs de performance reporting et BI quels outils seront incontournables à l horizon 2010? Les intervenants Editeur/Intégrateur

Plus en détail

Grands Magasins et Magasins Multi-Commerces

Grands Magasins et Magasins Multi-Commerces Famille professionnelle de l, Secrétaire / Assistant Assistant, assistant administratif Le secrétaire aide à la planification et à l organisation des activités afin de faciliter la gestion de l information.

Plus en détail

Présentation de la Gestion des Exigences (REQM) SopraGroup / Direction de la Transformation et de la Performance : Qualité, Méthode & Outils

Présentation de la Gestion des Exigences (REQM) SopraGroup / Direction de la Transformation et de la Performance : Qualité, Méthode & Outils emedia Présentation de la Gestion des Exigences (REQM) SopraGroup / Direction de la Transformation et de la Performance : Qualité, Méthode & Outils Unissons nos Talents T A L E N T E D T O G E T H E R

Plus en détail

solution technologique globale qui couvre en

solution technologique globale qui couvre en Dealer Management System solution technologique globale qui couvre en amont tous les besoins fonctionnels et techniques de l activité d un distributeur de véhicules : magasin, atelier, VN/VO. Adaptable

Plus en détail

Chapitre 9 : Informatique décisionnelle

Chapitre 9 : Informatique décisionnelle Chapitre 9 : Informatique décisionnelle Sommaire Introduction... 3 Définition... 3 Les domaines d application de l informatique décisionnelle... 4 Architecture d un système décisionnel... 5 L outil Oracle

Plus en détail

Filière de formation :

Filière de formation : Filière de formation : CONSULTANT TESTING HP FOR SAP DOSSIER PEDAGOGIQUE Renseignements et moyens pédagogiques Contenus de cours détaillés Durée : 26 jours (en centre FITEC) Sommaire Sommaire...1 Sommaire...2

Plus en détail

Le "tout fichier" Le besoin de centraliser les traitements des fichiers. Maitriser les bases de données. Historique

Le tout fichier Le besoin de centraliser les traitements des fichiers. Maitriser les bases de données. Historique Introduction à l informatique : Information automatisée Le premier ordinateur Définition disque dure, mémoire, carte mémoire, carte mère etc Architecture d un ordinateur Les constructeurs leader du marché

Plus en détail

et les Systèmes Multidimensionnels

et les Systèmes Multidimensionnels Le Data Warehouse et les Systèmes Multidimensionnels 1 1. Définition d un Datawarehouse (DW) Le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées

Plus en détail

Gestion Projet : Cours 2

Gestion Projet : Cours 2 Gestion Projet : Cours 2 Le Système d Information «Ensemble d acteurs humains et/ou applicatifs en interaction les uns avec les autres ayant pour but de traiter, diffuser, persister l information afin

Plus en détail

Pratique de logiciels de planification

Pratique de logiciels de planification Pratique de logiciels de planification MASTER TECHNOLOGIE & HANDICAP Université Paris 8 Sommaire Introduction Organisation d un projet Les principaux axes de la planification Gestion des tâches Gestion

Plus en détail

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise.

Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Solutions PME VIPDev Nos Solutions PME VIPDev sont les Atouts Business de votre entreprise. Cette offre est basée sur la mise à disposition de l ensemble de nos compétences techniques et créatives au service

Plus en détail

Découvrez la gestion collaborative multi-projet grâce à la. solution Project EPM

Découvrez la gestion collaborative multi-projet grâce à la. solution Project EPM Découvrez la gestion collaborative multi-projet grâce à la solution Project EPM Project EPM 2007 est la solution de gestion de projets collaborative de Microsoft. Issue d une longue expérience dans le

Plus en détail

MINI-PROJET L ERP SAP R/3

MINI-PROJET L ERP SAP R/3 MINI-PROJET L ERP SAP R/3 Marc BEGUIGNEAU DESS QUASSI Promotion 2002/2003 SOMMAIRE! Introduction! Qu est ce qu un ERP! SAP R/3! Conclusion 2 Introduction! ERP (Entreprise Ressources Planning)! PGI (progiciel

Plus en détail

Plaisir, le 19 Décembre 2011 Rapport sur le contrôle interne et le gouvernement d entreprise.

Plaisir, le 19 Décembre 2011 Rapport sur le contrôle interne et le gouvernement d entreprise. Plaisir, le 19 Décembre 2011 Rapport sur le contrôle interne et le gouvernement d entreprise. LES DISPOSITIFS DE GESTION DES RISQUES ET DE CONTRÔLE INTERNE L objet de ce rapport est de rendre compte aux

Plus en détail

Travail sous le thème :

Travail sous le thème : Travail sous le thème : Avant d entamer directement le sujet, il faudra d abord commencer par une définition et une présentation d un ERP pour comprendre les limites qui ont conduit à l adoption d un ERP

Plus en détail

ZODIAC AEROSPACE Page 1 sur 7

ZODIAC AEROSPACE Page 1 sur 7 Plaisir, le 18 décembre Rapport sur le contrôle interne et le gouvernement d entreprise DISPOSITIFS DE GESTION DES RISQUES ET DE CONTRÔLE INTERNE Cette partie du rapport s appuie sur le cadre de référence

Plus en détail

QU EST-CE QUE LE DECISIONNEL?

QU EST-CE QUE LE DECISIONNEL? La plupart des entreprises disposent d une masse considérable d informations sur leurs clients, leurs produits, leurs ventes Toutefois ces données sont cloisonnées par les applications utilisées ou parce

Plus en détail

Le parcours pédagogique Sage Business Intelligence. Utilisateur Niv I BO XI 3.0 WebI pour Sage 1000 2 jours

Le parcours pédagogique Sage Business Intelligence. Utilisateur Niv I BO XI 3.0 WebI pour Sage 1000 2 jours Vous êtes Consultant, Chef de Projets, Directeur des Systèmes d Information, Directeur Administratif et Financier, Optez pour les «formations Produits» Nous vous proposons des formations vous permettant

Plus en détail

Contractualiser un projet Agile. Comment s engager sans forfait global?

Contractualiser un projet Agile. Comment s engager sans forfait global? Contractualiser un projet Agile Comment s engager sans forfait global? Sommaire Le contrat au forfait : objectifs et limites Les critères de choix d un fournisseur Les trois engagements incontournables

Plus en détail

Sébastien MUR. Objectifs. Expériences Professionnelles. Consultant Junior Transverse SI (technique et fonctionnel)

Sébastien MUR. Objectifs. Expériences Professionnelles. Consultant Junior Transverse SI (technique et fonctionnel) Sébastien MUR http://sebastienmur.netcv.org Objectifs Consultant Junior Transverse SI (technique et fonctionnel) Bonjour! Actuellement en stage de fin d'étude dans une SSII en tant que Consultant Technico/Fonctionnel,

Plus en détail

M I S E E N P L A C E D U N O U T I L D E M A N A G E M E N T D E P R O J E T

M I S E E N P L A C E D U N O U T I L D E M A N A G E M E N T D E P R O J E T M I S E E N P L A C E D U N O U T I L D E M A N A G E M E N T D E P R O J E T F A C I L I T A N T L A G E S T I O N C O N T R A C T U E L L E Q U O T I D I E N N E D U M A I T R E D O E U V R E D E X E

Plus en détail

Master Logistique parcours logistique industrielle

Master Logistique parcours logistique industrielle IUP - Management et Gestion des Entreprises Master Logistique parcours logistique industrielle 008/009 Lieu de formation : Clermont-Ferrand Références de l'enquête : diplômés issus de la promotion 009

Plus en détail

Accélérateur de votre RÉUSSITE

Accélérateur de votre RÉUSSITE Accélérateur de votre RÉUSSITE En choisissant SAP Business One, entrez dans un monde sans frontière, ouvert, mobile, agile et social. Achats Finance Avec une seule plateforme, vous répondez à l ensemble

Plus en détail

Chiffre d affaires 2014 pro forma : 3 370,1 M Résultat Net Part du Groupe pro forma : 92,8 M

Chiffre d affaires 2014 pro forma : 3 370,1 M Résultat Net Part du Groupe pro forma : 92,8 M Communiqué de presse Chiffre d affaires pro forma : 3 370,1 M Résultat Net Part du Groupe pro forma : 92,8 M Paris, le 19 mars 2015 Le Conseil d administration du Groupe Sopra Steria, réuni le 17 mars

Plus en détail

Optimiser la recherche d informations dans deux des Bases de Données internes et Accroître la productivité des analystes

Optimiser la recherche d informations dans deux des Bases de Données internes et Accroître la productivité des analystes Optimiser la recherche d informations dans deux des Bases de Données internes et Accroître la productivité des analystes Mémoire de stage Promotion 2010 Priscillia VON HOFMANN Abstract Today, the importance

Plus en détail

RAPID 3.34 - Prenez le contrôle sur vos données

RAPID 3.34 - Prenez le contrôle sur vos données RAPID 3.34 - Prenez le contrôle sur vos données Parmi les fonctions les plus demandées par nos utilisateurs, la navigation au clavier et la possibilité de disposer de champs supplémentaires arrivent aux

Plus en détail

GESTION DE PROJET. www.ziggourat.com - Tél : 01 44 61 96 00 N enregistrement formation : 11752861675

GESTION DE PROJET. www.ziggourat.com - Tél : 01 44 61 96 00 N enregistrement formation : 11752861675 GESTION DE PROJET www.ziggourat.com - Tél : 01 44 61 96 00 N enregistrement formation : 11752861675 Introduction à la Gestion de Projet... 3 Management de Projet... 4 Gestion de Projet informatique...

Plus en détail

Cahier des charges n 06-AMO-02

Cahier des charges n 06-AMO-02 Cahier des charges n 06-AMO-02 Relatif à une évaluation du projet de mise en œuvre de SAP dans le domaine budgétaire, financier et comptable Table des matières 1 Présentation de l 2 2 Le contexte des SI

Plus en détail

1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM

1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM 1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM Scrum est une méthode agile pour la gestion de projets informatiques. C est une méthode itérative basée sur des itérations de courte durée appelées Sprints.

Plus en détail

Management par les processus Les facteurs clés de succès. Lionel Di Maggio Master 1 MIAGE

Management par les processus Les facteurs clés de succès. Lionel Di Maggio Master 1 MIAGE Management par les processus Les facteurs clés de succès Lionel Di Maggio Master 1 MIAGE 1 1. Objectifs et définitions 2. Le retour sur investissement des démarches 3. Les éléments structurants 4. Mise

Plus en détail

L assistance à maîtrise des projets logistiques risqués

L assistance à maîtrise des projets logistiques risqués L assistance à maîtrise des projets logistiques risqués Congrès Eurolog 21 juin 2006 Michel Fender Professeur Ecole nationale des ponts et chaussées Président Département Management Industriel, ENPC Co-directeur

Plus en détail

W4 - Workflow La base des applications agiles

W4 - Workflow La base des applications agiles W4 - Workflow La base des applications agiles, W4 philippe.betschart@w4global.com Vous avez dit «workflow»? Processus : Enchaînement ordonné de faits ou de phénomènes, répondant à un certain schéma et

Plus en détail

FICHE CONCEPT 01 ETL (EXTRACT TRANSFORM & LOAD)

FICHE CONCEPT 01 ETL (EXTRACT TRANSFORM & LOAD) FICHE CONCEPT 01 ETL (EXTRACT TRANSFORM & LOAD) BIEN GERER SES REFERENTIELS DE DONNEES : UN ENJEU POUR MIEUX PILOTER LA PERFORMANCE DE SON ETABLISSEMENT octobre 2008 GMSIH 44, Rue de Cambronne 75015 Paris.

Plus en détail

Le parcours pédagogique Sage 1000 Suite Financière ENVIRONNEMENT FONDAMENTAUX THEMATIQUES. Sage 1000 Comptabilité. 4 jours.

Le parcours pédagogique Sage 1000 Suite Financière ENVIRONNEMENT FONDAMENTAUX THEMATIQUES. Sage 1000 Comptabilité. 4 jours. Vous êtes consultant, chef de projets, acteur clé au sein de votre entreprise et vous intervenez en phase de déploiement ou de paramétrage d un logiciel Sage, Optez pour les formations «Produits» : Nous

Plus en détail

UE 5 Management des systèmes d informations. Le programme

UE 5 Management des systèmes d informations. Le programme UE 5 Management des systèmes d informations Le programme Légende : Modifications de l arrêté du 8 mars 2010 Suppressions de l arrêté du 8 mars 2010 Partie inchangée par rapport au programme antérieur 1.

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

DÉMATÉRIALISATION DES DOCUMENTS ET AUTOMATISATION DES PROCESSUS UN PREMIER PAS VERS LA BANQUE SANS PAPIER

DÉMATÉRIALISATION DES DOCUMENTS ET AUTOMATISATION DES PROCESSUS UN PREMIER PAS VERS LA BANQUE SANS PAPIER DÉMATÉRIALISATION DES DOCUMENTS ET AUTOMATISATION DES PROCESSUS UN PREMIER PAS VERS LA BANQUE SANS PAPIER Pour les banques, le papier devrait servir à imprimer des billets ; pas à en garder la trace dans

Plus en détail

Consultant Dynamics AX Supply Chain

Consultant Dynamics AX Supply Chain Filière de Formation : Consultant Dynamics AX Supply Chain DOSSIER PEDAGOGIQUE Renseignements et moyens pédagogiques Contenus de cours détaillés Durée : 40 jours Sommaire Sommaire... 2 Découpage de la

Plus en détail

CHEF DE PROJET FORMATION COMPETENCES. Anne COUSTENOBLE App. 72 8, rue d Atlanta 59700 MARCQ EN BAROEUL 06-18-06-44-27 acoustenoble@free.

CHEF DE PROJET FORMATION COMPETENCES. Anne COUSTENOBLE App. 72 8, rue d Atlanta 59700 MARCQ EN BAROEUL 06-18-06-44-27 acoustenoble@free. Anne COUSTENOBLE App. 72 8, rue d Atlanta 59700 MARCQ EN BAROEUL 06-18-06-44-27 acoustenoble@free.fr 34 ans, née le 07/12/1977 Mariée CHEF DE PROJET FORMATION 2000 : Diplôme d Ingénieur de l école des

Plus en détail

TABLE DES MATIÈRES CHAPITRE 1 CHAPITRE 2 CHAPITRE 3 APPLICATIONS... 27 APPLICATIONS... 34

TABLE DES MATIÈRES CHAPITRE 1 CHAPITRE 2 CHAPITRE 3 APPLICATIONS... 27 APPLICATIONS... 34 TABLE DES MATIÈRES CHAPITRE 1 L information et le système d information... 19 I. La place du système d information dans l organisation... 19 A. L organisation et ses composants... 19 B. L organisation

Plus en détail

Le logiciel Négoce International du Système COSMOS

Le logiciel Négoce International du Système COSMOS Le logiciel Négoce International du Système COSMOS Le logiciel «Cosmos Négoce International» est une gestion commerciale complète spécialisée pour les entreprises dont les activités de ventes aux clients

Plus en détail

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition)

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition) Avant-propos 1. Objectifs du livre 13 2. Structure du livre 14 Un projet informatique 1. Les enjeux 17 1.1 Les buts d'un projet 17 1.2 Les protagonistes d'un projet 18 1.3 Exemples de projets 19 2. Les

Plus en détail

UE 8 Systèmes d information de gestion Le programme

UE 8 Systèmes d information de gestion Le programme UE 8 Systèmes d information de gestion Le programme Légende : Modifications de l arrêté du 8 mars 2010 Suppressions de l arrêté du 8 mars 2010 Partie inchangée par rapport au programme antérieur Indications

Plus en détail

NOTE D APPLICATION EXIGENCES DE SECURITE POUR UN CHARGEMENT DE CODE EN PHASE D'UTILISATION

NOTE D APPLICATION EXIGENCES DE SECURITE POUR UN CHARGEMENT DE CODE EN PHASE D'UTILISATION P R E M I E R M I N I S T R E Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d information Paris, le 23 janvier 2015 N 260/ANSSI/SDE/PSS/CCN

Plus en détail

IBM Cognos TM1. Fiche Produit. Aperçu

IBM Cognos TM1. Fiche Produit. Aperçu Fiche Produit IBM Cognos TM1 Aperçu Cycles de planification raccourcis de 75 % et reporting ramené à quelques minutes au lieu de plusieurs jours Solution entièrement prise en charge et gérée par le département

Plus en détail

Formations Méthode et conduite de projet

Formations Méthode et conduite de projet Formations Méthode et conduite de projet Présentation des formations Qualité et Conduite de projets Mettre en place et gérer un projet SI nécessite diverses compétences comme connaître les acteurs, gérer

Plus en détail

SQL Server 2012 Implémentation d'une solution de Business Intelligence (Sql Server, Analysis Services...)

SQL Server 2012 Implémentation d'une solution de Business Intelligence (Sql Server, Analysis Services...) Avant-propos 1. À qui s'adresse ce livre? 15 2. Pré-requis 15 3. Objectifs du livre 16 4. Notations 17 Introduction à la Business Intelligence 1. Du transactionnel au décisionnel 19 2. Business Intelligence

Plus en détail

Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009»

Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009» Concours EXTERNE d ingénieur des systèmes d information et de communication «Session 2009» Meilleure copie "Rapport Technique" Thème : conception et développement logiciel Note : 15,75/20 Rapport technique

Plus en détail

Qu est-ce qu une solution d affaires intégrée (ERP)? Automne 2004 Séance 1 Pierre-Majorique Léger (pierre-majorique.leger@hec.ca) 3-715-00 Automne 2004 Séance 1, page 1 1- Qu est-ce qu une solution d affaires

Plus en détail

Excellente performance au premier semestre 2011 pour Sopra Group

Excellente performance au premier semestre 2011 pour Sopra Group Communiqué de Presse Contacts Relations Investisseurs : Kathleen Clark Bracco +33 (0)1 40 67 29 61 kbraccoclark@sopragroup.com Relations Presse : Virginie Legoupil +33 (0)1 40 67 29 41 vlegoupil@sopragroup.com

Plus en détail

Présentation de l offre produit de Business Objects XI

Présentation de l offre produit de Business Objects XI Conseil National des Assurances Séminaire - Atelier L information au service de tous Le 09 Novembre 2005 Présentation de l offre produit de XI Amar AMROUCHE Consultant Avant Vente aamrouche@aacom-algerie.com

Plus en détail

SQL Server 2014 Implémentation d'une solution de Business Intelligence (Sql Server, Analysis Services, Power BI...)

SQL Server 2014 Implémentation d'une solution de Business Intelligence (Sql Server, Analysis Services, Power BI...) Avant-propos 1. À qui s'adresse ce livre? 15 2. Pré-requis 15 3. Objectifs du livre 16 4. Notations 17 Introduction à la Business Intelligence 1. Du transactionnel au décisionnel 19 2. Business Intelligence

Plus en détail

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS Méthode de tests MODE D EMPLOI Cette première partie est destinée à ceux qui débutent en tests et permet une approche progressive et simple de la méthodologie des tests. L introduction vous aura permis

Plus en détail

Generali France optimise la visibilité et la gestion de l ensemble du portefeuille de projets informatiques grâce à la solution PPM de CA Clarity.

Generali France optimise la visibilité et la gestion de l ensemble du portefeuille de projets informatiques grâce à la solution PPM de CA Clarity. PRESENTATION DE LA TECHNOLOGIE : INNOVATION ET TRANSFORMATION DES ACTIVITES Generali France optimise la visibilité et la gestion de l ensemble du portefeuille de projets informatiques grâce à la solution

Plus en détail

Demande d Information

Demande d Information Lettre de Demande d Information Réf. : RFI20100001_CRSP_BSC_final.docx SG - CRSP Page 1/20 SOMMAIRE 1. OBJET DE LA DEMANDE D INFORMATION... 3 2. PÉRIMÈTRE DE L INFORMATION... 3 2.1. UTILISATEURS DE L APPLICATION...

Plus en détail

Contexte. Objectif. Enjeu. Les 3 questions au cœur du Pilotage de la Performance :

Contexte. Objectif. Enjeu. Les 3 questions au cœur du Pilotage de la Performance : Contexte Il est naturel de construire et d adapter son système d information à son métier pour répondre aux besoins opérationnels et quotidiens. Facturation, production, gestion de stocks, ressources humaines,

Plus en détail

Le Référentiel Management/Encadrement

Le Référentiel Management/Encadrement répertoire des métiers Le Référentiel Management/Encadrement Le management/encadrement est vu comme une fonction transversale liée à l organisation et à l ensemble des familles professionnelles. Le référentiel

Plus en détail

Le Choix d un PGI Année 2005/2006

Le Choix d un PGI Année 2005/2006 Le Choix d un PGI Année 2005/2006 ESCI Bourg en Bresse PLAN D ENSEMBLE 1/ Objectifs 2/ Fonctionnement et apports d un progiciel intégré 3/ Cas pratique 1 : Démarche de choix et points clés 4/ Choix d un

Plus en détail

LES TESTS. Les tests. Organisation d un projet de recette Les types de tests Les outils

LES TESTS. Les tests. Organisation d un projet de recette Les types de tests Les outils Les tests Organisation d un projet de recette Les types de tests Les outils Organiser le déroulement des tests Spécifier Exécuter les Cahiers de tests les Cahiers de tests Analyser les résultats Correction

Plus en détail

CONSULTING, BANQUE & ASSURANCE. axiwell LE SENS DE L ESSENTIEL

CONSULTING, BANQUE & ASSURANCE. axiwell LE SENS DE L ESSENTIEL CONSULTING, BANQUE & ASSURANCE axiwell LE SENS DE L ESSENTIEL SOMMAIRE Édito... page 3 Axiwell Financial Services... Exemples de missions réalisées... Nos offres spécifiques... Risques / Conformité / Réglementaire...

Plus en détail

Tous droits réservés SELENIS

Tous droits réservés SELENIS 1. Objectifs 2. Etapes clefs 3. Notre proposition d accompagnement 4. Présentation de SELENIS 2 Un projet est une réalisation spécifique, dans un système de contraintes donné (organisation, ressources,

Plus en détail

BUSINESS INTELLIGENCE

BUSINESS INTELLIGENCE GUIDE COMPARATIF BUSINESS INTELLIGENCE www.viseo.com Table des matières Business Intelligence :... 2 Contexte et objectifs... 2 Une architecture spécifique... 2 Les outils de Business intelligence... 3

Plus en détail

PHASE SOUS-PHASE MOA MOE POINTS A TRAITER. besoins. charges. I.A.2 Échéances. I.A.3 Utilisateurs. I.A.4 Besoin fonctionnels. I.A.5 Évolutions à venir

PHASE SOUS-PHASE MOA MOE POINTS A TRAITER. besoins. charges. I.A.2 Échéances. I.A.3 Utilisateurs. I.A.4 Besoin fonctionnels. I.A.5 Évolutions à venir PHASE SOUS-PHASE MOA MOE POINTS A TRAITER I. La définition des I.A. L'expression des besoins Rédige (spécifie les besoins). Consulte / utilise pour rédiger le cahier des I.A.1 Positionnement stratégique

Plus en détail

Comment booster vos applications SAP Hana avec SQLSCRIPT

Comment booster vos applications SAP Hana avec SQLSCRIPT DE LA TECHNOLOGIE A LA PLUS VALUE METIER Comment booster vos applications SAP Hana avec SQLSCRIPT 1 Un usage optimum de SAP Hana Votre contexte SAP Hana Si vous envisagez de migrer vers les plateformes

Plus en détail