Stand vs customisation

1Entire contents © 2003 Baumgartner Papiers Holding SA All rights [email protected]

Implantation d’un ERP

ÉtapesFacteurs clés de succès

Écueils à éviter

Entire contents © 2003 Baumgartner Papiers Holding SA All rights [email protected] 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 SIBP Holding SA

CEO Resp. division CFO CIO

Commercede

papierFibertec Transfor-

mationFinanceHoldingEmballage

Chef de projets Chef de projets Chef de projetsChef de projets Chef de projets

RéseauBureautique / Messagerie / Internet / Sécurité / etc.

ERP

Proc

essu

s m

étie

rs

Proc

essu

s m

étie

rs

Proc

essu

s m

étie

rs

Proc

essu

s m

étie

rs

Proc

essu

s m

étie

rsResp. division Resp. division Resp. division Resp. division CFO

Info

rmat

ique

Info

rmat

ique

Info

rmat

ique

Info

rmat

ique

Info

rmat

ique


Question fondamentale (entre autres)

Home made

PackageIntegration

ERP


ERP – Cinq étapes

BPRAtelier

d ’évaluationde package

Proofof

conceptImplantation

Miseen

production

Partenariat avecCTP

> 1x <

Partenariat avec le fournisseur choisi>>>>>>>>> 1x par division <<<<<<<<<

Interne


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 ’organisationSource:

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

Achats Ventes 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


Réclamation Correction de stock

Gestion du parc de

véhicules


Réclamation

Transport

Facturation

Key Process Process secondaire

CLIENTS

FOURNISSEURS

CONCURRENTS

Serv. Vente Externe

ETAT

-PO

LITI

QUE

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


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�� Selection��Selection��

RFIScope

AtelierEdition RFI

Choix 10/16Edition Scenarios

Visites FournisseursTraitement 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 ProcessModeler

• 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.


Implantation de la solutionChange Management

Méthode d’implantationPlanification des ressources / Equipe

d’implantationStandard vs Customized

Les InterfacesLes impressions et le reporting


Implantation de la solution

• 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…

Prob

lèm

es



• 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.

Cau

ses



• 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…

Obj

ectif

s



• 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.Im

plan

tatio

n de

la s

olut

ion


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

Rapportd ’avancement

CONCEPT.

Rapport d ’auditRapport d ’audit

Enregistrements de testProgramme de formation

Solution configuréeManuel technique

Description de la configuration

Rapport d ’avancemnt Rapport d ’avancement

CONFIGURAT.

Programme de formation

Enregistrements de test

Construction de la base de données

Enregistrements de test

Rapport d ’audit

Rapport d ’avancement

IMPLANTATION

Plan d ’amélioration

Rapport de fin de projet

DEMARRAGE

Impl

ex


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.

Ris

ques



• 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é…

Ris

ques



• 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é…

Ris

ques



• 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

Ris

ques


La planification des ressources

• Qui choisir, avec quelles compétences ?

– Le chef de projet

– Les Process Owners

– Les Key Users

Impl

anta

tion

de la

sol

utio

n


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

ConsultantMPM

ConsultantMPM

ConsultantCOM

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

Pour

cent

age

d'ac

tivité

Equipe de projetConsultants

Impl

anta

tion

de la

sol

utio

n


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

Impl

anta

tion

de la

sol

utio

n


Standard vs Customized

• 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 ! Impl

anta

tion

de la

sol

utio

n


Standard vs Customized

• 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é… !!!

Prin

cipe

s


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…

Prob

lèm

es


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 !!!


Les impressions et le reporting

• 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…


Les impressions et le reporting

• 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


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 leremplacer



• 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.



Solution stabiliséeProcessus 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 !

Documents

Stand vs customisation