Stand vs customisation

1
Entire contents © 2003 Baumgartner Papiers Holding SA All rights reserved
marc-antoine.busigny@baumgartner.ch
Implantation d’un ERP
Étapes
Facteurs clés de succès
Écueils à éviter

marc-antoine.busigny@baumgartner.ch 2
Table des matières
Présentation de BP Holding
Problématique du système d’information
Méthodologie du choix d’un ERP
Implantation de l’ERP
Stabilisation de la solution
Business Improvement

… le Commerce de Papiers

… Fibertec

… la Transformation

… l’Emballage alimentaire

… et une seule vision de son SI
BP Holding SA
CEO Resp. division CFO CIO
Commerce
de
papier
Fibertec
Transfor-
mation
Finance
Holding
Emballage
Chef de projets Chef de projets Chef de projetsChef de projets Chef de projets
Réseau
Bureautique / Messagerie / Internet / Sécurité / etc.
ERP
Processusmétiers
Processusmétiers
Processusmétiers
Processusmétiers
Processusmétiers
Resp. division Resp. division Resp. division Resp. division CFO
Informatique
Informatique
Informatique
Informatique
Informatique

Question fondamentale (entre autres)
Home made
Package
Integration
ERP

ERP – Cinq étapes
BPR
Atelier
d ’évaluation
de package
Proof
of
concept
Implantation
Mise
en
production
Partenariat avec
CTP
> 1x <
Partenariat avec le fournisseur choisi
>>>>>>>>> 1x par division <<<<<<<<<
Interne

10
BPR
Business Process Re-Engineering

« Best practice » lors d’implantation ERP
• un Business Process Re-
Engineering détaillé devrait
être fait avant de démarrer un
projet ERP
• le BPR met à jour les
insuffisances du système
actuel
• le BPR tente de maximiser la
productivité par une
réorganisation des divisions,
départements et ressources
de l ’organisation
Source:
www.erpfans.com
BPR

Le Principe CSA
Comprendre, Simplifier,
Automatiser
• Comprendre la manière de
faire actuelle
(Diagrammes de flux,
brainstorming)
• Simplifier et épurer les
processus
(Eliminations, combinations,
reorganisations)
• Automatiser les processus
(ERP, EDI, ...)Source:
www.erpfans.com
« Best practice » lors
d ’implantation ERP
BPR

BPR – Big picture
Commande en
entrée
Etablissement
d'offre
Réclamation
Gestions
clients
Facturation
Etablissement
d'Offre
Modification
de commande
Achat de
marchandise
Commande en
entrée
Ventes du stock Logistique
AchatsVentes Transit
Entrée de
marchandise
(OGS)
Stock minimal
Achat de
marchandise
Réclamation
Gestion des
articles
Gestion des
fournisseurs
Préparation
d'une
commande
Arrivage /
Réception
marchandise
Modification
de commande
Réclamation
Correction de
stock
Gestion du
parc de
véhicules
Modification
de commande
Réclamation
Transport
Facturation
Key Process
Process
secondaire
CLIENTS
FOURNISSEURS
CONCURRENTS
Serv. Vente
Externe
ETAT-POLITIQUE
Gestion des
fournisseurs
Gestions des
articles
Gestion des
clients
Key Process
déjà traité

Processus clé

BPR – Exemple processus

BPR - Avantages
• Introduit une approche Processus dans des structures
organisées hiérarchiquement
• Permet de comprendre le fonctionnement de
l’entreprise… et d’identifier les processus clés
• Permet d’éliminer les redondances et simplifie les
processus
• Apprend les bases de la modélisation aux process
owners et key users (capacité d’abstraction)
• Permet de se distancier du fonctionnement actuel de
l’entreprise
• Permet à l’entreprise de s’organiser pour supporter le
nouveau système d’information (bonnes personnes aux
postes clés)
• Motive le team en vue d’une implantation future
• Permet de définir le périmètre du projet (project scope)
et les fonctionnalités à implanter

17
PEW
Package Evaluation Workshop

Méthodologie classique
Evaluation
(3)
Selection
(1)
Scope

PEW - Méthodologie utilisée
RFI et
Scenarios
Recherche
et Analyse
SelectionScope
Raffinement
Point de départ

Selection SelectionSelection
RFIScope
Atelier
Edition RFI
Choix 10/16
Edition Scenarios
Visites Fournisseurs
Traitement RFIs
Choix 5/10
Évaluation Critères de Sélection
Démonstrations Choix
FinalistesÉvaluation démonstrations
Recherche et Analyse
Démarche

Proof of Concept
• Démontrer les fonctionnalités
principales
• Capacité à configurer la fonctionnalité
dans un délai très limité
• Aptitude à résoudre les scénarii avec
les fonctions standards du produit
• Vérification que le produit est capable
de couvrir le périmètre
• Perception par le fournisseur des
problématiques de l’entreprise
• Détermination du candidat à travailler
avec nous.

Proof of Concept
• Préparation de scénarios complets
• Séminaire de quatre jours par
fournisseurs
– lundi matin : vente stock
– lundi après-midi : vente transit
– mardi matin : achat
– mardi après-midi : transport
– mercredi matin : production Elco
– mercredi après-midi : production Fibertec
– jeudi matin : finance (financière)
– jeudi après-midi : finance (analytique)
• Un jour d’analyse des écarts

Critères de choix
• Enterprise Process
Modeler
• Modèles de référence
papier
• Gestion des attributs
• Configurateur de
produit
• Gestion des lots
• MRP, APP
• Rechercher un
Partenaire avec qui le
Dialogue est possible

Négociations commerciales
• Effectuer les négociations avec les 2
finalistes
• In- ou Outsourcing de la solution ?
• Déterminer un contrat fixed time, fixed
price (Le scope doit être précis)
• Négocier le prix des licences
• Négocier le prix des consultants
• Calculer le TCO de la « solution »
complète sur 5 ans permet d’éviter des
surprises.

25
Implantation de la solution
Change Management
Méthode d’implantation
Planification des ressources / Equipe
d’implantation
Standard vs Customized
Les Interfaces
Les impressions et le reporting

• Le majorité des projets ERP
prennent du retard
• La majorité des projets ERP
coûtent davantage que prévu
• Les objectifs fixés ne sont souvent
pas atteints
• Certains projets n’aboutissent
jamais…
Problèmes

• Un ERP est fondé sur des Best Practices et
l’entreprise doit s’y adapter.
• Des modifications du produit Core sont
effectuées (guerre entre les barons du
business et l’IT)
• On pense que changer les habitudes des gens
est plus aisé que de faire des modifications...
• Plus l’entreprise est résistante aux
changements plus le risque d’échec de
l’implantation est grand.
• La structure de l’entreprise doit être figée
durant la durée de l’implantation.
Causes

• Implantation sans aucune modification
• Interfaces « invisibles » (intégrées dans le
processus standard)
• Mise en place de haute-disponibilité hardware
• Respect du budget
• Respect des délais
• Transfert de connaissance entre les
consultants et les Process owners
• + atteindre tous les objectifs de l’entreprise…
Objectifs

• Choix du Chef de projet
• Choix des Process Owners
• Choisir la langue officielle du projet
• Dilemme pouvant se poser :
– Compétence Business vs Incompétence Système
d’information
– Compétence Système d’information vs
Incompétence Business

Change Management
• La volonté de changement doit exister à tous
les niveaux
• La Direction de l’entreprise doit s’impliquer
dès le démarrage de l’implantation
• L’implantation d’une ERP est un projet
d’entreprise et non pas un projet informatique
• Les utilisateurs doivent s’approprier la
solution
• Un ERP est un projet stratégique pour
l’entreprise et doit être considéré comme tel
• Le périmètre impacté par un ERP est toujours
sous-évalué par la Direction.
Implantationdelasolution

La méthode d’implantation
Activités de l ’entrepriseGestion de projet Jalons
Potentialité d ’amélioration des processus
Définition de projet
POSITIONMT
Rapport d ’audit
Processus redéfinis
Description des processus
Rapport
d ’avancement
CONCEPT.
Rapport d ’auditRapport d ’audit
Enregistrements de test
Programme de formation
Solution configurée
Manuel technique
Description de la configuration
Rapport d ’avancemnt Rapport d ’avancement
CONFIGURAT.
Programme de
formation
Construction de la base de données
Rapport
d ’audit
Rapport
d ’avancement
IMPLANTATION
Plan d ’amélioration
Rapport de fin de projet
DEMARRAGE
Implex

Méthode d ’implantation
• Phase 1 : Positionnement
– Les consultants posent des questions par rapport à
l ’existant
– Oubli du travail effectué dans le BPR par les utilisateurs
– Risque : on reproduit l ’existant dans le nouveau système
– Risque : les consultants tentent de réduire le périmètre du
projet (fixed time, fixed price…)
• Phase 2 : Conception
– Les outils de modélisation ne sont pas ou pas assez
utilisés
– La capacité d ’abstraction des process owners est
insuffisante
– La Direction ne s ’implique pas -> les « master data » ne
permettront pas de faire « Out of the box » le reporting ou
le controlling nécessaire au pilotage de l ’entreprise.
Risques

• Phase 3 : Configuration
– Incompréhension de la structure des données dans le
système
– Incompréhension de la signification du mot « intégré »
– Difficulté d ’utilisation du système
– Problème du maintien du paramétrage entre
l ’environnement de Production et l ’environnement de
Test
– Problème de documentation du paramétrage et des
processus.
– Plan de formation des end-users trop court
– Importance des spécifications de tests non comprise
– Changement de structure de la société…
Risques

• Phase 4 : Implantation
– Consistance des données à reprendre
– Données incomplètes nécessitant un retraitement
important
– Risque report du démarrage (si toutes les données ne
sont pas reprises à temps)
– Difficulté de sortir les utilisateurs de leur fonction pour les
former
– Incapacité pour certains utilisateurs d ’utiliser le système
– Changement de structure de la société…
Risques

• Phase 5 : Démarrage
– Big Bang : le démarrage ne se passe pas bien
• Définir la deadline jusqu ’à laquelle un rollback peut
être effectué.
– Transition Plan non adapté à la problématique business
Risques

La planification des ressources
• Qui choisir, avec quelles
compétences ?
– Le chef de projet
– Les Process Owners
– Les Key Users

Exemple de structure de projet
Comité de Pilotage
Chef de projet
Coordination
Brunegg
Coordination
Crissier
Vente Stock Vente Transit Achats Logistique
Sponsor du Projet
Directeur de
projet
Consultant
MPM
Consultant
MPM
Consultant
COM
Responsable
Qualité
Garant du projet
Consultant
Technique
Responsable
Qualité
Chef de projet
informatique Resp. EPM
Front Office e-Business e-BusinessCRM/SMS
Spécialiste
Papier

La planification des ressources
Evolution de la charge de l'Equipe de projet
0
20
40
60
80
100
120
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5
Phases
Pourcentaged'activité
Equipe de projet
Consultants

Comité de projet
• Fonction
– Donneur d’ordre du projet, décision finale sur la
solution proposée par la Direction de Projet.
• Type de poste
– Ligne (ligne, relation de hiérarchie entre les cases
supérieures et inférieures)
• Responsabilité
– Validation de la solution proposée au niveau
budgétaire et stratégique
• Dépend de :
– N/A

• Stay release compliant !
• Pas de modifications du produit Core
• Les interfaces ne sont pas considérées
comme des modifications
• Lors du design de la solution, penser
au produits interfacés !
• Attention ! Les consultants ont
tendance à faire faire des modifications
=> Participation du chef de projet à toutes
les séances !

• Il existe toujours un workaround…
• Il est possible d’accéder aux
données via SQL (ODBC,…)
• Un certain nombre de « Must » au
démarrage peuvent devenir des
« nice to have » avec le temps
• Ne pouvons-nous pas changer
notre façon de travailler ?

Les interfaces
• Principe : 1 des 2 applicatifs doit, si
possible, rester standard.
• Diminution du coût en cas de release.
• Diminution du coût de développement.
• Diminution du nombre de tests
• Rester le plus près du flux standard
• Le coût du développement d’une
interface peut rapidement dépasser le
prix du Logiciel interfacé… !!!
Principes

Les interfaces
• Difficulté en phase de test de simuler
une charge réelle
• Difficulté de simuler tous les cas
possibles
• Certaines transactions déclenchent des
triggers de façon inopportune
• L’interface doit être réécrite ou du
moins retestée à chaque changement
de release.
• Attention aux quittances partielles,
marques de fin de traitement, etc…
Problèmes

Les interfaces
• Utiliser des technologies simples et
éprouvées (FTP,...)
• Développer des mécanismes de contrôle des
anomalies
• Prévoir la possibilité de régénérer des
télégrammes
• Prévoir des logs permettant un accès aisé via
SQL
• Garder les spécifications de test de
l’implantation pour les réutiliser à chaque
changement de release -> exiger les
spécifications fonctionnelles
• Un changement de release de l’OS peut avoir
un impact sur les interfaces !!!

• L’établissement du Corporate Design dans le
nouveau système prend du temps !
• Le coût du développement des impressions
(internes et externes) est souvent sous-évalué
• Le nombre de documents est parfois très
important
• Les possibilités de reporting standard ne
correspondent pas aux attentes Business
• Un grand nombre d’informations manquent
parfois sur les impressions standards
• Il est difficile de tester et valider des
statistiques sans données…

• Démarrer le design des documents
relativement tôt
• Faire valider chaque document externe
par la Direction
• Prévoir un portail d’accès au données
pour un reporting plus flexible et
l’établissement de tableaux de bord
• Assurer dès le démarrage du projet que
les catégorisations (clients, articles,…)
permettront de réaliser les statistiques
souhaitées

49
Go Live

Go Live - Stabilisation
• Il ne faut pas imaginer pouvoir résoudre les bugs au
moment du démarrage !
– L ’intégration étant totale les erreurs se propagent dans tout le
système instantanément.
• Le travail de l’équipe Finance est plus important !
– Chaque opération génère une écriture en finance…
– Prévoir une augmentation de l’effectif au démarrage
• La performance de l’organisation (management) peut
être évaluée lors du démarrage
– Réactivité par rapport aux problèmes
– Capacité au changement et à la réorganisation des processus
– Communication en interne et externe
• Les process owners vont passer le majorité de leur
temps à faire du support !

• Certain collaborateurs ne parviendront pas à travailler
avec le système
– Changement de poste ou de fonction
– Changement du collaborateur…
• La capacité de réaction de l’IT est beaucoup plus
grande de celle du reste de l’organisation
– Les éventuels bugs sont rapidement identifiés et corrigés
– Le changement des habitudes de travail est beaucoup plus long
– Le remplacement de collaborateurs prend du temps
• L’Entreprise dépend d’un nombre restreint de Process
Owners
– S’ils quittent l’Entreprise alors que le transfert de connaissance
n’a pas eu lieu c’est une perte de substance
– Seul un consultant (ou le chef de projet) peut éventuellement le
remplacer

• Une Equipe de support (Help-Desk 1er niveau)
doit éventuellement être créée
– Dans le cas où les Process Owner ne sont pas
suffisamment compétents…
• Déplacement des compétences de
l’Informatique vers le Business
– Une grande partie du paramétrage est effectué par le
Business lui-même.

53
Solution stabilisée
Processus d’amélioration

• Développement d’un portail
d’accès aux données
• Amélioration des processus
– Simplification
– Diminution du temps de traitement
• Formation continue
– Maintenir la connaissance assimilée lors de
l’implantation

• Mise en place de fonctions de
controlling
• Bénéfice de l’intégration
– Evaluation du coût de certaines opérations
• Evaluation des apports d’une
nouvelle release

That’s all Folks !

Stand vs customisation

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Stand vs customisation

Similaire à Stand vs customisation (20)

Stand vs customisation