Nouvelles technologies et réorganisation structurelles
Depuis les années 90, les nouvelles technologies ont permis aux éditeurs de réaliser des solutions informatiques (progiciels et logiciels) de plus en plus complexes. De leur côté, les entreprises se sont trouvées confrontées à la nécessité de réorganisations structurelles, pour faire face aux menaces de la concurrence, qui ont engendré des problèmes organisationnels nouveaux, auxquels les progiciels peinent encore aujourd’hui à s’adapter, forçant les éditeurs à imaginer les adaptations techniques nécessaires pour que leurs logiciels puissent être « interopérables », c'est-à-dire pour qu’ils puissent communiquer avec les autres applications de l’entreprise.

La grande difficulté : conjuguer l’aspect technique et l’aspect fonctionnel

Or, cette interopérabilité n’est pas une simple affaire technique. Elle se doit d’intégrer un ensemble de paramètres conceptuels liés au métier de chaque application, qui devraient être pensés dès la conception du logiciel. C’est pourquoi ce type d’adaptations faites a posteriori ne peuvent être l’œuvre d’une équipe uniquement technique, mais doivent émaner d’une équipe ayant la maîtrise parfaite des différents métiers afférents aux logiciels concernés par ces adaptations. Par exemple, la conception d’un système de cashpooling d’entreprise n’est pas un simple système de reporting de position de cash, mais il s’agit bien d’une fonction métier de centralisation avec équilibrage par palier en suivant la convention de trésorerie du groupe. Son implication va au-delà de la problématique d’équilibrage des comptes, elle touche de plein fouet la comptabilité des comptes courants et par conséquent, la consolidation pour les écritures intercos. Par ailleurs, les fonctions de l’entreprise sont souvent cloisonnées par nécessité organisationnelle et structurelle, la communication entre elles doit donc être extrêmement efficace pour optimiser la performance de l’entreprise.

Des solutions d’adaptation compensatoires, bancales et coûteuses

Cette exigence en termes d’interopérabilité incite les éditeurs à imaginer et proposer des fonctions d’interfaçage, avec des moyens plus ou moins adaptés. Certains proposent un module entier d’interfaçage et d’autres proposent des formats standards d’échange des données avec d’autres applications de l’entreprise. Qui n’a pas vécu l’expérience inoubliable d’essayer d’interfacer une application de trésorerie et une application de comptabilité ? Rappelez-vous les efforts déployés, en conjuguant les équipes techniques et fonctionnelles internes alliées à celles des deux éditeurs, pour arriver à réaliser une passerelle permettant à la comptabilité de prendre en compte les écritures issues des flux de trésorerie, alors qu’il s’agit des deux métiers les plus anciens de l’entreprise… Sans compter le budget et le temps que représentent ces efforts, et les demandes d’améliorations survenant quelques mois après, pour adapter cet interfaçage à un nouveau schéma comptable correspondant à un nouveau type de flux !

Première innovation : les progiciels intégrés et la gestion du référentiel unique

Enfin, la naissance des PGI (Progiciel de gestion intégré) ou des ERP (Enterprise Resource Planning) ou encore des CRM (Customer Relationship Management) était censée délivrer les entreprises de ce souci d’interopérabilité et de partage des informations. Dès l’an 2000 ces solutions ont pris place au sein des entreprises, pour celles ayant les moyens de s’en offrir, mais leur mise en place est une affaire de politique globale, car cela engendre un bouleversement dans les méthodes de travail du fait de la nécessité de décloisonner les fonctions de l’entreprise pour utiliser cette nouvelle génération de solutions informatiques dont le concept est basé sur la gestion du référentiel unique. Mais une autre préoccupation entre en jeu : c’est le déploiement de ces solutions !

Car la configuration de l’entreprise continue à évoluer et devient de plus en plus complexe en raison de son périmètre changeant (fusions, acquisitions, scissions …etc.) créant ainsi un besoin d’adaptation extrêmement rapide de ces solutions pour éviter de se retrouver parfois avec 2 ou 3 ERP au sein d’un même groupe lors d’une fusion de plusieurs entités, et donc 2 ou 3 référentiels « uniques » !… Nous vous laissons imaginer le chantier d’intégration pour assurer l’interopérabilité, et le budget afférent !...

Dans le domaine de la facturation intra-groupe, par exemple, le système de netting de facturation se charge non seulement de la prise en comptes des factures déclarées, mais également d’assurer leur traitement de compensation périodiquement pour déterminer les propositions de règlement. Or un tel système doit disposer de tentacules capables d’intégrer les factures issues de la comptabilité, d’actualiser des prévisions d’encaissements et de décaissements pour la gestion de trésorerie de chaque entité du groupe à la date de valeur de compensation, de déterminer les couples d’intercos selon le périmètre du groupe à une date donnée de façon à simplifier le travail de la consolidation et enfin de préparer toutes les informations issues des paiements (relevés détaillés de facturation compensée) pour actualiser la comptabilité. Puisqu’il s’agit de facturation intragroupe, les intercos doivent s’éliminer et par conséquent, il n’y aura pas d’impact sur le résultat du groupe. Mais sans solution appropriée d’interopérabilité entre ces applications, les charges récurrentes périodiques liées à la mise en place de ses interfaces et à leur fiabilité se voient augmentées d’une façon significative et aura un impact négatif sur le résultat du groupe.

Voyons à présent les différentes approches possibles pour mieux appréhender la logique permettant de naviguer dans un univers le plus interopérable possible.

Autre innovation : les EAI

Survinrent alors les EAI (Enterprise Application Integration), censées rendre les applications métiers et l’ensemble des PGI, ERP, CRM …etc. interopérables ; il s’agit « de l'interopérabilité et de l'organisation de la circulation de l'information entre des applications hétérogènes, c'est-à-dire faire communiquer les différentes applications constituant le HYPERLINK "http://www.commentcamarche.net/systeme-d-information/si-systeme-d-information.php3" système d'information de l'entreprise, voire même celles des clients, des partenaires ou des fournisseurs. ». La définition est simple, mais l’instrument est complexe. Ces solutions sont riches en terme de technologie et en même temps complexes par leur architecture très sophistiquée, lourdes à déployer, et donc plutôt réservées à la Direction Informatique. Et pourtant, ce sont les utilisateurs fonctionnels (trésoriers, directeurs financiers, assistants de trésorerie, comptables, contrôleurs de gestion,…) qui sont les plus concernés par cette problématique d’interopérabilité des flux.
Il leur faudrait donc un outil semblable, mais simplifié.

Où se situent les problèmes d’interopérabilité ?

Car le problème de l’interopérabilité se trouve plutôt au niveau de ceux qui initient tous les flux élémentaires de l’entreprise, constituant une masse d’informations réelles pour les décisionnaires. C’est là que l’interopérabilité fait le plus défaut et cela génère un risque majeur en raison de nombreuses interventions humaines en termes de ressaisies, de manipulations directes des données, ou de transport via les process de reporting …etc. Combien de fois ai-je entendu des utilisateurs dire «… Quel temps perdu avec ces ressaisies, et quelle source d’erreurs… », ou bien « …je dois contrôler moi-même telles ou telles données avant de les envoyer vers la maison mère… ». Cette absence de moyens permettant de fiabiliser ces flux et donc les données, oblige à l’utilisation d’outils bureautiques comme Microsoft Excel pour diminuer les traitements et les contrôles de cohérences via des macros commandes ou des programmes spécifiques en VB (Visual Basic) ou autres. Or l’ensemble de ces outils ne respecte pas la chaîne complète de la circulation des flux sans rupture de traitement avec une traçabilité probante. Il y a donc une véritable défaillance, et un vide technique à combler.


Comment régler ces problèmes d’interopérabilité ?

Il n’y a pas de solutions miracles, mais il y a une démarche pragmatique permettant, à l’aide d’outils simples, de substituer à ces gestes manuels, sans valeur ajoutée et générateurs d’erreurs, des process quotidiens automatisés, fiables et pérennes, sans rupture de traitement, à l’échelle de l’utilisateur final.

En quoi cela consiste-t-il ? Si on se reporte à la définition de l’interopérabilité, on comprend bien qu’elle n’est possible que si toutes les interfaces sont connues et maîtrisées. Or, seuls les utilisateurs sont à même de connaître les besoins d’interfaçage entre les différentes applications qu’ils utilisent. C’est pourquoi il est nécessaire d’acquérir un outil permettant de créer soi-même d’une façon extrêmement simple et vulgarisée des interfaces « métier » et non uniquement techniques. Il faut donc commencer par éliminer toutes les solutions d’adaptation spécifiques et acquérir une solution d’interfaçage unique automatisé (il en existe sur le marché, voir Google ou autres), puis y adapter une vision d’approche métier. Seul l’utilisateur peut déterminer la manière dont il souhaite échanger les informations ou automatiser ses process. Par exemple, « tous les mouvements rapprochés issus de mon application X doivent être restitués automatiquement sur un tableau Excel avant de procéder à la génération des écritures comptables…. » C’est sur cette base que nous devons construire la première brique logique de l’interopérabilité. Une fois la première brique posée, les autres peuvent se mettre en place en se collant par continuité à la première. Par exemple, « les écritures comptables doivent être générées automatiquement selon un plan de compte avant de les mettre à la disposition du système comptable… » etc. Cette approche doit s’appuyer sur des outils simples et immédiatement opérationnels permettant de modéliser et construire étape par étape ces process métiers avec l’utilisateur dans un délai extrêmement court. Par ailleurs, le système d’information de l’entreprise et les process métiers étant en permanente évolution, l’outil doit être convivial et accessible par l’utilisateur, rendant son intervention plus facile et l’adaptation de l’outil plus rapide. L’utilisateur doit pouvoir ainsi modéliser ses process, composant une sorte de maquette évolutive en fonction de ses besoins.

En conclusion, on peut dire qu’il ne faut pas considérer que l’interopérabilité est seulement une mise en place de moyens techniques d’interfaçage entre les différentes applications, mais un moyen applicatif donnant à l’utilisateur une autonomie lui permettant de maîtriser son environnement métier et de l’optimiser.

Pour maîtriser l’interopérabilité, il ne faut pas se placer sous le projecteur d’un progiciel métier ou d’un autre pour vérifier sa capacité à s’interfacer avec d’autres, il faut au contraire prendre suffisamment de recul pour avoir une vue d’ensemble des besoins d’interfaçage « métier » de l’entreprise, et les analyser par rapport à la problématique de circulation des flux, et ce à travers les utilisateurs quotidiens. Il faut donc non seulement se doter d’un outil simple (oublier les EAI complexes et coûteux), permettant de se construire un univers interopérable en tenant compte des paramètres métiers essentiels (interfaçage, automatisation et traçabilité), mais il faut aussi que l’éditeur de cet outil soit capable de fournir une assistance fonctionnelle « métier », et non une assistance technique uniquement.