La face cachée d’un projet de transformation numérique

Projet de transformation numérique - innovation

 

La face cachée d’un projet de transformation numérique.

Votre organisation se transforme, vous êtes un acteur du changement (chargé de projet, leader agile, responsable de produit, scrum master, architecte ou analyste d’affaires…)

 

Reconnaissez-vous l’une de ces situations ?

  • Difficultés à gérer le développement de vos solutions ?
  • Projets qui se terminent avec du retard ou en deçà des exigences prévues ?
  • Clients désappointés de votre offre de produits/services ?
  • Solutions qui répondent partiellement aux attentes fonctionnelles des clients?
  • Rétention et recrutement de personnel difficile ?

Actuellement, la plupart des organisations sont engagées dans une course contre la montre : celle de la transformation numérique. Bien qu’on en discute sur toutes les tribunes, plusieurs se demandent, en fait: qu’est-ce que l’on transforme ?

Transformation numérique axée sur la valeur

Autant pour le secteur privé que public, la pression est là. La question n’est plus tant : comment optimiser nos processus? La question est plutôt : qu’est-ce qu’il faut changer pour retrouver la manière de proposer à nos clients des solutions qui répondent à leurs besoins? (Parlez-en à Eastman Kodak, Sears, Téo Taxi, Sinorama… !).  Les attentes sont très élevées. Certaines organisations semblent si bien réussir le virage (Amazon, Chocolats Favoris, Coveo… ça vous dit quelque chose?), alors que d’autres peinent à y arriver?

La transformation impose de nouveaux paradigmes. Réorienter ses façons de faire c’est aussi une occasion de réfléchir sur la valeur de ce que l’on offre. Les symptômes énumérés plus haut sont intimement liés à ce que l’on appelle le passage du mode « projet » à « produit ». Cet article explore cette face cachée de la transformation numérique qu’on a tendance à mésestimer et qui, pourtant, peut faire toute la différence.  Notez qu’ici « produit » est équivalent à « service » et que la tendance gagnante est nettement de réfléchir comme des firmes de développement logiciel.

Nouveaux paradigmes associés à la transformation numérique

Les nouveaux paradigmes associés à la transformation numérique sont au confluent de différentes tendances observées ces dernières années : l’expérience client, l’amélioration continue, l’innovation, l’étude des processus, l’introduction de l’agilité (dans les projets et organisationnelle), la gestion du changement, le Lean, l’architecture d’entreprise et d’affaires, les chaînes de valeur, le tout numérique et, à travers tout ça… le passage du mode « projet » à « produit ».

Jusqu’ici, et la plupart du temps, on agissait sur ces sujets comme si c’étaient différentes initiatives ponctuelles, pas nécessairement concertées et issues d’un groupe ou ligne d’affaires, sans véritable stratégie d’ensemble ou transversale. Avec du recul, on voit mieux qu’ils équivalaient à des tentatives visant à se donner un modèle d’affaires plus efficace. On cherchait intuitivement à recentrer les opérations sur ce qui donne de la valeur et de la flexibilité.

Projet de transformation numérique

À la base, une transformation implique d’avoir établi une vision de ce que l’on veut devenir – une cible. Partant de là, on peut établir un point de départ et d’arrivée. En architecture TI, deux écoles de pensée mènent le bal. En considérant la disponibilité d’une vision, il y a les tenants :

  • de partir de la situation actuelle vers la cible (en identifiant les évolutions nécessaires., c.-à-d. les projets);
  • d’établir une cible et de la contraster avec l’actuel pour dégager un plan de travail pour s’y rendre (c.-à-d. les projets).

La première approche nous amène à réfléchir en termes de contraintes. On entendra souvent : ce n’est pas possible… on ne peut pas pour telle ou telle raison technique…). Généralement, avec cette approche, les résultats sont plutôt modestes.

Dans le 2e cas, on réfléchit moins aux contraintes. On identifie d’abord la cible, après quoi on recule pour ajuster l’actuel. Généralement on a de meilleurs résultats. Cependant, la démarche peut nous conduite à retrancher certaines activités ou produits de notre portefeuille de solutions (n’étant plus alignées sur la vision cible).

Il faut ajouter la variable temps à l’équation. De nos jours se projeter dans le temps plus loin que cinq ans est un exercice périlleux, vu le rythme des changements. En général, on se limite à cette durée et le projet de transformation est actualisé en continu. Ce qui donne la flexibilité nécessaire pour tenir compte des modifications qui surviennent dans l’environnement d’affaires et technologique.

Figure 1 : Modèle cible et identification des projets reliés à la transformation

Projet de transformation numérique - Évolution des services

Étapes d’évolution des services

  1. Inventorier les services actuels
  2. Identifier la situation cible (regroupée par domaines) selon l’analyse des tendances
  3. Évaluer l’arrimage des services actuels vs la cible (impacts)
  4. Identifier les ajustements requis aux services actuels (projets)
  5. Regrouper les résultats sous forme de feuille de route (planification)

Comme on s’en doute, l’exercice peut conduire à revoir les services actuels : ils pourront demeurer identiques, évoluer, être délestés ou on voudra en créer de nouveaux. Ici c’est une décision de gestion. Le portefeuille de projet sera le résultat d’un arbitrage entre la volonté de l’organisation, ses priorités et capacités (ajoutez à cela certains de jeux de pouvoir). Ce processus n’est pas statique, il est itératif et continu.

Gestion de « produits » vs « projets »

Une perspective plus stratégique liée aux services demande de revoir la façon dont on les conçoit et les développe. Aujourd’hui, la plupart des organisations opèrent suivant une approche de développement par projets. Ce qui implique d’évaluer le travail à faire, d’identifier un calendrier, une portée, un budget et mettre une équipe au travail pour réaliser la solution.  Lorsque le projet est terminé. On redéploie les membres de l’équipe à travers d’autres projets. Plusieurs de ces projets ont chacun leurs propres mesures du résultat atteint.

À l’usage, on constate que souvent la stratégie globale, à partir de laquelle on doit assurer la traçabilité des réalisations et leur bon alignement, reste difficile à établir. Il faut également éviter de confondre l’approche de livraison d’un projet vs l’approche de conception d’un service. Somme toute, un projet reste une initiative ponctuelle qui repose sur un but précis. Quand un projet se termine, l’objectif est atteint.

Bien sûr, les projets sont définitivement une part importante du développement d’un service. Sans être réducteur, il faut toutefois réaliser qu’ils peuvent avoir des impacts limités s’ils sont mal alignés stratégiquement. Ce qui n’enlève rien au fait que, par exemple, une amélioration déployée dans un logiciel contribue au succès du service.

Cela dit, pour mieux réfléchir sur ce qui distingue le mode projet et les produits, on doit revenir à la base, c.-à-d. la valeur.

Notion de valeur

Voilà un concept apprêté à différentes sauces par des cuisiniers qui ne manquent surtout pas… d’imagination. En réalité, il faut revenir à sa signification de base pour un client et son fournisseur. Dans cette perspective, le modèle suivant indique que la valeur résulte d’un échange entre deux parties et le produit (ou service), est ce qui la véhicule.

Figure 2 : Modèle de la valeur

Projet de transformation numérique - modèle de valeur

Une faible valeur signifie que l’arrimage entre les produits et services offerts par un fournisseur et la satisfaction des problèmes, désirs et besoins d’un client est imparfait. Les deux parties cherchant à optimiser le tout, malgré leurs contraintes respectives. Il faut donc se soucier de la valeur livrée si l’on souhaite assurer la pertinence d’une solution (ex. le virage numérique). Ce qui implique que l’on va s’organiser pour la mesurer (et ceci, autrement que par la seule quantité) – on voudra aussi s’assurer de la pertinence de ce qui a été livré.

Ambitions et moyens

Si l’organisation se donne une cible, elle doit réfléchir sur les impacts technologiques et humains qu’auront les opportunités proposées, mais également, sur ceux qui concernent sa gouvernance. Ainsi, outre définir les projets requis pour atteindre la cible, il faut s’intéresser aux compétences qu’ils vont réclamer.

Peut-être faudra-t-il créer de nouveaux rôles afin de soutenir les nouveaux services ou en délester d’autres. Il faut donc inclure les ajustements à la main d’œuvre dans votre projet de transformation. Autrement dit, la question à se poser est : quels sont les profils de ressources requis dans cinq ans pour livrer les services planifiés? Ce qui pourrait conduire à revoir vos politiques d’embauche pour arriver à combler les écarts possibles et prévoir un plan de transition (Vous cherchez un exemple ? Pensez à l’infonuagique).

Imputabilité ultime face à un produit ou service et votre projet de transformation numérique

Il y a une différence entre l’imputabilité qui existe sur un service et la fonction de propriétaire de produit (Product Owner – PO).

Dans les organisations plus traditionnelles, l’imputabilité du contenu d’une solution est généralement attribuée au gestionnaire de la ligne d’affaires. Force est de constater que ce modèle – même s’il donne une certaine imputabilité sur les services, est plutôt mal adapté dans une perspective long terme. Dans le cas où le gestionnaire agit comme PO, on observe une propension à reconduire l’effet silos que l’on cherche à faire disparaître au profit d’une perspective plus horizontale.

Non qu’un gestionnaire ne veuille bien faire, mais sa perspective des résultats à atteindre est plus immédiate et se mesure par ses contraintes : combien ai-je de budgets pour livrer mes solutions, de gens pour faire le travail, de temps j’ai pour livrer et où j’en suis dans ma capacité, etc. Bref, il a peu d’espace pour manœuvrer hors de la perspective de l’exploitation.

Votre projet de transformation repose sur l’intention de donner de la valeur à vos clients, alors il faut se souvenir que vos solutions serviront à la véhiculer. Il faut donc s’assurer qu’elles soient livrées efficacement (agilité), mais aussi optimales et au meilleur intérêt de toute l’organisation et de ses clients (valeur).

Agilité – solution en vue 

Dans le monde SCRUM, en agilité, on retrouve minimalement trois rôles typiques dans une équipe de projet : le propriétaire de produit (Product Owner-PO), l’équipe de développement et le Scrum Master.

Un responsable de produit indépendant du rôle de gestionnaire est mieux à même de garder le cap sur l’objectif stratégique en vertu de l’arrimage constant que sa fonction implique auprès de la clientèle, ses besoins et désirs et pourrait relever du dirigeant d’une ligne d’affaires.

Évidemment que de plus en plus les organisations ont acquis une maîtrise des concepts de l’agilité et que ces rôles sont établis (dont celui essentiel de PO). On aura également intégré la notion de valeur à nos activités et projets ainsi que mis en place des indicateurs pour s’en assurer.  Au fil du temps et avec la multiplication des projets et des équipes agiles, on réalise qu’il faut ajouter un rôle supplémentaire : celui de responsable de produit (Product Manager – PM). On voit ce rôle dans différentes méthodes – dont SAFe et autres.

En recentrant vos actions autour de ces concepts, votre organisation sera mieux à même de réussir ce virage et prendre en compte la face cachée d’un projet de transformation. Il faut cesser de faire des projets sans considérer un alignement avec la notion de produit.

Prochain article

Le prochain article traite de ce qu’implique la gestion axée sur le produit : comment concrétiser ces concepts dans votre organisation ? Description du rôle du PO et PM? Qui doit occuper la fonction de PO ? Pourquoi prévoir un rôle de PM ? On discutera de l’approche : assigner une équipe à un projet ou un projet à une équipe?  Quelle structure organisationnelle ? L’agilité à l’échelle demande ces ajustements.

Présentation de l’auteur

Auteur Marc Lafontaine, PMP, PSMMonsieur Marc Lafontaine PMP, PSM
Conseiller senior en architecture d’affaires, Alithya

marc.lafontaine@alithya.com

Monsieur Lafontaine cumule plus de 30 années d’expérience en gestion des TI dans les secteurs public et privé. Son savoir-faire a été mis à profit à titre de chef de projet ou architecte d’affaires dans de nombreux dossiers technologiques d’envergure ou projets de transformation.

Actuellement, il exerce comme conseiller senior en architecture d’affaires au sein de l’équipe Alithya. Il est également administrateur au PMI Lévis-Québec depuis plusieurs années, conférencier et rédacteur de nombreux articles portant sur les domaines de la gestion de projet et l’analyse d’affaires.

Article précédent
Au-delà des outils – la culture de projet et l’entreprise
Article suivant
Transformation numérique/agile – partie 2 : les impacts

Articles liés

Menu