Le schéma directeur : y-a-t-il un sujet de conseil IT plus classique et plus éculé que celui-ci ? Et pourtant, y'a-t-il un sujet qui semble plus vaporeux et dont la valeur est plus difficile à expliciter ?
Quand on parle de schéma directeur, on parle de ces études à rallonge (6 à 9 mois) consistant définir une cible stratégique à 3-5 ans, faire un deep dive au sein des grands projets existants, analyser l’écart fonctionnel et technique et définir une trajectoire pour parvenir à la cible.
Quoi de plus logique, rationnel, évident me direz-vous ? Et pourtant, c’est la prestation qui génère le plus de frustration chez les consultants (ou tout au moins, ceux qui aiment voir du concret sortir de leurs efforts).
Ce qui pèche dans le schéma directeur IT, c’est que sa finalité n’est pas IT. D’une manière générale, c’est un document qui sert plus à des négociations financières entre la DAF et la DSI, pour définir les budgets à 5 ans de cette dernière.
Gare à la DSI si elle s’est trompée de 10% sur son budget à 5 ans. Autant rectifier la trajectoire d’un paquebot lancé à vitesse de croisière au dernier moment, alors qu’il va heurter un iceberg.
S’agissant d’un document cadre, à visée politique et de gouvernance financière, le schéma directeur a souvent une durée de vie utile limitée : environ 6 mois, voire un peu plus, c’est-à-dire le temps de son élaboration et de sa communication. Il meurt peu après, tel le papillon sorti de son cocon ne vit que quelques jours après son éclosion (oui c’est poétique).
Difficile de dire aujourd’hui quel est le ratio entre les schémas directeurs utilisés comme de véritables outils de gouvernance de la trajectoire IT et ceux qui viennent caler une bibliothèque.
D’où la frustration des consultants IT qui, après l’avoir élaboré souhaiteraient avoir la satisfaction d’en voir constater les résultats concrets.
En effet, le schéma directeur est souvent hors sol car on ne classe pas les priorités selon la valeur, mais selon d’autres critères : urgence projet, obsolescence technique, visibilité politique, … Qui plus est, on fait rarement le bilan du schéma directeur pour voir ce qui a été réalisé : qui peut alors en évaluer la pertinence initiale ?
De ce fait, les projets sont souvent en échec en l’absence de prise en compte de contraintes techniques (notamment interfaçages projets)
Le schéma directeur élaboré, il est figé. Venez toucher une ligne et c’est l’ensemble qui s’effondre, tel un château de cartes. Le schéma directeur n’est pas évolutif, pas suffisamment agile.
Dans un monde où chaque événement géopolitique, politique, économique… peut avoir des répercussions profondes sur l’orientation du SI, le schéma directeur apparaît comme Gulliver se mouvant difficilement au milieu des lilliputiens.
Prenons une image bien concrète : qui aurait pu prévoir la crise de la CoViD-19 ? Qui l’avait inscrit dans sa trajectoire à 5 ans ? Et pourtant, combien de répercussions sur l’infrastructure : à l’issue, il faudra dénombrer les organisations qui mettront en place un plan de renforcement de leur infrastructure, pour faciliter le télétravail et qui digitaliseront leurs processus internes pour les rendre plus résilients et moins dépendants d’une présence physique.
Mais sur quels critères ces décisions seront-elles prises ? Ne seront-elles pas précipitées ? Les choix seront-ils toujours les bons ? La décision sera-t-elle toujours pertinente ? Et ceux qui voudront placer cette décision dans le processus classique du schéma directeur, seront-ils prêts pour la prochaine crise qui - forcément - sera différente ?
Constats faits, que devrait être un schéma directeur, si ce n’est un outil permettant de piloter la valeur et un levier pour atteindre les objectifs stratégiques de l’organisation ?
Or la stratégie d’une organisation étant de plus en plus soumise à des aléas et ses processus étant de plus en plus imprégnés de digital, toute évolution (même mineure) de la stratégie fera évoluer le schéma directeur.
Le problème du schéma directeur n’est pas tant le schéma directeur lui-même, que la définition de valeur qu’on veut lui faire produire. Quel est l’outcome du schéma directeur IT ? S’agit-il de définir un macro-plan budgétaire ou de servir de plan de gouvernance de transformation (de révolution ?) du système d’information, en continu “hasta la victoria” ?
L’aspect structurel, rassurant du schéma directeur IT actuel, n’est pas compatible avec une finalité concrète de livraison de valeur immédiate. La DSI doit se transformer en révolutionnaire en co-construisant stratégie d’entreprise et stratégie IT et cela pour deux raisons :
Cette stratégie n’a pas de cible, si ce n’est ce que veut devenir l’organisation. Le système d’information est, avec l’humain, le levier et l’outil qui lui permettront de devenir ce qu’elle prétend être. Iron Man ne serait pas Iron Man, sans son armure, il ne serait jamais que Tony Stark...
Quel serait le visage d’un schéma directeur IT qui se voudrait :
En sommes, il faut adopter une démarche de “design” pour produire un schéma directeur conforme à ces attentes.
Une organisation humaine, s’adresse à des humains, c’est-à-dire qu’elle délivre de la valeur à des humains. Quelle que soit cette valeur. Ces personnes lui sont soit externes (ses clients, ses fournisseurs, ses partenaires), soit internes (ses collaborateurs).
Construire une stratégie c’est définir la valeur que l’on souhaite apporter à chacune de ces personnes et trouver les chemins pour y parvenir.
Une stratégie devrait donc adopter une démarche “UX” : une organisation doit comprendre quelles sont ces personnes et quelles relations elle entretient avec elles. A quoi aspirent-elles quand elles entrent en relation avec l’organisation ? Quelles sont les douleurs de cette relation ? Comment l’organisation peut-elle apporter une réponse à ces personnes, en respectant sa raison d’être (actuelle ou projetée) ?
Adopter une démarche UX pour définir sa stratégie, c’est s’assurer de ne pas faire fausse route. C’est en cartographiant les persona qui entrent en relation avec l’organisation et en définissant les cas d’usage de celle-ci, que l’on pourra définir une cible : il n’y a pas de meilleure manière de savoir où mes clients m’attendent (à plus ou moins court terme) que de leur demander directement.
Il ne s’agit pas d’avoir une vision exhaustive et détaillée de l’ensemble des personas interagissant avec l’organisation, mais de bien comprendre l’écosystème humain dans lequel elle évolue, quelles sont les attentes des uns et des autres et à auxquelles elle souhaite pouvoir répondre à l’avenir.
C’est en décrivant ces attentes que l’on peut déterminer ce à quoi l’organisation est en mesure ou non de répondre (notamment à travers son système d’information), selon quelle temporalité et quel niveau de complexité.
Les attentes des personas se traduisent au sein de cas d’usage (ou de typologie de cas d’usage), qui feront l’objet d’initiatives concrètes qui devront être priorisées pour être intégrées au sein du système d’information.
En décrivant ce qu’elle, ce qu’elle souhaite être, ce qu’elle peut être aujourd’hui et ce qu’elle devra faire pour devenir ce qu’elle souhaite demain, l’organisation peut déterminer une trajectoire concrète et évolutive, en prise avec la réalité quotidienne de ses clients.
L’heure n’est plus à la disruption rêvée, mais à l’évolution progressive, en prise avec le réel.
Il faut considérer le schéma directeur comme un produit (complexe) à part entière. Il ne pourra pas évoluer d’un bloc. Il faut prioriser ces évolutions en fonction de leur impact sur l’atteinte de la vision de l’entreprise à un moment donné.
Toutes ces évolutions viennent alimenter un backlog propre. Il ne s’agit pas de créer un backlog autre, à côté des backlogs produits, mais d’avoir une vision claire de ce que l’on veut faire, de l’effort et de l’impact de chaque évolution.
Les évolutions font l’objet d’une évaluation, une rétrospective qui permet de dire si les évolutions qui ont été apportées au SI ont contribué de manière concrète - ou pas - à la vision de l’entreprise.
Le schéma directeur n’est donc plus un document statique, mais l’association d’une vision d’entreprise à backlog d’initiatives participant directement à l’atteinte d’une vision d’entreprise.
Ce backlog fait l’objet d’un suivi, d’une rétrospective très régulièrement pour faire un bilan des initiatives entreprises et re-prioriser les actions en fonction :
L’objectif est de s’assurer que le schéma directeur acquiert bien sa dimension opérationnelle, c’est-à-dire que ses effets sont visibles.
Par ailleurs, le backlog fait l’objet d’une re-priorisation récurrente, afin de s’assurer que les initiatives qui sont prises sont bien en phase avec les orientations stratégiques de l’organisation.
La définition et re-priorisation du backlog pourra s’appuyer sur des méthodologies comme la gestion du flux (‘Flow’) qui permet de donner rapidement de nouvelles priorités, en recherchant toujours le maximum de valeur.
Cela nécessite notamment de raccourcir les cycles de décision et de donner la juste responsabilité aux équipes (afin que chacune puisse résoudre elle-même les problèmes qui sont de sont niveau). Cette attitude permet de rapidement se réorienter en prenant en compte des facteurs extérieurs, tout en sécurisant la valeur.
Il s’agit principalement de bien comprendre la nécessité de s’assurer du caractère opérant de schéma directeur et de sa capacité à évoluer facilement en fonction de l’évolution des orientations stratégiques d’une organisation.
Plusieurs outils existent pour piloter le backlog dans le temps. Il s’agit de mesurer de manière objective un certain nombre d’indicateurs qui sont clé pour une organisation donnée (ex : vitesse de delivery, satisfaction des utilisateurs, régularité des mise à disposition de nouveaux services, …). Le framework XLR8 propose une grille de pilotage pour
Pour faciliter cette évolutivité, le système d’information doit basculer pour faciliter l’intégration de nouveaux services à destination des personas identifiés.
Le système d’information a longtemps été construit sur un schéma très séquentiel, prenant en compte deux visions interdépendantes :
Cela se traduit de manière particulièrement claire au sein des ERP, mais également au sein des systèmes métier. Il reflète finalement une vision très “chaîne de montage” (conformément à la loi de Conway, le rendant peut évolutif : c’est la donnée qui transite d’une fonction à une autre pour être transformée).
Les organisations tentent en général de représenter leur système d’information à travers une vaste cartographie fonctionnelle (ou “POS” selon les termes de l’urbanisation des systèmes), laquelle est en général complexe et difficile à maintenir. Surtout, la représentation des données au sein du système d’information y est inexistante.
Par ailleurs, cela suppose une représentation des données permettant à plusieurs systèmes de travailler avec les mêmes données : c’est l’interopérabilité. Malgré la capacité d’échanger des données, cela rend les systèmes très dépendants les uns des autres et donc peu évolutifs (ou à fort coûts), car un même objet de donnée sera traité par plusieurs systèmes au cours de son cycle de vie.
La difficulté se perçoit aujourd’hui dans la difficulté à construire des datalake opérationnels, car les données (pourtant connexes) proviennent de systèmes différents, ayant des représentations sémantiques et logiques différentes.
La bascule vers un système d’information plutôt orienté “donnée”, suppose de reconstruire conceptuellement le système autour des objets de données et de déterminer les responsabilités sur ces données, en distinguant les services et fonctionnalités qui les opèrent.
On adopte ici un design tiré par le domaine de données (“domain driven”), à l’échelle du système d’information.
Ce modèle permet par ailleurs, au niveau du système d’information, de dissocier ce qui évolue moins vite (le modèle) de ce qui évolue avec une plus grande célérité (les fonctionnalités et les services), selon les principes de la clean architecture.
Appliqué à l’ensemble du système d’information cela le rend beaucoup plus évolutif avec une bien plus grande sécurité sur les données et leur modèle.
Pour être efficace, le schéma directeur ne devrait pas prendre plus de 2 mois à définir et être évolutif.
La première étape consiste d'abord à s'interroger sur un “Why” : Que voulons nous être ? Pour qui ? Définir cette vision de l’organisation et de son système d’information est essentiel pour en assurer la réussite. Elle me permet de déterminer en continu quels seront les personas et initiatives prioritaires sur le système d’information.
Cette vision doit être re-challengée tous les ans, ou lorsqu’un événement inattendu survient remettant en cause les priorités.
La deuxième étape consiste à en faire découler les personas clés de l'organisation (qu’ils soient internes ou externes), de les prioriser et de les décrire. Il ne s’agit pas de décrire l’ensemble, mais d’identifier ceux qui correspondent à un objectif stratégique.
Cela permet de comprendre les objectifs attendus de l’organisation par un ou des personas (par exemple : pour le persona X, je veux être l’entreprise qui livre des produits frais, en achat direct, le plus rapidement possible, e.g. en moins de 24h).
La troisième étape consiste à décrire les interactions d’un persona sur le système d’information et les impacts sur les autres personas, en identifiant le domaine de données clés concerné par l’initiative et le cycle de vie de l’objet métier pour apporter le service attente (par exemple : pour permettre la livraison d’un produit en 2 jours, quels événements ont eu lieu en amont pour que cela soit possible ?).
Cette définition pourra s’appuyer sur une démarche d’atelier d’event storming en faisant intervenir les acteurs pertinents pour bien décrire le circuit dans son ensemble.
La quatrième étape consiste à identifier les actions à mener sur les systèmes d’information existants et les nouveaux systèmes à construire pour mettre en œuvre les initiatives à destination des personas. Ces initiatives seront ensuite suivies dans leur phase de delivery, mais également lorsqu’elles seront déployées : la finalité est de s’assurer que l’initiative en question contribue bien aux objectifs stratégiques visés.
Par ailleurs, lors de la définition des initiatives, il faudra prendre en compte des chantiers à l’impact transverse (comme les sujets d’infrastructures et d’hébergement) et s’appuyer sur ces initiatives métier pour les traiter.
La cinquième étape consiste dans la mise en œuvre des initiatives et dans le pilotage de leur mise en œuvre au sein des systèmes. Il s’agit d’évaluer la bonne application d’initiatives ayant un impact concret à court ou moyen terme, afin de pouvoir l’évaluer et réévaluer la priorité des actions.
Le schéma directeur (ou ‘schema designer’) fait l’objet d’une rétrospective régulière et récurrente pour s’assurer de sa pertinence toujours constante (par exemple : tous les ans), afin de stopper des initiatives ou d’en lancer de nouvelles lorsque cela apporte de la valeur à l’organisation et à ses objectifs.
Le schéma directeur n’a pas été conçu et n’est pas utilisé pour piloter la transformation du système d’information mais pour décider un budget. Il est en général long à décrire et finit en général au sein d’une étagère.
Nous pensons que le schéma directeur peut et doit avoir un caractère opérationnel et évolutif. Pour y parvenir il faut changer la finalité du schéma directeur pour le rendre plus proche des initiatives à destination d'utilisateurs concrets du système.
Cela nécessite de prendre une démarche de “design”, visant à bien définir la vision, en incorporant l’ensemble des parties prenantes (des métiers au technique), pour la détailler en des initiatives concrètes, répondant à des objectifs stratégiques clairs, impactant des personnes avec leurs douleurs.
Le schéma directeur devient ainsi un outil actionnable et pilotable, pour faire apparaître une valeur qualifiable et mesurable.