ERP, CRM, application métier : comment connecter vos outils sans tout reconstruire ?

Après avoir équipé les métiers, il faut faire fonctionner l’ensemble

Au début de cette série, SERVIPRO rencontrait un problème finalement très courant. Son CRM fonctionnait. Son ERP également. Son application métier répondait aux besoins des équipes opérationnelles et son portail client avait toute son utilité. Pourtant, entre ces différents outils, l’information circulait mal.

Nous avons d’abord mis un nom sur ce problème avec les silos de données en entreprise. Nous avons ensuite expliqué le rôle de l’interfaçage applicatif, comparé connecteur natif, iPaaS et intégration applicative sur mesure, puis détaillé les étapes permettant de sécuriser un projet d’intégration applicative.

À l’issue de ce parcours, SERVIPRO n’a pourtant pas remplacé son système d’information.

Son CRM est toujours là. Son ERP aussi. Son application métier continue à porter les processus spécifiques qui font sa valeur.

Ce qui a changé, c’est la manière dont ces outils travaillent ensemble.

C’est probablement l’un des enjeux majeurs des systèmes d’information actuels : après plusieurs années de digitalisation et d’empilement de solutions spécialisées, la priorité n’est plus forcément d’ajouter un nouvel outil. Elle consiste de plus en plus souvent à mieux exploiter ceux qui existent déjà.

Et pour cela, reconstruire n’est pas toujours nécessaire.

Connecter l’existant plutôt que repartir systématiquement de zéro

Lorsqu’un système d’information montre ses limites, la tentation peut être forte de raisonner en remplacement : changer de CRM, migrer vers un nouvel ERP, reconstruire une application métier devenue difficile à intégrer.

Dans certains cas, cette décision est justifiée. Une dette technique trop importante, une application devenue inmaintenable ou un outil qui ne correspond plus aux processus de l’entreprise peuvent nécessiter une véritable refonte d’application métier.

Mais ce n’est pas toujours le problème.

Une entreprise peut parfaitement disposer de plusieurs applications efficaces individuellement, mais mal coordonnées entre elles. Le CRM répond aux attentes des commerciaux, l’ERP reste adapté à la gestion et l’application métier couvre précisément les besoins opérationnels. Les remplacer ne supprimerait pas nécessairement le problème de circulation des données.

Cela pourrait même en créer de nouveaux : migration, reprise de données, conduite du changement, formation des utilisateurs ou perte de certaines règles métier construites au fil des années.

Dans ces situations, l’interfaçage offre une autre voie : conserver ce qui fonctionne et créer les connexions nécessaires pour rendre l’ensemble plus cohérent.

L’objectif n’est pas de préserver l’existant à tout prix.

Il est de ne reconstruire que ce qui mérite réellement de l’être.

Racontez-nous

Quand un connecteur ERP CRM sur mesure devient pertinent

Tous les échanges ne nécessitent évidemment pas un développement spécifique.

Nous l’avons vu dans l’article consacré au choix de l’approche : lorsqu’un connecteur natif couvre correctement le besoin, il n’y a aucune raison de réinventer ce qui existe déjà. De la même manière, une plateforme iPaaS peut être parfaitement pertinente pour automatiser certains flux simples ou périphériques.

Le développement d’un connecteur ERP CRM sur mesure prend son sens lorsque l’échange doit s’adapter à des processus que les solutions standards ne savent pas correctement représenter.

Prenons un exemple. Dans un scénario classique, une opportunité gagnée dans le CRM doit créer un client dans l’ERP. Un connecteur standard peut parfaitement répondre à ce besoin.

Mais que se passe-t-il si la création dépend du type de contrat ? Si plusieurs établissements doivent être rattachés à un même compte ? Si les conditions tarifaires proviennent de l’ERP, alors que certains statuts opérationnels doivent remonter d’une application métier vers le CRM ? Ou si le portail client doit également afficher une partie de ces informations ?

À ce stade, nous ne parlons plus simplement de synchroniser deux fiches.

Nous parlons de traduire un processus métier dans le système d’information.

C’est précisément là que le sur-mesure apporte sa valeur : il permet de définir les règles d’échange en fonction du fonctionnement réel de l’entreprise, plutôt que de demander à l’entreprise de modifier son fonctionnement pour entrer dans le cadre d’un connecteur.

Trois situations où l’intégration sur mesure prend tout son sens

La première situation concerne les ERP qui doivent progressivement s’ouvrir à de nouveaux usages.

Un ERP peut parfaitement continuer à jouer son rôle de cœur de gestion tout en devant alimenter un portail client, un site e-commerce, une application mobile ou une solution partenaire. Il devient alors nécessaire d’exposer certaines données, d’en sécuriser l’accès et parfois de transformer leur format avant qu’elles puissent être utilisées ailleurs.

La deuxième concerne les CRM. Plus l’entreprise cherche à donner aux équipes commerciales une vision complète du client, plus le CRM doit consommer des informations qui ne lui appartiennent pas naturellement : commandes, factures, contrats, statut d’une intervention, incidents ou données issues d’une application métier. L’enjeu n’est pas de dupliquer tout le système d’information dans le CRM, mais de rendre accessibles les informations réellement utiles au bon moment.

Enfin, les applications métier doivent rarement fonctionner seules. Une solution développée pour piloter un processus spécifique doit souvent récupérer des données dans l’ERP, transmettre des informations au CRM, appeler un service externe ou alimenter un outil de reporting.

C’est d’ailleurs tout l’intérêt d’une approche sur mesure : le spécifique et le standard ne sont pas nécessairement opposés. Une application métier peut se concentrer sur ce qui différencie réellement l’entreprise tout en s’appuyant sur des solutions existantes pour les fonctions plus génériques.

La valeur se trouve alors autant dans l’application elle-même que dans sa capacité à s’insérer correctement dans le reste du système d’information.

Parlez-en à un expert

SALTI : faire évoluer le SI progressivement plutôt que par rupture

Le projet mené avec SALTI illustre particulièrement bien cette logique.

Spécialiste de la location de matériel pour les professionnels, SALTI a engagé avec Access it une refonte progressive de ses applications métier afin de les regrouper au sein d’un ERP sur mesure.

Le point intéressant n’est pas uniquement la construction de ce nouvel ERP. Il réside dans la transition.

Les nouvelles briques ne pouvaient évidemment pas remplacer toutes les anciennes applications du jour au lendemain. Pendant le projet, les deux environnements devaient coexister. Les différents composants du système d’information devaient donc continuer à échanger des informations pendant que la migration progressait.

Le site internet et l’espace client devaient également s’intégrer à cet écosystème, aux côtés des applications mobiles utilisées pour certains usages opérationnels.

Autrement dit, la transformation ne s’est pas faite selon une logique de « big bang ». Elle s’est construite progressivement, en maintenant la continuité des processus existants tout en déplaçant les fonctions vers une architecture plus cohérente.

Ce type d’approche montre bien qu’interfaçage et modernisation applicative sont souvent intimement liés. Les interfaces permettent de faire coexister l’ancien et le nouveau, de sécuriser les transitions et d’éviter qu’une transformation du SI impose une rupture brutale aux métiers.

API Restauration : intégrer un service externe directement dans le processus métier

L’intégration ne concerne pas uniquement les échanges entre ERP et CRM.

Le projet réalisé pour API Restauration en fournit un autre exemple.

L’entreprise souhaitait disposer d’une application permettant aux collaborateurs de gérer les demandes d’ajout de nouveaux fournisseurs, avec un processus d’approbation dépendant notamment du volume d’achat, du pays ou du type de produits.

Mais le workflow ne pouvait pas se limiter aux seules informations saisies dans l’application. L’un des contrôles nécessaires concernait la solvabilité du fournisseur.

Plutôt que de demander à l’utilisateur de quitter son application, de se connecter à un autre service puis de reporter manuellement le résultat, la solution intègre directement le contrôle via CreditSafe.

L’utilisateur reste dans son processus métier. L’application va chercher l’information dont elle a besoin auprès d’un service externe.

Cet exemple paraît plus simple qu’un vaste projet ERP, mais il repose sur la même philosophie : éviter les ruptures de parcours et faire venir la donnée là où elle est réellement utile.

C’est souvent à cela que l’on reconnaît une intégration réussie.

L’utilisateur ne pense plus à l’interfaçage. Il réalise simplement son travail.

On en discute ?

Le sur-mesure ne doit pas devenir une réponse automatique

Ces exemples pourraient donner l’impression que tout flux mérite un développement spécifique.

Ce serait une erreur.

Un bon projet d’interfaçage d’applications commence justement par déterminer ce qui doit réellement être développé.

Si un connecteur natif répond parfaitement au besoin, il faut l’utiliser. Si une plateforme existante permet d’automatiser durablement un flux simple, elle peut constituer la meilleure solution. Le développement spécifique n’a de valeur que lorsqu’il répond à une contrainte que les solutions standards couvrent mal.

Cette approche évite deux travers opposés : reconstruire inutilement ce que le marché sait déjà faire, ou forcer un processus métier stratégique à entrer dans un outil trop limité.

Le bon système d’information n’est donc ni 100 % standard, ni 100 % spécifique.

Il combine les deux intelligemment.

Le standard prend en charge ce qui est commun. Le spécifique se concentre là où l’entreprise possède ses propres règles, ses propres contraintes ou ses propres facteurs de différenciation. L’interfaçage assure ensuite la continuité entre ces différents composants.

Ne reconstruire que ce qui mérite de l’être

Au terme de cette série, le sujet de départ paraît finalement assez éloigné de la technologie.

Nous avions commencé par des collaborateurs qui perdaient du temps à copier des données entre plusieurs logiciels. Derrière ces doubles saisies se cachait en réalité une question beaucoup plus large : comment construire un système d’information capable d’évoluer sans accumuler de nouvelles ruptures ?

La réponse n’est pas forcément de réduire le nombre d’applications.

Elle n’est pas non plus de chercher un logiciel unique capable de tout faire.

Elle consiste plutôt à donner à chaque outil un rôle clair et à organiser correctement les échanges entre eux.

La maturité d’un système d’information ne se mesure donc pas au nombre d’applications qu’il contient. Elle se mesure aussi à leur capacité à fonctionner ensemble.

Pour SERVIPRO, notre fil rouge, l’enjeu n’était finalement pas de reconstruire son ERP, son CRM ou son application métier. Il était de déterminer quelles informations devaient circuler, quelles applications devaient en rester responsables et quels flux nécessitaient une intégration plus spécifique.

C’est exactement la même question qui peut servir de point de départ à un projet réel.

Si vos équipes multiplient les ressaisies, les exports Excel ou les contournements pour faire circuler des informations entre plusieurs logiciels, la première étape n’est pas nécessairement de développer un nouveau connecteur.

Elle consiste d’abord à comprendre les flux, à identifier les ruptures et à déterminer ce qui mérite réellement d’être connecté.

Vous souhaitez faire le point sur votre environnement applicatif et identifier les flux à simplifier ? Échangeons sur votre projet d’interfaçage.