Tous les témoignages de clients
Comment Continental a remplacé Lotus Notes et Domino par le Low-Code
La plupart des gens savent continental pour son activité de pneumatiques. Mais le constructeur automobile a évolué vers bien plus que cela, proposant désormais des solutions télématiques, des moteurs électriques, des technologies de conduite automatisée et bien plus encore. Aujourd'hui, Continental compte plus de 241,000 573 employés sur XNUMX sites dans le monde.
Avec l'élargissement de sa gamme de produits, Continental a pris la décision stratégique de devenir plus qu'un fabricant de matériel informatique en devenant une société informatique qui fournit également des logiciels. Fournir des services à ses clients qui exploitent ses logiciels et son matériel est devenu un objectif clé pour l'organisation. Pour ce faire, Continental a décidé d'examiner de près remplacement de Lotus Notes et Domino.
Les moteurs du changement
L'un des principaux moteurs du changement chez Continental a été la nécessité de s'adapter rapidement et de manière innovante à des marchés et des environnements en constante évolution. Non seulement les clients de Continental modifient leur comportement et leur interaction avec la technologie, mais les attentes de leurs employés en matière de création d'applications évoluent également.
Continental commence à voir de plus en plus de personnes chercher à utiliser la technologie pour résoudre les problèmes au sein de l'entreprise, tout en souhaitant comprendre comment le faire elles-mêmes. La culture de l'entreprise évolue vers un environnement de libre-service lorsqu'il s'agit d'utiliser, de consommer et de créer des technologies.
Avant de moderniser ses processus, le délai de mise sur le marché de Continental était d'un à trois ans, selon la complexité Ce retard technologique constituait un défi majeur et ne permettait pas la flexibilité nécessaire pour s'adapter rapidement aux changements. Continental ne disposait pas seulement des outils nécessaires au développement d'applications d'entreprise et de la capacité à adopter et à s'adapter à des environnements en constante évolution, mais elle manquait également d'une culture permettant de gérer l'incertitude et les imperfections des logiciels.
Le deuxième facteur de changement a été la dépendance de Continental aux applications Lotus Notes et Domino. L'équipe informatique était chargée de développer, de maintenir et d'améliorer des centaines d'applications exécutées sur Domino. Modernisation héritée et un remplacement de Lotus Notes semblait inévitable.
Après avoir migré avec succès les outils de messagerie et de productivité vers Office 365, ils ont tenté de mettre en œuvre des processus permettant une plus grande agilité au niveau du réseau et de la culture, contribuant ainsi à accélérer le développement. Ce projet a abordé le changement de culture et de technologie, mais a en quelque sorte laissé un vide pour toutes les applications Domino.
Cette lacune et la nécessité de remplacer toutes ces applications ont poussé Continental à trouver des alternatives à Lotus Notes et Domino.
5 raisons de remplacer Lotus Notes et Domino
La décision de Fleischer de remplacer Lotus Notes et Domino s'explique par cinq raisons :
1. Latence et bande passante
Une application exécutée sur Domino a rencontré des problèmes de latence dans des endroits éloignés en Asie en raison de l'hébergement allemand. Les utilisateurs ont dû acheter des ordinateurs portables et des machines séparés, car il fallait environ 10 minutes pour exécuter un clic sur un bouton de l'application.
L'application se bloquait souvent et les utilisateurs ne pouvaient plus continuer à travailler. L'ensemble du processus ralentissait ou s'arrêtait complètement, ce qui posait de graves problèmes à l'entreprise et expérience utilisateur.
2. Maintenabilité
Continental a une demande constante de nouvelles fonctionnalités qu'elle souhaite mettre en œuvre. Pourtant, avec la dette technique Avec l'augmentation des applications Domino, il est devenu de plus en plus difficile d'ajouter une fonctionnalité simple.
Maintenir et améliorer ces applications est devenu un véritable défi. S'ils ajoutaient une fonctionnalité, ils en détruisaient 10 autres sans le savoir, malgré des tests rigoureux.
3. Réutilisabilité
Continental souhaitait accélérer les projets de développement de logiciels en construisant composants réutilisablesAvec Domino et tout le code à usage unique, il est devenu presque impossible de réutiliser ce qui était déjà construit.
4. Qualité
Continental doit garantir la qualité des applications qu'elle développe. Cela n'était pas seulement un défi avec Domino, mais cela nécessitait également un effort et un investissement considérables. Lors de l'ajout de fonctionnalités à une application, il fallait plus d'un an pour les tester, identifier les bugs, les corriger et recommencer jusqu'à ce que la qualité soit au rendez-vous.
5. Espace de rangement
Domino n’est pas exactement une base de données, et l’accès de Continental à l’espace de stockage au sein des applications diminuait rapidement.
Avec plus de 10 ans de données collectées dans une application donnée, les applications Domino atteignaient rapidement leurs limites. Les cycles de nettoyage de la base de données devenaient de plus en plus courts et l'entreprise était confrontée à la nécessité d'archiver et de libérer de l'espace, ce qui avait un impact sur les processus métier de Continental.
Domino aurait pu être une solution acceptable lorsque Continental était uniquement une entreprise de fabrication de pneus, mais à mesure que l'entreprise s'est développée, les problèmes liés à Domino sont devenus des obstacles importants. En conséquence, l'équipe informatique de Continental, qui est à proximité de l'entreprise — élaborer un plan pour moderniser toutes les applications Domino de l'entreprise.
Évaluation des alternatives
Avec un plan de modernisation de l’héritage en place, l’organisation était sur le point de connaître un changement important, non seulement en termes de technologie, mais également en termes de mentalité et de culture.
En évaluant les solutions, le service informatique de l’entreprise s’est rendu compte que sa pile technologique manquait d’une plate-forme polyvalente permettant mise sur le marché rapideIls savaient qu’ils avaient besoin d’un cinquième pilier en plus de leur ERP/CRM existant, d’Office 365/Sharepoint, d’applications spécifiques au domaine et de code personnalisé.
Plus précisément, Continental souhaitait une plateforme qui :
- C'est facile et amusant à utiliser et compréhensible par les utilisateurs professionnels
- Permet la réutilisabilité avec des protocoles et des structures communes
- Garantit la qualité du résultat
Dans son discours prononcé lors d'une récente Mendix Monde, Fleischer a expliqué les options disponibles et pourquoi elles étaient pas un bon choix pour Continental :
Des solutions universelles
Après des recherches approfondies, Continental a conclu qu’une seule solution technologique ne fonctionnerait pas pour toutes les applications, car beaucoup sont construites ou utilisées différemment.
Réutiliser les technologies existantes
Après avoir réalisé qu'une approche unique ne fonctionnerait pas, Continental a essayé de regrouper les applications et les technologies. Ils ont réalisé que certains cas d'utilisation étaient étroitement liés à leurs systèmes d'enregistrement, comme SAP, où il était logique d'utiliser SAP comme back-end et Fiori comme front-end.
Cependant, les délais de livraison et les coûts de maintenance étaient prohibitifs. Si ce n'est pas un processus SAP de base, ce n'est pas une bonne solution pour SAP.
Solutions commerciales prêtes à l'emploi (COTS)
Certaines applications étaient mieux adaptées à un Solution COTS.
Par exemple, lorsque les processus étaient spécifiques à un domaine ou à un cas d'entreprise, ou lorsqu'ils nécessitaient une logique métier complexe et davantage de temps à mettre en place, une solution COTS permettrait à Continental d'acheter exactement le produit dont elle avait besoin au lieu de créer quelque chose en interne ou de réutiliser une technologie qu'elle possédait déjà.
Cependant, aucune solution clé en main ne pouvait répondre à leurs nombreuses exigences et cas d'utilisation, même avec toutes les applications spécifiques à un domaine du portefeuille de Continental qui partageaient un même langage.
Constructions personnalisées
Si tout échoue, vous pouvez toujours avoir une solution sur mesure avec .NET ou tout autre langage de programmation traditionnel, n'est-ce pas ? Bien sûr, mais cette option est coûteuse et demande beaucoup d'efforts. Ce n'est pas une solution qui permet à une organisation d'appliquer rapidement les modifications. Si le service informatique doit écrire du code personnalisé, les utilisateurs professionnels continueront d'être exclus du processus de développement et ne comprendront pas une solution écrite en .NET.
Atterrissage avec le Low-code
Après avoir étudié le marché et identifié les produits et les fournisseurs qui pourraient combler leur lacune technologique, Continental s'est tourné vers développement low-code.
Les fournisseurs ont été invités sur place à créer une application et à tester différentes technologies en fonction de leurs besoins. Continental a évalué les fournisseurs low-code selon les critères suivants :
- Facilité de configuration
- Comment les applications sont créées
- La quantité de code personnalisé ou de modules complémentaires requis
- Comment le modèle de données est construit et comment la logique métier est décidée
- Dans quelle mesure la technologie couvre-t-elle les exigences initiales en matière de gestion des utilisateurs et des accès, d'intégrations, de gestion des demandes et des flux de travail, d'automatisation, de recherche, de surveillance et de création de rapports ?
Continental a choisi Mendix parce que la plateforme low-code :
- Permet collaboration entre l'entreprise et l'informatique
- Leur permet de créer et itérer des solutions rapidement
- Permet de remplacer les processus obsolètes par des processus adaptables, workflows automatisés
Une nouvelle application en seulement 12 semaines
Continental a commencé par reconstruire une application de 300 étages, Electronic Capital Request, en seulement 12 semaines. Mendix, un processus de reconstruction initial a duré plus d'un an. Continental a non seulement accéléré le processus de manière significative avec Mendix, mais ils ont également considérablement amélioré l'expérience de fin des opportunités .
L'application Electronic Capital Request est un outil de demande et d'approbation de budget comptant 10,000 10,000 utilisateurs fréquents, soit un débit d'au moins XNUMX XNUMX demandes soulevées, approuvées et traitées dans cette application chaque année.
Chaque année, l'application voit environ 20 gigaoctets de fichiers joints s'ajouter au sein de l'application. Construite sur l'architecture Domino, l'application a très vite atteint sa limite de stockage. Mais avec Mendix, l'application est illimitée.

Passage à l'Agile
Au début de mon travail avec MendixContinental avait appris la Méthodologie agile est la clé pour offrir une valeur maximale au fil du temps. Le succès de Continental dans le cadre de ce projet a créé un argument en faveur de la mise en œuvre d'Agile dans toute l'entreprise. Ils voient une énorme marge de progression, en particulier dans le processus de déploiement qui a pris plus de temps à mettre en place que l'application.
Continental a commencé à se préparer à ce changement en affectant des équipes de projet dédiées aux côtés Mendix les développeurs pour garantir que la vitesse et la qualité sont conformes aux normes.
Que réserve l'avenir?
L'évolution de Continental est la preuve que chaque organisation doit devenir une société de logiciels pour survivre et prospérer, et elle prévoit de continuer mise à l'échelle.
Continental dispose désormais d'une équipe interne Mendix développeurs qui, selon eux, grandiront chaque année. En tant qu'équipe Agile axée sur le low-code, ils construiront eux-mêmes des parties d'applications et des applications entières, et utiliseront Mendix en tant que plate-forme permettant aux utilisateurs professionnels de spécifier ce dont ils ont besoin avant de transmettre un projet au service informatique.
Cet article de blog a été initialement publié le 10 mai 2019 et a été mis à jour pour inclure les informations les plus récentes.