OpCon 18.1: Autonomie pour une entreprise saine

Au tournant du siècle, l’autonomie était à la mode en matière de logiciels informatiques, et j’en étais un ardent défenseur. J’étais également obsédé par l’automatisation depuis mes débuts dans la programmation en 1980 avec un programme appelé Whist qui jouait aux cartes, puis la réalisation d’une simulation complète d’une ligne de production de saucisses. Cette dernière a été utilisée par des ingénieurs pour modéliser les processus de production réels et leur a permis de modifier les paramètres pour voir ce qui se passerait. J’étais conscient des conditions limites et fixais des limites aux entrées sans lesquelles j’aurais facilement pu créer un scénario qui n’aurait eu aucun sens dans le monde réel. J’ai ensuite développé pas mal de solutions d’analyse numérique, puis un programmateur d’entreprise qui fut ma première programmation rémunérée. Je croyais que quel que soit le programme que j’écrivais, il ne devait jamais échouer et devais prendre des décisions intelligentes chaque fois que cela était possible. Dans mon esprit, le programme n’était terminé que lorsqu’il était autonome et facile à utiliser. Dans mon jeune esprit, s’il se passait quelque chose, comme une mauvaise entrée, et que le programme ne pouvait pas se terminer, cela n’était pas un problème tant que le programme tentait de corriger et de gérer la situation. Je voulais également que les écrans soient intuitifs, qu’ils aient le moins possible de texte et d’entrées pour que les utilisateurs n’utilisent pas leur énergie à tenter de savoir que faire. Bref, je voulais de l’autonomie, mais je n’en connaissais pas le terme. Je suppose que je n’étais pas le seul à avoir ce souhait.

Ces premières convictions et impulsions se sont cristallisées pour se transformer en véritables forces motrices à l’origine des logiciels d’entreprise que j’écrivais et, sans le savoir, je concevais et créais des produits logiciels autonomes. Finalement, l’industrie du logiciel s’est impliquée dans ce domaine (en un clin d’œil) et l’autonomie est devenue à la mode. Si je m’en souviens bien, IBM était presque propriétaire du terme au début des années 2000 et avait publié une description détaillée sur l’auto-configuration, l’auto-réparation, l’auto-optimisation et l’auto-protection. Ce fut une période passionnante pour le développement de logiciels et l’autonomie présageait de la résilience future du cloud. L’étendue de l’autonomisation s’est rapidement accrue pour inclure des éléments tels que l’auto-apprentissage et le nombre d’opérations autonomes est passé à 11. Ce sont toujours les piliers de l’autonomie et ils doivent être à la base des logiciels de niveau entreprise, voire de tous les logiciels.

Je n’entends malheureusement que rarement le terme aujourd’hui, sauf dans les conversations sur le corps humain ou le système nerveux. En discutant avec un ami du corps médical, j’ai appris que la nature a inventé l’autonomie il y a des milliards d’années. Dans le corps, l’autonomie est constamment active et régule par exemple la respiration, les processus métaboliques et la fréquence cardiaque. Des signaux de tous types de capteurs différents au sein de notre corps fournissent des informations et le système nerveux involontaire émet des instructions. Par exemple, si nous avons trop chaud, le flux sanguin vers la peau augmente et nous aide à nous refroidir.

Dans la dernière version d’OpCon, nous avons franchi une autre étape intéressante vers la voie de l’autonomisation des entreprises. Les contrats de niveau de service (SLA) sont souvent utilisés pour mesurer les services métier ou informatiques par rapport aux niveaux convenus. En toute logique, il est important de savoir si vous n’obtenez pas le service pour lequel vous avez payé ; mais il n’est cependant pas idéal d’attendre la fin de la réalisation dudit service. Vous voulez le savoir à temps pour pouvoir prendre des mesures correctives. Avec les nouveaux contrats de niveau de service  à optimisation automatique d’OpCon Vision, vous pouvez être averti si un flux de travail doit démarrer en retard ou adapter automatiquement le traitement. Par exemple, en dirigeant des travaux d’impression vers un périphérique de secours, en retardant des processus non critiques ou en procédant à un arrêt dans les cas extrêmes. L’important étant que ces actions autonomes adaptent et protègent les processus critiques pour maintenir votre entreprise en bonne santé, tout comme les autonomies du corps humain.

C’est facile de complexifier les sujets techniques, c’est pourquoi j’aime les explications simples. L’autonomie est essentiellement un système automatique, adaptatif et conscient. J’apprécie maintenant l’explosion des données et des capteurs et informations de l’IdO qui servent d’entrées que les systèmes utilisent pour proposer des applications et des systèmes beaucoup plus autonomes dans de nombreux cas. La complexité croissante des écosystèmes des entreprises et informatiques exige presque un niveau d’intelligence plus élevé, et je pense qu’il est grand temps que nous nous concentrions à nouveau sur l’autonomie. L’automatisation pure est excellente pour contrôler et répondre aux défaillances, mais l’adaptation aux défaillances est plus forte et plus résiliente, et moins susceptible d’entraîner des échecs en cascade, qui sont presque inévitables avec une automatisation débridée. Peut-être qu’il s’agit de la dernière manche de l’automatisation intelligente, peut-être que l’automatisation extrême a vraiment besoin de l’autonomie.

A propos de l'auteur
blank

Paul Wade

Paul Wade est VP Products chez SMA Solutions. Il est responsable de l’orientation stratégique globale des solutions SMA, des relations avec les analystes, du marché de l'automatisation et de nouvelles opportunités. Paul s'efforce constamment de trouver des solutions innovantes et simples à implémenter qui instaurent la confiance et réduisent les coûts de support pour nos clients. Son leadership novateur, combiné à une équipe chevronnée de chefs de produits, contribue à augmenter la croissance et la valeur de nos clients.