La consolidation est une décision concernant l'architecture et la responsabilité
Moins d'outils peuvent améliorer les décisions si cela élimine les fonctions redondantes, les données contradictoires, les responsabilités peu claires et les interfaces inutiles. Le bénéfice ne vient pas de la seule réduction, mais d'un paysage système plus clair.
La bonne taille cible est le paysage d'outils le plus viable qui remplit de manière fiable les tâches commerciales, permet la spécialisation nécessaire et peut être maîtrisé par l'entreprise.
Situation de départ
Les paysages d'outils numériques se développent progressivement. Un nouveau système résout un problème aigu, un département spécialisé a besoin d'une fonction spécifique, un prestataire apporte sa propre plateforme, un produit existant est sous-utilisé et complété par un autre.
Chaque décision individuelle peut être compréhensible. Cependant, la somme crée des données de contact parallèles, plusieurs aperçus de projets, différentes interfaces d'analyse, des stockages de fichiers en double et des automatisations dont la responsabilité est floue.
Les conséquences ne se font pas sentir uniquement dans les coûts de licence. Les décisions sont plus lentes car les informations doivent être recherchées, comparées et vérifiées pour les contradictions. Personne ne sait avec certitude quel système est le principal. Les changements dans un outil atteignent d'autres domaines en retard ou pas du tout.
Ce qui se cache derrière le problème
L'optimisation locale crée une complexité globale
Un service spécialisé choisit le meilleur outil pour sa tâche. De son point de vue, la décision est logique. Pour le système global, elle peut générer des accès supplémentaires, des copies de données, des interfaces et des efforts de support.
Cette tension ne peut être entièrement évitée. Mais elle doit être gérée de manière visible. Un outil spécialisé est justifié si son utilité technique l'emporte sur la complexité supplémentaire et si l'exploitation et l'intégration sont clarifiées.
Les copies de données affaiblissent la fiabilité
Plus les systèmes contiennent les mêmes données clients, produits ou contenus, plus les efforts de maintenance augmentent. Sans source principale claire, des divergences apparaissent. Les employés développent leurs propres méthodes de contrôle ou tiennent des listes supplémentaires.
La conséquence n'est pas seulement un travail inefficace. Les décisions perdent leur fondement car il n'est pas clair quelles informations sont actuelles et contraignantes.
Les fonctions sont achetées mais pas reprises sur le plan organisationnel
Les logiciels peuvent techniquement permettre des tâches. Pour une utilisation réelle, ils nécessitent des rôles, des processus, une qualité de données et un fonctionnement. Si ces éléments font défaut, la fonction reste inutilisée ou n'est maîtrisée que par des individus.
Un autre outil résout rarement ce problème. Il le déplace vers une nouvelle interface.
Positionnement stratégique
Les cadres officiels de technologie et de sécurité soulignent depuis longtemps l'importance de l'inventaire, de la responsabilité, des normes ouvertes, de l'interopérabilité et des dépendances gérables. Ces principes ne plaident pas pour une standardisation globale. Ils plaident pour la transparence et une architecture réfléchie.
La consolidation des outils devrait poursuivre quatre objectifs :
- Clarté des tâches : Chaque système a un rôle identifiable.
- Clarté des données : Les sources et les transferts principaux sont définis.
- Clarté des responsabilités : Le fonctionnement, les droits, la qualité et les coûts sont attribués.
- Capacité de changement : L'entreprise peut intégrer, exporter, remplacer et développer.
Quand moins n'est pas mieux
La réduction peut être préjudiciable si un outil spécialisé approprié est remplacé par une plateforme large qui prend moins bien en charge le processus principal. Une consolidation basée uniquement sur les coûts de licence, ignorant les conséquences de la migration, de la formation ou de la qualité, est également problématique.
Un outil peut rester s'il :
- une tâche stratégiquement pertinente est mieux remplie
- est exploité de manière fiable
- maintient les données et les interfaces sous contrôle
- aucune double structure injustifiable n'a été créée
- a un avantage compréhensible
Le point de vue n'est donc pas « moins, c'est toujours plus ». Il est : chaque composant supplémentaire a besoin d'une justification architecturale.
Perspective pratique
Un examen des outils ne devrait pas commencer par la question de savoir quel produit peut être résilié. Il faut d'abord organiser le paysage système par tâches et par données.
Pour chaque outil, six points sont enregistrés :
- tâche professionnelle
- utilisateurs actifs et rôle responsable
- données stockées ou générées
- Interfaces et transferts manuels
- utilisation réelle des fonctions centrales
- Obstacles au changement ou à la mise hors service
Ensuite, les doublons et les lacunes deviennent visibles. Quatre décisions en résultent souvent :
- conserver et clarifier la responsabilité
- mieux intégrer
- remplacer par un système existant
- arrêter de manière contrôlée
La désactivation n'est terminée que lorsque les données, les processus, les accès, la documentation et les contrats sont nettoyés.
De la quantité d'outils à la clarté du système
Cadre d'action
1. Enregistrer les outils par tâche plutôt que par département
Classez les systèmes en fonction de la tâche qu'ils accomplissent. Cela rend visibles les solutions fonctionnellement identiques, même si elles sont utilisées dans des domaines différents.
2. Définir les sources de données principales
Déterminez pour les types de données centraux quel système fait autorité. Documentez comment les autres systèmes obtiennent et renvoient les données.
3. Vérifier l'utilisation réelle
N'évaluez pas la gamme de fonctionnalités disponibles, mais les fonctionnalités utilisées et dont on est responsable. Les possibilités inutilisées ne justifient pas la complexité.
4. Évaluer pleinement les conséquences de la consolidation
Tenez compte de la migration, des changements de processus, de la formation, des interfaces, des données historiques, des contrats et des risques de défaillance. Une économie à court terme peut coûter cher à long terme.
5. Planifier l'architecture cible et la transition
Définissez les rôles système qui devraient exister à l'avenir. Planifiez le remplacement par étapes et assurez le fonctionnement pendant la transition.
Ce que les entreprises ne doivent pas faire
Les entreprises ne devraient pas fixer d'objectif général tel que « vingt pour cent d'outils en moins ». Un tel chiffre ne dit rien sur les tâches, les risques ou l'impact.
De même, la consolidation ne doit pas être entièrement déléguée à l'informatique. Les départements métier doivent expliquer quels processus et exigences de qualité sont réellement pertinents. La direction doit décider des conflits d'objectifs et des priorités.
Conséquence pour les entreprises
Un paysage d'outils clair n'améliore pas automatiquement chaque performance. Mais il crée de meilleures conditions pour des données fiables, une responsabilité claire et des décisions plus rapides.
Le gain décisif réside dans la maîtrisabilité. Les responsables savent quel système remplit quelle tâche, où les informations font autorité et comment les changements peuvent être mis en œuvre.
La sélection avant une introduction traite « La boîte à outils numérique s'agrandit. La décision devient plus difficile. ». La classification dans une planification globale montre « Ce qu'une feuille de route numérique fiable doit accomplir ». Le modèle d'architecture et d'impact plus complet est en « Des mesures individuelles à un système d'impact numérique ».
La vue d'ensemble est fournie par Domaines thématiques Stratégie numérique.
Connexion technique
Consolider stratégiquement les paysages d'outils existants
Le conseil en systèmes et stratégies numériques n'évalue pas les outils isolément. Il classe les tâches, les données, les intégrations, l'exploitation, les risques et les possibilités de changement. Il en résulte une architecture cible qui conserve la spécialisation nécessaire et réduit la complexité inutile.
Examiner la structure du paysage système numérique
Sources et bases techniques (5)
- GOV.UK Service Standard, „Choose the right tools and technology“. Ouvrir la source
- GOV.UK, « The Technology Code of Practice ». Ouvrir la source
- GOV.UK Service Manual, „Working with open standards“. Ouvrir la source
- NIST, « Cloud Computing Standards Roadmap ». Ouvrir la source
- NIST, « Cybersecurity Framework ». Ouvrir la source
