Jusqu'à présent, dans notre série de blogs sur notre position de challenger dans The 2022 Gartner® Magic Quadrant™ for Manufacturing Execution Systems (MES), nous avons couvert beaucoup de détails sur les concepts de composabilité et la façon dont ils s'appliquent dans différentes industries.
Il est maintenant temps de réfléchir à la raison pour laquelle la plateforme d'opérations de première ligne de Tulipa été choisie comme challenger dans le Quadrant MES, et ce que cela dit, selon nous, des MES traditionnels.
La principale différence entre une plateforme en tant que service (PaaS) et un MES traditionnel est que l'architecture de la première permet une solution composable.
À quoi ressemble une architecture composable ?
L'architecture composable repose sur quatre piliers.
Agilité
L'agilité exige que vous puissiez adapter les processus à ce qui doit être fait, et non l'inverse. Ce pilier se caractérise par une mise en œuvre, des mises à jour et des itérations rapides, ainsi que par des structures de données flexibles et accessibles.
Extensibilité
Une architecture composable est modulaire dans sa capacité à se connecter à d'autres solutions, en offrant une API ouverte avec des connecteurs préconstruits. Elle doit également offrir une connectivité périphérique sans code et des capacités à faible code.
Accessibilité et évolutivité
Une architecture composable doit vous permettre de reproduire des solutions pour des sites et des situations similaires. Elle doit être fiable et performante à mesure qu'elle se développe. Et les bonnes données doivent être accessibles de n'importe où, et pas seulement d'une certaine station ou même d'un certain site, dans les structures de données dont les gens ont besoin.
Centré sur l'humain
La composabilité est par nature centrée sur l'humain. Une architecture composable doit présenter des interfaces intuitives et des flux de travail simplifiés avec des données provenant des appareils des travailleurs. Ces exigences correspondent aux souhaits et aux attentes de la main-d'œuvre industrielle d'aujourd'hui. Les gens veulent travailler pour des entreprises innovantes qui valorisent leur expérience.
Comment étaient les modèles du passé ?
Les MES traditionnels ne peuvent pas gérer la composabilité comme le fait une plate-forme.
Imaginez que vous souhaitiez déployer un MES traditionnel sur un site donné. Vous passez par des processus d'exigences et des diagrammes de flux opérationnels et vous choisissez un fournisseur. Le fournisseur commence à déployer le MES.
Presque toujours, une personnalisation de votre part est nécessaire. Vous devez vous adapter aux exigences du système en matière d'intégration ou de processus.
Dans le meilleur des cas, vous avez raison sur tous les points de vos exigences, et rien ne change entre le moment où vous avez choisi le MES et celui où vous l'avez entièrement mis en œuvre.
Maintenant, vous voulez le déployer sur un autre site. Les choses sont différentes là-bas. Vous devez prendre des dispositions supplémentaires. (Vous n'avez peut-être pas de machines sur ce site, alors que votre première implémentation ne concernait que les machines, par exemple). Ensuite, vous voulez ajouter ce système à un troisième site. Dans chaque implémentation du même MES, chaque modification et personnalisation que vous apportez au code de base est un peu différente de la précédente.
Maintenant, disons que vous voulez identifier une meilleure pratique de votre deuxième site qui est directement applicable à votre troisième. Vous rencontrez un problème. Le concept même d'une base de code monolithique nécessite une personnalisation pour la mise en œuvre de chaque site.
Ce n'est pas le cas d'une approche microservices.
Alors, qu'est-ce qui retient les gens de passer à cette approche, maintenant que l'hésitation à l'égard du cloud est, dans l'ensemble, morte ?
L'héritage. Les fabricants doivent toujours faire face aux conséquences des décisions architecturales qui ont été prises lorsque tous les logiciels ont été conçus pour être utilisés sur site. Il n'est pas possible d'extraire cette base de code, de l'expédier dans le cloud et de s'attendre à ce qu'elle fonctionne.
Il est difficile de recréer la façon dont l'architecture cloud-native vous permet de construire si vous n'avez pas commencé à le faire.
Vous êtes donc coincé. Si vous n'avez pas commencé par le cloud-native, il est trop difficile de prendre les meilleures pratiques et de passer au site suivant. Il est peut-être encore plus difficile de passer de MES 1.0 à MES 2.0, ou 2.1 ou 2.2. C'est douloureux et lent.
C'est votre point de vue. Mais imaginez ce que c'est pour un fournisseur de MES traditionnel. Quelles sont les implications pour lui ?
S'il gère 12 clients avec 12 sites chacun, il doit maintenir 144 versions différentes de sa base de code. Toute modification apportée à son offre principale doit être rétro-compatible avec 144 versions différentes de ce code. Il s'agit d'une solution complexe et difficile.
Et cela explique la lenteur de l'évolution de l'innovation que nous constatons dans le domaine des MES. Une décision architecturale du jour zéro dicte tout.
Pour récapituler, le modèle MES traditionnel est :
Centrée sur les systèmes, pas sur les humains
Difficile à mettre à niveau
Mise à jour lente et coûteuse
Complexe et cloisonné
Comment Tulip remet-il en question le MES traditionnel ?
Par rapport à l'architecture précédente que nous avons décrite (qui, elle aussi, est née sur site), une architecture "cloud-native" facilite et accélère les choses.
La plateforme Tulip n'a qu'une seule base de code et les applications sont des configurations, et non des personnalisations codées. Si l'on repense aux piliers de l'architecture composable, l'agilité et l'extensibilité l'exigent.
Une base de code unique permet des mises à jour régulières et rapides de cette base de code, ce qui équivaut à des mises à niveau de la plate-forme toutes les deux semaines ou tous les trimestres sur tous vos sites, plutôt qu'à des révisions et des personnalisations. Vous avez accès à de nouvelles fonctionnalités plus rapidement.
Cela signifie également que vous pouvez facilement reproduire vos meilleures pratiques sur l'ensemble des sites via les applications.
Vous vous souvenez de Sofiya, qui a créé une solution pour ses opérateurs de première ligne chez Stanley Black & Decker ? Si elle voyait l'opportunité de déployer cette application sur dix autres sites susceptibles d'en bénéficier, elle pourrait le faire de manière triviale. Cela serait pratiquement impossible si SB&D avait commencé son parcours vers le développement d'applications avec l'architecture précédente et un MES traditionnel.
Pour récapituler, les avantages d'une plateforme nativement cloud et d'un modèle composable :
La même base de code fonctionne sur tous les sites
Partage des meilleures pratiques en matière d'applications
Vue d'ensemble des opérations
Mises à jour silencieuses toutes les deux semaines
Accès plus rapide à l'innovation
Les applications sans code permettent la flexibilité
Dans le Magic Quadrant™ 2022 de Gartner® pour les systèmes d'exécution de la fabrication (MES), nous voyons beaucoup de commentaires réfléchis sur les implications du changement sur le marché. Et nous voyons l'introduction de la capacité MES Architectural Innovation, qui suppose que le fournisseur propose une architecture microservices qui prend en charge le niveau d'agilité et la vitesse de développement que nous pensons nécessaire à la réussite de l'entreprise manufacturière d'aujourd'hui.
Les MES traditionnels ne le permettent pas. C'est pourquoi Tulip est un challenger.
Malgré cela, il est important de noter que le passage du MES traditionnel à la composabilité n'est pas spécifique à Tulip.
C'est plus fondamental. Il s'agit de la façon dont nous envisageons le développement de logiciels et où il doit et peut se produire : Les solutions traditionnelles étaient construites sur des décisions architecturales on-prem, mais la composabilité nécessite une architecture cloud-native. Nous sommes prêts à faire progresser la fabrication.
Automatiser la collecte de données et améliorer la productivité avec Tulip
Discutez avec un membre de notre équipe pour voir comment un système d'applications peut connecter les travailleurs, les machines et les appareils de vos opérations.
