Lorsque deux systèmes d'entreprise ne partagent pas correctement les informations, cela est généralement traité comme une gêne mineure. Quelqu'un exporte un tableur, corrige quelques lignes, l'envoie par e-mail à un collègue, qui le télécharge ailleurs. Cela fonctionne, jusqu'à ce que cette personne parte en vacances, que le volume de commandes double, ou qu'un des systèmes soit mis à jour et que le fichier change de format.
Ce qui a commencé comme une solution rapide est devenu, sans qu'on s'en aperçoive, un élément dont dépend l'entreprise.
La ressaisie n'est que le coût visible
Le coût évident est le temps passé à copier des informations d'un endroit à un autre. Le coût plus important est le délai. Une commande est prise, mais les niveaux de stock ne le reflètent que le lendemain. Un paiement arrive, mais la comptabilité l'affiche toujours comme dû. L'équipe a terminé le travail ce matin, mais le bureau pense toujours qu'il est en cours.
Les gens contournent ces lacunes. Ils s'appellent pour vérifier. Ils tiennent leurs propres tableurs. Ils ajoutent des étapes d'approbation supplémentaires par précaution. Au fil du temps, l'entreprise construit un second système officieux au-dessus des systèmes officiels, qui réside généralement dans la tête de quelques employés expérimentés.
Décider quel système est responsable de quoi
Avant de connecter quoi que ce soit, je pose une question simple qui s'avère très importante : pour chaque information, quel système a le dernier mot ?
Si l'adresse d'un client peut être modifiée à trois endroits différents, lequel l'emporte ? Si une facture est annulée après avoir été transmise à la comptabilité, comment celle-ci le découvre-t-elle ? Si un scanner envoie accidentellement la même lecture deux fois, cela doit-il créer deux transactions ?
Cela ressemble à des questions techniques, mais ce sont en réalité des décisions commerciales. S'accorder sur ces points dès le départ évite beaucoup de confusion plus tard. Une connexion peut transférer des données parfaitement et pourtant transférer les mauvaises données.
Prévoir les dysfonctionnements
Les connexions entre systèmes tombent en panne de manière classique. Internet se coupe. Un mot de passe expire. Un fournisseur change son logiciel. Les informations arrivent dans le mauvais ordre. Une bonne connexion anticipe cela. Elle détecte le problème, conserve l'information, réessaie intelligemment et permet à quelqu'un de voir facilement ce qui est bloqué pour le résoudre.
Réessayer demande de la prudence. Vérifier un niveau de stock deux fois ne fait aucun mal. Envoyer le même paiement ou la même expédition deux fois, si. Les connexions bien conçues reconnaissent un message répété et l'ignorent, au lieu de le traiter une seconde fois.
Rendre les problèmes faciles à voir
Une bonne connexion doit pouvoir répondre à quelques questions simples à tout moment. Combien de commandes sont arrivées aujourd'hui ? Y en a-t-il en attente ? Depuis combien de temps la plus ancienne attend-elle ? Quelque chose a-t-il échoué, et quelqu'un doit-il intervenir ?
Les alertes les plus utiles concernent l'activité, pas les ordinateurs. « Une commande n'a pas atteint l'entrepôt en deux heures » est bien plus utile que « le serveur est occupé ».
Il est également utile de comparer régulièrement les totaux entre les systèmes : nombre de commandes, totaux des factures, stock disponible. Même les bons systèmes dérivent lentement. Personne ne peut promettre que rien ne tournera jamais mal. Ce que vous pouvez faire, c'est détecter les problèmes tôt, avant qu'ils ne deviennent des surprises coûteuses.
Réparer d'abord la connexion la plus critique
Toutes les connexions n'ont pas besoin d'être instantanées. Un rapport de ventes qui se met à jour pendant la nuit est souvent parfaitement suffisant. Tout ce qui contrôle le stock disponible à la vente, ou qui déplace de l'argent, doit être beaucoup plus fiable et étroitement surveillé.
Un bon point de départ est de dessiner comment l'information circule dans l'entreprise, de compter combien de fois les gens la manipulent manuellement et de noter quels problèmes consomment le plus de temps. Ensuite, réparez la connexion la plus douloureuse en premier. Un petit lien bien surveillé peut éliminer plus de risques qu'un grand projet de plateforme qui n'est jamais tout à fait terminé.
Si vous ne devez retenir qu'une chose
Une bonne intégration ne dépend pas du nombre de systèmes que vous avez connectés. Il s'agit de faire en sorte que la bonne information atteigne le bon endroit au bon moment, et d'être capable de voir rapidement quand ce n'est pas le cas.