Sous le règne de l'ERP, nous avons été endoctrinés que l'intégration était la meilleure des choses et qu'il n'y avait qu'une voie, l'ERP ! En pastichant une publicité célèbre, "vous en rêviez ? L'éditeur ERP l'a réalisé pour vous !". La fameuse "bibliothèque de bonnes pratiques" offrait les bons processus, déjà tous tout intégrés. Avec l'eApprovisionnement, la problématique de l'intégration redevient d'actualité. Quels événements déclencheurs ? Quels flux intégrer ? Quels coûts ? Et pour quels bénéfices ?

Double discours
Ces questions se posent, depuis plusieurs années, avec les progiciels eApprovisionnement fournis pas les éditeurs de solutions dédiées qui sont apparus sur le marché en 1996. On a vu d'ailleurs plusieurs grands groupes adopter des solutions radicales comme, par exemple, pas d'intégration entre eApprovisionnement et ERP.

Ces questions se posent, aujourd'hui, avec encore plus d'acuité pour les modules eApprovisionnement fournis par les éditeurs ERP. En effet, les éditeurs ERP ont à tenir le double discours suivant.

D'une part, à leur base installée, il leur faut dire que, naturellement, leur module "lave plus blanc". N'est-il pas nativement intégré avec tous les autres modules de l'ERP ?

D'autre part, au reste du monde, c'est-à-dire à tous les groupes qui ont plusieurs ERP et/ou systèmes comptables, en fait, la grande majorité des groupes, il leur faut dire que, bien évidemment, leur module aura la flexibilité et la capacité d'intégration pour savoir communiquer efficacement avec tous les autres ERP.

Ce n'est peut-être pas de la schizophrénie, mais ça ressemble quand même à un grand écart, non ? Concevoir un schéma d'intégration standard d'un module eApprovisionnement de l'ERP de marque A avec non seulement l'ERP de marque A mais aussi les ERP de marques B et C et les systèmes comptables de marques D et E … est un problème intéressant à dire le moins ! Cette chronique propose quelques recommandations en la matière.

A quel moment intégrer?
Quels sont les événements déclencheurs susceptibles de requérir une intégration ? On peut vouloir intégrer dès l'émission d'une demande d'achat. On pourrait ainsi vérifier la disponibilité en stock. On pourrait également vérifier l'existence d'un budget et suivre les engagements dès leur genèse.

L'expérience montre toutefois qu'il existe rarement des budgets de dépenses détaillés par centre de coût. Quant bien même un tel budget existerait (ce qui sera souvent le cas pour un projet), il faudra s'interroger sur les règles de gestion d'autorisation à mettre en œuvre. Sinon, une comparaison immédiate avec le budget disponible autoriserait toutes les dépenses dans les premiers mois de l'année et les interdirait par la suite. Cela peut être le mode de fonctionnement de certaines administrations, ce n'est pas, et de loin, une bonne pratique à automatiser.

On peut ensuite intégrer à la commande. Ceci permettra de suivre les engagements. C'est un impératif notamment pour tous ceux qui ont mis précédemment en place des modules achats intégrés à leur comptabilité.

On peut encore intégrer à la réception. C'est un impératif pour suivre les provisions et autres factures à recevoir. On peut enfin intégrer à la réception facture.

Deux grands scénarios
Dans notre expérience, il y a deux grands scénarios d'intégration selon le niveau de maturité de l'ERP existant.

Quand l'ERP comprend un module achats et comptabilité intégrés " état de l'art ", notre recommandation sera de
i) traiter dans le module eApprovisionnement la demande d'achat et la réception,
ii) transférer dans l'ERP une "carbon copy" de la demande d'achat et de la réception,
iii) traiter dans l'ERP l'enregistrement des factures et leur règlement.

Quand l'ERP est plus ancien et ne comprend qu'un module comptable, notre recommandation sera de
i) traiter dans l'eApprovisionnement la demande d'achat, la réception et l'enregistrement de la facture et
ii) traiter dans l'ERP le règlement.
Il faudra toutefois prêter attention au niveau de maturité et d'ergonomie du module facture de l'eApprovisionnement qui, pour certains éditeurs, est encore trop rudimentaire. L'intégration avec les systèmes de maintenance est également un sujet intéressant. Il fera l'objet d'une prochaine chronique.