Nous le constatons encore aujourd’hui, certains projets n’aboutissent jamais, ou alors après des mois voire des années de mise en œuvre et sont boudés par les utilisateurs.
Malgré une gestion des changements, la plateforme n’est jamais utilisée et l’application meurt (on l’espère rapidement) sans jamais rencontrer ses utilisateurs.
Dans certains cas, le projet “stratégique” a été validé par la Direction, la technologie en haut à droite du cadran du Gartner a bien été déployée, mais au final les cas d’usage sont beaucoup trop compliqués à intégrer sur la plateforme. Ces projets finissent souvent en échec, les ressources ont été gaspillées et l’image de la DSI en pâtit.
Enfin, dans d’autres cas, l’étude s’éternise pour concevoir, et planifier l’architecture qui répondra à l’ensemble des cas d’usages et qui permettra de résorber la dette technologique. Ces cas de figure trop fréquents partent malheureusement de bonnes intentions. Il s’agissait de couvrir l’ensemble des besoins existants et d’absorber les besoins qui ne manqueront pas d’arriver à court et moyen terme.
Une approche frugale
La meilleure solution consiste à se concentrer sur quelques utilisateurs clés pour prendre en compte des fonctionnalités précises qui peuvent être implémentés sous forme de MVP en quelques sprints et le faire évoluer pour prendre en compte les nouveaux besoins.
L’architecture de la solution devra rester souple et prévoir “by design” de pouvoir intégrer de nouveaux composants et technologies qui répondront demain à des nouveaux besoins.
Pour réussir cette mise en œuvre, il faut donc réunir une équipe pluridisciplinaire qui sera en charge de :
Collecter et analyser les besoins des utilisateurs
Définir l’architecture fonctionnelle et de données
Définir l’architecture technique
Constituer et suivre la backlog
Concevoir et mettre en œuvre les développements
Déployer l’architecture technique
Au démarrage du projet il faudra donc :
un Product Owner
un architecte en charge des aspects fonctionnel, applicatifs et data
un architecte technique
un scrum master
un ou plusieurs développeurs spécialisés sur les stacks à mettre en oeuvre
un cloud-ops
Un Business Analyste
Une organisation efficiente
Cette organisation s’inspire des Pizza Teams (l’ensemble des membres d’une équipe doit pouvoir se nourrir sur une Pizza Américaine). Elle vise à simplifier la communication au sein d’une équipe. En effet, le nombre de liens entre les personnes d’une équipe peut être calculé avec la formule suivante (1) :
( N x (N -1 ) )/ 2
Où N est égale au nombre de personnes dans l’équipe.
Plus le nombre de personnes est important plus les échanges sont importants et les risques et le temps consacrés aux échanges sont importants.
La mobilisation de l’équipe permettra de produire au fil des sprints des versions de plus en plus abouties, revues régulièrement par les utilisateurs.
En quelques semaines, une première version pourra être déployée en production sur le périmètre jugé prioritaire par les utilisateurs.
L’adoption ne sera plus un problème, car les utilisateurs auront participé à la conception de leur outil et remonteront directement les fonctionnalités prioritaires.
Au fil des évolutions, l’équipe pourra être élargie pour prendre en compte des besoins impliquant des nouvelles briques d’architecture et de nouvelles technologies. Il faudra toutefois rester vigilant afin de ne pas dépasser le nombre critique de membres dans l’équipe.
Une dynamique dès le cadrage
Un cadrage initial est indispensable avant de lancer le projet. Certes l’organisation projet et le user-centrisme sont des facilitateurs, mais la clef dans le succès de la démarche se trouve en amont. Si au lieu de demander aux utilisateurs quels sont leurs besoins et de les hiérarchiser par priorités, nous leur demandions leurs envies ?
Les utilisateurs vont être concentrés sur ce qui est vraiment important dans leur travail et ce qui va leur simplifier la vie. Si l’application a de multiples utilisateurs, il faudra les amener à trouver un consensus et à présenter une liste commune. Cette liste sera la base de la backlog projet et devra être affinée afin de la rendre implémentable.
Faire adhérer les décideurs
Cette approche projet nécessite de rassurer les décideurs. En cela la méthode agile est insuffisante. Le burn out chart ou les autres indicateurs sont utiles au pilotage agile des projets, mais suffisent rarement à rassurer les décideurs sur les aspects coûts / délais / valeur ajoutée des projets.
Il faut donc trouver des indicateurs complémentaires, aptes à rendre compte de l’avancement des sprints, mais qui permettent aussi d’apporter de la visibilité aux décideurs qui n’ont que faire des points de complexités et autres idiomes agiles.
Revoir la méthode
La réussite des projets passe par une remise en question profonde de nos méthodes d’architecture. Le framework TOGAF nous donne de bonnes bases, mais elles sont loin d’être suffisantes pour aller vers de l’architecture SI agile.
Les évolutions de l’architecture découlant des besoins métiers et non plus d’une planification détaillée réalisée en début de projet et implémentée dans un cycle de plusieurs mois ou années, cela nous amène à adresser des problématiques qui remettent en cause nos méthodes de travail :
Les projets font de plus en plus souvent appel à de l’expérimentation. Les composants sont testés sur des calendriers resserrés et suivant l’adéquation par rapport au besoin, sont adoptés ou abandonnés.
Les schémas d’architecture initiaux sont vite obsolètes et ne seront maintenus qu’en contrepartie d’un investissement conséquent à faible valeur ajoutée pour l’utilisateur.
Les technologies évoluent (trop) vite, la maîtrise des technologies par les équipes de support et d’exploitation prend beaucoup plus de temps.
Les utilisateurs ne comprennent plus que l’informatique professionnelle soit décorrélées des technologies mises à dispositions par les GAFA.
Les projets sur plusieurs années sont obsolètes avant d’être ouverts aux utilisateurs.
Pourtant des méthodes et outils inspirés du design thinking, du Lean ou du manifeste agile sont là pour nous aider avec par exemple :
La méthode sprint pour l’expérimentation ;
Des outils de documentation automatique des architectures qui garantissent des schémas toujours à jour (2) ;
Une organisation devops et une automatisation du traitement des incidents ;
Une approche itérative des projets, pour apporter de la valeur aux utilisateurs de manière linéaire sans sacrifier la qualité.
Certains argumentent que ces transformations sont réalisables à l’échelle des startups ou de compagnies digital natives, mais c’est oublier que le dev-ops tire son origine du monde industriel, certes beaucoup moins souple que l’IT, mais où la transformation vers le lean a été une condition de survie. The phoenix project (3) illustre très bien les parallèles entre le monde industriel et l’agilité , plus proche de notre quotidien, la gestion des maintenances des TGV est opérée par la SNCF via des tableaux agiles où l’ensemble des bonnes pratiques sont respectées.
Se transformer pour survivre
Les architectes n’auront bientôt plus le choix, les projets planifiés à plusieurs années induisent trop de risques :
tant sur le budget (il est de plus en plus difficile d’obtenir un budget pluriannuel pour un projet qui délivrera dans un futur éloigné)
que sur l’adoption utilisateur : la solution prévue ne correspondra plus aux priorités du business lorsqu’elle aboutira.
L’architecte doit donc à la fois porter une vision à long terme permettant de respecter les règles de l’entreprise, garantissant l’exploitabilité de l’application et être capable de faire opérer des changements d’architecture pour répondre aux priorités métier à court terme.
Un changement de paradigme est nécessaire pour passer d’une organisation ou les technologies sont des capacités de soutien qui fournissent des services, des plates-formes ou des outils spécifiques au reste de l’organisation, tels que définis par les priorités, les ressources et le budget, à une organisation ou les technologies sont parfaitement intégrées et au cœur de tous les aspects de l’organisation en tant que moyen de libérer de la valeur et de permettre des réactions rapides aux besoins des entreprises et des parties prenantes (4).
Il nous faut nous habituer à la distribution de valeur dès le début du projet et nous préparer à prendre en compte les nouveaux besoins à chaque nouveaux sprints.
Les utilisateurs doivent se sentir impliqués, considérés. Leurs remarques doivent être valorisées afin de rentrer dans un cercle vertueux qui permettra de délivrer de l’expérience utilisateur de qualité en continu.
Le succès des projets dépend maintenant de la capacité des architectes à prendre en compte les besoins des utilisateurs, afin de toujours pouvoir s’adapter aux priorités métier et délivrer de la valeur au plus près des enjeux business. Ces changements bousculent certainement les habitudes ancrées dans la DSI, mais la valeur dispensée aux utilisateurs justifiera l’investissement à apporter dans ces changements.
La gestion de portefeuille des projets est une activité de mieux en mieux considérée au sein des organisations. Elles sont de plus en plus nombreuses à prendre conscience que le rendement de leurs investissements n’est pas seulement le fait des livraisons mais aussi de leurs capacités à engager les bonnes initiatives de changement au bon moment. La gestion de portefeuille de projets y contribue par ses processus mis en œuvre pour les prioriser, pour s’assurer de leur pertinence vis-à-vis des objectifs stratégiques, pour optimiser les ressources, pour anticiper les incertitudes et les risques, pour coordonner les adhérences, pour discipliner les pratiques et pour maximiser les bénéfices. C’est bien tout cela qu’apporte la gestion de portefeuille de projets.
Des capacités d’action et d’information à développer
Les bonnes pratiques de gestion de portefeuille de projets (instances, prise de décision, etc.), toutes ensembles, permettent de régler la bonne vitesse du changement, c’est à dire le plus efficace. À ce titre, la gestion de portefeuille aspire à fournir à sa Direction des données fiables qui lui permettent de prendre des décisions d’investissement plus éclairées, en fonction des ambitions et des moyens disponibles. Il revient donc à la direction de rattachement du dispositif PMO au sein de l’entreprise d’exprimer ses besoins vis-à-vis d’elle. Cela s’étend de la surveillance passive jusqu’à la gestion active de la composition et de l’exécution du portefeuille dans son ensemble, ainsi qu’à s’assurer que les équipes sont dynamisées, que la réalisation des bénéfices est optimisée et que les leçons de l’expérience sont tirées et appliquées à l’avenir (amélioration continue).
Connaître ses défis pour mieux les affronter
Parce que “charité bien ordonnée commence par soi-même”, les PMO doivent se prêter à un auto-examen pour connaître leur propre maturité au regard des besoins de gouvernance, de l’évolution de l’environnement et des technologies. En effet, la gestion des projets est soumise aux mêmes contraintes que les autres activités de l’entreprise : enjeux multiples, interdépendants et sur des horizons de temps toujours plus courts qui réclament toujours plus d’agilité. Pour ne citer que ceux-ci :
Positionnement dans l’organisation : où doit se situer ce centre névralgique, porteur de la vue panoramique des projets de l’entreprise, qui constituent rien de moins que le moteur des futures transformations ?
Posture de facilitateur : comment assumer le rôle de coordinateur du changement, comme gestionnaire des dépendances entre projets et entre programmes et des flux de données en temps réel qui s’y rattachent ?
Réduction des temps de réponse : comment accélérer ses propres procédés avec les nouveaux outils digitaux pour limiter au mieux l’inertie et la charge administrative appliquées aux projets ?
Intégration de l’agilité : quelles sont les nouvelles capacités de travail à développer (travail collaboratif, gestion des produits, etc.) pour gagner à la fois en flexibilité du travail et surtout être à même de plus de réactivité face aux attentes des usagers, et à toutes sortes de contingences externes ?
Ainsi, il incombe au PMO de veiller à ce que ses méthodes, compétences, indicateurs, et outils soient à jour et apte à optimiser la création de valeur ainsi que l’exécution de la stratégie.
L’évaluation des capacité est un impératif avant les actions de progrès
Pour y parvenir, l’évaluation apporte un regard objectivé sur le niveau de sophistication des fonctions et services réalisés sur tout ou partie des activités PMO d’une entreprise. La connaissance de la maturité PMO éclaire tout à la fois sur la capacité de ses services et moyens à répondre aux besoins des parties prenantes et sur la valeur qu’ils sont aptes à générer.
Cet exercice d’introspection est possible depuis que les éditeurs de référentiels de bonnes pratiques de gestion de projets proposent chacun leurs modèles d’évaluation de la maturité des pratiques PPM. Le plus ancien est OPM3 (du PMI éditeur du PMbok) le plus connu. L’autre modèle notoire est P3M3 (de l’OGC éditeur des référentiels P3O et Prince 2) qui reste le plus accessible dans sa mise en œuvre.
OPM3 & P3M3 pour évaluer la maturité: les limites
Le référentiel OPM3 construit autour de 3 groupes de processus (projets, programmes, portefeuilles), 5 domaines de connaissances, 16 processus de gestion de portefeuille et 18 Facilitateurs organisationnels, est aligné sur les principaux standards de son éditeur. Ce modèle, très exhaustif, met l’accent sur la valeur de la gestion de projet organisationnelle dans l’exécution des stratégies organisationnelles pour identifier les domaines d’amélioration.
Le modèle de maturité P3M3 examine la façon dont une organisation exécute ses 3 champs d’activités projets, programmes et portefeuilles. Il est unique en ce sens qu’il examine l’ensemble du système et pas seulement les processus. L’évaluation P3M3 peut être adaptée aux besoins de l’organisation et être déployée de multiples façons. Il propose d’évaluer tous les domaines de l’organisation au travers de 7 perspectives de processus (le contrôle de gestion, la gestion des gains, la gestion financière, la gestion des parties prenantes, la gouvernance organisationnelle, la gestion des risques, la gestion des ressources).
Cependant, pour un usage récurrent, effectuer une évaluation de la maturité PMO avec ces deux modèles devient rapidement difficile car nécessitent de faire appel à un évaluateur certifié sans faire de distinction entre les processus pour servir l’organisation et ceux internes exécutés en fonction de la localisation du PMO dans l’organisation. Enfin, le relevé des forces et faiblesses de maturité qui résulte de leur évaluation est établie entre l’existant de l’organisation et une référence standard maintenue par l’éditeur.
Rhapsodies Conseil a élaboré un outil d’évaluation de la maturité PPM
C’est en cherchant à disposer d’un outil à la fois facile à mettre en œuvre et proposant un rendu plus visuel de l’évaluation de la maturité PPM des organisations, que Rhapsodies Conseil en est venu à développer son outil. Après plusieurs versions et mises à l’épreuve, le CUBe de la maturité PMO est une création issue d’une forte inspiration du concept du CUBe® (collectif Americo Pinto, Marcelo F De Matheus Cota, et Dr. Ginger Levin – 2010) et des modèles OPM3, P3M3.
A partir d’un référentiel de 27 services adaptés des fonctions les plus communes en PMO (travaux de Hobbs and Aubry – 2007) et des 18 facilitateurs organisationnels du modèle OPM3, le CUBe est structuré par ses trois dimensions en 9 cadrans et 3 niveaux de maturité. La première dimension, la Portée s’attache aux niveaux de l’activité PMO dans l’organisation (Entreprise, Direction, Projet/programme). La seconde, l’Approche, représente les niveaux d’action (Stratégique, Tactique, Opérationnelle) de ses services comme l’évoque le modèle P3O. Enfin les niveaux de maturité se déclinent en Basic, Intermédiaire et Avancé.
Aux croisements des niveaux de Portée et d’Approches, il en résulte le questionnaire de l’évaluation. Pour limiter les biais de réponses aux questions celles-ci sont proposées en choix limité à 3. Autre caractéristique de simplification, la détermination des services à améliorer peut se faire par comparaison de la maturité existante du dispositif avec celle des capacités de ses activités en cible. Cette cible est déterminée en parallèle avec le responsable de rattachement du PMO. Car les exigences et attentes entre les différentes Portées et vis à vis de chacune des Approches de l’activité PMO sont propre aux ambitions et rythme d’évolution de chaque PMO.
Enfin, la restitution se fait selon deux formats possibles, un score en % des cadrans du CUBe à destination des décideurs et sur une carte « Heatmap » des différents services évalués plus adaptée aux opérationnels pour construire le plan de développement de la maturité PMO PPM où cela est nécessaire dans l’organisation. C’est ainsi que l’outil permet de dresser un bilan des pratiques et des besoins d’évolution à traiter et d’en relever les progrès plus facilement au fil du temps.
Si après cette lecture vous êtes curieux de découvrir ou d’essayer cet outil, vous trouverez ci-dessous le lien de téléchargement. Si vous souhaitez en savoir plus ou pour obtenir des réponses à vos questions, nous sommes à votre disposition. N’hésitez pas à nous contacter.
¹ Organizational Project Management Maturity Model (PMI) ² P3M3 : Programme, Project, Management Maturity Model (OGC) ³ P3O : Portfolio, programme and Project Offices
Gartner estime que les budgets des DSI vont baisser de 8% en 2020 par rapport à 2019.
Dans ce contexte, c’est toujours la même sempiternelle question qui revient : comment faire plus quand on a moins d’argent ?
Il n’y a pas de solution miracle
Si la réponse à cette question était si simple, quelqu’un en aurait fait une méthode et serait devenu probablement très riche en très peu de temps.
Pas de solution miracle donc, mais peut-être des pistes de solutions à chercher dans les modes de fonctionnement de certaines équipes.
Première piste : dépenser moins.
Maigrir : lean, lean, lean…
Il s’agit ici d’optimiser les processus, de standardiser et d’automatiser au maximum pour réduire les coûts. L’approche Lean et ses dérivés dans l’industrie, l’IT ou le Management contient tout un tas de méthodes pour arriver à cet objectif. Cet article à ce sujet est très intéressant : “Sorry, But Lean Is About Cost Reduction…” et identifie certaines pistes :
Eliminer les gaspillages (c’est ce qui est le plus connu dans Lean et parfois on s’arrête là).
Analyser et catégoriser les coûts et s’attaquer aux coûts non justifiés
Rationaliser les activités
Supprimer des postes (mais pas les personnes que l’on emploiera à travailler sur le système)
… Oui mais pas n’importe comment !
Vous noterez que cet article au titre provocateur insiste finalement sur le fait que l’approche Lean n’a pas pour seul but de réduire les coûts, mais permet de le faire si on l’adresse de manière globale et intelligente.
Sur ce point, considérer qu’il est possible de réduire les coûts en supprimant des postes et en demandant toujours plus aux employés a peu de chance d’être rentable. Les coûts cachés ne sont pas loin : augmentation du turnover, de l’absentéisme, désengagement.
Par exemple, cette étude montre qu’une implémentation d’une approche Lean qui ne serait centrée que sur les aspects méthodologiques au détriment des aspects humains peut conduire à une augmentation de 82% du nombre d’arrêts maladie et de 62% de leur fréquence moyenne. En effet, une culture du process à outrance peut conduire à une diminution de l’autonomie et du contenu cognitif du travail, deux facteurs jouant sur la motivation intrinsèque du travailleur comme nous le rappelle Dan Pink dans cette vidéo “la vérité sur ce qui nous motive”.
Simplifier
Vous connaissez les 4 valeurs du Manifeste Agile ? Normalement oui.
Vous connaissez les 12 principes sous-jacents ? Moins sûr n’est-ce pas ?
Je les relisais récemment et l’un d’entre eux me semble totalement aligné avec le thème de cet article : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
Apprendre à faire simple pour travailler moins et donc dépenser moins, vous en avez forcément entendu parler.
Innovation frugale vous connaissez ? Allez lire cet article où Navi Radjou nous dit :
“L’objectif est également de faire des produits simples, robustes et durables. Et d’aller vite.”
Qu’est-ce qui nous empêche de faire pareil dans la DSI ?
Planifier juste à temps et pas tout le temps : roadmap produit, sprint planning, et basta !
Estimer par comparaison plutôt que chiffrer : j’ai réussi un jour à réduire à 45 minutes une session d’estimation d’une équipe de 8 personnes qui durait d’habitude 1 journée entière, et qu’ils réalisaient une fois par mois. Je vous laisse faire le calcul des économies réalisées. De mon côté les remerciements des participants de ne plus avoir à subir cette journée infernale m’ont suffit.
CoProj, coPil, CoStrat, ComInvest, etc… Privilégiez la transparence et la visibilité à froid (emails, supports de communication) et ne participez à des comités que si des décisions importantes sont à prendre. Sinon traitez les petites décisions en point à point.
Développeurs, écoutez Uncle Bob et codez proprement avec Clean Code : Keep it simply stupid !
Antoine de Saint-Exupéry annonçait d’ailleurs le Lean et l’Agilité avant l’heure :
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
Investir
Comment ? Dépenser moins en investissant ? Mais qu’est-ce qu’il raconte ?
Et pourtant : investir au début et régulièrement permet d’économiser sur la durée.
Pas le temps d’industrialiser les tests, il faut qu’on produise de la valeur, c’est notre PO qui l’a dit.
Expliquez donc à votre PO que produire du code sans automatiser les tests aujourd’hui est plus rapide et moins coûteux, mais qu’il est probable qu’il devra repayer une toute nouvelle application dans 3 ans quand celle-ci sera impossible à maintenir.
Nous pouvons regrouper toutes ces pratiques d’automatisation (des tests, des déploiements, de l’infrastructure) sous le terme chapeau de DevOps (je préfère parler de BizDevOps). Ces pratiques et outils nous servent à faire des économies :
moins d’évaluation et de gestion des risques en amont car on teste plus tôt et on obtient rapidement les feedback des utilisateurs
moins de charges de recette manuelle qui ont tendance à augmenter de manière exponentielle avec le temps
moins de temps perdu à bricoler parce qu’on n’a pas à disposition les bonnes données ou l’environnement pour les tests de performances (coucou Infrastructure as code)
Sans oublier que BizDevOps, c’est avant tout un mode de fonctionnement qui favorise les interactions et la collaboration. Qui n’a jamais entendu une phrase du type : « Mon job c’est développeur, …peu importe ce qui arrive …je développe » ? Phrase qui annonce de bien mauvaises nouvelles dans quelques sprints…
Deuxième piste : produire plus de valeur
Prioriser
Cela fait plus de 10 ans que je travaille autour de l’agilité. Ce qui m’avait passionné dès le début, au-delà de l’amélioration des interactions et des relations humaines qui en découlent, c’est la priorisation par la valeur. Je ne sais pas combien j’ai fait d’ateliers avec des Product Owners (PO) pour les aider à appliquer ce principe si simple à énoncer, si difficile à mettre en œuvre.
Évidemment, aujourd’hui tout le monde est d’accord sur le principe de faire d’abord ce qui a le plus de valeur. Il y a 10 ou 20 ans, ce n’était pas si naturel, puisque de toute façon il fallait tout faire, alors pourquoi ne pas commencer par le plus facile, ou le plus difficile…
Avec mon équipe de coachs agiles, nous avons créé une école pour les PO d’une grande entreprise leader du e-commerce. Nous avons dédié un module entier d’½ journée à la valeur. Pas à la priorisation, mais à la représentation de la valeur. Car c’est un travail qui peut être extrêmement complexe. Il consiste à identifier les drivers ayant un impact sur la valeur et à les catégoriser : risques, valeur intrinsèque, valeur d’investissement, technologies…
En travaillant sur la priorisation du backlog, le processus de développement en agile permet donc, pour un coût constant, de livrer en premier des fonctionnalités qui génèrent plus de valeur.
Alistair Cockburn nous propose d’ailleurs la définition suivante :
“Agile is early delivery of Value and less bureaucracy”
Comprendre et mesurer
Pour produire plus de valeur, il faut probablement développer sa compréhension des utilisateurs et des clients.
Et pour aller plus loin que cette simple phrase, j’aime beaucoup la combinaison des 3 approches Design Thinking + Lean Startup + Agile :
Design Thinking ou l’approche centrée utilisateur vise à se mettre à la place du client/utilisateur pour bien comprendre quels sont ses problèmes.
Lean Startup permet de poser des hypothèses sur les solutions à mettre en oeuvre en face de ses problèmes, et de boucler très vite pour savoir si nos hypothèses sont bonnes, ou pas.
Le développement Agile permet d’organiser le processus de livraison des fonctionnalités de sorte que ce soit régulier (itératif) et incrémental en priorisant par la valeur (comme vu précédemment).
Si même le Gartner le dit…
La combinaison de ces 3 approches est pour moi indispensable dans la réussite d’un produit car on peut très facilement en arriver à développer vite et bien des fonctionnalités parfaitement inutiles. J’intègre tout cela dans tous mes accompagnements pour product owners et product managers.
Au final : lean et agile, la solution ?
Ce qui définit l’Agilité, c’est cette importance donnée à l’apport de valeur plus qu’à la réduction des coûts. Il y a bien sûr une recherche d’efficacité, mais surtout d’efficience.
Avec plusieurs années d’expérience derrière moi, une combinaison des 2 est probablement une bonne approche : optimiser au maximum ce qui va être répétitif (tests, déploiements…) et accélérer au maximum le processus de création de valeur (priorisation, less is more…).
Comme dans un bon cocktail, tout est question de dosage et de vision globale : pour avoir un système efficient, il se peut que certaines parties du système ne soient pas optimisées au maximum, générant de fait une capacité à innover et à créer plus de valeur.
Pour arriver à trouver ce bon dosage permettant de produire plus de valeur, plus vite et avec moins d’argent, vous avez probablement besoin d’une bonne équipe produit qui :
Comprend les problèmes réels de ses clients (avec un profil UX par exemple dans l’équipe)
Expérimente fréquemment des morceaux de solutions pour mieux comprendre son écosystème et valider ses hypothèses (avec le Lean Startup). Cela implique de systématiquement mesurer a posteriori de la livraison les indicateurs liés à ces hypothèses, chose qu’on a parfois tendance à oublier de faire
Développe son produit avec des principes agiles : en favorisant les interactions, en livrant fréquemment des fonctionnalités en production, en documentant le nécessaire et en étant ouvert à des changements fréquents (vous avez reconnu les 4 valeurs du Manifeste Agile ?)
Met en place un système de mesure de la performance et s’organise pour l’améliorer en continu (avec le Lean). Je me permets d’insister sur ce dernier point : la mise en place d’une véritable démarche d’amélioration continue est la base de l’optimisation d’un système. C’est également ce qui fait trop souvent défaut dans les implémentations Agiles qui prennent insuffisamment en compte le changement de mindset nécessaire
J’ai observé personnellement une équipe de 6 personnes (PO, UX, devs) produire en 6 semaines ce qu’une équipe de 12 n’avait pas réussi à finaliser en 6 mois.
Leur différence ? Probablement un peu plus d’expérience (et donc un TJM plus élevé coucou les fausses économies) et surtout une capacité à se poser les bonnes questions.
Rappelez-vous A. Einstein qui disait :
“Si j’avais une heure pour sauver le monde, je passerais 55 minutes à définir le problème et cinq minutes à trouver la solution.”
Attention je le répète : ceci n’est pas une solution miracle. Ca ne fonctionnera pas si votre organisation n’est pas collaborative, si vos métiers et vos IT ne savent pas se parler, si votre management met des bâtons dans les roues plutôt que d’aider les équipes de dev. Mais si vous prenez maintenant ce chemin, ce sera toujours mieux que la situation actuelle. C’est dans les situations de crise que l’Homme est le plus innovant.
L’Instant Payment, parallèlement à la DSP2, a projeté les paiements dans un nouveau monde, ouvert à la créativité et à la compétition. Cette ouverture vise à offrir de nouveaux services, dans une économie digitale, en réponse aux attentes des utilisateurs : instantanéité, mobilité, accessibilité, fluidité et simplicité.
Il est dès lors naturel de citer en priorité les usages de l’Instant Payment correspondant à des services qu’aucun autre moyen de paiement n’offre jusqu’ici ; l’exemple le plus courant est le dépannage d’un proche à distance (à l’autre bout de l’Europe, dans un aéroport pour ajouter à l’urgence de la situation…).
L’absence d’alternative confère alors à l’Instant Payment sa vraie valeur d’innovation. L’examen de ces cas d’usage, tant côté particuliers qu’entreprises, montre bien les caractéristiques les plus disruptives de l’Instant Payment :
la disponibilité immédiate des fonds,
la couverture 24/7/365.
Au-delà du dépannage d’un proche, le règlement d’un sinistre (assurance), le remboursement d’un vol annulé, illustrent bien ces nouveaux services rendus possibles par l’Instant Payment, souvent dans des situations d’urgence. Côté Entreprises, l’urgence aussi peut exister quand il faut régler tardivement une facture (relance fournisseur ou échéance sociale à ne pas manquer).
Pour autant, les enjeux de développement de l’Instant Payment ne peuvent se limiter aux situations d’urgence. Il doit s’imposer aussi sur des cas d’usage déjà couverts par d’autres moyens de paiement. Les premiers retours d’expérience (sur les paiements instantanés au sens large, au-delà du SCT Inst) montrent bien que les attentes des utilisateurs pour une large adoption de l’Instant Payment portent essentiellement sur :
la facilité d’utilisation ou, dit autrement, la fluiditédu parcours intégrant le paiement :
payer entre amis, sur smartphone, sans même besoin de l’IBAN : vous avez toujours des espèces sur vous ? je peux te faire un chèque…
régler un taxi, non équipé d’un lecteur carte…
régler un achat entre particuliers (e.g. voiture d’occasion) : mais si vous préférez le chèque de banque…
le coût :
face à la carte, la différence ne se fait pas sur le plan de la facilité d’utilisation ; la garantie de paiement de la carte suffit aussi dans de nombreux cas, lorsque la disponibilité immédiate des fonds n’est pas indispensable ; la comparaison se joue plutôt sur le terrain des coûts / de la politique commerciale des acteurs
de même, côté entreprises, hormis les cas de disponibilité immédiate des fonds, le recours à l’Instant Payment reste largement conditionné par le coût d’opération.
Le point de vue des Entreprises mérite un complément, notamment au regard des volumes qu’elles représentent :
la fluidité côté Entreprises s’exprime aussi dans l’accélération et la rationalisation des processus :
l’accélération du règlement (disponibilité immédiate des fonds) permet d’enclencher plus rapidement l’expédition, voire même de manière automatisée, en exploitant l’acquittement positif (confirmant la bonne fin de l’Instant Payment) ;
l’unité de temps, enchaînant commande et règlement, jusqu’à son acquittement explicite, évite également les reprises de dossiers, avec leur charge et risque d’erreur ;
les réflexions en cours (inspirées de l’expérience britannique) sur un SCT Faster, non plus de l’ordre de quelques secondes, mais de quelques heures, élargissent le champ de réponse à cette recherche de fluidité et d’accélération ; et même si elles sortent du cadre strict de l’Instant Payment, elles démontrent :
le potentiel de transformation d’une partie du volume d’opérations traitées en batch actuellement vers un traitement individualisé au format SCT Int ;
l’intérêt en matière de mutualisation des infrastructures et l’impact correspondant sur les coûts ;
l’évolution de la fluidité, du traitement par lots vers des transactions unitaires quasi instantanées.
A en juger par la dynamique des acteurs dans les différents états membres, l’ambition du régulateur européen est bien en train de se concrétiser : l’élargissement de l’offre de services aux clients, particuliers et entreprises…
Et la réglementation ne date que de quelques mois : nous n’en sommes qu’au début !
[br]L’activité PMO-PPM de coordination des transformations dans l’entreprise est elle-même en pleine mutation. Il est nécessaire de faire un pas de côté pour se rendre compte des changements en cours qui la place progressivement au centre de l’échiquier des décisions prises de toutes parts dans l’organisation.
Comment sont redéfinies les relations du PMO-PPM ?
Comment sont redéfinies les relations du PMO-PPM en aval, pour développer plus d’impact sur les projets et en amont pour contribuer aux prises de décisions stratégiques ?
[br]Les missions et responsabilités des équipes PMO-PPM évoluent plus vite dans leur définition que dans leur mise en œuvre. Il y a encore peu, la direction générale se tournait uniquement vers ses directeurs métiers pour gouverner ses investissements. Puis, pour objectiver les remontées des projets stratégiques, elle a missionné son bureau PMO de consolider les informations pour éclairer ses décisions au regard de la progression de ce portefeuille de projets. Maintenant, que l’équipe appelée PMO Centrale, PMO portefeuille Stratégique, ou encore PMO Transformations a pris place dans la plupart des organisations, les attentes ne cessent de grandir vis-à-vis de ce tiers aux côtés de la direction générale.
[br]Plus elle démontre sa capacité à optimiser les décisions d’investissement à mesure que les données augmentent, plus les décideurs se tournent vers elle pour étayer leurs décisions (sélection, priorités, ressources, risques, calendrier de mise en service et niveau qualité de service).
[br]Progressivement, les nouvelles attentes qui lui sont adressées touchent à l’optimisation de la concrétisation des bénéfices liés aux investissements engagés. Sur ces aspects, les responsables PMO avaient pris l’habitude de limiter leur attention à la durée de vie des projets sous leur surveillance.
[br]Désormais pour répondre aux attentes, il faut étendre la vigilance jusqu’au terme de l’atteinte des bénéfices annoncés à l’origine du projet et actualisés par les sponsors. De fait il incombe à cette équipe de définir son processus de « Gestion de la Réalisation des Bénéfices » et d’en animer les activités en interaction avec toutes les parties prenantes en mesure d’influencer la concrétisation des bénéfices de l’entreprise issus de ses projets. Pour ce faire, la nature de ses relations avec ses interlocuteurs (projets, sponsors, directions, etc.) évolue pour satisfaire à ces nouvelles exigences sur les plans stratégiques, tactiques et opérationnelles.
Au côté de la direction générale, le PMO PPM devient un animateur de la stratégie établie en COMEX en préparant les décisions d’engagement et le suivi pour garantir l’alignement des travaux avec la stratégie de l’entreprise. C’est ainsi que l’enregistrement des annonces de bénéfices, de leurs révisions et de leur concrétisation sont dévolus à l’équipe centrale au cœur de cette chaîne de valeur des investissements. Ainsi, les restitutions faites aux dirigeants, de la performance du portefeuille des projets évolue pour devenir celle de l’alignement de l’ensemble avec la stratégie d’entreprise et ses révisions périodiques.
Au côté des métiers et sponsors, les membres du PMO assistent les interlocuteurs métiers pour documenter les hypothèses de décision d’engagement et ensuite pour les mettre à jour, chaque fois que nécessaire, tout en justifiant du maintien de l’alignement stratégique. Ce partenariat implique pour les Sponsors d’actualiser les données projets et les hypothèses jusqu’à la réalisation effective des bénéfices. En retours, l’équipe PMO assiste les métiers sur les décisions opérées au fil de l’eau les changements nécessaires à l’aboutissement des projets.
Au côté des directeurs de programme, chefs de projet et chefs de produit, l’équipe PMO-PPM apporte toute l’aide nécessaire pour garantir la cohérence des livrables avec les bénéfices annoncés, quitte à les réviser lorsque les événements ou le contexte les remettent en cause. Elle veille à éviter, ou du moins à atténuer, l’occurrence des 3 principales causes d’échec des projets — à savoir un changement dans les priorités organisationnelles, un changement dans les objectifs du projet et une collecte d’exigences erronées — en privilégiant l’adaptation à la planification absolue.
Comment tirer parti des supports existants, et notamment l’instruction des Business Cases et leur suivi dans le temps ?
Si depuis une dizaine d’année les Business Cases ont trouvé leur place dans la liste des livrables des méthodes de gestion de projets, leur usage après la fin du projet est resté limité. Dans beaucoup de cas, il est réservé à servir de pivot de l’engagement des projets en rassemblant hypothèses, estimations financières, identification des risques et adhérences inévitables. Mais, la finalité du business case est pourtant essentielle dans le temps. La perspective de progresser sur la gestion de la réalisation des bénéfices, implique de remettre en cause ce document à chaque étape de révision des engagements. Le Business Case devient ainsi le support indispensable de l’arbitrage de la réussite des investissements engagés et ce jusqu’au constat factuel des bénéfices générés (fussent-ils obtenus bien après la fin du projet).
[br]Au-delà des bénéfices visés et de leurs variations dans le temps c’est aussi le Business Case qui trace les opportunités, les menaces et les inconvénients dus aux effets de bords issus de projets connexes et autres événements inopinés (Ceux-ci pouvant nécessiter des dépenses supplémentaires de réduction des inconvénients constatés).
[br]En plus de ce changement d’échelle de temps, l’existence du Business Cases autorise aussi un regard transversal lors des revues du registre des bénéfices des projets inscrits au portefeuille. Pour ce faire, l’équipe PMO-PPM analyse les effets croisés que ces documents peuvent révéler sous formes d’opportunités mais aussi de risques susceptibles de compromettre la confiance dans l’accès aux bénéfices. Pour ce faire, le traitement des écueils (ex. les biais dans les estimations, les bénéfices comptés plus d’une fois, dégradation des prévisions) entre les Business cases des projets, sont des occasions pour les décideurs de prendre acte de leurs variations pour agir en conséquence au plus tôt.
Quelles sont les capacités nouvelles dont l’équipe PMO doit se doter ?
Enfin quelles sont les capacités nouvelles dont l’équipe PMO doit se doter pour devenir le gardien des promesses de résultats et de la pertinence des investissements accordés par la direction ? Et ce même longtemps après la fin des projets toujours au service de la stratégie mise à jour.
[br]Les projets pilotés avec le prisme de la Triple contrainte (Coût – Qualité – Délais) ne satisfont plus unanimement aujourd’hui. Cela amène à mesurer leurs succès ou leurs échecs à partir d’autres indicateurs qui ne dépendent plus des projets eux-mêmes, comme le « ROI » par exemple. Il en vient à être remplacé par le « TCO » (Total Cost of Ownership) attaché à la valeur d’usage des applications, services et capacités de l’organisation. Pour aller toujours plus dans le sens de la valeur, l’équipe PPM-PMO peut construire avec les chefs de projets/produits leur cadre de travail (avec une démarche « OKR » par exemple) permettant de définir des indicateurs au plus près des produits ou services à délivrer, appuyée sur une logique d’évolution permanente des pratiques.
[br]Ainsi le pilotage change de perspective à plusieurs registres :
Le pilotage par la « valeur » remplace le pilotage « par le budget »
« L’adaptation » avec des itérations aux résultats rapides remplace « l’anticipation » (associée à la planification et au contrôle)
Les « bénéfices obtenus » par les clients (ou les utilisateurs) remplace la « réussite des projets » réduite au respect du prisme cité plus tôt.
[br]Parmi les nouvelles compétences que le bureau PMO doit mettre en œuvre, figure l’orientation de ses activités au service des parties prenantes de la stratégie.
Il lui faut se défaire de son image bureaucratique qui lui colle pour valoriser les informations qui convergent vers son équipe.
Il doit développer son écoute des métiers afin d’être reconnu non plus seulement pour ses qualités de coordination mais pour celles de dialogue et de mise en relations aux carrefours des transformations de l’entreprise.
De fait ses mots-clés changent pour de nouveaux tels que : « capacités », « résultats », « bénéfices ».
Enfin, il développe des compétences utiles à l’adaptation du contenu de la stratégie, des priorités et des arbitrages dans son portefeuille pour assurer aux sponsors et à la direction générale une conduite optimum des transformations de l’entreprise.
[br]C’est ainsi que le PMO-PPM en lien avec son époque accompagne les acteurs de l’organisation pour satisfaire plus encore la stratégie avec des produits et services en cohérence avec les besoins des clients pour générer les revenus qui nourrissent le développement de l’entreprise.
À l’occasion des Rencontres Annuelles du France Payments Forum le 3 mars, vous trouverez ci-après la conclusion de la table ronde – Etat des lieux de l’implémentation des API : Solutions et perspectives
La keynote d’introduction (par Ghela BOSKOVICH, Head of Europe, FDATA GLOBAL) avait pour but de tirer parti de l’expérience du Royaume-Uni dans le domaine de l’OpenBanking.
L’expérience Open-banking au Royaume-Uni
18 mois d’avance : premiers déploiements en test dès Janvier 2018
Les difficultés rencontrées :
Mobiliser les banques, dans un contexte où on leur impose des investissements sans retour économique ; cela a conduit à une position ferme d’obligation faite aux banques par la Competition & Markets Authority (CMA) en 2017 ;
Créer la confiance dans la réussite de l’initiative OpenBanking, pour attirer les investisseurs ; la gouvernance via l’OBIE (Open Banking Implementation Entity) et du « Trustee » répondent à cet enjeu « make sure things happen » ;
Définir des standards techniques partagés et les conditions de tests pour vérifier l’opérationnalité et les performances ; malgré cela, l’interprétation des standards reste un écueil…
Fluidifier leparcours client, qui a donné lieu en 2018 aux Customer Expérience Guidelines, ajoutées aux obligations des acteurs après les premiers retours d’expérience ;
Prendre en compte de la Directive Européenne DSP2, notamment sur l’Authentification Forte, qui reste actuellement la principale préoccupation, avec notamment la contrainte de réauthentification tous les 90 jours…
La situation en France
La Table Ronde a été constituée de manière à rassembler les différents points de vue :
Modérateur : Ludovic VATHELOT, TREEZOR et animateur du GT RED du France Payments Forum
Depuis Décembre (cf. Table Ronde que nous avions organisée sur le même sujet), les participants constatent un net progrès sur l’accès / agrégation de comptes :
Le régulateur a créé les conditions d’un échange constructif entre Banques et TPP pour établir une liste détaillée des points d’achoppement et en engager le traitement ; les instances CNPS (Comité National des Paiements) et AFEPAME (Association des Etablissements de Paiement) contribuent largement à cette convergence ;
Concrètement, l’ACPR fait le bilan d’une accélération des tests entre Banques et TPP : alors que 25% des API étaient en test en décembre, ce taux est passé à 70% en janvier : des couples Banque /-TPP se sont constitués pour des « Canary Tests », comparant les résultats entre Web Scraping et API … révélant bien sûr des écarts à traiter ;
Il reste donc encore du chemin à parcourir pour se mettre en conformité avec la Directive / les RTS ; on retrouve les mêmes difficultés que le Royaume-Uni :
Différentes interprétations du standard (STET), notamment sur les cartes à débit différé, les dates optionnelles…
Mise en œuvre de l’authentification forte (mode redirect, App-to-App),
Parcours utilisateur laborieux et surtout hétérogènes, difficilement acceptables dans une application d’agrégation multi-banque…
Quant à l’Initiation de Paiement, elle subit le retard au niveau de l’Agrégation : elle progresse à partir d’expérimentations locales, comme le pilote entre BPCE / Natixis Payment Solutions et System U.
Duo gagnant : initiation de paiement + instant payment
La voix des commerçants, portée par Jean-Michel CHANAVAS, déplace l’enjeu, au-delà de l’Initiation de Paiement vers l’instantanéité, rendue possible par sa combinaison avec l’Instant Payment : « on veut que se développe le Paiement Instantané ! ».
Pour avancer …
Les prochaines étapes à franchir :
Finaliser la mise en conformité avec les RTS, avec la disponibilité et performance attendues pour l’accès au compte
Et pourquoi pas publier les statistiques de montée en charge (trafic, disponibilité, performance des API), pour créer la confiance (et l’émulation), comme le fait l’OBIE en Grande-Bretagne ?
Résorber les différences d’interprétation du standard STET, sur les dates, les cartes…
Dégager les meilleurs parcours utilisateur pour l’authentification (en cours au sein de l’AFEPAME) : In-App, SMS, Universal Link…
Reconsidérer l’obligation de réauthentification tous les 90 jours : le régulateur a engagé des discussions sur le sujet…
Et plus particulièrement pour l’Initiation de Paiement :
Intégrer l’ajout d’IBAN bénéficiaire
Revoir les parcours, a minima pour remplacer les parcours hors ligne (sur plusieurs jours !)
Tirer parti des opportunités de combinaison avec l’Instant Payment !
Tout cela sous la menace d’une concurrence internationale et d’acteurs majeurs, qui sauront exploiter leur position pour apporter des expériences utilisateurs fluides dans un modèle simplifié de « closed loop »…
