Principales sorties:

• Enexis s'attaque à l'évolution du paysage énergétique aux Pays-Bas en utilisant le développement low-code pour optimiser les processus pour les ingénieurs de terrain.
• Formé 24 heures sur XNUMX en interne et en externe Mendix développeurs pour mettre en place une usine d'applications qui a produit 100 applications en seulement deux ans avec du low-code et le cycle de développement agile.
• Nous avons continué à fournir de l’énergie à plus de 2.8 millions de foyers aux Pays-Bas.

« Le changement est difficile », déplore ma collègue en essayant d’accéder à notre nouveau système de gestion des dépenses. Chaque changement apporté à un nouveau système ou à une nouvelle façon de travailler, aussi minime soit-il, entraîne des difficultés et perturbe les processus et les personnes.

Comme pour ma collègue (qui a d'ailleurs réussi à comprendre le nouveau système avec brio), changer sa façon de travailler est difficile pour toute entreprise. Mais réfléchissez aux changements Enexis, une entreprise de maintenance du réseau électrique qui gère un tiers de l'énergie des Pays-Bas, a adapté son processus de développement d'applications qui l'aide à faire face aux changements du marché de l'énergie. Les moyens de subsistance de millions de ménages et d'entreprises qu'elle dessert étaient en jeu.

Voici comment Enexis a apporté des changements massifs à ses méthodes de développement et de distribution d'applications pour fournir des produits essentiels à l'entreprise et à ses clients.

Un chef d'orchestre du changement

Le secteur énergétique des Pays-Bas était autrefois assez stable et prévisible. Oscar Berger, Responsable du bureau des DSI chez Enexis, ils « travaillaient dans un secteur très stable et prévisible. La demande en énergie – électricité et gaz – est à sens unique et dépend du développement urbain et de la croissance économique. On pouvait planifier des années à l’avance. »

Mais le pays s'est récemment retrouvé au cœur d'une transition énergétique, comme le dit Berger. La demande en électricité a augmenté. Berger cite la croissance des ventes de voitures électriques et le doublement des factures d'électricité des ménages suite à l'achat de ce type de véhicule. Cela a nécessité de modifier les installations des maisons et des entreprises pour répondre aux nouveaux besoins des consommateurs.

Les consommateurs deviennent également producteurs d’électricité grâce à des technologies telles que les panneaux solaires. Ainsi, ce qui était autrefois un flux d’électricité à sens unique est devenu bidirectionnel.

Enfin, en réponse à la hausse des niveaux de CO2, les Pays-Bas ont décidé d’arrêter de produire du gaz d’ici 2050. « Cela signifie », explique Berger, « que nos infrastructures gazières seront obsolètes vers 2050. La question est de savoir ce que nous allons en faire. »

Le passage d'un flux d'énergie unidirectionnel à un flux bidirectionnel et l'abandon progressif du gaz ont obligé Enexis à modifier sa façon d'entretenir l'infrastructure.

Pour que tous les changements ci-dessus puissent se produire, les ingénieurs de terrain et les sous-traitants d'Enexis avaient besoin de l'aide du service informatique pour être plus efficaces.

Le transformateur low-code

L'équipe informatique d'Enexis a trouvé la réponse dans la façon dont elle gère son portefeuille d'applications. En tant que grande entreprise disposant d'applications de base massives, elle devait gérer ses systèmes critiques tout en évoluant suffisamment rapidement pour répondre aux besoins émergents de ses homologues commerciaux, tout en continuant à fournir de l'énergie à 2.8 millions de foyers. C'est à ce moment-là qu'elle s'est tournée vers la Mendix plate-forme de développement low-code.

Nos infrastructures gazières seront obsolètes vers 2050. La question est : qu’allons-nous en faire ?

Enexis a construit une « architecture de transition » avec MendixIls étaient impatients de remplacer toute leur infrastructure informatique pour innover et répondre aux besoins de l'entreprise et des clients. Cela devait se produire immédiatement. L'architecture de transition a permis à leurs équipes de développement de concevoir, de développer et de déployer des applications à une vitesse qu'elles ne pouvaient pas atteindre avec la norme l'architecture d'entreprise. Berger a reconnu l’importance de faire approuver officiellement l’architecture de transition par son bureau, plaisantant en disant qu’il avait donné à son équipe « une excuse pour ne pas se conformer à l’architecture définie ».

Les résultats n’ont cependant pas été une mince affaire. Prenons par exemple l’application des autocollants. Selon Berger, le principe est simple : les 40,000 XNUMX stations Enexis doivent être dotées d’autocollants qui sensibilisent à la sécurité et mettent en garde contre les risques spécifiques posés par les équipements spécifiques hébergés sur ce site. Définir et exécuter un projet visant à remplacer ces autocollants représente un travail considérable.

L'application Sticker permet à Enexis de mettre à jour les autocollants à la demande. Des capteurs dans la station indiquent aux ingénieurs de terrain à proximité que la station a besoin d'un nouvel autocollant de promotion de la sécurité. Ils peuvent se rendre à la station la plus proche d'eux, remplacer l'autocollant et l'enregistrer directement dans l'application. En utilisant les services de localisation pour alerter les ingénieurs qui se trouvaient déjà à proximité de la station, ils ont pu économiser du temps et des ressources en leur attribuant une tâche mineure supplémentaire, au lieu d'envoyer des ingénieurs dédiés supplémentaires sur leur chemin.

Une augmentation des livraisons d'applications

L'innovation numérique ne s'est pas arrêtée avec le succès de l'application Sticker. Enexis a plutôt continué à réévaluer la manière dont elle a constitué ses équipes. Enexis a lancé ce qu'elle a appelé une usine d'applications. Cela a commencé avec quatre Mendix développeurs. Ces développeurs ont travaillé avec l'architecture de transition et ont appris comment l'utiliser au mieux Mendix comme outil de développement principal. Trois mois plus tard, cette équipe a été divisée en deux équipes de deux, et chaque équipe a reçu deux développeurs supplémentaires qui ont ensuite été formés sur Mendix. Trois mois plus tard, les équipes ont été à nouveau divisées et dotées de plus de développeurs. À ce jour, il existe 24 équipes internes et externes Mendix les développeurs créent des applications à une vitesse inimaginable pour Enexis avant le low-code.

Le résultat : 100 applications construites et déployées en deux ans.

Il ne s'agit pas seulement du nombre de personnes qui composent ces équipes dédiées à l'Application Factory, mais aussi des rôles qui y sont attribués. Il est très important de créer des normes autour de l'UX. Un Scrum Master fait avancer la chaîne de production. La taille des équipes augmente ou diminue en fonction de l'échelle de l'application en cours de création. S'il s'agit d'une application plus petite (peu de dépendances, par exemple), un seul développeur constitue un nombre approprié de personnes. Si l'application est plus grande, six développeurs sont parfois nécessaires.

Créer davantage d'applications low-code avec davantage de personnes a permis à Enexis d'obtenir un délai de rentabilisation plus rapide.Par exemple, Berger cite une application d'inspection que l'équipe a créée en seulement trois mois. Grâce à cette application, lorsque les ingénieurs de terrain se rendent dans les stations et constatent qu'elles ont besoin de peinture, ils ouvrent simplement leur application et l'indiquent. L'intégration SAP créée par l'équipe de développement crée un ordre de travail qui est ensuite envoyé à un sous-traitant d'Enexis qui peut prendre en charge le travail. En trois mois, l'application a été créée et le temps consacré à la planification de l'entretien des stations a été économisé.

100 applications peuvent sembler intimidantes. Adopter une méthodologie Agile et donner aux propriétaires de produits le pouvoir de prendre des décisions concrètes a été un élément clé pour atteindre cette échelle. Un propriétaire de produit aide les développeurs à évaluer et à prioriser les projets pour chaque sprint. Grâce à cette priorisation claire, le département de Berger est en mesure d'améliorer et de maintenir son vaste portefeuille d'applications.

L’App Factory d’Enexis peut faire penser à des ouvriers qui travaillent à la chaîne, mais Berger met en garde contre cette interprétation de la métaphore. Ces développeurs ne sont pas des ouvriers d’usine. Loin de là. Les équipes sont autonomes et décident elles-mêmes des applications qu’elles vont créer ou mettre à jour. Selon Berger, « la force de la métaphore est qu’elle est organisée. Et j’aime que l’agilité soit organisée… Je pense que c’est important de savoir qu’elle fonctionne comme une usine. »

Jusqu’où êtes-vous réellement capable de regarder devant vous ?

Berger mentionne qu'Enexis essaie de se projeter dans l'avenir sur deux ans. Mais de nouveaux défis apparaissent toujours, comme l'IoT. Il cite un autre exemple d'une application intelligente que leur App Factory a pu produire et qui leur a permis d'installer des capteurs IoT dans les stations. Lorsqu'un ingénieur de terrain installe le boîtier dans lequel ces capteurs IoT sont placés, un signal est envoyé à la station centrale. Enexis est capable de capter ce signal à l'endroit où le boîtier est installé et l'ingénieur de terrain reçoit un avis de confirmation dans l'application.

Avec 100 applications en seulement deux ans, Enexis a mis en place un atelier de développement low-code sans précédent. processus de développement d'applicationsEn livrant à grande échelle, ils sont en mesure de répondre aux besoins changeants de leurs clients, de faire face aux transitions du marché de l'énergie et de toujours garder un œil sur l'avenir.