
Plus de choix augmente d'abord l'effort de décision
Un outil numérique ne doit pas être choisi en fonction de son étendue fonctionnelle ou de sa notoriété, mais selon sa mission, son processus, ses données, ses interfaces, ses responsabilités, son coût total et ses possibilités de migration. La décision stratégique n'est pas : quel produit peut faire le plus ? Elle est : quelle solution répond à l'objectif concret avec des dépendances maîtrisables ?
Plus le paysage des outils s'agrandit, plus une décision d'architecture commune devient importante. Sinon, des bases de données parallèles, des fonctions et des responsabilités redondantes apparaissent, que personne ne maîtrise complètement.
Situation de départ
Au début de l'année 2021, le nombre d'applications numériques pour la communication, la collaboration, le marketing, les ventes et l'analyse était déjà important. De nombreuses entreprises avaient introduit des outils supplémentaires dans les mois précédents pour rester opérationnelles à court terme ou pour créer de nouveaux canaux de contact numériques.
La sélection semblait confortable à première vue. Pour presque chaque tâche, il existait plusieurs solutions spécialisées. En même temps, la décision devenait plus difficile. Les produits différaient non seulement par leurs fonctions et leur prix. Ils influençaient la gestion des données, les processus, les interfaces, les accès, le temps de formation et les possibilités de changement ultérieures.
Ainsi, la question centrale s'est déplacée. La disponibilité d'un outil n'était pas le problème. La capacité à prendre une décision de sélection viable est devenue le goulot d'étranglement.
Ce qui se cache derrière le problème
Les listes de fonctionnalités ne remplacent pas la logique des exigences
Les décisions concernant les outils commencent souvent par des pages produits, des recommandations ou une liste de fonctionnalités souhaitées. Cette perspective est trop tardive. Avant de comparer les fonctionnalités, il faut clarifier quelle tâche doit être améliorée dans le processus existant.
Un CRM peut posséder de nombreuses fonctions et pourtant s'avérer inadapté si les phases de vente, la responsabilité des données et les processus de mise à jour ne sont pas clairs. Un système de newsletter peut être performant et générer malgré tout des efforts supplémentaires si les contenus, les consentements et les contacts sont gérés séparément dans plusieurs systèmes. Un outil de projet peut promettre de la transparence tout en devenant un îlot supplémentaire.
L'exigence ne naît donc pas du produit. Elle naît du problème, du groupe d'utilisateurs et du processus.
Un outil modifie le déroulement
Les nouveaux logiciels sont souvent considérés comme un soutien neutre. En réalité, ils apportent leurs propres modèles de données, rôles, logiques d'utilisation et processus standard. Cela peut être judicieux si cette logique correspond à l'entreprise. Cela peut devenir problématique si un processus historiquement développé est repris uniquement parce que l'outil le dicte.
La sélection doit donc examiner les deux directions :
- L'outil correspond-il au processus nécessaire ?
- Le processus existant a-t-il réellement un sens ou devrait-il être simplifié avant la numérisation ?
Sans cet examen, on numérise soit un mauvais processus, soit l'entreprise se plie inutilement aux exigences du logiciel.
Le prix d'achat ne représente qu'une partie des coûts
Les coûts totaux ne proviennent pas seulement des licences. S'y ajoutent l'installation, la migration des données, les interfaces, la formation, la maintenance interne, la gestion des droits, le support, la documentation et un éventuel changement.
Un outil apparemment bon marché peut devenir coûteux si les données sont difficiles à exporter, si des fonctions clés nécessitent des produits supplémentaires ou si des adaptations individuelles nécessitent une aide externe permanente. Inversement, une licence plus élevée peut être judicieuse si elle remplace plusieurs solutions individuelles contrôlées et simplifie l'exploitation.
Chaque ajout crée des dépendances
Les directives technologiques officielles soulignent depuis des années les normes ouvertes, la portabilité, l'interopérabilité et la possibilité de modifier les décisions ultérieurement. Ces critères ne sont pas de simples détails techniques. Ils déterminent si une entreprise maîtrise toujours ses données, ses processus et le changement de fournisseur.
Une dépendance n'est pas fondamentalement mauvaise. Chaque système crée des dépendances. L'essentiel est de savoir si elles sont connues, justifiables et gérables contractuellement et techniquement.
Positionnement stratégique
Le manuel des services de GOV.UK formule un principe clair pour les décisions technologiques : la sélection doit permettre de changer de direction ultérieurement, d'adapter la technologie aux nouvelles connaissances et de maîtriser efficacement les risques de sécurité. Le Code de pratique technologique complète les normes ouvertes, la réutilisation et l'évitement des dépendances inutiles vis-à-vis de fournisseurs individuels.
Ces directives proviennent du secteur public, mais les critères de décision sont transférables aux entreprises. La technologie n'est pas choisie uniquement pour sa fonction actuelle. Elle est choisie pour un cycle de vie au cours duquel les exigences, les responsables et les systèmes adjacents évoluent.
La solution minimale viable
Un principe de sélection judicieux est le suivant : ne choisissez pas la solution maximale possible, mais la plus petite solution viable.
« Petit » ne désigne pas ici le moindre ensemble de fonctions. Il s'agit d'une solution qui :
- la tâche essentielle est entièrement remplie
- s'intègre dans les processus et les flux de données existants
- peut être maîtrisé par les personnes responsables
- dispose des interfaces nécessaires
- satisfait aux exigences appropriées en matière de sécurité et de protection des données
- permet un fonctionnement réaliste
- un changement ultérieur n'est pas bloqué inutilement
Les fonctions supplémentaires ne sont un avantage que si leur utilisation et leur responsabilité peuvent être anticipées.
Peser la standardisation et la spécialisation
Les entreprises se trouvent souvent entre une plateforme large et plusieurs outils spécialisés. Il n'y a pas de réponse universelle.
Les plateformes larges peuvent regrouper les données et les accès. Mais elles peuvent être trop volumineuses, coûteuses ou inflexibles. Les outils spécialisés peuvent mieux résoudre des tâches individuelles. Mais ils augmentent les interfaces, la coordination et les frais de gestion.
La décision doit être guidée par l'importance stratégique de la tâche. Un processus central différenciateur peut justifier une solution spécialisée. Pour les tâches standard interchangeables, la consolidation est souvent plus judicieuse.
Perspective pratique
Un processus de sélection fiable ne commence pas par une démo. Il commence par un bref profil des exigences. En pratique, sept champs suffisent souvent pour cela :
- Quel problème doit être résolu ?
- Qui utilise l'outil et qui en est responsable ?
- Quelles données sont nécessaires, générées et transmises ?
- Dans quels systèmes existants doit-il s'intégrer ?
- Quelles exigences sont indispensables, lesquelles sont seulement souhaitables ?
- À quoi ressemblent l'exploitation, la maintenance et le support ?
- Comment les données et les processus peuvent-ils être transférés ou arrêtés ultérieurement ?
Ces questions modifient également la démo produit. Au lieu de se faire présenter l'ensemble des fonctionnalités, un processus concret est examiné. Les fournisseurs doivent expliquer comment les données sont exportées, comment les droits fonctionnent, quelles interfaces existent et quelles tâches restent en dehors du produit.
Un deuxième principe pratique est le suivant : l'outil doit avoir un rôle responsable avant l'achat. Si personne ne prend en charge l'exploitation, la qualité des données et le développement, l'introduction n'est pas encore prête à être décidée.
Arbre de décision pour les outils numériques
Cadre d'action
1. Décrire le problème et le changement souhaité
Formulez l'état actuel, l'état souhaité et les rôles concernés. Évitez les exigences telles que "Nous avons besoin d'un CRM moderne". Décrivez plutôt quelle décision ou quel déroulement doit être amélioré.
2. Séparer les exigences obligatoires et facultatives
Limitez les exigences indispensables à ce qui est réellement nécessaire. Les listes de souhaits étendues favorisent automatiquement les produits complexes. Chaque fonction facultative devrait avoir une utilisation et une responsabilité identifiables.
3. Vérifier les données et les interfaces
Clarifiez la propriété, l'exportation, l'importation, les formats de données, les droits, les possibilités de suppression et les connexions nécessaires. Vérifiez également quelles transmissions manuelles subsisteront malgré l'intégration.
4. Planifier l'exploitation avant l'introduction
Déterminez la responsabilité du système, la gestion des utilisateurs, la documentation, la formation, le support et la fréquence des audits. Un outil sans modèle d'exploitation devient rapidement une île liée à une personne.
5. Penser au changement et à la fin
Avant de conclure un contrat, demandez comment les données peuvent être exportées intégralement, comment les intégrations peuvent être résolues et comment les processus peuvent être transférés. Une perspective de sortie n'affaiblit pas la décision. Elle la rend plus solide.
Ce que les entreprises ne doivent pas faire
Les entreprises ne devraient pas tester plusieurs outils en parallèle sans avoir préalablement défini des critères communs. Sinon, c'est souvent la présentation la plus convaincante qui l'emporte, plutôt que la solution la plus adaptée.
La sélection basée sur le plus grand ensemble de fonctions possible est tout aussi problématique. Les fonctions inutilisées augmentent la complexité et peuvent fausser les décisions. L'outil devient alors un cadre dans lequel les processus sont adaptés ultérieurement.
Conséquence pour les entreprises
Le choix des outils est une décision d'architecture et de responsabilité. Il influence la manière dont les informations circulent, la flexibilité des processus et l'effort de contrôle futur.
Le choix croissant exige donc moins de connaissances sur les produits, mais de meilleurs critères. Les entreprises doivent mieux comprendre leur problème, leur processus et leurs dépendances. Ce n'est qu'alors que la technologie devient le moyen approprié au lieu du point de départ de la stratégie.
L'intégration stratégique des mesures approfondit « Plus de mesures numériques ne créent pas encore de stratégie numérique ». Comment les systèmes sélectionnés s'intègrent dans une feuille de route est montré « Ce qu'une feuille de route numérique fiable doit accomplir ». La consolidation ultérieure des paysages développés est traitée « Moins d'outils, des systèmes plus clairs, de meilleures décisions ».
La vue d'ensemble est fournie par Domaines thématiques Stratégie numérique.
Connexion technique
Vérifier les décisions relatives aux systèmes et aux outils avant de s'engager
Le conseil en stratégie et systèmes numériques associe exigences métier, processus, données, intégrations, exploitation et possibilités de migration. Il aide à fonder un choix non pas sur la promesse du produit, mais sur la finalité de l'entreprise et sur une architecture globale maîtrisable.
Évaluer de manière structurée la décision du système numérique
Sources et bases techniques (5)
- GOV.UK Service Manual, "Choosing technology: an introduction". Ouvrir la source
- GOV.UK Service Standard, „Choose the right tools and technology“. Ouvrir la source
- GOV.UK, „The Technology Code of Practice“, 2021. Ouvrir la source
- GOV.UK Service Manual, „Working with open standards“. Ouvrir la source
- NIST, « Cloud Computing Standards Roadmap ». Ouvrir la source
