Que faut-il inclure dans votre contrat ERP (Entreprise Ressource Planning) ?
Nous entendons régulièrement parler d’échecs de mises en œuvre d’ERP (Enterprise Ressource Planning), mais nous entendons rarement parler d’entreprises qui intentent une action en justice contre leurs fournisseurs de systèmes ou leurs intégrateurs de systèmes. Est-ce parce que ces personnes ne sont en fait pas responsables, même si leurs honoraires se chiffrent en millions, dizaines de millions ou même centaines de millions de dollars, ou y a-t-il autre chose à prendre en compte ? Peut-être est-ce dû au fait qu’il est en fait très difficile pour les clients mécontents de poursuivre avec succès les entreprises qui n’ont pas été à la hauteur, de sorte que seuls les méga-échecs (comme Lidl, National Grid et Waste Management) sont portés devant les tribunaux.
Il est vrai que de nombreux projets ERP sont si importants et si complexes que, lorsqu’ils échouent, personne n’est totalement irréprochable. Pour chaque client qui se plaint des conseils qui lui ont été donnés, il y a un consultant qui se plaint que ses conseils ont été sélectionnés ou complètement ignorés. Pour chaque client qui se plaint de la formation qu’il a reçue, il y a un formateur en logiciels qui se plaint que le personnel du client se présente à la formation, apporte son téléphone portable et pianote sans relâche pendant toute la session. Mais la raison la plus importante est peut-être que les contrats qui régissent le projet ne remplissent pas leur fonction.
Un bon contrat garantit qu’il n’y aura pas de surprises pendant le projet. Il indique, clairement et sans ambiguïté, ce qui doit être fait, qui est responsable de le faire, quand cela doit être fait et quels sont les recours possibles si les choses tournent mal. Mais ces contrats sont presque toujours rédigés par le fournisseur, qui dispose presque toujours d’un service juridique plus important que celui du client. De plus, ce département juridique est spécialisé dans les contrats ERP, de sorte qu’en cas de litige, le client se trouve sur le terrain de jeu choisi par le fournisseur et joue selon les règles de ce dernier.
Comment les entreprises qui achètent des systèmes ERP peuvent-elles s’assurer qu’en cas de problème, les chances ne sont pas trop fortes ? Dans les années 1980, l’acronyme SMART était populaire pour qualifier les objectifs des entreprises : ils devaient être intelligents, mesurables, réalisables, réalistes et liés au temps. Ces critères ne sont pas un mauvais départ pour définir ce que devrait être un bon contrat (pour toutes les parties).
Spécifique
Pour la protection du client et du fournisseur, un contrat doit indiquer très clairement ce qui doit être fourni. Des phrases telles que « Fourniture et mise en œuvre d’un système ERP (nommé) » sont beaucoup trop imprécises – que signifie « mise en œuvre » ? Cela signifie-t-il que le système doit fonctionner, qu’il doit fournir les fonctionnalités convenues et qu’il doit passer les tests d’acceptation convenus ? Cela devrait, mais ce n’est pas le cas. Et même dire des choses comme « un système qui fonctionne » ou « un système qui satisfait aux exigences de l’entreprise » ne sert à rien si ces expressions ne sont pas clairement et explicitement définies.
En outre, au cours de la période de prévente et des démonstrations, des affirmations et des promesses concernant les capacités et les fonctionnalités du système auront été faites (souvent verbalement), mais ces déclarations ne signifient rien si elles ne sont pas inscrites dans le contrat.
Mesurable
Étroitement lié à la section précédente, ce problème est plus facilement identifié dans un contrat lorsque le mot « améliorer » est utilisé. Par exemple : « Le système doit (ou va) améliorer la gestion des stocks » ; ou « Le système doit (ou va) améliorer le service à la clientèle ». Si une entreprise n’est pas satisfaite du système fourni et que le litige est soumis à l’arbitrage ou au tribunal, comment prouver ou réfuter facilement que quelque chose n’a pas été « amélioré » ? On pourrait faire valoir qu’une amélioration de la gestion des stocks devrait se traduire par une diminution des niveaux de stock mais, de même, elle pourrait signifier une augmentation des niveaux de service et ces deux mesures peuvent, en fait, souvent être en conflit. (Ces phrases échouent probablement aussi au test du « spécifique »).
Consultez notre liste de contrôle gratuite en 5 étapes pour le choix d’un ERP (Entreprise Ressource Planning) afin de vous assurer que vous avez couvert toutes les bases lors du choix de l’ERP.
Réalisable
Conscientes de certains des problèmes susmentionnés, certaines entreprises tentent de les contourner en rédigeant leurs propres contrats ou du moins en faisant insérer des clauses qu’elles, ou leurs avocats, ont rédigées dans le contrat du fournisseur. Mais si elles insèrent des déclarations telles que « le système doit réduire les niveaux de stock de X% » ou « le système doit réduire les délais de livraison de Y% », aucun fournisseur de système sensé ne signera ce contrat car ce ne sont pas des choses que même un bon système peut garantir. Elles dépendent dans une large mesure à la fois de l’acceptation du système par le personnel du client et de facteurs indépendants de la volonté du fournisseur. Par exemple, si l’entreprise croît en taille ou décide d’ouvrir de nouveaux centres de distribution, les niveaux de stock pourraient très facilement augmenter, quelles que soient les performances du système ; en effet, dans ces circonstances, il pourrait s’agir d’un acte délibéré.
Réaliste
Encore une fois, en lien étroit avec la section précédente, les vendeurs non professionnels peuvent être tentés de promettre (même si ce n’est pas écrit !) des avantages qui, dans la réalité, ne seront pas réalisables. Mais ils ajouteront des mises en garde telles que « De nombreux clients ont atteint ….. », ou « Utilisé correctement, le système peut …. ». Ces déclarations peuvent sembler impressionnantes, mais si les choses tournent mal, elles n’auront pratiquement aucune valeur devant un tribunal.
Le facteur temps
Lorsqu’une entreprise lance un projet ERP, elle se fixe, du moins dans son esprit, une date de mise en service. Cette date peut n’être qu’une date nominale pour attirer l’attention, mais elle peut aussi représenter une exigence critique si, par exemple, le support de leur ancien système est interrompu ou si les développements commerciaux prévus signifient que de nouvelles fonctionnalités sont essentielles. Lorsque la date de mise en service est importante, elle doit tout simplement être inscrite dans le contrat, mais il n’est pas toujours facile de le faire efficacement. Le problème est que le fournisseur ne peut s’engager à effectuer que le travail spécifié dans le contrat, et il n’est pas rare qu’après la signature du contrat, de nouvelles tâches ou exigences soient identifiées comme étant nécessaires pour une conclusion réussie. Si l’étendue des travaux change, il peut être irréaliste de s’attendre à ce que le fournisseur tienne sa promesse initiale.
Le projet doit donc être doté d’une procédure formelle de contrôle des modifications, dont le fonctionnement et l’impact sur les promesses de livraison doivent être explicitement définis. Faut-il convenir d’un délai d’urgence ? Une formule doit-elle être convenue pour définir les dérapages admissibles du projet ? Le fournisseur doit-il fournir des ressources supplémentaires (à un coût convenu) pour s’assurer que la date de mise en service n’est pas affectée ?
Un deuxième problème lié aux dates de mise en service cibles est que, souvent, le fournisseur ou l’intégrateur de système n’a pas intérêt à respecter ces dates. Ils disposent d’un grand nombre de consultants (dans le cas d’un système de niveau 1, il s’agit régulièrement de douzaines ou de centaines) qui touchent des tarifs lucratifs et ne veulent pas que cela cesse, surtout s’ils n’ont pas d’autres contrats immédiats pour absorber ces ressources.
Retournement de situation : il arrive que les clients parviennent à conclure un marché difficile avec leurs fournisseurs mais, lorsqu’un travail plus lucratif se présente à eux, ils seront tentés de retirer leurs employés dès que possible. Parfois, cela peut se traduire par le retrait de leurs meilleurs éléments et leur remplacement par l’équipe B. C’est déjà assez grave. C’est déjà assez grave en soi, mais ces personnes auront besoin de temps pour se familiariser avec le projet, tout comme l’équipe initiale. Le client a payé pour que les consultants initiaux progressent le long de la courbe d’apprentissage : le contrat indique-t-il qui doit payer pour que les remplaçants suivent à nouveau ce processus ?
Une autre réflexion liée au temps est que, pendant la durée de vie d’un système ERP, l’entreprise qui le gère changera. Elle peut devenir plus grande ou plus petite, ce qui implique un changement du nombre d’utilisateurs du système. De plus, si le système est basé sur le cloud, la quantité de stockage requise pour des fichiers de plus en plus volumineux changera également. Le contrat doit indiquer en termes clairs comment ces changements seront répercutés sur les frais mensuels et annuels. Et, étant donné que le système est susceptible d’être utilisé pendant au moins dix ans, il doit également spécifier quelles augmentations des frais pendant cette période seraient considérées comme raisonnables et comment elles seront calculées. Certains clients de niveau 1 ont récemment subi des chocs importants lorsque leur fournisseur est passé d’une tarification basée sur le nombre d’utilisateurs à une tarification basée sur les transactions.
Les entreprises doivent également savoir que, pour un certain nombre de raisons, certaines mises en œuvre d’ERP sont décevantes ou échouent complètement. Elles doivent savoir, si cela se produit, comment elles peuvent (si elles le peuvent) se dégager du contrat afin de ne pas se retrouver à payer des frais et des charges longtemps après l’abandon de ces systèmes.
Une dernière réflexion : il existe de nombreux conseils judicieux pour garantir le bon déroulement des projets. En tirant parti de ces informations, les entreprises doivent toujours se rappeler que, jusqu’à ce qu’elles signent un contrat, ce sont elles qui ont le pouvoir. Elles ne devraient jamais signer un mauvais contrat, même si cela signifie dépenser une fraction du budget total du projet pour obtenir de bons conseils indépendants.
