Pourquoi vos systèmes d'affaires ne communiquent pas entre eux, et ce que cela vous coûte

Une entreprise peut avoir d'excellents logiciels dans chaque service et pourtant avoir du mal à fonctionner comme une seule organisation. Les ventes utilisent un système, les finances un autre, l'horaire du personnel un troisième, et la direction s'appuie sur des chiffriers assemblés à la fin de la semaine. Chaque outil peut bien fonctionner isolément. Les transferts entre eux, non.

Le problème n'est pas toujours qu'une entreprise a besoin de plus de logiciels. Elle peut avoir besoin d'une architecture de l'information plus claire : quelles données vont où, quel système fait autorité, quand l'information doit circuler et comment les exceptions sont gérées.

Il est utile de distinguer quatre problèmes qui se ressemblent souvent vus de l'extérieur :

• Un problème de connexion. Deux systèmes ne peuvent techniquement pas échanger l'information dont ils ont besoin.
• Un problème de flux de travail. L'information circule, mais les étapes qui l'entourent sont redondantes, dans le désordre ou floues.
• Un problème de propriété. Personne n'est responsable de déterminer quel dossier est exact, ni de le corriger lorsqu'il ne l'est pas.
• Un problème organisationnel. Les équipes gardent des outils et des conventions distincts parce qu'elles travaillent séparément.

Seul le premier se règle principalement par une intégration. Les autres exigent des décisions sur le processus et la reddition de comptes, que l'intégration peut ensuite soutenir.

Une défaillance silencieuse est souvent pire qu'une défaillance explicite.

Constat clé

Le travail caché entre les applications

Des systèmes non connectés engendrent des coûts faciles à négliger : ressaisir la même information, rapprocher des dossiers contradictoires, vérifier si un message a été reçu et corriger des décisions prises avec de l'information périmée. Dans une organisation de soins ou de services à sites multiples, par exemple, le même scénario se produit lorsque des notes de quart, des mesures de suivi ou des changements d'horaire sont consignés à un endroit et exécutés à un autre.

Prenons un processus d'accueil illustratif. Un nouvel employé est ajouté à l'application d'horaires, mais pas à la plateforme interne de tâches. Un gestionnaire écrit au service des TI, qui crée manuellement le deuxième compte. Une correction est apportée plus tard à la paie, mais pas dans l'outil d'horaires. Rien n'a techniquement échoué dans une application prise isolément. La défaillance se situe dans la circulation de l'information et des responsabilités d'un système à l'autre.

Pour comprendre le coût opérationnel, suivez un changement représentatif du début à la fin. Comptez les saisies en double, les vérifications manuelles, les retards et les écarts. Calculez ensuite des fourchettes à partir du volume enregistré et du temps de traitement observé, et non de gains de productivité présumés.

L'intégration, c'est plus que brancher une API

Une API offre un moyen technique pour que des systèmes échangent de l'information. Une intégration fiable exige aussi des règles opérationnelles. Pour chaque échange de données, quelqu'un doit répondre à ces questions :

• Quel système est la source de vérité pour ce champ?
• L'échange est-il immédiat, planifié ou déclenché par un événement?
• Que se passe-t-il si le système récepteur est indisponible?
• La même demande peut-elle être traitée deux fois sans risque?
• Comment une exception est-elle détectée, attribuée, corrigée et vérifiée?
• Quelles permissions et quelles limites relatives aux renseignements personnels s'appliquent?

La documentation Application Integration de Google Cloud décrit les connecteurs, les déclencheurs, les tâches ainsi que le mappage et la transformation des données comme des composantes de l'intégration d'applications. Le produit en particulier est facultatif; les questions d'architecture s'appliquent largement.^[1]

Évitez les trois erreurs d'intégration les plus courantes

1. Aucune source de vérité déclarée. Lorsque deux applications peuvent mettre à jour indépendamment un champ commun, elles peuvent se contredire. Définissez le responsable faisant autorité pour chaque dossier ou attribut critique, y compris qui peut le corriger.
2. Traiter les défaillances comme invisibles. Les réseaux et les services tombent parfois en panne. Une intégration devrait consigner les tentatives de livraison, détecter les étapes incomplètes, éviter les traitements en double involontaires et alerter l'opérateur responsable au besoin. Une défaillance silencieuse est souvent pire qu'une défaillance explicite.
3. Intégrer sans simplifier. Si un flux de travail dépend de quatre approbations redondantes, automatiser leur transfert rend le système plus rapide, mais pas plus clair. Remettez la séquence en question avant de la coder.

Dressez une carte des flux de données avant la feuille de route d'intégration

Notez les applications critiques, les principales entités, les responsables et les flux entre eux. Mettez en évidence les données sensibles, les fournisseurs externes, les restrictions contractuelles et les systèmes qui n'offrent pas d'interfaces d'intégration prises en charge. Montrez ce qui se passe lorsque l'information change et où les gens doivent intervenir.

Priorisez ensuite les flux selon leur importance pour l'entreprise, leur faisabilité et leur risque. Une simple synchronisation unidirectionnelle de données de référence peut apporter de la valeur avant une intégration bidirectionnelle complexe. Un projet pilote devrait inclure les cas normaux, les données manquantes, les événements en double, les pannes de service et les échecs d'accès.

Quoi mesurer après la mise en œuvre

Une bonne intégration doit produire plus qu'un voyant vert. Suivez le pourcentage de transferts réussis, l'ancienneté des exceptions, les dossiers en double, les corrections manuelles et le temps que met l'information clé à joindre la bonne personne. Veillez à ce qu'un responsable désigné examine ces indicateurs.