Blog Post

MES agile versus déploiement agile


MES agile versus déploiement agile

Il a récemment été porté à mon attention qu'il existe une confusion sur le terme "Agile" et sur la façon dont il est lié à un Manufacturing Execution System ou MES. J'ai pensé qu'il serait utile de fournir quelques informations sur la façon dont ce terme peut s'appliquer soit à la méthodologie de déploiement, soit à la façon dont l'application est conçue. Je poursuivrai ensuite cette discussion dans un article complémentaire sur les raisons pour lesquelles vous avez vraiment besoin des deux. Tout d'abord, parlons du MES agile et de sa différence avec un déploiement agile.

À première vue, ces deux concepts peuvent sembler très similaires. En réalité, ils sont très différents. Certains fournisseurs de logiciels semblent (délibérément ?) brouiller les pistes pour pallier les lacunes de leurs propres applications. La plupart des gens soutiendraient qu'une méthodologie de déploiement agile est une meilleure pratique acceptée. Un système agile d'exécution de la fabrication (MES), cependant, est une grande affaire - il pourrait être l'une des plus importantes percées de la décennie pour cette catégorie d'applications logicielles.

Développement de produits en cascade ou en mode agile

Si l'on remonte 20 ans en arrière, la quasi-totalité des logiciels étaient écrits selon une stratégie en cascade, un concept introduit pour la première fois en 1970 par le Dr Winston W. Royce. Cette approche traditionnelle et monolithique consistait en une méthodologie séquentielle et non itérative. Il s'agit essentiellement d'un cadre dans lequel le développement de logiciels se déroule de manière séquentielle à travers une série de phases. Une bonne analogie est que le processus de développement s'écoule vers le bas comme une cascade à travers différentes étapes.

Le principal avantage d'un cadre en cascade est que le cycle de développement échelonné impose une discipline : chaque phase a un début et une fin définis, et les progrès peuvent être identifiés de manière concluante (avec des jalons) par le vendeur et le client. L'accent mis sur les exigences et la conception avant l'écriture d'une seule ligne de code permet de minimiser le gaspillage de temps et d'efforts et de réduire le risque de retard dans le calendrier ou de non-respect des attentes du client. La critique la plus importante porte sur le fait que, très souvent, les clients ne savent pas vraiment ce qu'ils veulent au départ. Ce qu'ils veulent émerge des interactions bidirectionnelles répétées au cours du projet.

Le modèle de développement Waterfall trouve ses racines dans les industries de la fabrication et de la construction - des environnements physiques hautement structurés où les changements de conception devenaient prohibitifs à mesure que l'on avançait dans le processus de développement. C'est pourquoi la mentalité de "verrouillage du code et de la conception" est intégrée dans le modèle.

Agile adopte une approche complètement différente. Avec ce modèle, on reconnaît que le monde fonctionne de manière beaucoup plus dynamique. Il repose plutôt sur une approche de développement itératif. Les exigences et les solutions évoluent avec une plus grande collaboration dans le cadre d'une structure beaucoup plus lâche.

Avec ce modèle, le plus grand avantage est que l'application résultante sera plus étroitement alignée sur ce que veulent les utilisateurs finaux - un objectif souvent changeant. Les applications peuvent être développées plus rapidement, avec un nombre réduit de fonctionnalités au départ. De nouvelles fonctionnalités peuvent toutefois être ajoutées rapidement dès qu'un besoin confirmé est identifié. En conséquence, le retour d'information des utilisateurs est plus pertinent, sachant que le changement peut intervenir rapidement. Cela permet aux projets de passer plus rapidement d'une étape à l'autre. Bien menée, une équipe de développement de produits agile peut fonctionner avec une plus grande efficacité et moins de gaspillage, ce qui se traduit par une réduction des coûts.

Les défauts d'un modèle de déploiement Agile sont principalement centrés sur la dérive de la portée. Étant donné la nature itérative d'un modèle Agile, il peut être difficile de savoir quand un projet Agile est terminé. Les entreprises qui cherchent à tirer parti du cadre Agile doivent comprendre qu'un projet dont la durée et/ou le coût sont fixes ne signifie pas qu'il a une portée fixe. Par conséquent, il se peut que vous ne réalisiez pas tout ce que vous aviez prévu de faire dans les délais prévus.

Mise en œuvre agile du MES

De la même manière qu'une application peut être développée selon une approche en cascade ou agile, ces concepts peuvent également être appliqués au processus d'installation d'une application, une fois celle-ci écrite. Les deux concepts sont pratiquement les mêmes. Un projet de mise en œuvre d'un système MES commence généralement par la collecte d'une liste complète d'exigences et d'objectifs, suivie de l'identification de toutes les parties prenantes concernées, puis de l'évaluation de l'impact des changements qui se produiront une fois le nouveau système MES installé.

Quel que soit votre modèle de déploiement, la conception initiale du programme, l'étendue des travaux et les éléments d'architecture vont probablement changer. Plus vous êtes loin dans le processus lorsque ces changements sont identifiés, plus la durée du retard qui en résultera sera importante. Le coupable commun : les choses changent. Les exigences sont modifiées. De nouvelles parties prenantes sont impliquées et la complexité continue de croître. C'est ici que les avantages d'une approche Agile deviennent très prononcés et significatifs.

Applications MES monolithiques ou agiles

De même, les systèmes d'exécution de la fabrication peuvent être considérés comme ayant une architecture logicielle monolithique ou agile.

Regardez l'enregistrement de ce webinaire pour en savoir plus sur la façon d'entamer le processus de mise à la retraite de votre ancien MES monolithique.

Il peut être difficile d'ajouter de nouvelles fonctionnalités ou d'étendre les capacités des applications MES typiques des "grands fournisseurs". Ces nouvelles fonctionnalités doivent souvent attendre un nouveau Service Pack ou une mise à niveau majeure de la version du produit. D'une certaine manière, cela ressemble beaucoup à un modèle de développement ou de mise en œuvre Waterfall, n'est-ce pas ?

Une application MES Agile possède une architecture qui permet à une équipe de mise en œuvre (ou à ceux qui sont chargés d'effectuer les mises à jour ou la maintenance future) d'effectuer dynamiquement des mises à jour des capacités rapidement au logiciel lui-même - en plus de la façon dont il est déployé.

Un exemple pourrait être la modification d'une interface utilisateur et de ses fonctions connectées dans un environnement réel. Cette mise à jour pourrait avoir lieu entre les connexions des utilisateurs. Dans ce cas, une architecture agile vous permet de gérer, de maintenir et de mettre à niveau une application MES pour qu'elle reste actuelle et pertinente. L'avantage clé est une flexibilité considérablement plus élevée sur les fonctionnalités qui sont déployées initialement et celles qui peuvent être facilement ajoutées au fil du temps.

Dans mon prochain billet, je parlerai de la façon dont un MES agile peut exister, et de la puissante combinaison qui est possible lorsqu'on associe un MES agile à une stratégie de déploiement agile.

Nouvel appel à l'action


clients vedettes de ibaset