|
Le contrô le ATP - du progicie l
intégré a la solution spécifique
|
|
|
Lors du choix d'un progiciel on prend en compte
les aspects materiel et logiciel. Et c'est lors de la mise en
place qu'on découvre des procedures et des règles de
travail.
4 Le progiciel - un bilan
Le progicie l APO est un succes, car il a
répondu tres rapidement au probleme du « First In First Out »
(FIFO) qui péna lisait les clients stratégiques (comme Renault)
au profit de clients de moindre importance.
Mais il est aussi un échec, pour 3 raisons
:
n Le besoin est incomp let ; on a démarré
dans l'urgence une solution qui ne répondait pas a tous les besoins
(uniquement l'Auto, par exemp le).
n On rencontre des problèmes dans APO parce
que R/3 a été trop « customisé » ; les
Modification Requests (MRs), par exemp le, sont inconnues d'APO.
n On rencontre un problème techno logique ; on se
heurte en effet a une boite noire ( le CIF, et surtout le
liveCache)
Figure 75 - Quantites temporaires et
liveCache
(Source SAP)
|
Le contrôle ATP - du progicie l integre a la
solution specifique
|
|
|
5 Du progiciel au specifique
En juillet 2007 commence la pre-etude pour cDDQ
(controle industrie l). C'est un projet de 1,35M€ pour une charge de
1130j/h, en « mixte », c'est a dire avec du deve loppement en
offshore.
J'ai congu l'architecture generale et les trois
sous-systemes BRMS, ATP et VM.
J'ai detaille la partie BRMS et j'ai de legue la partie
technique d'ATP a un collegue. Les specifications genera les sont terminees en
novembre 2007.
Les premieres usines ont demarre en mode « Parallel
run » en juin 2008.
Depuis e lles sont presque toutes en « Operational
Run », et on dep loie cDDQ sur d'autres bassins (dernier en date la
Roumanie).
En septembre 2008 demarre le projet intitu le «
Load management » (LM) pour remp lacer le 1A et le 1B. La mise en
production, initia lement prevue pour mars 2009, est reportee a juin 2009 apres
le deve loppement d'additifs. Ma lheureusement des problemes graves dans le
workflow de la commande font capoter le projet, qu'on annu le. Une fois les
problemes reso lus il est question de re lancer le projet, mais une
reorganisation du business le rend caduc.
Cette reorganisation aboutit en octobre 2009 a un
nouveau projet, qu'on baptise « Allocation Management » (AM) pour
bien signifier qu'il integre une nouvelle gestion des allocations.
Le projet est decoupe en deux releases :
n La release 1, mise en production en octobre
2010
n La release 2, extension de la release 1 avec le check
au niveau mois, mise en production en decembre 2010
Le budget est initia lement estime a 470k€ dont
340k€ pour l'IT.
I l sera revu a 407k€ pour l'IT, change requests
comprises.
La vo lonte de passer au specifique vient de la
rigidite de APO ; sa conception et son parametrage ont prouve les limites du
systeme dans chacune de ses fonctions :
n Difficu ltes de determination des pots
n Manque d'homogeneite, notamment avec les modifications
de commande
n Incapacite d'ana lyser et d'exp liquer l'a lgorithme
de check
n Opacite des mecanismes APO (CIF,
liveCache)
n Manque de convivia lite dans la gestion des
allocations
Arce lorMitta l a vou lu faire table rase de ce passif,
et a choisi le sur-mesure, le « full specifique ».
|
Le contrô le ATP - du progicie l
intégré a la solution spécifique
|
|
|
| 
