Steelcan
Steelcan
Steelcan
Sur le site de l'ANACT on trouvera un résumé de l’étude « ERP, organisation, travail » faite par Bénédicte
Geffroy-Maronnat, Marc Bidan, Redouane Elamrani et Frantz Rowe
Avec 2 millions de tonnes, SteelCan, une unité opérationnelle d’un grand groupe européen, est le
premier producteur mondial d’aciers pour emballage (alimentaire, boîtes boissons, aérosols, bouchage et
emballages industriels). Les six sites de productions se trouvent dans trois pays : 3 sites en France, 1 site en
Belgique et 2 sites en Espagne dont les activités commerciales et industrielles sont coordonnées par
SteelCan.
Face à un marché d’emballage de plus en plus concurrentiel marqué par la baisse des prix de vente,
l’accroissement des exigences des clients et l’arrivée des emballages plastiques, l’entreprise SteelCan a
lancé un projet global appelé « First » dont l’objectif est de devenir le numéro 1 de l’emballage en
reconstruisant l’organisation, ses processus et ses SI. La dispersion des sites de production et la
multiplication des applications informatiques rendait très difficile la rationalisation des ressources et l’atteinte
des objectifs de performance. C’est dans ce contexte que le projet « En Réseau », faisant partie du projet
global fut lancé. Il avait pour but de doter l’entreprise d’un SI moderne permettant de fédérer son
fonctionnement au sein d’un même réseau.
Les premières réflexions par le comité de direction autour d’une solution ERP ont été entamées
durant le printemps 2000 pour aboutir en juillet 2000 au choix de SAP, entériné par la direction centrale du
groupe. SAP R/3 4.6 fut sélectionné comme solution informatique pour l’homogénéisation du SI du groupe et
remplacé un certain nombre de systèmes internes. Le progiciel Baan était la première solution informatique
adoptée par le groupe avant la fusion avec les entités belges et espagnoles. Baan fut abandonné en raison
notamment des difficultés économiques de l’éditeur.
Selon le DSI, trois objectifs sont assignés au projet SAP :
1. Atteindre un système commercial unique. L’objectif était de remplacer les quatre systèmes
commerciaux différents issus de sociétés différentes. Le slogan « Gestion Commerciale unifiée :
One face to the customer » signifie que quelle que soit l’entité qui produit, distribue et facture le
produit, le processus vis-à-vis du client doit être unique.
2. Améliorer les services clients à travers l’amélioration de la planification inter-usines et le
rapprochement des pôles industriel et commercial (les résultats financiers n’étaient pas
satisfaisants). Il s’agissait d’améliorer l’organisation des commandes en renforçant le partage et la
fiabilité des informations entre les différents acteurs comme avec les clients.
3. Disposer d’un outil de pilotage par la marge.
Ces objectifs n’étaient pas explicitement présentés par le comité de direction. Ils se sont précisés au
moins 8 mois après le lancement effectif du projet SAP. Le périmètre organisationnel SteelCan concerné par
la mise en place de SAP est constitué des 5 sites suivants : Basse Indre, Florange, Liège, la défense et
Mardyck. Dans chaque site, le périmètre fonctionnel touchait les services suivants : vente, finance, contrôle
de gestion, qualité, achats et production. SteelCan a opté pour un déploiement global (Bing-Bang) limité aux
sites français et le site belge1.
1
Le processus de fusion a engendré des problèmes techniques au moment des montées de versions mais également lorsqu’il s’agissait d’intégrer les sites espagnols et celui
d’Italie qui a été évalué à 500.000 euros car il n’appartient pas à la même entité juridique de SteelCan. La solution de contournement consisterait à rajouter SteelCan Italie
comme un type de client et non en tant qu’entité, ce qui nécessite un paramétrage et un développement spécifique. C’est une contradiction par rapport aux discours
commerciaux de SAP.
marge : suivi • PP (Production
précis des coûts Planning) :
de production par planification de la
article en relation production
avec les prix de • QM (Quality
vente. Management) :
• Prévisions gestion des
commerciales : réclamations
budget des ventes • FI (Finance) :
équilibré selon la comptabilité
contrainte des générale
sites. • CO (Controlling
• Planification : operational):
gestion des ordres contrôle de
de fabrication, gestion
déclaration de • Le configurateur
production. de SAP
• Configuration des • BW (Business
articles à fabriquer
Warehouse)
• Infocentre et
reporting
Le premier travail consistait à analyser et à reconfigurer les processus clés de gestion des différents
sites de production de l’entreprise. La deuxième partie du travail portait principalement sur l’unification des
SI à travers l’adoption d’un seul outil de gestion de commande et la construction détaillée des modules SAP.
Suite au lancement du projet, une structure projet appelée « Bulle » a été mise en place, suivant le
concept « green field », un environnement détaché des routines de l’entreprise pour produire de nouveaux
processus. Neuf ateliers (données techniques, configurateur, achats et stocks, planification et suivi de
fabrication, réclamations, contrôle de gestion, comptabilité générale, administration des ventes et Infocentre)
ont été crées et ont fonctionné en parallèle durant deux ans. 60 personnes ont été mobilisées pour le projet
dont 25 personnes représentant les fonctions de SteelCan 2 et 35 consultants SAP et spécialistes en
organisation.
L’équipe projet chargée de la mise en place de SAP s’est constituée autour de groupes de travail composés
de :
• correspondants métier et utilisateurs clés représentant la MOA (Maîtrise d’Ouvrage)
• consultants fonctionnels et techniques SAP de l’intégrateur représentant la MOE (Maîtrise d’œuvre)
• consultants A-Systems pour l’assistance de la MOA et le suivi des travaux MOE.
La première configuration de l’équipe projet chargée de SAP était la suivante : une MOA SteelCan
chargée de réaliser l’expression besoins, le regroupement des différentes demandes, de la mise en œuvre
et du développement. L’équipe A-System apportait de l’assistance à la MOA et assurait le suivi des travaux
de la MOE. Cette dernière était représentée par un intégrateur dont la responsabilité est d’assurer le
paramétrage du système SAP UPR et la mise en production des modules.
La deuxième configuration voyait l’équipe A-System (MOE) prendre la responsabilité, dés juillet 2003, de
la mise en œuvre de SAP, des développements et de l’assistance auprès des utilisateurs SteelCan. Cette
responsabilité était assurée jusque là par un intégrateur tiers. Ce dernier a produit des formations pour les
consultants de A-System afin d’assurer un transfert de connaissances et de compétences. Certains
consultants clés ont intégré la structure A-System pour une période limité pour supporter cette phase de
transfert. La MOA SteelCan se recentrait sur la collecte et traitement des nouveaux besoins et demandes
d’évolution.
Le coût initial du projet SAP était chiffré à 8 millions d’euros en septembre 2000 avant de passer à 10
millions en juillet 2002 et finir à 30 millions en juin 2003.
2
Une équipe interne d’informaticiens était intégrée à l’équipe projet. L’objectif est d’apprendre des consultants et de se préparer à reprendre en main le système après le
départ des consultants et construire des interfaces entre SAP et les autres applications maintenues par SteelCan.
S’il est difficile de dégager un effet quantitatif net de la mise en place de SAP, il est néanmoins
possible de repérer certaines tendances globales. Après avoir présenté les principaux résultats et
changements, nous discuterons les effets organisationnels du projet ERP à travers trois points : le choix de
l’ERP par les dirigeants, les problèmes liés à la détermination de la cible organisationnelle et la réduction du
périmètre d’intégration et enfin l’opportunité partiellement ratée d’une reconfiguration des processus. Nous
exposerons également certains problèmes résultant de la stratégie managériale des dirigeants à savoir la
formation des utilisateurs SAP et la politique d’habilitation.
Bien que la gestion ait été plus longue et coûteuse que prévu, les coûts ont été largement dépassés
pour un périmètre fonctionnel un peu réduit, finalement si l’on reprend les trois objectifs initiaux, il apparaît
que les deux premiers objectif visant l’homogénéisation du système d’information ont été atteints. SteelCan
utilise aujourd’hui un seul système dans sa relation avec les clients. Le traitement des commandes est
opérationnel et fluidifié même si quelques aspects techniques (problèmes de prix et de facturation) et
organisationnels (partage des responsabilités entre les SC et les AC) restent à améliorer. La planification
s’effectue maintenant de façon souple entre les usines et cela permet de rationaliser les choix de production
qu’il s’agisse de la fabrication ou de la logistique.
Le dernier objectif le pilotage par la marge n’est pas encore pleinement atteint en 2004, il est en voie
de réalisation.
Par ailleurs, les entretiens ont fait ressortir des niveaux de satisfaction variés. L’atteinte des objectifs
fait que, pour la Direction, le projet est clairement un succès ; les dérapages de la gestion de projet sont
imputés à un effort nécessaire d’apprentissage sur ce type de système auquel il fallait s’adapter alors que
jusqu’ici l’entreprise fonctionnait avec des systèmes développés en interne et patiemment construits en
interne pour correspondre parfaitement aux besoins. La plupart des utilisateurs clés ont vécu un projet
intéressant et se montrent aujourd’hui satisfaits.
Cependant, pour l’utilisateur de base, et notamment les AC, le bilan est encore en demi-teinte.
Certes avec le système le processus est bien suivi et le travail beaucoup plus rigoureux et précis. Mais la
contrepartie est le temps passé à entrer des données et le changement que cela représente par rapport aux
attentes du métier.
Malgré les efforts de l’équipe projet, il était difficile de stabiliser les changements réalisés et de les
ancrer dans les pratiques quotidiennes des acteurs. Dans le nouvel environnement organisationnel, les
actions de l’équipe projet auprès des utilisateurs n’ont pas pu rendre les processus de gestion plus visibles.
La vision transversale dans un environnement intégré était presque absente pour des utilisateurs. Le Vice-
Président chargé des opérations industrielles trouvait « dommage qu’on doive attendre SAP pour connaître
et apprendre de nouvelles choses concernant les processus de SteelCan ». Malgré l’apport de cette
dimension processus, l’utilisation de SAP n’était pas orientée dans une dimension processus. Dans ce sens,
les actions de conduite de changement n’ont pas insisté suffisamment sur les transmissions coopératives
des informations permettant au travail d’autrui d’être fait correctement.
Un point très sensible a souvent été ignoré et passé sous silence durant la période
d’implémentation. C’est celui de tenir compte de la diversité des pratiques professionnelles et des sous-
cultures qui existent eu sein de l’entreprise afin de développer de nouveaux modes de coopération. Les
systèmes et les pratiques locales ont persisté et étaient à l’origine des dysfonctionnements organisationnels.
Ces pratiques de « bricolage » des données et des informations dans des systèmes annexes (Excel,
Access) ont été préjudiciables à la fiabilité de l’intégration.
Même les études réalisées sur Baan ne furent pas utilisées pour évaluer SAP. Pour les dirigeants,
SAP était la meilleure solution pour SteelCan qui allait supporter tous les objectifs, résoudre les problèmes
organisationnels et réaliser des économies.
Du point de vue des dirigeants, les anticipations sur les effets et les avantages à tirer s’inscrivaient
dans une perspective déterministe et supposée bénéfique. L’environnement était perçu comme très
contraignant et la solution ERP a jailli rapidement sans que le problème ait pu être sereinement posé et
sérieusement étudié. Cette entame étonnante, sans repères et avec un enthousiasme excessif, s’est soldée
par une diminution du périmètre d’intégration et l’entrée dans une phase de perturbation organisationnelle
marquée par le prolongement de la durée du projet.
3.2 Ambition initiale large établie sans cadrage global suffisant pour un horizon temporel trop
rapproché.
Il est usuel de souligner les bénéfices que l’entreprise peut tirer notamment d’un resserrement des
liens entre les différentes fonctions à travers le partage d’un référentiel unique. Mais de la proclamation
officielle de cette nécessité, à travers l’intégration des processus dans une base de données commune, à sa
traduction organisationnelle, il y a toute l’épaisseur d’un apprentissage organisationnel de l’intégration et de
ses interdépendances qui ne se décrète pas. Ceci est d’autant plus vrai dans le cas de l’entreprise
SteelCan.
Suivant les premiers objectifs, la cible organisationnelle initiale était large et le projet devait être
terminé en 6 à 9 mois. Cependant, au fur et à mesure de l’avancement du projet, le périmètre
organisationnel touché par SAP a été largement réduit (gestion de production, des approvisionnements et
des stocks, la comptabilité) face aux difficultés rencontrées. Les délais initiaux ont également été fortement
allongés. Il était difficile, dans un contexte international et culturel aussi divers, de mener de façon
satisfaisante un tel projet dans des délais aussi brefs. Ceci indique clairement des problèmes
d’apprentissage dans ce nouveau type de progiciels.
Le projet SAP fut lancé en septembre 2000 pour une fin prévue en avril 2001. En décembre 2001, le
déploiement n’était pas encore lancé et la direction de projet décidait alors de réduire le périmètre de projet
en conservant les outils de gestion de production. Le premier périmètre fonctionnel SteelCan était large. Il a
été réduit dans le domaine de la production et de la comptabilité. En effet dans le domaine de la production,
l’intégration des processus dans SAP était délicate, longue et coûteuse. La spécificité du métier de
sidérurgie, une industrie de transformation, et des différents sites de production était très forte et les
fonctionnalités standards de SAP ne répondaient pas aux différentes exigences. Des risques de blocages
étaient réels. La décision finale fut de conserver le système de gestion de production local pour la
programmation des lignes, la localisation des produits et la déclaration de production et de réaliser des
interfaces pour l’échange des données avec SAP.
3
Propos rapportés par les principaux acteurs de la direction qui étaient plus au moins impliqués dans le processus de mise en place de SAP.
La mise en production en juin 2002 avorta à cause des insuffisances du système. Les oublis de la
MOA et la mise en œuvre non satisfaisante de la MOE ont aboutit à une solution instable et incapable de
répondre aux besoins de l’entreprise. En octobre 2002, la « Bulle » a terminé son travail et une nouvelle
mise en production de SAP a été faite en janvier 2003.
Sept 2000 Déc 2001 Juin 2002 Jan 2003 Avr 2003
Les AC ont commencé à passer réellement les commandes dans SAP en janvier 2003 dans le cadre
du déploiement qui correspond au premier lot de commandes 4. Ce premier déploiement ne correspondait
pas aux attentes, beaucoup d’anomalies ont été constatées. Les autres lots ont été terminés en décembre
2004. Les autres modules ont été déployés en avril 2003.
Les difficultés rencontrées par SteelCan peuvent être expliquées tout d’abord par l’incapacité de
SAP de répondre aux spécificités de l’activité SteelCan. Bien que assez complet, SAP n’arrivait pas à offrir
les meilleures solutions pour toutes les fonctions de l’entreprise. De plus, une telle couverture exigeait des
dirigeants de fournir des efforts d’adaptation organisationnelle pour arriver à atteindre les périmètres
souhaités.
Selon les principaux acteurs de la direction, le choix d’adopter SAP était une bonne solution pour le
groupe Arcelor malgré les retards constatés dans la livraison de la solution finale. SteelCan disposait d’un
patchwork d’applications et de systèmes et il était difficile d’obtenir une vision d’ensemble et globale aussi
bien au niveau SI que métier. Cependant, l’équipe projet n’a pas pu profiter de SAP pour parvenir à simplifier
les processus métiers de l’entreprise. Cette mise en place s’est accompagnée par une remise en cause
timide des processus en place, malgré la bonne volonté des acteurs avant le lancement du projet.
Trois mois après le commencement du travail de reconfiguration des processus, l’équipe projet a
pris conscience de la complexité des processus qui se mettaient en place derrière les objectifs fixés par la
direction générale. L’équipe projet a eu des difficultés à reconfigurer les processus en place. Ceci a eu
comme résultat une « Customisation » de SAP, c’est à dire la réalisation des développements spécifiques
sans toucher au code source de SAP. Les processus standards SAP étaient incapables de couvrir tous les
besoins métier de l’entreprise. De plus, il n’y avait pas une grande volonté de la part de certains
4
L’entreprise a découpé le carnet de commandes en 5 lots. Leur intégration était faite de façon progressive.
5
Le module HR pour gérer la table des commerciaux en liaison avec les clients ; le module MM n’est pas utilisé pour les processus d’achats, mais
plutôt pour les références articles ; le module FI pour centraliser toutes les données.
responsables de procéder à une réingénierie complète des processus. La plupart d’entre eux voulaient
reconduire les mêmes modes de fonctionnement. Selon le DSI :
« Les directions de chaque site ont souvent fait valoir leurs propres spécificités et la particularité de
leurs modes opératoires plutôt que de militer pour une homogénéisation globale des différents
processus. Les écarts en termes de pratiques et de cultures étaient importants entre les sites ».
L’harmonisation des pratiques métiers à travers l’adoption d’un référentiel unique en l’occurrence
SAP était restreinte par la volonté des entités de renforcer leur territoire en accentuant leurs différences. Ces
différences étaient difficiles à gérer vu le contexte international dans lequel évolue l’entreprise (différence
des langues, d’histoire et de culture d’entreprise), les difficultés d’aboutissement du projet SAP et enfin la
non maîtrise des processus SAP. Les anciens processus de chaque unité et service ont été partiellement
reproduits. Les questions de reproduction de l’existant et d’intégration ont parfois pris le dessus sur les
problématiques de transversalité.
Si la volonté de revoir le mode de fonctionnement a été présente, le niveau de reengineering des
processus a été souvent limité, en partie faute d’analyse préalable suffisante et complète des processus
existants. Une certaine naïveté et sous-estimation de la complexité d’intégration des processus de
l’entreprise dans l’ERP ont conduit à un prolongement de la durée du projet et à manquer l’opportunité
d’amélioration des processus en place.