Si la pratique de la roadmap est très largement répandue chez les constructeurs et les éditeurs de logiciels, elle est, curieusement, peu développée au sein des DSI. C’est pourtant un exercice utile pour donner de la visibilité à ce que la DSI fait, à la fois pour ses collaborateurs de l’entité et pour les clients, qu’il s’agisse des métiers ou de la DG.
« Il n’y a pas de vent favorable pour celui qui ne sait dans quel port il veut arriver », affirmait Sénèque. Il faut reconnaître qu’aujourd’hui, pour les DSI, fixer un cap (et s’y tenir…) constitue une réelle difficuté, tant les évolutions dans les usages peuvent être rapides et les exigences, auxquelles ils sont confrontés, contradictoires. Parvenir à concilier ouverture du système d’information et renforcement de la sécurité, développement des services et réduction des coûts, est un combat quotidien. Comment faire pour résoudre ce paradoxe et donner du sens à son action ?
L’un des moyens de s’en sortir consiste à s’inspirer des pratiques des fournisseurs IT et de créer une roadmap de la DSI. Quel DSI n’a pas déjà participé à une réunion au cours de laquelle l’un de ses fournisseurs est venu lui présenter la roadmap d’un produit qu’il utilise, ou qu’il prévoit d’acquérir, dans le cadre d’un projet ? La roadmap est l’outil de base de l’industrie informatique, comme la truelle pour le maçon ou le marteau pour le charpentier.
À toutes les phases du cycle de vie d’un produit IT, il existe une roadmap :
• Au moment de la conception, la roadmap détermine la direction dans laquelle le fournisseur veut aller et la cible qu’il souhaite atteindre, en termes de services rendus et de type de clientèle.
• Au moment du développement, la roadmap permet de lister les fonctionnalités principales que le fournisseur veut proposer et l’ordre dans lequel il compte les mettre en œuvre.
• Au moment de la commercialisation, la roadmap est là pour montrer au marché ce que le fournisseur veut proposer et comment il se positionne par rapport à sa concurrence.
• A la fin de la vie du produit, la roadmap prépare la transition vers la solution qui lui succédera.
Qu’elle soit interne ou externe, la roadmap est bien souvent le seul support qui permet vraiment de matérialiser, et donc de comprendre, la stratégie d’un fournisseur de technologie.
La roadmap, un outil de pilotage
Pour un service de développement, la roadmap est le document de référence qui donne de la cohérence à tous les chantiers qui sont menés en parallèle par les différentes équipes. Pour le manager, c’est un outil de pilotage qui lui permet de savoir à tout moment où il en est et d’arbitrer les priorités, si des difficultés surviennent au cours du projet ou si la demande du marché évolue par rapport aux hypothèses initiales.
La roadmap, un outil de collaboration
Dans les phases amont de la réalisation du produit, la roadmap est l’outil qui va permettre à la R&D et au marketing de travailler ensemble sur les grandes caractéristiques et fonctionnalités, en tenant compte de l’état de l’art technique, des ressources disponibles, des cas d’usage et de ce que propose la concurrence. On définit ainsi une V1 avec un périmètre limité, mais précis.
On imagine déjà une V2 à douze mois, avec un spectre fonctionnel élargi, et ainsi de suite jusqu’au produit complet et mature, à 24 ou 36 mois. Ce travail collaboratif permet à chaque département d’exprimer et de faire comprendre ses enjeux. Le résultat de cette démarche est une vision partagée et réaliste de l’objectif à atteindre.
La roadmap, un outil de communication
Pour tous les acteurs du secteur high tech, la roadmap est un moyen privilégié de présenter leur vision et, indirectement, leur stratégie à plus ou moins long terme dans leur domaine. Même s’il est bien conscient que rien n’est jamais gravé dans le marbre et qu’une roadmap est susceptible d’évoluer, le DSI peut malgré tout se forger une idée assez précise de la direction que souhaitent prendre ses fournisseurs et adapter ses propres choix en conséquence.
La roadmap de la DSI : pour quoi faire ?
Si la pratique de la roadmap est très largement répandue chez les constructeurs et les éditeurs, elle est curieusement peu développée au sein des DSI. C’est pourtant un exercice utile pour donner de la visibilité à ce que l’on y fait, à la fois pour les collaborateurs de l’entité et pour les clients, qu’il s’agisse des métiers ou de la direction générale.
Comment transposer alors cette pratique dans une DSI ? Il convient d’abord d’envisager d’élaborer non pas une seule, mais au minimum deux roadmaps au sein de la DSI : une roadmap stratégique et une roadmap opérationnelle.
La roadmap stratégique, pour se rapprocher des métiers
C’est celle qui va donner les grandes orientations du système d’information à trois ans. Elle s’articule autour de trois axes :
- Un axe fonctionnel (finance, production, ventes et marketing, R&D, RH…) qui va décrire l’évolution des services rendus aux métiers en interne ou aux clients/fournisseurs/ partenaires en externe.
- Un axe applicatif (ERP, CRM, CAD/PLM, messagerie/collaboratif…), éventuellement en lien avec l’axe fonctionnel, qui va préciser quelles sont les solutions logicielles qui vont être mises en œuvre et les montées de versions prévues.
- Un axe infrastructure (serveurs/stockage, plan de reprise d’activités, cloud, mobilité, sécurité…) qui va montrer l’évolution du socle technique sur lequel repose le SI.
L’élaboration de cette roadmap stratégique constitue une bonne occasion de se rapprocher des métiers afin, bien sûr, de recueillir leur vision et leurs besoins, mais également de les éduquer sur les opportunités business offertes par les technologies. L’expérience montre que les métiers n’anticipent pas toujours correctement leurs propres usages et ont parfois besoin d’un accompagnement pour se projeter dans l’avenir.
La roadmap opérationnelle, pour la coopération entre les équipes
La roadmap opérationnelle a pour objectif de présenter les projets majeurs qui ont un impact important sur l’entreprise et qui mobilisent les différentes équipes de la DSI. Elle ne se substitue pas au portefeuille de projets. Il ne s’agit pas de tout y intégrer, mais de mettre en exergue les dépendances entre les projets principaux, afin d’identifier les éventuels conflits de priorités et les problèmes d’allocation de ressources. Par exemple, une montée de version majeure d’ERP ne s’improvise pas : elle a des impacts à la fois techniques et fonctionnels. Les équipes en charge de l’opération doivent être bien coordonnées, afin que le planning ne dérape pas et que les utilisateurs ne soient pas trop gênés au quotidien.
Comme pour la roadmap stratégique, l’établissement de la roadmap opérationnelle est l’occasion d’une véritable coopération entre les différentes équipes concernées. C’est le moment de mettre à plat toutes les contraintes et d’essayer de converger vers une cible commune.
Une mise en œuvre en trois temps
La réalisation d’une roadmap (stratégique ou opérationnelle) débute par le recueil des besoins/projets/exigences des différentes parties prenantes. Cela s’effectue en général sous forme d’interviews, individuelles ou en groupe. Puis vient la phase de mise en forme. Pour cela, les outils bureautiques traditionnels suffisent amplement. Un PowerPoint ou un Excel permettent de présenter de façon visuelle, sur une échelle de temps appropriée, les différents éléments recueillis. Il convient juste être vigilant sur le niveau de détail choisi, afin que le document reste lisible et compréhensible par un large public.
Arrive enfin la phase de négociation où les priorités vont être définies et partagées. L’idéal, pour obtenir rapidement un consensus, est d’organiser des ateliers collaboratifs dans lesquels les différentes parties prenantes vont pouvoir exposer leurs points de vue et s’efforcer de trouver des compromis pour avancer. Une fois que la première version de la roadmap est réalisée, il faut la diffuser largement pour que tout le monde soit bien aligné sur les objectifs définis.
Par définition, une roadmap est amenée à évoluer dans le temps. Il est bon de planifier une revue systématique, à intervalles réguliers, pour comparer la réalité avec les hypothèses. Pour une roadmap stratégique, il faut prévoir une revue semestrielle, pour une roadmap opérationnelle, une revue trimestrielle, au minimum, est nécessaire.
Définir les rôles et les responsabilités
Pour pérenniser cette pratique au sein d’une DSI, il est indispensable de définir des rôles et des responsabilités entre le pilote, les « roadmappers » et les contributeurs.
- Le pilote : c’est celui qui anime le processus. Il peut faire partie de la cellule PMO, si elle existe. Sinon, un manager avec une bonne vision globale de l’activité de la DSI et des qualités relationnelles avérées est tout indiqué.
- Les « roadmappers » : ce sont les personnes responsables de la pertinence et de la cohérence des informations contenues dans les roadmaps. Ils peuvent être chefs de départements IT, pour la roadmap opérationnelle, DSI et patrons métiers, pour la roadmap stratégique.
- Les contributeurs : ce sont les personnes habilitées par les « roadmappers » à alimenter et mettre à jour les informations des roadmaps. •
Cet article a été écrit par Laurent Chiozzotto, fondateur de Start&scale, cabinet de conseil spécialisé dans la mise en place de pratiques collaboratives en entreprise.
Les principaux bénéfices de la roadmap de la DSI
- Renforcer la cohésion des équipes de la DSI en cassant les silos habituels.
- Établir un dialogue de qualité avec les métiers en indiquant clairement la direction choisie
- Mieux faire comprendre à la direction générale les actions de la DSI.
- Justifier les investissements que la DSI demande.