Vous êtes sur la page 1sur 127

bu

THESE PROFESSIONNELLE

Les facteurs de russite dun projet de migration de donnes dans


SAP

Seydou LY
Mastre Spcialis
Management des Systmes dInformation Rpartis
Promotion 2005-2007

Tuteur formation : Mr Dominique Briolat

Les facteurs de russite dun projet de migration de donnes dans SAP

Page de garde

Nom

LY

Prnom

Seydou

Programme promotion

MSIR 2005-2007

Adresse pour le renvoi par la poste

Tlphone portable personnel

Tlphone fixe personnel

Email personnel et professionnel

Version

finale

Nombre de pages

125

Numro des chapitres inclus dans la version


prcdente

Numro des nouveaux chapitres inclus dans


cette nouvelle version

MSIR

Page 1/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Remerciements

Je tiens remercier M. Dominique BRIOLAT pour sa contribution la validation de ce document,


pour ses conseils et sa disponibilit durant llaboration de ce document en tant que tuteur de thse
et surtout pour sa patience.
Jen profite galement pour remercier toute lquipe acadmique de lESSEC et de lENST Paris
qui fait un travail remarquable pour garantir lexcellence de ce mastre.
Pour mavoir accept au sein de cette formation enrichissante et trs motivante, je remercie Ren
JOLY et Dominique BRIOLAT.
Merci mes chers camarades avec qui jai partag des moments de bonheur durant ses deux
annes.

MSIR

Page 2/125

2005-2007

Les facteurs de russite dun projet de migration de donnes 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'exprience, tout le reste n'est que de


l'information.
(Albert Einstein)

MSIR

Page 3/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Sommaire
RESUME .....................................................................................................................................9
INTRODUCTION ...............................................................................................................11
1.

PRESENTATION DU GROUPE DEBIERE ...........................................13

1.1

Prsentation gnrale....................................................................................................................................... 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
Dfinitions......................................................................................................................................................... 22
2.1.1
Quest-ce quune donne ?......................................................................................................................... 22
2.1.2
Quest-ce quune migration de donnes ? .................................................................................................. 22
2.2

Pourquoi migrer des donnes ?....................................................................................................................... 23

2.3

Produits & March .......................................................................................................................................... 24

2.4
La migration de donnes : un projet parallle .............................................................................................. 28
2.4.1
Organisation ............................................................................................................................................... 30
2.4.2
Stratgies de migration............................................................................................................................... 32
2.4.3
Documentation ........................................................................................................................................... 33
2.4.4
La qualit des donnes migres.................................................................................................................. 33
2.4.5
Choix et Spcification des outils................................................................................................................ 36
2.4.6
Prparation de la mise en uvre ................................................................................................................ 36
2.5

Les facteurs de risque d'un projet de Migration de donnes ....................................................................... 36

3.

PRESENTATION DE SAP..................................................................................37

3.1

Prsentation gnrale de lentreprise SAP..................................................................................................... 38

3.2

Historique ......................................................................................................................................................... 39

3.3
Prsentation de SAP R/3.................................................................................................................................. 43
3.3.1
Vue Fonctionnelle ...................................................................................................................................... 43
3.3.2
Vue Organisationnelle................................................................................................................................ 44
3.4
Architecture du systme SAP R/3................................................................................................................... 46
3.4.1
Environnement client/serveur .................................................................................................................... 47
3.4.2
La hirarchie trois niveaux ...................................................................................................................... 48

MSIR

Page 4/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.5
Principes de la base de donnes chez SAP ..................................................................................................... 51
3.5.1
Base de donnes ......................................................................................................................................... 51
3.5.2
Structure dune base de donnes ................................................................................................................ 51
3.5.3
Systme de gestion des bases de donnes relationnel (SGDBR) ............................................................... 52
3.5.4
Bases de donnes supportes par SAP ....................................................................................................... 52
3.5.5
Mtadonnes .............................................................................................................................................. 52
3.5.6
Le modle de donnes dentreprise SAP.................................................................................................... 53

4.

LA MIGRATION DE DONNEES DANS SAP .......................................54

4.1

La Migration de donnes de SAP R/2 vers SAP R/3..................................................................................... 56

4.2
La Migration de donnes dun systme non-SAP (legacy system) vers SAP R/3 ....................................... 58
4.2.1
Latelier de reprise de donnes d'anciens systmes (Legacy System Migration Workbench (LSMW)),
"l'arme absolue" ......................................................................................................................................................... 59
4.2.2
Diffrentes faons d'utiliser LSMW........................................................................................................... 60
4.2.3 Atouts et limites du LSMW ........................................................................................................................... 61
4.3
Techniques & Outils de Conversion de donnes dans SAP.......................................................................... 62
4.3.1 Les techniques................................................................................................................................................... 63
4.3.1.1 Saisie manuelle (Manual Input) ................................................................................................................. 63
4.3.1.2 Entre par lots (Batch Input)...................................................................................................................... 63
4.3.1.3 Traitement par transaction (Call Transaction) ........................................................................................... 63
4.3.1.4 Entre 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 Loutil 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 Droulement du projet de migration de donnes ................................................................................................ 66
5.2.1 Lapproche migration de donnes chez DeBiere .............................................................................................. 66
5.2.1.1 Correspondance des donnes (mapping des donnes) ............................................................................... 67
5.2.1.1 Extraction des donnes............................................................................................................................... 68
5.2.1.2 Manipulation des donnes.......................................................................................................................... 68
5.2.1.3 Vrification des donnes ............................................................................................................................ 68
5.2.1.4 Chargement des donnes............................................................................................................................ 68
5.2.1.5 Rconciliation des donnes ........................................................................................................................ 69
5.2.2 Organisation ........................................................................................................................................................ 71
5.2.3 Stratgie de migration ........................................................................................................................................ 73
5.2.4 Documentation .................................................................................................................................................... 74
5.2.5 La qualit des donnes migres.......................................................................................................................... 74
5.2.6 Choix et spcification des outils ......................................................................................................................... 75
5.2.7 La mise en uvre ................................................................................................................................................ 75
5.2.8 Les risques ........................................................................................................................................................... 77

MSIR

Page 5/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

5.3 Typologie des donnes reprises............................................................................................................................. 78


5.4 Bilan ........................................................................................................................................................................ 80

6.

FACTEURS CLES DE SUCCES ET RECOMMANDATIONS .81

CONCLUSION......................................................................................................................83
REFERENCES ......................................................................................................................87
ANNEXES ................................................................................................................................88
Prsentation de SAP Exemple : cration dun outil de chargement via LSMW dans SAP Guide de
chargement via LSMW................................................................................................................................................ 89
Planning de suivi des chargements ........................................................................................................................... 101
Template : Fichier de chargement des donnes. Exemple : fichier de chargement des conditions de prix ....... 102
Template : Mapping des donnes. Exemple : fichier de mapping des conditions de prix. .................................. 104

COMMENT FONCTIONNE UN LSMW BATCH INPUT RECORDING? .........................106

MSIR

Page 6/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Table des figures


Figure 1.1 Les 4 produits vedettes DeBiere : Stella Artois, Brahma, Becks et Leffe...13
Figure 1.2 - Classement des 5 premiers brasseurs mondiaux .......................................................17
Figure 1.3 : La migration de donnes intgre aux processus mtier ..........................................20
Figure 2.1 : Schma du processus de reprise des donnes............................................................23
Figure 2.2 : Le contexte de la migration de donnes.....................................................................24
Figure 2. 3 : Cycle de vie processus de conversion et reprise de donnes ....................................29
Figure 2.4 : Equipe de Migration des donnes intgre au processus global de migration ........31
Figure 3.1 : Modle dintgration de R/3.......................................................................................38
Figure 3.2 : Solutions compltes d'industrie..................................................................................39
Figure 3.3 : Principales units structurelles SAP..........................................................................44
Figure 3.4 Larchitecture du systme SAP R/3 comprend des serveurs de bases de donnes, des
serveurs dapplications et des systmes de prsentation. ........................................................46
Figure 3.5 : Une architecture standard client/serveur relie les stations de travail au serveur....47
Figure 3.6 : Larchitecture 3 niveaux est devenue le concept architectural standard des
installations SAP R/3................................................................................................................48
Figure 3.7 : SAP sinterface avec plusieurs systmes....................................................................49
Figure 3.8 : Types de donnes SAP ................................................................................................53
Figure 4.1 : La migration de donnes dans SAP ...........................................................................55
Figure 4.2 : Comment migrer les donnes 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 donnes dun systme Legacy vers SAP R/3 ? ........................58
Figure 4.5 : Le fonctionnement de LSMW ....................................................................................60
Figure 5.1 : Lapproche migration de donne chez DeBiere intgre au processus global de
migration ...................................................................................................................................67
Figure 5.3 : La structure du projet Omega ....................................................................................71
Figure 5.4 : Lquipe migration de donnes chez DeBiere ...........................................................72

MSIR

Page 7/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Tableaux
Tableau 1.1 : Quelques chiffres cls DeBiere ................................................................................17
Tableau 1.2 : Planning de dmarrage par pays .............................................................................19
Tableau 2.1 : Les principaux diteurs dETL ................................................................................27
Tableau 3.1 : Part de march en 2005 des diteurs dERP en France (Source PAC) .................40
Tableau 3.2 : Les dates cls du dveloppement de SAP.................................................................41
Tableau 3.3 : Quelques chiffres cls de SAP .................................................................................42

MSIR

Page 8/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Rsum
Dsormais au cur des stratgies dentreprises, les systmes dinformation sont de plus en plus
confronts une spirale dvolutions permanentes : changements denvironnements techniques,
risques dobsolescence de certaines plate-formes, rapprochements de systmes dinformation dans
le cadre de fusions, gnralisation des nouvelles technologies, ... Face ces problmatiques,
lenjeu pour les entreprises est triple, dabord capitaliser sur lexistant en ne perdant rien de la
richesse de leurs informations et donnes, permettre la continuit du fonctionnement des systmes
dinformation pendant la migration, de faon la plus transparente possible pour les utilisateurs et
enfin veiller la matrise totale du projet, en terme de cots, dlais et risques.
Pour rpondre ces enjeux stratgiques, il est ncessaire de matriser son projet de migration et en
particulier son projet de migration de donnes.
La problmatique de migration de donnes recouvre des situations varies. Il peut dagir d'une
fusion ou d'un rapprochement de socits, les donnes devant tre portes vers le systme cible
retenu ou dans le cadre de l'intgration d'un ERP ou de lalimentation dun entrept de donnes
(data warehouse). Enfin, il peut aussi sagir dune rnovation de systmes dinformation, avec une
volution vers un SGBD plus prenne (passage dIDS2 Oracle, de DL1 ou Datacom DB2, ).
Quiconque sest lanc dans un projet de migration de donnes ou de consolidation de systmes
grande chelle sait quel point dplacer massivement les donnes est une tche difficile et risque
surtout si lon ne prpare, ni ne planifie son projet de migration de migration de donnes. Celle-ci
implique des transformations et des conversions complexes ainsi que des oprations de nettoyage
et de validation de donnes.

Nous avons analys la migration de donnes chez DeBiere

et partir de cette analyse, nous

avons dgag quelques lments cls qui contribuent au succs dun projet de migration de
donnes et avons pu faire quelques recommandations.
Il tait indispensable de comprendre dabord les raisons et objectifs qui ont pouss DeBiere
migrer ses donnes dans SAP, en faisant une prsentation gnrale de lentreprise et en expliquant
le contexte et les enjeux. Le choix de SAP ne sest pas fait par hasard, cest pour cela que jai
prsent la technologie sur laquelle jai travaill tout au long de cette tude : SAP R/3, afin de

Le nom de la socit a t chang en Debiere

MSIR

Page 9/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

comprendre les volutions et les raisons du succs de ce progiciel dune part et dautre part la
manire dont les donnes sintgrent dans SAP.
Lautre aspect de notre tude est la qualit des donnes. Migrer les donnes est une chose, encore
faudrait-il quelles soient exploitables et quelles ne soient pas obsoltes.
En consquence, pour russir limplmentation des applications dentreprise SAP, une approche
rigoureuse de la migration de donnes est indispensable.

MSIR

Page 10/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Introduction
Le traitement de l'information dans l'entreprise est en pleine mutation. Les changements
fondamentaux (comptitivit accrue, acquisitions, fusions, mondialisation, etc..) conduisent de
plus en plus d'entreprises mieux organiser leur systme dinformation (SI) et migrer leurs
applications informatiques internes vers les progiciels de gestion intgrs du march, ou ERP
(Enterprise Resource Planning), qui offrent des solutions transversales, homognes, intgres,
efficaces et volutives. De nombreuses entreprises voient dans leur Systme dInformation un
vecteur dinnovation souvent stratgique.
De plus, le client est maintenant trs exigeant et, mme pire, ses exigences sont en changement
continu. Il ne veut pas seulement un prix bas, mais des dlais plus courts et une meilleure qualit
(ensemble de caractristiques du produit qui le satisfassent). Et en plus, il faut innover
frquemment pour apporter au Client une qualit quil ne trouve pas ailleurs.
Pour rpondre ce dfi, il faut vhiculer une information homogne et enrichie sur les clients et
sur chaque maillon de la chane informationnelle de la prise de la commande,
lapprovisionnement et la production, il faut avoir un rfrentiel fiable de donnes commun.
Les technologies de linformation, notamment dans le domaine des rseaux et des bases de
donnes, offrent des opportunits permettant aux entreprises de se diffrencier, de crer de
nouveaux services, de capter de nouveaux marchs. Certes le stratgique daujourdhui deviendra
loprationnel de demain, mais les entreprises qui ont cette vision stratgique dveloppent des
positions dominantes.
Attention, cependant une mise en place des SI, notamment des ERP peut tourner au cauchemar car
il existe des risques rels de drapage en termes de cots et de dlais, dus parfois une sousestimation de la charge, tant pour llaboration du volet technique (paramtrage) que pour celle du
volet organisationnel (analyse des processus de lentreprise et des pratiques mtier) ou celle de sa
migration de donnes car daprs une tude qui a t ralise par the Standish group :

Plus de 80% des projets d'intgration de donnes chouent ou dbordent,


la moiti des projets excdent le planning de trois quarts,
les budgets excdent de deux tiers,
1/3 dentre eux chouent entirement.

MSIR

Page 11/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Les entreprises qui investissent des moyens financiers et humains considrables pour dployer des
applications intgres, savent quel point dplacer massivement les donnes dune unit centrale
(mainframe) ou dautres sources est un parcours sem dembches, impliquant des transformations
et des conversions complexes ainsi des oprations de nettoyage et de validation de donnes.
Malgr ces dpenses et ces efforts, nombre de solutions ont encore aujourdhui du mal tenir leurs
promesses. Il est indispensable de comprendre que la valeur dun ERP, de mme que celle dune
solution de Supply Chain Management (SCM ou en franais GCL, gestion de la chane logistique)
ou de Business Intelligence (BI ou en franais informatique dcisionnelle), dpend principalement
de la qualit des donnes qui lalimentent. Le fait que les clients cherchent aller toujours plus
loin dans lintgration de leurs activits et de leurs processus mtiers impose aujourdhui des
niveaux indits de qualit des donnes. La haute qualit des donnes de rfrence est essentielle
afin de garantir lefficacit des changes de donnes entre les entits rgionales dune mme
entreprise, ainsi quavec et entre les fabricants, fournisseurs et distributeurs de lentreprise.
De nombreuses tudes ont montr quune prparation et une planification insuffisantes des
migrations de donnes pouvaient gravement pnaliser les projets dimplmentation de logiciels.
Pour russir limplmentation des applications dentreprise, une approche rigoureuse de la
migration de donnes est indispensable. La migration de donnes ne consiste pas simplement
transfrer les donnes mais, il sagit de faire en sorte quune fois transfres, ces donnes soient
exploitables.
La migration de donnes nest donc pas une mince affaire, do la ncessit absolue de bien
matriser son projet de migration de donnes.
Au cours de la prsente thse, nous conduisons ltude des facteurs de russite dun projet de
migration de donnes dans les entreprises. Cette tude est applique sur le cas du projet DeBiere.
Nous prsenterons dabord la socit DeBiere cest--dire que nous dcrirons le contexte du projet
DeBiere. Ensuite nous essayerons de comprendre ce quest la migration de donnes dans sa
globalit avant dexpliquer comment elle est ralise dans SAP. Nous rpondrons cette
problmatique par lanalyse du projet DeBiere et en faisant des recommandations en vue de
minimiser les risques des projets dintgration de donnes.

MSIR

Page 12/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

1. Prsentation du groupe DeBiere2


Dans ce chapitre nous parlerons de lentreprise DeBiere, son histoire, ses diffrentes acquisitions
et fusions, son organisation afin de mieux comprendre pourquoi lentreprise a choisi de migrer ses
applications vers un nouveau systme dinformation commun, ce qui induit une migration des
donnes vers ce nouveau systme. Nous terminerons ce chapitre en expliquant les vritables
objectifs et enjeux de ce projet dimplmentation. Lintrt de ce chapitre rside dans le fait quil
nous donne des indications sur la taille du projet de migration de donnes de par la taille de
lentreprise et de ses activits dans le monde, sur son importance aussi notamment celle de la
qualit des donnes chez DeBiere puisque nous verrons que cette entreprise a une vritable
ambition, devenir la meilleure.

1.1 Prsentation gnrale


Le groupe DeBiere est le premier brasseur mondial en termes de volumes, avec des positions
leaders en Amrique, Europe et Asie. DeBiere est une entreprise cote en bourse dont le sige
social est bas Louvain (Leuven) en Belgique. Elle a ralis en 2006 un chiffre daffaires net de
13.3 milliards d'euros.
Forte dun portefeuille de plus de 200 marques dont 4 marques mondiales vedettes : Stella
Artois, Becks, Brahma et Leffe, DeBiere dtient 14% du march brassicole mondial avec
246,5 millions dhectolitres par an.

Figure 1.1 Les 4 produits vedettes DeBiere : Stella Artois, Brahma, Becks et Leffe.

Le nom de la socit a t chang en DeBiere

MSIR

Page 13/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le groupe DeBiere emploie prs de 88 000 collaborateurs et dploie ses activits dans plus de 130
pays sur le continent amricain, en Europe et dans la zone Asie-Pacifique.
DeBiere a cr des chanes de bars et brasseries pour vendre directement ses produits : en France,
elle reprsente 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 nest quen
1987, lors de la fusion des brasseries belges Artois (Louvain) et Piedboeuf (Jupiller), que
lentreprise pris le nom dInterbrew, The Worlds Local Brewer .
Ds lors, le groupe cherche avant tout souvrir vers linternational. Les acquisitions senchanent
avec en 1991, la 1re acquisition trangre dInterbrew : la brasserie Borsodi (Hongrie). Puis ce
premier investissement signe ainsi lentre dInterbrew sur le march de la bire en Europe
centrale. Puis en 1995 lentre du groupe sur le continent Nord Amricain avec lacquisition de la
Brasserie Labatt au Canada et en 1999 Interbrew souvre au march russe avec Sun Interbrew.
En 2000 et 2001, Interbrew simplante respectivement au Royaume Uni avec les acquisitions de
Whitbread et Bass et en Allemagne avec les marques Becks et Diebels.
La puissance du groupe saccentue au fil des acquisitions mais Interbrew ne compte pas sarrter
en chemin et poursuit son ascension avec ses implantations en Chine en 2002 grce sa
participation dans KK Brewery et son partenariat avec la brasserie Zhujiang.
En 2003, le groupe dcide de consolider sa position sur des marchs cls tels que la Chine
(acquisition de Lion Group Breweries) ou lAllemagne (acquisition de Spaten). Interbew devient
alors numro 3 en Chine et numro 2 en Allemagne avec des marques sur tous les segments.
En 2004, Interbrew, troisime brasseur mondial en volume, et AmBev (Companhia de Bebidas das
Americas), entreprise brsilienne et cinquime brasseur mondial, dont les origines remontent
1885, sassocient pour crer DeBiere, le plus grand brasseur du monde en termes de volume.
Cette anne-l, le groupe DeBiere a vendu 202 millions dhectolitres de bire et 31,5 millions
dhectolitres de soft drinks.
Aujourdhui, la stratgie de DeBiere consiste renforcer ses plates-formes locales par
l'tablissement de positions solides sur les principaux marchs brassicoles du monde. La
croissance organique, l'efficacit de classe mondiale, la croissance externe cible et la priorit
donne ses consommateurs en sont les instruments.
MSIR

Page 14/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le groupe dispose dsormais dune plate-forme mondiale et de 14% de part de march travers le
monde, grce un dploiement de ses activits dans plus de 30 pays sur le continent amricain, en
Europe et dans la zone Asie-Pacifique.
DeBiere, class n1 ou n2 dans plus de 20 marchs brassicoles cls travers le monde entier, est
ambitieux puisque aujourdhui 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 ninsisterons pas sur lorganisation mais nous dirons simplement que les activits de
DeBiere sont organises en cinq zones gographiques : Amrique du Nord, Amrique latine,
Europe de lOuest, Europe centrale et de lEst et Asie-Pacifique. Chaque zone est dirige par un
prsident de zone qui sige galement lExecutive Board of Management (EBM). LExecutive
Board of Management (EBM) est lorgane de gestion international de DeBiere. Cette quipe aux
comptences trs complmentaires donne la socit des aptitudes de leadership dans tous les
aspects de son activit.
Les membres de lEBM sont issus dAmBev et de lancienne Interbrew. LEBM a jou un rle
dcisif dans lintgration 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 defficacit
de consolider tous ses diffrents systmes. Nous allons voir que cette entreprise ne cherche pas
seulement runir tous ses diffrents systmes par commodit mais que cela rpond une
vritable ambition et une relle vision.

1.4 Mission, Vision & Valeurs de DeBiere

MSIR

Page 15/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Cette partie nous aidera comprendre les vritables ambitions du groupe DeBiere.
1.4.1

Mission

Toujours plus forte, DeBiere a la volont de dvelopper des liens durables avec les
consommateurs en leur proposant des marques ainsi que des expriences qui fdrent et qui
rassemblent.
Au cur de tout ce que DeBiere entreprend, le consommateur fait partie intgrante de lactivit de
lentreprise, qui, quotidiennement identifie les possibilits dinnovation pour y donner suite avec
dtermination.
1.4.2

Vision

Afin dexploiter pleinement le potentiel de chaque brasserie, DeBiere prend conscience de la


ncessit dharmoniser lensemble de ses activits brassicoles, toutes zones confondues. Il fallait
trancher entre lautonomie et lharmonisation.
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,
une croissance du chiffre d'affaires devanant les volumes,
s'assurer que les augmentations de cots reste en dessous de l'inflation.
Devenir le meilleur est lengagement de DeBiere et cela reprsente un dfi permanent. Il implique
de fixer constamment de nouveaux objectifs pour btir une entreprise qui gnre de la croissance
et des rsultats durables long terme.
Cest dans ce contexte que sinscrit le projet dimplmentation SAP qui doit aussi aider DeBiere
rpondre un autre dfi : tablir des liens durables avec les consommateurs en proposant des
marques et des expriences qui rassemblent les gens.
Pour terminer sur la prsentation gnrale nous en ferons un bref rsum en donnant quelques
chiffres cls sur DeBiere et en montrant son positionnement face ses concurrents directs.
MSIR

Page 16/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Cration : 2004 (fusion entre Interbrew et AmBev)


Sige Social : Louvain, Belgique
Secteur dactivits : Brasserie
Chiffre daffaires : 13,3 milliard (2006)
Effectif : 88.000
Produits : Bire, lager3 et soda
Produits vedettes : Stella Artois, Brahma, Becks et Leffe.
Personne-cl : Carlos Brito (CEO)
Vente / an : 246,5 millions hl / an
Parts de march : 14%
Tableau 1.1 : Quelques chiffres cls de DeBiere

La figure ci-dessous nous indique le positionnement de DeBiere sur le march mondial


(concurrents directs, part de march)

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. Lobjectif principal de cette entreprise, est certes dtre toujours le leader en
terme de volume mais aussi dtre le meilleur do sa vision Passer du Plus Grand au Meilleur From Biggest to Best ! .

1.5 Le projet OMEGA de DeBiere

On appelle lager l'ensemble des bires fermentation basse.

MSIR

Page 17/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

La migration de donnes qui constitue la base de notre tude sinscrit dans le cadre du projet
dimplmentation OMEGA de DeBiere cest pour cela que nous allons dcrire, dans cette partie,
ce projet OMEGA pour mieux comprendre le contexte dans lequel DeBiere a choisi
dimplmenter un nouveau systme dinformation pour toutes ses filiales et par consquent de
migrer ses donnes vers ce systme.
Omega est un projet dimplmentation pour lEurope occidentale qui touchera par la suite chaque
employ de DeBiere dans la zone europe. Le vrai objectif d'Omega est de changer
fondamentalement la manire de DeBiere de faire des affaires. Les objectifs du programme
OMEGA visent, principalement donner DeBiere un avantage concurrentiel (pouvoir rpondre
rapidement sur un march concurrentiel et dynamique ; par exemple intgrer rapidement les
nouvelles acquisitions), rduire leur base de cot (ZBB - Zero Base Budgeting) car en ayant des
manires communes de travailler, DeBiere veut rduire ses cots de maintenance ; par exemple
mettre en place un systme commun tous, et enfin travailler dans la transparence (les
meilleures entreprises au monde ont un KPI (Key Performance Indicator - Paramtre qui se veut
le plus reprsentatif d'une activit de l'entreprise et qui permet d'valuer la performance globale
de cette dernire 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 units d'affaires : BeNeFraLux,
GISE et UK&I. C'taient des entreprises l'origine indpendantes rassembles par le programme
d'acquisition d'Interbrew. Chacune possdant ses propres systme dinformation et processus.
Lquipe centrale (quipe core), dont je faisais partie tait base Leuven, en Belgique, pour la
phase de conception et la premire implmentation. Ensuite nous avons t temporairement
affects dans les pays au fur et mesure des implmentations, pour assister les quipes locales lors
de la mise en production des donnes.

Le projet Omega est un investissement de 100 millions deuros o travailleront plus de 100
personnes directement. Cest un projet qui devra durer 5 ans pour tre complet comme le montre la
figure ci-dessous :
MSIR

Page 18/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Main Assumptions
Criteria
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).

Tentative Deployment Roadmap

Implementation
UK

Implementation
Germany & ISE

Implementation
Luxembourg
Implementation
Belgium

Implementation
Netherlands

Implementation
France

Template
Phase

Implementation
Russia

Implementation
Ukraine

Sept 05

Jan 06

May 06

Business Season

Sept 06

Jan 07

Implementation Implementation
Serbia Montenegro
Croatia

Implementation
Romania

May 07

Sept 07

Jan 08

Implementation
Czech Republic

May 08

Sept 08

Jan 09

Implementation
Hungary

Implementation
Bulgaria

May 09

Sept 09

Jan 10

May 10

Copyright 2005 Accenture All Rights Reserved.

Tableau 1.2 : Planning de dmarrage par pays

Ce planning a t mis jour suite au report dans le dmarrage de certains pays comme les deux
pays pilotes qui nous ont servi pour cette tude, le Luxembourg et lUkraine.
Il y a plusieurs phases au programme dimplmentation. Pendant la phase de conception, en 2005,
les processus et les systmes principaux seront remodels pour la zone Europe occidentale.
Ensuite de 2006 la fin de 2010 cette conception sera mise en application pour toutes les units de
l'Europe occidentale, par une approche par tapes (phase d'excution ou de dploiement)
Lenjeu pour la migration de donnes dans ce projet OMEGA est de taille car il sagit dassurer la
reprise des donnes (extraction, transformation et chargement dans SAP) de 6 domaines
fonctionnels dans un dlai de 6 mois pour les 2 sites pilotes Luxembourg et Ukraine avec laide de
lintgrateur Accenture.
Le primtre fonctionnel pour la reprise des donnes comprend les modules suivants de SAP :
finance (la gestion comptable et financire), commercial et logistique (ladministration des ventes,

MSIR

Page 19/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

la logistique, le transport,...), la gestion des achats, la gestion de la production, la gestion des


stocks.

Les domaines concerns par la migration chez DeBiere

Material Master

Procurement

Manufacturing

Supply Chain

Finance

Commercial

Migration de donnes

Figure 1.3 : La migration de donnes intgre aux processus mtier

Ensuite le primtre gographique pour la reprise des donnes concernera la maison mre
(Belgique) ainsi que toutes les filiales de la zone Europe (France, Angleterre, Allemagne,
Russie,..).
La typologie comportait des donnes statiques (rfrentiels clients et fournisseurs, donnes
comptables de rfrence...) et des donnes dynamiques (stocks, donnes comptables lies aux
donnes logistiques, etc..). Dans lorganisation adopte, DeBiere avait en charge la fiabilisation
des donnes sources et leur extraction, Accenture assurant ensuite la transcodification et
lintgration dans SAP.
Une premire tape a consist dfinir pour chaque domaine fonctionnel, les donnes sources
migrer vers SAP puis, en fonction des donnes demandes par les processus SAP, les champs et
les rgles de transformation ncessaires.
Ainsi, nous allons voir dans le prochain chapitre comment seffectue la migration et quels sont les
lments importants lors dune migration de donnes.

MSIR

Page 20/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

2. Migrer des donnes

MSIR

Page 21/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Lobjet de notre tude tant la migration de donnes, il est ncessaire de sentendre sur les
terminologies de donnes et de migration. Nous essayerons dans ce chapitre de donner une
dfinition du mot donne et de migration avant de nous intresser au contexte global de migration
cest--dire essayer de rpondre la question pourquoi migrer des donnes ?

2.1 Dfinitions
2.1.1

Quest-ce quune donne ?

Une donne est une information de nature numrique ou alphanumrique, reprsente sous forme
code en vue d'y tre enregistre, traite, conserve et communique et qui est exploitable par la
machine.
Les donnes constituent une ressource cruciale pour lentreprise, cest un actif stratgique. Elles
sont essentielles toute implmentation car elles constituent la base de tout document. Delles
dpendent la qualit des prestations, la fluidit des process, la fiabilit des indicateurs.
Elles constituent un facteur clef de la russite du projet de systme dinformation. Autour des
donnes plusieurs mtiers et outils se sont dvelopps : nettoyage de donnes (data cleaning),
entrept de donnes (data warehousing), extraction de donnes (data mining), gestion des donnes
matres (master data management).
2.1.2

Quest-ce quune migration de donnes ?

Dans The Horrible World Of Data Migration Tony Rodriguez dfinissait ainsi la Migration
de Donnes :
La Migration de donnes est le processus complexe entrepris pour permettre des donnes
existantes d'tre employes par une nouvelle application.
Une autre dfinition proche de celle de Tony Rodriguez : La migration de donnes dsigne le
processus de transfert de volumes (souvent trs vastes) de donnes des systmes existants des
anciens systmes vers de nouveaux systmes. Les systmes existants peuvent tre trs divers,
depuis les infrastructures informatiques personnalises jusqu'aux bases de donnes autonomes, en
passant par les feuilles de calcul.
En rsum nous dirons que la migration de donnes (souvent appele reprise de donnes) consiste
transfrer des donnes de sources disparates, profiler, nettoyer, normaliser, transformer

MSIR

Page 22/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

(conversion) celles-ci afin quelles soient conformes aux normes de la nouvelle application. Le
schma ci-dessous nous donne une illustration pour mieux comprendre ce quest une migration de
donnes :

Figure 2.1 : Schma du processus de reprise des donnes

2.2 Pourquoi migrer des donnes ?

MSIR

Page 23/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

DeBiere a migr ses donnes dans le cadre de son projet dimplmentation du progiciel SAP, qui
avait pour but principalement dharmoniser lensemble de ses activits brassicoles, toutes zones
confondues et dintgrer rapidement ses nouvelles acquisitions. Mais ce nest pas dans le seul cas
de fusion et acquisitions quon est amen migrer des donnes.

Il peut aussi sagir dun

remplacement danciens systmes devenus obsoltes afin dacqurir un avantage concurrentiel,


damliorer la comptitivit ou damliorer le service la clientle.
Le besoin toujours croissant de fournir de nouvelles fonctionnalits 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 donnes depuis leurs anciennes
applications vers les nouvelles.
La migration de donnes s'avre tre une opration incontournable tout projet de mise en place
d'applications mtier et principalement sur des projets de gestion de la relation client.
Le schma ci-dessous permet dillustrer des cas o on est amen migrer des donnes.

Figure 2.2 : Le contexte de la migration de donnes

Il est certes important de comprendre pourquoi on migre des donnes mais cest encore mieux de
russir sa migration et le choix des outils est un lment qui participe la russite du projet de
migration de donnes.

2.3 Produits & March

MSIR

Page 24/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Nous avons voulu dvelopper cette partie car pour migrer des donnes, il existe une panoplie
doutils et de solutions sur le march et lon narrive pas toujours faire un choix adquat or
comme nous lavons dit prcdemment, 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 donnes vers une autre dont lobjectif est dintgrer les donnes
ncessaires aux traitements. Selon le contexte, on traduira par alimentation , extraction ,
transformation , constitution ou conversion , ces termes tant souvent combins.
A l'origine, les solutions d'ETL sont apparues pour le chargement rgulier de donnes agrges
dans les entrepts de donnes (ou datawarehouse), avant de se diversifier vers les autres domaines
logiciels. Ces solutions sont largement utilises dans le monde bancaire et financier, ainsi que dans
l'industrie.
Elle est fonde sur des connecteurs servant exporter ou importer les donnes dans les
applications (Ex : connecteur Oracle ou SAP...), des transformateurs qui manipulent les donnes
(agrgations, filtres, conversions...), et des mises en correspondance (mappages). Le but est
l'intgration de l'entreprise par ses donnes.
Des technologies complmentaires sont apparues par la suite : l'EAI (Intgration d'applications
d'entreprise), puis l'ESB (Enterprise Service Bus).
Il existe galement des solutions d'ETL de contenu permettant de manipuler des donnes non
structures tels que les dossiers et les documents. Ces solutions sont utilises 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 donnes (GED) vers une autre.
Schmatiquement, cet intergiciel (middleware) commence par extraire les contenus stocks par les
diffrents systmes d'entreprise avant de les transmettre la base de donnes de la plate-forme.
Les outils ETL prsents ici nont pas t utiliss lors de notre tude mais il nous a paru important
de les lister car nous voulions tout simplement faire comprendre ici quils existent. Il est possible
de les utiliser dans le cadre dune migration de donnes.

MSIR

Page 25/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Ci-dessous nous trouverons les outils existants sur le march avec quelques descriptions et
commentaires. Nous navons aucune recommandation particulire faire pour les outils cits cidessous car nous navons pas pu les tester.
Editeur et Solution

Extraction / consolidation de donnes


Positionnement
Connexions natives

Business Object
ActaWorks

Issue du rachat d'Acta, cette


solution se propose de rendre
accessible en "quasi-temps rel"
les donnes les plus souvent
accdes.

Acta tait le fournisseur historique


du premier connecteur SAP.
Partenaire notamment de Siebel,
Peoplesoft et JDEdwards.
Interfaage avec Cognos,
Hyperion, Actuate et Brio.

Ascential Software
DataStage XE

DataStage XE est l'offre


traditionnelle d'Ardent
qu'Informix a rachet dbut 2000
avant qu'Ascential ne la
reprenne son compte lors de
sa prise d'indpendance, tandis
qu'Informix partait chez IBM
avec ses entrepts de donnes.

Plus de 40 connecteurs natifs


vers des sources de donnes,
dont IBM/Informix, Oracle,
Sybase, Teradata et IBM DB2.
Package complet ddi SAP et
la collection de modules
MySAP. Partie analytique : Brio,
Business Objects, SPSS et
Crystal Decisions.

Computer
Associates
DecisionBase

Computer Associates est plus


connu pour ses offres de
scurit, de surveillance et de
gestion d'infrastructures
rseaux/informatiques. Mais son
offre ETL s'avre assez
complte y compris pour
maintenir l'intgrit des
mtadonnes sur toute la chane
de traitement. L'outil ETL
s'appelle Vision : Pursuit.

Connecteurs en direct pour


extraire les donnes en temps
rel depuis SAP, PeopleSoft et
des systmes unit centrale
(mainframe)s. Accs de
nombreuses sources de donnes
dont IBM/Informix, Oracle,
Sybase, IBM DB2, HTML et
fichiers txt.

Cognos
DecisionStream

Ce n'est pas la spcialit de


Cognos, mais l'outil semble
s'tre prouv dans le temps
aprs avoir chang de nom.

Se dit compatible avec 100


sources OLAP, dont SAP BW
(certifi), Hyperion, Informix, SQL
Server 2000 et Sybase...

Data Mirror
Transformation Server

MSIR

Peu connu en France mais


nanmoins prsent, l'diteur
canadien propose la fois une
offre ETL pour extraire et
transformer les donnes, un
ensemble d'outils pour leur
gestion, mais galement une
plate-forme EAI et un "hub" pour
les changes b-to-b.

Page 26/125

Accs natif non ODBC vers


Oracle, IBM DB2, Sybase,
Microsoft SQL Server.
Connecteurs externes vers les
entrepts OLAP propritaires
Hyperion, Cognos, Oracle.

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Extraction standard depuis :


fichiers plats (C et Cobol), Siebel,
les SGBDR, Informix, Teradata,
Oracle Financials, PeopleSoft
HRMS, SAP R3 et BW...
Librairies pour toutes les bases
de donnes ci-dessous, sauf
Hyperion, sur systmes anciens
et plus rcents. Plugins
ETI.Accelerator pour Siebel,
SQL/Teradata et les middleware
MQ (IBM, Tibco...).
Entrepts de donnes : Oracle,
Sybase, Teradata, Hyperion
Essbase, MS SQL Server et IBM
DB2. Prise en charge nouvelle
des formats de donnes : XML,
unit centrale (mainframe), SAP
en natif, binaires, versions
rcentes des SGBDR. En EAI :
Siebel, SAP, support de MQ
Series. Le roadmap prvoit
l'intgration prochaine des
acteurs comme Brio, BO, Cognos
et MicroStrategy.

ETI
ETI.Extract

Parfois cite comme plate-forme


ETL de rfrence par certains
acteurs, mais pas ceux de la
business intelligence,
ETI.Extract fonctionne avec des
librairies pour supporter les
entrepts de donnes et des
plugins additionnels en
prolongement d'applications
prcises.

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 rpute. 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 aggrge plus de
15 algorithmes de datamining
diffrents.

Informatica
PowerCenter 5

L'une des plates-formes


d'extraction / transformation de
donnes les plus compltes et
rpandues. PowerCenter
l'chelle de l'entreprise, et
PowerMart celle du service ou
du dpartement. Informatica
s'est rcemment engag sur le
crneau des applications
analytiques, mais l'offre ETL est
indpendante.

Gamme extrmement vaste de


connecteurs spcifiques aux
sources de donnes pour
consolider tous les principaux
entrepts de donnes. Pour citer
quelques acteurs du CRM
analytique en vrac : Siebel,
Business Objects, Oracle,
Hyperion, Crystal Decisions, Brio,
SAP, Cognos, Peoplesoft, Kana,
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 rcemment l'EAI avec la
cration de sa filiale iWay
Software. Les 2 dernires offres
sont les plus compltes, la
premire se cantonnant
essentiellement du reporting
sans vritable analyse
approfondie.

A travers son outil ETL, I.B.


attaque prs de 80 sources de
donnes. Les connecteurs EAI
d'iWay concernent environ
120 applications selon l'diteur.

Tableau 2.1 : Les principaux diteurs dETL

MSIR

Page 27/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

2.4 La migration de donnes : un projet parallle


Une migration est un sous-projet part entire qui se gre comme tel. Il se mne en parallle avec
le projet de mise en uvre. Il y a bien sr des dpendances entre le planning de cette mise en
uvre et celui de la migration des donnes.
Migrer ne signifie surtout pas faire en sorte que la nouvelle application ressemble le plus possible
lancienne et en reprenne toutes les donnes dans leur moindre dtail. Cela se payerait par
lexplosion des cots, la rigidit du rsultat et en dfinitive linsatisfaction des utilisateurs. Migrer,
cest au contraire sadapter aux diffrences.
Dans un projet dintgration de progiciel, la migration des donnes du systme existant peut
dterminer une grande partie du chemin critique. En particulier, les outils de migration peuvent
reprsenter une partie significative des dveloppements spcifiques.
La migration des donnes est aussi une activit dlicate, dans laquelle il nest pas possible de
sauter les tapes. Or elle est souvent sous-estime, tant par les matres douvrage que par les
intgrateurs. On doit effectuer les vrifications prvues au fur et mesure des oprations de
migration, puis la fin, si celles-ci dmontrent des problmes majeurs, on revient en arrire et on
fixe une nouvelle date pour la mise en production des donnes.
Le schma ci-dessous montre les tapes importantes dans le cycle de conversion des donnes.

MSIR

Page 28/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Figure 2. 3 : Cycle de vie processus de conversion et reprise de donnes

1. Cette phase permet de dtailler et de planifier toutes les oprations de prparation et


dexcution des bascules de donnes. Elle fixe les principaux choix techniques doutils et
darchitecture des reprises de donnes (description des structures de donnes entre et sortie,
description des tables de transcodification, dcoupage en traitements principaux et
ordonnancement de ces traitements).
2. Cette phase permet de dtailler champ par champ les rgles et oprations de transcodification
(rgles dtailles de transcodification enregistrement /champs, description dtaille des tables
de transcodification,..)
Les donnes sources doivent

tre contrles et prpares pour tre aptes aux reprises

automatises, les systmes sources et cibles doivent comporter les environnements de test et
simulation pour permettre le droulement des bascules de test.

MSIR

Page 29/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3. Cette phase a pour objet de raliser et tester tous les composants logiciels des reprises et
conversions de donnes.
Les dveloppements doivent prendre en compte ces contraintes (performances, contrles
effectuer, enchanement des traitements, traitements dcarts etc..).
4. Cette phase a pour objet de conduire la recette des programmes de reprise et de conversion en
vrifiant leur intgrit dans SAP.
Pour garantir une mise en oeuvre fiable de la bascule de donnes, les tests de recette doivent
seffectuer dans le cadre de simulation de bascule de donnes qui, au del de la vrification du bon
fonctionnement du logiciel, permettent de vrifier la fiabilit des donnes et fournissent aux
quipes des possibilits dentranement en vraie grandeur.
5. Cette phase a pour objet de raliser lintgration des reprises de donnes avec le logiciel SAP
qui utilisera ces donnes. Cest un processus de reprise de donnes contrl dans son
droulement complet.
On appelle bascule des donnes rsiduelles la reprise et conversion, aprs le dmarrage, des
donnes dont la prsence sur le systme cible nest pas indispensable aux oprations quotidiennes.
Toutes ces tapes sont importantes et elles doivent tre excutes correctement. Pour chaque tape
un responsable doit tre identifi afin doptimiser les ressources humaines du projet. Il est
indispensable davoir une organisation humaine cohrente en phase avec les objectifs du projet.

2.4.1 Organisation
Dans le cas de la mise en place dun ERP, la migration implique une collaboration entre lquipe
responsable du systme remplac, lquipe de projet du nouveau systme, cest--dire lintgrateur
et les utilisateurs cls (key users ou responsable de domaine fonctionnel) du nouveau systme.
Plus encore que la mise en uvre dun progiciel, la migration des donnes exige la participation
dutilisateurs qui connaissent bien lexistant pour lanalyse des donnes des applications
existantes, les spcifications fines, lamlioration de la qualit des donnes et enfin les contrles
post migration.

MSIR

Page 30/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Ces utilisateurs ne sont pas toujours disponibles. Il faut donc que la composition des quipes et le
rle de chacun soient dfinis clairement, par crit et le plus tt possible. En considrant la figure
2.1 du schma global du processus de reprise des donnes, nous pouvons y montrer comment les
quipes peuvent sy articuler avec le schma ci-dessous :

Figure 2.4 : Equipe de Migration des donnes intgre au processus global de migration

Lquipe de reprise des donnes (gnralement lintgrateur surtout dans le cadre dun projet
ERP) a pour responsabilit le pilotage du chantier reprise (laboration des grandes orientations /
calendriers, arbitrages, en collaboration avec lquipe projet), la coordination et supervision des
travaux de reprise des donnes, le conseil, la production des fichiers, lexamen posteriori des
rapports derreurs produits lissue des chargements.
Le client a la charge de la prparation des donnes (listes de donnes reprendre, collecte des
informations ncessaires la reprise, nettoyage des donnes, ), la saisie manuelle des donnes,
le contrle des donnes, lexploitation systmatique, priori, des rapports de compltude, la
correction de certaines donnes sur la base des rapports derreur retransmis et interprts par
lquipe reprise. Le client via ses responsables de domaine fonctionnels valide les donnes
charges. Ils doivent drouler des flux complets afin de sassurer que les donnes migres
correspondent bien aux besoins de lentreprise.

MSIR

Page 31/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

2.4.2

Stratgies de migration

La stratgie consiste surtout choisir entre la migration globale (big bang) et la migration par
tapes (dmarrage par fonctions, par entits..). La stratgie et les contraintes de mise en oeuvre des
reprises de donnes dpendent de la stratgie de dmarrage du projet. Cest de cette stratgie dont
dpendra lordonnancement des oprations de bascule. Selon la stratgie choisie, il y aura une
incidence forte sur le projet.
La Stratgie Big Bang ou Grand coup permet des oprations manuelles sur les donnes et
pendant le chargement et impose une validation parfaite en amont de la mise en production :
donnes et processus.
La stratgie dmarrage par lots permet de dcouper le dmarrage pour respecter les contraintes
douverture du systme (par rgion, fonctionnalits, ).
La stratgie dmarrage progressif permet douvrir progressivement le systme (ouvrir et
fermer les vannes) et limite les impacts des erreurs sur le processus. Elle impose une volution
constante des outils, ainsi quune automatisation des principaux processus.
Pour la stratgie fil de leau , les utilisateurs saisissent les donnes dans le nouveau systme au
fur et mesure des activits mtiers, il ny a pas doutil dvelopper mais cependant les temps de
saisie sont importants et le risque derreurs est trop grand.
Les scnarios de reprise consistent dterminer ce quon va migrer.
Schmatiquement, il y a trois possibilits, on peut migrer seulement les donnes de base ou les
donnes de base et les donnes variables qui correspondent des vnements non clos au moment
de la migration. Par exemple, on migre les soldes et les factures non encore rgles mais pas les
factures rgles ou enfin les donnes de base, les donnes variables et les historiques dans la limite
dune certaine dure, par exemple les deux derniers exercices comptables.
La premire solution rpond une situation durgence. Elle suppose que lon fasse vivre en
parallle lancien et le nouveau systme jusqu lpuisement naturel de lancien ou jusqu une
autre migration plus complte.
La seconde nest pas entirement satisfaisante puisquil faut continuer utiliser lapplication
antrieure, en mode dgrad, pour accder aux historiques. Des interfaces provisoires avec
lancienne application permettent de pallier cet inconvnient.

MSIR

Page 32/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Migrer tous les historiques nest pas toujours possible. Pour transposer les vnements passs dans
un nouveau systme il faut des conversions souvent trs lourdes.
Bien entendu, des scnarios de reprise de donnes peuvent combiner diffrentes approches.
Chaque scnario se concrtise par un calendrier prcis.
2.4.3

Documentation

Les documents et les procdures constituent notre police dassurance en cas dincident dans un
projet. Il savre donc indispensable de disposer dune documentation prcise sous forme de
protocole de reprise des donnes afin dy tracer les principaux lments ncessaires pour la
migration de donnes (scnario de reprise, risques, organisation, matriel,) afin de prvenir les
risques organisationnels et humains.
En dehors de ce protocole de reprise, il convient de documenter les donnes reprendre par
domaine, les gabarits (fichiers de chargement, fichiers de correspondance, ..), les outils utiliss
pour les reprises (LSMW,..). Il convient aussi dexpliquer comment utiliser les outils de migration
afin de minimiser les pertes de temps et dargent en cas, par exemple, dindisponibilit dun
membre de lquipe.
Il est souvent ncessaire de complter la documentation ou de la mettre jour.
On sattachera aussi disposer particulirement de documents dcrivant les modles de donnes
logiques et physiques, la structure des bases de donnes, le contenu des tables, les volumes de
donnes, les descriptions des donnes.
On sassure aussi de disposer de la documentation des progiciels installer, des principaux
documents de spcification, en particulier les spcifications fonctionnelles et les modles de
donnes, de la documentation et des sources dinformation sur les mthodologies de migration et
les outils daide la migration fournis par les diteurs.

2.4.4

MSIR

La qualit des donnes migres

Page 33/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

<< Un centre de radiographie dun hpital a envoy un bureau metteur une facture impaye, qui
me fut alors adresse. Mais quand je vrifiai mes factures, je constatai que ma compagnie
dassurance lavait dj rgle >>.

<< La banque qui ma prt de largent pour lachat de ma dernire voiture menvoya un courrier
me signifiant que je navais pas satisfait une clause de lassurance. Mon adresse ainsi que le
modle et lanne de ma voiture taient mal libells>>
Faits relats par Thomas Redman dans son livre <<La qualit de donnes lge de linformation>>

Ces deux faits relats par Thomas Redman sont anodins mais bien reprsentatifs de limpact des
donnes de mauvaise qualit.
Manifestement il y a dans ces deux cas un enregistrement de donnes incorrectes. Une simple
erreur peut tre responsable de linsatisfaction des clients, de la perte de revenus court ou long
terme.
Le dfi le plus important auquel toutes les organisations ont faire face est la qualit au sens plein
du terme et particulirement, en ce monde o linformatisation sacclre, la qualit des donnes
devient le premier dfi rsoudre.
Les donnes sont un actif critique de l'entreprise et ce titre doivent faire l'objet d'un contrle au
niveau le plus haut de management. La matrise de la qualit des donnes requiert une matrise des
chanes de valeur de l'information, notamment au sein des grands processus mtier. Ces
comptences appartiennent, de manire naturelle, aux urbanistes des systmes d'Information.
Ce sont les mieux placs pour dfinir et mettre en oeuvre la politique de gestion des donnes.
D'un point de vue organisationnel, il faut dfinir la chane de responsabilit de la qualit des
donnes, le rle et les objectifs de chacun, revoir les processus mtier, identifier les points
risques pour la qualit des donnes, comme les points d'impact de la non qualit et dfinir les
moyens consacrer.
Cela doit rsulter de la dfinition d'une politique de gestion de la qualit des donnes, qui donnera
lieu des audits rguliers.

MSIR

Page 34/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Du point de vue des systmes d'information, l'tablissement d'un dictionnaire des donnes
publiques qui soit un catalogue des modles, des types de donnes et des rgles de capture et de
contrle est un fondement indispensable. Ce dictionnaire doit tre fait avec les utilisateurs pour les
utilisateurs et les informaticiens.
Il faut rhabiliter les fonctions de data manager (responsable de donnes), centraliser
l'administration des donnes de rfrence et mettre en oeuvre des applications ddies la gestion
des donnes qui, non seulement, stockent et distribuent les donnes, mais galement excutent les
traitements qui appliquent les rgles de contrles.
La qualit des donnes doit faire l'objet d'un processus ddi qui ne repose pas uniquement sur des
solutions techniques, mais aussi et surtout sur le savoir-faire des hommes, managers et experts du
mtier.
L'identification et le recensement des bases de donnes existantes dans l'entreprise et des
informations qu'elles contiennent constituent aussi une tape importante. Or dans la plupart des
entreprises, ces bases sont parpilles dans diverses bases de donnes ou fichiers bureautiques. Il
faut les rpertorier mais aussi analyser la qualit des donnes, car la plupart d'entre elles peuvent
s'avrer incompltes, redondantes ou inexactes. Il faut viter la reprise de donnes prsentant un
risque de "pollution".
Pour faire une analyse de la qualit des donnes il faut confronter ce qui est avec ce qui aurait d
tre en recherchant les donnes partiellement ou totalement manquantes, les donnes non
cohrentes ou errones et les moyens de contrle et de rectification (tables de rfrence).
Tout progiciel a sa propre logique interne. Il ne saccommode pas ncessairement des lacunes et
des erreurs dans les donnes que les applications quil remplace tolraient.
Des projets ont eu de relles difficults pour navoir pas voulu ou pas pu amliorer suffisamment
la qualit des donnes.
On spcifie et on ralise les actions ncessaires pour complter et corriger les donnes des
applications migrer.
Lanalyse de la correspondance des donnes constitue la principale tape danalyse. Elle implique
que les spcifications dtailles du nouveau systme soient disponibles. On dtaille les
correspondances entre les donnes du nouveau systme et celles des applications migrer.

MSIR

Page 35/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Lordre dintroduction des donnes dans les tables nest ni compltement impos, ni indiffrent.
On identifie donc aussi les contraintes en ce qui concerne les squences de chargement.
Le nettoyage de donnes (data cleansing) est une opration par laquelle on s'assure que les
donnes d'un fichier sont cohrentes et qu'elles ont t saisies de manire ce qu'elles soient
identifiables, indexables de manire correcte par la suite. Ainsi, on veillera uniformiser les
diffrents formats de codes postaux utiliss en Europe pour permettre leur traitement homogne.
L'opration de nettoyage visera galement liminer les doublons dans un fichier. Tout ceci sera
mis en oeuvre pour mieux qualifier les donnes d'un fichier clients par exemple.
2.4.5

Choix et Spcification des outils

Cette tape consiste choisir la fois les outils gnraux daide la migration des donnes
mettre en oeuvre, les outils raliser spcifiquement ou adapter et le niveau dautomatisation des
oprations de migration atteindre.
La ralisation des outils de migration des donnes le paramtrage, la modification, si ncessaire, et
la qualification doutils logiciels gnraux ou prexistants et enfin la ralisation et la qualification
doutils logiciels spcifiques.
Les outils de migration de donnes sont destins servir une seule fois, mais massivement. Les
consquences des erreurs ventuelles seront difficiles corriger aprs coup pour certaines
donnes. La vrification de ces outils est donc particulirement importante.
Des outils fonctionnellement satisfaisants mais peu performants peuvent provoquer des dures de
traitement rdhibitoires.

2.4.6

Prparation de la mise en uvre

La prparation implique des procdures et des dispositions de scurit, notamment la prise


systmatique de sauvegardes. II faut prparer le droulement de la migration des donnes jusquen
production, en passant par les bascules blanc, faire les vrifications et enfin grer les retours en
arrire ventuels, en cas dincident majeur.

2.5 Les facteurs de risque d'un projet de Migration de donnes

MSIR

Page 36/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Beaucoup de projets se trouvent retards ou bloqus du fait d'une mauvaise valuation


prvisionnelle de la charge de travail que reprsente la reprise et l'intgration des donnes.
La migration de donnes est souvent une opration coteuse et risque car laccs aux donnes
issues de vieux systmes et de systmes existants, ainsi que leur comprhension requiert souvent
des comptences spcifiques, les systmes en place sont souvent mal documents, la migration de
plusieurs systmes implique de rsoudre des problmes de redondance et dincohrence des
donnes et enfin la conception itrative (exprience-apprentissage) aboutit des situations
ingrables et des dlais incompressibles lis lcriture manuelle des lignes de code.
Pour avoir une scurit peu prs totale, il faut utiliser en parallle lancien et le nouveau systme
pendant une courte priode.
Ceci suppose cependant un double travail de la part des utilisateurs et de certains informaticiens,
ce qui est trs difficile organiser en pratique.
Deux circonstances peuvent rendre incontournable cette option cest lorsque le traitement est
essentiel la vie de lentreprise et si et on connat imparfaitement les fonctions et les donnes des
applications qui vont tre remplaces.
Pour rduire les risques, il faut viter les manipulations manuelles et utiliser les mthodes et outils
standards autant que possible et amliorer la qualit des donnes (normalisation des adresses,
suppression des doublons, identification et correction des donnes endommages, suppression des
donnes inutilises).
Il faut aussi oprer une migration transparente (respecter le planning du projet, perturber le moins
possible les actions utilisateurs (continuit de service), reflter les donnes source le plus finement
possible et permettre de tirer parti au mieux des fonctionnalits du nouveau systme) et rduire le
volume de donnes transfrer (archiver sur microfilms, utiliser les anciens systmes pour les
donnes dhistoriques).
Nous avons vu quil existe plusieurs cas de migrations, cependant notre tude sest base sur la
migration de donnes des applications DeBiere vers SAP R/3. Pour mieux comprendre le
processus de migration, nous allons prsenter la technologie SAP R/3 avant de voir, comment la
migration de donnes sy opre.

3.

MSIR

Prsentation de SAP

Page 37/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Dans ce chapitre sera prsente la technologie sur laquelle j'ai travaill tout au long du projet
DeBiere : SAP R/3. Je commence par une prsentation gnrale, puis je fais un peu d'historique
afin de bien comprendre les volutions et les raisons du succs de ce progiciel. Ensuite, j'explique
l'architecture sur laquelle est base le progiciel avant de parler des principes de la base de donnes
chez SAP. Lintrt de ce chapitre sexplique par le fait quil sagit du systme cible, base de notre
tude. Pour comprendre le concept gnral de SAP, il est ncessaire de comprendre son
architecture et surtout les principes de la base de donnes puisquelle en est le pilier central.
La reprsentation ci-dessous de tous les modules R/3, relis les uns aux autres dans le systme
SAP R/3 est connue sous le nom de modle dintgration de R/3.

Figure 3.1 : Modle dintgration 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 Prsentation gnrale de lentreprise SAP

MSIR

Page 38/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

SAP est le nom dune socit allemande qui dite un logiciel phare de gestion intgr (progiciel)
appel R/3 (devenu mySAP ERP en 2003). SAP signifie Systeme, Anwendungen, Produkte in der
Datenverarbeitung (Systme, Applications, Produits de Gestion de Donnes). Cest 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 troisime fournisseur mondial de logiciels.
Etablie Walldorf, Allemagne, SAP est cote sur plusieurs marchs financiers, notamment aux
bourses de Francfort et de New York, sous le symbole "SAP".
La gamme SAP, constitue de produits et services, va de lorganisation 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 possde aujourdhui une multitude de solutions dans tous les domaines de notre socit.
Chaque entreprise peut, partir de cette solution de base, tendre le logiciel selon ses besoins
spcifiques :

Figure 3.2 : Solutions compltes d'industrie

3.2 Historique

MSIR

Page 39/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le 1er avril 1972, cinq anciens employs dIBM fondent SAP pour Systemanalyse und
Programmentwicklung (Systems Analysis and Program Development), Mannheim en
Allemagne. Leur objectif tait de dvelopper et lancer sur le march un logiciel dentreprise
standard qui intgrerait tous les processus mtiers. Lide leur est venue suite leurs travaux de
consultants systmes pour IBM, lorsquils ont not que leurs clients dveloppaient tous des
programmes machine sensiblement identiques. La seconde partie de leur objectif tait que les
donnes soient traites de faon interactive et en temps rel. Lcran dordinateur deviendrait ainsi
le point focal de la gestion des donnes dentreprise.
En vingt-cinq ans, ils ont fait dune petite entreprise rgionale, une compagnie internationale de
classe mondiale. Aujourdhui, le groupe SAP est le leader incontestable sur le march des
progiciels de gestion possdant 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 tmoigne le tableau ci-dessous qui nous montre ses parts de march :

Tableau 3.1 : Part de march en 2005 des diteurs dERP en France (Source PAC)

Pour mieux comprendre le dveloppement de SAP depuis sa cration, nous avons rsum les
vnements cls sous forme de tableau ci-dessous plutt quun long discours :

MSIR

Page 40/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Tableau 3.2 : Les dates cls du dveloppement de SAP

MSIR

Page 41/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Il existe plusieurs solutions qui sont dveloppes et qui se dclinent selon les spcificits
sectorielles de plus de 25 secteurs dactivit. Elles sappuient sur la plate-forme technologique et
dintgration SAP NetWeaver.
Pour finir cette partie concernant la prsentation gnrale de lentreprise, nous avons fait un bref
rsum pour avoir un aperu global de lentreprise SAP :
Cration : 1972
Sige Social : Walldorf, Allemagne
Secteur dactivits : Informatique, Progiciel
Chiffre daffaires : ~9,5 milliards (2006)
Effectif : ~42.000 dans + de 50 pays
Produit phare : SAP R/3 (rebaptis SAP ERP depuis 2007)
Produits : SAP ERP, SAP Business Suite, SAP NetWeaver, SAP Business One, SAP All-InOne, SAP AS1
Nombre dinstallations : ~121.000
Personne-cl : Henning Kagermann (CEO)
Nombre clients : ~41.000 clients dans 120 pays
Parts de march : 43% (en 2005)

Tableau 3.3 : Quelques chiffres cls de SAP

MSIR

Page 42/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.3 Prsentation de SAP R/3


3.3.1

Vue Fonctionnelle

R/3 est un progiciel destin optimiser les processus de gestion dune entreprise. II est compos
dapplications standard et couvre trois grands domaines : la Finance, la Logistique et la Gestion du
Personnel. Pour chacun dentre eux, R/3 offre des fonctionnalits compltes qui permettent
lentreprise de reproduire lensemble des flux de valeurs et de marchandises.
Le systme R/3 bnficie dune technologie parmi les plus avances. Conu de manire globale, il
permet une mise en oeuvre modulaire et progressive. Sa souplesse lamne sadapter aux besoins
spcifiques de chaque entreprise.
On peut distinguer dans SAP, 3 familles de modules fonctionnels : la logistique, la finance et les
ressources humaines :
Logistique
 Module MM (Material Management)
Le module MM concerne la gestion des articles dun 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 ladministration des ventes.


Autres modules (QM Gestion de la qualit, PM Gestion de la maintenance)

Finance
 Module FI (FinanciaI)
Le module FI contient toutes les critures des ventes et achats, lesquelles se
dversent dans la comptabilit gnrale 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.

MSIR

Page 43/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

 Autres modules (TR : Trsorerie, Gestion financire (gestion des flux de


trsorerie, gestion des paiements) / IM : Gestion des Investissements financiers))

Ressources Humaines
 Module HR (Human Resources) (Donnes de base personnelles, Suivi du temps de
travail, Suivi des carrires, Suivi des frais de dplacement, Gestion de la paie)

3.3.2 Vue Organisationnelle


Lentreprise peut avoir comme activits la gestion des achats, ladministration des ventes, la
gestion des stocks, la gestion de la production, la comptabilit analytique.
Les principales units structurelles SAP sont le mandant, la socit, lorganisation commerciale,
lorganisation dachat et la division comme le montre la figure ci-dessous :

Figure 3.3 : Principales units structurelles SAP


Reprsentation dune entreprise dans SAP

MSIR

Page 44/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le mandant est un regroupement dunits lgales, structurelles, commerciales et/ou


administratives avec un objectif commun. Il reprsente un groupe international avec une gestion
de bilan consolid. Sur une mme machine, chaque mandant est autonome et identifi par un
numro et chaque mandant possde son propre plan comptable.
La base de donnes est inter-mandants, mais les donnes dpendent du mandant et aussi chaque
mandant possde son propre paramtrage (customizing). Les programmes sont inter-mandants.
La socit reprsente une entit, au sein du mandant, disposant de son propre bilan et cre son
propre compte de rsultat. Cest le niveau de la gestion comptable des flux financiers de
lentreprise. Exemple : une socit, une filiale.
Elle est lie un mandant et les donnes sont mmorises par socit. Les plans comptables, les
types de documents, les cls de comptabilisation, les codes mouvement sont communs toutes les
socits dun mme mandant

Lorganisation commerciale (ou des ventes) reprsente une unit structurelle responsable de la
ngociation et des ventes de biens et services.
Lorganisation dachats reprsente une unit structurelle responsable de la ngociation et de
lapprovisionnement des biens et services pour une ou plusieurs divisions.
La division reprsente, au sein dune socit, une Business Unit cest--dire un site oprationnel,
sans comptabilit propre qui peut tre valorise ou non.
Exemple : site, tablissement, succursale, un domaine de comptabilisation, unit logistique.
Cest le niveau de gestion.
Le magasin reprsente, au sein dune division, un regroupement darticles qui suivent des rgles
communes qui peuvent prendre en compte les notions de site, emplacement, nature (produits
finis, matires premires, ...), comptabilisation, ligne de produit, proprit, et dont les entres et les
sorties gnrent des critures comptables. Cest le niveau de gestion physique des stocks.

MSIR

Page 45/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.4 Architecture du systme SAP R/3


Il est intressant de connatre larchitecture du systme SAP R/3 pour savoir si cest une
architecture ouverte qui permet lintgration facile de produits complmentaires tels que des
applications Internet ou sil sinterface avec dautres outils de migration de donnes.
R/3 signifie Runtime System Three. Il est constitu dun ensemble dapplications mtiers conues
pour un environnement client/serveur. R/3 a t dvelopp partir du systme SAP original R/2
qui tait fond sur une unit centrale. Larchitecture de R/3 permet la rpartition de la charge de
traitement (prsentation, logique de lapplication et gestion des donnes) entre plusieurs
ordinateurs relis entre eux par un rseau (voir Figure 1.1).

Serveur de base
de donnes

Serveur
dapplication

Systme de prsentation

Figure 3.4 Larchitecture du systme SAP R/3 comprend des serveurs de bases de donnes, des serveurs
dapplications et des systmes de prsentation.

MSIR

Page 46/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.4.1

Environnement client/serveur

Le concept de lenvironnement client/serveur est devenu trs commun, cest actuellement un


standard dans la mise en place de tout type darchitecture de communication informatique.
Dans un environnement client/serveur, le client (un ordinateur individuel ou une station de travail)
demande une information (grce une connexion) la machine mettrice, appele serveur. La
communication et lchange de donnes entre les machines est appele relation client/serveur.
Stations de travail

Imprimante laser
Serveur de base
de donnes

Porte de communication
Serveur de fichiers

Serveur dapplication

Stations de travail distantes loignes

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

Dans cet exemple, un ordinateur central contient la base de donnes, cest le serveur base de
donnes. La base de donnes est lendroit o les donnes sont stockes. Le serveur dapplications
est charg des fonctions administratives du systme. Cela inclut les processus darrire-plan,
limpression (requtes spool) et le processus de gestion des requtes. Les serveurs applications
multiples existent galement dans cette version de SAP.

MSIR

Page 47/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.4.2

La hirarchie trois niveaux

Larchitecture du systme SAP R/3 est une hirarchie 3 niveaux : une architecture client/serveur
dans laquelle la structure des systmes de logiciels est rpartie sur 3 niveaux : le niveau interface
de lutilisateur, le niveau de logique mtier, le niveau de la base de donnes comme le montre la
figure ci-dessous :

Figure 3.6 : Larchitecture 3 niveaux est devenue le concept architectural standard des installations SAP R/3

La capacit dintgration de SAP est un des lments cls qui lui permettent de se diffrencier des
autres applications dentreprise. Cette intgration offre un environnement mtier fond sur la
connexion, qui stend du domaine des Finances et des Ressources Humaines la Fabrication et
la Distribution.
Dans SAP intgration signifie que tous les processus mtiers de lentreprise sont apparents et
relis les uns aux autres, de sorte quune modification dans un domaine se rpercutera sur les
autres domaines. A titre dexemple, les calculs de disponibilits du module Ressources humaines
peuvent tre lis aux comptes du Grand Livre, dans le module Finances.
Une transaction SAP R/3 est un processus logique interne au systme R/3, cest--dire une unit
au contenu explicite. Crer un nouveau client, gnrer une liste des clients dj existants, effectuer
un ordre ou excuter un programme, sont des exemples de transactions.

MSIR

Page 48/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le SGBDR (Systme de Gestion de Base de Donnes Relationnelle) est stock sur une seule
machine physique. Cest ce niveau que seffectue la gestion du dictionnaire physique de
donnes, cest--dire laccs aux donnes, la mise jour physique de celles-ci et leur validation.
Pendant une transaction, les donnes sont stockes dans un tampon (buffer) et cest seulement en
fin de transaction que la mise jour physique est effectue. On dit alors que la validation des
donnes seffectue par blocs.
3.4.3

Interfaage avec les systmes extrieurs

SAP sinterface facilement avec dautres systmes externes par le biais de techniques que nous
dvelopperons ci-dessous :

Figure 3.7 : SAP sinterface avec plusieurs systmes

Interfaage CPIC (Commun Programming Interface Communication) est un protocole de


communication qui permet lenvoi de messages ou de donnes en synchrone sur un autre systme.
Lensemble des instructions du protocole peut tre utilis dans un programme ABAP (Advanced
Business Application Programming (processeur gnrique pour la prparation de rapport).

MSIR

Page 49/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Interfaage RFC (Remote Function Call) : ce sont des fonctions SAP que lon peut appeler en
temps rel depuis un systme distant (SAP ou autre) permettant de raliser des interfaces
synchrone. Exemples dapplications : SAP/Internet, SAP/Lotus Notes, SAP/SAP, etc.
Interfaage BAPIs (Business Application Programming Interface) qui est une fonction standard
SAP oriente objet qui gre un objet de gestion SAP avec ses mthodes. Par exemple un BAPI de
gestion de demande dachat (DA) avec des mthodes de cration, modification et affichage de la
DA. Les BAPIs sont des fonctions RFC appeles en temps rel par des systmes externes.
Interfaage OLE (Object Link and Embedding) permet de piloter des documents MS-OFFICE
(Word, Excel, ..).
Interfaage I-DOCs (Intermediate DOCument) : linterface IDOC est utilise pour des
communications de donnes lectroniques entre diffrents systmes. On met ainsi un processus
transactionnel (commande, facture, ...) sous forme dun message lectronique. LIDOC est envoy
au systme distant via EDI ou ALE.
EDI (Electronic Data Interchange) : cest un change de messages lectroniques entre SAP et des
systmes externes ncessitant un sous-systme EDI traduisant le message IDOC en message
EDIFACT.
ALE (Application Link Enabling) : Echange de donnes de base (fiches articles, comptes
gnraux, ..), de donnes applicatives (commandes, ...) entre systmes SAP.
Interfaage Batch-Input : dans SAP R/3, il nest pas possible de faire des crations et des mises
jour directement sur la base de donnes. Pour intgrer en masse des donnes transactionnelles, on
utilise donc le batch-input qui permet de faire des reprises de donnes depuis un ancien systme.
Interfaage Extraction : lextraction des donnes dans SAP est tout simplement la cration dun
fichier plat unix contenant des donnes extraites du systme.

MSIR

Page 50/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.5

Principes de la base de donnes chez SAP

Pour comprendre le concept gnral de SAP, il est ncessaire de comprendre les principes de la
base de donnes SAP, puisquelle en est le pilier central.
3.5.1

Base de donnes

Une base de donnes est un conteneur qui peut stocker, organiser, extraire et prsenter des
informations. Une base de donnes est essentiellement un systme de classement lectronique qui
peut contenir une grande quantit dinformations organises. Par ailleurs, la base de donnes
simplifie et acclre la performance dun programme informatique durant la slection de donnes.
Une base de donnes est compose de tables, de colonnes (appeles champs) et de lignes (appeles
enregistrements ou donnes). La base de donnes joue un rle essentiel dans le systme SAP R/3.
Elle se trouve dans un ordinateur central et contient toutes les donnes utilises par le systme
SAP R/3. SAP peut utiliser des bases de donnes de diffrents diteurs comme supports pour le
systme.
3.5.2

Structure dune base de donnes

Les structures de la base de donnes sont des groupes de champs internes imbriqus. Les
structures sont actives et dfinies dans le dictionnaire de donnes ABAP/4 (langage de
programmation propritaire, faisant partie de l'ensemble logiciel SAP - 4 pour quatrime
gnration); elles ne contiennent que des donnes temporaires, et ce, uniquement pendant la dure
dexcution dun programme.
Pour diffrencier les structures des tables de la base de donnes, il faut considrer trois critres :

une structure ne contient pas de table associe au dictionnaire de donnes ABAP/4,


une structure ne contient pas de clef primaire,
une structure na pas de proprits techniques telles que classe, taille, catgorie ou
spcification de fonction tampon.

MSIR

Page 51/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

3.5.3

Systme de gestion des bases de donnes relationnel (SGDBR)

La base de donnes de SAP comprend plus de 12.000 tables stockant les informations. Ces tables
sont connectes les unes aux autres par des relations.
Cette connexion de diffrentes tables par des relations est connue sous le nom de Systme de
gestion des bases de donnes relationnel (SGBDR).
Un systme de base de donnes qui stocke des informations ainsi que des relations entre les
donnes dans les tables deux dimensions est appel Systme de gestion des bases de donnes
relationnel (SGBDR). Un des avantages du concept du SGBDR est llimination des redondances.
Pour rsumer nous dirons que le systme SAP R/3 est fond sur un systme de gestion des bases
de donnes relationnel (SGBDR). La base de donnes sert de noyau tous les systmes et modules
R/3.
3.5.4

Bases de donnes supportes par SAP

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

Mtadonnes

Il nous a paru intressant de parler trs rapidement des mtadonnes car ce sont des donnes qui
renseignent sur la nature de certaines autres donnes et qui permettent ainsi leur utilisation
pertinente. Grce elles on peut aussi faire communiquer les bases de donnes classiques, utilises
dans les progiciels de gestion intgrs comme SAP et les donnes non structures (documents,
images, manipuls en gestion des connaissances...).
Dans SAP, les mtadonnes sont dfinies comme des descriptions des structures de donnes
utilises dans les programmes. Les mtadonnes recouvrent ainsi notamment les dfinitions de
tables et de zones, ainsi que les dfinitions des domaines de valeurs acceptables pour chaque zone.
Les relations entre les tables sont enregistres laide de tables de cls externes, qui constituent
des mtadonnes du dictionnaire de donnes actif ABAP/4.

MSIR

Page 52/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Figure 3.8 : Types de donnes SAP

Les mtadonnes sont le plus souvent dcrites comme des donnes au service des autres
donnes . Elles sont stockes et dfinies dans un entrept de donnes central, d'o elles sont
accessibles pour tous. Elles sont indpendantes des applications.
Les mtadonnes dcrivent, entre autres :
la dfinition du contenu (par exemple quest ce quune vente nette)
quels lments d'informations dfinissent des donnes
niveau de priodicit et d'agrgation de collecte de donnes (par exemple mensuellement)
comment et o trouver les donnes (par exemple systmes ERP dans les pays)
autorisation (qui est permis de voir les donnes, les manipulations sur ces donnes...),
3.5.6

Le modle de donnes dentreprise SAP

Le modle est labor partir dunits entits-association dsignant des objets rls de la vie
commerciale, tels que des documents, des messages, des articles ou du personnel. Le terme
association fait ici rfrence des notions telles que celles de possession ou dappartenance.
Une commande comporte par exemple, quand elle est complte, un entte ou plusieurs postes
spcifiant les lments commands et leurs prix.
MSIR

Page 53/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Une association peut dans ce cas tre dcrite de la manire suivante : un poste dune commande
appartient la commande et un en-tte de commande possde un ou plusieurs postes.
Quand une commande est affiche lcran et que loprateur actionne la touche F1, il obtient la
signification commerciale donne par le systme llment slectionn par le curseur. Cette
information est directement drive du modle de donnes dentreprise.
Lutilisateur peut choisir la manire dont le modle de donnes dentreprise va lui tre prsent.
Tous les lments de donnes utiliss pour laborer les vues et les tables virtuelles sont tirs du
dictionnaire de donnes ABAP/4, lutilisateur est assur de la cohrence des donnes et de leur
formatage.
Tous ces lments seront indispensables lorsque nous aborderons la migration de donnes dans
SAP au chapitre suivant.

4.

MSIR

La Migration de donnes dans SAP

Page 54/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Dans cette partie, on distinguera deux types de migrations de donnes : dabord la migration de
donnes dun systme SAP en loccurrence SAP R/2 vers SAP R/3 puis celle dun systme non
SAP vers SAP R/3. Nous ninsisterons pas sur les produits existants sur le march qui peuvent tre
interfacs avec SAP pour aider la migration des donnes mais nous parlerons plutt des outils
SAP disponibles pour migrer les donnes. Nous avons complt le schma global de la migration
de donnes (figure 2.4) : la cible devenant SAP (voir figure ci-dessous) :

Figure 4.1 : La migration de donnes dans SAP

MSIR

Page 55/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

4.1 La Migration de donnes de SAP R/2 vers SAP R/3


Nous traiterons ici plus particulirement les cas o les installations existantes sont des systmes
SAP ncessitant des amliorations, soit par transfert sur une autre configuration de matriel, soit
par acquisition de nouvelles versions du progiciel SAP.

Migration de Donnes
Datenmigration

Figure 4.2 : Comment migrer les donnes de R/2 vers R/3 ?

Le systme SAP R/2 a t dvelopp dans le contexte des architectures unit centrale (mainframe),
qui taient intgres avec des systmes de serveurs ddis des tches spcifiques telles que la
gestion de bases de donnes alors que le systme SAP R/3 a t au contraire conu dans loptique
dune architecture htrogne forme de multiples couches de configurations client-serveur.
Quand les entreprises squipent de nouveaux composants de matriel ou logiciels, ou quand elles
entreprennent une r-ingnierie de leurs processus commerciaux, les socits veulent en gnral
pouvoir continuer exploiter les informations commerciales quelles ont archives ainsi que les
donnes des transactions les plus rcentes.
Lobjectif est alors de transfrer des donnes et ventuellement des fonctions commerciales
personnalises vers le nouveau systme SAP R/3 ou le nouveau module applicatif qui vient dtre
install.
Le processus de migration de donnes mis en oeuvre lors dune implmentation du systme
SAP R/3 mrite de faire lobjet dun plan de projet. Les principales tapes sont la familiarisation
du personnel avec le systme SAP R/3, la dfinition de la stratgie de migration des donnes, la
mise au point dun projet formel dimplmentation du systme SAP R/3 dans lequel est incluse la
phase de migration des donnes, le re-travail des fonctions et processus existant sous SAP R/2, de
sorte quils puissent exploiter les amliorations apportes SAP R/3, la personnalisation complte

MSIR

Page 56/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

du prototype cible du systme SAP R/3, la mise en place des mcanismes qui permettront des
transferts de fichiers haut dbit entre le systme unit centrale (mainframe) SAP R/2 et le
systme SAP R/3 (par exemple par le protocole FTP), la mise en oeuvre de tests de migration des
donnes et vrification des transferts, la mise en oeuvre de tests de volume grande chelle pour
la conversion des donnes, la planification et loptimisation du calendrier darrt du systme
productif et de transfert des donnes et enfin la mise en service du systme SAP R/3.
Le systme SAP R/3 manipule des objets de donnes structurs de plus ou moins complexes. Ces
objets sont accessibles sous la forme dentits uniques. Cest grce lapplication de telles
techniques que le systme SAP R/3 peut tre puissant et flexible sans pour autant monopoliser trop
de ressources informatiques. Le systme SAP R/2 ne manipule pas quant lui les objets de la
mme manire que R/3.
Au cours du processus de migration, les informations dtenues dans les tables SAP R/2 doivent
tre rcupres et insres dans les structures du systme SAP R/3. Les informations sont en fait
transfres sous la forme dun ensemble dobjets de migration dont la structure est dicte par le
contexte commercial, et qui ont t nomms en consquence. Les donnes doivent tre extraites de
la base de donnes de R/2, transfres vers la base de donnes R/3, puis tre rendues disponibles
lensemble du systme SAP R/3.
Les donnes du systme SAP R/2 sont exportes 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 utiliss pour crer ces structures dexportation sont automatiquement gnrs en
temps rel dans le systme SAP R/2. Le systme SAP R/3 gnre de la mme manire des
programmes dimportation qui reoivent et intgrent les structures et leurs objets de donnes. Les
rgles de conversion de la socit cliente sont prises en compte et appliques par les programmes
dimportation.
SAP fournit un outil de migration et des mthodes qui permettent de transfrer des donnes de
SAP R/2 SAP R/3 sous la forme d'un transfert de donnes de cl. Le schma ci-dessous nous
rsume le transfert de donnes de SAP R/2 vers SAP R/3 :

MSIR

Page 57/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

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

Cest le serveur ALE qui convertit le format de donnes et transfert les donnes entre le systme
hte R/2 et les instances R/3.

4.2 La Migration de donnes dun systme non-SAP (legacy system) vers SAP
R/3
Dans ce cas prsent nous avons des installations qui ne sont pas des systmes SAP (legacy system)
et dont les donnes doivent tre migres vers des installations SAP.

Migration de Donnes
Datenmigration
LSMW

Figure 4.4 : Comment migrer les donnes dun systme Legacy vers SAP R/3 ?

Dans le pass, les cots de la migration de donnes ont reprsent jusqu' 20% du cot total d'un
projet de mise en uvre de SAP. Ce cot a t considrablement rduit. Pour ce faire, SAP offre
des outils personnaliss qui rendent plus efficace la migration de donnes.

MSIR

Page 58/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Pour migrer des donnes dun systme non-SAP vers un systme SAP R/3, on utilise
principalement loutil LSMW (Legacy System Migration Workbench ou "Atelier de reprise de
donnes d'anciens systmes").
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 lments de paramtrages et de mise en uvre de la future
installation.

4.2.1

Latelier de reprise de donnes d'anciens systmes (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 donnes.
Outre l'utilisation pour la reprise de donnes telle que prvue l'origine par SAP, LSMW permet
galement la cration et la modification en masse de donnes de faon efficace et trs fiable.
Le Legacy System Migration Workbench est un outil SAP qui peut servir transfrer dans SAP
des donnes des anciens systmes. Il comporte des fonctionnalits de correspondance (mapping) et
de conversion, de mme quun accs possible pour le dveloppement ABAP (Advanced Business
Application Programming (processeur gnrique pour la prparation de rapport) pour le codage
maison.
L'approche est relativement simple : on commence par dfinir les structures de donnes cible et
source. Puis on dfinit la correspondance ou le mapping entre donnes source et cible, c'est-dire des modalits d'intgration des anciennes donnes dans SAP, via des oprations de
transcodification par exemple. Suivent enfin les phases de lecture du fichier source, la conversion
des donnes source sur la base des rgles de correspondance (mapping) dfinies prcdemment et
lintgration des donnes en rel. La figure ci-dessous rsume le fonctionnement du LSMW :

MSIR

Page 59/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Figure 4.5 : Le fonctionnement de LSMW

4.2.2

Diffrentes faons d'utiliser LSMW

Pour reprendre des donnes dans SAP, plusieurs possibilits existent, prsentes ci-dessous.
Dabord utiliser une structure cible propose par SAP, le plus souvent pour les donnes 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 systme pour la rejouer plusieurs fois (Batch Input Recording).
Je voudrais insister sur la dernire mthode, les autres seront dvelopps dans la section 4.3 (voir
plus bas).
Dans la mthode "Batch input recording", SAP va enregistrer les crans (dynpros) dans lesquels

MSIR

Page 60/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

l'utilisateur va passer lors de l'enregistrement. Ensuite, l'utilisateur dfinira, parmi les champs
dtects 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 pralable, est en mesure
d'enregistrer une transaction pour fournir au systme le cheminement des crans par lesquels il
devra passer, et les champs alimenter.
De ce fait, lors de l'tape d'excution, SAP va rejouer autant de fois que ncessaire la transaction
enregistre, sous forme d'un dossier batch-input (cette mthode, mme 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'intrt de ce systme, dj important de base, peut tre grandement accru en
ajoutant quelques lignes d'ABAP pour faciliter la transcodification... en fait, les possibilits de
mapping sont tellement vastes que, la plupart du temps, on extrait les donnes du systme Legacy
pratiquement telles quelles, et on pilote toutes les oprations de manipulation de donnes dans
LSMW.
Ce mode de fonctionnement est tout particulirement adapt de la cration / modification en
masse de donnes (ou de documents) sortant du cadre des structures standard fournies par SAP.

4.2.3

Atouts et limites du LSMW

En bref, voici une synthse des points forts et des limites du LSMW (particulirement dans
l'utilisation en batch-input prsente ci-dessus).

Avantages :
Le LSMW permet une dfinition claire dune structure source et dune structure cible.
Le mapping est trs souple car il existe la possibilit de lenrichir par valeurs fixes,
transcodification ou routine ABAP.
Le mcanisme dexcution de la reprise est squentiel, ce qui permet chaque tape de valider les
donnes (lecture source, conversion, excution).
Il permet de bnficier du retraitement d'erreurs de la gestion des dossiers batch.

MSIR

Page 61/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Limites :
Le LSMW nest pas un outil dextraction du systme Legacy et nest pas non plus un outil
d'export partir de SAP car il fonctionne en import uniquement.
Il permet de reprendre des donnes de base (son utilisation originelle), mais galement de les
modifier en masse ou bien de crer / modifier des documents (commandes SD par exemple), voire
du paramtrage.
Il est compltement transverse dans SAP (pas limit un ou plusieurs modules) et ses limites sont
rduites par rapport aux avantages qu'il procure.
Voyons quelques exemples "rels" d'utilisation de LSMW (liste non exhaustive !) :
reprise d'articles, d'quipements, de gammes, de centres de cots, etc,
reprise facile de plans de comptes (on fournit en entre uniquement le numro de compte et
son libell, tous les paramtres de compte FI tant dfinis dans le LSMW),
cration et ordonnancement de plans d'entretien PM avec rgles complexes,
cration en masse de documents (commandes SD, ordres de service, etc).
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 comptences SAP. En effet
c'est un outil trs puissant mais dot d'une ergonomie simple et utilisable par des consultants
fonctionnels, sans comptences techniques particulires. Il va de soi que possder 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 quil existe, certes moins
puissants, dautres outils et techniques qui nous permettent de migrer des donnes.

4.3 Techniques & Outils de Conversion de donnes 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 lments de paramtrages et de mise en uvre de la future
solution.
Dans le cadre dune migration de donnes, il est frquent quun consultant veuille connatre loutil
de migration de donnes, dun ancien systme un autre, afin de mieux matriser le processus, le
paramtrage ainsi que les dveloppements faire.

MSIR

Page 62/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

4.3.1 Les techniques


Nous exposerons ici les diffrentes techniques existantes dans SAP. Chacune dentre elle a son
importance et sa spcificit. Par exemple, si nous avons des donnes de trs faible volume, il est
plus intressant dutiliser la saisie manuelle des donnes. Si nous voulons mieux grer le
traitement des erreurs, les IDOCs (Intermitted DOCument = document intermdiaire entre deux
systmes) offrent plus de possibilit et si nous avons de trs gros volumes de donnes, nous
pouvons utiliser les entres par lots (direct input) mais la cohrence des donnes pourrait en ptir.

4.3.1.1 Saisie manuelle (Manual Input)


Il sagit ici de la saisie manuelle des donnes.

4.3.1.2 Entre par lots (Batch Input)


Le principe du batch-input consiste programmer la squence des crans d'une transaction, et
remplir les champs avec les donnes d'entre.
La transaction est mule. Tous les contrles standard SAP sont effectus, cela permet une parfaite
cohrence des donnes.
Un dossier batch-input tant cr, il est ais de retraiter les enregistrements errons.

4.3.1.3 Traitement par transaction (Call Transaction)


Sur le mme principe que le batch-input, mais une seule transaction est traite la fois. Il n'y a pas
de dossier cr donc les donnes d'entre restent volatiles et si la transaction n'est pas enregistre
dans SAP (incohrence des donnes), alors les donnes sont perdues.

4.3.1.4 Entre directe (Direct Input)


Le principe consiste alimenter directement les tables SAP partir des donnes d'entre sans
passer par les contrles SAP. Fortement dconseill par SAP pour des raisons de cohrence des
donnes. Cependant la version 4.6 de SAP permettra d'effectuer des Direct Inputs plus scuriss.
4.3.1.5 ALE / IDOC
IDoc = Intermitted DOCument = document intermdiaire entre deux systmes.
Domaines fonctionnels IDOC :
EDI = Echange de Donnes Informatis entre diffrentes socits (partenaires).

MSIR

Page 63/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

ALE = Echange de Donnes Informatis entre diffrents systmes au sein d'une mme socit.
Il faut fournir SAP les donnes d'entre au format IDOC, et SAP gre automatiquement la
cinmatique des crans et les zones renseignes, et fournit une fonctionnalit flux dinformations
(workflow) pour le traitement des erreurs.
Les IDocs sont changs avec les systmes externes en fonction d'un partenaire ou d'un message
spcifique. Les donnes IDoc sont donc dfinies au moyen d'accords d'interchange et de
dfinitions de port.

4.3.2 Les outils


Nous ne listerons ici que les principaux outils standards proposs par SAP. Cependant il en existe
dautres qui sont souvent spcifiques certaines solutions de SAP comme par exemple EMIGALL
(spcifique SAP IS-U), IBIP (spcifique PM), Intergiciel (Middleware) (spcifique CRM),
SAP Query, Quick-viewer (utilisable pour effectuer des contrles quantitatifs aprs reprise).

4.3.2.1 LSMW
Comme vu dans le prcdent chapitre, le LSMW encapsule des programmes dinjection comme
les Batch-Input (soit standard ou spcifique (recording)), Direct Input,
Il permet la lecture des donnes sources, le mapping des structures sources (tables internes) avec
les structures cibles et linjection des donnes dans les structures cibles.
4.3.2.2 Loutil CATT (Computer Aided Test Tool)
Cest un outil initialement conu 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)
Cest une fonction standard SAP oriente objet qui gre un objet de gestion SAP avec ses
mthodes. Par exemple un BAPI de gestion de demande dachat avec des mthodes de cration,
modification et affichage de la demande dachat (DA). Les BAPIs sont des fonctions appeles en
temps rel par des systmes externes.

MSIR

Page 64/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

La connaissance de ces outils et techniques est indispensable si on veut mieux matriser sa


migration de donnes car en fonction des types de donnes certains outils et techniques sont plus
adapts que dautres. Nous avons tenu compte de ces lments lors du projet de migration de
donnes chez DeBiere dcrit dans le prochain chapitre.

MSIR

Page 65/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

5.

Analyse du projet de Migration de donnes chez DeBiere

Dans ce chapitre, nous commencerons par prsenter le contexte et le principal enjeu de la


migration de donnes chez DeBiere, ensuite nous verrons quelle a t lapproche pour ce projet de
reprise. Les principaux risques, la qualit des donnes et la stratgie adopte seront aussi abords
dans ce chapitre.

5.1 Contexte et Enjeu


Pour rappel, le projet OMEGA a t mis en place pour dune part rpondre au besoin
dharmonisation des diffrents systmes suite aux nombreuses acquisitions faites par DeBiere et
dautre part pour donner un avantage concurrentiel afin de raliser son principal objectif : Passer
du plus grand au meilleur . Cest dans ce contexte que sest inscrit le projet de migration dans
SAP et par consquent le projet de migration de donnes dans SAP.
Le groupe choisit le progiciel SAP qui bnficie de plusieurs atouts parce quil permet dintgrer
les fonctionnalits et les donnes des entreprises dans un systme unique dune part et dautre part
parce quil est leader sur le march des progiciels de gestion intgre.
Lenjeu est de taille car il sagit dassurer la reprise des donnes (extraction, transformation et
chargement dans SAP) de 6 domaines fonctionnels dans un dlai de 6 mois pour les 2 sites pilotes
Luxembourg et Ukraine avec laide de lintgrateur Accenture.

5.2 Droulement du projet de migration de donnes


Nous expliquerons ci-dessous le droulement du projet DeBiere notamment notre approche de la
migration de donnes chez DeBiere, lorganisation, la stratgie adopte et tout le processus de
mise en uvre et enfin nous terminerons en faisant un bilan de ce projet de migration des donnes.
5.2.1 Lapproche migration de donnes chez DeBiere
Notre approche de la migration de donnes a consist en 6 tapes dcrites ci-dessous :

01Correspon
dance
(mapping)
donnes

MSIR

02 Extraction
donnes

03 Manipulation
donnes

04 Vrification
donnes

Page 66/125

05 Chargement
donnes

06 Rconciliation
donnes

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

En intgrant cette approche dans le processus gnral de migration dans SAP (figure 4.1), nous
obtenons le schma ci-dessous :

Figure 5.1 : Lapproche migration de donne chez DeBiere intgre au processus global de migration

5.2.1.1 Correspondance des donnes (mapping des donnes)


Le mapping de donnes vise tablir des correspondances entre lancien systme et le nouveau
systme.
Les diffrentes filiales DeBiere oprent sur diffrentes plateformes en utilisant diffrents
technologies et processus. Afin de contrler le transfert de donnes, le mapping des donnes est
ncessaire car il permet de nous assurer que les donnes sont migres l o cest ncessaire.
Pour le mapping de donnes, nous disposions, pour chaque objet de la liste de tous les champs
ncessaires avec leur description fonctionnelle comme par exemple ci-dessous (liste non
exhaustive) :

MSIR

Page 67/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Objet : articles
Groupe

Table

Champs

Description

Type de donne

longueur

MARA

MATNR

Numro darticle

Caractre (CHAR)

18

Vue donnes gnrales de base

MAKT

MAKTX

Description article

Description article

40

Vue donnes gnrales de base

MARA

MEINS

Unit de meseure

Unit de meseure

Vue donnes gnrales de base

MARA

MATKL

Groupe darticle

Groupe darticle

Ancien numro

Ancien numro

Vue donnes gnrales de base

Vue donnes gnrales de base

MARA

BISMT

darticle

darticle

18

Vue comptabilit

MBEW

PEINH

Prix unitaire

Prix unitaire

Vue comptabilit

MBEW

VPRSV

Indicateur prix

Indicateur prix

Vue comptabilit

MBEW

STPRS

Prix standard

Prix standard

12

5.2.1.1 Extraction des donnes


Le processus d'extraction de donnes vise extraire toutes les donnes indispensables du systme
source pour les migrer dans un format prdfini. Puisque les filiales oprent sur des plateformes
diffrentes, il est ncessaire davoir un format commun de fichiers dextraction pour faciliter le
processus de migration. Le format de fichier dpend de loutil de migration cr.
5.2.1.2 Manipulation des donnes
Le processus de manipulation de donnes consiste nettoyer les donnes, les enrichir, les
valider afin davoir les donnes prtes dans le format requis de chargement avec la qualit exige
de donnes.
Plus prcisment, elle consiste au formatage des donnes, llimination des doublons,
laddition des donnes manquantes, la conversion de donnes (utilisation des transcodifications)
et la validation des donnes (rgle de gestion).

5.2.1.3 Vrification des donnes


Le processus de vrification des donnes consiste obtenir la validation des quipes mtier aprs
avoir effectu toutes les manipulations ncessaires sur les donnes et avant le chargement de
celles-ci dans le nouveau systme.
Cette tape est une tape de contrle pour assurer la qualit des donnes. Une liste prcise des
points contrler doit tre effectue avant le chargement.

5.2.1.4 Chargement des donnes

MSIR

Page 68/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Cette tape vise intgrer toutes les donnes extraites dans le systme cible.
Aprs validation des donnes par les quipes mtier, les donnes sont prtes tre intgres dans
le nouveau systme.
Pour avoir un processus de chargement des donnes fiable, il est recommand dviter laltration
des donnes durant le chargement, cest--dire quune fois le fichier de chargement valid, on ne
doit pas y effectuer des modifications avant le chargement.
5.2.1.5 Rconciliation des donnes
Le processus de rconciliation de donnes vise s'assurer que les donnes principales extraites
sont 100% charges dans le systme cible. Cest le second contrle dans le cycle de la migration
des donnes et intervient aprs le chargement. Cette tape est importante car elle permet de
sassurer que le processus de chargement a t correctement excut.
En cas de rejet de certaines donnes lors du chargement, on doit effectuer une analyse des erreurs,
les corriger et refaire valider un nouveau fichier avec uniquement les donnes corriges en vue
dun second chargement.
Nous pouvons rsumer lapproche migration de donnes chez DeBiere par le schma ci-aprs :

MSIR

Page 69/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

04
Vrification
donnes

MDM (Master
Data Management)

Input

Output

02
Extraction
donnes

IMPORT

DONNEES

EXPORT

Formatage
Validation
Contrle des
tables
Vrification
des
doublons

Enrichissement

Format final

C
I
B
L
E

06 Rconciliation donnes

03 Manipulation
donnes

05 Chargement donnes - LSMW

S
O
U
R
C
E

01
Mapping
donnes

Figure 5.2 : Schma global de la migration de donnes chez DeBiere

MDM (Master Data Management) est la plateforme qui nous a permis de manipuler les donnes
aprs extraction des donnes de lancien systme. Il permet de formater les donnes extraites, de
les vrifier, de les enrichir, de supprimer les doublons et enfin de les valider en vue de les charger
dans le nouveau systme. Aprs cela les donnes sont exportes de MDM vers des fichiers texte
ou Excel prts tre intgrs dans SAP R/3 via loutil LSMW.
Jai particip la migration des donnes pour 2 filiales de DeBiere le Luxembourg et lUkraine.
La filiale luxembourgeoise de DeBiere avait dj intgr SAP R/2 (donc une migration de SAP
R/2 vers SAP R/3) et la filiale ukrainienne avait un autre systme qui lui tait propre qui sappelait
EFAS. Pour toutes ses 2 filiales lapproche a t presque la mme cest--dire que les 6 tapes cidessus ont t autant valides pour le Luxembourg que pour lUkraine. Nous avons utilis
principalement loutil LSMW qui est un outil puissant dont nous avions dj parl, pour intgrer
les donnes.

MSIR

Page 70/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

5.2.2 Organisation
Comme dit prcdemment, la migration de donnes exige dune part la participation dutilisateurs
qui connaissent bien lexistant pour lanalyse des donnes, lamlioration de leur qualit et les
contrles post migration et dautre part la participation dexperts pour le formatage des donnes,
lintgration des rgles de gestion tablies, lenrichissement des donnes et leur intgration dans le
nouveau systme.
Nous allons voir ci-dessous lorganisation globale du programme Omega avant dexpliquer
comment tait structure lquipe de migration de donnes.

Figure 5.3 : La structure du projet Omega

Le management du programme tait compos de responsables de la socit DeBiere et du


responsable

Accenture

sur

ce

projet.

Chaque

domaine

fonctionnel

(Procurement,

manufacturing,) tait compos dquipes mixtes DeBiere et Accenture.

MSIR

Page 71/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Lquipe migration de donnes tait organise comme suit :

Equipe locale

Expert
Local - outil
(Intgrateur
)

Equipe centrale (Leuven)

Responsable
des donnes
(DeBiere)

Expert outil
MDM
(Intgrateur)

Chargement
des donnes
(Intgrateur)

Expert SAP
(Reprise de
donnes)
(Intgrateur)

Responsable
des donnes
(DeBiere)

Responsable
fonctionnel
local (par
domaine)
(Intgrateur)

Off-Shore-Ile-Maurice

Equipe
fonctionnelle
(Intgrateur)

Figure 5.4 : Lquipe migration de donnes chez DeBiere

Pour tre plus explicite, Louvain dans lquipe centrale (core team) nous avions une personne
responsable des donnes pour chacun des 6 domaines (manufacturing, finance,..). Cette personne
constituait linterface entre le responsable des donnes local (filiale) et lquipe dintgrateur
dAccenture.
Les 2 responsables des donnes (un de lquipe centrale et un de la filiale) tudient ensemble, en
fonction aussi des dcisions prises avec la direction et avec lassistance de lquipe fonctionnelle
de lintgrateur les donnes extraire. Par exemple les clients qui nont pas command depuis plus
de 2 ans ntaient pas pris en compte.
Aprs cela, lexpert technique local dveloppait des outils ou utilisait les outils standard en vue
dextraire les donnes souhaites. Une fois les donnes extraites, lexpert MDM (Master Data
Management) prend le relais en enrichissant les donnes, en les formatant et en intgrant les rgles
de gestion dfinies auparavant par DeBiere et en utilisant les transcodifications adquates.
Une fois transformes, les donnes sont extraites de MDM dans un fichier texte ou Excel (si les
donnes taient suprieures 65.000, elles taient extraites sur un fichier texte) avant dtre
envoyes lexpert reprise de donnes SAP qui tait mon rle. Certaines transcodifications

MSIR

Page 72/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

ntaient pas faites par loutil MDM (par exemple les units de mesure) et de mme certaines
rgles de gestion ntaient pas intgres par loutil MDM.
Mon rle donc, en tant quexpert reprise de donnes SAP, tait de vrifier dans SAP sil existait
un outil standard pour chaque objet de migration (clients, articles, fournisseurs, etc), auquel cas,
il fallait que je le modifie en vue dintgrer les transcodifications de donnes non faites et
dintgrer aussi certaines rgles de gestion.
Au cas o loutil de migration nexistait pas, il fallait le crer en tenant compte de plusieurs
facteurs comme par exemple la volumtrie des donnes, la rapidit dexcution du programme. Le
choix de la technique de migration ou de loutil tait important puisque par exemple utiliser un
enregistrement (recording) pour une volumtrie de 100.000 donnes tait tout simplement
impensable. On risquait de passer un aprs-midi attendre que les donnes soient charges et aussi
de bloquer une transaction pendant plusieurs heures. Le chargement des donnes tait effectu par
une quipe de 4 personnes, tous dAccenture, qui taient situs en Ile-Maurice. Jtais responsable
des 5 domaines suivants : Manufacturing, Supply Chain, Procurement, Commercial, Material
Master. Un autre expert soccupait spcifiquement de la finance.

5.2.3 Stratgie de migration


La stratgie globale de reprise qui a t utilise est la stratgie par tapes cest--dire que les
donnes sont intgres par filiale.
Au niveau de la reprise de donnes dune filiale, la stratgie de reprise nous a permis de savoir
prcisment comment le travail de reprise de donnes sera construit, dans quel ordre les oprations
vont tre menes pour parvenir atteindre les objectifs dfinis. Par exemple, on ne pouvait pas
migrer les conditions de prix avant davoir migr les clients, les articles ou mme les fournisseurs
car il y avait une dpendance avec ces objets.
Nous avions aussi convenu que pour tous les objets dont le nombre de donnes tait infrieur 50
devaient tre saisies manuellement.
Seules les donnes appropries seront migres donc pas de donnes obsoltes. Le contrle des
doublons est critique dans la migration de donnes : des lments de donnes uniques seront
chargs par objet de donnes. Des commandes de contrle doivent tre intgres dans le processus
de transfert de donnes pour assurer la qualit de donnes.

MSIR

Page 73/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

5.2.4 Documentation
Il sagit dune part de disposer des documents concernant les donnes existantes, les outils
existants et dautre part nous devions documenter tout ce que nous faisions cest--dire
documenter la cration des nouveaux outils, leur utilisation et comment relancer les donnes en
erreur une fois corriges etc
Cela est dautant plus important car au cours du projet de migration lexpert reprise de donnes
finance est dcd suite une maladie et de ce fait nous devions continuer son travail. Il avait cr
tous les outils ncessaires mais il nous tait impossible den utiliser certains. Dune part pour
certains outils plusieurs programmes devaient tre lancs les uns derrire les autres mais nous ne
savions pas dans quel ordre et dautre part nous ne savions pas quel format de fichier utiliser pour
le chargement. Nous avons finalement fait venir un autre expert pour recrer de nouveaux outils.
Cela nous a pris quelques jours de retard dans notre planning.
Lautre raison pour dire que la documentation tait indispensable est que les chargements taient
effectus par une quipe qui se trouvait des milliers de kilomtres de nous en Ile Maurice (offshore). Il fallait donc des documents qui expliquent prcisment loutil utiliser pour chaque
objet, la procdure de chargement. Et surtout que faire en cas derreur de chargement (par exemple
sils ont charg un mauvais fichier) ou sil y a des rejets dans le chargement (par exemple
certaines donnes sont rejetes si elles sont incompltes).
La documentation ne semblait pas tre une des priorits du manager du projet car nous avions un
retard sur le planning du projet (nous expliquerons plus tard le retard). Aprs le souci que nous
avions eu avec le dcs de notre collgue, jai tir la sonnette dalarme et suis all expliquer au
manager la ncessit absolue de documenter tout ce lquipe faisait et de lintgrer dans le
planning. Nous avons finalement convenu dune semaine entire pour mettre jour toute la
documentation. Chaque fois que les donnes sont valides dans le nouveau systme, nous
disposions dune demi journe pour la documentation.

5.2.5 La qualit des donnes migres


La complexit des donnes saccrot avec les modifications inhrentes aux personnes (mariage,
dpart, dcs) ou aux entreprises (rachat, fusion, etc.). Il est donc indispensable de concevoir ses
informations comme des actifs, grer de la mme manire quun patrimoine, sous peine

MSIR

Page 74/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

dimposer au sein de son entreprise une mauvaise culture des donnes. Plusieurs facteurs
expliquent cette grance dfaillante, comme par exemple une mauvaise information des clients.
Nous avons eu beaucoup plusieurs soucis avec la qualit des donnes puisque nous avons
effectus beaucoup de correctifs en production. Il ny a pas eu proprement parler, chez DeBiere,
une relle politique de gestion de la qualit de donnes.
En considrant les donnes comme secondaires, les entreprises aboutissent des problmes
dincohrence ou de doublons qui les empchent de dvelopper des qualits de transparence et de
scurisation ncessaires la satisfaction des clients et donc la croissance de lentreprise.

5.2.6 Choix et spcification des outils


Le principal outil que nous avions utilis pour la migration de donnes chez DeBiere est le LSMW
(dcrit plus haut) car cest un outil souple et simple dutilisation. Cependant les techniques
utilises avec le LSMW dpendait de la volumtrie des donnes, des types de donnes et des
dures de traitement (par exemple le direct input est beaucoup plus rapide en terme de traitement
que les autres techniques mais nest pas performant en terme de retraitement des erreurs. Pour
retraiter les donnes, non charges qui sont tombes en erreur lors du chargement, les IDOCS
offrent beaucoup plus de possibilits). Pour mettre jour les donnes dj charges, nous
utilisions le recording (batch input spcifique).

5.2.7 La mise en uvre


Nous disposions de 4 environnements pour le droulement de la migration de donnes : un
environnement de dveloppement pour la cration et la modification des outils de migration
(DEV100), un environnement de test (ERA310) pour tester si les donnes ont t bien migres, un
environnement de Pr-production (ou Business simulation) (ERO100) et un environnement de
Production (PRD100). Les 3 chiffres correspondent au mandant dcrit plus haut.
Nous avions 3 cycles de chargement de donnes avant la production. Ces cycles de chargement
taient appels mock cycle . Les 2 premiers cycles de chargement correspondaient au
chargement de donnes dans lenvironnement de test et le dernier chargement correspondait au
chargement de donnes en pr-production. Les outils taient dvelopps et tests dans
lenvironnement de dveloppement, ensuite ils sont transfrs dans lenvironnement de test.

MSIR

Page 75/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Concernant le premier cycle de chargement, pour chaque objet on faisait un premier chargement
afin de vrifier que celui-ci seffectuait correctement et que les rgles de gestion et les
transcodifications taient bien prises en compte. Les erreurs taient extraites sur un fichier excel
afin de vrifier leur nature, leur nombre pour pouvoir les corriger.
Ensuite lenvironnement de test devait tre rafrachi cest--dire que les donnes devaient tre
supprimes avant le second chargement qui correspondait au second cycle de chargement. Pour le
premier cycle de chargement, nous nous tions engags sur un taux de chargement entre 60 et 70%
de donnes correctes et pour le second cycle de chargement, ce taux devait tre de 80 90% de
donnes correctes charges. Pour le troisime cycle de chargement cest--dire la pr-production,
ce taux devait tre 100% car les fichiers utiliss pour le chargement en pr-production doivent
tre les mmes que ceux qui seront utiliss pour le chargement en production.
En ralit, une fois les donnes charges dans le premier cycle de chargement, lenvironnement de
test ntait pas rafrachi par ladministrateur SAP. Nous tions obligs de nous dbrouiller pour
distinguer nos donnes du premier cycle de chargement du second puisque le chargement est fait
dans le mme environnement et mme mandant. Pour sen sortir nous notions, par exemple les
premiers et derniers numros darticles crs dans la table des articles puisque les numros
sincrmentent.
Mais nous tions vite dbords car nous avions 2 types de numrotation pour les articles : interne
et externe. Les numros internes correspondent des numros darticle crs par SAP. Les
numros externes correspondent des numros darticle DeBiere dont ils ne voulaient pas changer
la codification. Jai attir lattention du management sur cette difficult et jai demand dfaut de
crer un nouvel environnement, au moins de crer un nouveau mandant dans lenvironnement de
test afin de sparer les donnes des premier et second cycles de chargement. Le management a
rpondu que cela ne pouvait pas tre fait car il ne disposait pas de ressources supplmentaires, ni
de dlai supplmentaire pour crer ce nouveau mandant (paramtrage, plan comptable,).
Aprs cela, nous ne soucions plus de la qualit des donnes charges mais uniquement des
donnes en erreur. Aprs chaque correction du fichier de donnes, nous rechargions jusqu ce
quil ny ait plus derreur dans lenvironnement de test sans nous soucier de la cohrence des
donnes charges.

MSIR

Page 76/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

La rgle tait que nous ne pouvions pas charger dans lenvironnement suivant si les donnes
ntaient pas valides dans lenvironnement prcdent par chacun des responsables de donnes.
Valider les donnes voulait dire, pour moi, dune part vrifier que les donnes dans le systme
taient bien celles contenues dans le fichier de chargement (donnes extraites de MDM) et dautre
part en droulant les flux complets, on valide quon obtient les rsultats attendus.
Or chaque fois que je demandais une validation aux quipes fonctionnelles, elles faisaient une
extraction des donnes du systme et les comparaient avec les donnes du fichier et ds quils se
rendaient compte quelles taient identiques, elles menvoyaient leur validation. Or nous savions
que ce qui tait dans le fichier a t correctement charg sinon nous aurions obtenu un rapport
derreur. Nous faisions une extraction des donnes stockes dans les tables SAP et nous les
comparions avec celles contenues dans les fichiers de chargement. Et les donnes taient
identiques. Ce que nous attendions des quipes fonctionnelles cest une analyse approfondie des
donnes en droulant des flux complets et de valider quen sortie (output), on obtient les rsultats
attendus.
Cela a t une grosse faille puisque par la suite jai t oblig de crer beaucoup de correctifs
(patch) en production pour mettre jour des donnes qui ne correspondaient pas ce qui tait
attendu. Ce nest pas concevable quon fasse beaucoup de modifications en production sur les
donnes.

5.2.8 Les risques


Le dmarrage (GO Live) a t retard de quelques mois parce que dune part nous navons pas su
faire une bonne valuation de la charge de travail pour la reprise de donnes et dautre part les
ressources ont t mobilises trop tt (quelques semaines avant que les environnements ne soient
rellement disponibles) donc consommation inefficiente du budget jour/homme.
Le retard a t aussi d au fait que nous navons pas anticip lindisponibilit dune ressource en
prvoyant un back up. Nous navions pas non plus document ds le dbut ce que nous faisions
(expliquer les outils choisis, comment les utiliser,).
Principalement nous dirons que la problmatique de la migration de donnes est de rechercher une
solution qui optimisera trois types de risque :

MSIR

Page 77/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

le risque humain notamment d la dsorganisation de lexploitation informatique en


raison de la charge de travail de mise en production des donnes et aussi la dstabilisation
temporaire des diffrents services au dmarrage en raison du nombre lev de correctifs devant
tre apports aux donnes (par exemple il y avait un risque que les utilisateurs travaillent sur
des donnes errones qui peuvent avoir certaines consquences dont le risque dmettre des
factures avec des donnes errones (mauvaise condition de prix, pas le bon destinataire,..) ;

le risque technique d aux incohrences dans les fichiers de chargement et au


dysfonctionnement dans la reprise en particulier si de nombreuses interfaces provisoires sont
dvelopper dans le cadre dun dmarrage progressif ;

le risque fonctionnel d un retard dans le dmarrage et qui peut conduire des blocages
de fonctionnalits de SAP (ex. commandes).

5.3 Typologie des donnes reprises


5.3.1 Donnes matre stables Master data
MSIR

Page 78/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Il sagit principalement des clients, fournisseurs, plan comptable, articles, banques. Ces donnes
ont ncessit un travail de fiabilisation et dpuration dans le systme source et un travail manuel
de saisies complmentaires dans le systme cible a aussi t effectu.
Ce travail a t anticip pour permettre toutes les oprations de contrle et leur reprise sur le
systme cible (production). Cependant leur planification na pas t suffisante car de mon avis, la
reprise de ces donnes aurait du se faire en production un mois au moins avant le dmarrage. Car
la mise jour de ces donnes a des rpercussions sur tous les autres types de donnes et sur les
traitements. Il est inconcevable que par exemple les utilisateurs travaillent sur la facturation et que
paralllement des mises jour seffectuent sur les conditions de prix. Prendre suffisamment le
temps entre la mise en production des donnes et le dmarrage est ncessaire pour dune part
dtecter les ventuelles anomalies non dtectes au cours des oprations dassainissement, les
corriger et dautre 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 Donnes mouvement en cours
Il sagit des critures comptables en cours (soldes de compte, en-cours tiers, ). Ces donnes sont
mises jour quotidiennement dans les systmes sources. Leur reprise dans le systme cible a t
mise en phase avec larrt des systmes sources.
5.3.3 Donnes mouvement de lanne
Il sagit des critures comptables de lanne. Ces donnes sont souvent consultes dans les
systmes sources. Leur reprise doit tre phase avec larrt des systmes source. Ce sont des
donnes qui peuvent reprsenter un volume important et donc un temps de traitement important
lors de reprises et conversion. Les donnes vitales ne doivent tre converties que dans le dernier
week-end avant le dmarrage pour le bon fonctionnement du systme au jour du dmarrage. Les
autres mouvements ne seront repris quaprs le dmarrage.

5.3.4 Donnes mouvement historique

MSIR

Page 79/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Ces donnes ont t reprises en mme temps que la reprise des mouvements de l'anne. Elles
peuvent reprsenter un volume important et donc un temps de traitement important lors des
reprises et conversion.
Ne doivent tre converties que les donnes vitales pour le bon confort dutilisation du systme en
rgime de croisire, ou dont la disponibilit rpond des ncessits lgales que la suppression des
anciens systmes ne permet plus de remplir.
5.3.5 Paramtres de structure
Ces donnes reprsentent peu de volume, leurs caractristiques sont lies la structure des
systmes existants et lorganisation actuelle. La spcificit de ces donnes dans SAP a ncessit
une reprise manuelle. Il sagit des donnes socit, domaine d'activit, divisions,

5.4 Bilan

MSIR

Page 80/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le dmarrage a finalement eu lieu, certes dans la douleur mais les utilisateurs des deux sites
pilotes peuvent prsent profiter de leur nouvelle application. Jusqu la veille de la mise en
production pour lUkraine, la plupart des donnes stocks ntaient pas correctes en production. Ce
nest quaprs plusieurs mises jour via des programmes que jai crs quon a pu rsoudre les
problmes. Pour le premier site pilote le Luxembourg, nous avions plutt des soucis au niveau des
conditions de prix. La plupart dentre elles ntaient pas correctes aprs la mise en production.
Cela veut dire que la phase en amont de prparation des donnes na pas t ralise avec toute la
rigueur requise.
Lintrt pour ce projet a t triple : il ma permis dune part de participer un grand projet
denvergure internationale avec des interlocuteurs de tous horizons, changeant avec eux nos
mthodes de travail et partageant avec eux certaines approches de la gestion dun projet de
migration donnes. Ce projet ma permis de dcouvrir des pays que je navais jamais visit avant
ce projet et de renforcer mon anglais puisque le projet sest droul entirement en anglais.
De plus il ma permis aussi de prendre conscience de limportance de la qualit des donnes.
Jamais avant ce projet je ne mtais souci de la qualit des donnes dans un projet de migration
de donnes, je me contentais de charger les donnes et de vrifier que les donnes charges
correspondaient bien aux donnes contenues dans le fichier de chargement (comparaison faite en
faisant une extraction des tables charges).
Avant de quitter ce projet, jai form une personne qui se trouvait en Ile Maurice (quon a fait
venir Louvain) pour me remplacer et fait le transfert de connaissance avec elle. Nous avions
commenc le processus de migration des donnes pour la Russie qui tait la filiale suivante dans le
planning de migration. Toute lintgration des donnes des autres filiales tait pilote en offshore
lle Maurice.
A travers la migration de donnes chez DeBiere, de la littrature et de notre exprience travers
diffrents projets auxquels nous avons particip, nous avons pu dgager quelques points
importants qui contribuent au succs dun projet de migration de donnes que nous dvelopperons
dans le chapitre suivant.

6.

MSIR

Facteurs cls de succs et Recommandations

Page 81/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Lorsque lon aborde une migration de donnes, un des facteurs de succs consiste en la conception
pralable dune documentation prcise sous forme de protocole de reprise afin dune part de tracer
le chemin et dautre part de prvenir les risques organisationnels et humains.
Elle doit reprendre les principaux lments ncessaires pour la migration de donnes (scnario de
reprise, risques, organisation, matriel,).
Un autre facteur de succs pour tout projet de migration de donnes est la disponibilit et
lexprience des ressources que le partenaire choisi (intgrateur) met la disposition de
l'entreprise car de ceux l dpendent en partie le succs du projet. Nous savons tous que la plupart
des intgrateurs ont tendance placer beaucoup de jeunes diplms sans exprience dans des
projets, qui par ailleurs en profitent pour se former. Chose lgitime mais les donnes tant une
ressource cruciale de lentreprise, il faudrait sassurer que ceux qui les manipulent ont une certaine
expertise afin de ne pas compromettre la qualit des donnes. La disponibilit des ressources pour
vrification des donnes reprises est un facteur trs important de succs de cette activit. En effet,
l'accs aux donnes doit tre vrifi au travers des transactions SAP et des tests prcis doivent tre
excuts pour valider la compltude des rsultats et le temps de rponse.
Il est indispensable aussi de faire une valuation de charge des reprises de donnes automatiques
qui a pour objectif de donner un ordre de grandeur de la charge de dveloppement du projet de
reprise de donnes.
Cette valuation couvre la totalit du cycle des reprises (programmes dextraction depuis les
systmes existants, de cration et maintenance des tables de transcodification, Abap vers SAP...).
Ceci permettra par la suite dtablir un planning plus prcis de la migration.
Concernant les donnes, il est important de conduire avec les utilisateurs et les acteurs process une
dmarche danalyse sur chaque flux pour dterminer la pertinence et le primtre de la reprise
effectuer. Il faut aussi valider les performances attendues et la fiabilit des conversions et
contrles en phase de recette et mettre disposition les machines assez tt pour commencer les
reprises.
Construire le plus tt possible une quipe utilisateur qui, en liaison avec lquipe projet tudiera
les oprations dassainissement mener afin de permettre de minimiser le volume de donnes
rejetes et de neffectuer que la reprise des donnes vivantes est un facteur important de succs.
Ces oprations porteront sur la slection des enregistrements de donnes obsoltes dont la reprise

MSIR

Page 82/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

est inutile, lencodage des complments de donnes ncessaires pour permettre un passage
uniformis dans les routines de reprise (exemple : tout enregistrement client payeur doit comporter
un code mode et type de rglement), les natures de champ (exemple : un champ considr comme
numrique dans les reprises doit comporter des zros gauche etc...).
Nous recommandons pour russir son projet de migration de donnes, en plus de tout ce que nous
avons voqu ci-dessus :

davoir une stratgie clairement dfinie, car elle permet de savoir prcisment comment le
travail de reprise de donnes sera construit, dans quel ordre les oprations seront menes pour
parvenir atteindre les objectifs dfinis ;
de bien dfinir la composition de lquipe de migration et le rle de chacun ;
de documenter toutes les tapes de la migration, les outils utiliss, lordre des reprises (par
exemple les articles doivent tre migrs avant les conditions de prix) ;
de faire une analyse de la qualit des donnes (rechercher les donnes partiellement ou
totalement manquantes, les donnes non cohrentes ou errones,..) ;
de bien spcifier les outils de migration utiliser (prfrer les standards aux spcifiques) ;
mettre disposition trs tt les machines pour les reprises ;
deffectuer des bascules blanc pour test et validation. Ces bascules blanc permettent de
drouler le processus complet de reprise avant dmarrage dans des conditions aussi proches
que possible des conditions relles.
Les objectifs recherchs sont damliorer et valider les procdures darrt des systmes source
et de dmarrage du nouveau systme, doffrir aux quipes en charge de ces oprations la
possibilit de sentraner en grandeur relle, de vrifier la validit des donnes source pour
reprise et la compltude des tables de transcodification et enfin destimer le temps de
traitement des programmes. Si ces bascules blanc permettent de dceler un trop grand
nombre de donnes rejetes au moment des traitements de reprise, de nouvelles bascules
doivent tre effectues jusqu ce que le volume de rejet soit minimum.

Conclusion

MSIR

Page 83/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

A travers cette tude, nous avons constat la place prpondrante que prend la migration de
donnes dans un projet de mise en place dun systme dinformation. En fait, les donnes
constituent lpine dorsale du Systme dinformation de lentreprise, ncessitant une attention
particulire, notamment, lors de leur migration dans le nouveau systme.
Au vu des normes enjeux, nous avons tent, partir de la littrature et en analysant le
droulement du projet de migration de donnes chez DeBiere, de comprendre dabord ce quest la
migration de donnes dans sa globalit et ensuite de savoir quels sont les facteurs qui contribuent
la russite dun projet de migration de donnes dans SAP.
Une prparation et une planification suffisantes, de mme quune approche rigoureuse de la
migration de donnes est indispensable pour russir limplmentation des applications dentreprise
SAP. Il est important pour cette raison de mettre en oeuvre des procdures standard confirmes
afin de garantir le succs de la migration de donnes et de ne laisser aucun dtail au hasard.
Lentreprise doit naturellement tout dabord identifier ses modes de fonctionnement et rpertorier
les donnes rcuprer et migrer cest--dire cartographier lexistant au niveau des donnes.
En dehors des donnes statiques (clients, articles,..), il est important aussi de prendre en compte
les contraintes lgales dans le cadre de la migration en terme de donnes dynamiques (par exemple
en ce qui concerne les donnes comptables : totaux, soldes, postes ouverts,..).
Il est important dans la mise en uvre dun projet de migration de donnes den faire comprendre
limportance aux responsables car sans une bonne prparation, une bonne planification et une
implication de tous les acteurs, les projets dimplmentation courent un risque pour la survie de
lentreprise.
Cependant, quelque soit lattention accorde la fiabilit des donnes migres, un certain nombre
de rejets peut toujours apparatre. Do limportance de la vrification des donnes post-migration.
Une documentation claire et prcise prsentant toutes les tapes de la migration est indispensable
pour donner une orientation au projet dune part et dautre part pour avoir une meilleure charge de
travail des membres de lquipe du projet.
Le partage des responsabilits et l'organisation efficace des tches s'imposent trs vite comme des
priorits pour l'entreprise qui souhaite disposer de donnes fiables et compltes. Et

MSIR

Page 84/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

paradoxalement, le rle de l'humain devient, dans un systme toujours plus automatis, de plus en
plus important.
L'entreprise doit rpondre certains impratifs afin de rester comptitive dans un secteur o le
phnomne 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
dune politique de diminution des cots, lentreprise doit, si elle veut crotre, se diffrencier en
tablant sur la cration perptuelle de nouvelles valeurs pour ses dpositaires (clients, employs,
partenaires, etc.).
La dmarche de migration de donnes prsente ici peut tre gnralise quelque soit le contexte
structurel.
Dans les projets de migration de donnes o jai eu intervenir, je ne moccupais que de la partie
technique cest--dire de la cration des outils, de leur choix sils existaient en standard, du format
des fichiers de chargement, du chargement des donnes. Cette thse ma permis de pousser plus
loin ma curiosit afin de mieux comprendre la dmarche de migration de donnes. Cela ma
permis de comprendre la ncessit de bien prparer et planifier son projet de migration de donnes
depuis la phase dextraction jusquau chargement et mme jusquaux contrles des donnes postmigration.

Glossaire
ABAP signifiant l'origine Allgemeiner Berichtsaufbereitungsprozessor (processeur gnrique
pour la prparation de rapport) a par la suite t anglicis en Advanced Business Application
Programming. Cest un langage de programmation propritaire, faisant partie de l'ensemble

MSIR

Page 85/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

logiciel SAP. Dans ABAP/4 le chiffre 4 fait rfrence son appartenance la classe des langages
de quatrime gnration.
Bascule de donnes : Processus de passage de lensemble des donnes reprendre dun systme
source vers un systme cible jusquau dmarrage de celui ci. Ce processus inclut les oprations
dorganisation des ressources, de mise disposition des moyens techniques, de contrles
intermdiaires, de conversion, de vrification des donnes dans le systme cible, de clture et
darrt du systme source.
Cible : Systme en cours de dmarrage destinataire dun flux de reprise de donnes
Conversion : Opration qui consiste transformer une donne entre le systme source et le
systme cible en modifiant son format (nature des caractres, longueur) ou/et son contenu
(codification du champ) sans que sa fonction soit modifie entre lancien et le nouveau systme.
Lager : ensemble des bires fermentation basse.
Reprise de donne : Oprations qui consistent extraire des donnes dun systme (source) pour
les injecter dans un autre (cible) avec dventuelles tapes intermdiaires automatiques ou non
(reformatage, transcodification, saisies manuelles...)
Source : Systme actuellement en exploitation, origine dun flux de reprise de donnes.

MSIR

Page 86/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Rfrences
Bibliographie
 Danielle LAROCCA SAP R/3 lIntro (CampusPress Edition 1999)
 Pierre-Yves MARTIN Guide de mise en place dun progiciel (Editions dorganisation
2001)
 LE Macmillan SAP R/3 (CampusPress Edition 1999)
 Philippe FENOUILERES Les donnes de l'entreprise (Editions EYROLLES ; 1992)
 Thomas REDMAN La qualit des donnes lge de linformation (ditions
InterEditions 1998)

Webographie
http://www.sap.com/fr

www.DeBiere.com

Ce site permet dobtenir des informations sur Ce site permet dobtenir des informations sur la
la socit SAP, son histoire, les solutions socit DeBiere, son histoire, ses produits, ses
proposes et les services quelle offre.
valeurs.
www.01net.com

www.journaldunet.com

Ce site nous a permis davoir des Ce site nous a permis davoir des informations
tmoignages sur des projets de migration de sur les principaux acteurs de la migration de
donnes.
donnes et a attir notre attention sur les risques
des projets de migration de donnes.

Autres :
 Documents internes DeBiere
 Documents internes Accenture

MSIR

Page 87/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Annexes

MSIR

Page 88/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Prsentation de SAP Exemple : cration dun outil de chargement via LSMW


dans SAP Guide de chargement via LSMW
La porte dentre dans SAP est lcran ci-dessous :

Nous avions expliqu la notion de mandant plus haut (cf. : chapitre 3.5). Pour entrer dans SAP, il
faut mettre son nom dutilisateur et son mot de passe qui ont t attribus.
Ensuite nous accdons aux diffrents menus. Nous voyons dans lcran ci-dessous, par exemple, le
module administration des ventes. En descendant la hirarchie jusqu client, nous voyons le
rpertoire Crer qui permet de crer un client.

En rgle gnrale, lextension 01 dans SAP signifie quon est en mode cration, 02 en mode
modification, 03 en mode display. Exemple : XD01 pour crer un client, XD02 pour modifier les
informations concernant un client, XD03 pour uniquement visualiser les informations concernant
un client. Cest une information importante qui nous sera indispensable lorsquon va manipuler les
LSMW pendant la migration de donnes. Lexemple ci-dessous concernant la cration des
nomenclatures (Bill of material) nous difiera sur la manire de crer les LSMW. Ce document
faisait partie de mes livrables et constituait un guide de chargement dans SAP.

MSIR

Page 89/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

LSMW GUIDE
Bill Of Material

History of the document


Version
1.0

MSIR

Dsignation de la version du document


Draft

Date
12/09/2006

Page 90/125

Auteur
S. LY

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Summary
Subject

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

Application
Domain
Responsibles

E ERP


Application et Contrle
Integration / Conversion Team

Use:
Integration / Conversion Team

Validation
Author:

Unit

Date

S. LY

12/09/2006

Validator:
Approver:

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

MSIR

Page 91/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Table of content

LAUNCHING OF THE LSMW ....................................................................................................... 93

CREATION OF BILL OF MATERIAL (BY LSMW)................................................................... 93

2.1

Project........................................................................................................................................................................ 93

2.2

Fields.......................................................................................................................................................................... 94

2.3

Structures Relations ................................................................................................................................................. 95

2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5

Launching LSMW .................................................................................................................................................... 95


Specify Files: Specify the directory of the files.............................................................................................. 95
READ DATA.................................................................................................................................................... 96
Convert data.................................................................................................................................................... 97
Create Batch Input .......................................................................................................................................... 98
Run Batch Input (we can use SM35 too) ....................................................................................................... 98

2.5

Process BOM............................................................................................................................................................. 98

MSIR

Page 92/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Launching of the LSMW


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

Transaction:
Project:
Subproject:
Object :

LSMW
ZTESTSLY
MANUFACTURING
BOM

Etape Technique of
importation

Batch Input

Program name

Description

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 :
Subproject :
Object :

ZTESTSLY
MANUFACTURING
BOM

2 Files needed : 1 header file and 1 items file


HEADER_BOM.txt
ITEM_BOM.txt

MSIR

 1 header file
 1 Item file

Page 93/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

1.2 Fields

MSIR

Page 94/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

1.3 Structures Relations

1.4 Launching LSMW


Transaction : LSMW

Specify Files: Specify the directory of the files

MSIR

Page 95/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

READ DATA

Important: We must have 0 to Not written . If we have not 0, please verify the files.
Display read data:

To check that the data are well recovered (see below)

MSIR

Page 96/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Convert data

To check that we have not an errors

MSIR

Page 97/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Create Batch Input

Run Batch Input (we can use SM35 too)

1.5 Process BOM


If we have a lot of data, we must process data in Background.

MSIR

Page 98/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

MSIR

Page 99/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

After process Batch Input, we must check the status (errors). For this example data are not loaded. Why? we can
know the reason by looking at the log. For this example we note that Material 19 does not exist; we must correct the
file and start again the procedure of loading described above until one does not obtain any more errors.

MSIR

Page 100/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Planning de suivi des chargements


Javais aussi livr le planning ci-dessous de chargement qui contient lobjet charger et le
module, le type de reprise (manuel ou automatique), les dates limite (rception du fichier,
chargement et validation), le statut (outil en cours de cration, outil en test, chargement test,
attente de validation, valid, ferm), lestimation de charge.
Pour laborer ce planning, je me suis bas sur mes expriences prcdentes, et sur les contraintes
du projet.

MSIR

Page 101/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Template : Fichier de chargement des donnes. Exemple : fichier de chargement


des conditions de prix
Il sagit ici dun fichier de chargement des donnes dentte des conditions de prix. Dans ce fichier
de chargement, nous avons des informations indispensables pour le chargement. En vert M
comme mandatory signifie que ces donnes sont obligatoires pour le chargement.

Pour ces mmes conditions de prix nous avons cr 2 autres fichiers : 1 pour charger les items
(donnes supplmentaires) et 1 autre pour charger les barmes.
Fichier de chargement des items :

MSIR

Page 102/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Fichier de chargement des barmes

MSIR

Page 103/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Template : Mapping des donnes. Exemple : fichier de mapping des conditions de


prix.
Le fichier de mapping aide connatre la structure des tables, les champs contenus dans ces tables,
leur longueur, le type de donnes, les valeurs possibles pour chaque champs/

MSIR

Page 104/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

MSIR

Page 105/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Comment fonctionne un LSMW Batch input Recording?

MSIR

Page 106/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Nous allons voir comment fonctionne un LSMW avec la technique batch input en difiant par un
exemple. A la fin de ce document nous ferons un rsum de toutes les tapes de chargement de
donnes via la technique LSMW-batch input.
La transaction LSMW existe dans SAP. Cest elle qui permet la cration dun lsmw pour le
chargement des donnes.
On accde au premier cran ci-dessous une fois quon a lanc la transaction lsmw

Fentre de
lancement de
la transaction

Donner un nom
significatif pour
pouvoir le
retrouver plus

Appuyer sur ce
bouton pour aller
lcran suivant

Nous allons
slectionner la
ligne Maintain
object attributes

Appuyer sur
ce bouton
pour aller
lcran
suivant

Cest dans Maintain object attributes que nous allons choisir notre technique (batch input
recording, direct input, idoc, etc..).

MSIR

Page 107/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Pour utiliser un direct input


appuyer ici

Pour utiliser un batch input


recording appuyer ici

Pour utiliser un
BAPI appuyer ici

Pour utiliser un Idoc


appuyer ici

Pour crer manuellement une condition de prix on utilise la transaction VK11.

Saisie de la transaction VK11

Saisir la condition de
prix quon veut crer

Nous allons voir comment charger les conditions de prix dans SAP en utilisant la mthode LSMW
avec Batch input recording.

MSIR

Page 108/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Nous allons simuler la transaction VK11 via LSMW comme ci-suit :

Saisir un nom au
batch input record

Description du batch input.

Saisir une
description

Une fois le nom et la description du batch input saisis, on appuie sur ok pour obtenir lcran
suivant.
Nous allons saisir la transaction VK11 car cest la transaction quil faut utiliser pour crer une
condition de prix.

MSIR

Page 109/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Une fois quon va appuyer sur le bouton


, le systme va drouler toutes les tapes de la
cration dune condition de prix (comme exactement lors de la cration manuelle). On obtient les
crans suivants :
Saisir la condition de
prix quon veut crer

Aprs saisie de la condition


appuyer sur le bouton OK

Aprs avoir appuy sur le bouton OK

, on obtient lcran ci-dessous:

Saisir les informations ncessaires cette


condition de prix : ici lorganisation
commerciale et le canal de distribution.

Saisir les autres informations qui dterminent la condition de


prix : ici il sagit de larticle, le montant, lunit, les dates de
validit de la condition de prix,..

Aprs avoir saisi toutes les informations, on


sauvegarde les informations en appuyant sur ce
bouton.
Par exemple :

MSIR

Page 110/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Article

Montant

FOR : Forfait

Dates de validit

Dans ce cas, il sagit dun montant forfait de 10 euros pour un diagnostic qualit lectricit.
Lorganisation commerciale est Gaz de France Direction commerciale.
Aprs avoir sauvegard les informations ci-dessus, le systme nous gnre lcran suivant avec
toutes les valeurs par dfaut que nous avions saisi. Par exemple, on voit bien dans le champs
RV13A-KSCHL la valeur ZFIX qui correspond au type de condition que nous avons crs.

Pour crer les conditions de prix en masse, nous allons dabord supprimer les valeurs par dfaut
que nous voyons lcran .
On appuie 2 fois sur le champs pour avoir lcran suivant puis on efface la valeur par dfaut
(default value).

MSIR

Page 111/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

On fait pareil pour tous les champs cest--dire quon efface toutes les valeurs par dfaut. De ce
fait on obtient ce qui suit :

On voit les champs avec des valeurs par dfaut vides . on sauvegarde .

MSIR

Page 112/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Ensuite, on revient lcran principal.

On va crer une structure qui va contenir les mmes champs utiliss lors de la cration de la
condition de prix. On cre la structure en appuyant ici (maintain source structure).

On donne un nom notre structure et une description comme par exemple ci-dessous :

on sauvegarde et on revient lcran principal :

MSIR

Page 113/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

On va dfinir maintenant les champs dans la structure cre prcdemment. Pour les crer, on va
appuyer sur Maintain Source Fields. Les champs qui seront crs dans cette structure constituent
les informations ncessaires la cration dune condition de prix.
On va crer le 1er champ qui est le nom de la condition de prix. La condition de prix est sur quatre
(4) caractres.

on appuie sur ok.

MSIR

Page 114/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Et on cre les autres champs ncessaires pour dterminer une condition de prix (organisation
commerciale, canal distribution, article, montant, dates de validit de la condition de prix). On
obtient lcran ci-dessous. Puis on sauvegarde .

On revient sur lcran principal. On va maintenant faire la correspondance (le mapping) des
champs de la structure cre ci-dessus et les champs standards de la structure SAP contenant les
conditions de prix. Pour cela, on appuie sur Maintain Field Mapping and Conversion Rules

MSIR

Page 115/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

On obtient alors lcran ci-dessous. Nous observons ci-dessous les champs contenus dans la
structure standard SAP. Pour faire la correspondance avec les champs de la structure que nous
avons cre ci-dessus, nous allons appuyer sur le bouton source field

on obtient lcran suivant :

Ici nous avons les champs de


la structure standard SAP

Ici nous avons les champs de la


structure que nous avons cre

Pour faire la correspondance (mapping), nous allons appuyer 2 fois sur le champ quon veut faire
correspondre.

MSIR

Page 116/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Voil ce quon obtient (voir cran ci-dessous).

La valeur du champ type de


condition de la structure standard
SAP gale la valeur du champ
type de condition de la structure
cre.

A chaque champ de la structure standard SAP pour les conditions de prix on fait correspondre le
champ identique de la structure que nous avons cre. Cela veut dire que la valeur du champ de la
structure cre se dversera dans le champ de la structure standard SAP.
Comment fait-on pour remplir les champs de la structure cre ?
Revenons lcran principal de notre LSMW.

Nous allons appuyer sur le bouton


specify file pour spcifier un
fichier

MSIR

Page 117/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le fichier quon va spcifier doit contenir les mmes champs que la structure que avions cre,
comme par exemple le fichier ci-dessous :
KSCHL

VKORG
Organisation
Condition de prix
commerciale
Description du champ
4
4
longueur
CHAR
CHAR
Type
Champ

DATAB
VTWEG
MATNR KBETR
Canal
de
Date de dbut de
Article Montant
distribution
validit
2
CHAR

18
CHAR

14
CHAR

8
CHAR

Le fichier doit contenir les donnes quon veut charger dans SAP. Par exemple, soient les deux
enregistrements ci-dessous :
Champ
Description
champ
longueur
Type

KSCHL
du Condition de
prix
4
CHAR
ZFIX
ZFIX

VKORG
Organisation
commerciale

VTWEG
Canal de
distribution

4
CHAR
5DCE
5DCO

2
CHAR
50
50

MATNR
Article

KBETR

DATAB
Date de dbut
Montant
de validit

18
14
CHAR
CHAR
00000000000300017 10,85
00000000000200014 34,94

8
CHAR
01011900
01011900

Nous avons nomm le fichier fichier chargement condition prix.xls (on peut le transformer
aussi en fichier texte)
Dans specify file nous allons rcupr ce fichier de chargement comme indiqu ci-dessous :
On appuie sur ce
bouton pour
spcifier un fichier

Pour retrouver notre


fichier
nous
pouvons appuyer sur
le match code
Nous pouvons mettre ici
nimporte quel nom. Pas de
signification particulire

Prciser les sparateurs dans


le fichier. Nous avons choisi
de sparer les fichiers par
point virgule

Nous avons appuy sur le match code pour rcuprer notre fichier.

MSIR

Page 118/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le fichier de
chargement

Le fichier est rcupr

Voil ce que nous obtenons aprs rcupration du fichier :


MSIR

Page 119/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Ensuite nous allons lire le fichier avant de rcuprer les donnes dans la structure cre pour
ensuite dverser les donnes dans la structure standard SAP.

Lecture du fichier

Les 2 enregistrements du fichier sont rcuprs par le programme de LSMW :

MSIR

Page 120/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Nous allons vrifier que les donnes rcupres correspondent bien celles saisies dans le fichier
en allant Display Read Data :

Nous voyons dans lcran ci-dessous que les donnes sont bien rcupres dans les champs
adquats :
Condition de prix = ZFIX
Date = 01011900
Etc

Ensuite nous allons convertir les donnes lues du fichier. Mais dans notre exemple nous navons
pas de transcodification faire puisque les donnes saisies dans le fichier correspondent bien aux
donnes format SAP => pas besoin de convertir les donnes.

Conversion des donnes


du fichier

MSIR

Page 121/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Dans Display converted data , on vrifie que la structure standard SAP rcupre bien les
donnes qui ont t lues dans Read data .

Structure
standard SAP

Donnes du fichier

On cre un dossier batch input en appuyant sur create batch input session

MSIR

Page 122/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

on obtient :

On slectionne la ligne puis on


excute le programme de batch input

Quand on excute le batch input lcran, on constatera que le programme rpte les mmes
gestes que nous quand crait manuellement une condition de prix, au dbut (voir plus haut).

Excution lcran

Voici lenchanement des crans quand on excute le programme lcran.

MSIR

Page 123/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Le programme lit et enregistre le premier champ du fichier cest--dire le type de condition (cran
ci-dessus) puis rcupre les autres enregistrements comme exactement lorsque nous crions la
condition de prix manuellement. Nous voyons ci-dessous que larticle, le montant, la date de dbut
de validit sont bien rcuprs et mis dans les champs adquats.

La dsignation, les units sont rcuprs


automatiquement. Aucune intervention nest ncessaire

On appuie sur OK et le systme sauvegarde le premier enregistrement puis va rcuprer le


deuxime enregistrement

MSIR

Page 124/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Nous voyons aussi pour le deuxime enregistrement que larticle, le montant, la date de dbut de
validit sont bien rcuprs et mis dans les champs adquats.
Comme il ny avait que deux donnes, le systme termine lexcution du batch input aprs avoir
intgr les deux enregistrements.

MSIR

Page 125/125

2005-2007

Les facteurs de russite dun projet de migration de donnes dans SAP

Si on avait N donnes dans le fichier de chargement, le batch input serait excut N fois.
Cependant si on a beaucoup de donnes (par exemple plus dune cinquantaine), il vaut mieux
lancer le batch en arrire plan.
Pour rsumer, lapproche de LSMW est :
1. dfinition de la structure de donnes cible,
2. dfinition de la structure des donnes source,
3. dfinition de la correspondance (mapping) entre donnes source et cible, c'est--dire des
modalits d'intgration des anciennes donnes dans SAP, via des oprations de
transcodification par exemple,
4. lecture du fichier source,
5. conversion des donnes source sur la base des rgles de mapping dfinies l'tape 3,
6. intgration des donnes en rel.
Pour la mthode batch input recording , on fait enregistrer une transaction par le systme pour
la rejouer n fois.
Dans cette mthode SAP va enregistrer les dynpros (crans) dans lesquels l'utilisateur va passer
lors de l'enregistrement. Ensuite, l'utilisateur dfinira, parmi les champs dtects 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 pralable, est en mesure
d'enregistrer une transaction pour fournir au systme le cheminement des crans par lesquels il
devra passer, et les champs alimenter.
De ce fait, lors de l'tape d'excution, SAP va rejouer autant de fois que ncessaire la transaction
enregistre, sous forme d'un dossier batch-input. Cette mthode, mme si elle n'est pas la plus
rapide en temps de traitement, offre un avantage certain en permettant de relancer les transactions
"en chec".

MSIR

Page 126/125

2005-2007