CONSERVATOIRE NATIONAL DES ARTS ET...

sur 73

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

PARIS

MEMOIRE

Présenté en vue d’obtenirLE TITRE D’INGENIEUR DIPLOME PAR L’ETAT

enINFORMATIQUE

parJacques BOHLY

Migration des données pour la mise en place d’un progiciel de gestion intégré

Soutenu le : 24 janvier 2008

JURY

PRESIDENT : Monsieur le Professeur Jacky AKOKA

Membres : Madame le Professeur Isabelle COMYN-WATTIAU

Monsieur Cédric DU MOUZA

Monsieur Jean-Luc de SINZOGAN

Monsieur Christian GODON

sur 73

Résumé.

Réalisation d’une plate-forme de migration de données, application à la mise en

place du système intégré de gestion SAP dans différentes sociétés d’un groupe

industriel.

Ce projet a été mené au cours de l’année 1998, à l’époque les migrations de

données vers SAP étaient limitées à la fourniture des fichiers de base comme les

Articles, les sièges sociaux des Clients et des Fournisseurs, les fichiers de liens

comme par exemple les commandes ne pouvaient pas faire l’objet d’une reprise,

et la reprise des encours de fabrication était réputée impossible.

S’inscrivant dans une démarche de développement rapide d’application (RAD), et

utilisant la puissance et la souplesse d’une base de donnée selon le modèle

multivaluée, le projet va concevoir et valider des outils logiciels permettant de

codifier les opérations de transformation des données nécessaires à la migration

vers le nouveau système, et permettant d’exploiter cette codification pour

réaliser les traitements ainsi définis. La codification sera également exploitée

pour produire automatiquement les spécifications fonctionnelles qui seront

validées par les utilisateurs des sociétés migrées.

La plate-forme et les outils logiciels développés par le projet vont permettre de

réaliser l’épuration et la fiabilisation des données, dont le dédoublonnage des

fichiers Clients et Fournisseurs, la reprise des commandes la reprise des encours

de fabrication, de la gestion du personnel et de la comptabilité. Ils ont permis le

démarrage de SAP en cours d’année et un fonctionnement en parallèle des

anciens et du nouveau système de gestion, y compris pour les opérations de

clôture annuelle. Ils ont permis l’arrêt des anciens systèmes un an avant la date

initialement prévue et ont représenté un gain de productivité considérable pour

les opérations de migration proprement dites.

sur 73

Nos conclusions proposent des axes d’élargissement des possibilités offertes.

Mots clés :

Migration de données, reprise des encours, transcodage (ou transcodification),

modèle multivalué, progiciel intégré, ERP, SAP, entrepôt de données

sur 73

Table des matières.

Préambule, contexte du projet....................................................................................................4

Première phase, définition de la stratégie de migration...........................................................6

Définition des objectifs. 6

Les choix stratégiques pour la réussite du projet. 7

Deuxième phase, vérification de la faisabilité........................................................................14

Premier prototype, migrations de données. 14

Deuxième prototype, reconstitution des liens. 26

Troisième phase, industrialisation et migrations opérationnelles.........................................28

Programme de travail de mi-juin à fin juillet. 28

Industrialisation des prototypes. 28

Migrations opérationnelles. 33

Poursuite de l’industrialisation. 34

Quatrième phase, dédoublonnage et épuration des fichiers..................................................39

Programme de travail de juillet à fin septembre. 39

Troisième prototype, dédoublonnage et épuration des fichiers. 40

Organisation des espaces de travail. 43

Poursuite des migrations opérationnelles. 47

Bilan des quatre premières migrations. 50

Suite et fin du projet. 51

Conclusions..............................................................................................................................52

Bilan final du projet. 52

Les extensions envisageables. 53

Bibliographie :..........................................................................................................................56

sur 73

Préambule, contexte du projet.

Le présent mémoire retrace le projet de migration de données mené par une

équipe de la société CISI-Transtech pour le compte de la Compagnie des Signaux,

nouveau propriétaire de CISI-Transtech. Il s’est déroulé de mai à décembre 1998

lors de la mise en place de l’E.R.P. SAP dans sa version complète incluant la

gestion de production dans quatre sociétés récemment acquise par la

« Compagnie des Signaux »pour constituer la branche « Sécurité » du groupe,

puis, dans une version limitée à la comptabilité, la paye et la gestion du

personnel, dans les autres sociétés du groupe.

Le paramétrage et la mise en place de SAP a été réalisé par une équipe de KPMG,

l’équipe CISI ayant en charge la migration des données des différents systèmes

propriétaires équipant les filiales pour préparer les données nécessaires au

chargement initial des fichiers de base (Clients, Fournisseurs, Produits, Gammes

et nomenclatures). Le projet prévoyait un démarrage ex nihilo au 1er janvier

1999, excluant toute reprise des encours. Les opérations en cours devant être

maintenues dans les anciens systèmes jusqu’à leur achèvement, seules les

nouvelles opérations (commandes clients, commandes fournisseurs,…) feraient

l’objet d’une saisie dans le nouveau système. Le plan d’action initial prévoyait

une préparation des données de chacune des différentes sociétés échelonnée de

mai à décembre 1998, pour un démarrage coordonné des 4 sociétés de la

banche « sécurité » au 1er janvier 1999, précédé par un fonctionnement « à

blanc » du nouveau système au cours du deuxième semestre 1998 pour la plus

importante des quatre sociétés. La mise en route au 1er janvier ne portant que

sur les « affaires nouvelles», la cohabitation du nouveau et des anciens systèmes

étant prévu jusqu’à la fin de l’année 1999. La préparation de la migration des

autres sociétés du groupe étant prévue pendant l’année 1999 pour un

sur 73

démarrage au 1er janvier 2000. A l’origine, il n’était pas prévu d’opération de

migration des données, la démarche préconisée par les experts en charge de la

mise en place était une ressaisie complète de toutes les données gérées dans

chacun des systèmes. C’est la charge de travail induite et l’opportunité créée par

le rachat de Cisi-Transtech, dont l’une des spécialités était la migration de

données qui ont conduit les responsables de la Compagnie des Signaux à

envisager cette opération.

L’auteur du présent mémoire, consultant indépendant, qui venait de mener à

bien la conduite d’un important projet de CISI-Transtech pour le Ministère de

l’Agriculture a été chargé d’étudier l’opportunité de cette opération de migration

de données et, dans ce cas, d’élaborer une proposition d’intervention. Après

avoir participé à une semaine de présentation détaillée des principes de

fonctionnement de SAP ainsi qu’à une présentation sommaire du processus de

paramétrage, l’auteur et deux des ingénieurs de l’équipe du projet précédent

rencontrent les responsables locaux des quatre sociétés de la branche sécurité

de la compagnie des signaux. Il ressort de ces rencontres que le processus de

paramétrage a été entamé depuis plusieurs mois et qu’il se heurte à une réelle

difficulté dans la validation des options choisies, en particulier du fait de

l’impossibilité de construire manuellement des jeux d’essais cohérents

suffisamment riches pour permettre cette validation du paramétrage.

Les responsables locaux ne cachent pas leur réticences à l’idée de l’impossibilité

d’effectuer une reprise des encours, ce qui va se traduire par une année entière

de coexistence des deux systèmes sur chaque site, avec l’impossibilité d’obtenir

des situations globales complètes et l’impossibilité de comparer les résultats

obtenus entre anciens et nouveau systèmes.

Les méthodes de chiffrage et les standards utilisés par la société Cisi-Transtech,

spécialiste de la migration de données, aboutissent à une estimation de 200 jours

sur 73

homme par société pour les migrations complètes et de 50 jours homme pour les

migrations « compta – paye - gestion du personnel », soit un budget global

d’environ 1 000 jours homme pour l’ensemble du projet. Cette proposition est

globalement plus économique que la ressaisie des données et présente surtout

l’avantage de transférer la charge de travail des utilisateurs concernés vers

l’équipe de migration des données, cet avantage est plus fortement ressenti par

les sociétés de la branche sécurité, qui se trouvaient être celles qui étaient

confrontés à la plus forte charge de travail.

La proposition sera acceptée, l’auteur se verra confié la responsabilité de ce

projet classifié « projet stratégique » par la Compagnie des Signaux du point de

vue de sa gestion interne, et par la société CISI en raison de sa volonté puissante

de former des collaborateurs afin d’investir le créneau SAP.

Première phase, définition de la stratégie de migration.

Définition des objectifs.

Habituellement, les opérations de migration de données ne concernaient qu’une

société à la fois et étaient menées sur place en utilisant les matériels et systèmes

du client, par contre le précédent projet (pour le ministère de l’agriculture) s’était

déroulé au siège de CISI, sur une plate-forme Unix appartenant à la CISI. Pour le

nouveau projet, les sources sont hétérogènes, chaque société étant doté de son

matériel et de son système propre, le système cible, SAP est installé sur une

plate-forme dans la plus importantes des quatre sociétés de la branche sécurité,

les trois autres sociétés venant s’y connecter, pour les sociétés de service du

groupe, SAP est installé sur l’un des ordinateurs du siège de la compagnie des

signaux, elles viendront s’y connecter pour la comptabilité, la paye et la gestion

du personnel. Aucun des systèmes sources à migrer ne disposait de liens entre

les fichiers clients et fournisseurs de la gestion et les fichiers clients et

sur 73

fournisseurs de la comptabilité, or le projet mené pour le ministère de

l’agriculture avait permis d’acquérir une forte expérience de l’appariement de

sources hétérogènes de données concernant les agriculteurs individuellement ou

en sociétés et la détection et la résolution automatique de doublons ainsi que la

création de liens entre les sociétés et les individus les constituant.

Il était donc naturel d’envisager de mener les migrations au siège de CISI, avec

une partie de l’équipe du précédent projet qui était disponible, sur la même

plate-forme Unix, d’intégrer dans la prestation l’épuration et le dédoublonnage

des fichiers sources ainsi que l’appariement entre les fichiers Tiers de la gestion

et de la comptabilité.

CISI disposait d’un ensemble de fonctions élémentaires utilisables dans le cadre

d’une migration de données (récupération de définition de fichiers, transcodage

de données par application de table de correspondances, …) sans que ces outils

ne soient intégrés dans un véritable « processus industrialisé » de migration de

données. Il était donc également naturel d’envisager d’intégrer et d’étendre ces

fonctionnalités pour constituer un véritable « atelier de migration » paramétrable

industrialisant le processus. Le temps ainsi investi, prélevé sur le budget global

de l’opération de migration devant être largement compensé par les gains de

productivité attendus.

Les choix stratégiques pour la réussite du projet.

Choix de la méthode de conduite du projet.

Les risques principaux induits par la décision d’investir du temps pour réaliser

l’atelier de migration au lieu d’effectuer directement les transformations de

données nécessaires, en particulier pour la première des quatre sociétés

industrielles à migrer sont d’abord un risque d’échec au cas où il s’avérerait

impossible de codifier simplement les transformations à exécuter et de les

réaliser automatiquement à partir de la codification, puis un risque de retard

sur 73

dans la mise à disposition des premiers fichiers attendus, et enfin un risque de

dépassement de budget si les gains de productivité attendus ne sont pas obtenus

auquel cas le budget prévu ne permettrait pas la réalisation des migrations de

toutes les sociétés.

Il est donc nécessaire de clarifier rapidement les fonctionnalités de base

nécessaires, et d’en valider la faisabilité par des prototypes opérationnels qui

pourront ensuite être étendus ou complétés par des interventions manuelles en

fonction de l’avancement et des délais à respecter. L’atelier de migration sera

donc développé selon les principes du « RAD » (Rapid Application

Développement), par cycles successifs de prototypes opérationnels.

Cisi-Transtech souhaitant donner un code évocateur à ce projet, le projet sera

baptisé PIAF pour Plate-forme d’Intégration Automatique de Fichiers.

Définition des itérations et des couvertures fonctionnelles visées.

Le premier problème détecté lors de la semaine de présentation de SAP puis au

cours des rencontres avec les experts en charge du paramétrage est l’attribution

automatique d’une nouvelle codification pour toutes les entités gérées. Produits,

Matières, Composants, Clients, Fournisseurs, Commandes, se voient attribués

chacune une numérotation automatique lors de leur chargement dans SAP, ce

qui entraîne l’impossibilité de conserver les liens comme par exemple les liens

(Clients ----- Commandes ----- Articles) ou (Produits ----- Opérations --------

Composants) des Gammes et nomenclatures. Pour résoudre ce problème, il faut

être capable de constituer une correspondance entre l’ancien et le nouveau code

pour reconstituer les liens existants dans la nouvelle codification avant leur

chargement.

Le deuxième problème détecté est l’impossibilité dans SAP de saisir ou de

charger les encours de fabrication, la seule façon de procéder étant de lancer les

ordres de fabrication puis d’en faire progresser l’avancement. Le lancement des

sur 73

ordres de fabrication entraîne automatiquement les sorties de stock

correspondantes, il faut donc reconstituer l’état des stocks de composants et de

matières tels qu’ils étaient avant le lancement de l’ordre de fabrication.

S’ajoutent à ces difficultés les problèmes traditionnels rencontrés lors de la

migration de systèmes à savoir l’épuration des fichiers par la correction des

erreurs de codification et surtout la détection des éventuels doublons.

Le premier prototype à développer est tout d’abord destiné à vérifier la

possibilité de codifier les opérations de transformation de données qui doivent

être réalisées lors d’une migration et de mesurer jusqu’à quel degré de

complexité le processus peut être conduit. Ce premier prototype sera utilisé pour

effectuer le chargement des fichiers de base de la gestion de production, à savoir

Articles, Composants, Matières, Stock.

Le deuxième prototype à développer sera destiné à la reconstitution des liens, il

sera utilisé dans un premier temps pour le chargement des gammes et

nomenclatures.

Le troisième prototype à développer sera destiné à la détection des doublons

dans les fichiers Clients et Fournisseurs, il sera également utilisé pour le

rapprochement du fichier Client de la Gestion commerciale (gestion des

commandes) avec le fichier Client de la comptabilité pour s’adapter aux notions

de Client livré, de Client facturé et du lien Client livré – Client facturé de SAP.

Ces trois prototypes seront intégrés dans un « Atelier de migration » installé sur

une plate-forme dans les locaux de Cisi-Transtech. Chacun des prototype sera

progressivement étendu par l’élargissement de ses possibilités fonctionnelles.

Dès que la complexité des problèmes à traiter ne permettra plus de poursuivre

l’enrichissement préalable de l’atelier de migration dans les délais impartis au

projet, les opérations seront réalisées par des développements spécifiques.

sur 73

Un axe complémentaire de développement, avec son prototype et sa démarche

d’élargissement viendra s’y ajouter lors de la mise en œuvre, nous l’évoquerons

dans la suite de ce mémoire.

Choix du système.

Un projet de ce type s’apparente à une démarche de recherche ce qui nécessite

une très grande rapidité de développement alliée à une très grande facilité

d’évolution. L’auteur du mémoire, spécialiste des systèmes de bases de données

a une connaissance approfondie des bases de données « multivaluées » dont la

souplesse, la puissance et la rapidité de développement ainsi que la facilité

d’apprentissage correspondent exactement aux besoins du projet. Vous

trouverez ci-après une brève présentation de leurs caractéristiques principales

Le projet sera donc mené sur un serveur Windows NT doté de la base de données

UNIVERSE de Vmark, avec des poste clients Windows NT dotés de l’interface

Winpick de Pole stratégie SA. Les applicatifs aussi bien serveur que client seront

développés à l’aide du générateur d’applications STRAGTEGE de Pole Stratégie

SA. Cisi-trantech dispose également de plates-forme Unix SCO, l’une de ces

machines sera équipée de la base de données UNIVERSE pour effectuer les

traitements de masse avec des applications qui seront importés depuis la plate-

forme Windows.

Le générateur d’application STRATEGE de Pole Stratégie dote les applications

qu’il développe d’une gestion centralisée des postes clients à partir du serveur,

ce qui permet une diffusion automatique des évolutions du logiciel des postes

clients et permet une installation simplifiée. D’autre part, ces applications

permettent une gestion centralisée (dans la base de données) des documents

Words produits au cours de l’utilisation de la plate-forme de migration, ce qui va

permettre de préparer la gestion de la documentation de la migration dans un

sur 73

premier temps, puis dans un deuxième temps, débouchera sur la production

automatique de la majeure partie de la documentation.

Présentation des caractéristiques principales de la base de données choisie.

Il nous semble indispensable, pour la compréhension du lecteur, de présenter ici

les principales caractéristiques du système de base de données choisi, d’autant

plus que sans cette base de données, il n’aurait pas été possible de mener à bien

ce projet.

UNIVERSE est la version sous Unix de la base de données Pick.

sur 73

Origines et évolutions.

Dans les années 1960, aux Etats Unis, la mode des grands projets de recherche

en informatique était à la portabilité, il s’agissait de concevoir de nouveaux

systèmes qui puissent remplacer les systèmes d’exploitation propriétaires et

s’affranchir ainsi d’un environnement technique prédéfini en garantissant la

pérennité des applications, quelque soit le constructeur et la gamme de machine

choisie. Deux de ces projets ont abouti à la création d’un nouveau système

d’exploitation, UNIX et PICK.

Pour UNIX, l’idée directrice a été de construire un système d’exploitation

contenant le minimum d’instructions de base nécessaires au fonctionnement

d’un ordinateur et à la programmation de ses applications, ceci pour minimiser

les coûts de réécriture du système pour chacune des plates-formes technique sur

lesquelles on souhaitait l’implanter.

Pour Richard PICK, l’idée directrice a été de rechercher la portabilité maximale en

concevant tout à la fois un système d’exploitation, une base de données dotée de

dictionnaires de données, d’un langage de requêtes pour les utilisateurs, d’un

langage de programmation pour les informaticiens et d’un système de traitement

de texte, tous intégrés et homogènes, avec une gestion des contenants (comptes

et fichiers) séparée de la gestion des structures des données, et une forme

unique pour la manipulation des données élémentaires en mémoire comme des

enregistrements dans les fichiers ou des articles des dictionnaires. Cette forme

unique, le tableau multivalué, demeure 40 ans plus tard l’innovation majeure qui

le distingue de tous les autres systèmes de bases de données.

Devant le succès de la diffusion du système d’exploitation UNIX, la société

Vmark a acheté à Pick Système les droits de reproduction du système PICK pour

en développer une version sous UNIX commercialisée sous le nom d’UNIVERSE,

et qui a été ultérieurement portée sous LINUX.

sur 73

UNIVERSE est aujourd’hui la propriété d’IBM qui la commercialise sous le nom de

U2, elle a absorbé les bases de données INFORMIX et UNIDATA, elle fonctionne

selon le modèle PICK, mais peut aussi être utilisée selon le standard ODBC via

SQL Server, ce qui a élargit son public mais ne permet pas d’en exploiter toutes

les possibilités.

sur 73

L’unité de gestion de l’information, le tableau multi-valué.

Au cœur des innovations apportées par le système Pick se trouve la façon de

gérer les informations, aussi bien les enregistrements dans les fichiers que les

données gérées en mémoire, tous ont la même structure physique, support de la

structure logique des informations.

Les caractéristiques sont la longueur variable et l’utilisation de caractère

spéciaux, les séparateurs, qui sont les outils de la structuration logique des

données.

Le modèle multivalué utilise une structure à trois dimensions, c’est un

« tableau » comportant un nombre variable (0 à n) de lignes appelées

« attributs », chaque attribut comporte un nombre variable (0 à n) de zones

appelées « valeurs », chaque valeur comporte un nombre variable (0 à n) de

zones appelées « sous-valeurs ». Les délimitations sont matérialisées par des

caractères spéciaux représentant les séparations entre attributs, valeurs et sous

valeurs, l’utilisation des différents niveaux est facultative.

Pour toute application informatique, nous pouvons être confrontés à des besoins

d’évolution comportant notamment la nécessité de gérer de nouvelles données.

Bien sûr, si l’on bouleverse l’ordre des données gérées, il sera nécessaires de

faire évoluer les programmes existants, par contre, si l’on se contente de rajouter

les nouvelles données à la suite des données précédemment gérées, nous

obtenons ce résultat unique de ne pas devoir modifier les anciens programmes et

de ne pas avoir à procéder à une quelconque reprise des données, sauf bien sûr

pour renseigner les nouvelles zones.

Le langage de requêtes et le langage de programmation associés à ce système

de fichiers possèdent les instructions nécessaires à la manipulation des

structures de données, mais les données (enregistrements de fichiers ou

tableaux en mémoire) peuvent également être traitées comme des chaînes de

sur 73

caractères, le langage de programmation et le langage de requêtes possèdent

des instructions spécifiques à la manipulation des chaînes de caractères.

Le langage de programmation associé présente la particularité d’être réellement

récursif, ce qui est particulièrement adapté pour le décodage de formules

contenant des parenthèses.

D’autres caractéristiques très particulières de ce système vous seront présentés

ultérieurement.

Constitution de l’équipe du projet.

L’équipe du projet précédent (migration de données pour le ministère de

l’agriculture) a fait la preuve de son efficacité et de son engagement en

redressant un projet fortement compromis. Elle a également acquis une riche

expérience en matière de normalisation d’adresses postales, d’épuration de

fichiers, ainsi qu’en techniques de dédoublonnage. Cette expérience est très

intéressante, l’équipe sera donc reconduite pour ce nouveau projet.

Elle sera répartie en :

2 Fonctionnels, chargé d’acquérir les compétences SAP, d’analyser les besoins

des utilisateurs et de conduire les migrations, ils auront en charge

l’expression des besoins vis à vis de la plate-forme :

2 Concepteurs chargés de la réalisation des outils d’épuration et de

dédoublonnage des fichiers :

1 Programmeur chargé de la génération et de l’administration de la

documentation :

1 Programmeur chargé de développements divers :

L’auteur souhaite ici les remercier chaleureusement pour la qualité de leur travail

autant que pour leurs qualités humaines qui ont permis de faire de ce projet

sur 73

ambitieux une réussite technique mais aussi une belle aventure partagée par

tous.

Directeur du projet, concepteur de l’ensemble des outils logiciels et

réalisateur du cœur des moteurs de traitement :

- Jacques Bohly, Autodidacte, auteur du présent mémoire.

L’auteur est le seul a connaître la base de données, les autres membres de

l’équipe sont des informaticiens expérimentés, il suivront trois semaines de

formation au début du projet (la base de données UNIVERSE et ses langages, le

générateur d’applications STRATEGE et l’interface Winpick).

sur 73

Planification du projet, définition des cycles.

La planification initiale a été établie lors de l’étude de l’opportunité de l’opération

de migration des données, elle servira de base de référence et fixera les jalons

incontournables pour le déroulement du projet.

Le projet débute en mai, et les utilisateurs de l’usine de Baldenheim ont imposé

un essai de fonctionnement de la gestion de production de SAP au mois de

septembre. Pour pouvoir disposer du délai nécessaire à la migration des données

par la réalisations de programmes spécifiques, il nous faut prendre la décision

d’utiliser ou pas l’atelier de migration au plus tard mi juin pour le fichier articles

et les fichiers de stock, ce qui définit le jalon de fin du premier prototype; et au

plus tard le 14 juillet pour la reprise des gammes et nomenclatures, de façon à

laisser le temps aux utilisateurs de les saisir dans SAP, en cas de besoin, ce qui

définit le jalon de fin du deuxième prototype. La reprise des données Clients et

Fournisseurs qui constituent le domaine le plus concerné par les problèmes de

doublons doit être effectuée fin octobre si elle est réalisée par des programmes

spécifiques, ce qui place le jalon de fin du troisième prototype à la mi septembre.

sur 73

L’industrialisation de ces prototypes n’est à priori pas prévue dans le projet

initial, mais devrait plutôt être réalisée à l’occasion d’un projet de migration

ultérieur. Il est donc prévu de se limiter aux fonctionnalités strictement

nécessaires.

Deuxième phase, vérification de la faisabilité.

Premier prototype, migrations de données.

Description des données et des fichiers.

Les spécifications des opérations de migration de données consistent à définir les

fichiers nécessaires au chargement du système cible, qui seront donc appelés

« fichiers cibles », et pour chaque rubrique de ces fichiers, de définir le processus

de transformation permettant l’élaboration des données (données cibles) à partir

des données issues de l’ancien système appelées « données et fichiers sources ».

Il sera donc nécessaire de décrire les fichiers à traiter, ou bien de récupérer leur

description. Dans un premier temps, seule la récupération à partir d’un tableau

Excel sera développée, cette fonction sera probablement à enrichir par la suite,

et un programme permet de saisir les descriptions :

sur 73

La saisie de la description des rubriques (données) d’un fichier va permettre de

définir le type de zone (numérique, alphanumérique, date, etc …), sa longueur,

les conversions à effectuer en entrée (avant d’utiliser la donnée pour les fichiers

sources) et en sortie (après avoir élaboré la donnée et avant de fournir le résultat

de la migration pour les fichiers cibles).

Elle va permettre également d’indiquer :

- Si une donnée est obligatoire,

- Si elle correspond à la clé d’un enregistrement qui doit exister dans un

fichier

- Si sa valeur doit se trouver dans une table

- Si elle doit faire l’objet d’un transcodage lors de sa prise en compte (pour

les données sources)

- Si elle doit faire l’objet d’un rapprochement (pour les données cibles).

Cette partie sera progressivement enrichie tout au long du projet, tirant partie en

cela de la facilité d’évolution de la base multivaluée.

Définition des rapprochements.

Nous appelons « rapprochement » les opérations liant entre elles les données

cibles avec les données sources dont elles sont issues. L’enjeu est ici de trouver

une façon de codifier les rapprochement et de mettre au point un moyen

d’exploiter cette codification.

Les rapprochements peuvent être effectués de quatre façons distinctes, à savoir :

- Non conditionnée, la valeur cible est directement constituée,

- Conditionnée, la valeur cible peut être obtenue de deux façons

différentes en fonction du résultat d’un test,

sur 73

- Directement par une fonction, la valeur cible est élaborée par une

fonction dont elle est le résultat principal,

- Indirectement par une fonction, la valeur cible est un sous-produit d’une

fonction utilisée pour produire une autre donnée cible, nous appellerons

ce cas « Dépendance »,

Nous allons créer un écran de saisie des rapprochements permettant de choisir le

fichier cible, et pour chaque rubrique du fichier cible de définir le rapprochement

permettant de l’obtenir.

Un rapprochement sera défini par son type (non conditionné, conditionné,

fonction, dépendance) :

- Pour un rapprochement non conditionné, la partie droite de l’écran va

permettre de saisir les opérations à effectuer. La formulation se fait de

façon naturelle avec les opérateurs d’addition, soustraction,

multiplication, division, concaténation de chaînes de caractères (bouton

:) ou extraction de sous chaîne (bouton [ ). Il est possible d’utiliser des

parenthèses.

- Pour codifier les opérations, les rubriques des fichiers sources sont

choisies en ouvrant la liste déroulante des fichiers sources (fenêtre

source) et en sélectionnant le fichier voulu, la liste des rubriques du

fichier s’affichent alors dans la fenêtre centrale de la partie droite de

l’écran, qui permet de sélectionner la rubrique voulue, les boutons

« calculette » permettent de saisir l’opération à effectuer. Il est

également possible de saisir des valeurs à prendre en compte. Dans la

codification des opérations, les rubriques seront toujours identifiées par

le nom du fichier concaténé à un dollar et au nom de la rubrique source.

sur 73

- Pour les rapprochements conditionnés, la partie droite de l’écran va

permettre de saisir les expressions à évaluer et les opérateurs de

comparaison : inférieur ou égal, inférieur, égal, supérieur, supérieur ou

égal et les opérateurs logiques ET et OU. Le premier prototype, destiné à

vérifier la faisabilité des rapprochements ne prévoit pas de combinaisons

de niveaux ni d’utilisation des parenthèses dans les tests, cette

possibilité sera ajoutée ultérieurement.

- La difficulté à résoudre pour l’utilisation de fonction réside dans le

passage des paramètres, généralement en nombre variable. Nous

utiliserons ici la facilité apportée par les tableaux multivalués en

normalisant ce passage de paramètres. Toutes les fonctions utiliseront

trois paramètres, à savoir le tableau (multivalué) des rubriques en

entrées, le tableau des rubriques en sortie, et le tableau des codes

retours et anomalies rencontrées.

- Pour définir les rapprochements effectués par une fonction, il suffit de

saisir le nom de la fonction (dans la zone valeur), puis de sélectionner les

rubriques ou valeurs servant de paramètres à la fonction, dans l’ordre

sur 73

prévu par la fonction. La valeur de la rubrique cible ainsi défini sera

toujours la première valeur du tableau des rubriques en sortie.

- Pour les rapprochements effectués par dépendance, il suffit d’indiquer la

rubrique cible constituée par la fonction concernée, et d’indiquer le

numéro d’ordre de la valeur à retenir dans le tableau des sorties.

Chaque fichier cible à fournir est donc défini par un enregistrement dans le fichier

des descriptions de fichier, la clé d’accès est le nom du fichier cible. Chaque

rubrique du fichier cible est définie par un attribut de l’enregistrement du fichier

des descriptions (dans le même ordre) chaque attribut contient :

Nom]désignation]type]longueur]obligatoire]nom du fichier (la valeur doit

être la clé d’un enregistrement existant dans le fichier indiqué)]nom de la

table (la valeur doit se trouver dans la table indiquée)]rapprochement (oui-

non)

] est le séparateur de valeurs matérialisant la structure de l’attribut.

Chaque fichier cible est également défini par un enregistrement dans le fichier

des rapprochements, la clé d’accès est le nom du fichier cible. Chaque rubrique

est définie par un attribut de l’enregistrement dans le fichier des rapprochements

sur 73

qui contient, dans l’ordre des rubriques et selon le type de rapprochement

(plusieurs valeurs par attribut):

- N (non cond)]formule de calcul.

- C (conditionné)]premier membre]opérateur]deuxième membre]formule

de calcul si vrai]formule de calcul si faux.

- F (fonction)]nom de la fonction]liste des paramètres d’entrées (sous-

valeur de la troisième valeur de l'attribut).

- D (dépendance)]nom de la rubrique cible dont dépend la

rubrique]numéro d’ordre dans le tableau des sorties.

Pour toutes les fonctions présentes et à venir, le mode de passage des

paramètres va être normalisé, ainsi que la présentation de la fonction qui devra

toujours commencer par des lignes de commentaires décrivant le traitement

effectué, les paramètres en entrées, les paramètres en sortie ainsi que les

éventuels messages d’anomalie. Les messages d’anomalie sont numérotés

séquentiellement pour constituer un fichier de référence commun, il est possible

d’ajouter des nouveaux messages.

sur 73

Exemple simplifié extrait de la migration de la gestion du personnel.

Le cœur de l’ancien système de gestion de la première usine migrée est

constitué par le fichier du personnel, complété par différents fichiers dont un

fichier des absences qui enregistre les périodes de congés pris par les salariés. Le

fichier du personnel comporte les dates d’entrées et de sorties éventuelles des

salariés, ainsi que les motifs de sortie.

Le fichier du personnel, que nous appellerons FPERS, contient les rubriques

suivantes, représentées sous forme de tableau :

Par exemple, les deux premières lignes (attributs) de l’enregistrement FPERS du

fichier des descriptions contiennent (les attributs correspondent aux lignes, les

« ] »sont les séparateurs de valeurs) :

MATRIC]matricule du salarié]Num]5]O

NOM]nom du salarié]Alpha-num]25]O

Et la cinquième ligne contient :

NATIO]nationalité]Alpha]4]O]]TABNATIO

nom désignation type longueur oblig fichier table rapprochMATRIC matricule du salarié Num 5 ONOM nom du salarié Alpha-num 25 ONOMJF nom de jeune fille Alpha-num 25 NPRENOM prénom Alpha-num 25 ONATIO nationalité Alpha 4 O TABNATIODATNAIS date de naissance Date 10 OLIEUNAIS lieu de naissance Alpha 20 NDATENT date d'entrée Date 10 OCATEMB catégorie à l'embauche num 1 NECHEMB échelon à l'embauche num 2 NSALEMB salaire de base à l'embauche N8,2 10 NDATMOD date dernière modification Date 10 NTYPMOD type de modification Alpha-num 2 N TABMODIFCATEG categorie actuelle num 1 OECHELON échelon actuel num 2 OSALAIRE salaire de base actuel N8,2 10 ODATSOR date de sortie de l'entreprise Date 10 NMOTIFSOR motif de sortie de l'entreprise Alpha-num 2 N MOTIFSORTIESOLDCONG solde de droits de congés N4,2 6 OCUMCONG cumul conges pris N4,2 6 O

sur 73

Car le code nationalité doit appartenir à la table des nationalités qui s’appelle

TABNATIO. Il n’y a pas de vérification par rapport à un fichier, d’où la sixième

valeur vide « ]] ».

Le système de gestion d’origine gère également un fichier des congés, que nous

appellerons CONGES contenant :

Son enregistrement dans le fichier des descriptions contient donc :

MATRIC]matricule du salarié]Num]5]O

TYPCONG]type de congés]alpha]3]O]]TYPE_CONGES

DATDEBUT]date de début]date]10]O

NBJOURS]nombre de jours de congés]num]2]O

Pour SAP, nous devons alimenter quatre fichiers, le fichier des AGENTS,

contenant les informations concernant les salariés, le fichier des EVENEMENTS

contenant les événements de la gestion du personnel (embauche, promotions,

départ), le fichier des droits aux congés (DROITSCONGES) et le fichier des

ABSCENCES contenant les dates et motifs d’absence.

La description du fichier AGENTS contient :

NOM]nom du salarié]Alpha-num]25]O

PRENOM]prénom]Alpha-num]25]O

NOMJF]nom de jeune fille]Alpha-num]25]N

DATNAIS]date de naissance]Date]10]O

LIEUNAIS]lieu de naissance]Alpha-num]30]O

CODNAT]code nationalité]Alpha]3]O]]CODNAT

nom désignation type longueur oblig fichier table rapprochMATRIC matricule du salarié Num 5 OTYPCONG type de congés alpha 3 O TYPE_CONGEDATDEBUT date de début date 10 ONBJOURS nombre de jours de congés num 2 O

sur 73

STATUT]statut du salarié]num]1]O

COEFF]coefficient]num]3]O

Les rapprochements simples (enregistrement AGENTS du fichier des

rapprochements) contiendront, par exemple pour le nom et le prénom qui sont

des rapprochements non conditionnés :

N]FPERS$NOM

N]FPERS$PRENOM

Qui indique qu’ils sont obtenus en prenant respectivement le nom et le prénom

du fichier FPERS.

Les rapprochements peuvent être moins simples, par exemple :

Le code nationalité est présent dans le fichier source et dans le fichier cible, mais

les codifications sont différentes, le rapprochement utilisera une table de

transcodage, il sera codifié comme suit (attribut correspondant à CODNAT dans

le fichier AGENTS (donc 6éme attribut de l’enregistrement) :

N]FPERS$NATIO]]]]]NATIO_CODNAT

Où NATIO_CODNAT est le nom de la table de correspondance des codes nationalités.

Le statut du salarié et le coefficient sont déduits de la catégorie et de l’échelon.

deux tables de transcodage ont été constituées, donnant pour chaque

combinaison valide d’une catégorie et d’un échelon le statut (cadre /non cadre)

et le coefficient correspondant. La recherche dans les tables s’effectue par

« catégorie-échelon » (il faut concatener la catégorie, un tiret et l’échelon) ce qui

s’exprime, dans l’enregistrement des rapprochements pour le statut et l’échelon,

par :

N]FPERS$CATEG\:\ «-»\:\FPERS$ECHELON]]]]]TABSTATUT

N]FPERS$CATEG\:\ «-»\:\FPERS$ECHELON]]]]]TABCOEFF

Où « \ » représente le séparateur de sous-valeurs (subdivision d’une valeur d’un

attribut). Les instructions de manipulation des chaînes de caractères permettent,

en une seule instruction, de remplacer les séparateurs de sous-valeurs de la

sur 73

formule par des espaces facilitant la lisibilité de la formule, à l’écran ou dans les

éditions

La deuxième valeur de la description du rapprochement codifie les opérations à

effectuer pour obtenir la valeur de « catégorie-échelon », puis cette valeur est

recherchée dans la table de transcodage mentionnée par la septième valeur de

l’attribut, cette table fournit la valeur finale qui doit être chargée dans SAP.

Pour constituer le fichiers cible des ABSENCES qui contient la date de début et la

date de fin alors que le fichier source des CONGES contient la date de début et le

nombre de jours de congés pris, nous utiliserons une fonction (DATE_CONGES)

pour effectuer le calcul des dates de fin, ce qui se traduira par :

F]DATE_CONGES]CONGES$DATDEB\CONGES$NBJOURS

dans l’attribut correspondant à la date de fin de l’enregistrement ABSENCES du

fichier des rapprochements.

Nous effectuons un premier chargement dans SAP du fichier des agents en

remplaçant le prénom du salarié par son ancien numéro matricule, puis nous

exportons le fichier des AGENTS de SAP et nous constituons ainsi un fichier de

correspondance entre l’ancien numéro matricule des salariés et leur nouveau

numéro SAP, à la suite de quoi nous fournirons un fichier de mise à jour

rétablissant les prénoms des salariés dans SAP.

Pour constituer le fichier des événements de la gestion du personnel de SAP, le

fichier source du personnel nous donne les informations concernant l’embauche

du salarié, et celles concernant son éventuel départ. Par contre nous ne

connaissons la catégorie, l’échelon et le salaire de base que pour l’embauche et

pour la situation actuelle du salarié.

Nous allons, dans un premier temps, écarter de la reprise les salariés ayant

quitté l’entreprise avant le 1er janvier 1998 (contrôle avec rejet de la date de

départ dans le fichier source).

sur 73

Pour chaque salarié chargé dans SAP, nous allons créer un événement

« Embauche ».

Pour chaque salarié ayant quitté la société avant la date du passage sous SAP,

nous allons créer un événement « Démission » ou « Licenciement » en fonction

du motif de départ.

Pour chaque salarié dont la position (catégorie et échelon) actuelle est différente

de la position à l’embauche, nous allons créer un événement « Promotion ».

Pour chaque salarié dont la position sera identique entre la position à l’embauche

et la position actuelle mais dont le salaire de base sera différent, nous allons

créer un événement « Augmentation de salaire ».

Chacun de ces événements sont reliés au salarié concerné par la fourniture du

numéro SAP du salarié, qui est obtenu par l’intermédiaire du fichier de

correspondance à partir du matricule du salarié.

Le fichier des droits aux congés de SAP sera alimenté par l’addition du nombre

de jours de congés pris par le salarié avec son solde de congés disponible fournis

par le fichier du personnel, et une absence globale sera générée pour alimenter

le fichier SAP des ABSENCES et rétablir le solde de congés restant à prendre pour

chacun des salariés.

sur 73

Utilisation des rapprochements.

Un échantillon du fichier Articles sera utilisé pour la mise au point d’un

« interpréteur» mettant en œuvre les rapprochements saisis. La cinématique est

simple puisqu’il s’agit de fournir un enregistrement cible pour chaque

enregistrement source.

L’interpréteur lit la définition du fichier source et constitue une table de

correspondance entre les noms des rubriques (nom_fichier$nom_rubrique) et leur

position (n° d’attribut) dans l’enregistrement source. Il effectue le même

traitement pour le fichier cible et obtient une autre table de correspondance. Il lit

les enregistrements du fichier cible dans le fichier des définitions et dans le

fichier des rapprochements. Il constitue une table des dépendances, chaque

rubrique « dépendante » est inscrite dans la table des dépendance. Dans

l’attribut correspondant à la rubrique appelant la fonction de transformation nous

ajouterons autant de valeur qu’il y a de rubrique dépendante, chaque valeur

contenant le numéro d’attribut de la rubrique dépendante. Le traitement de

l’appel de la fonction permettra de stocker l’ensemble des valeurs produites par

la fonction à leur place dans l’enregistrement cible.

L’interpréteur traite ensuite l’ensemble des enregistrements du fichier source, et

pour chaque enregistrement source fournit un enregistrement cible.

Pour chaque rubrique de l’enregistrement cible, l’attribut de la table des

rapprochements correspondant à la rubrique est traité selon son type :

- En remplaçant dans la formule les noms des rubriques sources par leur

valeur puis en appelant une fonction récursive qui traite la formule ainsi

constituée ( elle s’appelle elle-même à chaque ouverture de parenthèse

en transmettant la suite de la formule, et revient au niveau précédent en

transmettant la suite de la formule à chaque fermeture de parenthèse.

sur 73

- En effectuant le test indiqué pour les formules conditionnées puis en

traitant comme indiqué ci-dessus la formule correspondant au résultat

du test.

- En chargeant les valeurs nécessaires dans le tableau des paramètres en

entrée et en appelant la formule (le langage permet un appel indirect

grâce à une variable contenant le nom de la fonction à appeler), puis en

affectant le contenu du premier attribut du tableau des sorties à la

rubrique traitée, et avec la table des dépendances en affectant les autres

valeurs du tableau des sorties aux rubriques dépendantes.

- Les valeurs dépendantes figurant dans la table des rapprochements ne

sont pas traitées puis qu’elles le sont lors du traitement de la rubrique

dont elles dépendent.

Ce premier prototype sera conçu, réalisé et mis au point par l’auteur en moins de

15 jours, il prouve la faisabilité de l’atelier de migration de données, il est

fonctionnellement plus puissants que les outils ponctuels utilisés auparavant par

CISI, en particulier parce que la récursivité qui permet l’utilisation des

parenthèses dans les formules n’est à priori pas limitée.

Le prototype sera intégré dans une première ébauche de l’atelier de migration

proprement dit avec la création de menus et sous-menus, il sera également

complété par la possibilité de modifier ou supprimer des rapprochements déjà

saisis. La saisie de la description des fichiers sera complété par la possibilité de

dupliquer une description déjà saisie puis de la modifier.

La définition et la mise en œuvre des rapprochements va également être

complétée par la possibilité d’utiliser des tables de transcodage (déjà utilisées

par la description des fichiers). Après avoir saisi les rapprochements nécessaires

à l’élaboration d’une rubrique cible, il est possible de faire appel à une table de

transcodage. Lors du traitement, la rubrique cible est élaborée, et la valeur ainsi

sur 73

obtenue est recherchée dans une table de correspondance qui va fournir la

véritable valeur cible.

Cette possibilité d’intégrer l’utilisation d’une table de transcodage sera alors que

des rapprochements ont déjà été saisis et utilisés. Il suffira de modifier l’écran de

saisie des rapprochement pour ajouter les nouvelles rubriques (nom de la table

de transcodage et indicateur d’activité ou d’inhibition) et de stocker le résultat de

la saisie dans la 7ème valeur de l’attribut de définition des rapprochements, car la

codification du traitement pour une rubrique à rapprochement conditionné

nécessite 6 valeurs. Il suffira de revenir sur la définition des rapprochements déjà

saisis, uniquement pour les rubriques qui doivent utiliser cette nouvelle

possibilité, pour saisir le nom de la table et activer ou non la transcodification. Il

n’y a rien d’autre à modifier. Dans le cas, par exemple, d’un rapprochement non

conditionné (qui ne nécessite que 2 valeurs dans l’attribut, c’est UNIVERSE qui va

automatiquement ajouter les séparateurs manquants si une table de transcodage

est utilisée). La constitution des tables de transcodage se fera à partir de tables

(codes – libellés) sources et cibles chargées sur la plate-forme de migration. Les

tables sources peuvent être constituées par une recherche des valeurs prises par

sur 73

une rubrique d’un fichier, la constitution de la table de transcodage proprement

dite peut être automatique lorsque les libellés correspondent.

sur 73

Deuxième prototype, reconstitution des liens.

Le problème posé par la conservation des liens est que SAP utilise une

codification numérique qui lui est propre, et tous les fichiers chargés dans SAP

reçoivent une nouvelle codification alors qu’il est impossible de conserver

l’ancienne codification, certaines notions sont mêmes subdivisées, par exemple

si l’ancien fichier client comporte des adresses de livraison et des adresses de

facturation, chaque adresse de livraison doit donner lieu à la création d’un

« Client livré », chaque adresse de facturation doit donné lieu à la création d’un

« client facturé », l’adresse du Client qui passe commande donnant lieu à la

création d’un « client donneur d’ordres »

Nous allons procéder en plusieurs temps :

Pour chaque Client de l’ancien système, nous devons fournir deux clients à SAP,

les donneurs d’ordre d’une part et les clients livrés d’autre part. Nous allons donc

définir deux fichiers cibles et les rapprochements qui les constituent en

substituant l’ancien code client au nom du client (ou à n’importe quelle rubrique

qui ne nécessite pas de contrôle ou de format particulier lors du chargement de

SAP).

Client SARL Bastille1 place de la Bastille

Adresse de livraison :SARL Bastille12 quai de la rapée

3812TZ

Donneur d'ordre : SARL Bastille1 place de la Bastille

Client livré :SARL Bastille12 quai de la rapée

537

614Perte du lien

Client 3812TZ1 place de la Bastille

Adresse de livraison :3812TZ12 quai de la rapée

3812TZ

Donneur d'ordre : 3812TZ1 place de la Bastille

Client livré :3812TZ12 quai de la rapée

537

614

sur 73

Après chargement dans SAP, nous allons exporter le fichier clients pour le

recharger sur la plate-forme de migration et récupérer ainsi la nouvelle

codification.

Nous allons donc pouvoir fournir à SAP un fichier de mise à jour restituant les

raisons sociales initiales des clients et constituer un fichier de correspondance

des codes clients qui va nous permettre de charger les liens dans SAP (614 est

client livré de 537).

Nous procéderons de la même façon pour les fichiers Articles, Clients et

Fournisseurs, et cette technique nous permettra aussi de fournir les fichiers

Commandes des Clients et des Fournisseurs.

Pour obtenir une mise en œuvre facile, nous allons tout d’abord organiser les

fichiers cibles à produire en « lot de migration », un lot de migration est constitué

de l’ensemble des fichiers à fournir pour une opération de chargement de SAP,

par exemple le fichier client et le fichier des liens entre clients (au sens SAP), ou

encore les fichiers Articles, Opérations, Gammes et nomenclatures et Stocks pour

le lot « gestion de production ». Les lots de migration doivent s’articuler autour

d’un fichier source principal servant de fichier maître et traité en totalité, les

autres fichiers étant utilisés en accès direct.

Donneur d'ordre : 3812TZ1 place de la Bastille

Client livré :3812TZ12 quai de la rapée

537

614

Donneur d'ordre : SARL Bastille1 place de la Bastille

Client livré :SARL Bastille12 quai de la rapée

537

614

sur 73

Troisième phase, industrialisation et migrations

opérationnelles.

Programme de travail de mi-juin à fin juillet.

Le groupe fonctionnel a terminé sa formation SAP et le reste de l’équipe a suivi

les formations à UNIVERSE, au générateur d’application STRATEGE et à l’interface

client WINPICK, les deux premiers prototypes vont être réécrits et enrichis en

fonction des besoins exprimées par les deux membres du groupe fonctionnel qui

définissent les migrations nécessaires à la mise en œuvre de la Gestion de

production pour l’usine de Baldenheim, l’objectif est de permettre le

fonctionnement d’un prototype SAP de la gestion de production pour le 1er

septembre, les experts SAP pensent augmenter arbitrairement le niveau des

stocks de matières et composants pour ne pas être gênés par les sorties de stock

des lancement de production à effectuer, pour sa part, l’équipe projet est

convaincue de réussir la reprise des encours de production.

sur 73

Industrialisation des prototypes.

Le traitement des rapprochements fait par l’interpréteur de la codification va être

transformé en étape spécifique qui va permettre d’une part de déterminer les

fichiers sources et les rubriques nécessaires à la constitution des fichiers cibles,

et d’autre part de préparer les tables de chargement.

sur 73

Des possibilités de contrôle des rubriques vont être ajoutées, et il sera possible

de définir les contrôles à appliquer aux rubriques des fichiers sources, avant

d’effectuer les rapprochements, ainsi que les contrôles à appliquer aux rubriques

des fichiers cibles, après avoir effectué les rapprochements.

Chaque rubrique peut être associée à un contrôle, mais un contrôle peut faire

intervenir plusieurs rubriques. Un texte de message doit être associé à chaque

contrôle, il est composé de parties fixes et de parties variables qui sont les

identifiants des rubriques à inclure dans le texte de façon à constituer des

messages compréhensibles par les utilisateurs du client (ceux pour qui est

effectuée la migration). Lors du traitement ces messages seront édités sous la

forme d’un compte rendu de traitement. Une évolution ultérieure est prévue pour

constituer une base de données des messages et anomalies rencontrés, avec un

outils permettant la saisie des corrections ou des arbitrages souhaités par

l’utilisateur final pour être ré-injectés dans le traitement de migration. Mais cette

possibilité ne fait pas partie du périmètre du projet.

Revenons à l’exemple de la gestion du personnel, les gestionnaires ont décidé de

ne pas charger dans SAP les membres du personnel ayant quitté l’entreprise

sur 73

avant le 1er janvier 1998, ce que nous traduirons par un contrôle de la date de

départ du fichier source du PERSONNEL associé à un message de rejet NOM

PRENOM MATRIC « hors domaine de la reprise, départ le » DATSOR..

sur 73

A partir des définitions de fichiers gérées, l’application va générer les contrôles

des rubriques des fichiers sources pour les rubriques obligatoires, celles devant

appartenir à une table de valeurs ou celles devant correspondre à un

enregistrement existant dans un fichier. Elle génère en même temps les

messages d’anomalies associés.

Avec les messages d’anomalie sont définies les actions correspondantes qui

peuvent être un rejet de l’enregistrement, une anomalie (la valeur incriminée est

alors remplacée par la valeur par défaut prévue quand elle est définie), ou une

simple alerte à l’usage de l’utilisateur final.

Une fois les règles de contrôles et les messages associés saisis, l’application va

permettre de procéder à la génération d’une table de traitement définissant les

fichiers sources du lot de migration, et pour chaque fichier source, d’une table

des contrôles à appliquer. La codification interne des contrôles est similaire à la

codification interne des rapprochements conditionnés.

Un traitement de migration comportera donc trois étapes majeures de

traitement :

- Contrôle des fichiers sources

sur 73

- Rapprochements (constitution des données des fichiers cibles du lot de

migration)

- Contrôle des fichiers cibles.

Chaque étape se subdivise en :

- Saisie des contrôles ou des rapprochements

- Génération d’une table définissant les traitement

- Exécution des traitements.

Par exemple, pour la génération des contrôles des fichiers sources :

Et pour le traitement des rapprochements (constitution des fichiers cibles du

lot) :

sur 73

Génération et administration de la documentation.

Initiée par la constitution des messages d’anomalies paramétrables, des

fonctions de génération de la documentation vont être développées, elles vont

prendre la forme de spécifications fonctionnelles et techniques et vont concerner

la description des fichiers sources et des fichiers cibles, l’édition des

rapprochements, l’édition des fonctions utilisées par les rapprochements (chaque

fonction comportera à partir de la deuxième ligne, une description des entrées,

des sorties, des codes retours et un texte d’explication sur son objet et son

fonctionnement, sous la forme de lignes de commentaires dans le texte du

programme, qui sont lues et intégrées dans l’édition des spécifications). Les

éditions porteront également sur les messages et les tables.

sur 73

Le générateur d’applications STRATEGE permettant de gérer des documents

Word au sein même de la base de données UNIVERSE, nous allons doter tous les

éléments constitutifs du traitement d’un lot de migration (tables de descriptions

de fichiers, tables de traitements de contrôles et tables de rapprochements)

d’une version incrémentable à chaque modification. C’est à dire que l’édition des

spécifications précisera si il s’agit d’éditer une version de travail non définitive, le

numéro de version ne sera pas incrémenté, si il s’agit d’éditer une nouvelle

version à destination des utilisateurs, il sera possible de préciser si il s’agit d’une

version issue de corrections effectuées depuis la version précédente, c’est alors

le numéro d’itération (version mineure) qui sera incrémenté, ou bien si il s’agit

d’une reprise complète de l’opération de migration, et c’est alors le numéro de

version majeure qui sera incrémenté. Lors de la demande d’édition, l’application

vérifiera que les tables de traitement ont été ou non modifiées et, en cas de

modification, rendront obligatoire le changement de version majeure ou de

version mineure. De cette façon, les spécifications éditées correspondront

toujours au traitement puisqu’elles en sont issues, et la dernière version de la

documentation correspondra toujours au dernier état du traitement effectué.

sur 73

Migrations opérationnelles.

Le groupe fonctionnel de l’équipe va fournir les fichiers Articles, Opérations,

Gammes et nomenclatures et Stocks pour la mise en œuvre de la gestion de

production de SAP à titre d’essai, ce qui va permettre aux utilisateurs de l’usine

de faire ajuster à plusieurs reprises le paramétrage de SAP, cinq livraisons seront

ainsi échelonnées tout au long du mois de juillet, elles auront toutes un impact

sur la migration des données en raison de modifications de la structure et du

contenu des cibles, mais les modifications seront toutes réalisées dans un délai

de 48 heures.

A partir de la deuxième livraison, l’usine nous fournira le fichier des stocks

matières et composant à la date de début des opérations, ainsi que les ordres de

fabrication en cours. Nous pourrons alors, par des traitements de migrations

définis et exécutés de façon standard, constituer le fichier des sorties de

matières et de composants correspondants aux ordre de fabrications lancés,

ajouter ces sorties aux quantités en stocks pour reconstituer le stock matières et

composants avant lancement des ordres de fabrications. Cette opération va

permettre de lancer sous SAP les ordres de fabrications en cours, ce qui va

débiter automatiquement les stocks et va les ramener à leur niveau à la date

considérée comme la date de reprise.

Les vérifications effectuées donnant satisfaction, la Direction de l’usine et le

comité de projet prendront la décision d’effectuer la migration des quatre usines

vers SAP le 1er octobre, avec la reprise des encours, et de faire fonctionner

l’ancien et le nouveau système informatique en parallèle jusqu’aux opérations de

clôture annuelle, puis d’arrêter l’ancien système dès que la clôture annuelle aura

été validée.

sur 73

Poursuite de l’industrialisation.

A la demande du groupe fonctionnel de l’équipe, nous allons organiser les

traitements sur la plate-forme avec d’une part la création d’un menu principal :

et la création de menus secondaires.

Chaque choix du menu principal donne accès à un menu secondaire, sauf bien

sûr le choix « déconnexion » qui fait sortir de l’application.

Mais nous allons surtout regrouper les traitements de migration proprement dits

pour pouvoir les lancer plus facilement de façon répétitive. Nous ajouterons la

possibilité d’inhiber certaines étapes comme les formatages de zone ou les

transcodages pour faciliter la recherche d’erreurs lors de la mise au point des

traitements.

sur 73

Les importations et exportations de fichiers sont des opérations simples puisqu’il

suffit par exemple pour des fichiers CSV de remplacer les points virgules par le

séparateur de valeur, char(253), et les retours chariot, char(13), par des

séparateurs d’attributs, char(254) ce qui se fait globalement par enregistrement

entier et ne nécessite que deux instructions; ou d’utiliser la fonction d’extraction

de sous-chaîne de caractères pour les fichiers avec des enregistrements de

format fixe.

Nous allons organiser les traitements en « lot de migration », un lot est un

ensemble de fichiers cibles qui doivent être fournis en même temps. Un écran de

saisie va permettre la constitution des lots. Cet écran va également permettre de

choisir d’appliquer ou non le formatage des zones et de procéder ou non aux

transcodification. Il permet également de choisir le format des fichiers cibles qui

peuvent être des fichiers UNIVERSE ou des fichiers « texte ». Ceci pour faciliter la

mise au point des traitements de migration.

sur 73

Une fois le lot de migration défini et les fichiers sources importés, il faut lancer le

traitement de prise en compte des fichiers sources.

Ce traitement effectue les contrôles définis par la description des fichiers sources

et donne lieu à un rapport de traitement.

sur 73

L’étape suivante consiste à lancer les traitements de contrôle des fichiers

sources (il s’agit ici des contrôles définis par l’écran de « saisie des contrôles ») :

Ce traitement donne également lieu à un rapport.

L’étape suivante est constituée par la mise en œuvre des

rapprochements (constitution des données cibles):

sur 73

Des utilitaires et des services vont être développés et ajoutés à l’application, ils

seront regroupés dans un sous-menu spécifique :

Il permettront en particulier de chaîner automatiquement tous les traitements

d’un lot défini sans avoir à lancer chacune des étapes. Il comporteront aussi des

fonctions de duplications de descriptions de fichiers ou de tables de traitements

(contrôles et rapprochements) pour n’avoir que quelques modifications à saisir

pour définir un nouveau traitement similaire à un traitement déjà défini.

Le dernier choix est un outil de test des fonctions développées, il permet de saisir

les paramètres en entrée d’une fonction et de visualiser le tableau dynamique

des sorties ainsi que le tableau des anomalies rencontrées. Il permet de basculer

vers l’éditeur pour effectuer des modification dans la fonction, de la compiler et

de la cataloguer, puis de revenir dans la phase de tests. Cette possibilité va

considérablement accroître la vitesse d’écriture et de mise au point des

fonctions.

sur 73

sur 73

Quatrième phase, dédoublonnage et épuration des

fichiers.

Programme de travail de juillet à fin septembre.

Pendant que le groupe fonctionnel et le programmeur chargé de la

documentation vont réaliser la troisième phase, le reste de l’équipe s’attaque

aux problèmes liés à l’épuration des fichiers sources, et plus particulièrement au

dédoublonnage des fichiers Clients et Fournisseurs, c’est l’objet du troisième

prototype. L’objectif est de disposer d’une première version vérifiant la faisabilité

à la fin du mois de juillet, pour disposer d’un outil capable d’effectuer un

dédoublonnage des fichiers Clients et Fournisseurs si possible vers le 15

septembre, et en tout cas avant la fin du mois de septembre avec un taux de

succès qui puisse être considéré comme acceptable par les utilisateurs finaux.

L’épuration des fichiers sera abordée à partir du mois d’août, dans la mesure ou

les contrôles mis en place pour le traitement des fichiers sources apportent déjà

une partie de la réponse au problème.

Il n’existe pas de liens direct entre les fichiers Clients et Fournisseurs de la

gestion commerciale et de la gestion des achats avec les fichiers de la

comptabilité. L’idée directrice est de traiter ces fichiers avec les outils de la plate-

forme pour constituer des fichiers cibles « identification des clients » comportant

le nom du fichier d’origine et la référence du client dans ce fichier, ainsi que les

informations d’identification (raison sociale, adresse, téléphone, fax, nom du

contact), puis de fusionner les fichiers cibles ainsi obtenus et de les soumettre au

traitement de dé-doublonnage, les « doublons » ainsi obtenus entre fichier

commercial et fichier comptable sont en réalité des appariements et constituent

une table de correspondance identifiant commercial – identifiant comptable ; le

même traitement sera appliqué aux fichiers fournisseurs.

sur 73

Comme nous l’avons évoqué à propos du deuxième prototype concernant la

recréation des liens, nous utiliserons ces techniques pour recharger les

commandes en cours, Clients et Fournisseurs.

Nous devrons également effectuer la reprise de la comptabilité avant la fin du

mois de septembre, et si cela s’avère possible dans SAP, nous envisageons

également de reprendre une partie de l’historique des commandes Clients et

Fournisseurs.

Troisième prototype, dédoublonnage et épuration des fichiers.

Pour rechercher les doublons éventuels dans des fichiers, le traitement va

reposer sur la définition de critères de dédoublonnage qui vont être associés à

une pondération :

- Doublons certains, ils seront traités en tant que doublons, c’est à dire

que l’utilisateur final pourra choisir un « maître » qui sera repris, les

doublons seront exclus de la reprise, mais les dépendances des doublons

(pour des clients et des commandes : les commandes des doublons

seront rattachées au client « maître »).

- Doublons présumés, ce ne sont pas des doublons certains, mais il y a

une présomption forte pour qu’ils le soient, ils seront traités comme des

doublons certains, sauf décision de l’utilisateur final.

- Doublons soupçonnés, il ne seront pas traités comme des doublons, sauf

avis contraire.

sur 73

La recherche des doublons va se faire exclusivement au moyen de fonctions qui

vont être développées, l’objectif étant d’enrichir progressivement la bibliothèque

des fonctions disponibles.

L’appariement de fichiers différents reprendra la philosophie et les outils de la

recherche des doublons. Il ne s’agira pas d’éliminer des enregistrements

redondants mais de rapprocher des enregistrements provenant de fichiers

différents et se rapportant à une même entité. Ces techniques seront utilisées

pour le rapprochement des fichiers Clients de la gestion commerciale et de la

comptabilité, ainsi que pour les Fournisseurs de la gestion des achats avec les

Fournisseurs de la Comptabilité.

Les premières fonctions utilisées sont :

- Accent : remplacement des lettres accentuées et du ç par les lettres non

accentuées, remplacement des tirets par un espace

- Compact : suppression des espaces redondants, suppression des

consonnes doubles

sur 73

- Raisoc : suppression des sigles SA, SARL, … et des mots société, société

d’exploitation, société nouvelle d’exploitation, compagnie, … pour ne

conserver que les mots réellements signifiant.

- Adresse : transformation d’un texte en adresse, puis élimination des

vocables rues, place, boulevard, etc … pour ne conserver que les noms

discriminants.

- Soundex : transformations phonétiques pour rapprocher des mots par

leur prononciation

Le traitement de dédoublonnage peut être conduit par itérations successives en

affinant les critères à chaque itération.

L’édition des doublons, certains, présumés et soupçonnés, permet de

sélectionner les rubriques à éditer pour que l’utilisateur puisse se prononcer et

choisir le « maître » de chaque groupe de doublons.

sur 73

L’utilisateur final devra confirmer ou non la qualité de doublons et choisir le chef

de file de chaque groupe. Ses choix sont ressaisis sur la plate-forme de

migration. Une évolution a rapidement été mise en place avec l’exportation d’un

fichier Excel puis son importation au retour, après mise à jour.

sur 73

Organisation des espaces de travail.

Durant cette phase, le projet va devoir changer de rythme et plusieurs opérations

de migrations vont devoir être menées en parallèle. Nous allons devoir organiser

les espaces de travail pour éviter toutes interférences, mais le fonctionnement de

la base de données UNIVERSE va considérablement nous faciliter la tâche.

Gestion des contenants et des contenus.

Le système UNIVERSE sépare la gestion des

contenants (comptes et fichiers) de la gestion des

contenus (dictionnaires et structures). Sur le plan

physique, un fichier est essentiellement un espace

initial et une taille de bloc à rajouter si nécessaire,

et il comporte deux parties, le « réservoir des

données » et une partie « dictionnaire » du fichier.

Cette partie dictionnaire est utilisée par le langage

de requêtes pour manipuler et présenter les

données. Il contient la définition de chacune des

données élémentaires, le

format de présentation,

les éventuels contrôles

unitaires à effectuer, etc

…

dictionnaire

données

sur 73

Mais un « fichier UNIVERSE » peut être formé de l’association d’une ou plusieurs

parties dictionnaires avec une ou plusieurs parties données, de même qu’à

contrario, un fichier peut ne comporter qu’un dictionnaire et aucune partie

donnée, ou bien le dictionnaire d’un fichier peut se limiter à la définition de la

partie donnée.

L’architecture de « base de données » repose sur la possibilité de créer des liens

entre les différents fichiers. Ces liens peuvent être gérés en totalité

« manuellement » par des séquences programmées recréant les différents

modes de liaisons (accès direct par mémorisation des clés d’accès dans certains

attributs des enregistrements, mais peut également être gérée par

l’intermédiaire des dictionnaires). Il est en effet possible de définir dans le

dictionnaire d’un fichier des attributs virtuels qui sont le résultat d’un lien, par

exemple un fichier commande pourra avoir comme clé un numéro d’ordre,

comme premier attribut le code du client, comme deuxième la date de la

commande, puis la date de livraison souhaitée, comme quatrième attribut les

codes articles commandés sous forme de multivaleurs, comme cinquième

attribut les quantités commandées, et comme sixième attribut les quantités

livrées :

Commande n° xxxx

Commande<1> : client312

Commande<2> : 14/12/2007

Commande<3> : 24/01/2008

Commande <4,1> : article001

Commande<4,2> : article002

Commande<4,3> : article003

sur 73

Que l’on peut aussi représenter par

Commande<4>=article001]article002]article003

Commande<5> : les quantités : 12]6]25

Commande<6> : vide, rien n’est encore livré

Dans le dictionnaire du fichier, on peut définir le code_client (attribut 1), la

date_commande (attribut 2), la date_livraison_demandée(attribut 3), code_article

(attribut 5), quantité_commandée (attribut 6).

Nota bene : il est possible de développer un programme pour la saisie des

commandes avant de s’apercevoir qu’il conviendrait également de gérer la date

réelle de livraison. Il suffit de placer la date réelle de livraison dans l’attribut 7

lorsque l’on écrit la gestion des expéditions, il n’y aura aucune autre modification

à apporter, le programme de saisie des commandes continue à fonctionner, et le

programme qui enregistre les expédition sait stocker la date de livraison réelle à

sa place.

Dans le dictionnaire du fichier, il est possible de déclarer, par exemple, deux

attributs virtuels, le nom du client et la désignation des articles. Pour le nom du

client, l’enregistrement du dictionnaire contiendra le fait qu’il s’agit d’un attribut

virtuel et mentionnera la façon de l’obtenir, en utilisant l’attribut 1 du fichier pour

aller chercher l’attribut 3 du fichier « CLIENTS » (si la raison sociale du client est

en 3), ou même d'aller chercher RAISON_SOC de CLIENT si RAISON_SOC est

défini dans le dictionnaire du fichier CLIENT, et la même chose pour récupérer la

désignation des articles depuis le fichier ARTICLES.

sur 73

L’organisation générale est un système à trois niveaux homogènes permettant à

un concepteur averti d’avoir une vision claire et complète du fonctionnement des

applications qu’il conçoit ; cette vision facilite la conception d’applications

efficaces donc performantes.

La description des fichiers que gère la plate-forme de migration va permettre

très facilement de créer les définitions d’attributs du dictionnaire de chacun

des fichiers sources et cibles, le langage de requête pourra donc être utilisé

avec une cohérence complète vis à vis des données saisies, données qui sont

également accessibles via SQL Server.

Le système permet aussi la création de « pointeurs » qui sont un adressage

indirect des fichiers. Ces pointeurs sont eux-mêmes des dictionnaires, il

permettent donc d’utiliser un fichier sous un nom différent, avec des

dictionnaire

données

dictionnaire

données

dictionnaire

données

le compte "système"

compte"de travail"

fichierd'un compte

Le compte maître

appelé aussi "compte système",il contient le langage d'exploitation,

le langage de requêtes, le langage de programmation et les maîtres dictionnaires

définissant les comptes de travail

Un maître dictionnaire

un maître dictionnaire définit un espace de travail appelé "compte",

il contient les programmes et procédures catalogués (ordres exécutables)

et les dictionnaires définissant les fichiers de travail

Un dictionnaire de fichier

un dictionnaire définit un espace de stokage des données

appelé "fichier",il contient également la définition des

données permettant l'utilisation du langage de requêtes

sur 73

définitions d’attributs différentes, il peuvent être assortis de critères de

sélections et servent à bâtir des « vues » à la manière des vues de BO.

Les pointeurs permettent également de rendre accessible dans un compte un

fichier situé dans un autre compte. C’est cette propriété que nous allons

utiliser pour gérer un compte « programmes » de développement contenant

l’ensemble des programmes et des fonctions de l’application, ainsi que les

dictionnaires définissant les fichiers utilisés par l’application.

Le générateur d’application STRATEGE permet de gérer le versionnage des

différents éléments et de tracer les modifications en cours. Chaque

développeur disposera d’un compte de tests contenant ses données propres

et dont les fichiers programmes pointent sur le compte « programme de

développement ». Lors de la création d’un compte de test, une procédure

effectue la création des fichiers et des dictionnaires associés à partir des

dictionnaires du compte « programme de développement ».

Nous allons également créer un compte « programme de production »

analogue au compte « programme de développement » mais contenant la

dernière version validée de la plate-forme de migration. Ce compte

« programme de production » permet la création de comptes opérationnels

destinés à réaliser les migrations opérationnelles. Pour chaque site à migrer,

nous allons créer un compte opérationnel par grand domaine, à savoir :

- Gestion de production

- Gestion commerciale

- Comptabilité

- Gestion du personnel

Chacun de ces comptes opérationnels pointe sur les programmes et fonctions

du « compte «programme de production ». Lorsqu’une modification a été

apportée et testée par un développeur, puis validée par le Directeur du projet,

sur 73

elle est « livrée », c’est à dire qu’elle est intégrée dans le compte programme

de production et qu’elle devient utilisable par tous. Les modifications

apportées à la partie « Client » sont gérées par l’interface WINPICK qui vérifie

à chaque connexion que le poste client qui se connecte dispose bien des

dernières versions validées de tous les composants du poste client et effectue

automatiquement les mises à jour éventuellement nécessaires. Pour ne pas

créer d’interférence, nous implanterons l’interface WINPICK client dans deux

arborescences différentes du poste de travail, l’une pour être utilisée avec un

compte de développement et l’autre pour être utilisée avec les comptes

opérationnels. Cette organisation donnera pleinement satisfaction.

La mise en production d’une nouvelle application, dès lors qu’elle est dotée de

son propre compte de travail s’effectue par la création d’un nouveau compte,

c’est à dire la création d’un nouvel enregistrement dans un fichier du compte

système, ce sont les seules mises à jour effectuées dans ce compte, il n’y a

pas de possibilité de conflit de mise à jour et cette opération ne nécessite donc

ni arrêt de la machine ni déconnexion des utilisateurs. Il faut ensuite

simplement créer les fichiers du compte et les charger, ce qui peut se faire « à

la main » par les techniciens de l’exploitation, mais peut également être

facilement totalement automatisé.

Lorsqu’il s’agit de compléter une application déjà existante, une interruption

de quelques minutes est nécessaire, le temps de créer les nouveaux fichiers

s’il y en a, et de cataloguer les nouveaux « verbes », ce processus est lui aussi

totalement automatisable et peut être exécuté de nuit, il n’y a alors aucune

interruption de service.

sur 73

Poursuite des migrations opérationnelles.

Le prototype SAP de la gestion de production sera chargé fin juillet pour l’usine

de Baldenheim, les responsables de la production de l’usine le valideront

pendant le mois d’août. Le paramétrage SAP des trois autres usines de la

branche sécurité sera effectué entre le 15 août et le 15 septembre.

L’un des membres du groupe fonctionnel de l’équipe projet et l’un des deux

programmeurs vont prendre en charge les migrations concernant la gestion de

production et fourniront les fichiers nécessaires au chargement du prototype

SAP de gestion de production de chacune de ces usines dans le même délai.

L’autre membre du groupe fonctionnel et le deuxième programmeur vont

prendre en charge la migration des comptabilités des quatre usines.

L’équipe technique, chargés de l’élaboration du troisième prototype prendra

en charge la migration des Clients et des Fournisseurs ainsi que la reprise des

commandes en cours puis la reprise des historiques de commandes. Elle va

introduire à cette occasion une étape supplémentaire en amont de la

migration proprement dite. Dans cette étape baptisée « précible » les fichiers

cibles auront la même structure que les fichiers sources, mais les contrôles

appliqués sur les fichiers sources vont permettre de restreindre le domaine de

la reprise des données, ainsi les clients dont la dernière commande date de

plus de deux ans ne seront pas repris, les fournisseurs dont aucune référence

n’est citée dans les gammes et nomenclatures et qui n’ont pas reçus de

commandes depuis plus de trois ans ne seront pas repris.

L’auteur du présent mémoire, pour sa part prendra en charge la paye et la

gestion du personnel à partir de la deuxième semaine de septembre. La

reprise du fichier du personnel et des totalisateurs annuels de la paye ne

posent pas de problèmes particuliers, seule la reprise des congés et des droits

sur 73

pose un problème analogue au problème de la reprise des encours, a savoir

que le fichier des droits aux congés fonctionne comme un fichier stock qu’il

faut incrémenter des congés déjà pris pour pouvoir charger les congés déjà

pris qui vont venir diminuer le « stock » de droits aux congés.

Les opérations vont être cadencées de la façon suivante :

- 15 et 16 septembre 1998 : traitement des doublons Clients et

Fournisseurs pour les usines de Baldenheim et de St Dié.

- 17 et 18 septembre 1998 : traitement des doublons Clients et

Fournisseurs pour les usines de Dreux et d’Aubagne.

Les utilisateurs disposent d’une semaine pleine pour rendre leurs arbitrages.

- 21 et 22 septembre 1998 : Chargement des Articles et des Gammes et

Nomenclatures pour les usines de Baldenheim et de St Dié.

- 23 et 24 septembre 1998 : Chargement des Articles et des Gammes et

Nomenclatures pour les usines de Dreux et d’Aubagne.

Les utilisateurs ont l’interdiction de créer ou de modifier des articles ou des

gammes ou nomenclatures jusqu’au 5 octobre.

- 24 et 25 septembre 1998 : chargement sur la plate-forme des

arbitrages sur les doublons et chargement des Clients et des

Fournisseurs sous SAP pour les usines de Baldenheim et de St Dié.

- 28 et 29 septembre 1998 : chargement sur la plate-forme des

arbitrages sur les doublons et chargement sous SAP des Clients et des

Fournisseurs pour les usines de Dreux et d’Aubagne.

Les utilisateurs ont l’interdiction de créer ou de modifier des Clients ou des

Fournisseurs jusqu’au 5 octobre.

- 28 et 29 septembre 1998 : Chargement sous SAP des commandes en

cours (Clients et Fournisseurs) pour les usines de Baldenheim et de St

Dié.

sur 73

- 30 septembre et 1er octobre 1998 : Chargement sous SAP des

commandes en cours (Clients et Fournisseurs) pour les usines de

Dreux et d’Aubagne.

Les utilisateurs ont l’interdiction de créer ou de modifier des commandes

Clients ou Fournisseurs jusqu’au 5 octobre.

- 1er octobre 1998: arrêté comptable des quatre usines

- 1er octobre au soir : fourniture par les quatre usines des fichiers stocks

et des lancements de fabrication en cours, fourniture des fichiers

comptables et des fichiers de la paye et de la gestion du personnel

- 2 et 3 octobre 1998 : traitements de migration des comptabilités, des

stocks et des ordres de fabrication en cours, de la paye et de la

gestion du personnel.

- 3 octobre : chargement dans SAP des stocks et des ordres de

fabrication en cours

- 5 octobre matin : chargement dans SAP des fichiers de la comptabilité

et de la gestion du personnel.

5 octobre 1998 à 13 heures : début de la gestion des quatre usines

avec SAP, en marche en double avec les anciens systèmes de gestion.

sur 73

Bilan des quatre premières migrations.

L’ensemble de l’équipe apporte un soutient aux quatre usines pendant la

première semaine de fonctionnement sous SAP. Les quatre usines de la

branche Sécurité de la Compagnie des Signaux ont démarré leur gestion

complète sous SAP au début du quatrième trimestre de 1998, avec reprise des

encours. Elle vont travailler en double pendant le dernier trimestre 98,

effectuer 3 clôtures mensuelles, une clôture trimestrielle et une clôture

annuelle en marche en double qui toutes donneront satisfaction, et nous

seront en mesure de répondre à toutes les questions des utilisateurs

concernant les valeurs prises par une données à partir des données

conservées sur la plate-forme de migration qui constituent de véritables

« traces » de l’élaboration des données chargées dans SAP. La marche en

double prendra fin à la fin du mois de janvier 1999 et les anciens systèmes

seront définitivement mis hors service à la fin du premier semestre 1999.

L’équipe a consommé 540 jours homme dont 140 jours homme de formation,

250 jours pour le développement de la plate-forme de migration et 150 jours

homme pour les opérations de migrations proprement dites, dont 9 migrations

de la gestion de production (5 transitoires de l’usine de Baldenheim pour la

mise au point du paramétrage de SAP et 4 migrations définitives pour les 4

sociétés de la branche).

Les performances des traitements se révéleront suffisamment bonnes pour ne

pas nécessiter de transposition sur les machines Unix beaucoup plus

puissantes, et la totalité des traitements de migration seront exécutées sur le

serveur Windows.

Il convient de noter au passage que la compatibilité totale existant entre

UNIVERSE sous Windows et UNIVERSE sous Unix ne posait aucun problème

pour le transfert des traitements, ce que nous démontrerons aux responsables

sur 73

de CISI au mois d’octobre en transférant les fichiers sources, les tables de

pilotage des contrôles et les tables de rapprochements ainsi que les

programmes batch et les interpréteurs sur la machine Unix équipée

d’UNIVERSE, nous exécuterons les traitements sur le serveur unix (avec des

temps divisés par 10) puis nous rapatrierons les résultats sur le serveur

Windows.

Suite et fin du projet.

Au cours de l’été 1998, le Directeur de la Branche et le directeur du

Département concernés de CISI ont quitté la société, et lors du comité de

projet qui se tient à la fin de la première semaine de fonctionnement sous SAP,

la Compagnie des Signaux prends position pour stopper son investissement

dans la plate-forme de migration, estimant qu’ils sont les seuls à financer un

investissement purement CISI. Les nouveaux Directeurs recrutés par CISI ne

sont pas réellement convaincus de l’intérêt représenté par la plate-forme de

migration dans la mesure où ils souhaitent réorienter la stratégie commerciale

du département vers les entrepôts de données, sans se rendre compte que

l’un des problèmes concrets qui vont se poser à la mise en œuvre de ces

entrepôts sont justement l’épuration des fichiers et les chargements initiaux

qui sont typiquement des opérations de migration de données.

Le Directeur du projet, auteur du présent mémoire, réussira à obtenir 70 jours

de complément d’investissement pour réaliser le manuel d’utilisation et l’aide

en ligne qui vont s’ajouter aux 70 jours homme prévus (la prévision initiale de

200 jours a été revue à la baisse) pour la migration des comptabilités et des

gestions du personnel des 4 sociétés de service du groupe.

Le projet va se poursuivre par la migration des comptabilités et des gestions

du personnel des quatre sociétés de service du groupe au cours des mois

sur 73

d’octobre et de novembre. Ici aussi, la reprise des encours permettra un

démarrage sous SAP au 1er novembre pour 2 des sociétés et au 1er décembre

pour les 2 autres, avec un fonctionnement en double jusqu’à la clôture

annuelle et un abandon de l’ancien système au cours du premier semestre

1999, soit avec plus de un an d’avance pour la branche « Services ».

Planning final du projet :

Conclusions

Bilan final du projet.

La consommation finale du projet sera de 670 jours homme pour 1 000 jours

homme de budget, soit un gain global de 33% en incluant le développement

de la plate-forme de migration, et de 220 jours pour les opérations de

migration pure, soit un gain de 78% (rappel : les estimations initiales ont été

faites sur la base des standards CISI utilisés pour l’estimation des projets de

migration de données).

Le développement de la plate-forme de migration a nécessité 320 jours

homme, manuel utilisateur et aide en ligne inclus, ce qui est une performance

tout à fait remarquable compte tenu du fait qu’au début du projet, seul le

Directeur de Projet connaissait le système et le langage dans lequel le

développement a été réalisé et compte tenu de la forte complexité

fonctionnelle et technique, et qu’aucun des membres de l’équipe n’avait de

connaissance SAP.

sur 73

Cette performance est la résultante des composantes suivantes :

- L’équipe projet avait une très bonne connaissance des problématiques

« métier » de la migration de données,

- Cette petite équipe était très soudée après un projet difficile de 18

mois réussi ensemble,

- La démarche RAD et l’intégration des « utilisateurs » (le groupe

fonctionnel) et des « développeurs » (le groupe des concepteurs -

programmeurs) dans une même équipe, apporte des temps de

réaction très brefs.

- Chaque idée directrice de la solution a fait l’objet d’une vérification

rapide mais opérationnelle avant d’être développée dans une forme

plus aboutie.

- La puissance et la souplesse de la base de données et de son langage

de programmation ainsi que la qualité et la facilité d’utilisation des

outils de développement ont été des facteurs déterminants.

sur 73

Les extensions envisageables.

Les générateurs de programmes.

La première des extensions techniques envisageables concerne les temps de

traitements, elle consistera à compléter les interpréteurs des tables de

traitements (tables des contrôles et tables des rapprochements) par des

générateurs de programmes qui interpréteront également ces tables de

définition des traitements, non pas pour exécuter les traitements décrits par

les tables, mais pour fabriquer automatiquement des programmes exécutant

les traitements définis. La première version de générateurs à réaliser serait

bien sûr la version générant des programmes écrits en « basic UNIVERSE »

(c’est le nom du langage de programmation associé à la base de données),

pour profiter des gains de performances qui en découleront.

Mais une fois ces générateurs développés et mis au point, il serait également

facile d’en développer des version générant du Cobol, du C, ou à priori tout

autre langage. Les traitements pourront alors être spécifiés et mis au point sur

la plate-forme de migration à partir de jeux d’essais constitués d’échantillons

représentatifs des fichiers sources, en utilisant les interpréteurs puis une fois

les traitements validés sur jeux d’essais, les mêmes spécifications donneront

lieu à la génération de programmes de traitements plus performants pouvant

être utilisés sur d’autre machines que la plate-forme de migration. Par

exemple pour déporter les contrôles des fichiers sources sur le système source

lui-même, ou pour fractionner et paralléliser les traitements de migration sur

plusieurs serveurs.

Les analyseurs de données.

La plate-forme de migration pourra être dotée de programmes effectuant des

analyses des données sources, par exemple pour effectuer des comptages

sur 73

d’occurrences des valeurs prises par une rubrique, ou des captures des

différentes valeurs prises par une rubrique pour constituer une table des

valeurs qu’il sera ensuite éventuellement possible de remplacer par une

codification. Ces aspects peuvent se révéler particulièrement intéressants

dans le cadre de l’alimentation d’un entrepôt de données. Par exemple

l’analyse du fichier mensuel des cartes grises, que l’auteur a réalisé lors du

projet suivant, a montré que les ventes de véhicules d’occasion sont très

largement réalisées au sein d’un même département, et dans une proportion

encore plus large au sein d’une même région administrative ; cette

connaissance a été déterminante pour concevoir des traitements

d’alimentation efficace pour l’entrepôt de données d’un grand constructeur

automobile.

La consultation des traces.

La conservation de la trace de l’ensemble des traitements effectués sur la

plate-forme de migration a permis de renseigner avec précision les utilisateurs

finaux sur l’origine de données qui les ont intrigué après la mise en route du

nouveau système de gestion, et a également permis de corriger des arbitrages

qu’ils avaient rendus à tord. Ainsi un client, doublon présumé d’un autre client

a pu être restitué. Ces traces pourront facilement devenir directement

accessibles par l’utilisateur final.

L’élargissement du champ d’action.

Le projet mené a démontré qu’il était possible de mettre en place un E.RP. à

n’importe quelle période de l’année, et surtout qu’il était possible d’effectuer

une reprise complète des encours.

Mais l’intérêt de la fiabilisation et de l’épuration des données apportées par

une opération de migration ne se limite pas à des actions exceptionnelles de

sur 73

ce type, une entreprise a tout intérêt à effectuer périodiquement un nettoyage

de ses fichiers. Au fil du temps les codifications ont pu évoluer, et il n’est pas

rare de retrouver dans les données d’une entreprise des codes obsolètes. Le

dédoublonnage des fichiers clients est une opération dont le bénéfice ne se

limite pas à l’économie de place sur les supports informatiques, c’est aussi,

par exemple, un élément important de la gestion du risque client, que l’on

peut penser plafonné à une certaine valeur alors qu’en réalité l’existence de

plusieurs doublons peut multiplier le risque pris bien au delà de la valeur

voulue ou garantie. L’élimination des doublons a également un impact majeur

sur l’image que l’entreprise donne d’elle-même lors de ses opérations de

marketing, surtout lorsque celle-ci sont orientées vers des prospects.

Lors de la mise en place d’un entrepôt de données, c’est le volume des

données à gérer qui focalise l’attention. Il est pourtant ici aussi nécessaire de

considérer cette opération comme une migration de données, surtout si la

mise en place de l’entrepôt comporte une phase de chargement initial à partir

de fichiers existants. L’orientation « Gestion de l’information Client » de la

plupart des entrepôts de données rend nécessaire une opération de

normalisation et de fiabilisation des données et le situe généralement dans le

domaine de la fiabilisation des adresses postales. Les volumes mis en jeux

rendent encore plus important l’efficacité du dédoublonnage, d’autant plus

que le rapprochement de fichiers d’origines diverses repose sur les techniques

utilisées pour cela. De plus, dans le contexte d’une forte sollicitation de

l’entrepôt de données, par exemple pour des activités de marketing, il est

nécessaire de réserver des « fenêtres temporelles » pour effectuer les mises à

jour des données. L’utilisation d’une plate-forme multi-serveurs, associant un

serveur de spécification, des serveurs de traitement et des serveurs de

consultation des résultats des processus, permet d’industrialiser et de

sur 73

paralléliser les traitements, elle permet également d’effectuer ces opérations

en temps masqués. Lorsque l’utilisation d’un entrepôt de données impose des

fenêtres de mise à jour, elles sont alors réservées aux mises à jour proprement

dites.

L’ingénierie de données est un domaine très intéressant, porteur

d’efficacité pour les entreprises qui y ont recours, elle apporte aux

informaticiens des problématiques complexes dès lors qu’ils se

situent dans une démarche d’industrialisation des processus.

Au sein d’une société de services et d’ingénierie informatique, la

constitution d’une équipe spécialisée, opérant sur une plate-forme

interne à la SSII, apporte des gains de productivité très important,

mutualise les risques des projets et permet sans difficulté d’intégrer

et de former des débutants. Elle permet de construire une offre « clé

en main » autour de prestations comme la mise en place d’un ERP ou

l’initialisation d’un entrepôt de données, elle permet d’élargir l’offre

en incluant un « service après vente » pour les données traitées.

sur 73

Bibliographie :

Le système d’exploitation Pick, Malcom Bull; Paris

Masson 1989

The Pick Operating System, Joseph St Jhon Bate et Mike Wyatt

New York

Van Nostrand Reinhold

1986

CONSERVATOIRE NATIONAL DES ARTS ET...

Documents

Transcript of CONSERVATOIRE NATIONAL DES ARTS ET...