.svg)
Comment les fabricants répartissent leurs systèmes entre le cloud et le site
Le secteur manufacturier est celui où le sur site n'a jamais disparu. Le cloud est désormais la norme pour les nouveaux déploiements, mais la base installée de systèmes locaux dans les usines, la production réglementée et la chaîne d'approvisionnement de la défense reste importante et majoritairement volontaire. La plupart des fabricants ne choisissent donc pas entre les deux. Ils utilisent déjà les deux et décident de ce qui doit être migré ensuite.
La division suit généralement une logique : à quel point un système doit-il rester opérationnel en cas de coupure réseau ? La planification de la production, le contrôle au niveau des machines, les points de contrôle qualité et l'exécution en entrepôt restent au plus près du terrain. La finance de groupe, la planification de la demande, l'analytique, les portails clients et, de plus en plus, les charges de travail liées à l'IA tournent dans le cloud, où la puissance de calcul est élastique et l'accès indépendant d'un bâtiment.
Cette division est une bonne pratique d'ingénierie. C'est aussi là que les problèmes commencent, car les deux ensembles de systèmes ont été achetés séparément, utilisent des formats différents et n'ont jamais eu de responsable commun.
Pourquoi les fabricants conservent-ils leurs systèmes de production sur site ?
Une heure d'arrêt de production coûte plus cher que n'importe quelle économie de licence qu'une migration cloud pourrait financer. C'est ce calcul, plutôt que la prudence, qui maintient les systèmes critiques à l'intérieur du bâtiment. Le raisonnement se divise en trois points précis.
La latence est le premier. Une décision de planification ou de verrouillage située à côté de l'équipement ne peut pas attendre un aller-retour vers une région située à plusieurs centaines de millisecondes. L'autonomie est le second, car une usine doit continuer à produire malgré une panne WAN, ce qui exclut toute dépendance à une liaison sortante. La réglementation est le troisième, car les dossiers de production et de qualité dans les secteurs réglementés comportent des obligations de résidence et de conservation des données plus simples à justifier localement.
L'investissement déjà réalisé dans des systèmes fonctionnels explique le reste. Une partie de cette empreinte est une habitude plutôt qu'une exigence, et les cas justifiés sont plus rares qu'il y a cinq ans. Plusieurs d'entre eux restent néanmoins réels.
Qu'est-ce que les fabricants gagnent à migrer la planification et l'analytique vers le cloud ?
La comparabilité entre les sites est le gain principal. Lorsque chaque usine rapporte ses données depuis sa propre instance locale, une question au niveau du groupe sur la production, les rebuts ou la marge par ligne devient un exercice de réconciliation plutôt qu'une simple requête.
La puissance de calcul élastique est le second gain. La planification de la demande, la modélisation de scénarios et l'analytique qualité sont des charges de travail irrégulières qui restent inactives la majeure partie du mois, ce que le matériel local fixe gère très mal. Le troisième est que les mises à jour ne sont plus des projets planifiés autour des fenêtres de production.
L'IA a également sa place ici, bien que ce ne soit pas le point principal. Les modèles ont besoin de données historiques regroupées sur plusieurs sites et années, structurées de manière cohérente. C'est un problème de données avant d'être un problème de modèle, c'est pourquoi les fabricants qui se lancent dans l'IA finissent généralement par migrer leur couche de données en premier.
Pourquoi les systèmes locaux et cloud finissent-ils par créer des silos séparés ?
Personne ne gère le trafic entre eux. L'informatique d'usine gère ce qui tourne dans le bâtiment et l'informatique de groupe gère ce qui tourne dans le cloud, tandis que les flux passant de l'un à l'autre appartiennent à celui qui a construit la dernière connexion.
Ce qui comble ce fossé est bien connu. Une liaison point à point par paire de systèmes, écrite par une personne différente chaque année. Un transfert de fichier nocturne que personne ne surveille jusqu'à ce qu'il manque. Un tableur où quelqu'un compare la production de l'usine aux rapports du groupe chaque lundi. Le symptôme est l'existence de deux versions de la vérité, où le directeur d'usine et le directeur des opérations citent des chiffres de production différents provenant de systèmes qui pensent tous deux être dans le vrai.
Pour y remédier, il faut traiter ces flux comme des composants avec un responsable attitré, plutôt que comme une série d'incidents isolés. Le coût intervient avant les bénéfices, et c'est un point sur lequel il faut être transparent. En contrepartie, on s'affranchit des vérifications manuelles et on gagne l'assurance qu'une modification d'un côté ne cassera pas silencieusement quelque chose de l'autre.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
