IT Strat #2 - Définir une stratégie IT qui répond aux enjeux de l'Entreprise

Nous avons vu dans notre premier article d’introduction sur la stratégie IT l’importance d’une approche modernisée pour répondre aux différents enjeux métier, technologiques, SI, opérationnels, sociétaux aussi bien qu’environnementaux, dans un contexte de plus en plus mouvant.

Nous allons maintenant voir ensemble quelles sont les étapes et outils d’une stratégie IT, informée, actionnable et qui permet d’aligner au plus proche les exigences et besoins des stakeholders.
En commençant dans cet épisode par regarder de plus près les méthodes et outils que nous utilisons chez OCTO Technology pour intégrer à la fois les enjeux métier et technologiques, ou dit autrement comment participer à la stratégie métier en y apportant les bonnes réponses technologiques.

Nous pourrons ensuite aborder dans les prochains volets comment maîtriser l’évolution du SI, poser une feuille de route et la piloter, redéfinir le rôle des architectes et revoir le modèle opérationnel de l’IT dans cette approche modernisée.

Cette série d’articles s’adresse à tous les responsables IT au sens large et à ceux et celles qui les aident à anticiper et prévoir les évolutions à mener sur leur périmètre : DSI, CTO, architectes, responsables de domaine…
A noter aussi que dans cette série d’articles nous utiliserons souvent le
mot entreprise qui est à prendre dans sa définition la plus large, au sens unité organisationnelle qui peut être privée ou publique (organisation institutionnelle).

Partenariat Business & IT

La définition et l'exécution d’une stratégie IT moderne, que ce soit pour le système technique ou le système social, n’est pas le fruit d’une improvisation, elle repose sur un processus méthodologique qui vise un alignement des capacités de l’entreprise (métiers ou techniques) avec les contraintes légales et les ambitions/objectifs business à l’échelle de l’entreprise, tout en prenant en compte les opportunités technologiques.

Même si nous ne l’abordons pas dans cet article, rappelons qu’un alignement temporel est également nécessaire, l’exécution de la stratégie IT s’inscrivant dans une trajectoire de réalisation avec des jalons de livraison techniques qui peuvent coïncider aussi bien avec des attentes de clients finaux, de régulateurs extérieurs ou de partenaires commerciaux.

A la recherche de l’alignement des différentes perspectives de l’entreprise

La transformation continue de l’entreprise est animée par de nombreux acteurs qui ont chacun leurs méthodes et outils, ce qui se traduit souvent par différents points de vue qui ne sont pas toujours cohérents entre eux. Le schéma ci-dessous est inspiré par les travaux Open Agile Architecture de l’Open Group (1) et montre les différentes perspectives d’une entreprise (en gris) : Expérience utilisateurs, Opérations métier, Produit et Systèmes techniques. Dans chaque perspective, des vues ou méthodes (en bleu) peuvent être pratiquées pour comprendre l’existant et définir les évolutions de l’entreprise.

Les différentes perspectives de l’entreprise et la recherche d’alignement

Les différentes perspectives de l’entreprise (en gris), les différentes vues ou méthodes (en bleu) et la recherche d’alignement nécessaire

Malheureusement les perspectives Expérience utilisateurs, Opérations métier et Produit sont trop souvent pensées de manière décorrélée de l’IT (les systèmes techniques). Qui n’a jamais été confronté à une entité métier ayant déjà choisi son prochain progiciel, motivé par la force de conviction de certains commerciaux, sans prendre en compte les contraintes et orientations technologiques de l’entreprise? Cela entraîne des difficultés dans la définition d’une vision cible puis dans la manière de mener les projets et dans leurs résultats, avec des insatisfactions de toutes les parties prenantes.
Au-delà d’embrasser son cœur métier, une stratégie IT efficiente doit reposer sur une vision globale du fonctionnement de l’entreprise et apporter une cohérence d’ensemble. Pour cela, l’IT ne doit pas être uniquement positionnée en aval, mais idéalement être impliquée et participer en amont pour apporter du lien entre les différentes perspectives de l’entreprise, cela de manière continue, et décliner les ambitions métier dans la transformation digitale et la stratégie IT :

  • Stratégie d’entreprise : une implication des équipes IT à cette vision globale est nécessaire pour bien comprendre les besoins, les enjeux et définir ensemble les ambitions et critères de succès. Cette contribution peut se faire, par exemple, à travers des canevas et des ateliers participatifs. Ces ateliers vont faciliter l’identification des capacités nécessaires pour l’entreprise et sont aussi souvent l’occasion d’apporter d’autres perspectives d’avenir au métier en proposant des opportunités technologiques (boucle de feedback).
  • Expérience utilisateur (“User experience”) : une meilleure prise en compte des besoins réels des utilisateurs (et non les besoins estimés par les responsables du pilotage) est un facteur clé de la réussite d’une transformation (digitale et/ou IT). Il faut donc exploiter des outils de type “Experience design” ou “Journey map” qui formalisent le point de vue utilisateurs et aident à mieux cerner les nouvelles capacités digitales devant être développées et aller au-delà de la vision historique des opérations métier.
  • Opérations métier (“Business operations”) : le fonctionnement de l’entreprise (vente en ligne, services bancaires, fabrication de biens et produits, service public…). La seule expérience utilisateur ne suffit pas à traiter l’entreprise dans sa globalité. La modélisation des activités et des flux de valeur de l’entreprise (value stream mapping) permet de définir les capacités IT nécessaires (nous y reviendrons dans le chapitre suivant)
  • Produit et Systèmes techniques : la richesse, et donc la complexité croissante des produits et systèmes techniques constituant les systèmes d’information, implique une approche plus ciblée des actions à entreprendre. Un découpage ciselé du système d’information est une étape fondamentale pour réaliser une transformation digitale, et plus largement mettre en œuvre une stratégie IT. Pour réaliser ce découpage, l’utilisation d’outils comme le DDD (Domain Driven Design) n’est pas obligatoire mais elle est souvent pratiquée par nos consultants OCTO pour co-construire la cible avec le métier et donner de la cohérence entre les visions métier / produit et technique.
    Le DDD est un ensemble de pratiques visant à définir des systèmes techniques et qui participent à la conception du produit. Souvent utilisés dans la conception de nouvelles applications, les travaux de DDD peuvent aussi être positionnés en amont de manière stratégique pour prendre en compte la vision métier et les flux de valeur (value streams). Le tout de manière itérative comme illustré dans le schéma plus haut.

Vision métier à travers les flux de valeur

La stratégie IT doit participer à la construction d’une vision métier formalisée, tout en respectant le dynamisme du métier. Cette représentation du métier de l’entreprise sous différentes formes, comprise par tous et évolutive, servira de base à l__’analyse des écarts__ et à la transformation nécessaire. En effet, il n’est envisageable de mettre en application une stratégie, quelle qu'elle soit, sans disposer d’une cartographie et autres descriptions du cœur métier couvert (par exemple sous la forme de capacités).
Nous ferons un focus dans cet article sur la modélisation des Value streams, ou flux de valeur, qui sont la déclinaison de la chaîne de valeur de l’entreprise en séquences d’activités (produits et services). Cette technique appelée Value stream mapping (2) aide le métier à mieux visualiser les macro-processus, les étapes qui les composent et l’enchaînement des capacités nécessaires pour réaliser ces séquences d’activités.

Value stream map

Exemple (simplifié) d’une value stream map avec les différentes étapes et les capacités associées

Les value streams apportent un côté concret, ciblé et dynamique à la cartographie métier, et servent en général de base au découpage en domaines et produits. Les value streams donnent du sens aux fonctions et solutions IT qui vont contribuer à réaliser ces activités, mais sans rentrer dans les détails des processus opérationnels.

Cartographie des capacités de l’entreprise

Les capacités identifiées dans le Value stream mapping sont en général regroupées dans des “Capability maps”. Dans les contextes métiers les plus stables (par exemple dans le monde bancaire ou le secteur public), elles ont pris, historiquement, la forme de POS (Plan d’Occupation des Sols), mais le dynamisme de la transformation digitale, et son impact sur les activités métiers, invite à introduire plus de souplesse dans la formalisation des capacités de l’entreprise. Ainsi, les “capability maps”, sans figer le métier couvert, donnent une vision d’ensemble sur laquelle nous pouvons pointer les écarts à la cible et travailler sur les principaux investissements requis :

  • les “Business capabilities”, ce sont les capacités métiers de l’entreprise nécessaires à son business model, on représentera à minima celles supportées par l’IT. C’est quelque part le pourquoi de l’IT, qui doit être revue fréquemment pour coller aux évolutions et ambitions de l’entreprise.
    La “Business Capability map” donne une vision commune sur laquelle s’appuiera la discussion autour des enjeux, priorités et des capacités IT à mettre en œuvre sur les axes Technologiques, Process et People. Cette cartographie est en général structurée par domaines métier. Dans l’exemple ci-dessous on peut y voir un domaine métier standard assez large (“Ventes”), mais il peut être intéressant de découper plus finement cette carte en sous-domaines en phase avec les “Value streams” de l’entreprise.

  • les “Technical capabilities”, ce sont les capacités techniques qui vont permettre de répondre aux besoins métier (directement pour un besoin précis ou de manière transverse, à l’image des Enablers). On est plus ici dans la représentation du comment de l’IT.
    Les technical capabilities peuvent être de plusieurs sortes :
    - Accélérateurs : Éléments d’infrastructure, modèles d’architecture…
    - Facilitateurs : Framework, Plateforme Low Code, Business Process Management (BPM)...
    - Communs : Gestionnaire d'identité, Gestion électronique de documents, Référentiel métier…
    L'identification puis la gestion de ces assets technologiques est un enjeu majeur chez la plupart de nos clients, notamment sur les communs. Construire cette vue constitue un point d’entrée intéressant de la stratégie technologique, on pourra ensuite y mapper les solutions techniques actuelles ou nécessaires et s’en servir de base pour construire un catalogue de services en lien avec l’organisation et rationaliser les solutions technologiques. La rationalisation des solutions technologiques est un des principaux leviers pour répondre aux objectifs d’optimisation financière, plus encore dans un contexte de transformation numérique, propice à l’adoption effervescente de solutions en tout genre.

Business et Technical capabilities

Illustration de business et technical capabilities (enablers) avec dans cet exemple la mise en relief d’enjeux à adresser dans la stratégie IT (en jaune)

Analyse d’écarts et scénarios métier

Ces méthodes de représentation ne sont pas une fin en soi, mais un moyen de renforcer le partenariat Business & IT qui est le titre de ce chapitre et auquel nous sommes particulièrement attachés chez OCTO Technology. Construire cette vision partagée permet ensuite de mieux analyser les écarts par rapport aux ambitions de l’organisation, aux exigences réglementaires auxquelles elle est soumise, ou encore à l’état de l’art du marché.
L’analyse d’écart permet ensuite de travailler ensemble avec les responsables métier sur les différents scénarios possibles pour l’évolution de l’entreprise et sur les impacts IT associés. Ces scénarios métier vont influencer la stratégie IT qui va devoir identifier :

  • Les potentielles transformations à mener induites par le digital dans les value streams pour y répondre : activités et capacités à créer pour apporter de la valeur, ou à améliorer pour optimiser l'efficience de l’entreprise ou la rendre plus éco-responsable par exemple,
  • Les impacts IT qui en résultent : systèmes à rénover, enablers / communs à mettre en œuvre, nouvelles technologies à appréhender, changements de modèle opérationnel…

Co-construction de la cible avec les équipes

L’approche capacitaire et value streams décrite plus haut permet d’avoir une vision macro partagée avec les responsables métier, mais elle peut parfois être ressentie comme étant trop “top-down” quand elle est pratiquée en comité restreint. On veillera donc à inclure un maximum de participants métier et IT pertinents dans la réflexion, et les faire converger vers une vision intentionnelle servant de cadre et de base de travail à la solution émergente qui vient des équipes (cf le principe de boucle de feedback expliqué dans notre premier article).

Des outils plus participatifs issus de l’approche DDD (Domain-Driven Design) sont intéressants pour réaliser cette convergence en introduisant une approche bottom-up qui va permettre d’aller plus dans le détail de la chaîne de valeur métier, d’affiner les impacts IT, et de faire émerger de nouvelles idées pour le futur : on citera en particulier l’Event Storming qui peut être utilisé au niveau stratégique pour mieux comprendre le métier et ses besoins, découper les domaines métier à gérer dans le SI (Big Picture), leur donner une substance fonctionnelle concrète en utilisant, dès les premières réflexions, le même langage entre métier et IT. Nous reviendrons plus en détails dans un prochain article sur cette approche DDD stratégique.
L’Event Storming joue aussi un rôle charnière avec l’IT en permettant, grâce à une formalisation partagée de l’espace du problème (ou plutôt du besoin) avec le métier, de se projeter sur l’espace de la solution (qui est par nature le domaine d’expertise de l’IT), en commençant à détourer des sous-domaines plus précis (appelés Bounded Contexts) pour répondre aux problématiques soulevées. Ce travail, qui peut être fait de manière globale ou sur des parties ciblées de l’entreprise, est à faire le plus possible en continu pour alimenter la stratégie technologique qui s’intéresse aux solutions.

Mise en oeuvre d’une stratégie technologique

Priorisation des investissements

D’autres outils DDD comme la Wardley Map ou le Core domain chart vont eux aider à prioriser les investissements et à définir une stratégie technologique en lien avec le métier.

Pour mémoire, la Wardley Map était un des sujets de la Duck Conf 2024 (3) et le Core domain chart a été abordé en 2022 (4) mais plus dans un objectif de priorisation des ressources humaines.
Nous allons faire un focus ici sur le Core domain chart utilisé comme un outil d’aide à la décision qui permet d’éclairer la question Make or Buy en évaluant les domaines / sous-domaines sur deux axes : leur spécificité (“business différenciation”), mais aussi leur complexité qu’elle soit métier ou potentiellement solution (“model complexity”). Ce qui permet d’arriver à une classification sur 3 niveaux :

  • les domaines différenciants (les “core domains”). Ce sont les domaines au cœur de la stratégie de l’entreprise ou de l’organisation, ceux où il est pertinent d’investir sur des solutions “sur-mesure” (Make) là où le spécifique est nécessaire pour apporter un avantage compétitif, ou simplement pour répondre aux besoins des clients ou des entités internes.
  • les domaines intermédiaires (“supporting”) : un domaine peut être important pour l’entreprise, mais adressable par une solution sur étagère ou développée en interne mais avec un investissement limité (le choix Make or Buy est à traiter au cas par cas).
  • les autres domaines dits “génériques” peuvent en général être adressés par des solutions sur étagère car communes à toutes les entreprises du secteur (Buy).

Core domain chart

Core domain chart avec ses axes d’évaluation et des 3 niveaux de classification (cf https://github.com/ddd-crew/core-domain-charts)

La classification des domaines est aussi intéressante dans une vision dynamique pour montrer l’évolution souhaitée. Celle-ci peut être matérialisée par des flèches dans le Core Domain Chart pour montrer la stratégie par sous-domaines.
Un domaine “supporting” peut devenir différenciant par ambition stratégique (il serait ainsi enrichi d’une flèche vers la droite), ou à l’inverse ne plus être considéré comme différenciant et ne plus justifier des développements custom importants (dans ce la flèche serait vers le bas pour inviter à réduire sa complexité).

Discernement dans les choix technologiques

Ces grandes directions Make or Buy vont devoir prendre en compte le contexte de l’entreprise (les contraintes réglementaires, les accords cadres passés avec des fournisseurs, les compétences à disposition …), et s’appuyer sur une stratégie technologique, c'est-à-dire comment utiliser au mieux les possibilités offertes par les solutions du marché (Buy) tout en sachant aussi répondre aux besoins de fabrication de solutions sur-mesure (Make) :

  • Technologies de développement front (web / mobile), back, API…
  • Solutions de stockage et d’échange de données
  • Solutions de déploiement et d’hébergement Cloud, conteneurisation, automatisation…

Poser un cadre directeur permet d’adresser plus facilement ces enjeux technologiques en définissant les patterns et solutions à privilégier, mais aussi en définissant comment opérer au bon moment les choix de solution, en éclairant les options et les critères de décision.
Les opportunités technologiques doivent donc être identifiées et revues fréquemment pour répondre aux enjeux de l’entreprise et aux enjeux opérationnels des équipes IT.
Des méthodes et des outils permettant de faire des choix éclairés dans le contexte de l’entreprise sont à mettre en place, on peut citer:

  • les “Tech radars” qui synthétisent la veille technologique et apportent une classification des technologies du marché. Plutôt que de prescrire de manière directive une solution pour chaque besoin, un Tech radar offre un panel de possibilités à la disposition des équipes.
  • les analyses d’écart pour mieux contextualiser la décision et évaluer la trajectoire

Tech radar

Tech Radar Thoughtworks, une illustration de la complexité des choix technologiques et du besoin d’appropriation et de simplification

Comme illustré ci-dessus avec l’un des plus connus d’entre eux, les Tech radars que l’on peut trouver sur Internet offrent, bien souvent, trop de possibilités pour pouvoir s’y retrouver. Il faut les contextualiser en se focalisant sur l’essentiel des options technologiques et en tenant compte des capacités et de la maturité de son entreprise. En effet, une technologie classée “Adopt” par Thoughtworks sera considérée comme “Trial” (à essayer) dans beaucoup d’entreprises.
Les vues de type radar sont d’ailleurs intégrées dans de plus en plus d’outils de type Architecture d’Entreprise comme LeanIX ou de type IDP (Internal Developer Platform) comme Backstage.

L’anticipation du futur doit aussi s’accompagner d’une bonne gestion du patrimoine technologique existant, de l’obsolescence associée et des risques induits sur les opérations, la conformité et la sécurité. Le prérequis est un inventaire précis et à jour, donc le plus automatisé possible, des composants techniques utilisés dans le SI et de leurs versions (différents outils de type CMDB ou Architecture d’Entreprise peuvent aider à cette tâche), et une organisation adéquate qui responsabilise les équipes locales tout en gardant une vision globale pour permettre des rationalisations et mutualiser les efforts.
La dette technique doit ensuite être caractérisée et traitée de manière continue et le cycle de vie des technologies géré dans son ensemble : de l’adoption au décommissionnement en passant par les mises à niveau et évolutions nécessaires.

Conclusion

L’importance et la finalité de la stratégie IT restent les mêmes qu’auparavant (discernement, alignement avec les enjeux de l’entreprise, maîtrise des coûts), mais les outils pour sa conception et mise en œuvre évoluent en intégrant le besoin d’avoir des résultats rapides pour gagner en agilité et permettre d’ajuster le plan en continu.
Nous avons vu dans cet article comment :

  • Intégrer la stratégie métier, la formaliser sous différentes formes (vision métier, chaînes de valeur, cartographie des capabilities et des domaines métier) et y participer en travaillant sur des scénarios et en proposant des éléments à valeur ajoutée de l’IT
  • Établir un lien cohérent avec la stratégie tech grâce à des outils comme le DDD, être en mesure de prioriser et de faire des choix (par exemple Make or Buy), avoir une bonne gouvernance de la dette et des opportunités technologiques

Des méthodes et des outils utiles à la stratégie IT vous ont été présentés, mais la façon de les mettre en œuvre et les étapes nécessaires sont spécifiques à chaque contexte et OCTO peut vous accompagner dans cette démarche.
Pour citer un CTO dans le domaine de la distribution : “ce travail d'éclairage et de priorisation de notre stratégie IT, en cohérence avec notre business plan, était indispensable et a permis de redonner du sens et de la visibilité à nos équipes digitales”.

Nous verrons dans notre prochain article comment traduire les visions métier et tech en stratégie d’évolution du SI, comment maîtriser la gestion et la transformation du patrimoine applicatif et poser un cadre pour décliner la stratégie IT.

Références :

  1. Open Agile Architecture : perspectives et building blocks d’architecture
  2. TOGAF Value Streams Guide (opengroup.org)
  3. Olivier Wulveryck, Duck Conf 2024 : Décider avec : Stratégie, Wardley, Orientation, et Territoire - OCTO Talks !
  4. Romain Vailleux, Duck Conf 2022 : Core Domain Chart - Une pratique socio-technique à découvrir à travers un atelier et une étude de cas - OCTO Talks !