SAP Essec PDF

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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
2. Migrer des donnes
MSIR
Page 21/125
2005-2007
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
(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
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
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
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
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
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
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
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
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
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
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
<< 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
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
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
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
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
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
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
Tableau 3.2 : Les dates cls du dveloppement de SAP
MSIR
Page 41/125
2005-2007
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
MARA
MEINS
Unit de meseure
Unit de meseure
MARA
MATKL
Groupe darticle
Groupe darticle
Ancien numro
Ancien numro
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Annexes
MSIR
Page 88/125
2005-2007
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
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
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
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
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
1.2 Fields
MSIR
Page 94/125
2005-2007
1.3 Structures Relations
1.4 Launching LSMW

Transaction : LSMW
Specify Files: Specify the directory of the files
MSIR
Page 95/125
2005-2007
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
Convert data
To check that we have not an errors
MSIR
Page 97/125
2005-2007
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
MSIR
Page 99/125
2005-2007
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
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
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
Fichier de chargement des barmes
MSIR
Page 103/125
2005-2007
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
MSIR
Page 105/125
2005-2007
Comment fonctionne un LSMW Batch input Recording?
MSIR
Page 106/125
2005-2007
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
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
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
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
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
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
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
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
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
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
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
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
Le fichier de
chargement
Le fichier est rcupr
Voil ce que nous obtenons aprs rcupration du fichier :

MSIR
Page 119/125
2005-2007
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
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
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
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
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
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
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

SAP Essec PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SAP Essec PDF

Transféré par

Droits d'auteur :

Formats disponibles

bu

Les facteurs de russite dun projet de migration de donnes dans

Tuteur formation : Mr Dominique Briolat

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

Adresse pour le renvoi par la poste

Tlphone portable personnel

Tlphone fixe personnel

Email personnel et professionnel

Numro des chapitres inclus dans la version

Numro des nouveaux chapitres inclus dans

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

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

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

La connaissance s'acquiert par l'exprience, tout le reste n'est que de

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

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

Mission, Vision & Valeurs DeBiere ................................................................................................................ 15

Le projet OMEGA DeBiere............................................................................................................................. 17

MIGRER DES DONNEES ..................................................................................21

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

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

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

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

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

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

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

5. ANALYSE DU PROJET DE MIGRATION DE DONNEES

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

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

FACTEURS CLES DE SUCCES ET RECOMMANDATIONS .81

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

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

Table des figures

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

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

Nous avons analys la migration de donnes chez DeBiere

et partir de cette analyse, nous

Le nom de la socit a t chang en Debiere

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

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

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

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

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

1. Prsentation du groupe DeBiere2

1.1 Prsentation gnrale

Le nom de la socit a t chang en DeBiere

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

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

1.4 Mission, Vision & Valeurs de DeBiere

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

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

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

Cration : 2004 (fusion entre Interbrew et AmBev)

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

Figure 1.2 - Classement des 5 premiers brasseurs mondiaux

1.5 Le projet OMEGA de DeBiere

On appelle lager l'ensemble des bires fermentation basse.

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

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

Tentative Deployment Roadmap

Copyright 2005 Accenture All Rights Reserved.

Tableau 1.2 : Planning de dmarrage par pays

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