Cours DSCG Management des systmes dinformation

Les ERP

J. Sornet 2014

APPLICATIONS

Ces applications sont essentiellement pdagogiques. Elles visent une assimilation assez large de la problmatique des ERP et vont au-del du rfrentiel. Elles ne constituent aucunement des modles de sujets dexamen et, dailleurs, le chapitre 3 (lERP dans lorganisation) ny est pas spcifiquement trait car il peut tre illustr par plusieurs anciens sujets du DSCG et les exercices proposs dans divers ouvrages.

1 LES PRINCIPES ET LA CIBLE DE LERP

Exercice 1.1 Proposer une solution logicielle argumente dans chacun des cas suivants:A - PME de 300 personnes fabriquant portes et fentres sur mesure aprs tude et devis. Lentreprise, tablie depuis longtemps, a une activit assez stable en sous-traitance dentreprises du btiment ou pour des particuliers.Le systme dinformation, qui doit tre rnov, exploite les lments suivants:- une gestion de production couple un logiciel dtudes permettant llaboration des devis techniques. Cet ensemble a comme origine un organisme professionnel inter-rgional et il est parfaitement adapt et soutenu;- un pack comptabilit gnrale, gestion de la paie et gestion commerciale intgr et interfac avec la GPAO mais trs ancien et ne devant plus tre maintenu dans huit mois, aprs disparition de la SSII ditrice de ces logiciels;- un ensemble dapplications bureautiques parfaitement adaptes aux besoins pour la dtermination et le suivi des cots. Ces applications bnficient dextractions automatiques depuis la GPAO.

B - PME commerciale de 120 personnes en pleine croissance, devant absorber une entreprise similaire et doubler ainsi son activit.Lentreprise dispose dun logiciel comptable performant, mais le reste de la gestion est pris en charge par un ensemble dapplications spcifiques prsentant de nombreux dfauts (interoprabilit problmatique, maintenance alatoire, coexistence de plusieurs rfrentiels de donnes).

Exercice 1.2 Dterminer les raisons qui ont pu freiner le dveloppement des ERP dans les petites entreprises.

2 LE MARCHE DES ERP

Exercice 2.1 Expliquer les fusions ou acquisitions constates depuis plusieurs annes chez les diteurs.Exercice 2.2 Comment peut se justifier le choix dun ERP open-source?Exercice 2.3 Caractriser loffre SAP destine aux PME (All in One, One, By Design) partir du site de cet diteur ou de vos connaissances. Vous expliquerez le rle et la place des outils danalyse Crystal et Business Object dans ces ERP.Exercice 2.4 Aprs avoir diffrenci les offres SAP, SAGE et CEGID partir des sites de ces diteurs et de vos connaissances, dterminer des solutions possibles partir des produits de ces diteurs qui soient en adquation avec les trois situations suivantes.Cas 1: groupe industriel employant 4000 personnes, rparties dans cinq units, dont deux implantes aux USA. Lentreprise fournit des moteurs et des boites de vitesse diffrents constructeurs automobiles.Cas 2: entreprise employant 800 personnes. Lentreprise est implante en France, o elle ralise 100% de son chiffre daffaires dans le domaine du ngoce de produits alimentaires prissables. Ses clients sont essentiellement des centrales dachat, des industries de transformation et des collectivits.Cas 3: boulangerie industrielle employant 55 personnes. Lentreprise ne dispose daucune comptence informatique et son activit est fortement dpendante de la ractivit de ses commerciaux.

4 LIMPLEMENTATION DUN ERP ET SES RISQUES

Exercice 4.1 Rapprocher les tapes prsentes dans le document CEGID ci-dessous des tapes classiques du dveloppement de projet de systme dinformation.

Exercice 4.2 A partir des exemples prsents ci-dessous (exemples publis sur internet par divers diteurs), rcapituler dans un tableau les principales raisons du choix dun ERP.

5 LES PROBLEMES LIES AUX ERP

Exercice 5.1: Aprs tude de lextrait du texte de Patrick Besson ci-dessous, vous ferez ressortir les facteurs de risque dimplantation dun ERP et comment les limiter. En quoi lvolution actuelle des ERP peut-elle limiter ce risque?

Autopsie de l'chec (2003)

Patrick Besson (Patrick Besson est professeur au Groupe ESCP, o il enseigne l'organisation et le contrle de gestion. Il enseigne galement et dirige des recherches Paris IX-Dauphine).Source: http://www.lesechos.fr/formations/manag_info/articles/article_10_12.htm

Les ERP, Enterprise Resource Planning , sont une des technologies pivots de l'entreprise de demain. Mais avons-nous la maturit et les comptences managriales pour les utiliser ?

Dans le numro 1 de L'Art du Management de l'Information , T. H. Davenport soulignait que les discours sur les technologies de l'information accentuaient la perspective technologique au dtriment de la perspective informationnelle. Une fois de plus, on parlait de la belle machine et non pas des besoins de l'entreprise. Cette erreur de perspective conduisait une mauvaise apprciation de la problmatique du management de l'information. Le propos de T. H. Davenport peut tre radicalis. L'illusion technologique nous conduit oublier que les technologies de l'information sont des technologies de l'organisation. En prenant les ERP comme exemple, nous montrerons les risques qu'encourent les entreprises en ngligeant la ralit organisationnelle. Cette ngligence est un handicap important dans la course l'intgration informationnelle. Elle pose aussi cruellement la question des capacits d'apprentissage et d'innovation de l'entreprise.

Le dfi de l'intgration informationnelle

Le rve deviendrait-il ralit ? Une seule donne de gestion fiabilise et stocke dans une base de donnes unique, accessible dans tous les recoins de l'organisation et partage par tous les acteurs, telles sont les promesses des ERP. Ce mode de traitement intgr constitue une rvolution. Actuellement, les donnes de gestion se caractrisent par l'indisponibilit, l'incohrence, l'ambigut et un cot lev de production. Cette situation de dsintgration informationnelle a des consquences dramatiques pour l'entreprise:- Le client est insatisfait, il ne reoit pas sa commande temps ou il reoit une commande incomplte.- Les systmes de conception, de production, de distribution sont inefficients ; en l'absence de donnes partages, chaque sous-systme s'optimise localement au dtriment de la recherche d'une optimisation globale. - Le systme informatique est clat en de nombreux sous-systmes qui ne communiquent pas, ses cots de dveloppement, de maintenance et d'volution sont levs.- Le management est inefficace, il passe plus de temps se chamailler sur des donnes de gestion diffrentes qu' s'entendre pour exploiter toutes les synergies cratrices de valeur.

Les entreprises considrent les ERP comme la rponse technologique ce syndrome de la tour de Babel, le levier pour exploiter cette rserve de cration de valeur que constitue l'intgration informationnelle.

Mais l'exprience dmontre que les projets ERP sont des projets trs risqus. D'abord, l'effet d'infrastructure et le caractre normatif des ERP fait prendre l'entreprise des risques stratgiques dus l'irrversibilit de leur implantation. Le phnomne ERP est trop rcent pour avoir une juste valuation de ces risques en termes de perte de comptitivit potentielle - o se diffrencier quand toutes les entreprises auront install des ERP standards ? - ou de perte d'indpendance au profit de quelques diteurs de progiciels en position dominante. Ensuite, le caractre global et structurant des ERP fait prendre l'entreprise des risques d'innovation dus la complexit des projets. L'implantation d'un ERP vise changer l'organisation. Le passage d'un outil progiciel standard un dispositif organisationnel ad hoc ncessite donc un processus d'innovation. Ce processus est risqu. Il peut ne pas produire les effets escompts. Il n'existe pas de chiffres fiables permettant d'valuer les risques d'innovation. Les entreprises sont peu prolixes sur leurs difficults. L'chec reste tabou. Mais les exemples et les rumeurs qui circulent dans les milieux informs laissent pressentir un taux d'chec trs important. partir de l'analyse d'un chantillon de 21 projets, nous avons pu identifier sept types de risques d'innovation.

Quelle est l'origine de ces risques d'innovation ? Le bouc missaire est vite trouv. C'est la faute des progiciels intgrs, trop complexes, trop rigides. Certes, la technologie des ERP est complexe, mais l'outil n'est pas la cause essentielle des checs. Le risque prend sa source dans le management de l'innovation. On reconnat que les projets ERP sont des projets d'organisation, mais on continue aborder l'implantation d'un ERP comme un projet informatique classique. A-t-on pris la mesure du sens du mot organisation ? Qu'est-ce qu'une organisation ? Qu'est-ce qu'organiser ? Comment conduire un projet global d'organisation ? Des rponses inappropries ces trois questions expliquent les difficults rencontres dans l'implantation des ERP. L'chec sanctionne l'inadquation des stratgies d'intgration informationnelle.

L'quilibre du systme organisationnel

La conflictualit est un bon indicateur pour comprendre l'organisation. Au travers du conflit, les acteurs rvlent ce qui fait sens et ce qui compte pour eux. Ils entrent en conflit pour manifester un dsaccord et essayer de faire entendre leurs points de vue. Dans le processus conflictuel se dvoilent et se confrontent les conceptions de l'organisation partages par les diffrents acteurs. C'est dire l'intrt qu'il y a couter la conflictualit dans un projet ERP.

Celui-ci n'est qu'une suite de conflits qui s'acclrent et s'amplifient mesure que le projet se concrtise. On en dnombre quatre types : - Le conflit de mode opratoire porte sur la dfinition et la meilleure manire de raliser une tche ou un ensemble de tches. Par exemple, les acteurs vont se confronter sur la question des procdures de passation d'une commande, sur la manire de saisir une facture, sur les mthodes de calcul d'un cot de revient. - Le conflit de mtier porte sur le type de comptences ncessaires, sur la distribution de ces comptences entre les acteurs, sur l'organisation des filires mtiers. La mise en place d'un ERP transforme plus ou moins profondment les mtiers. D'anciens mtiers deviennent obsoltes, de nouveaux mtiers mergent. Le profil des mtiers change mais les individus restent et s'interrogent sur leur avenir. - Le conflit d'influence porte sur la distribution du pouvoir. Ce type de conflit se manifeste sous des formes diffrentes, souvent dtournes. Le pouvoir n'est pas une question qui se traite frontalement dans l'entreprise. Le conflit d'influence se manifestera donc au travers de questions souvent techniques : par exemple, la confidentialit et la scurit des donnes ou le degr de standardisation des nomenclatures client, produit ou comptable. Dans de nombreuses entreprises, la diffrenciation informationnelle a t un moyen de construction et de consolidation des pouvoirs locaux. En voulant rduire ces autonomies informationnelles, la dynamique de la standardisation impulse par un projet ERP remet en cause l'quilibre des pouvoirs. - Le conflit de valeur porte sur les finalits de l'organisation et sur les modalits de la cration de valeur. De nombreux projets ERP s'articulent autour d'une refonte des systmes d'information financire et de contrle de gestion. Cette refonte est souvent l'occasion pour l'entreprise de moderniser sa culture et ses pratiques de gestion conomique. Dans de nombreuses entreprises marques par la domination des cultures techniques, la rticence vis--vis de la culture financire vhicule par les projets ERP est une source trs importante de conflit. Les acteurs n'acceptent pas la domination de la culture financire avec son corollaire, le durcissement des critres de cration de valeur.

Quelles leons pratiques peut-on tirer de cette conflictualit extraordinaire ? Les initiateurs de projets ERP se trompent de concept d'organisation. Ils vhiculent la mme image de l'organisation-machine que les ingnieurs industriels de la premire heure. Comme eux, ils confondent l'criture de procdures et la construction d'une organisation. Illusionns dans un exercice de r-engineering virtuel , ils oublient que l'organisation est un systme sociotechnique, un subtil quilibre de modes opratoires, de mtiers, de relations d'influence et de systmes de valeurs. Les mmes causes provoquant les mmes effets, comme eux, ils refont les mmes erreurs.

Les initiateurs des projets ERP ont-ils compris l'organisation ? Des propos souvent entendus tels que compte tenu des cots d'adaptation, il vaut mieux adapter l'organisation au progiciel plutt que l'inverse en font douter. Malgr le dveloppement des sciences de l'organisation, ils sont rests attachs aux vieux concepts tayloriens du dbut du sicle. L'ambigut de la notion de processus en tmoigne. Un processus est-il autre chose qu'une macro-gamme ? Rduite ses modes opratoires, rebaptiss pour la circonstance processus , l'organisation fait de la rsistance. Organiser, c'est reconstruire une communaut autour de nouveaux modes de coopration. Les checs constats proviennent de l'imprparation des quipes projets grer cette problmatique communautaire qui s'exprime au travers des conflits de mtiers, d'influence et de valeurs.

Les stratgies de l'action organisationnelle

Agir dans une organisation suppose une posture stratgique. Comme sur un march, il faut comprendre les dynamiques profondes, identifier les acteurs en prsence, valuer les manoeuvres possibles, choisir une option, dfinir une tactique de mise en oeuvre. Dans cette perspective, on distingue deux stratgies d'action:- La routinisation, qui vise dployer ou renforcer une norme d'action dj approprie par les acteurs et lgitime leurs yeux. L'action organisationnelle met dans ce cas l'accent sur l'instrumentation de cette norme d'action, sur la formation des acteurs l'utilisation des nouvelles procdures et sur le renforcement des mcanismes de sanction. Par exemple, l'implantation du module achat d'un ERP dans une entreprise ayant dj des nomenclatures achat standardises et homognes et une direction des achats puissante relve d'une stratgie de routinisation.- La transformation, qui vise crer puis lgitimer une nouvelle norme d'action. L'action organisationnelle met l'accent dans ce cas sur le dsapprentissage des anciennes normes, la construction des significations lies la nouvelle norme et la ngociation avec les acteurs des conditions oprationnelles de mise en oeuvre de cette nouvelle norme. Par exemple, l'implantation du mme module achat d'un ERP dans une entreprise o les nomenclatures sont htrognes, o les achats sont dcentraliss dans les tablissements relve d'une stratgie de transformation. Avant de s'intresser aux outils et leur mode d'utilisation, les acteurs sont en attente d'explication sur le sens de la rationalisation du processus d'achat, sur l'impact que cette dernire aura sur leurs mtiers, sur l'autonomie des tablissements. Les acteurs veulent comprendre le pourquoi de l'innovation, exprimenter les implications de ce nouveau processus d'achat sur leurs mtiers et leurs zones d'influence et tre activement impliqus dans la dfinition oprationnelle de l'outil.

Quelles leons pratiques tirer de cette distinction entre ces deux stratgies d'action ? D'abord, que tout projet ERP doit tre contextualis. Il n'existe pas une approche standard idale en matire de projet ERP, mais des approches cohrentes avec des contextes d'organisation diffrents. On n'aborde pas la mise en place des modules finance et contrle de gestion d'un ERP dans un groupe multinational de culture financire anglo-saxonne comme on aborde la mise en place des mmes modules fonctionnels dans un groupe franais rcemment privatis ou dans un hpital. Ensuite, que tout projet ERP doit faire l'objet d'une rflexion stratgique. /

Exercice 5.2 Aprs analyse du texte ci-dessous, faire ressortir une dizaine de points essentiels pour limiter les consquences dun chec de limplmentation dun ERP. Peut-on liminer tout risque de lERP?ERP : l'indemnisation des prjudices du client en cas d'chec du projetSource: http://www.immateria.fr/fr/blog/view/132/erp-l-indemnisation-des-prejudices-du-client-en-cas-d-echec-du-projet

Les ncessits techniques et organisationnelles dune entreprise la poussent recourir, le plus souvent, des progiciels de gestion intgre qui sappliquent un grand nombre de processus internes. Ainsi les progiciels de gestion intgre PGI ou ERP ( Entreprise Resource Planning ) sont aujourdhui indispensables la gestion des flux dune entreprise. Mais quid lorsque le projet drape ? Quel est rellement le cot de l'chec d'un projet informatique pour une entreprise ?

De nombreuses tudes professionnelles indiquent que les projets dimplmentation dERP rencontrent souvent des difficults. En moyenne selon les tudes (ex : "The Chaos Report", Standish Group, juin 2009), de 20 30% des projets ERP sont des checs plus ou moins complets, et plus de 50% sont achevs dans la douleur, avec retard ou moyennant un surcot significatif. Les causes en sont notamment une mauvaise analyse dadquation du produit aux besoins, des difficults dvelopper ou intgrer dans les faits le progiciel command, ou encore une drive calendaire ou financire. Les entreprises doivent donc se consacrer avec une grande rigueur la gestion de projet, et planifier en dtail les consquences de son succs comme de son chec.

1. COMPLEXITE DES PROJETS INFORMATIQUES ERP

Un ERP est communment dfini comme un progiciel grant tout ou partie des processus oprationnels de lentreprise, en intgrant l'ensemble de ses fonctions vitales, telles que la gestion des ressources humaines, la gestion comptable, la gestion financire, les processus de vente et de distribution, l'approvisionnement en produits, le suivi des fournisseurs, la maintenance des quipements, le commerce lectronique, la facturation, la gestion des bases clients, ladministration des campagnes marketing, etc.

De ce fait, un ERP constitue le centre nvralgique de la gestion informatique des activits de lentreprise, par secteur (gestion de production, gestion de la logistique, module financier) ou dans son ensemble (gestion commerciale intgre).

Quelle que soit la taille de lentreprise, les ERP utiliss ont une importance stratgique, et conditionnent les aspects commerciaux, financiers, logistiques et humains de son activit. Un ERP a un impact sur un grand nombre dquipes et de services, qui sont amenes lutiliser chacun pour leurs besoins spcifiques.

En outre, les projets commerciaux de lentreprise sont le plus souvent conditionns par les fonctionnalits et les performances de son systme informatique, lui-mme tributaire de lefficacit des ERP qui y sont implants. Un projet dimplmentation dERP au sein dune entreprise, quil sagisse de son quipement initial ou de sa modernisation, constitue donc un projet hautement stratgique, en ce quil influe sur tous les autres. Il nest pas excessif ce titre de parler dentreprise assiste par ordinateur .Lentreprise doit dfinir ses besoins et contraintes avec soin, afin de choisir lERP qui convient le mieux ses spcificits. De mme, lentreprise doit galement slectionner lintgrateur avec soin, car de lefficacit de ses prestations dpend le succs du projet. A ce titre, il est traditionnellement admis quun ERP, en tant que logiciel, doit tre choisi par le client auquel il incombe de vrifier ladquation du produit ses besoins.

Dans les faits cependant, le choix dun ERP implique une vritable tude dadquation, afin didentifier les carts invitables entre les fonctionnalits standard du progiciel et les besoins de lentreprise. Cette dtermination des carts permet de jauger limportance de la ncessaire phase de personnalisation (paramtrages, interfaages ou dveloppements spcifiques complmentaires).

Ainsi, le projet dintgration dun ERP ne doit pas tre conu comme un projet comme un autre. Ses impacts doivent tre mesurs et quantifis, et doivent tre ports la connaissance du prestataire retenu. Beaucoup dentreprises passent dailleurs des appels doffres qui exposent leurs besoins, afin de bnficier dun ventail doffres parmi lesquelles elles choisissent loffre technique et financire qui lui convient le mieux.

Le client peut donc exiger du prestataire intgrateur, non seulement son conseil et son expertise, mais galement une prestation pralable danalyse fine des besoins et didentification des carts, afin de planifier la charge relle de travail.

Le client doit galement exiger du prestataire une analyse des changements oprer au sein de lentreprise, afin de mesurer le temps que les quipes du client vont consacrer au projet. La conduite du changement ne se rsume pas quelques sessions de formation des personnels, mais implique souvent danalyser leurs pratiques, de les rationaliser, et de les faire voluer afin dassurer leur aptitude apprhender le nouveau systme, ds sa mise en production.

Le prestataire a tout intrt rappeler au client que cette conduite du changement est ncessaire, dautant quelle est en dehors de sa sphre dintervention. Plus dun projet choue parce que le client na pas su sensibiliser ses propres quipes au nouveau progiciel, ou quil sest crisp sur ses anciennes habitudes et na pas apprhend la nouveaut fonctionnelle.

On mesure lampleur de limpact du projet sur lorganisation et la production de lentreprise. Le projet ERP doit ds lors tre encadr par un contrat en adquation avec les attentes du client, qui doit identifier avec soin le primtre prcis des interventions du prestataire et envisager leur dimension juridique : force obligatoire de lexpression initiale des besoins, modalits de fourniture des matriels et des logiciels, droulement des phases de spcification, dintgration et de dploiement, obligation de rsultat, respect des dlais et application des pnalits, matrise duvre et mthodologie de travail, matrice de rpartition des tches, calendrier, phases et lots du projet, description des procdures de recette des livrables, modalits de collaboration du client, garanties de qualit et niveaux de service et enfin, la responsabilit du prestataire en cas dchec du projet.

Lchec dun projet revient souvent, en dernire analyse, labsence de dlivrance conforme du systme attendu. Que lchec soit d un dpassement des dlais, lincapacit du prestataire fournir les fonctionnalits convenues, labsence des performances souhaites, une drive des cots ou encore un dfaut de pilotage des prestations, le client constate en dernier ressort quil ne dispose pas de lERP command.

Il arrive aussi que le client ne mne pas suffisamment la conduite du changement, ou modifie unilatralement le primtre de ses besoins, ou encore manque son obligation de collaboration en ne validant pas les spcifications ou en naccomplissant pas les tches lui incombant. Il serait faux de croire quun projet informatique choue toujours cause du prestataire en charge de le mener : bien souvent, le client na pas su se mettre en ordre de bataille.

Toutefois, si lon se place du ct du client utilisateur, la jurisprudence accueille traditionnellement lchec en constatant ou en prononant la rsolution du contrat dintgration, faute pour lintgrateur de mettre le client mme de se servir du progiciel (CA Paris, 15 novembre 1988, Expertises 1989 p.72), de livrer un progiciel conforme aux spcifications convenues (CA Paris chambre 25 section A, 1er fvrier 2002, St Fichorga, CCE 2002, n103), ou encore de respecter les dlais de livraison convenus (CA Colmar, 13 avril 2006, GMBH Industrial Application Software c/ St Escarmor, Lamy droit de limmatriel juillet/aot 2006 p.49 ; Cour dappel de Paris, 25e ch. 2 septembre 2005, n2004/786). La Cour de cassation a galement prcis quen matire de fourniture de solutions informatiques, lobligation de dlivrance du vendeur de produits complexes nest pleinement excute quune fois ralise la mise au point effective de la chose vendue (Cass. Civ. I, 3 juillet 2001 GST Alcatel, et galement Cass. Com, 11 juillet 2006, n04-17.093).

Deux questions se posent alors : quelle est la responsabilit du prestataire dans cet chec, et quel est le prjudice subi par le client susceptible dtre indemnis ?

La premire question fait lobjet de dbats judiciaires et techniques parfois complexes : insuffisance dans lexpression initiale des besoins, dfaut danalyse pralable, indigence des spcifications, anomalies rcurrentes, rgressions des performances peuvent tre imputables au prestataire ou au client, selon la rpartition des diligences prvue au contrat.

Dans ce contexte, le prestataire fustige souvent le dfaut de collaboration du client, qui tarde transmettre les informations ou lments ncessaires au droulement de lintgration, ou encore valider les livrables, par exemple. Il est donc dans lintrt des deux parties dtablir, ds le stade du contrat, la matrice de rpartition des responsabilits voques plus haut, afin de clairement identifier les diligences qui leur incombent ainsi que le rythme auquel chacun doit les effectuer.

La seconde question, objet de la prsente tude, implique quant elle de mesurer quel sont les dommages rellement subis par le client.

2. LA COMPOSITION DU PREJUDICE DU CLIENT ET SON APPRECIATION PAR LE JUGELe Code civil dispose, son article 1149, que les dommages et intrts dus au crancier sont, en gnral, de la perte quil a faite et du gain dont il a t priv .

Le principe est immdiatement tempr par larticle 1150, qui dispose que le dbiteur nest tenu que des dommages et intrts qui ont t prvus ou quon a pu prvoir lors du contrat, lorsque ce nest point par son dol que lobligation nest point excute . Enfin, larticle 1151 prcise que mme en cas de faute dolosive, les dommages et intrts ne doivent comprendre lgard de la perte prouve par le crancier et du gain dont il a t priv, que ce qui est une suite immdiate et directe de linexcution de la convention .

La jurisprudence ajoute quune fois le dommage dtermin dans sa nature et son tendue, il importe uniquement dassurer la victime une indemnisation intgrale par le versement de lquivalent montaire dudit dommage au jour de sa rparation (Cass. Com. 16 fvrier 1954).

2.1 Llmentaire distinction entre crances de restitution et dindemnisation

Le prjudice se rduit trs rarement la simple privation de la prestation attendue. En matire de progiciel, il est ncessairement bien plus vaste, et comprend toute perte subie et tout gain manqu, directement lis cette privation. Les pertes subies sont des dpenses que le client naurait jamais engages sil navait pens en retirer un bnfice suprieur, un gain espr. Larticle 1149 du Code rappelle cette vidence.

La doctrine abonde en ce sens lorsquelle estime, comme Monsieur le Professeur P. Stoffel-Munck, que Le temps c'est videmment de l'argent. Il en va a fortiori ainsi quand le temps perdu a un cot aisment valuable en heures de travail payes accomplir des tches qui n'avaient pas lieu d'tre. C'est exactement ce dont rend compte la Cour de Paris quand elle admet comme prjudice les pertes de temps et dperditions d'nergie qui [...] ont distrait [les salaris] des tches auxquelles ils se seraient autrement consacrs . () Lobjet de linformatique est notamment, sinon essentiellement, de faire gagner du temps. Il est normal de sen souvenir quand, par la faute du fournisseur, elle nous en a bien plutt fait perdre (CCE juin 2004, com. 77 sous CA Paris 25e ch. 10 octobre 2003).

A lvidence, le remboursement des factures payes par le client, ainsi que lmission dventuels avoirs en compensation des factures mises, mais refuses par le client, ne correspondent quaux restitutions qui accompagnent toute rsolution contractuelle. Le progiciel nayant pas t livr ni mis en production, il est normal que sa contrepartie contractuelle, le paiement du prix, soit galement remis en cause. Il sagit de la consquence ultime de lexception dinexcution, car la cause du paiement disparat dfinitivement.

Le remboursement des factures acquittes ne peut donc jamais sanalyser en indemnisation du prjudice. Le premier correspond la crance de restitution du prix, issue de la rsolution. La seconde correspond la compensation des prjudices subis par le client. Les deux crances ont la mme origine, savoir lchec du projet pour faute du prestataire, mais sont de nature et dobjet diffrents.

Dans un arrt du 7 octobre 2008, la Cour de cassation a dailleurs rappel cette distinction essentielle entre la restitution et lindemnisation, en traitant dune part de la question des restitutions croises conscutives la rsolution du contrat de fourniture dun systme informatique, et dautre part la question de lindemnisation des prjudices subis par le client.

2.2 La varit des postes de prjudices

Chaque projet ERP est unique, car il correspond toujours une entreprise particulire, avec son organisation, ses mthodes, ses ressources, ses besoins, ses contraintes. La gamme des prjudices ventuellement occasionns par un chec du projet informatique est donc trs varie. A titre dexemple, larrt de la Cour dappel de Paris du 19 janvier 2011 (Ple 5 chambre 10, Comexposium / Axe Selection, Expertises n360, juillet 2011) illustre cette varit des postes de prjudice en cas dchec dun projet ERP.

Nanmoins, il est possible de classifier les catgories de prjudices envisageables, entre cot humain, cot matriel (et logiciel), consquences sur la production, et gain de productivit manqu. Il faut ainsi pouvoir identifier toute dpense, tout investissement qui est directement li au projet informatique, et qui est expos en pure perte si le projet informatique naboutit pas.

A titre dexemple, on doit considrer que le temps consacr par les quipes du client (sa DSI mais galement ses diffrents mtiers ds lors quils doivent exprimer leurs besoins) la constitution du cahier des charges, est directement li au projet informatique, puisquil en concrtise la conception initiale. Si lentreprise ne met jamais le progiciel en uvre, le temps pass rdiger le cahier des charges est perdu. A lvidence, il en va de mme du temps consacr par les prposs de lentreprise analyser loffre du prestataire, la ngocier ou demander des claircissements.

Une fois les prestations engages, et comme rappel plus haut, le client doit ddier des quipes lexcution de son obligation de collaboration, en rpondant aux questions complmentaires du prestataire, en participant aux ateliers de spcifications, bref en accompagnant le prestataire dans sa phase danalyse des pratiques de lentreprise. L encore, le temps consacr par les quipes ces diligences nest pas consacr autre chose.

Tout manquement cette obligation de collaboration peut avoir un impact trs fort sur le droulement du projet, et donc son succs. Le prestataire soulignera le dfaut de collaboration du client, pour expliquer que ce manque de coopration est l'origine vritable de l'chec du projet : comment le prestataire pouvait-il assurer le succs d'un projet si le client n'exprime pas correctement ses besoins, ne valide pas les spcifications ou les livrables en temps et heures, ou ne participe pas aux tches qui lui sont dvolues dans le contrat ?

Pour en revenir aux prjudices du client, lachat de matriels ou de logiciels (non compris dans le primtre ddes fournitures du prestataire) constitue bien entendu une autre catgorie de dpenses intrinsquement lie au projet, et ce dautant plus que cet achat est parfois prconis par lintgrateur. A moins que le client ait lopportunit de rutiliser diffremment ces achats aprs lchec du projet (on peut prendre l'exemple des baies qui illustre cet article), il faut considrer quils ont t contracts en vain. A cet gard, le prjudice peut aller trs loin, compte tenu des cots du matriel informatique, mais aussi des contrats ventuellement conclus avec dautres prestataires (mise en place dun rseau de communications lectroniques, fournitures diverses, etc.).

Par ailleurs, les phases de personnalisation, dintgration et dimplmentation du progiciel stendent dans le temps. Pendant ces priodes, lentreprise doit continuer de produire, et bien souvent, une partie du personnel est amene travailler en double commande . Ce mode dgrad implique des vrifications et recoupements, notamment dans les phases de validation daptitude au bon fonctionnement (VABF) ou, de manire plus critique, en phase de vrification de service rgulier (VSR). Les prposs sont parfois amens travailler sur leurs anciens outils, et en mme temps, sur un progiciel partiellement oprationnel, dont il sagit de dtecter les erreurs et les ventuelles non-conformits.

Si ces phases naboutissent pas un progiciel oprationnel, il faut considrer que ce travail en mode dgrad a fait perdre en productivit. Il sagit dun mal ncessaire si le projet est un succs, qui sera compens par les gains de productivit futurs mais si le projet choue, il sagit encore dune pesanteur subie en pure perte, linstar dune baie de serveurs achete en vain.

Au lieu de leur faire gagner du temps, le progiciel conduit les quipes du client en perdre sur leur travail quotidien, parce quils doivent vrifier les rsultats des traitements effectus via le progiciel, sans parler de la dmotivation qui risque daccompagner une phase de qualification trop fastidieuse. Les aspects psychologiques de limplmentation dun nouveau progiciel sont extrmement importants, et il nest pas rare de voir les cocontractants se reprocher mutuellement une absence de motivation

Il faut ici faire un sort lillusion, invoque par certains plaideurs, qui rside dans laffirmation que les salaires verss par le client ses prposs auraient t pays en toute hypothse , pour contester que le temps pass par les quipes du client puisse constituer un prjudice, puisquen toute hypothse, lentreprise tait tenue de payer ses salaris. Cette dfense relve du sophisme : certes les salaris auraient naturellement t pays, mais ils auraient bien entendu consacr leur temps de travail rmunr dautres tches, qui elles, auraient contribu augmenter les rsultats de lentreprise. A linverse, quatre mois passs participer aux ateliers de spcification dun progiciel qui nest finalement jamais livr, sont quatre mois perdus. Le salari a perdu son temps ; lentreprise a perdu les salaires qui correspondent au temps perdu par ses employs.

Enfin, certains juges admettent mme que le temps pass rechercher un nouveau progiciel et un nouveau prestataire, suite lchec du prcdent, constitue galement un prjudice directement li cet chec. Et, de fait, ce temps naurait jamais t consacr cette recherche si le premier prestataire avait tenu ses engagements.

Sil est finalement ais, pour lentreprise cliente, de dcompter lensemble des dpenses exposes en vain, elle doit toutefois observer certaines prcautions pour que ces dpenses puissent tre ultrieurement considres comme des prjudices et recevoir une juste compensation.

3. LES PRECAUTIONS A OBSERVER

Le client doit amnager la preuve des prjudices qu'il subit. La jurisprudence a raffirm avec constance que le juge ne peut estimer ceux-ci de manire forfaitaire (CA Com, 24 novembre 2009, n08-16428). Les prcautions prendre, pour le client, sont de trois ordres :

mesurer lensemble des enjeux lis au projet informatique ; identifier et tracer lensemble des dpenses et ressources investies dans le projet ; identifier et prvoir les gains de productivit attendus du projet.

Ces trois axes doivent tre perus comme des instruments dune gestion optimale du projet, idalement confis une Direction Qualit ou un service spcialement ddi au pilotage du projet, au titre de la matrise douvrage. Si de nombreux mtiers de lentreprise peuvent contribuer, un stade ou un autre, au droulement du projet, il est vivement conseill quau moins une personne conserve une vision transversale et historicise du projet.

Mais ces trois axes consistent en ralit, dun point de vue contentieux, sassurer que les dommages ventuellement subis seront considrs comme prvisibles, directs et certains.

3.1 Assurer la prvisibilit des dommages

Beaucoup de praticiens conseillent au client de raliser ou de commander une tude dimpact avant tout appel doffres. Il est en effet opportun, avant de dcider dun projet qui va impacter durablement lactivit de lentreprise et peser pendant quelques mois sur le travail de ses membres, de procder cette tude dimpact.

Cest cette tude qui permet destimer, ab initio, les cots induits par le projet, les gains de productivit attendus, et les risques encourus en cas dchec, Il sagit dun lment fort daide la dcision.

Il est trs important, ds avant la rdaction du contrat, didentifier avec rigueur les cots gnrs en interne et en externe pour la prparation du projet, la slection du prestataire, et lensemble des diligences pendant tout le projet. Tout matriel, tout service acquis aux fins de ralisation de lERP doit tre identifi comme tel, afin dtre valoris dans la demande dindemnisation si le projet choue. Cest le seul moyen dont le client dispose pour faire reconnatre son dommage.

Toutes les entreprises ne souhaitent ou ne peuvent pas commander une tude dimpact pralable au lancement de leur projet ERP. Mais tout le moins, elles doivent dcrire les enjeux du projet et les communiquer au prestataire, afin que celui-ci ait conscience des consquences que pourraient avoir une mauvaise excution de ses prestations. Le dommage devient alors prvisible.

Larticle 1150 du Code civil dispose quon ne peut indemniser que les dommages qui ont t prvus ou qui taient prvisibles lors de la conclusion du contrat. Il est donc capital, pour le client, dexposer ds le contrat lensemble des enjeux techniques et conomiques que le projet ERP revt pour lui. Il est ncessaire dinformer par crit le prestataire, dans le contrat, que lERP command conditionne lensemble de la chane de production par exemple, et donc la capacit du client mener ses activits.

LERP peut galement constituer la condition sine qua non dune rorganisation stratgique de lentreprise, en vue de la conqute de nouveaux marchs. LERP peut avoir un impact sur les personnels embauchs, et un chec du projet peut ainsi dsquilibrer les ressources humaines de lentreprise.

Le prestataire auquel tous ces enjeux sont indiqus pourra difficilement prtendre par la suite quil ne savait pas et le caractre impratif dune date de livraison prend alors tout son sens, parce quil est directement corrl aux autres activits de lentreprise.

Outre la prvision des consquences en cas daccident et lindication au prestataire des enjeux conomiques du projet, le client doit galement prendre soin de quantifier ce que le projet lui cote, afin dtre en mesure de prsenter lensemble de ces investissements comme des prjudices, entendus comme les pertes subies et les gains manqus de larticle 1149 du Code civil.

Les pertes subies sentendent de toutes les dpenses exposes pour construire, suivre et valider le projet informatique (matriels et temps humain compris), et les gains manqus sentendent des gains de productivit que le client tait lgitimement en droit dattendre compter de la date imprative de mise en production de lERP.

3.2 Etayer la varit des pertes subies

Le client que souhaite faire valoir ses prjudices doit fournir des justificatifs prcis. Plus d'une dcision a refus l'indemnisation d'un client malheureux pour la simple raison qu'il ne produisait pas de documents tayant son calcul de prjudice (voir par exemple CA Paris, 3e chambre, 15 septembre 2006, n05/22450) !

A lvidence, toute dpense matrielle expose par le client sans pouvoir tre rutilise dans un autre contexte, constitue une perte sche pour lui.

Le cot salarial peut tre double : il concerne non seulement les personnels spcialement embauchs pour pallier les carences du prestataire (spcialistes ou intrimaires), mais galement lensemble du temps perdu par les personnels du client dans llaboration et le suivi du projet.

On constate ici limportance capitale qui rside des feuilles de temps de chaque collaborateur, exposant le temps pass et le reliant directement au projet en cause (laboration du cahier des charges et des spcifications, suivi et validations des livrables, travail en double commande impos en raison des retards, etc.). Ce cot salarial peut dailleurs concerner une grande varit de personnels : quipes informatiques, contrleurs de gestion, acheteurs, quipes commerciales, consultants et peut stendre toute prestation dassistance matrise douvrage. En effet, le client qui recourt une socit dassistance matrise douvrage paie ses services pendant tout le temps que dure le projet. Cette dpense sera expose en pure perte si le projet naboutit rien.

Afin dtablir le caractre direct du prjudice, cest--dire son lien de causalit avec lchec du projet, il est capital que les lments de preuve produits par le client soient identifis comme inhrents au projet. Les feuilles de temps doivent identifier les travaux du salari et les relier expressment au projet. Les embauches ralises doivent tre traces comme tant directement conditionnes par le projet, etc. Dans cette optique, doivent galement tre conserves toutes les notes internes, les courriers, et bien videmment lensemble des comptes rendus de runion et de comits de pilotage, qui se rvleront des preuves particulirement importantes en cas de litige.

Le comit de pilotage constitue en effet linstance de pilotage du projet. Sy changent les griefs et les solutions, de sorte que les comptes-rendus de ces comits doivent aussi comporter un chapitre consacr la gestion des risques. Les avertissements adresss au prestataire doivent tre consigns, les inquitudes du client doivent tre explicites.

La perte prouve doit donc sentendre, au sens large, de la perte de temps et donc des cots salariaux, des tiers inutilement associs au droulement du projet, des dpenses exposes en vain, et mme de celles qui seront invitablement exposes lorsque le client devra prparer un nouveau projet de modernisation informatique.

Dautres postes de prjudice sont encore envisageables, pour autant que le client ait eu la discipline de les quantifier et de les attribuer spcifiquement son projet ERP : prjudice dimage ; atteinte sa valorisation financire (notamment sil a dj communiqu auprs de ses actionnaires ou du public sur sa modernisation informatique, en particulier sil est ct en bourse) ; perte de chance, si labsence de livraison en temps et heure du progiciel fait perdre un march au client ou lempche de rpondre avec rigueur un appel doffres, par exemple ; bouleversement des calculs damortissement des actifs de lentreprise, etc.

L encore, les documents probants doivent tre conservs : communications financires, plaquettes commerciales vantant le nouveau systme informatique en cours dimplantation, etc.

3.3 Etablir limportance des gains manqus

Le gain manqu doit sentendre de labsence des gains de productivit attendus, et au-del de limpossibilit doptimiser les autres investissements de lentreprise. Il doit tre indemnis en tant que prjudice certain, par opposition la perte de chance qui ne constitue pas un prjudice certain mais seulement potentiel.

Comme le rappelle l'Expert informatique Hubert Bitan dans son commentaire de l'arrt de la Cour d'appel de Paris du 19 janvier 2011 (CA Paris, Ple 5 chambre 10, Comexposium / Axe Selection, revue Lamy Droit de l'Immatriel n74 p. 43), la jurisprudence a affirm ds 1932 que la rparation d'un prjudice futur est parfaitement admissible ds lors qu'elle apparat comme "la prolongation certaine et directe d'un tat des choses actuel et comme tant susceptible d'estimation immdiate" - ce qui distingue le gain manqu de la perte de chance, qui n'est qu'hypothtique et donc moins aisment prouve.

Si la rentabilit attendue du projet ERP nest pas au rendez-vous, ce gain manqu, certes "futur" mais pourtant directement conscutif l'chec du projet, doit tre indemnis. Il ne le sera que si lentreprise est en mesure de prouver les gains de rentabilit esprs, ce quelle peut faire en produisant par exemple les calculs de progression de marge qui lavaient dcid recourir cette technologie.

Le prestataire contestera le caractre certain de ce prjudice, puisqu'il est futur, mais de nombreuses juridictions accueillent ce type de demande, en s'appuyant sur l'ide simple selon laquelle l'entreprise qui se lance dans un projet de type ERP le fait ncessairement pour amliorer sa productivit.

En gnral, une entreprise souhaite squiper dun ERP parce quelle souhaite amliorer sa performance, optimiser ses flux, et bnficier dune vision transversale de son activit ce pourquoi nous parlions dentreprise assiste par ordinateur . Rductions de stocks, raccourcissement des processus logistiques, automatisation des plans de maintenance des matriels, rductions dinvestissements en consquence sont autant de postes budgtaires qui doivent tre corrls au projet dERP, et prsents au juge avec prcision.

Le gain manqu rejoint dailleurs la perte subie, sagissant de la dsorganisation de lentreprise : non seulement est-elle prive de lamlioration de ses processus par automatisation, mais elle doit en outre subir les ralentissements et les risques derreur que lui font courir le maintien de ses anciens outils, ou le travail en double-commande qui exige tant de vrifications et de recoupements.

Cette notion de dsorganisation constitue un prjudice, comme lindique la Cour dappel de Paris dans un arrt du 25 mai 2005 (SAS Horizon 2000 Informatique c/ SARL Etude Colonna dIstria) propos la perte de temps de tout le personnel, occup rpondre aux rclamations des clients suite aux dysfonctionnements dun logiciel.

Toutes ces prcautions permettent dassurer, le cas chant, une vritable rparation intgrale des prjudices subis par le client. Plus linformation relative ces enjeux connexes sera prcise, voire chiffre, plus le client aura la possibilit dtayer la ralit et la quotit des dommages subis devant le juge. Il est important quune vocation des gains esprs figure au contrat, afin den faire des prjudices prvisibles. Le cahier des charges, notamment, est tout dsign cette fin. Idalement, le contrat lui-mme prcise quels sont ces enjeux.

Mais, afin que ces prcautions ne restent pas lettre morte, il est galement important de surveiller les clauses relatives la responsabilit du prestataire, que celui-ci tient videmment limiter du mieux quil peut. Il sagit l des clauses limitatives ou exonratoires de responsabilit, qui nourrissent une abondante jurisprudence.4. LA LIMITATION CONTRACTUELLE DU MONTANT DES PREJUDICES

Les contrats informatiques comportent galement trs souvent des clauses relatives la rparation des ventuels dommages provoqus par lune des parties, en particulier le prestataire. Ces clauses sont de deux types : elles sappliquent soit ltendue de la prestation promise, soit, de faon plus frquente, ltendue du droit rparation du client.

Ces dernires plafonnent le montant de lindemnisation que le prestataire serait amen payer au client en cas de dommage, et sont en principe ngocies entre les parties. Elles sont toutefois cartes de plein droit si le prestataire commet une faute lourde, rvlant une particulire incomptence ou une incurie grave, ou sil commet une faute dolosive, rvlant une intention de nuire.

Ces clauses influent forcment sur le cot des prestations proposes, notamment parce quelles conditionnent le montant des polices dassurances que le prestataire doit contracter. Ces clauses participent pleinement lconomie du contrat, et le client doit avoir lesprit quelles influent sur son quilibre.

Leur rdaction peut inclure lindemnisation du damnum emergens et exclure celle du lucrum cessans, distinguer entre dommages directs et dommages indirects pour exclure la rparation des seconds, plafonner le montant total de lindemnisation un multiple du montant du contrat, laligner sur le montant de la police dassurance du prestataire, etc. Ces clauses doivent tre examines avec soin par le client, car elles sont gnralement proposes sinon imposes par le prestataire, et quelles seront considres comme acceptes en tant que telles ds lors quelles figurent au contrat sign par le client.

Outre les cas de faute lourde ou dolosive, la jurisprudence a identifi, il y a dj quelques annes, le risque de voir ce type de clause permettre au prestataire davoir toute latitude entre excuter correctement ses prestations, ou abandonner lexcution du contrat moyennant le paiement dun montant indemnitaire contractuellement born par ses soins. Le caractre potestatif (soumis la discrtion dune seule des parties) de certaines clauses, dans le cadre de contrats excution successive notamment, a amen la Cour de cassation forger la thorie des obligations essentielles.

Depuis larrt de principe Chronopost du 22 octobre 1996, et encore rcemment dans larrt Faurecia II du 13 fvrier 2007, la Cour de cassation a rgulirement nonc que si la clause limitative de responsabilit permettait au prestataire de choisir de ne pas excuter le contrat, ds lors quil sait dj le cot total quune telle inexcution engendrera pour lui puisquil la lui-mme dtermin alors cette clause a pour effet de vider le contrat de sa substance, en tant tout caractre contraignant aux engagements contractuels du prestataire.

Certains commentateurs ont dailleurs crit que larrt Faurecia II du 13 fvrier 2007 procde une application trop systmatique de la thorie, et anantit lintrt des clauses limitatives de responsabilit (ou cantonne leurs effets aux seules obligations non essentielles ). Ils sappuient volontiers sur larrt de la Cour dappel de renvoi (Paris), dit Faurecia III en date du 26 novembre 2008, qui tente effectivement de cantonner les effets de la thorie des obligations essentielles.

Toutefois, la Cour dappel de renvoi sest place non plus sur le terrain de lexcution contractuelle dfaillante, mais sur le terrain de la formation du contrat, pour constater que la clause avait t spcifiquement accepte par le client, dans un contrat o la fixation mme du prix avait t lie la fixation du plafond de responsabilit du prestataire, de manire explicite, pour une prise en charge partage du risque . Ainsi, la Cour a nonc que le manquement une obligation essentielle ne peut conduire carter la clause limitative de responsabilit que pour autant que cette clause na pas t ngocie par le client, ou si elle est dun montant drisoire.

Selon cet arrt de la saga Faurecia, confirm par la chambre commerciale de la Cour de cassation du 29 juin 2010, ce nest que si le plafond dindemnisation est drisoire quil vide le contrat de sa substance. En lespce, la Cour a estim que le montant du plafond ntant pas drisoire, il pouvait sappliquer en dpit de labsence totale de livraison du progiciel.

Il semble toutefois prmatur de voir dans cette dcision un vritable coup darrt au dveloppement de la thorie, dans la mesure o les faits de lespce sont assez particuliers. Le prestataire tait en effet en mesure dtablir que le plafond dindemnisation avait t ngoci par les parties, et expressment intgr dans lquilibre conomique du contrat.

Le plus souvent pourtant, il ny a pas de relle ngociation de ce plafond dindemnisation. Il est rare que les parties le prennent en compte dans le calcul du prix des prestations. On doit donc estimer quen principe, en cas de manquement lobligation essentielle de lintgrateur (livrer un progiciel conforme dans les dlais convenus), le plafond dindemnisation tombe. Le client peut alors faire valoir lensemble de ses prjudices, pertes prouves et gains manqus dment tablis, sans se heurter au plafond dindemnisation stipul par le prestataire.

5. Conclusion

Un projet dimplmentation dERP est un projet stratgique. Il implique des investissements et des ressources en amont, et pendant tout son droulement. Il conditionne un grand nombre dautres projets et activits au sein de lentreprise.

Ces investissements et ces enjeux doivent imprativement tre ports la connaissance du prestataire choisi, et doivent, idalement, tre prciss au contrat, afin de constituer des prjudices prvisibles .

Ils doivent galement tre scrupuleusement tracs et relis au projet ERP, quil sagisse des dpenses concrtes ou de la rmunration des personnels impliqus, afin de constituer des prjudices immdiats et directement lis lchec du projet.

Ils doivent galement tre pris en compte dans le calcul de lventuel plafond de responsabilit du prestataire, qui aura tendance limiter celle-ci. Certes, la jurisprudence relative aux obligations essentielles permet de combattre ces plafonds sils vident le contrat de sa substance, mais en toute hypothse, le plafond de responsabilit doit tre pens par le client laune de lensemble des enjeux lis au projet.

Un projet ERP ne peut ni ne doit tre conu de faon isole des autres activits de lentreprise, parce quil les conditionne souvent toutes. Une telle rforme des pratiques de lentreprise doit donc sentourer de toutes les prcautions possibles, et chaque euro dpens pour son succs doit tre identifi et trac par le client afin dtre indemnis en cas dchec.

De son ct, le prestataire a tout intrt responsabiliser le client sur les tches qui incombent celui-ci (notion de matrice des tches), et prciser de manire trs prcise les contours de son engagement, le primtre fonctionnel et technique dont il est responsable, les informations au vu desquelles il sengage, et les limitations de responsabilit dont il entend assortir sa prestation, afin que chacune des deux parties sengage en pleine connaissance de cause.

6 LES COUTS DUN ERP

Exercice 6.1 Estimer, en premire approche, les cots dimplmentation correspondant aux cas suivants:- SAP business one dans une PME de 50 salaris, 15 utilisateurs, licence unitaire de 2500 euros;- SAP All in One, licence unitaire ngocie 3700 euros, dans une entreprise industrielle employant 1500 personnes, dont 120 utilisateurs;- un ERP gnraliste, dont 8 modules implants soit 3800 euros de licence unitaire, dans une PME de 350 personnes et 45 utilisateurs.Dterminer le rapport cot / CA en admettant uniformment un CA de 100000 par employ.

Exercice 6.2 Cas PHARMA PLUS(Source modifie: http://www.ensit.ma/biblio/Mr%20derboul/Etude%20de%20cas%20ERP.pdfModule systmes dinformation logistique et ERP - A. DERBOUL - 2011)

Pharma plus est une socit pharmaceutique internationale prsente commercialement et par limplantation dusines en France, en Allemagne, aux Etats unis et au Japon. En plus de ces implantations stratgiques, lentreprise a une prsence significative sur dautres marchs via de petites filiales commerciales et quelques usines de conditionnement.

Pharma plus est organise en plusieurs branches : oprations commerciales, distribution, production, recherche &dveloppement (la recherche est situe en France et aux USA).Lentreprise dispose de centres de distribution, notamment sur ses marchs stratgiques. Sa production est organise deux niveaux:- production primaire de molcules de base : un produit primaire ne peut tre fabriqu que dans une seule usine au niveau mondial. Divers fournisseurs approvisionnent chaque usine;- production secondaire de produits labors : 5 usines de transformations des produits primaires au niveau mondial, 10 usines de conditionnement. Les produits finis sont ventils au niveau mondial.

A - Analyse du systme dinformation

Lactivit et lorganisation de Pharma plus donnent une importance particulire la supply chain. Mais lentreprise est le fruit de nombreuses fusions et acquisitions, dont rsultent des systmes dinformation et des processus trs diffrents. Chaque pays a son propre systme dinformation et certains pays ont des systmes diffrents pour chacune de leurs usines.Les produits sont donc peu visibles dans la supply chain et le manque de traabilit des produits est vident. Plusieurs rfrentiels de donnes coexistent et le niveau de stocks est globalement lev (il reprsente de 20 100% du CA annuel suivant la production) et lon constate des ruptures dapprovisionnement.Lcart entre prvisions et ralisation des ventes peut atteindre 40% sur 3 mois.

Travail faire

- Schmatiser les flux de la supply chain de Pharma Plus (des fournisseurs de matires aux pays utilisateurs de produits finis).- Analyser les faiblesses de la supply chain de Pharma Plus et en dterminer les causes potentielles.- Proposer des axes damliorations prioritaires.

B Estimation des cots et gains dun projet

Vous tes responsable du systme dinformation de la filiale de Pharma Plus au Maroc. Pharma Plus dispose, au Maroc, de fonctions de support, dune usine demballage et dun centre de distribution.

Le sige de Pharma Plus est en train de dfinir une stratgie pour son systme dinformation. Pour cela, le sige est en train de raliser une tude des gains et des cots pour la mise en place dun ERP au niveau europen dans un premier temps, et potentiellement un dploiement de cet ERP sur les filiales dEurope de lEst et dAfrique du nord. Souhaitant valuer plusieurs options, le sige considre galement une stratgie dERP par rgion ou groupe de pays et vous demande de raliser en parallle, de votre ct, une tude des gains apports par lERP et de ses cots pour sa mise en place au Maroc. LERP pourrait probablement tre dploy en Algrie et en Tunisie ultrieurement.

Les caractristiques de votre filiale marocaine sont les suivantes:- CA de 4 millions dEuros;- niveau de stock de produits correspond 10 mois de ventes (le groupe vous demande de le rduire 3 mois);- le stock des produits fini est valoris au cot de revient, soit 50% du prix de vente;- le cot de possession du stock (hors financement) est de 2% de sa valeur;- la filiale a recours lemprunt au taux de 4% pour financer son besoin en fond de roulement (2 millions deuros au total);- la direction de ventes prvoit quun accroissement de la demande de 20% sera gnr ds la deuxime anne, du fait de lamlioration du SI(cette augmentation des ventes peut tre assure avec lquipement productif actuel);- la marge ralise est de 5% du CA.

Les processus qui doivent tre couverts par le systme dinformation sont :- les achats (couverts par lERP), soit 3 utilisateurs;- les ventes (couverts par lERP), soit 3 utilisateurs;- les stocks (couverts par lERP), soit 3 utilisateurs;- la gestion des emplacements (couverts par une application logistique WMS Warehouse Management System), soit 3 utilisateurs;- la production (couverts par lERP), soit 3 utilisateurs;- la maintenance (couverts par lERP), soit 3 utilisateurs;- la qualit (couverts par lERP), concernant 6 utilisateurs;- la distribution (couverts par lERP), concernant 6 utilisateurs;- la finance (couverts par lERP), concernant 3 utilisateurs.

ERP et WMS ont t choisis par le sige et vous sont imposs, la charge dtude pralable est donc ngligeable.

Nayant pas en interne les ressources ncessaires pour ce projet, vous comptez faire appel une socit de service. Vous assurerez vous-mme la matrise douvrage, soit 50% de votre emploi du temps pendant la priode de mise en place du projet. Les cots unitaires retenir sont les suivants:- 800 euros par jour de consultant et 500 euros par jour de dveloppeur;- 300 euros par jour pour un cadre de Pharma Plus Maroc, 150 euros pour un technicien.

Pour vous aider raliser une valuation des cots, vous avez demand vos collaborateurs deffectuer des recherches, et ils vous ont apport les informations suivantes :- en terme de dure, le projet devrait durer 6 mois;- en terme de cot de logiciel, pour lERP ou le WMS, le cot de licence est de 1000 Euros par utilisateur, puis de 100 euros par an en cot de maintenance. Pour la base de donnes, le cot de licence est de 5000 Euros (une licence par serveur), puis de 500 Euros par an en cot de maintenance;- en terme de machine, il faudra acheter 2 serveurs de moyen gamme 10 000 Euros lunit (dveloppement, test), et 1 serveur haut de gamme (production) 20 000 Euros. Les cots de maintenance annuels seront de 1000 Euros pour les serveurs de moyenne gamme et de 2000Euros pour le serveur de haute gamme;- il faudra galement remplacer les ordinateurs clients raison dun poste par utilisateur (cout unitaire de remplacement de 1000 Euros par ordinateur);- vous disposez dj dun rseau informatique et un audit informatique a confirm que le rseau est suffisant.

Vous avez lanc un appel doffre 3 socits de service, dont il ressort que la charge de consultant sera la suivante :- pour la partie conception-organisation, il faut compter 15 jours homme par processus;- pour la partie ralisation, il faut compter 5 jours homme par processus;- pour la partie test, il faut compter 5 jours homme par processus;- pour le dmarrage, il faut compter 10 jours homme par processus (charge incluant les activits de formation et de reprise de donnes). Un processus correspond une fonction de gestion.

Les socits de service prvoient un dveloppement spcifique pour chacun des modules production, qualit et distribution, de complexit moyenne, soit 10 jours par dveloppement. Il faudrait aussi raliser une interface entre lERP et le WMS, soit 20 jours de ralisation.

Les trois socits de service ont confirm la dure du projet initial de 6 mois, un chef de projet MOE tant dsign durant cette priode, o 4 techniciens de Pharma Plus seront mobiliss.

Un des quatre techniciens de Pharma Plus assurera la maintenance applicative du systme dinformation par la suite. Il ne consacrera que 50% de son temps (220 jours travaills par an) cette maintenance du systme dinformation. Vous serez mobilis 10% de votre temps durant les deux premires annes dexploitation.

Travail faire

- Evaluer les gains du systme ERP- Evaluer les cots de mise en place de cet ERP- Evaluer les cots de fonctionnement- Conclure sur lopportunit du projet en 5 ans dexploitation

Cas de synthse S&S(source modifie: http://www.itformation.com/miage/ProjetSES.pdf)

La socit S&S (Scurit et signalisation) veut implmenter un ERP. La solution doit permettre quelques 300 utilisateurs de S&S de gagner en productivit.

L'organisation

Lentreprise S&S fonde en 1957 est spcialise dans la fabrication de plaques minralogiques. Elle est aujourd'hui leader dans la conception, la fabrication et la commercialisation de panneaux de signalisation, de systmes de gestion du trafic et de produits d'amnagement urbain. La socit emploie 540 personnes et ses produits sont installs sur les cinq continents. Chaque jour dans le monde, plus de 1500 panneaux messages variables S&S informent les usagers de leurs conditions de circulation. En avril 2006, S&S s'est spare du groupe Colas, dont elle tait devenue filiale en 1992, pour redevenir une entreprise indpendante.

Ltat du SI en 2007

L'anne 2007 marque une tape trs importante dans le dveloppement de S&S. Tandis que nous ftons nos 50 ans d'existence, nous redevenons une entreprise indpendante aprs avoir fait partie d'un trs grand groupe routier pendant prs de 15 ans. Il tait particulirement stratgique, dans ce contexte, de repenser en profondeur notre systme d'information. Celui-ci reposait sur de nombreuses applications htrognes, et gnrait de ce fait des problmes oprationnels et d'exploitation, commente Pierre Passet, directeur gnral adjoint de S&S.

Nous tions par consquent la recherche d'un systme ERP complet, prouv et facile d'utilisation, capable de remplacer la majeure partie de nos applications pour nous permettre, au final, de mieux servir nos clients.S&S utilisait jusque-l diffrents outils pour chacune des grandes fonctions de l'entreprise, telles que la gestion commerciale ou la production, auxquels s'ajoutent plusieurs dizaines d'applications spcifiques ddies la gestion d'aspects particuliers, comme les chantiers ou les stocks d'ateliers. L'htrognit des donnes ou les interfaces parcellaires en temps diffr qui en dcoulaient avaient un impact ngatif sur certaines oprations, comme par exemple les lancements de nouvelles gammes de produits, qui ncessitent de rassembler de nombreuses donnes.

Le projet de SI

Aprs sa sparation avec le groupe Colas, SES prit la dcision d'adopter un nouveau systme ERP. En septembre 2006, le projet baptis Sesme est lanc avec une premire phase d'analyse des besoins, mene par un groupe de travail compos de quatre personnes, dont Pierre Passet, le directeur gnral adjoint de la socit. L'implication, ds le dbut, de la direction gnrale s'est rvle fondamentale dans la russite du projet. Le cahier des charges, soumis prs de 90 utilisateurs de SES, est valid fin janvier, permettant la socit d'identifier 22 solutions potentielles. A la suite d'un processus d'valuation minutieux impliquant une vingtaine d'utilisateurs, S&S slectionne, fin avril 2007, la solution Jeeves.La couverture fonctionnelle extrmement riche de l'ERP Jeeves a t un critre dterminant dans le choix de S&S. Les aspects lis aux temps de rponse de la solution, qui a fait l'objet de tests spcifiques, ont galement rpondu aux attentes de S&S. Ces aspects, importants pour la socit, furent de plus valids auprs de clients existants de Jeeves, que S&S consulta durant les dernires phases de son processus de slection. Enfin, la solution de l'diteur sudois a galement dmontr une ergonomie trs leve et une grande facilit de configuration, apportant une facilit d'utilisation largement suprieure la concurrence.Le paramtrage de la solution est prvu doctobre 2007 mi-janvier 2008. Suivra la phase de formation des utilisateurs cls. La mise en production de la solution Jeeves est prvue pour fin mars 2008.

L'ERP sera interfac avec la majeure partie des applications mtiers utilises par S&S, comme par exemple l'outil de dimensionnement des portiques de signalisation. S&S a compar les systmes d'entreprise IBS ASW, IFS, Jeeves, Movex (Lawson, anciennement Intentia) et SAP. L'tude s'est concentre sur la frquence et le type de mise jour, ainsi que sur leur catgorie, leur primtre fonctionnel et leurs cots rels, donne extrmement rare sur le march.Les cots levs reprsentent la raison principale poussant les entreprises ne pas procder aux mises jour de leur systme d'information. Jeeves est l'exception ce constat, avec un cot de mise jour de l'ordre de 215 euros par utilisateur. Selon l'tude, ce facteur encourage les clients Jeeves mettre jour leur systme d'entreprise plus rgulirement que les utilisateurs d'autres solutions.L'ge du systme et le nombre de mises jour, le niveau d'utilisation quotidienne et les critres de maintenance ont une influence significative sur la satisfaction des clients, et sur la productivit de l'entreprise elle-mme. La satisfaction des clients atteint 2,9 sur une chelle allant de 0 3 parmi les utilisateurs Jeeves, suivie par une moyenne de 2,7 pour les clients SAP, et 1,9 pour ceux d'IFS. Les clients les moins satisfaits seraient ceux de Movex et d'IBS, avec respectivement 1,6 et 1,5 selon ltude.Puisque les mises jour sont simples et rapides, la grande majorit des clients les mettent en oeuvre ds leur sortie. Lavantage conomique (cot de migration) et professionnel (productivit et comptitivit par lutilisation dune solution toujours jour) sont significatifs.Jeeves distribue ses licences travers un rseau international dintgrateurs slectionns. Les licences sont abordables ( partir de 1300 euros par utilisateur pour une configuration de type ngoce) et la qualit des intgrateurs permet de garantir un haut niveau de qualit et un respect des dlais. Prs de 20 intgrateurs franais couvrent lintgralit du territoire.Une tude internationale dmontre que les clients de lERP Jeeves bnficient du plus faible cot de possession. Un cabinet indpendant dmontre les atouts de Jeeves en matire de cot rel de possession, de productivit et de satisfaction.

La solution Jeeves

Comment bnficier dune solution technologique qui dynamise lorganisation dentreprise et permet de conjuguer amlioration de la productivit et rduction des cots ?Dans le cadre du dveloppement de la version 9.2 de son produit, Jeeves a concentr ses efforts sur trois axes majeurs, plbiscits par les entreprises utilisatrices dERP, savoir :- Dvelopper lergonomie au service de la productivit- Rendre simples et accessibles les outils danalyses- Rduire et contrler les cots

La richesse fonctionnelle de Jeeves et la volont affirme de la Direction Gnrale de SES de privilgier le standard du progiciel doivent permettre de dployer le nouveau systme d'information de SES dans un dlai relativement court pour un projet de cette ampleur. La mise en uvre de modules avancs, comme le configurateur par exemple, va simplifier et amliorer la qualit des donnes techniques (lment cl des entreprises industrielles) et de gnrer galement des gains de productivit administrative en particulier dans le domaine commercial.

Lquipe projet

S&S Scurit et Signalisation est responsable de lefficacit de l'organisation et des mthodes de travail et reprsente le matre douvrage.Anelia, filiale 100% d'IBM, est en charge du projet et reprsente le matre duvre. Philippe Pascot est responsable du projet S&S chez Anelia.

Prodware croque Anelia, l'intgrateur d'IBM pour les PMEEdition du 01/10/2007 - http://www.lemondeinformatique.frArticle de Marie-Anne Delalande

Editeur et intgrateur spcialis dans les solutions de gestion pour PME, Prodware fait preuve d'un apptit gargantuesque. Aprs le rachat au cours de ces deux dernires annes de Tecso, du groupe Syliance, puis de Sefrogi, d'Interface Data ou encore du Belge WinIt, il vient d'annoncer l'acquisition d'Anelia, filiale 100% d'IBM spcialise dans l'intgration des systmes pour PME.

Chose tonnante, Prodware avait jusqu'alors plutt choisi ses proies dans les spcialistes des technologies Microsoft et Sage. En s'offrant 100% des parts d'Anelia, il renforce son partenariat avec Sage mais met galement un pied chez SAP, la filiale d'IBM tant distributeur valeur ajoute des solutions SAP All in One.

Au passage, cette transaction devrait galement bnficier IBM, Prodware annonant dj son intention de crer de nouvelles solutions intgres, optimises et pr-packages embarquant n'en pas douter le matriel et les technologies de son nouveau partenaire. Anelia est en effet un spcialiste de l'intgration sur System i (ex-AS/400), le mini d'IBM best-seller dans les PME.

TRAVAIL A FAIRE

1 - Dcrire brivement l'organisation actuelle de S&S et son activit.2 - Quels sont les problmes de cette organisation ?3 - Quel est le projet de SI et quels sont ses objectifs?4 - Quelle est la structure de l'quipe projet et quels sont ses atouts pour la russite ?5 - Pourquoi le PGI Jeeves a-t-il t retenu ?6 - Retrouvez les grandes tapes du projet informatique.7 - Analysez le planning et les cots du projet.8 Situer le regroupement Prodware Anelia dans le march des ERP. Quels seront les atouts de Prodware? Cette volution aura-t-elle des consquences pour S&S?

Les ERP DSCG Jacques Sornet Page: 1