Vous êtes sur la page 1sur 127
bu
bu
bu THESE PROFESSIONNELLE Les facteurs de réussite d’un projet de migration de données dans SAP Seydou

THESE PROFESSIONNELLE

Les facteurs de réussite d’un projet de migration de données dans SAP

Seydou LY

Mastère Spécialisé « Management des Systèmes d’Information Répartis »

Promotion 2005-2007

Tuteur formation : Mr Dominique Briolat

d

Les facteurs de réussite d’un projet de migration de données dans SAP

Page de garde

Nom

LY

Prénom

Seydou

Programme – promotion

MSIR 2005-2007

Adresse pour le renvoi par la poste

 

Téléphone portable personnel

 

Téléphone fixe personnel

 

Email personnel et professionnel

 

Version

finale

Nombre de pages

125

Numéro des chapitres inclus dans la version précédente

 

Numéro des nouveaux chapitres inclus dans cette nouvelle version

 

Les facteurs de réussite d’un projet de migration de données dans SAP

Remerciements

Je tiens à remercier M. Dominique BRIOLAT pour sa contribution à la validation de ce document, pour ses conseils et sa disponibilité durant l’élaboration de ce document en tant que tuteur de thèse et surtout pour sa patience.

J’en profite également pour remercier toute l’équipe académique de l’ESSEC et de l’ENST Paris qui fait un travail remarquable pour garantir l’excellence de ce mastère.

Pour m’avoir accepté au sein de cette formation enrichissante et très motivante, je remercie René JOLY et Dominique BRIOLAT.

Merci à mes chers camarades avec qui j’ai partagé des moments de bonheur durant ses deux années.

Les facteurs de réussite d’un projet de migration de données dans SAP

« Celui qui dit que deux et deux font quatre, a-t-il une connaissance de plus que celui qui se contenterait de dire que deux et deux font deux et deux ? »

(Jean le Rond d'Alembert)

« La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information. »

(Albert Einstein)

Les facteurs de réussite d’un projet de migration de données dans SAP

Sommaire

 

RESUME

9

INTRODUCTION

11

1.

PRESENTATION DU GROUPE DEBIERE

13

1.1 Présentation générale

13

1.2 Historique

14

1.3 Organisation

15

1.4 Mission, Vision & Valeurs DeBiere

15

1.5 Le projet OMEGA DeBiere

17

2. MIGRER DES DONNEES

21

2.1

Définitions

22

2.1.1 Qu’est-ce qu’une donnée ?

22

2.1.2 Qu’est-ce qu’une migration de données ?

22

2.2 Pourquoi migrer des données ?

23

2.3 Produits & Marché

24

2.4 La migration de données : un projet parallèle

28

2.4.1 Organisation

30

2.4.2 Stratégies de migration

32

2.4.3 Documentation

33

2.4.4 La qualité des données migrées

33

2.4.5 Choix et Spécification des outils

36

2.4.6 Préparation de la mise en œuvre

36

2.5

Les facteurs de risque d'un projet de Migration de données

36

3. PRESENTATION DE SAP

37

3.1 Présentation générale de l’entreprise SAP

38

3.2 Historique

39

3.3 Présentation de SAP R/3

43

3.3.1 Vue Fonctionnelle

43

3.3.2 Vue Organisationnelle

44

3.4

Architecture du système SAP R/3

46

3.4.1 Environnement client/serveur

47

3.4.2 La hiérarchie à trois niveaux

48

Les facteurs de réussite d’un projet de migration de données dans SAP

3.5

Principes de la base de données chez SAP

51

3.5.1 Base de données

51

3.5.2 Structure d’une base de données

51

3.5.3 Système de gestion des bases de données relationnel (SGDBR)

52

3.5.4 Bases de données supportées par SAP

52

3.5.5 Métadonnées

52

3.5.6 Le modèle de données d’entreprise SAP

53

4. LA MIGRATION DE DONNEES DANS SAP

54

4.1 La Migration de données de SAP R/2 vers SAP R/3

56

4.2 La Migration de données d’un système non-SAP (legacy system) vers SAP R/3

58

4.2.1

L’atelier de reprise de données d'anciens systèmes (Legacy System Migration Workbench (LSMW)),

"l'arme absolue"

59

4.2.2 Différentes façons d'utiliser LSMW

60

4.2.3 Atouts et limites du LSMW

61

4.3

Techniques & Outils de Conversion de données dans SAP

62

4.3.1

Les techniques

63

4.3.1.1 Saisie manuelle (Manual Input)

63

4.3.1.2 Entrée par lots (Batch Input)

63

4.3.1.3 Traitement par transaction (Call Transaction)

63

4.3.1.4 Entrée directe (Direct Input)

63

 

4.3.1.5

ALE / IDOC

63

4.3.2

Les outils

64

4.3.2.1 LSMW

64

4.3.2.2 L’outil CATT (Computer Aided Test Tool)

64

4.3.2.3 Modules fonctions standards, BAPI (Business Application Programming interface)

64

5. ANALYSE DU PROJET DE MIGRATION DE DONNEES

CHEZ DEBIERE

66

5.1 Contexte et Enjeu

66

5.2 Déroulement du projet de migration de données

66

5.2.1

L’approche migration de données chez DeBiere

66

5.2.1.1

Correspondance des données (mapping des données)

67

5.2.1.1

Extraction des données

68

5.2.1.2

Manipulation des données

68

5.2.1.3

Vérification des données

68

5.2.1.4

Chargement des données

68

5.2.1.5

Réconciliation des données

69

5.2.2 Organisation

71

5.2.3 Stratégie de migration

73

5.2.4 Documentation

74

5.2.5 La qualité des données migrées

74

5.2.6 Choix et spécification des outils

75

5.2.7 La mise en œuvre

75

5.2.8 Les risques

77

Les facteurs de réussite d’un projet de migration de données dans SAP

5.3 Typologie des données reprises

78

5.4 Bilan

80

6. FACTEURS CLES DE SUCCES ET RECOMMANDATIONS .81

CONCLUSION

83

REFERENCES

87

ANNEXES

88

Présentation de SAP – Exemple : création d’un outil de chargement via LSMW dans SAP – Guide de chargement via LSMW

89

Planning de suivi des chargements

101

Template : Fichier de chargement des données. Exemple : fichier de chargement des conditions de prix

102

Template : Mapping des données. Exemple : fichier de mapping des conditions de prix

104

COMMENT FONCTIONNE UN LSMW BATCH INPUT RECORDING?

106

Les facteurs de réussite d’un projet de migration de données dans SAP

Table des figures

Figure 1.1 – Les 4 produits vedettes DeBiere : Stella Artois®, Brahma®, Beck’s® et Leffe®

13

Figure 1.2 - Classement des 5 premiers brasseurs mondiaux

17

Figure 1.3 : La migration de données intégrée aux processus métier

20

Figure 2.1 : Schéma du processus de reprise des données

23

Figure 2.2 : Le contexte de la migration de données

24

Figure 2. 3 : Cycle de vie processus de conversion et reprise de données

29

Figure 2.4 : Equipe de Migration des données intégrée au processus global de migration

31

Figure 3.1 : Modèle d’intégration de R/3

38

Figure 3.2 : Solutions complètes d'industrie

39

Figure 3.3 : Principales unités structurelles SAP

44

Figure 3.4 L’architecture du système SAP R/3 comprend des serveurs de bases de données, des

serveurs d’applications et des systèmes de

46

Figure 3.5 : Une architecture standard client/serveur relie les stations de travail au serveur

47

Figure 3.6 : L’architecture à 3 niveaux est devenue le concept architectural standard des installations SAP R/3

48

Figure 3.7 : SAP s’interface avec plusieurs systèmes

49

Figure 3.8 : Types de données SAP

53

Figure 4.1 : La migration de données dans SAP

55

Figure 4.2 : Comment migrer les données de R/2 vers R/3 ?

56

Figure 4.3 La migration de SAP R/2 vers SAP R/3

58

Figure 4.4 : Comment migrer les données d’un système Legacy vers SAP R/3 ?

58

Figure 4.5 : Le fonctionnement de LSMW

60

Figure 5.1 : L’approche migration de donnée chez DeBiere intégrée au processus global de migration

67

Figure 5.3 : La structure du projet Omega

71

Figure 5.4 : L’équipe migration de données chez DeBiere

72

Les facteurs de réussite d’un projet de migration de données dans SAP

Tableaux

Tableau 1.1 : Quelques chiffres clés DeBiere

17

Tableau 1.2 : Planning de démarrage par pays

19

Tableau 2.1 : Les principaux éditeurs d’ETL

27

Tableau 3.1 : Part de marché en 2005 des éditeurs d’ERP en France (Source PAC)

40

Tableau 3.2 : Les dates clés du développement de SAP

41

Tableau 3.3 : Quelques chiffres clés de SAP

42

Les facteurs de réussite d’un projet de migration de données dans SAP

Résumé

Désormais au cœur des stratégies d’entreprises, les systèmes d’information sont de plus en plus confrontés à une spirale d’évolutions permanentes : changements d’environnements techniques,

risques d’obsolescence de certaines plate-formes, rapprochements de systèmes d’information dans

le cadre de fusions, généralisation des nouvelles technologies,

l’enjeu pour les entreprises est triple, d’abord capitaliser sur l’existant en ne perdant rien de la richesse de leurs informations et données, permettre la continuité du fonctionnement des systèmes d’information pendant la migration, de façon la plus transparente possible pour les utilisateurs et enfin veiller à la maîtrise totale du projet, en terme de coûts, délais et risques. Pour répondre à ces enjeux stratégiques, il est nécessaire de maîtriser son projet de migration et en particulier son projet de migration de données.

Face à ces problématiques,

La problématique de migration de données recouvre des situations variées. Il peut d’agir d'une fusion ou d'un rapprochement de sociétés, les données devant être portées vers le système cible retenu ou dans le cadre de l'intégration d'un ERP ou de l’alimentation d’un entrepôt de données (data warehouse). Enfin, il peut aussi s’agir d’une rénovation de systèmes d’information, avec une évolution vers un SGBD plus pérenne (passage d’IDS2 à Oracle, de DL1 ou Datacom à DB2, …).

Quiconque s’est lancé dans un projet de migration de données ou de consolidation de systèmes à grande échelle sait à quel point déplacer massivement les données est une tâche difficile et risquée surtout si l’on ne prépare, ni ne planifie son projet de migration de migration de données. Celle-ci implique des transformations et des conversions complexes ainsi que des opérations de nettoyage et de validation de données.

Nous avons analysé la migration de données chez DeBiere 1 et à partir de cette analyse, nous avons dégagé quelques éléments clés qui contribuent au succès d’un projet de migration de données et avons pu faire quelques recommandations.

Il était indispensable de comprendre d’abord les raisons et objectifs qui ont poussé DeBiere à migrer ses données dans SAP, en faisant une présentation générale de l’entreprise et en expliquant le contexte et les enjeux. Le choix de SAP ne s’est pas fait par hasard, c’est pour cela que j’ai présenté la technologie sur laquelle j’ai travaillé tout au long de cette étude : SAP R/3, afin de

1 Le nom de la société a été changé en Debiere

Les facteurs de réussite d’un projet de migration de données dans SAP

comprendre les évolutions et les raisons du succès de ce progiciel d’une part et d’autre part la manière dont les données s’intègrent dans SAP. L’autre aspect de notre étude est la qualité des données. Migrer les données est une chose, encore faudrait-il qu’elles soient exploitables et qu’elles ne soient pas obsolètes. En conséquence, pour réussir l’implémentation des applications d’entreprise SAP, une approche rigoureuse de la migration de données est indispensable.

Les facteurs de réussite d’un projet de migration de données dans SAP

Introduction

Le traitement de l'information dans l'entreprise est en pleine mutation. Les changements

fondamentaux (compétitivité accrue, acquisitions, fusions, mondialisation, etc

plus en plus d'entreprises à mieux organiser leur système d’information (SI) et à migrer leurs applications informatiques internes vers les progiciels de gestion intégrés du marché, ou ERP (Enterprise Resource Planning), qui offrent des solutions transversales, homogènes, intégrées, efficaces et évolutives. De nombreuses entreprises voient dans leur Système d’Information un vecteur d’innovation souvent stratégique.

)

conduisent de

De plus, le client est maintenant très exigeant et, même pire, ses exigences sont en changement continu. Il ne veut pas seulement un prix bas, mais des délais plus courts et une meilleure qualité (ensemble de caractéristiques du produit qui le satisfassent). Et en plus, il faut innover fréquemment pour apporter au Client une qualité qu’il ne trouve pas ailleurs.

Pour répondre à ce défi, il faut véhiculer une information homogène et enrichie sur les clients et sur chaque maillon de la chaîne informationnelle de la prise de la commande, à l’approvisionnement et à la production, il faut avoir un référentiel fiable de données commun.

Les technologies de l’information, notamment dans le domaine des réseaux et des bases de données, offrent des opportunités permettant aux entreprises de se différencier, de créer de nouveaux services, de capter de nouveaux marchés. Certes le stratégique d’aujourd’hui deviendra l’opérationnel de demain, mais les entreprises qui ont cette vision stratégique développent des positions dominantes.

Attention, cependant une mise en place des SI, notamment des ERP peut tourner au cauchemar car il existe des risques réels de dérapage en termes de coûts et de délais, dus parfois une sous- estimation de la charge, tant pour l’élaboration du volet technique (paramétrage) que pour celle du volet organisationnel (analyse des processus de l’entreprise et des pratiques métier) ou celle de sa migration de données car d’après une étude qui a été réalisée par « the Standish group » :

Plus de 80% des projets d'intégration de données échouent ou débordent,étude qui a été réalisée par « the Standish group » : la moitié des projets

la moitié des projets excèdent le planning de trois quarts,d'intégration de données échouent ou débordent, les budgets excédent de deux tiers, 1/3 d’entre eux

les budgets excédent de deux tiers,moitié des projets excèdent le planning de trois quarts, 1/3 d’entre eux échouent entièrement. MSIR Page

1/3 d’entre eux échouent entièrement.des projets excèdent le planning de trois quarts, les budgets excédent de deux tiers, MSIR Page

Les facteurs de réussite d’un projet de migration de données dans SAP

Les entreprises qui investissent des moyens financiers et humains considérables pour déployer des applications intégrées, savent à quel point déplacer massivement les données d’une unité centrale (mainframe) ou d’autres sources est un parcours semé d’embûches, impliquant des transformations et des conversions complexes ainsi des opérations de nettoyage et de validation de données.

Malgré ces dépenses et ces efforts, nombre de solutions ont encore aujourd’hui du mal à tenir leurs promesses. Il est indispensable de comprendre que la valeur d’un ERP, de même que celle d’une solution de Supply Chain Management (SCM ou en français GCL, gestion de la chaîne logistique) ou de Business Intelligence (BI ou en français informatique décisionnelle), dépend principalement de la qualité des données qui l’alimentent. Le fait que les clients cherchent à aller toujours plus loin dans l’intégration de leurs activités et de leurs processus métiers impose aujourd’hui des niveaux inédits de qualité des données. La haute qualité des données de référence est essentielle afin de garantir l’efficacité des échanges de données entre les entités régionales d’une même entreprise, ainsi qu’avec et entre les fabricants, fournisseurs et distributeurs de l’entreprise.

De nombreuses études ont montré qu’une préparation et une planification insuffisantes des migrations de données pouvaient gravement pénaliser les projets d’implémentation de logiciels. Pour réussir l’implémentation des applications d’entreprise, une approche rigoureuse de la migration de données est indispensable. La migration de données ne consiste pas simplement à transférer les données mais, il s’agit de faire en sorte qu’une fois transférées, ces données soient exploitables.

La migration de données n’est donc pas une mince affaire, d’où la nécessité absolue de bien maîtriser son projet de migration de données.

Au cours de la présente thèse, nous conduisons l’étude des facteurs de réussite d’un projet de migration de données dans les entreprises. Cette étude est appliquée sur le cas du projet DeBiere. Nous présenterons d’abord la société DeBiere c’est-à-dire que nous décrirons le contexte du projet DeBiere. Ensuite nous essayerons de comprendre ce qu’est la migration de données dans sa globalité avant d’expliquer comment elle est réalisée dans SAP. Nous répondrons à cette problématique par l’analyse du projet DeBiere et en faisant des recommandations en vue de minimiser les risques des projets d’intégration de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

1. Présentation du groupe DeBiere 2

Dans ce chapitre nous parlerons de l’entreprise DeBiere, son histoire, ses différentes acquisitions et fusions, son organisation afin de mieux comprendre pourquoi l’entreprise a choisi de migrer ses applications vers un nouveau système d’information commun, ce qui induit une migration des données vers ce nouveau système. Nous terminerons ce chapitre en expliquant les véritables objectifs et enjeux de ce projet d’implémentation. L’intérêt de ce chapitre réside dans le fait qu’il nous donne des indications sur la taille du projet de migration de données de par la taille de l’entreprise et de ses activités dans le monde, sur son importance aussi notamment celle de la qualité des données chez DeBiere puisque nous verrons que cette entreprise a une véritable ambition, devenir la meilleure.

1.1 Présentation générale

Le groupe DeBiere est le premier brasseur mondial en termes de volumes, avec des positions leaders en Amérique, Europe et Asie. DeBiere est une entreprise cotée en bourse dont le siège social est basé à Louvain (Leuven) en Belgique. Elle a réalisé en 2006 un chiffre d’affaires net de 13.3 milliards d'euros.

Forte d’un portefeuille de plus de 200 marques dont 4 marques mondiales vedettes : Stella Artois®, Beck’s®, Brahma® et Leffe®, DeBiere détient 14% du marché brassicole mondial avec 246,5 millions d’hectolitres par an.

mondial avec 246,5 millions d’hectolitres par an. Figure 1.1 – Les 4 produits vedettes DeBiere :

Figure 1.1 – Les 4 produits vedettes DeBiere : Stella Artois®, Brahma®, Beck’s® et Leffe®.

2 Le nom de la société a été changé en DeBiere

Les facteurs de réussite d’un projet de migration de données dans SAP

Le groupe DeBiere emploie près de 88 000 collaborateurs et déploie ses activités dans plus de 130 pays sur le continent américain, en Europe et dans la zone Asie-Pacifique. DeBiere a créé des chaînes de bars et brasseries pour vendre directement ses produits : en France, elle représente 200 enseignes.

1.2 Historique

Les origines de DeBiere remontent à 1366 avec la brasserie « Den Horn ». En 1717, Sebastien Artois, brasseur principal, a acheté la brasserie et a changé son nom en Artois. Mais ce n’est qu’en 1987, lors de la fusion des brasseries belges Artois (Louvain) et Piedboeuf (Jupiller), que l’entreprise pris le nom d’Interbrew, « The World’s Local Brewer ». Dès lors, le groupe cherche avant tout à s’ouvrir vers l’international. Les acquisitions s’enchaînent avec en 1991, la 1ère acquisition étrangère d’Interbrew : la brasserie Borsodi (Hongrie). Puis ce premier investissement signe ainsi l’entrée d’Interbrew sur le marché de la bière en Europe centrale. Puis en 1995 l’entrée du groupe sur le continent Nord Américain avec l’acquisition de la Brasserie Labatt au Canada et en 1999 Interbrew s’ouvre au marché russe avec Sun Interbrew.

En 2000 et 2001, Interbrew s’implante respectivement au Royaume Uni avec les acquisitions de Whitbread et Bass et en Allemagne avec les marques Becks et Diebels. La puissance du groupe s’accentue au fil des acquisitions mais Interbrew ne compte pas s’arrêter en chemin et poursuit son ascension avec ses implantations en Chine en 2002 grâce à sa participation dans KK Brewery et son partenariat avec la brasserie Zhujiang. En 2003, le groupe décide de consolider sa position sur des marchés clés tels que la Chine (acquisition de Lion Group Breweries) ou l’Allemagne (acquisition de Spaten). Interbew devient alors numéro 3 en Chine et numéro 2 en Allemagne avec des marques sur tous les segments.

En 2004, Interbrew, troisième brasseur mondial en volume, et AmBev (Companhia de Bebidas das Americas), entreprise brésilienne et cinquième brasseur mondial, dont les origines remontent à 1885, s’associent pour créer DeBiere, le plus grand brasseur du monde en termes de volume. Cette année-là, le groupe DeBiere a vendu 202 millions d’hectolitres de bière et 31,5 millions d’hectolitres de soft drinks. Aujourd’hui, la stratégie de DeBiere consiste à renforcer ses plates-formes locales par l'établissement de positions solides sur les principaux marchés brassicoles du monde. La croissance organique, l'efficacité de classe mondiale, la croissance externe ciblée et la priorité donnée à ses consommateurs en sont les instruments.

Les facteurs de réussite d’un projet de migration de données dans SAP

Le groupe dispose désormais d’une plate-forme mondiale et de 14% de part de marché à travers le monde, grâce à un déploiement de ses activités dans plus de 30 pays sur le continent américain, en Europe et dans la zone Asie-Pacifique. DeBiere, classé n°1 ou n°2 dans plus de 20 marchés brassicoles clés à travers le monde entier, est ambitieux puisque aujourd’hui sa volonté est de passer du plus grand au meilleur brasseur mondial et pour cela une seule devise : « From Biggest to Best » (« Du plus Grand au Meilleur »).

1.3 Organisation

Nous n’insisterons pas sur l’organisation mais nous dirons simplement que les activités de DeBiere sont organisées en cinq zones géographiques : Amérique du Nord, Amérique latine, Europe de l’Ouest, Europe centrale et de l’Est et Asie-Pacifique. Chaque zone est dirigée par un président de zone qui siège également à l’Executive Board of Management (EBM). L’Executive Board of Management (EBM) est l’organe de gestion international de DeBiere. Cette équipe aux compétences très complémentaires donne à la société des aptitudes de leadership dans tous les aspects de son activité. Les membres de l’EBM sont issus d’AmBev et de l’ancienne Interbrew. L’EBM a joué un rôle décisif dans l’intégration du savoir-faire que chaque acteur a versé dans le nouveau modus operandi de DeBiere.

Nous venons de voir, que DeBiere, à travers toutes ses acquisitions a besoin, pour plus d’efficacité de consolider tous ses différents systèmes. Nous allons voir que cette entreprise ne cherche pas seulement à réunir tous ses différents systèmes par commodité mais que cela répond à une véritable ambition et une réelle vision.

1.4 Mission, Vision & Valeurs de DeBiere

Les facteurs de réussite d’un projet de migration de données dans SAP

Cette partie nous aidera à comprendre les véritables ambitions du groupe DeBiere.

1.4.1 Mission

Toujours plus forte, DeBiere a la volonté de développer des liens durables avec les consommateurs en leur proposant des marques ainsi que des expériences qui fédèrent et qui rassemblent. Au cœur de tout ce que DeBiere entreprend, le consommateur fait partie intégrante de l’activité de l’entreprise, qui, quotidiennement identifie les possibilités d’innovation pour y donner suite avec détermination.

1.4.2 Vision

Afin d’exploiter pleinement le potentiel de chaque brasserie, DeBiere prend conscience de la nécessité d’harmoniser l’ensemble de ses activités brassicoles, toutes zones confondues. Il fallait trancher entre l’autonomie et l’harmonisation. La Vision de DeBiere est de « Passer du Plus Grand au Meilleur - From Biggest to Best ! »

1.4.3 Valeurs

DeBiere veut être le meilleur au monde, le brasseur le plus rentable au monde et de ce fait son but à long terme est :

une croissance organique de ses volumes plus rapide que la moyenne du secteur,rentable au monde et de ce fait son but à long terme est : une croissance

une croissance du chiffre d'affaires devançant les volumes,de ses volumes plus rapide que la moyenne du secteur, s'assurer que les augmentations de coûts

s'assurer que les augmentations de coûts reste en dessous de l'inflation.croissance du chiffre d'affaires devançant les volumes, Devenir le meilleur est l’engagement de DeBiere et cela

Devenir le meilleur est l’engagement de DeBiere et cela représente un défi permanent. Il implique de fixer constamment de nouveaux objectifs pour bâtir une entreprise qui génère de la croissance et des résultats durables à long terme.

C’est dans ce contexte que s’inscrit le projet d’implémentation SAP qui doit aussi aider DeBiere à répondre à un autre défi : établir des liens durables avec les consommateurs en proposant des marques et des expériences qui rassemblent les gens.

Pour terminer sur la présentation générale nous en ferons un bref résumé en donnant quelques chiffres clés sur DeBiere et en montrant son positionnement face à ses concurrents directs.

Les facteurs de réussite d’un projet de migration de données dans SAP

Création : 2004 (fusion entre Interbrew et AmBev)Siège Social : Louvain, Belgique Secteur d’activités : Brasserie Chiffre d’affaires : 13,3 milliard €

Siège Social : Louvain, BelgiqueCréation : 2004 (fusion entre Interbrew et AmBev) Secteur d’activités : Brasserie Chiffre d’affaires : 13,3

Secteur d’activités : Brasserieentre Interbrew et AmBev) Siège Social : Louvain, Belgique Chiffre d’affaires : 13,3 milliard € (2006)

Chiffre d’affaires : 13,3 milliard € (2006): Louvain, Belgique Secteur d’activités : Brasserie Effectif : 88.000 Produits : Bière, lager 3 et

Effectif : 88.000: Brasserie Chiffre d’affaires : 13,3 milliard € (2006) Produits : Bière, lager 3 et soda

Produits : Bière, lager 3 et soda 3 et soda

Produits vedettes : Stella Artois®, Brahma®, Beck’s® et Leffe®.Effectif : 88.000 Produits : Bière, lager 3 et soda Personne-clé : Carlos Brito (CEO) Vente

Personne-clé : Carlos Brito (CEO)vedettes : Stella Artois®, Brahma®, Beck’s® et Leffe®. Vente / an : 246,5 millions hl /

Vente / an : 246,5 millions hl / anvedettes : Stella Artois®, Brahma®, Beck’s® et Leffe®. Personne-clé : Carlos Brito (CEO) Parts de marché

Parts de marché : 14%: Stella Artois®, Brahma®, Beck’s® et Leffe®. Personne-clé : Carlos Brito (CEO) Vente / an :

Tableau 1.1 : Quelques chiffres clés de DeBiere

La figure ci-dessous nous indique le positionnement de DeBiere sur le marché mondial (concurrents directs, part de marché)

DeBiere
DeBiere

Figure 1.2 - Classement des 5 premiers brasseurs mondiaux Part de Marché, 2005

A travers cette figure, nous voyons bien que DeBiere domine nettement ses concurrents avec 14%

de part de marché. L’objectif principal de cette entreprise, est certes d’être toujours le leader en

terme de volume mais aussi d’être le meilleur d’où sa vision « Passer du Plus Grand au Meilleur -

From Biggest to Best ! ».

1.5 Le projet OMEGA de DeBiere

3 On appelle lager l'ensemble des bières à fermentation basse.

Les facteurs de réussite d’un projet de migration de données dans SAP

La migration de données qui constitue la base de notre étude s’inscrit dans le cadre du projet d’implémentation OMEGA de DeBiere c’est pour cela que nous allons décrire, dans cette partie, ce projet OMEGA pour mieux comprendre le contexte dans lequel DeBiere a choisi d’implémenter un nouveau système d’information pour toutes ses filiales et par conséquent de migrer ses données vers ce système.

Omega est un projet d’implémentation pour l’Europe occidentale qui touchera par la suite chaque employé de DeBiere dans la zone europe. Le vrai objectif d'Omega est de changer fondamentalement la manière de DeBiere de faire des affaires. Les objectifs du programme OMEGA visent, principalement à donner à DeBiere un avantage concurrentiel (pouvoir répondre rapidement sur un marché concurrentiel et dynamique ; par exemple intégrer rapidement les nouvelles acquisitions), à réduire leur base de coût (ZBB - Zero Base Budgeting) car en ayant des manières communes de travailler, DeBiere veut réduire ses coûts de maintenance ; par exemple mettre en place un système commun à tous, et enfin à travailler dans la transparence (les meilleures entreprises au monde ont un KPI (Key Performance Indicator - Paramètre qui se veut le plus représentatif d'une activité de l'entreprise et qui permet d'évaluer la performance globale de cette dernière en fonction des objectifs à atteindre) transparent et relié, où chacun travaille dans un but commun).

Aujourd'hui DeBiere couvre, pour la partie Europe occidentale, 3 unités d'affaires : BeNeFraLux, GISE et UK&I. C'étaient des entreprises à l'origine indépendantes rassemblées par le programme d'acquisition d'Interbrew. Chacune possédant ses propres système d’information et processus.

L’équipe centrale (équipe core), dont je faisais partie était basée à Leuven, en Belgique, pour la phase de conception et la première implémentation. Ensuite nous avons été temporairement affectés dans les pays au fur et à mesure des implémentations, pour assister les équipes locales lors de la mise en production des données.

Le projet Omega est un investissement de 100 millions d’euros où travailleront plus de 100 personnes directement. C’est un projet qui devra durer 5 ans pour être complet comme le montre la figure ci-dessous :

Les facteurs de réussite d’un projet de migration de données dans SAP

Main Assumptions Criteria Tentative Deployment Roadmap • Progressive complexity to minimize risk (Small BU, Remote
Main Assumptions
Criteria
Tentative Deployment Roadmap
• Progressive complexity to minimize risk
(Small BU, Remote BU, large & remote BU,
complex BU, joint go-lives…),
• At least two months
between two go lives,
• No go-live during the season (one exception).
Implementation
UK
Implementation
Germany & ISE
Implementation
Luxembourg
Implementation
Implementation
Implementation
Belgium
Netherlands
France
Template
Phase
Implementation
Implementation
Implementation
Implementation
Russia
Serbia Montenegro
Croatia
Hungary
Implementation
Implementation
Implementation
Implementation
Ukraine
Romania
Czech Republic
Bulgaria
Sept 05
Jan 06
May 06
Sept 06
Jan 07
May 07
Sept 07
Jan 08
May 08
Sept 08
Jan 09
May 09
Sept 09
Jan 10
May 10
Business Season
Copyright © 2005 Accenture All Rights Reserved.

Tableau 1.2 : Planning de démarrage par pays

Ce planning a été mis à jour suite au report dans le démarrage de certains pays comme les deux pays pilotes qui nous ont servi pour cette étude, le Luxembourg et l’Ukraine.

Il y a plusieurs phases au programme d’implémentation. Pendant la phase de conception, en 2005, les processus et les systèmes principaux seront remodelés pour la zone Europe occidentale.

Ensuite de 2006 à la fin de 2010 cette conception sera mise en application pour toutes les unités de l'Europe occidentale, par une approche par étapes (phase d'exécution ou de déploiement)

L’enjeu pour la migration de données dans ce projet OMEGA est de taille car il s’agit d’assurer la reprise des données (extraction, transformation et chargement dans SAP) de 6 domaines fonctionnels dans un délai de 6 mois pour les 2 sites pilotes Luxembourg et Ukraine avec l’aide de l’intégrateur Accenture.

Le périmètre fonctionnel pour la reprise des données comprend les modules suivants de SAP :

finance (la gestion comptable et financière), commercial et logistique (l’administration des ventes,

Les facteurs de réussite d’un projet de migration de données dans SAP

la logistique, le transport, stocks.

),

la gestion des achats, la gestion de la production, la gestion des

Les domaines concernés par la migration chez DeBiere

Commercial

Finance

Supply Chain

Manufacturing

Procurement

Material Master

   

Migration

de données

   

Figure 1.3 : La migration de données intégrée aux processus métier

Ensuite le périmètre géographique pour la reprise des données concernera la maison mère (Belgique) ainsi que toutes les filiales de la zone Europe (France, Angleterre, Allemagne, Russie, ).

La typologie comportait des données statiques (référentiels clients et fournisseurs, données

comptables de référence données logistiques, etc

des données sources et leur extraction, Accenture assurant ensuite la transcodification et

l’intégration dans SAP.

et des données dynamiques (stocks, données comptables liées aux Dans l’organisation adoptée, DeBiere avait en charge la fiabilisation

)

).

Une première étape a consisté à définir pour chaque domaine fonctionnel, les données sources à migrer vers SAP puis, en fonction des données demandées par les processus SAP, les champs et les règles de transformation nécessaires. Ainsi, nous allons voir dans le prochain chapitre comment s’effectue la migration et quels sont les éléments importants lors d’une migration de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

2. Migrer des données

Les facteurs de réussite d’un projet de migration de données dans SAP

L’objet de notre étude étant la migration de données, il est nécessaire de s’entendre sur les terminologies de données et de migration. Nous essayerons dans ce chapitre de donner une définition du mot donnée et de migration avant de nous intéresser au contexte global de migration c’est-à-dire essayer de répondre à la question pourquoi migrer des données ?

2.1 Définitions

2.1.1 Qu’est-ce qu’une donnée ?

Une donnée est une information de nature numérique ou alphanumérique, représentée sous forme codée en vue d'y être enregistrée, traitée, conservée et communiquée et qui est exploitable par la machine.

Les données constituent une ressource cruciale pour l’entreprise, c’est un actif stratégique. Elles sont essentielles à toute implémentation car elles constituent la base de tout document. D’elles dépendent la qualité des prestations, la fluidité des process, la fiabilité des indicateurs. Elles constituent un facteur clef de la réussite du projet de système d’information. Autour des données plusieurs métiers et outils se sont développés : nettoyage de données (data cleaning), entrepôt de données (data warehousing), extraction de données (data mining), gestion des données maîtres (master data management).

2.1.2 Qu’est-ce qu’une migration de données ?

Dans “The Horrible World Of Data Migration” Tony Rodriguez définissait ainsi la Migration de Données :

La Migration de données est le processus complexe entrepris pour permettre à des données existantes d'être employées par une nouvelle application.

Une autre définition proche de celle de Tony Rodriguez : La migration de données désigne le processus de transfert de volumes (souvent très vastes) de données des systèmes existants des anciens systèmes vers de nouveaux systèmes. Les systèmes existants peuvent être très divers, depuis les infrastructures informatiques personnalisées jusqu'aux bases de données autonomes, en passant par les feuilles de calcul. En résumé nous dirons que la migration de données (souvent appelée reprise de données) consiste à transférer des données de sources disparates, à profiler, nettoyer, normaliser, transformer

Les facteurs de réussite d’un projet de migration de données dans SAP

(conversion) celles-ci afin qu’elles soient conformes aux normes de la nouvelle application. Le schéma ci-dessous nous donne une illustration pour mieux comprendre ce qu’est une migration de données :

mieux comprendre ce qu’est une migration de données : Figure 2.1 : Schéma du processus de

Figure 2.1 : Schéma du processus de reprise des données

2.2 Pourquoi migrer des données ?

Les facteurs de réussite d’un projet de migration de données dans SAP

DeBiere a migré ses données dans le cadre de son projet d’implémentation du progiciel SAP, qui avait pour but principalement d’harmoniser l’ensemble de ses activités brassicoles, toutes zones confondues et d’intégrer rapidement ses nouvelles acquisitions. Mais ce n’est pas dans le seul cas de fusion et acquisitions qu’on est amené à migrer des données. Il peut aussi s’agir d’un remplacement d’anciens systèmes devenus obsolètes afin d’acquérir un avantage concurrentiel, d’améliorer la compétitivité ou d’améliorer le service à la clientèle.

Le besoin toujours croissant de fournir de nouvelles fonctionnalités est constant et requiert souvent la mise en œuvre de nouvelles applications ou la mise à jour d'applications existantes.

Face à ces besoins, de nombreuses entreprises doivent migrer leurs données depuis leurs anciennes applications vers les nouvelles.

La migration de données s'avère être une opération incontournable à tout projet de mise en place d'applications métier et principalement sur des projets de gestion de la relation client. Le schéma ci-dessous permet d’illustrer des cas où on est amené à migrer des données.

des cas où on est amené à migrer des données. Figure 2.2 : Le contexte de

Figure 2.2 : Le contexte de la migration de données

Il est certes important de comprendre pourquoi on migre des données mais c’est encore mieux de réussir sa migration et le choix des outils est un élément qui participe à la réussite du projet de migration de données.

2.3 Produits & Marché

Les facteurs de réussite d’un projet de migration de données dans SAP

Nous avons voulu développer cette partie car pour migrer des données, il existe une panoplie d’outils et de solutions sur le marché et l’on n’arrive pas toujours à faire un choix adéquat or comme nous l’avons dit précédemment, il est important de bien choisir ses outils.

On appelle ces outils des ETL (Extraction Transfer Loading ou Extraction Transfert chargement).

Il s'agit d'une technologie informatique permettant d'effectuer des synchronisations massives

d'information d'une base de données vers une autre dont l’objectif est d’intégrer les données

nécessaires aux traitements. Selon le contexte, on traduira par « alimentation », « extraction », « transformation », « constitution » ou « conversion », ces termes étant souvent combinés.

A l'origine, les solutions d'ETL sont apparues pour le chargement régulier de données agrégées

dans les entrepôts de données (ou datawarehouse), avant de se diversifier vers les autres domaines logiciels. Ces solutions sont largement utilisées dans le monde bancaire et financier, ainsi que dans l'industrie.

Elle est fondée sur des connecteurs servant à exporter ou importer les données dans les

applications (Ex : connecteur Oracle ou SAP

(agrégations, filtres, conversions

l'intégration de l'entreprise par ses données. Des technologies complémentaires sont apparues par la suite : l'EAI (Intégration d'applications d'entreprise), puis l'ESB (Enterprise Service Bus).

des transformateurs qui manipulent les données

et des mises en correspondance (mappages). Le but est

),

),

Il existe également des solutions d'ETL de contenu permettant de manipuler des données non

structurées tels que les dossiers et les documents. Ces solutions sont utilisées pour des projets de migration de documents. Leur champ d'application peut également s'étendre à des projets d'archivage électronique. Par exemple, lors de migration de documents d'une application gestion électronique de données (GED) vers une autre. Schématiquement, cet intergiciel (middleware) commence par extraire les contenus stockés par les différents systèmes d'entreprise avant de les transmettre à la base de données de la plate-forme.

Les outils ETL présentés ici n’ont pas été utilisés lors de notre étude mais il nous a paru important

de

les lister car nous voulions tout simplement faire comprendre ici qu’ils existent. Il est possible

de

les utiliser dans le cadre d’une migration de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

Ci-dessous nous trouverons les outils existants sur le marché avec quelques descriptions et commentaires. Nous n’avons aucune recommandation particulière à faire pour les outils cités ci- dessous car nous n’avons pas pu les tester.

 

Extraction / consolidation de données

Editeur et Solution

Positionnement

Connexions natives

Business Object

Issue du rachat d'Acta, cette solution se propose de rendre accessible en "quasi-temps réel" les données les plus souvent accédées.

Acta était le fournisseur historique du premier connecteur à SAP. Partenaire notamment de Siebel, Peoplesoft et JDEdwards. Interfaçage avec Cognos, Hyperion, Actuate et Brio.

ActaWorks

 

Ascential Software DataStage XE

DataStage XE est l'offre traditionnelle d'Ardent qu'Informix a racheté début 2000 avant qu'Ascential ne la reprenne à son compte lors de sa prise d'indépendance, tandis qu'Informix partait chez IBM avec ses entrepôts de données.

Plus de 40 connecteurs natifs vers des sources de données, dont IBM/Informix, Oracle, Sybase, Teradata et IBM DB2. Package complet dédié à SAP et à la collection de modules MySAP. Partie analytique : Brio, Business Objects, SPSS et Crystal Decisions.

Computer

Computer Associates est plus connu pour ses offres de sécurité, de surveillance et de gestion d'infrastructures réseaux/informatiques. Mais son offre ETL s'avère assez complète y compris pour maintenir l'intégrité des métadonnées sur toute la chaîne de traitement. L'outil ETL s'appelle Vision : Pursuit.

Connecteurs en direct pour extraire les données en temps réel depuis SAP, PeopleSoft et des systèmes unité centrale (mainframe)s. Accès à de nombreuses sources de données dont IBM/Informix, Oracle, Sybase, IBM DB2, HTML et fichiers txt.

Associates

DecisionBase

Cognos

Ce n'est pas la spécialité de Cognos, mais l'outil semble s'être éprouvé dans le temps après avoir changé de nom.

Se dit compatible avec 100 sources OLAP, dont SAP BW (certifié), Hyperion, Informix, SQL Server 2000 et Sybase

DecisionStream

Data Mirror Transformation Server

Peu connu en France mais néanmoins présent, l'éditeur canadien propose à la fois une offre ETL pour extraire et transformer les données, un ensemble d'outils pour leur gestion, mais également une plate-forme EAI et un "hub" pour les échanges b-to-b.

Accès natif non ODBC vers Oracle, IBM DB2, Sybase, Microsoft SQL Server. Connecteurs externes vers les entrepôts OLAP propriétaires Hyperion, Cognos, Oracle.

Les facteurs de réussite d’un projet de migration de données dans SAP

   

Extraction standard depuis :

ETI

Parfois citée comme plate-forme ETL de référence par certains acteurs, mais pas ceux de la business intelligence, ETI.Extract fonctionne avec des librairies pour supporter les entrepôts de données et des plugins additionnels en prolongement d'applications précises.

fichiers plats (C et Cobol), Siebel, les SGBDR, Informix, Teradata, Oracle Financials, PeopleSoft HRMS, SAP R3 et BW Librairies pour toutes les bases de données ci-dessous, sauf Hyperion, sur systèmes anciens et plus récents. Plugins ETI.Accelerator pour Siebel, SQL/Teradata et les middleware

ETI.Extract

 

MQ (IBM, Tibco

).

Hummingbird Genio Suite 5

Surtout connu pour son offre de portail, Hummingbird fournit également une plate-forme ETL et EAI du nom de Genio Suite, assez réputée. En outre, une offre de business intelligence classique, BI/Suite prolonge le portail. Mais il n'est pas question de CRM analytique. Mais Genio Miner aggrège plus de 15 algorithmes de datamining différents.

Entrepôts de données : Oracle, Sybase, Teradata, Hyperion Essbase, MS SQL Server et IBM DB2. Prise en charge nouvelle des formats de données : XML, unité centrale (mainframe), SAP en natif, binaires, versions récentes des SGBDR. En EAI :

Siebel, SAP, support de MQ Series. Le roadmap prévoit l'intégration prochaine à des acteurs comme Brio, BO, Cognos et MicroStrategy.

L'une des plates-formes d'extraction / transformation de données les plus complètes et répandues. PowerCenter à l'échelle de l'entreprise, et PowerMart à celle du service ou du département. Informatica s'est récemment engagé sur le créneau des applications analytiques, mais l'offre ETL est indépendante.

Gamme extrêmement vaste de connecteurs spécifiques aux sources de données pour consolider tous les principaux entrepôts de données. Pour citer

Informatica

quelques acteurs du CRM analytique en vrac : Siebel, Business Objects, Oracle, Hyperion, Crystal Decisions, Brio, SAP, Cognos, Peoplesoft, Kana,

PowerCenter 5

Nuance, Microstrategy

ainsi que

les middleware MQ pour aller plus

 

loin.

Information Builders ETL Manager

Positionnement hybride entre la business intelligence, l'ETL et plus récemment l'EAI avec la création de sa filiale iWay Software. Les 2 dernières offres sont les plus complètes, la première se cantonnant essentiellement à du reporting sans véritable analyse approfondie.

A travers son outil ETL, I.B. attaque près de 80 sources de données. Les connecteurs EAI d'iWay concernent environ 120 applications selon l'éditeur.

Tableau 2.1 : Les principaux éditeurs d’ETL

Les facteurs de réussite d’un projet de migration de données dans SAP

2.4 La migration de données : un projet parallèle

Une migration est un sous-projet à part entière qui se gère comme tel. Il se mène en parallèle avec le projet de mise en œuvre. Il y a bien sûr des dépendances entre le planning de cette mise en œuvre et celui de la migration des données.

Migrer ne signifie surtout pas faire en sorte que la nouvelle application ressemble le plus possible à l’ancienne et en reprenne toutes les données dans leur moindre détail. Cela se payerait par l’explosion des coûts, la rigidité du résultat et en définitive l’insatisfaction des utilisateurs. Migrer, c’est au contraire s’adapter aux différences.

Dans un projet d’intégration de progiciel, la migration des données du système existant peut déterminer une grande partie du chemin critique. En particulier, les outils de migration peuvent représenter une partie significative des développements spécifiques.

La migration des données est aussi une activité délicate, dans laquelle il n’est pas possible de sauter les étapes. Or elle est souvent sous-estimée, tant par les maîtres d’ouvrage que par les intégrateurs. On doit effectuer les vérifications prévues au fur et à mesure des opérations de migration, puis à la fin, si celles-ci démontrent des problèmes majeurs, on revient en arrière et on fixe une nouvelle date pour la mise en production des données.

Le schéma ci-dessous montre les étapes importantes dans le cycle de conversion des données.

Les facteurs de réussite d’un projet de migration de données dans SAP

de réussite d’un projet de migration de données dans SAP Figure 2. 3 : Cycle de

Figure 2. 3 : Cycle de vie processus de conversion et reprise de données

1. Cette phase permet de détailler et de planifier toutes les opérations de préparation et d’exécution des bascules de données. Elle fixe les principaux choix techniques d’outils et d’architecture des reprises de données (description des structures de données entrée et sortie, description des tables de transcodification, découpage en traitements principaux et ordonnancement de ces traitements).

2. Cette phase permet de détailler champ par champ les règles et opérations de transcodification (règles détaillées de transcodification enregistrement /champs, description détaillée des tables de transcodification, )

Les données sources doivent être contrôlées et préparées pour être aptes aux reprises automatisées, les systèmes sources et cibles doivent comporter les environnements de test et simulation pour permettre le déroulement des bascules de test.

Les facteurs de réussite d’un projet de migration de données dans SAP

3. Cette phase a pour objet de réaliser et tester tous les composants logiciels des reprises et conversions de données.

Les développements doivent prendre en compte ces contraintes (performances, contrôles à effectuer, enchaînement des traitements, traitements d’écarts etc

4. Cette phase a pour objet de conduire la recette des programmes de reprise et de conversion en vérifiant leur intégrité dans SAP.

Pour garantir une mise en oeuvre fiable de la bascule de données, les tests de recette doivent s’effectuer dans le cadre de simulation de bascule de données qui, au delà de la vérification du bon fonctionnement du logiciel, permettent de vérifier la fiabilité des données et fournissent aux équipes des possibilités d’entraînement en vraie grandeur.

5. Cette phase a pour objet de réaliser l’intégration des reprises de données avec le logiciel SAP qui utilisera ces données. C’est un processus de reprise de données contrôlé dans son déroulement complet.

On appelle “ bascule des données résiduelles ” la reprise et conversion, après le démarrage, des données dont la présence sur le système cible n’est pas indispensable aux opérations quotidiennes.

Toutes ces étapes sont importantes et elles doivent être exécutées correctement. Pour chaque étape un responsable doit être identifié afin d’optimiser les ressources humaines du projet. Il est indispensable d’avoir une organisation humaine cohérente en phase avec les objectifs du projet.

2.4.1 Organisation

Dans le cas de la mise en place d’un ERP, la migration implique une collaboration entre l’équipe responsable du système remplacé, l’équipe de projet du nouveau système, c’est-à-dire l’intégrateur et les utilisateurs clés (key users ou responsable de domaine fonctionnel) du nouveau système.

Plus encore que la mise en œuvre d’un progiciel, la migration des données exige la participation d’utilisateurs qui connaissent bien l’existant pour l’analyse des données des applications existantes, les spécifications fines, l’amélioration de la qualité des données et enfin les contrôles post migration.

Les facteurs de réussite d’un projet de migration de données dans SAP

Ces utilisateurs ne sont pas toujours disponibles. Il faut donc que la composition des équipes et le rôle de chacun soient définis clairement, par écrit et le plus tôt possible. En considérant la figure 2.1 du schéma global du processus de reprise des données, nous pouvons y montrer comment les équipes peuvent s’y articuler avec le schéma ci-dessous :

peuvent s’y articuler avec le schéma ci-dessous : Figure 2.4 : Equipe de Migration des données

Figure 2.4 : Equipe de Migration des données intégrée au processus global de migration

L’équipe de reprise des données (généralement l’intégrateur surtout dans le cadre d’un projet ERP) a pour responsabilité le pilotage du chantier reprise (élaboration des grandes orientations / calendriers, arbitrages, en collaboration avec l’équipe projet), la coordination et supervision des travaux de reprise des données, le conseil, la production des fichiers, l’examen à posteriori des rapports d’erreurs produits à l’issue des chargements.

Le client a la charge de la préparation des données (listes de données à reprendre, collecte des informations nécessaires à la reprise, nettoyage des données, …), la saisie manuelle des données, le contrôle des données, l’exploitation systématique, à priori, des rapports de complétude, la correction de certaines données sur la base des rapports d’erreur retransmis et interprétés par l’équipe reprise. Le client via ses responsables de domaine fonctionnels valide les données chargées. Ils doivent dérouler des flux complets afin de s’assurer que les données migrées correspondent bien aux besoins de l’entreprise.

Les facteurs de réussite d’un projet de migration de données dans SAP

2.4.2 Stratégies de migration

La stratégie consiste surtout à choisir entre la migration globale (big bang) et la migration par

La stratégie et les contraintes de mise en oeuvre des

reprises de données dépendent de la stratégie de démarrage du projet. C’est de cette stratégie dont

dépendra l’ordonnancement des opérations de bascule. Selon la stratégie choisie, il y aura une incidence forte sur le projet.

étapes (démarrage par fonctions, par entités

).

La Stratégie « Big Bang » ou « Grand coup » permet des opérations manuelles sur les données et pendant le chargement et impose une validation parfaite en amont de la mise en production :

données et processus.

La stratégie « démarrage par lots » permet de découper le démarrage pour respecter les contraintes d’ouverture du système (par région, fonctionnalités, …).

La stratégie « démarrage progressif » permet d’ouvrir progressivement le système (ouvrir et fermer les vannes) et limite les impacts des erreurs sur le processus. Elle impose une évolution constante des outils, ainsi qu’une automatisation des principaux processus.

Pour la stratégie « fil de l’eau », les utilisateurs saisissent les données dans le nouveau système au fur et à mesure des activités métiers, il n’y a pas d’outil à développer mais cependant les temps de saisie sont importants et le risque d’erreurs est trop grand.

Les scénarios de reprise consistent à déterminer ce qu’on va migrer.

Schématiquement, il y a trois possibilités, on peut migrer seulement les données de base ou les données de base et les données variables qui correspondent à des événements non clos au moment de la migration. Par exemple, on migre les soldes et les factures non encore réglées mais pas les factures réglées ou enfin les données de base, les données variables et les historiques dans la limite d’une certaine durée, par exemple les deux derniers exercices comptables.

La première solution répond à une situation d’urgence. Elle suppose que l’on fasse vivre en parallèle l’ancien et le nouveau système jusqu’à l’épuisement naturel de l’ancien ou jusqu’à une autre migration plus complète. La seconde n’est pas entièrement satisfaisante puisqu’il faut continuer à utiliser l’application antérieure, en mode dégradé, pour accéder aux historiques. Des interfaces provisoires avec l’ancienne application permettent de pallier cet inconvénient.

Les facteurs de réussite d’un projet de migration de données dans SAP

Migrer tous les historiques n’est pas toujours possible. Pour transposer les événements passés dans un nouveau système il faut des conversions souvent très lourdes.

Bien entendu, des scénarios de reprise de données peuvent combiner différentes approches. Chaque scénario se concrétise par un calendrier précis.

2.4.3 Documentation

Les documents et les procédures constituent notre police d’assurance en cas d’incident dans un projet. Il s’avère donc indispensable de disposer d’une documentation précise sous forme de protocole de reprise des données afin d’y tracer les principaux éléments nécessaires pour la migration de données (scénario de reprise, risques, organisation, matériel,…) afin de prévenir les risques organisationnels et humains.

En dehors de ce protocole de reprise, il convient de documenter les données à reprendre par

domaine, les gabarits (fichiers de chargement, fichiers de correspondance,

pour les reprises (LSMW,

afin de minimiser les pertes de temps et d’argent en cas, par exemple, d’indisponibilité d’un membre de l’équipe.

les outils utilisés

Il convient aussi d’expliquer comment utiliser les outils de migration

),

).

Il est souvent nécessaire de compléter la documentation ou de la mettre à jour.

On s’attachera aussi à disposer particulièrement de documents décrivant les modèles de données logiques et physiques, la structure des bases de données, le contenu des tables, les volumes de données, les descriptions des données.

On s’assure aussi de disposer de la documentation des progiciels à installer, des principaux documents de spécification, en particulier les spécifications fonctionnelles et les modèles de données, de la documentation et des sources d’information sur les méthodologies de migration et les outils d’aide à la migration fournis par les éditeurs.

2.4.4 La qualité des données migrées

d’aide à la migration fournis par les éditeurs. 2.4.4 La qualité des données migrées MSIR Page

Les facteurs de réussite d’un projet de migration de données dans SAP

<< Un centre de radiographie d’un hôpital a envoyé à un bureau émetteur une facture impayée, qui me fut alors adressée. Mais quand je vérifiai mes factures, je constatai que ma compagnie d’assurance l’avait déjà réglée >>.

<< La banque qui m’a prêté de l’argent pour l’achat de ma dernière voiture m’envoya un courrier me signifiant que je n’avais pas satisfait une clause de l’assurance. Mon adresse ainsi que le modèle et l’année de ma voiture étaient mal libellés>>

Faits relatés par Thomas Redman dans son livre <<La qualité de données à l’âge de l’information>>

Ces deux faits relatés par Thomas Redman sont anodins mais bien représentatifs de l’impact des données de mauvaise qualité.

Manifestement il y a dans ces deux cas un enregistrement de données incorrectes. Une simple erreur peut être responsable de l’insatisfaction des clients, de la perte de revenus à court ou long terme.

Le défi le plus important auquel toutes les organisations ont à faire face est la qualité au sens plein du terme et particulièrement, en ce monde où l’informatisation s’accélère, la qualité des données devient le premier défi à résoudre.

Les données sont un actif critique de l'entreprise et à ce titre doivent faire l'objet d'un contrôle au niveau le plus haut de management. La maîtrise de la qualité des données requiert une maîtrise des chaînes de valeur de l'information, notamment au sein des grands processus métier. Ces compétences appartiennent, de manière naturelle, aux urbanistes des systèmes d'Information.

Ce sont les mieux placés pour définir et mettre en oeuvre la politique de gestion des données.

D'un point de vue organisationnel, il faut définir la chaîne de responsabilité de la qualité des données, le rôle et les objectifs de chacun, revoir les processus métier, identifier les points à risques pour la qualité des données, comme les points d'impact de la non qualité et définir les moyens à consacrer. Cela doit résulter de la définition d'une politique de gestion de la qualité des données, qui donnera lieu à des audits réguliers.

Les facteurs de réussite d’un projet de migration de données dans SAP

Du point de vue des systèmes d'information, l'établissement d'un dictionnaire des données publiques qui soit un catalogue des modèles, des types de données et des règles de capture et de contrôle est un fondement indispensable. Ce dictionnaire doit être fait avec les utilisateurs pour les utilisateurs et les informaticiens.

Il faut réhabiliter les fonctions de data manager (responsable de données), centraliser l'administration des données de référence et mettre en oeuvre des applications dédiées à la gestion des données qui, non seulement, stockent et distribuent les données, mais également exécutent les traitements qui appliquent les règles de contrôles.

La qualité des données doit faire l'objet d'un processus dédié qui ne repose pas uniquement sur des solutions techniques, mais aussi et surtout sur le savoir-faire des hommes, managers et experts du métier.

L'identification et le recensement des bases de données existantes dans l'entreprise et des informations qu'elles contiennent constituent aussi une étape importante. Or dans la plupart des entreprises, ces bases sont éparpillées dans diverses bases de données ou fichiers bureautiques. Il faut les répertorier mais aussi analyser la qualité des données, car la plupart d'entre elles peuvent s'avérer incomplètes, redondantes ou inexactes. Il faut éviter la reprise de données présentant un risque de "pollution".

Pour faire une analyse de la qualité des données il faut confronter ce qui est avec ce qui aurait dû être en recherchant les données partiellement ou totalement manquantes, les données non cohérentes ou erronées et les moyens de contrôle et de rectification (tables de référence).

Tout progiciel a sa propre logique interne. Il ne s’accommode pas nécessairement des lacunes et des erreurs dans les données que les applications qu’il remplace toléraient.

Des projets ont eu de réelles difficultés pour n’avoir pas voulu ou pas pu améliorer suffisamment la qualité des données.

On spécifie et on réalise les actions nécessaires pour compléter et corriger les données des applications à migrer. L’analyse de la correspondance des données constitue la principale étape d’analyse. Elle implique que les spécifications détaillées du nouveau système soient disponibles. On détaille les correspondances entre les données du nouveau système et celles des applications à migrer.

Les facteurs de réussite d’un projet de migration de données dans SAP

L’ordre d’introduction des données dans les tables n’est ni complètement imposé, ni indifférent. On identifie donc aussi les contraintes en ce qui concerne les séquences de chargement.

Le nettoyage de données (data cleansing) est une opération par laquelle on s'assure que les données d'un fichier sont cohérentes et qu'elles ont été saisies de manière à ce qu'elles soient identifiables, indexables de manière correcte par la suite. Ainsi, on veillera à uniformiser les différents formats de codes postaux utilisés en Europe pour permettre leur traitement homogène.

L'opération de nettoyage visera également à éliminer les doublons dans un fichier. Tout ceci sera mis en oeuvre pour mieux qualifier les données d'un fichier clients par exemple.

2.4.5 Choix et Spécification des outils

Cette étape consiste à choisir à la fois les outils généraux d’aide à la migration des données à mettre en oeuvre, les outils à réaliser spécifiquement ou à adapter et le niveau d’automatisation des opérations de migration à atteindre.

La réalisation des outils de migration des données le paramétrage, la modification, si nécessaire, et la qualification d’outils logiciels généraux ou préexistants et enfin la réalisation et la qualification d’outils logiciels spécifiques.

Les outils de migration de données sont destinés à servir une seule fois, mais massivement. Les conséquences des erreurs éventuelles seront difficiles à corriger après coup pour certaines données. La vérification de ces outils est donc particulièrement importante. Des outils fonctionnellement satisfaisants mais peu performants peuvent provoquer des durées de traitement rédhibitoires.

2.4.6 Préparation de la mise en œuvre

La préparation implique des procédures et des dispositions de sécurité, notamment la prise systématique de sauvegardes. II faut préparer le déroulement de la migration des données jusqu’en production, en passant par les bascules à blanc, faire les vérifications et enfin gérer les retours en arrière éventuels, en cas d’incident majeur.

2.5 Les facteurs de risque d'un projet de Migration de données

Les facteurs de réussite d’un projet de migration de données dans SAP

Beaucoup de projets se trouvent retardés ou bloqués du fait d'une mauvaise évaluation prévisionnelle de la charge de travail que représente la reprise et l'intégration des données.

La migration de données est souvent une opération coûteuse et risquée car l’accès aux données issues de vieux systèmes et de systèmes existants, ainsi que leur compréhension requiert souvent des compétences spécifiques, les systèmes en place sont souvent mal documentés, la migration de plusieurs systèmes implique de résoudre des problèmes de redondance et d’incohérence des données et enfin la conception itérative (expérience-apprentissage) aboutit à des situations ingérables et à des délais incompressibles liés à l’écriture manuelle des lignes de code.

Pour avoir une sécurité à peu près totale, il faut utiliser en parallèle l’ancien et le nouveau système pendant une courte période.

Ceci suppose cependant un double travail de la part des utilisateurs et de certains informaticiens, ce qui est très difficile à organiser en pratique. Deux circonstances peuvent rendre incontournable cette option c’est lorsque le traitement est essentiel à la vie de l’entreprise et si et on connaît imparfaitement les fonctions et les données des applications qui vont être remplacées.

Pour réduire les risques, il faut éviter les manipulations manuelles et utiliser les méthodes et outils standards autant que possible et améliorer la qualité des données (normalisation des adresses, suppression des doublons, identification et correction des données endommagées, suppression des données inutilisées).

Il faut aussi opérer une migration transparente (respecter le planning du projet, perturber le moins possible les actions utilisateurs (continuité de service), refléter les données source le plus finement possible et permettre de tirer parti au mieux des fonctionnalités du nouveau système) et réduire le volume de données à transférer (archiver sur microfilms, utiliser les anciens systèmes pour les données d’historiques).

Nous avons vu qu’il existe plusieurs cas de migrations, cependant notre étude s’est basée sur la migration de données des applications DeBiere vers SAP R/3. Pour mieux comprendre le processus de migration, nous allons présenter la technologie SAP R/3 avant de voir, comment la migration de données s’y opère.

3. Présentation de SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

Dans ce chapitre sera présentée la technologie sur laquelle j'ai travaillé tout au long du projet DeBiere : SAP R/3. Je commence par une présentation générale, puis je fais un peu d'historique afin de bien comprendre les évolutions et les raisons du succès de ce progiciel. Ensuite, j'explique l'architecture sur laquelle est basée le progiciel avant de parler des principes de la base de données chez SAP. L’intérêt de ce chapitre s’explique par le fait qu’il s’agit du système cible, base de notre étude. Pour comprendre le concept général de SAP, il est nécessaire de comprendre son architecture et surtout les principes de la base de données puisqu’elle en est le pilier central.

La représentation ci-dessous de tous les modules R/3, reliés les uns aux autres dans le système SAP R/3 est connue sous le nom de modèle d’intégration de R/3.

est connue sous le nom de modèle d’intégration de R/3. Figure 3.1 : Modèle d’intégration de

Figure 3.1 : Modèle d’intégration de R/3

SD : Sales and Disribution (administration des ventes)

MM : Material Management (Gestion des articles)

PP : Production Planning (Gestion de la production

QM : Quality Management (gestion de la qualité)

PM : Plant maintenance (gestion de la maintenance) CO : Costing (comptabilité analytique) PS : Project Systems (gestion de projet) FI : Finance IM : Gestion des Investissements financiers HR : Human Resources (Ressources humaines)

3.1 Présentation générale de l’entreprise SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

SAP est le nom d’une société allemande qui édite un logiciel phare de gestion intégré (progiciel) appelé R/3 (devenu mySAP ERP en 2003). SAP signifie Systeme, Anwendungen, Produkte in der Datenverarbeitung (Système, Applications, Produits de Gestion de Données). C’est le premier fournisseur mondial de logiciels inter-entreprises, avec 12 millions d'utilisateurs et plus de 100 000 installations et 1 500 partenaires. SAP est aussi le troisième fournisseur mondial de logiciels.

Etablie à Walldorf, Allemagne, SAP est cotée sur plusieurs marchés financiers, notamment aux bourses de Francfort et de New York, sous le symbole "SAP". La gamme SAP, constituée de produits et services, va de l’organisation des Finances et des Ressources humaines à la fabrication, la Vente et la Distribution. Aujourd'hui, SAP emploie plus de 42.000 personnes dans plus de 50 pays.

SAP possède aujourd’hui une multitude de solutions dans tous les domaines de notre société. Chaque entreprise peut, à partir de cette solution de base, étendre le logiciel selon ses besoins spécifiques :

base, étendre le logiciel selon ses besoins spécifiques : Figure 3.2 : Solutions complètes d'industrie 3.2

Figure 3.2 : Solutions complètes d'industrie

3.2 Historique

Les facteurs de réussite d’un projet de migration de données dans SAP

Le 1er avril 1972, cinq anciens employés d’IBM fondent SAP pour Systemanalyse und Programmentwicklung (“Systems Analysis and Program Development), à Mannheim en Allemagne. Leur objectif était de développer et lancer sur le marché un logiciel d’entreprise standard qui intégrerait tous les processus métiers. L’idée leur est venue suite à leurs travaux de consultants systèmes pour IBM, lorsqu’ils ont noté que leurs clients développaient tous des programmes machine sensiblement identiques. La seconde partie de leur objectif était que les données soient traitées de façon interactive et en temps réel. L’écran d’ordinateur deviendrait ainsi le point focal de la gestion des données d’entreprise.

En vingt-cinq ans, ils ont fait d’une petite entreprise régionale, une compagnie internationale de classe mondiale. Aujourd’hui, le groupe SAP est le leader incontestable sur le marché des progiciels de gestion possédant des filiales et des succursales dans presque chacune des nations industrielles de ce monde. En 1977 SAP passe au statut de GmbH (SARL). SAP est leader sur son marché, en témoigne le tableau ci-dessous qui nous montre ses parts de marché :

le tableau ci-dessous qui nous montre ses parts de marché : Tableau 3.1 : Part de

Tableau 3.1 : Part de marché en 2005 des éditeurs d’ERP en France (Source PAC)

Pour mieux comprendre le développement de SAP depuis sa création, nous avons résumé les événements clés sous forme de tableau ci-dessous plutôt qu’un long discours :

Les facteurs de réussite d’un projet de migration de données dans SAP

de réussite d’un projet de migration de données dans SAP Tableau 3.2 : Les dates clés
de réussite d’un projet de migration de données dans SAP Tableau 3.2 : Les dates clés
de réussite d’un projet de migration de données dans SAP Tableau 3.2 : Les dates clés

Tableau 3.2 : Les dates clés du développement de SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

Il existe plusieurs solutions qui sont développées et qui se déclinent selon les spécificités sectorielles de plus de 25 secteurs d’activité. Elles s’appuient sur la plate-forme technologique et d’intégration SAP NetWeaver™.

Pour finir cette partie concernant la présentation générale de l’entreprise, nous avons fait un bref résumé pour avoir un aperçu global de l’entreprise SAP :

Création : 1972Siège Social : Walldorf, Allemagne Secteur d’activités : Informatique, Progiciel Chiffre d’affaires : ~9,5 milliards

Siège Social : Walldorf, AllemagneCréation : 1972 Secteur d’activités : Informatique, Progiciel Chiffre d’affaires : ~9,5 milliards € (2006)

Secteur d’activités : Informatique, ProgicielCréation : 1972 Siège Social : Walldorf, Allemagne Chiffre d’affaires : ~9,5 milliards € (2006) Effectif

Chiffre d’affaires : ~9,5 milliards € (2006)Allemagne Secteur d’activités : Informatique, Progiciel Effectif : ~42.000 dans + de 50 pays Produit phare

Effectif : ~42.000 dans + de 50 paysProgiciel Chiffre d’affaires : ~9,5 milliards € (2006) Produit phare : SAP R/3 (rebaptisé SAP ERP

Produit phare : SAP R/3 (rebaptisé SAP ERP depuis 2007)milliards € (2006) Effectif : ~42.000 dans + de 50 pays Produits : SAP ERP, SAP

Produits : SAP ERP, SAP Business Suite, SAP NetWeaver, SAP Business One, SAP All-In- One, SAP AS1Produit phare : SAP R/3 (rebaptisé SAP ERP depuis 2007) Nombre d’installations : ~121.000 Personne-clé :

Nombre d’installations : ~121.000SAP NetWeaver, SAP Business One, SAP All-In- One, SAP AS1 Personne-clé : Henning Kagermann (CEO) Nombre

Personne-clé : Henning Kagermann (CEO)SAP All-In- One, SAP AS1 Nombre d’installations : ~121.000 Nombre clients : ~41.000 clients dans 120

Nombre clients : ~41.000 clients dans 120 paysOne, SAP AS1 Nombre d’installations : ~121.000 Personne-clé : Henning Kagermann (CEO) Parts de marché :

Parts de marché : 43% (en 2005)Nombre d’installations : ~121.000 Personne-clé : Henning Kagermann (CEO) Nombre clients : ~41.000 clients dans 120

Tableau 3.3 : Quelques chiffres clés de SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

3.3 Présentation de SAP R/3

3.3.1 Vue Fonctionnelle

R/3 est un progiciel destiné à optimiser les processus de gestion d’une entreprise. II est composé d’applications standard et couvre trois grands domaines : la Finance, la Logistique et la Gestion du Personnel. Pour chacun d’entre eux, R/3 offre des fonctionnalités complètes qui permettent à l’entreprise de reproduire l’ensemble des flux de valeurs et de marchandises.

Le système R/3 bénéficie d’une technologie parmi les plus avancées. Conçu de manière globale, il permet une mise en oeuvre modulaire et progressive. Sa souplesse l’amène à s’adapter aux besoins spécifiques de chaque entreprise.

On peut distinguer dans SAP, 3 familles de modules fonctionnels : la logistique, la finance et les ressources humaines :

Logistique: la logistique, la finance et les ressources humaines : Module MM (Material Management) Le module

Module MM (Material Management)

Le module MM concerne la gestion des articles d’un point de vue achats et gestion des stocks Module PP (Production Planning)

Le module PP concerne la gestion de la Production. Module SD (Sales and Distribution)

Le module SD concerne l’administration des ventes. Autres modules (QM Gestion de la qualité, PM Gestion de la maintenance)

Finance( QM Gestion de la qualité, PM Gestion de la maintenance) Module FI (FinanciaI) Le module

Module FI (FinanciaI)

Le module FI contient toutes les écritures des ventes et achats, lesquelles se déversent dans la comptabilité générale via la comptabilité client ou fournisseur. Module CO (Costing)

Le module CO concerne la comptabilité analytique. Module PS (Project Systems) Le module PS concerne la gestion des projets.

Les facteurs de réussite d’un projet de migration de données dans SAP

Autres modules (TR : Trésorerie, Gestion financière (gestion des flux de trésorerie, gestion des paiements) / IM : Gestion des Investissements financiers))

paiements) / IM : Gestion des Investissements financiers)) Ressources Humaines Module HR (Human Resources) ( Données

Ressources Humaines

Module HR (Human Resources) (Données de base personnelles, Suivi du temps de travail, Suivi des carrières, Suivi des frais de déplacement, Gestion de la paie)

3.3.2 Vue Organisationnelle

L’entreprise peut avoir comme activités la gestion des achats, l’administration des ventes, la gestion des stocks, la gestion de la production, la comptabilité analytique.

Les principales unités structurelles SAP sont le mandant, la société, l’organisation commerciale, l’organisation d’achat et la division comme le montre la figure ci-dessous :

et la division comme le montre la figure ci-dessous : Figure 3.3 : Principales unités structurelles

Figure 3.3 : Principales unités structurelles SAP Représentation d’une entreprise dans SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

Le mandant est un regroupement d’unités légales, structurelles, commerciales et/ou administratives avec un objectif commun. Il représente un groupe international avec une gestion de bilan consolidé. Sur une même machine, chaque mandant est autonome et identifié par un numéro et chaque mandant possède son propre plan comptable.

La base de données est inter-mandants, mais les données dépendent du mandant et aussi chaque mandant possède son propre paramétrage (customizing). Les programmes sont inter-mandants.

La société représente une entité, au sein du mandant, disposant de son propre bilan et crée son propre compte de résultat. C’est le niveau de la gestion “comptable” des flux financiers de l’entreprise. Exemple : une société, une filiale.

Elle est liée à un mandant et les données sont mémorisées par société. Les plans comptables, les types de documents, les clés de comptabilisation, les codes mouvement sont communs à toutes les sociétés d’un même mandant

L’organisation commerciale (ou des ventes) représente une unité structurelle responsable de la négociation et des ventes de biens et services.

L’organisation d’achats représente une unité structurelle responsable de la négociation et de l’approvisionnement des biens et services pour une ou plusieurs divisions.

La division représente, au sein d’une société, une Business Unit c’est-à-dire un site opérationnel, sans comptabilité propre qui peut être valorisée ou non. Exemple : site, établissement, succursale, un domaine de comptabilisation, unité logistique. C’est le niveau de gestion.

Le magasin représente, au sein d’une division, un regroupement d’articles qui suivent des «règles communes» qui peuvent prendre en compte les notions de site, emplacement, nature (produits

comptabilisation, ligne de produit, propriété, et dont les entrées et les

sorties génèrent des écritures comptables. C’est le niveau de gestion physique des stocks.

finis, matières premières,

),

Les facteurs de réussite d’un projet de migration de données dans SAP

3.4 Architecture du système SAP R/3

Il est intéressant de connaître l’architecture du système SAP R/3 pour savoir si c’est une architecture ouverte qui permet l’intégration facile de produits complémentaires tels que des applications Internet ou s’il s’interface avec d’autres outils de migration de données.

R/3 signifie Runtime System Three. Il est constitué d’un ensemble d’applications métiers conçues pour un environnement client/serveur. R/3 a été développé à partir du système SAP original R/2 qui était fondé sur une unité centrale. L’architecture de R/3 permet la répartition de la charge de traitement (présentation, logique de l’application et gestion des données) entre plusieurs ordinateurs reliés entre eux par un réseau (voir Figure 1.1).

Serveur de base de données Serveur d’application Système de présentation
Serveur de base
de données
Serveur
d’application
Système de présentation

Figure 3.4 L’architecture du système SAP R/3 comprend des serveurs de bases de données, des serveurs d’applications et des systèmes de présentation.

Les facteurs de réussite d’un projet de migration de données dans SAP

3.4.1 Environnement client/serveur

Le concept de l’environnement client/serveur est devenu très commun, c’est actuellement un standard dans la mise en place de tout type d’architecture de communication informatique. Dans un environnement client/serveur, le client (un ordinateur individuel ou une station de travail) demande une information (grâce à une connexion) à la machine émettrice, appelée serveur. La communication et l’échange de données entre les machines est appelée relation client/serveur.

entre les machines est appelée relation client/serveur. Stations de travail Imprimante laser Serveur de base de
Stations de travail Imprimante laser Serveur de base de données Porte de communication Serveur de
Stations de travail
Imprimante laser
Serveur de base
de données
Porte de communication
Serveur de fichiers
Serveur d’application
Stations de travail distantes éloignées
d’application Stations de travail distantes éloignées Figure 3.5 : Une architecture standard client/serveur relie
d’application Stations de travail distantes éloignées Figure 3.5 : Une architecture standard client/serveur relie

Figure 3.5 : Une architecture standard client/serveur relie les stations de travail au serveur Dans le système SAP, le client est aussi appelé mandant

Dans cet exemple, un ordinateur central contient la base de données, c’est le serveur base de données. La base de données est l’endroit où les données sont stockées. Le serveur d’applications est chargé des fonctions administratives du système. Cela inclut les processus d’arrière-plan, l’impression (requêtes spool) et le processus de gestion des requêtes. Les serveurs à applications multiples existent également dans cette version de SAP.

Les facteurs de réussite d’un projet de migration de données dans SAP

3.4.2 La hiérarchie à trois niveaux

L’architecture du système SAP R/3 est une hiérarchie à 3 niveaux : une architecture client/serveur dans laquelle la structure des systèmes de logiciels est répartie sur 3 niveaux : le niveau interface de l’utilisateur, le niveau de logique métier, le niveau de la base de données comme le montre la figure ci-dessous :

la base de données comme le montre la figure ci-dessous : Figure 3.6 : L’architecture à

Figure 3.6 : L’architecture à 3 niveaux est devenue le concept architectural standard des installations SAP R/3

La capacité d’intégration de SAP est un des éléments clés qui lui permettent de se différencier des autres applications d’entreprise. Cette intégration offre un environnement métier fondé sur la connexion, qui s’étend du domaine des Finances et des Ressources Humaines à la Fabrication et à la Distribution.

Dans SAP intégration signifie que tous les processus métiers de l’entreprise sont apparents et reliés les uns aux autres, de sorte qu’une modification dans un domaine se répercutera sur les autres domaines. A titre d’exemple, les calculs de disponibilités du module Ressources humaines peuvent être liés aux comptes du Grand Livre, dans le module Finances.

Une transaction SAP R/3 est un processus logique interne au système R/3, c’est-à-dire une unité au contenu explicite. Créer un nouveau client, générer une liste des clients déjà existants, effectuer un ordre ou exécuter un programme, sont des exemples de transactions.

Les facteurs de réussite d’un projet de migration de données dans SAP

Le SGBDR (Système de Gestion de Base de Données Relationnelle) est stocké sur une seule machine physique. C’est à ce niveau que s’effectue la gestion du dictionnaire physique de données, c’est-à-dire l’accès aux données, la mise à jour physique de celles-ci et leur validation. Pendant une transaction, les données sont stockées dans un tampon (buffer) et c’est seulement en fin de transaction que la mise à jour physique est effectuée. On dit alors que la validation des données s’effectue par blocs.

3.4.3 Interfaçage avec les systèmes extérieurs

SAP s’interface facilement avec d’autres systèmes externes par le biais de techniques que nous développerons ci-dessous :

le biais de techniques que nous développerons ci-dessous : Figure 3.7 : SAP s’interface avec plusieurs

Figure 3.7 : SAP s’interface avec plusieurs systèmes

Interfaçage CPIC (Commun Programming Interface Communication) est un protocole de communication qui permet l’envoi de messages ou de données en synchrone sur un autre système. L’ensemble des instructions du protocole peut être utilisé dans un programme ABAP (Advanced Business Application Programming (processeur générique pour la préparation de rapport).

Les facteurs de réussite d’un projet de migration de données dans SAP

Interfaçage RFC (Remote Function Call) : ce sont des fonctions SAP que l’on peut appeler en temps réel depuis un système distant (SAP ou autre) permettant de réaliser des interfaces synchrone. Exemples d’applications : SAP/Internet, SAP/Lotus Notes, SAP/SAP, etc. Interfaçage BAPIs (Business Application Programming Interface) qui est une fonction standard SAP orientée objet qui gère un objet de gestion SAP avec ses méthodes. Par exemple un BAPI de gestion de demande d’achat (DA) avec des méthodes de création, modification et affichage de la DA. Les BAPIs sont des fonctions RFC appelées en temps réel par des systèmes externes.

Interfaçage OLE (Object Link and Embedding) permet de piloter des documents MS-OFFICE

(Word, Excel,

).

Interfaçage I-DOCs (Intermediate DOCument) : l’interface IDOC est utilisée pour des

communications de données électroniques entre différents systèmes. On met ainsi un processus

transactionnel (commande, facture, au système distant via EDI ou ALE.

) sous forme d’un message électronique. L’IDOC est envoyé

EDI (Electronic Data Interchange) : c’est un change de messages électroniques entre SAP et des systèmes externes nécessitant un sous-système EDI traduisant le message IDOC en message EDIFACT.

ALE (Application Link Enabling) : Echange de données de base (fiches articles, comptes

généraux,

),

de données applicatives (commandes,

)

entre systèmes SAP.

Interfaçage Batch-Input : dans SAP R/3, il n’est pas possible de faire des créations et des mises à jour directement sur la base de données. Pour intégrer en masse des données transactionnelles, on utilise donc le batch-input qui permet de faire des reprises de données depuis un ancien système.

Interfaçage Extraction : l’extraction des données dans SAP est tout simplement la création d’un fichier plat unix contenant des données extraites du système.

Les facteurs de réussite d’un projet de migration de données dans SAP

3.5 Principes de la base de données chez SAP

Pour comprendre le concept général de SAP, il est nécessaire de comprendre les principes de la base de données SAP, puisqu’elle en est le pilier central.

3.5.1 Base de données

Une base de données est un conteneur qui peut stocker, organiser, extraire et présenter des informations. Une base de données est essentiellement un système de classement électronique qui peut contenir une grande quantité d’informations organisées. Par ailleurs, la base de données simplifie et accélère la performance d’un programme informatique durant la sélection de données.

Une base de données est composée de tables, de colonnes (appelées champs) et de lignes (appelées enregistrements ou données). La base de données joue un rôle essentiel dans le système SAP R/3. Elle se trouve dans un ordinateur central et contient toutes les données utilisées par le système SAP R/3. SAP peut utiliser des bases de données de différents éditeurs comme supports pour le système.

3.5.2 Structure d’une base de données

Les structures de la base de données sont des groupes de champs internes imbriqués. Les structures sont activées et définies dans le dictionnaire de données ABAP/4 (langage de programmation propriétaire, faisant partie de l'ensemble logiciel SAP - 4 pour quatrième génération); elles ne contiennent que des données temporaires, et ce, uniquement pendant la durée d’exécution d’un programme.

Pour différencier les structures des tables de la base de données, il faut considérer trois critères :

la base de données, il faut considérer trois critères : une structure ne contient pas de

une structure ne contient pas de table associée au dictionnaire de données ABAP/4, une structure ne contient pas de clef primaire, une structure n’a pas de propriétés techniques telles que classe, taille, catégorie ou spécification de fonction tampon.

techniques telles que classe, taille, catégorie ou spécification de fonction tampon. MSIR Page 51/125 2005-2007
techniques telles que classe, taille, catégorie ou spécification de fonction tampon. MSIR Page 51/125 2005-2007

Les facteurs de réussite d’un projet de migration de données dans SAP

3.5.3 Système de gestion des bases de données relationnel (SGDBR)

La base de données de SAP comprend plus de 12.000 tables stockant les informations. Ces tables sont connectées les unes aux autres par des relations.

Cette connexion de différentes tables par des relations est connue sous le nom de Système de gestion des bases de données relationnel (SGBDR).

Un système de base de données qui stocke des informations ainsi que des relations entre les données dans les tables à deux dimensions est appelé Système de gestion des bases de données relationnel (SGBDR). Un des avantages du concept du SGBDR est l’élimination des redondances.

Pour résumer nous dirons que le système SAP R/3 est fondé sur un système de gestion des bases de données relationnel (SGBDR). La base de données sert de noyau à tous les systèmes et modules

R/3.

3.5.4 Bases de données supportées par SAP

SAP supporte la plupart des bases de données : Microsoft SQL Server, DB2/CS, DB2/400, Informix, Oracle, Dynamic server, DB2/UDB.

3.5.5 Métadonnées

Il nous a paru intéressant de parler très rapidement des métadonnées car ce sont des données qui renseignent sur la nature de certaines autres données et qui permettent ainsi leur utilisation pertinente. Grâce à elles on peut aussi faire communiquer les bases de données classiques, utilisées dans les progiciels de gestion intégrés comme SAP et les données non structurées (documents, images, manipulés en gestion des connaissances

Dans SAP, les métadonnées sont définies comme des descriptions des structures de données utilisées dans les programmes. Les métadonnées recouvrent ainsi notamment les définitions de tables et de zones, ainsi que les définitions des domaines de valeurs acceptables pour chaque zone. Les relations entre les tables sont enregistrées à l’aide de tables de clés externes, qui constituent des métadonnées du dictionnaire de données actif ABAP/4.

Les facteurs de réussite d’un projet de migration de données dans SAP

de réussite d’un projet de migration de données dans SAP Figure 3.8 : Types de données

Figure 3.8 : Types de données SAP

Les métadonnées sont le plus souvent décrites comme des données « au service des autres données ». Elles sont stockées et définies dans un entrepôt de données central, d'où elles sont accessibles pour tous. Elles sont indépendantes des applications.

Les métadonnées décrivent, entre autres :

la définition du contenu (par exemple qu’est ce qu’une vente nette)applications. Les métadonnées décrivent, entre autres : quels éléments d'informations définissent des

quels éléments d'informations définissent des donnéesdu contenu (par exemple qu’est ce qu’une vente nette) niveau de périodicité et d'agrégation de collecte

niveau de périodicité et d'agrégation de collecte de données (par exemple mensuellement)éléments d'informations définissent des données comment et où trouver les données (par exemple systèmes

comment et où trouver les données (par exemple systèmes ERP dans les pays)de collecte de données (par exemple mensuellement) autorisation (qui est permis de voir les données, les

autorisation (qui est permis de voir les données, les manipulations sur ces donnéesles données (par exemple systèmes ERP dans les pays) ), 3.5.6 Le modèle de données d’entreprise

),

3.5.6 Le modèle de données d’entreprise SAP

Le modèle est élaboré à partir d’unités entités-association désignant des objets rééls de la vie commerciale, tels que des documents, des messages, des articles ou du personnel. Le terme “association” fait ici référence à des notions telles que celles de possession ou d’appartenance. Une commande comporte par exemple, quand elle est complète, un entête ou plusieurs postes spécifiant les éléments commandés et leurs prix.

Les facteurs de réussite d’un projet de migration de données dans SAP

Une association peut dans ce cas être décrite de la manière suivante : un poste d’une commande appartient à la commande et un en-tête de commande possède un ou plusieurs postes.

Quand une commande est affichée à l’écran et que l’opérateur actionne la touche F1, il obtient la signification commerciale donnée par le système à l’élément sélectionné par le curseur. Cette information est directement dérivée du modèle de données d’entreprise. L’utilisateur peut choisir la manière dont le modèle de données d’entreprise va lui être présenté.

Tous les éléments de données utilisés pour élaborer les vues et les tables virtuelles sont tirés du dictionnaire de données ABAP/4, l’utilisateur est assuré de la cohérence des données et de leur formatage.

Tous ces éléments seront indispensables lorsque nous aborderons la migration de données dans SAP au chapitre suivant.

4. La Migration de données dans SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

Dans cette partie, on distinguera deux types de migrations de données : d’abord la migration de données d’un système SAP en l’occurrence SAP R/2 vers SAP R/3 puis celle d’un système non SAP vers SAP R/3. Nous n’insisterons pas sur les produits existants sur le marché qui peuvent être interfacés avec SAP pour aider à la migration des données mais nous parlerons plutôt des outils SAP disponibles pour migrer les données. Nous avons complété le schéma global de la migration de données (figure 2.4) : la cible devenant SAP (voir figure ci-dessous) :

2.4) : la cible devenant SAP (voir figure ci-dessous) : Figure 4.1 : La migration de

Figure 4.1 : La migration de données dans SAP

Les facteurs de réussite d’un projet de migration de données dans SAP

4.1 La Migration de données de SAP R/2 vers SAP R/3

Nous traiterons ici plus particulièrement les cas où les installations existantes sont des systèmes SAP nécessitant des améliorations, soit par transfert sur une autre configuration de matériel, soit par acquisition de nouvelles versions du progiciel SAP.

soit par acquisition de nouvelles versions du progiciel SAP. Datenmigration Migration de Données Figure 4.2 :
Datenmigration Migration de Données
Datenmigration
Migration de Données
du progiciel SAP. Datenmigration Migration de Données Figure 4.2 : Comment migrer les données de R/2

Figure 4.2 : Comment migrer les données de R/2 vers R/3 ?

Le système SAP R/2 a été développé dans le contexte des architectures unité centrale (mainframe), qui étaient intégrées avec des systèmes de serveurs dédiés à des tâches spécifiques telles que la gestion de bases de données alors que le système SAP R/3 a été au contraire conçu dans l’optique d’une architecture hétérogène formée de multiples couches de configurations client-serveur.

Quand les entreprises s’équipent de nouveaux composants de matériel ou logiciels, ou quand elles entreprennent une ré-ingénierie de leurs processus commerciaux, les sociétés veulent en général pouvoir continuer à exploiter les informations commerciales qu’elles ont archivées ainsi que les données des transactions les plus récentes. L’objectif est alors de transférer des données et éventuellement des fonctions commerciales personnalisées vers le nouveau système SAP R/3 ou le nouveau module applicatif qui vient d’être installé.

Le processus de migration de données mis en oeuvre lors d’une implémentation du système SAP R/3 mérite de faire l’objet d’un plan de projet. Les principales étapes sont la familiarisation du personnel avec le système SAP R/3, la définition de la stratégie de migration des données, la mise au point d’un projet formel d’implémentation du système SAP R/3 dans lequel est incluse la phase de migration des données, le re-travail des fonctions et processus existant sous SAP R/2, de sorte qu’ils puissent exploiter les améliorations apportées à SAP R/3, la personnalisation complète

Les facteurs de réussite d’un projet de migration de données dans SAP

du prototype cible du système SAP R/3, la mise en place des mécanismes qui permettront des transferts de fichiers à haut débit entre le système unité centrale (mainframe) SAP R/2 et le système SAP R/3 (par exemple par le protocole FTP), la mise en oeuvre de tests de migration des données et vérification des transferts, la mise en oeuvre de tests de volume à grande échelle pour la conversion des données, la planification et l’optimisation du calendrier d’arrêt du système productif et de transfert des données et enfin la mise en service du système SAP R/3.

Le système SAP R/3 manipule des objets de données structurés de plus ou moins complexes. Ces objets sont accessibles sous la forme d’entités uniques. C’est grâce à l’application de telles techniques que le système SAP R/3 peut être puissant et flexible sans pour autant monopoliser trop de ressources informatiques. Le système SAP R/2 ne manipule pas quant à lui les objets de la même manière que R/3.

Au cours du processus de migration, les informations détenues dans les tables SAP R/2 doivent être récupérées et insérées dans les structures du système SAP R/3. Les informations sont en fait transférées sous la forme d’un ensemble d’objets de migration dont la structure est dictée par le contexte commercial, et qui ont été nommés en conséquence. Les données doivent être extraites de la base de données de R/2, transférées vers la base de données R/3, puis être rendues disponibles à l’ensemble du système SAP R/3.

Les données du système SAP R/2 sont exportées sous la forme de structures DDIC (Database Decimal lnterchange Code Structures) contenant les objets EBCDIC (Extended Binary-coded Decimal lnterchange Code). Les objets doivent ensuite être converties au format ASCII. Les programmes utilisés pour créer ces structures d’exportation sont automatiquement générés en temps réel dans le système SAP R/2. Le système SAP R/3 génère de la même manière des programmes d’importation qui reçoivent et intègrent les structures et leurs objets de données. Les règles de conversion de la société cliente sont prises en compte et appliquées par les programmes d’importation.

SAP fournit un outil de migration et des méthodes qui permettent de transférer des données de SAP R/2 à SAP R/3 sous la forme d'un transfert de données de clé. Le schéma ci-dessous nous résume le transfert de données de SAP R/2 vers SAP R/3 :

Les facteurs de réussite d’un projet de migration de données dans SAP

de réussite d’un projet de migration de données dans SAP Figure 4.3 La migration de SAP

Figure 4.3 La migration de SAP R/2 vers SAP R/3

C’est le serveur ALE qui convertit le format de données et transfert les données entre le système hôte R/2 et les instances R/3.

4.2 La Migration de données d’un système non-SAP (legacy system) vers SAP

R/3

Dans ce cas présent nous avons des installations qui ne sont pas des systèmes SAP (legacy system) et dont les données doivent être migrées vers des installations SAP.

données doivent être migrées vers des installations SAP. Datenmigration Migration de Données LSMW Figure 4.4 :
Datenmigration Migration de Données LSMW
Datenmigration
Migration de Données
LSMW
SAP. Datenmigration Migration de Données LSMW Figure 4.4 : Comment migrer les données d’un système

Figure 4.4 : Comment migrer les données d’un système Legacy vers SAP R/3 ?

Dans le passé, les coûts de la migration de données ont représenté jusqu'à 20% du coût total d'un projet de mise en œuvre de SAP. Ce coût a été considérablement réduit. Pour ce faire, SAP offre des outils personnalisés qui rendent plus efficace la migration de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

Pour migrer des données d’un système non-SAP vers un système SAP R/3, on utilise principalement l’outil LSMW (Legacy System Migration Workbench ou "Atelier de reprise de données d'anciens systèmes").

Lors de la mise en place de SAP R/3, il est important de savoir manipuler les quelques outils de SAP afin de bien cerner tous les éléments de paramétrages et de mise en œuvre de la future installation.

4.2.1 L’atelier de reprise de données d'anciens systèmes (Legacy System Migration Workbench (LSMW)), "l'arme absolue"

LSMW est un outil standard de SAP R/3 destiné à l'origine à proposer un cadre structuré pour la reprise de données.

Outre l'utilisation pour la reprise de données telle que prévue à l'origine par SAP, LSMW permet également la création et la modification en masse de données de façon efficace et très fiable. Le Legacy System Migration Workbench est un outil SAP qui peut servir à transférer dans SAP des données des anciens systèmes. Il comporte des fonctionnalités de correspondance (mapping) et de conversion, de même qu’un accès possible pour le développement ABAP (Advanced Business Application Programming (processeur générique pour la préparation de rapport) pour le codage maison.

L'approche est relativement simple : on commence par définir les structures de données cible et source. Puis on définit la correspondance ou le « mapping » entre données source et cible, c'est-à- dire des modalités d'intégration des anciennes données dans SAP, via des opérations de transcodification par exemple. Suivent enfin les phases de lecture du fichier source, la conversion des données source sur la base des règles de correspondance (mapping) définies précédemment et l’intégration des données en réel. La figure ci-dessous résume le fonctionnement du LSMW :

Les facteurs de réussite d’un projet de migration de données dans SAP

de réussite d’un projet de migration de données dans SAP Figure 4.5 : Le fonctionnement de

Figure 4.5 : Le fonctionnement de LSMW

4.2.2 Différentes façons d'utiliser LSMW

Pour reprendre des données dans SAP, plusieurs possibilités existent, présentées ci-dessous.

D’abord utiliser une structure cible proposée par SAP, le plus souvent pour les données de base (articles, gammes, nomenclatures, etc.) ou utiliser une interface BAPI (Business Application Programming Interface (voir paragraphe 4.2.3) ou un module fonction ou enfin faire enregistrer une transaction par le système pour la rejouer plusieurs fois (Batch Input Recording).

Je voudrais insister sur la dernière méthode, les autres seront développés dans la section 4.3 (voir plus bas).

Dans la méthode "Batch input recording", SAP va enregistrer les écrans (dynpros) dans lesquels

Les facteurs de réussite d’un projet de migration de données dans SAP

l'utilisateur va passer lors de l'enregistrement. Ensuite, l'utilisateur définira, parmi les champs détectés par SAP, ceux qui doivent faire l'objet d'une alimentation et ceux qu'il doit ignorer. Ainsi, n'importe quel utilisateur, sans connaissance technique préalable, est en mesure d'enregistrer une transaction pour fournir au système le cheminement des écrans par lesquels il devra passer, et les champs à alimenter.

De ce fait, lors de l'étape d'exécution, SAP va rejouer autant de fois que nécessaire la transaction enregistrée, sous forme d'un dossier batch-input (cette méthode, même si elle n'est pas la plus rapide en temps de traitement, offre un avantage certain en permettant de relancer les transactions "en échec").

Il va sans dire que l'intérêt de ce système, déjà important de base, peut être grandement accru en

ajoutant quelques lignes d'ABAP pour faciliter la transcodification

mapping sont tellement vastes que, la plupart du temps, on extrait les données du système Legacy pratiquement telles quelles, et on pilote toutes les opérations de manipulation de données dans LSMW.

en fait, les possibilités de

Ce mode de fonctionnement est tout particulièrement adapté à de la création / modification en masse de données (ou de documents) sortant du cadre des structures standard fournies par SAP.

4.2.3 Atouts et limites du LSMW

En bref, voici une synthèse des points forts et des limites du LSMW (particulièrement dans l'utilisation en batch-input présentée ci-dessus).

Avantages :

Le LSMW permet une définition claire d’une structure source et d’une structure cible. Le mapping est très souple car il existe la possibilité de l’enrichir par valeurs fixes, transcodification ou routine ABAP.

Le mécanisme d’exécution de la reprise est séquentiel, ce qui permet à chaque étape de valider les données (lecture source, conversion, exécution).

Il permet de bénéficier du retraitement d'erreurs de la gestion des dossiers batch.

Les facteurs de réussite d’un projet de migration de données dans SAP

Limites :

Le LSMW n’est pas un outil d’extraction du système Legacy et n’est pas non plus un outil d'export à partir de SAP car il fonctionne en import uniquement. Il permet de reprendre des données de base (son utilisation originelle), mais également de les modifier en masse ou bien de créer / modifier des documents (commandes SD par exemple), voire du paramétrage.

Il est complètement transverse dans SAP (pas limité à un ou plusieurs modules) et ses limites sont réduites par rapport aux avantages qu'il procure.

Voyons quelques exemples "réels" d'utilisation de LSMW (liste non exhaustive !) :

d'utilisation de LSMW (liste non exhaustive !) : reprise d'articles, d'équipements, de gammes, de

reprise d'articles, d'équipements, de gammes, de centres de coûts, etc…, reprise facile de plans de comptes (on fournit en entrée uniquement le numéro de compte et son libellé, tous les paramètres de compte FI étant définis dans le LSMW), création et ordonnancement de plans d'entretien PM avec règles complexes, création en masse de documents (commandes SD, ordres de service, etc…).

de documents (commandes SD, ordres de service, etc…). Pour terminer, nous dirons que LSMW est un
de documents (commandes SD, ordres de service, etc…). Pour terminer, nous dirons que LSMW est un
de documents (commandes SD, ordres de service, etc…). Pour terminer, nous dirons que LSMW est un

Pour terminer, nous dirons que LSMW est un outil qui gagnerait à être connu de tous les consultants SAP, intervenant sur des projets ou dans des centres de compétences SAP. En effet c'est un outil très puissant mais doté d'une ergonomie simple et utilisable par des consultants fonctionnels, sans compétences techniques particulières. Il va de soi que posséder quelques rudiments d'ABAP permet de gagner encore en efficacité (dans le mapping notamment), mais cela est valable dans tout SAP. Nous verrons dans la prochaine section qu’il existe, certes moins puissants, d’autres outils et techniques qui nous permettent de migrer des données.

4.3 Techniques & Outils de Conversion de données dans SAP

Lors de la mise en place de SAP R/3, il est important de savoir manipuler les quelques outils de SAP afin de bien cerner tous les éléments de paramétrages et de mise en œuvre de la future solution. Dans le cadre d’une migration de données, il est fréquent qu’un consultant veuille connaître l’outil de migration de données, d’un ancien système à un autre, afin de mieux maîtriser le processus, le paramétrage ainsi que les développements à faire.

Les facteurs de réussite d’un projet de migration de données dans SAP

4.3.1 Les techniques

Nous exposerons ici les différentes techniques existantes dans SAP. Chacune d’entre elle a son importance et sa spécificité. Par exemple, si nous avons des données de très faible volume, il est plus intéressant d’utiliser la saisie manuelle des données. Si nous voulons mieux gérer le traitement des erreurs, les IDOCs (Intermitted DOCument = document intermédiaire entre deux systèmes) offrent plus de possibilité et si nous avons de très gros volumes de données, nous pouvons utiliser les entrées par lots (direct input) mais la cohérence des données pourrait en pâtir.

4.3.1.1 Saisie manuelle (Manual Input)

Il s’agit ici de la saisie manuelle des données.

4.3.1.2 Entrée par lots (Batch Input)

Le principe du batch-input consiste à programmer la séquence des écrans d'une transaction, et remplir les champs avec les données d'entrée. La transaction est émulée. Tous les contrôles standard SAP sont effectués, cela permet une parfaite cohérence des données. Un dossier batch-input étant créé, il est aisé de retraiter les enregistrements erronés.

4.3.1.3 Traitement par transaction (Call Transaction)

Sur le même principe que le batch-input, mais une seule transaction est traitée à la fois. Il n'y a pas de dossier créé donc les données d'entrée restent volatiles et si la transaction n'est pas enregistrée dans SAP (incohérence des données), alors les données sont perdues.

4.3.1.4 Entrée directe (Direct Input)

Le principe consiste à alimenter directement les tables SAP à partir des données d'entrée sans passer par les contrôles SAP. Fortement déconseillé par SAP pour des raisons de cohérence des données. Cependant la version 4.6 de SAP permettra d'effectuer des Direct Inputs plus sécurisés.

4.3.1.5 ALE / IDOC

IDoc = Intermitted DOCument = document intermédiaire entre deux systèmes. Domaines fonctionnels IDOC :

EDI = Echange de Données Informatisé entre différentes sociétés (partenaires).

Les facteurs de réussite d’un projet de migration de données dans SAP

ALE = Echange de Données Informatisé entre différents systèmes au sein d'une même société. Il faut fournir à SAP les données d'entrée au format IDOC, et SAP gère automatiquement la cinématique des écrans et les zones renseignées, et fournit une fonctionnalité flux d’informations (workflow) pour le traitement des erreurs.

Les IDocs sont échangés avec les systèmes externes en fonction d'un partenaire ou d'un message spécifique. Les données IDoc sont donc définies au moyen d'accords d'interchange et de définitions de port.

4.3.2 Les outils

Nous ne listerons ici que les principaux outils standards proposés par SAP. Cependant il en existe d’autres qui sont souvent spécifiques à certaines solutions de SAP comme par exemple EMIGALL (spécifique à SAP IS-U), IBIP (spécifique à PM), Intergiciel (Middleware) (spécifique CRM), SAP Query, Quick-viewer (utilisable pour effectuer des contrôles quantitatifs après reprise).

4.3.2.1 LSMW

Comme vu dans le précédent chapitre, le LSMW encapsule des programmes d’injection comme les Batch-Input (soit standard ou spécifique (recording)), Direct Input, …

Il permet la lecture des données sources, le mapping des structures sources (tables internes) avec les structures cibles et l’injection des données dans les structures cibles.

4.3.2.2 L’outil CATT (Computer Aided Test Tool)

C’est un outil initialement conçu pour automatiser les tests. Il peut être utilisé pour des reprises simples. Il équivaut à LSMW par enregistrement (recording).

4.3.2.3 Modules fonctions standards, BAPI (Business Application Programming interface)

C’est une fonction standard SAP orientée ‘‘objet” qui gère un objet de gestion SAP avec ses méthodes. Par exemple un BAPI de gestion de demande d’achat avec des méthodes de création, modification et affichage de la demande d’achat (DA). Les BAPIs sont des fonctions appelées en temps réel par des systèmes externes.

Les facteurs de réussite d’un projet de migration de données dans SAP

La connaissance de ces outils et techniques est indispensable si on veut mieux maîtriser sa migration de données car en fonction des types de données certains outils et techniques sont plus adaptés que d’autres. Nous avons tenu compte de ces éléments lors du projet de migration de données chez DeBiere décrit dans le prochain chapitre.

Les facteurs de réussite d’un projet de migration de données dans SAP

5. Analyse du projet de Migration de données chez DeBiere

Dans ce chapitre, nous commencerons par présenter le contexte et le principal enjeu de la migration de données chez DeBiere, ensuite nous verrons quelle a été l’approche pour ce projet de reprise. Les principaux risques, la qualité des données et la stratégie adoptée seront aussi abordés dans ce chapitre.

5.1 Contexte et Enjeu

Pour rappel, le projet OMEGA a été mis en place pour d’une part répondre au besoin d’harmonisation des différents systèmes suite aux nombreuses acquisitions faites par DeBiere et d’autre part pour donner un avantage concurrentiel afin de réaliser son principal objectif : « Passer du plus grand au meilleur ». C’est dans ce contexte que s’est inscrit le projet de migration dans SAP et par conséquent le projet de migration de données dans SAP.

Le groupe choisit le progiciel SAP qui bénéficie de plusieurs atouts parce qu’il permet d’intégrer les fonctionnalités et les données des entreprises dans un système unique d’une part et d’autre part parce qu’il est leader sur le marché des progiciels de gestion intégrée.

L’enjeu est de taille car il s’agit d’assurer la reprise des données (extraction, transformation et chargement dans SAP) de 6 domaines fonctionnels dans un délai de 6 mois pour les 2 sites pilotes Luxembourg et Ukraine avec l’aide de l’intégrateur Accenture.

5.2 Déroulement du projet de migration de données

Nous expliquerons ci-dessous le déroulement du projet DeBiere notamment notre approche de la migration de données chez DeBiere, l’organisation, la stratégie adoptée et tout le processus de mise en œuvre et enfin nous terminerons en faisant un bilan de ce projet de migration des données.

5.2.1 L’approche migration de données chez DeBiere

Notre approche de la migration de données a consisté en 6 étapes décrites ci-dessous :

01Correspon 02 Extraction 03 Manipulation 04 Vérification 05 Chargement dance données données données
01Correspon
02 Extraction
03 Manipulation
04 Vérification
05 Chargement
dance
données
données
données
données
(mapping)
données

06 Réconciliation

données

Les facteurs de réussite d’un projet de migration de données dans SAP

En intégrant cette approche dans le processus général de migration dans SAP (figure 4.1), nous obtenons le schéma ci-dessous :

dans SAP (figure 4.1), nous obtenons le schéma ci-dessous : Figure 5.1 : L’approche migration de

Figure 5.1 : L’approche migration de donnée chez DeBiere intégrée au processus global de migration

5.2.1.1 Correspondance des données (mapping des données)

Le mapping de données vise à établir des correspondances entre l’ancien système et le nouveau système.

Les différentes filiales DeBiere opèrent sur différentes plateformes en utilisant différents technologies et processus. Afin de contrôler le transfert de données, le mapping des données est nécessaire car il permet de nous assurer que les données sont migrées là où c’est nécessaire.

Pour le mapping de données, nous disposions, pour chaque objet de la liste de tous les champs nécessaires avec leur description fonctionnelle comme par exemple ci-dessous (liste non exhaustive) :

Les facteurs de réussite d’un projet de migration de données dans SAP

Objet : articles

Groupe

Table

Champs

Description

Type de donnée

longueur

Vue données générales de base

MARA

MATNR

Numéro d’article

Caractère (CHAR)

18

Vue données générales de base

MAKT

MAKTX

Description article

Description article

40

Vue données générales de base

MARA

MEINS

Unité de meseure

Unité de meseure

3

Vue données générales de base

MARA

MATKL

Groupe d’article

Groupe d’article

9

     

Ancien numéro

Ancien numéro

 

Vue données générales de base

MARA

BISMT

d’article

d’article

18

Vue comptabilité

MBEW

PEINH

Prix unitaire

Prix unitaire

5

Vue comptabilité

MBEW

VPRSV

Indicateur prix

Indicateur prix

1

Vue comptabilité

MBEW

STPRS

Prix standard

Prix standard

12

5.2.1.1 Extraction des données

Le processus d'extraction de données vise à extraire toutes les données indispensables du système source pour les migrer dans un format prédéfini. Puisque les filiales opèrent sur des plateformes différentes, il est nécessaire d’avoir un format commun de fichiers d’extraction pour faciliter le processus de migration. Le format de fichier dépend de l’outil de migration créé.

5.2.1.2 Manipulation des données

Le processus de manipulation de données consiste à nettoyer les données, à les enrichir, à les valider afin d’avoir les données prêtes dans le format requis de chargement avec la qualité exigée de données.

Plus précisément, elle consiste au formatage des données, à l’élimination des doublons, à l’addition des données manquantes, à la conversion de données (utilisation des transcodifications) et à la validation des données (règle de gestion).

5.2.1.3 Vérification des données

Le processus de vérification des données consiste à obtenir la validation des équipes métier après avoir effectué toutes les manipulations nécessaires sur les données et avant le chargement de celles-ci dans le nouveau système. Cette étape est une étape de contrôle pour assurer la qualité des données. Une liste précise des points à contrôler doit être effectuée avant le chargement.

5.2.1.4 Chargement des données

Les facteurs de réussite d’un projet de migration de données dans SAP

Cette étape vise à intégrer toutes les données extraites dans le système cible. Après validation des données par les équipes métier, les données sont prêtes à être intégrées dans le nouveau système. Pour avoir un processus de chargement des données fiable, il est recommandé d’éviter l’altération des données durant le chargement, c’est-à-dire qu’une fois le fichier de chargement validé, on ne doit pas y effectuer des modifications avant le chargement.

5.2.1.5 Réconciliation des données

Le processus de réconciliation de données vise à s'assurer que les données principales extraites sont à 100% chargées dans le système cible. C’est le second contrôle dans le cycle de la migration des données et intervient après le chargement. Cette étape est importante car elle permet de s’assurer que le processus de chargement a été correctement exécuté.

En cas de rejet de certaines données lors du chargement, on doit effectuer une analyse des erreurs, les corriger et refaire valider un nouveau fichier avec uniquement les données corrigées en vue d’un second chargement.

Nous pouvons résumer l’approche migration de données chez DeBiere par le schéma ci-après :

Les facteurs de réussite d’un projet de migration de données dans SAP

04 Vérification données MDM (Master Input Data Management) Output 03 Manipulation S données O C
04
Vérification
données
MDM (Master
Input
Data Management)
Output
03 Manipulation
S
données
O
C
U
IMPORT
DONNEES
EXPORT
I
02
R
Extraction
B
∑ ∑ Enrichissement
Formatage
∑Format final
données
∑ Validation
C
L
Contrôle des
tables
E
E
∑ Vérification
des
doublons
01
Mapping
données
05 Chargement données - LSMW
06 Réconciliation données

Figure 5.2 : Schéma global de la migration de données chez DeBiere

MDM (Master Data Management) est la plateforme qui nous a permis de manipuler les données après extraction des données de l’ancien système. Il permet de formater les données extraites, de les vérifier, de les enrichir, de supprimer les doublons et enfin de les valider en vue de les charger dans le nouveau système. Après cela les données sont exportées de MDM vers des fichiers texte ou Excel prêts à être intégrés dans SAP R/3 via l’outil LSMW.

J’ai participé à la migration des données pour 2 filiales de DeBiere le Luxembourg et l’Ukraine. La filiale luxembourgeoise de DeBiere avait déjà intégré SAP R/2 (donc une migration de SAP R/2 vers SAP R/3) et la filiale ukrainienne avait un autre système qui lui était propre qui s’appelait EFAS. Pour toutes ses 2 filiales l’approche a été presque la même c’est-à-dire que les 6 étapes ci- dessus ont été autant valides pour le Luxembourg que pour l’Ukraine. Nous avons utilisé principalement l’outil LSMW qui est un outil puissant dont nous avions déjà parlé, pour intégrer les données.

Les facteurs de réussite d’un projet de migration de données dans SAP

5.2.2 Organisation

Comme dit précédemment, la migration de données exige d’une part la participation d’utilisateurs qui connaissent bien l’existant pour l’analyse des données, l’amélioration de leur qualité et les contrôles post migration et d’autre part la participation d’experts pour le formatage des données, l’intégration des règles de gestion établies, l’enrichissement des données et leur intégration dans le nouveau système.

Nous allons voir ci-dessous l’organisation globale du programme Omega avant d’expliquer comment était structurée l’équipe de migration de données.

était structurée l’équipe de migration de données. Figure 5.3 : La structure du projet Omega Le

Figure 5.3 : La structure du projet Omega

Le management du programme était composé de responsables de la société DeBiere et du responsable Accenture sur ce projet. Chaque domaine fonctionnel (Procurement, manufacturing,…) était composé d’équipes mixtes DeBiere et Accenture.

Les facteurs de réussite d’un projet de migration de données dans SAP

L’équipe migration de données était organisée comme suit :

Equipe locale Equipe centrale (Leuven) Off-Shore-Ile-Maurice Expert Local - outil (Intégrateur Responsable Expert
Equipe locale
Equipe centrale (Leuven)
Off-Shore-Ile-Maurice
Expert
Local - outil
(Intégrateur
Responsable
Expert outil
Chargement
des données
des données
MDM
(Intégrateur)
(DeBiere)
(Intégrateur)
Expert SAP
Responsable
(Reprise de
des données
données)
(DeBiere)
(Intégrateur)
Equipe
Responsable
fonctionnelle
fonctionnel
(Intégrateur)
local (par
domaine)
(Intégrateur)

Figure 5.4 : L’équipe migration de données chez DeBiere

Pour être plus explicite, à Louvain dans l’équipe centrale (core team) nous avions une personne

). Cette personne

responsable des données pour chacun des 6 domaines (manufacturing, finance,

constituait l’interface entre le responsable des données local (filiale) et l’équipe d’intégrateur

d’Accenture.

Les 2 responsables des données (un de l’équipe centrale et un de la filiale) étudient ensemble, en

fonction aussi des décisions prises avec la direction et avec l’assistance de l’équipe fonctionnelle

de l’intégrateur les données à extraire. Par exemple les clients qui n’ont pas commandé depuis plus

de 2 ans n’étaient pas pris en compte.

Après cela, l’expert technique local développait des outils ou utilisait les outils standard en vue

d’extraire les données souhaitées. Une fois les données extraites, l’expert MDM (Master Data

Management) prend le relais en enrichissant les données, en les formatant et en intégrant les règles

de gestion définies auparavant par DeBiere et en utilisant les transcodifications adéquates.

Une fois transformées, les données sont extraites de MDM dans un fichier texte ou Excel (si les

données étaient supérieures à 65.000, elles étaient extraites sur un fichier texte) avant d’être

envoyées à l’expert reprise de données SAP qui était mon rôle. Certaines transcodifications

Les facteurs de réussite d’un projet de migration de données dans SAP

n’étaient pas faites par l’outil MDM (par exemple les unités de mesure) et de même certaines règles de gestion n’étaient pas intégrées par l’outil MDM.

Mon rôle donc, en tant qu’expert reprise de données SAP, était de vérifier dans SAP s’il existait un outil standard pour chaque objet de migration (clients, articles, fournisseurs, etc…), auquel cas, il fallait que je le modifie en vue d’intégrer les transcodifications de données non faites et d’intégrer aussi certaines règles de gestion.

Au cas où l’outil de migration n’existait pas, il fallait le créer en tenant compte de plusieurs facteurs comme par exemple la volumétrie des données, la rapidité d’exécution du programme. Le choix de la technique de migration ou de l’outil était important puisque par exemple utiliser un enregistrement (recording) pour une volumétrie de 100.000 données était tout simplement impensable. On risquait de passer un après-midi à attendre que les données soient chargées et aussi de bloquer une transaction pendant plusieurs heures. Le chargement des données était effectué par une équipe de 4 personnes, tous d’Accenture, qui étaient situés en Ile-Maurice. J’étais responsable des 5 domaines suivants : Manufacturing, Supply Chain, Procurement, Commercial, Material Master. Un autre expert s’occupait spécifiquement de la finance.

5.2.3 Stratégie de migration

La stratégie globale de reprise qui a été utilisée est la stratégie par étapes c’est-à-dire que les données sont intégrées par filiale.

Au niveau de la reprise de données d’une filiale, la stratégie de reprise nous a permis de savoir précisément comment le travail de reprise de données sera construit, dans quel ordre les opérations vont être menées pour parvenir à atteindre les objectifs définis. Par exemple, on ne pouvait pas migrer les conditions de prix avant d’avoir migré les clients, les articles ou même les fournisseurs car il y avait une dépendance avec ces objets.

Nous avions aussi convenu que pour tous les objets dont le nombre de données était inférieur à 50 devaient être saisies manuellement. Seules les données appropriées seront migrées donc pas de données obsolètes. Le contrôle des doublons est critique dans la migration de données : des éléments de données uniques seront chargés par objet de données. Des commandes de contrôle doivent être intégrées dans le processus de transfert de données pour assurer la qualité de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

5.2.4 Documentation

Il s’agit d’une part de disposer des documents concernant les données existantes, les outils existants et d’autre part nous devions documenter tout ce que nous faisions c’est-à-dire documenter la création des nouveaux outils, leur utilisation et comment relancer les données en erreur une fois corrigées etc…

Cela est d’autant plus important car au cours du projet de migration l’expert reprise de données finance est décédé suite à une maladie et de ce fait nous devions continuer son travail. Il avait créé tous les outils nécessaires mais il nous était impossible d’en utiliser certains. D’une part pour certains outils plusieurs programmes devaient être lancés les uns derrière les autres mais nous ne savions pas dans quel ordre et d’autre part nous ne savions pas quel format de fichier utiliser pour le chargement. Nous avons finalement fait venir un autre expert pour recréer de nouveaux outils. Cela nous a pris quelques jours de retard dans notre planning.

L’autre raison pour dire que la documentation était indispensable est que les chargements étaient effectués par une équipe qui se trouvait à des milliers de kilomètres de nous en Ile Maurice (off- shore). Il fallait donc des documents qui expliquent précisément l’outil à utiliser pour chaque objet, la procédure de chargement. Et surtout que faire en cas d’erreur de chargement (par exemple s’ils ont chargé un mauvais fichier) ou s’il y a des rejets dans le chargement (par exemple certaines données sont rejetées si elles sont incomplètes).

La documentation ne semblait pas être une des priorités du manager du projet car nous avions un retard sur le planning du projet (nous expliquerons plus tard le retard). Après le souci que nous avions eu avec le décès de notre collègue, j’ai tiré la sonnette d’alarme et suis allé expliquer au manager la nécessité absolue de documenter tout ce l’équipe faisait et de l’intégrer dans le planning. Nous avons finalement convenu d’une semaine entière pour mettre à jour toute la documentation. Chaque fois que les données sont validées dans le nouveau système, nous disposions d’une demi journée pour la documentation.

5.2.5 La qualité des données migrées

La complexité des données s’accroît avec les modifications inhérentes aux personnes (mariage, départ, décès…) ou aux entreprises (rachat, fusion, etc.). Il est donc indispensable de concevoir ses informations comme des actifs, à gérer de la même manière qu’un patrimoine, sous peine

Les facteurs de réussite d’un projet de migration de données dans SAP

d’imposer au sein de son entreprise une mauvaise culture des données. Plusieurs facteurs expliquent cette gérance défaillante, comme par exemple une mauvaise information des clients.

Nous avons eu beaucoup plusieurs soucis avec la qualité des données puisque nous avons effectués beaucoup de correctifs en production. Il n’y a pas eu à proprement parler, chez DeBiere, une réelle politique de gestion de la qualité de données.

En considérant les données comme secondaires, les entreprises aboutissent à des problèmes d’incohérence ou de doublons qui les empêchent de développer des qualités de transparence et de sécurisation nécessaires à la satisfaction des clients et donc à la croissance de l’entreprise.

5.2.6 Choix et spécification des outils

Le principal outil que nous avions utilisé pour la migration de données chez DeBiere est le LSMW (décrit plus haut) car c’est un outil souple et simple d’utilisation. Cependant les techniques utilisées avec le LSMW dépendait de la volumétrie des données, des types de données et des durées de traitement (par exemple le direct input est beaucoup plus rapide en terme de traitement que les autres techniques mais n’est pas performant en terme de retraitement des erreurs. Pour retraiter les données, non chargées qui sont tombées en erreur lors du chargement, les IDOCS offrent beaucoup plus de possibilités). Pour mettre à jour les données déjà chargées, nous utilisions le recording (batch input spécifique).

5.2.7 La mise en œuvre

Nous disposions de 4 environnements pour le déroulement de la migration de données : un environnement de développement pour la création et la modification des outils de migration (DEV100), un environnement de test (ERA310) pour tester si les données ont été bien migrées, un environnement de Pré-production (ou Business simulation) (ERO100) et un environnement de Production (PRD100). Les 3 chiffres correspondent au mandant décrit plus haut.

Nous avions 3 cycles de chargement de données avant la production. Ces cycles de chargement étaient appelés « mock cycle ». Les 2 premiers cycles de chargement correspondaient au chargement de données dans l’environnement de test et le dernier chargement correspondait au chargement de données en pré-production. Les outils étaient développés et testés dans l’environnement de développement, ensuite ils sont transférés dans l’environnement de test.

Les facteurs de réussite d’un projet de migration de données dans SAP

Concernant le premier cycle de chargement, pour chaque objet on faisait un premier chargement afin de vérifier que celui-ci s’effectuait correctement et que les règles de gestion et les transcodifications étaient bien prises en compte. Les erreurs étaient extraites sur un fichier excel afin de vérifier leur nature, leur nombre pour pouvoir les corriger.

Ensuite l’environnement de test devait être rafraîchi c’est-à-dire que les données devaient être supprimées avant le second chargement qui correspondait au second cycle de chargement. Pour le premier cycle de chargement, nous nous étions engagés sur un taux de chargement entre 60 et 70% de données correctes et pour le second cycle de chargement, ce taux devait être de 80 à 90% de données correctes chargées. Pour le troisième cycle de chargement c’est-à-dire la pré-production, ce taux devait être à 100% car les fichiers utilisés pour le chargement en pré-production doivent être les mêmes que ceux qui seront utilisés pour le chargement en production.

En réalité, une fois les données chargées dans le premier cycle de chargement, l’environnement de test n’était pas rafraîchi par l’administrateur SAP. Nous étions obligés de nous débrouiller pour distinguer nos données du premier cycle de chargement du second puisque le chargement est fait dans le même environnement et même mandant. Pour s’en sortir nous notions, par exemple les premiers et derniers numéros d’articles créés dans la table des articles puisque les numéros s’incrémentent.

Mais nous étions vite débordés car nous avions 2 types de numérotation pour les articles : interne et externe. Les numéros internes correspondent à des numéros d’article créés par SAP. Les numéros externes correspondent à des numéros d’article DeBiere dont ils ne voulaient pas changer la codification. J’ai attiré l’attention du management sur cette difficulté et j’ai demandé à défaut de créer un nouvel environnement, au moins de créer un nouveau mandant dans l’environnement de test afin de séparer les données des premier et second cycles de chargement. Le management a répondu que cela ne pouvait pas être fait car il ne disposait pas de ressources supplémentaires, ni de délai supplémentaire pour créer ce nouveau mandant (paramétrage, plan comptable,…).

Après cela, nous ne soucions plus de la qualité des données chargées mais uniquement des données en erreur. Après chaque correction du fichier de données, nous rechargions jusqu’à ce qu’il n’y ait plus d’erreur dans l’environnement de test sans nous soucier de la cohérence des données chargées.

Les facteurs de réussite d’un projet de migration de données dans SAP

La règle était que nous ne pouvions pas charger dans l’environnement suivant si les données n’étaient pas validées dans l’environnement précédent par chacun des responsables de données.

Valider les données voulait dire, pour moi, d’une part vérifier que les données dans le système étaient bien celles contenues dans le fichier de chargement (données extraites de MDM) et d’autre part en déroulant les flux complets, on valide qu’on obtient les résultats attendus.

Or chaque fois que je demandais une validation aux équipes fonctionnelles, elles faisaient une extraction des données du système et les comparaient avec les données du fichier et dès qu’ils se rendaient compte qu’elles étaient identiques, elles m’envoyaient leur validation. Or nous savions que ce qui était dans le fichier a été correctement chargé sinon nous aurions obtenu un rapport d’erreur. Nous faisions une extraction des données stockées dans les tables SAP et nous les comparions avec celles contenues dans les fichiers de chargement. Et les données étaient identiques. Ce que nous attendions des équipes fonctionnelles c’est une analyse approfondie des données en déroulant des flux complets et de valider qu’en sortie (output), on obtient les résultats attendus.

Cela a été une grosse faille puisque par la suite j’ai été obligé de créer beaucoup de correctifs (patch) en production pour mettre à jour des données qui ne correspondaient pas à ce qui était attendu. Ce n’est pas concevable qu’on fasse beaucoup de modifications en production sur les données.

5.2.8 Les risques

Le démarrage (GO Live) a été retardé de quelques mois parce que d’une part nous n’avons pas su faire une bonne évaluation de la charge de travail pour la reprise de données et d’autre part les ressources ont été mobilisées trop tôt (quelques semaines avant que les environnements ne soient réellement disponibles) donc consommation inefficiente du budget jour/homme.

Le retard a été aussi dû au fait que nous n’avons pas anticipé l’indisponibilité d’une ressource en prévoyant un back up. Nous n’avions pas non plus documenté dès le début ce que nous faisions (expliquer les outils choisis, comment les utiliser,…).

Principalement nous dirons que la problématique de la migration de données est de rechercher une solution qui optimisera trois types de risque :

Les facteurs de réussite d’un projet de migration de données dans SAP

de réussite d’un projet de migration de données dans SAP le risque humain notamment dû à

le risque humain notamment dû à la désorganisation de l’exploitation informatique en raison de la charge de travail de mise en production des données et aussi à la déstabilisation temporaire des différents services au démarrage en raison du nombre élevé de correctifs devant

être apportés aux données (par exemple il y avait un risque que les utilisateurs travaillent sur des données erronées qui peuvent avoir certaines conséquences dont le risque d’émettre des

factures avec des données erronées (mauvaise condition de prix, pas le bon destinataire,

) ;

le risque technique dû aux incohérences dans les fichiers de chargement et au dysfonctionnement dans la reprise en dû aux incohérences dans les fichiers de chargement et au dysfonctionnement dans la reprise en particulier si de nombreuses interfaces provisoires sont à développer dans le cadre d’un démarrage progressif ;

à développer dans le cadre d’un démarrage progressif ; le risque fonctionnel dû à un retard

le risque fonctionnel dû à un retard dans le démarrage et qui peut conduire à des blocages de fonctionnalités de SAP (ex. commandes).

5.3 Typologie des données reprises

5.3.1 Données maître stables “ Master data ”

Les facteurs de réussite d’un projet de migration de données dans SAP

Il s’agit principalement des clients, fournisseurs, plan comptable, articles, banques. Ces données ont nécessité un travail de fiabilisation et d’épuration dans le système source et un travail manuel de saisies complémentaires dans le système cible a aussi été effectué.

Ce travail a été anticipé pour permettre toutes les opérations de contrôle et leur reprise sur le système cible (production). Cependant leur planification n’a pas été suffisante car de mon avis, la reprise de ces données aurait du se faire en production un mois au moins avant le démarrage. Car la mise à jour de ces données a des répercussions sur tous les autres types de données et sur les traitements. Il est inconcevable que par exemple les utilisateurs travaillent sur la facturation et que parallèlement des mises à jour s’effectuent sur les conditions de prix. Prendre suffisamment le temps entre la mise en production des données et le démarrage est nécessaire pour d’une part détecter les éventuelles anomalies non détectées au cours des opérations d’assainissement, les corriger et d’autre part pour éviter des mises à jour pendant le fonctionnement de la production car certaines mises à jour ont un temps de traitement important et cela risque de bloquer la production.

5.3.2 Données mouvement en cours

Il s’agit des écritures comptables en cours (soldes de compte, en-cours tiers, …). Ces données sont mises à jour quotidiennement dans les systèmes sources. Leur reprise dans le système cible a été mise en phase avec l’arrêt des systèmes sources.

5.3.3 Données mouvement de l’année

Il s’agit des écritures comptables de l’année. Ces données sont souvent consultées dans les systèmes sources. Leur reprise doit être phasée avec l’arrêt des systèmes source. Ce sont des données qui peuvent représenter un volume important et donc un temps de traitement important lors de reprises et conversion. Les données vitales ne doivent être converties que dans le dernier week-end avant le démarrage pour le bon fonctionnement du système au jour du démarrage. Les autres mouvements ne seront repris qu’après le démarrage.

5.3.4 Données mouvement historique

Les facteurs de réussite d’un projet de migration de données dans SAP

Ces données ont été reprises en même temps que la reprise des mouvements de l'année. Elles peuvent représenter un volume important et donc un temps de traitement important lors des reprises et conversion. Ne doivent être converties que les données vitales pour le bon confort d’utilisation du système en régime de croisière, ou dont la disponibilité répond à des nécessités légales que la suppression des anciens systèmes ne permet plus de remplir.

5.3.5 Paramètres de structure

Ces données représentent peu de volume, leurs caractéristiques sont liées à la structure des systèmes existants et à l’organisation actuelle. La spécificité de ces données dans SAP a nécessité une reprise manuelle. Il s’agit des données société, domaine d'activité, divisions,…

5.4 Bilan

Les facteurs de réussite d’un projet de migration de données dans SAP

Le démarrage a finalement eu lieu, certes dans la douleur mais les utilisateurs des deux sites pilotes peuvent à présent profiter de leur nouvelle application. Jusqu’à la veille de la mise en production pour l’Ukraine, la plupart des données stocks n’étaient pas correctes en production. Ce n’est qu’après plusieurs mises à jour via des programmes que j’ai créés qu’on a pu résoudre les problèmes. Pour le premier site pilote le Luxembourg, nous avions plutôt des soucis au niveau des conditions de prix. La plupart d’entre elles n’étaient pas correctes après la mise en production. Cela veut dire que la phase en amont de préparation des données n’a pas été réalisée avec toute la rigueur requise.

L’intérêt pour ce projet a été triple : il m’a permis d’une part de participer à un grand projet d’envergure internationale avec des interlocuteurs de tous horizons, échangeant avec eux nos

méthodes de travail et partageant avec eux certaines approches de la gestion d’un projet de migration données. Ce projet m’a permis de découvrir des pays que je n’avais jamais visité avant

ce projet et de renforcer mon anglais puisque le projet s’est déroulé entièrement en anglais.

De plus il m’a permis aussi de prendre conscience de l’importance de la qualité des données. Jamais avant ce projet je ne m’étais soucié de la qualité des données dans un projet de migration de données, je me contentais de charger les données et de vérifier que les données chargées correspondaient bien aux données contenues dans le fichier de chargement (comparaison faite en faisant une extraction des tables chargées).

Avant de quitter ce projet, j’ai formé une personne qui se trouvait en Ile Maurice (qu’on a fait venir à Louvain) pour me remplacer et fait le transfert de connaissance avec elle. Nous avions commencé le processus de migration des données pour la Russie qui était la filiale suivante dans le planning de migration. Toute l’intégration des données des autres filiales était pilotée en offshore à l’île Maurice.

A travers la migration de données chez DeBiere, de la littérature et de notre expérience à travers

différents projets auxquels nous avons participé, nous avons pu dégager quelques points importants qui contribuent au succès d’un projet de migration de données que nous développerons dans le chapitre suivant.

6. Facteurs clés de succès et Recommandations

Les facteurs de réussite d’un projet de migration de données dans SAP

Lorsque l’on aborde une migration de données, un des facteurs de succès consiste en la conception préalable d’une documentation précise sous forme de protocole de reprise afin d’une part de tracer le chemin et d’autre part de prévenir les risques organisationnels et humains.

Elle doit reprendre les principaux éléments nécessaires pour la migration de données (scénario de reprise, risques, organisation, matériel,…).

Un autre facteur de succès pour tout projet de migration de données est la disponibilité et l’expérience des ressources que le partenaire choisi (intégrateur) met à la disposition de l'entreprise car de ceux là dépendent en partie le succès du projet. Nous savons tous que la plupart des intégrateurs ont tendance à « placer » beaucoup de jeunes diplômés sans expérience dans des projets, qui par ailleurs en profitent pour se former. Chose légitime mais les données étant une ressource cruciale de l’entreprise, il faudrait s’assurer que ceux qui les manipulent ont une certaine expertise afin de ne pas compromettre la qualité des données. La disponibilité des ressources pour vérification des données reprises est un facteur très important de succès de cette activité. En effet, l'accès aux données doit être vérifié au travers des transactions SAP et des tests précis doivent être exécutés pour valider la complétude des résultats et le temps de réponse.

Il est indispensable aussi de faire une évaluation de charge des reprises de données automatiques qui a pour objectif de donner un ordre de grandeur de la charge de développement du projet de reprise de données. Cette évaluation couvre la totalité du cycle des reprises (programmes d’extraction depuis les systèmes existants, de création et maintenance des tables de transcodification, Abap vers SAP Ceci permettra par la suite d’établir un planning plus précis de la migration. Concernant les données, il est important de conduire avec les utilisateurs et les acteurs process une démarche d’analyse sur chaque flux pour déterminer la pertinence et le périmètre de la reprise à effectuer. Il faut aussi valider les performances attendues et la fiabilité des conversions et contrôles en phase de recette et mettre à disposition les machines assez tôt pour commencer les reprises.

Construire le plus tôt possible une équipe utilisateur qui, en liaison avec l’équipe projet étudiera les opérations d’assainissement à mener afin de permettre de minimiser le volume de données rejetées et de n’effectuer que la reprise des données vivantes est un facteur important de succès. Ces opérations porteront sur la sélection des enregistrements de données obsolètes dont la reprise

Les facteurs de réussite d’un projet de migration de données dans SAP

est inutile, l’encodage des compléments de données nécessaires pour permettre un passage uniformisé dans les routines de reprise (exemple : tout enregistrement client payeur doit comporter un code mode et type de règlement), les natures de champ (exemple : un champ considéré comme numérique dans les reprises doit comporter des zéros à gauche etc

Nous recommandons pour réussir son projet de migration de données, en plus de tout ce que nous avons évoqué ci-dessus :

d’avoir une stratégie clairement définie, car elle permet de savoir précisément comment le travail de reprise de données sera construit, dans quel ordre les opérations seront menées pour parvenir à atteindre les objectifs définis ; de bien définir la composition de l’équipe de migration et le rôle de chacun ; de documenter toutes les étapes de la migration, les outils utilisés, l’ordre des reprises (par exemple les articles doivent être migrés avant les conditions de prix) ; de faire une analyse de la qualité des données (rechercher les données partiellement ou

totalement manquantes, les données non cohérentes ou erronées,

de bien spécifier les outils de migration à utiliser (préférer les standards aux spécifiques) ; mettre à disposition très tôt les machines pour les reprises ; d’effectuer des bascules à blanc pour test et validation. Ces bascules à blanc permettent de dérouler le processus complet de reprise avant démarrage dans des conditions aussi proches que possible des conditions réelles. Les objectifs recherchés sont d’améliorer et valider les procédures d’arrêt des systèmes source et de démarrage du nouveau système, d’offrir aux équipes en charge de ces opérations la possibilité de s’entraîner en grandeur réelle, de vérifier la validité des données source pour reprise et la complétude des tables de transcodification et enfin d’estimer le temps de traitement des programmes. Si ces bascules à blanc permettent de déceler un trop grand nombre de données rejetées au moment des traitements de reprise, de nouvelles bascules doivent être effectuées jusqu’à ce que le volume de rejet soit minimum.

doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR
doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR
doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR
doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR
doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR
doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR
doivent être effectuées jusqu’à ce que le volume de rejet soit minimum. ) ; Conclusion MSIR

) ;

Conclusion

Les facteurs de réussite d’un projet de migration de données dans SAP

A travers cette étude, nous avons constaté la place prépondérante que prend la migration de

données dans un projet de mise en place d’un système d’information. En fait, les données constituent “ l’épine dorsale ” du Système d’information de l’entreprise, nécessitant une attention particulière, notamment, lors de leur migration dans le nouveau système.

Au vu des énormes enjeux, nous avons tenté, à partir de la littérature et en analysant le déroulement du projet de migration de données chez DeBiere, de comprendre d’abord ce qu’est la migration de données dans sa globalité et ensuite de savoir quels sont les facteurs qui contribuent à la réussite d’un projet de migration de données dans SAP.

Une préparation et une planification suffisantes, de même qu’une approche rigoureuse de la migration de données est indispensable pour réussir l’implémentation des applications d’entreprise SAP. Il est important pour cette raison de mettre en oeuvre des procédures standard confirmées afin de garantir le succès de la migration de données et de ne laisser aucun détail au hasard. L’entreprise doit naturellement tout d’abord identifier ses modes de fonctionnement et répertorier les données à récupérer et à migrer c’est-à-dire cartographier l’existant au niveau des données.

il est important aussi de prendre en compte

les contraintes légales dans le cadre de la migration en terme de données dynamiques (par exemple

en ce qui concerne les données comptables : totaux, soldes, postes ouverts, ).

En dehors des données statiques (clients, articles,

),

Il est important dans la mise en œuvre d’un projet de migration de données d’en faire comprendre l’importance aux responsables car sans une bonne préparation, une bonne planification et une implication de tous les acteurs, les projets d’implémentation courent un risque pour la survie de l’entreprise.

Cependant, quelque soit l’attention accordée à la fiabilité des données migrées, un certain nombre

de rejets peut toujours apparaître. D’où l’importance de la vérification des données post-migration.

Une documentation claire et précise présentant toutes les étapes de la migration est indispensable

pour donner une orientation au projet d’une part et d’autre part pour avoir une meilleure charge de travail des membres de l’équipe du projet.

Le partage des responsabilités et l'organisation efficace des tâches s'imposent très vite comme des

priorités pour l'entreprise qui souhaite disposer de données fiables et complètes. Et

Les facteurs de réussite d’un projet de migration de données dans SAP

paradoxalement, le rôle de l'humain devient, dans un système toujours plus automatisé, de plus en plus important.

L'entreprise doit répondre à certains impératifs afin de rester compétitive dans un secteur où le phénomène de consolidation et de mondialisation ne cesse d'augmenter, et où le client, plus informé que par le passé, acquiert chaque jour davantage de pouvoir. Plus que la mise en place d’une politique de diminution des coûts, l’entreprise doit, si elle veut croître, se différencier en tablant sur la création perpétuelle de nouvelles valeurs pour ses dépositaires (clients, employés, partenaires, etc.).

La démarche de migration de données présentée ici peut être généralisée quelque soit le contexte structurel.

Dans les projets de migration de données où j’ai eu à intervenir, je ne m’occupais que de la partie technique c’est-à-dire de la création des outils, de leur choix s’ils existaient en standard, du format des fichiers de chargement, du chargement des données. Cette thèse m’a permis de pousser plus loin ma curiosité afin de mieux comprendre la démarche de migration de données. Cela m’a permis de comprendre la nécessité de bien préparer et planifier son projet de migration de données depuis la phase d’extraction jusqu’au chargement et même jusqu’aux contrôles des données post- migration.

Glossaire

ABAP signifiant à l'origine Allgemeiner Berichtsaufbereitungsprozessor (processeur générique pour la préparation de rapport) a par la suite été anglicisé en Advanced Business Application Programming. C’est un langage de programmation propriétaire, faisant partie de l'ensemble

Les facteurs de réussite d’un projet de migration de données dans SAP

logiciel SAP. Dans ABAP/4 le chiffre 4 fait référence à son appartenance à la classe des langages de quatrième génération.

Bascule de données : Processus de passage de l’ensemble des données à reprendre d’un système source vers un système cible jusqu’au démarrage de celui ci. Ce processus inclut les opérations d’organisation des ressources, de mise à disposition des moyens techniques, de contrôles intermédiaires, de conversion, de vérification des données dans le système cible, de clôture et d’arrêt du système source.

Cible : Système en cours de démarrage destinataire d’un flux de reprise de données

Conversion : Opération qui consiste à transformer une donnée entre le système source et le système cible en modifiant son format (nature des caractères, longueur) ou/et son contenu (codification du champ) sans que sa fonction soit modifiée entre l’ancien et le nouveau système.

Lager : ensemble des bières à fermentation basse.

Reprise de donnée : Opérations qui consistent à extraire des données d’un système (source) pour

les injecter dans un autre (cible) avec d’éventuelles étapes intermédiaires automatiques ou non

(reformatage, transcodification, saisies manuelles

)

Source : Système actuellement en exploitation, origine d’un flux de reprise de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

Références

Bibliographie

Danielle LAROCCA « SAP R/3 l’Intro » (CampusPress Edition 1999)

 

Pierre-Yves MARTIN « Guide de mise en place d’un progiciel » (Editions d’organisation

2001)

LE Macmillan « SAP R/3 » (CampusPress Edition 1999)

 

Philippe FENOUILERES « Les données de l'entreprise» (Editions EYROLLES ; 1992)

Thomas

REDMAN

« La

qualité

des

données

à

l’âge

de

l’information »

(éditions

InterEditions 1998)

Webographie

http://www.sap.com/fr

Ce site permet d’obtenir des informations sur la société SAP, son histoire, les solutions proposées et les services qu’elle offre.

www.01net.com

Ce

témoignages sur des projets de migration de données.

des

site

nous

a

permis

d’avoir

Autres :

Documents internes DeBiere Documents internes Accenture

www.DeBiere.com

Ce site permet d’obtenir des informations sur la société DeBiere, son histoire, ses produits, ses valeurs.

www.journaldunet.com

Ce site nous a permis d’avoir des informations sur les principaux acteurs de la migration de données et a attiré notre attention sur les risques des projets de migration de données.

Les facteurs de réussite d’un projet de migration de données dans SAP

Annexes

Les facteurs de réussite d’un projet de migration de données dans SAP

Présentation de SAP – Exemple : création d’un outil de chargement via LSMW dans SAP – Guide de chargement via LSMW

La porte d’entrée dans SAP est l’écran ci-dessous :

La porte d’entrée dans SAP est l’écran ci-dessous : Nous avions expliqué la notion de mandant

Nous avions expliqué la notion de mandant plus haut (cf. : chapitre 3.5). Pour entrer dans SAP, il faut mettre son nom d’utilisateur et son mot de passe qui ont été attribués.

Ensuite nous accédons aux différents menus. Nous voyons dans l’écran ci-dessous, par exemple, le module administration des ventes. En descendant la hiérarchie jusqu’à client, nous voyons le répertoire ‘’Créer‘’ qui permet de créer un client.

‘’Créer‘’ qui permet de créer un client. En règle générale, l’extension ‘01’ dans SAP

En règle générale, l’extension ‘01’ dans SAP signifie qu’on est en mode création, ‘02’ en mode modification, ‘03’ en mode display. Exemple : XD01 pour créer un client, XD02 pour modifier les informations concernant un client, XD03 pour uniquement visualiser les informations concernant un client. C’est une information importante qui nous sera indispensable lorsqu’on va manipuler les LSMW pendant la migration de données. L’exemple ci-dessous concernant la création des nomenclatures (Bill of material) nous édifiera sur la manière de créer les LSMW. Ce document faisait partie de mes livrables et constituait un guide de chargement dans SAP.

Les facteurs de réussite d’un projet de migration de données dans SAP

LSMW GUIDE

Bill Of Material

History of the document

Version

Désignation de la version du document

Date

Auteur

1.0

Draft

12/09/2006

S. LY

Les facteurs de réussite d’un projet de migration de données dans SAP

Summary

Subject

Presentation of the steps to follow to launch the LSMW Bill Of Material

Application

Domain

Responsibles

E ERP

Application et Contrôle Integration / Conversion Team Use:

Integration / Conversion Team

Validation

Unit

Date

Author:

S. LY

12/09/2006

Validator:

Approver:

The original visas are stored in the documentary base or in a validation LOAD TEMPLATE.

Les facteurs de réussite d’un projet de migration de données dans SAP

Table of content

1 LAUNCHING OF THE LSMW

93

2 CREATION OF BILL OF MATERIAL (BY LSMW)

93

2.1 Project

93

2.2 Fields

94

2.3 Structures Relations

95

2.4 Launching LSMW

95

2.4.1 Specify Files: Specify the directory of the files

95

2.4.2 READ DATA

96

2.4.3 Convert data

97

2.4.4 Create Batch Input

98

2.4.5 Run Batch Input (we can use SM35 too)

98

2.5

Process BOM

98

Les facteurs de réussite d’un projet de migration de données dans SAP

Launching of the LSMW

We must launch the following LSMW to charge Bill of Material:

Transaction:

LSMW

Project:

ZTESTSLY

Subproject: MANUFACTURING

 

Object :

BOM

Etape

Technique of

Program name

Description

importation

1

Batch Input

RCSBI010

Material BOM

Creation of Bill of Material (by LSMW)

1.1 Project

This LSMW makes it possible to create Bill of Material.

Transaction : CS01.

Project :

ZTESTSLY

Subproject :

MANUFACTURING

Object :

BOM

Subproject : MANUFACTURING Object : BOM 2 Files needed : 1 header file and 1 items

2 Files needed : 1 header file and 1 items file

HEADER_BOM.txt

ITEM_BOM.txt

1 header file 1 Item file

Les facteurs de réussite d’un projet de migration de données dans SAP

Les facteurs de réussite d’un projet de migration de données dans SAP 1.2 Fields MSIR Page

1.2 Fields

Les facteurs de réussite d’un projet de migration de données dans SAP 1.2 Fields MSIR Page

Les facteurs de réussite d’un projet de migration de données dans SAP

1.3 Structures Relations

de migration de données dans SAP 1.3 Structures Relations 1.4 Launching LSMW Transaction : LSMW Specify

1.4 Launching LSMW