L'approche moderne pour harmoniser les activités, l'informatique et l'innovation20 lecture minimale

Comment les organisations peuvent transformer leurs besoins métier en meilleures décisions, en portefeuilles plus solides et en changements plus fructueux

Depuis des décennies, la relation entre les métiers et l'informatique constitue un défi récurrent pour la direction. Le métier identifie des opportunités, rencontre des problèmes opérationnels et souhaite évoluer. Le service informatique est chargé de traduire ces besoins en systèmes, données, plateformes et évolutions techniques, tout en veillant à la protection de l’architecture, à la sécurité, à la continuité et à la gestion d’un environnement technologique de plus en plus complexe. Les deux parties s’efforcent de créer de la valeur, mais elles abordent souvent une même initiative à partir de points de départ très différents.

Ce schéma est courant dans presque toutes les grandes entreprises. Une équipe est confrontée à un problème ou identifie une opportunité. Peut-être que les collaborateurs passent trop de temps à rechercher des informations, qu’un processus est inefficace, que les attentes des clients évoluent ou qu’une nouvelle technologie ouvre des possibilités qui n’existaient pas auparavant. Après quelques discussions, la demande métier contient souvent déjà la solution : « nous avons besoin d’un tableau de bord », « nous avons besoin d’une nouvelle application », « nous devrions automatiser ce processus », « nous avons besoin d’un agent IA ». Au moment où le service informatique intervient, la discussion ne porte plus uniquement sur le problème métier initial. Elle s’est déjà orientée vers la mise en œuvre.

Le service informatique commence alors à poser des questions. Que doit faire exactement la solution ? Qui l’utilisera ? Quels sont les systèmes et les sources de données concernés ? Quelles sont les implications en matière de sécurité ? Qui est responsable du processus ? Quelle est la valeur métier attendue ? Quelle est l’importance de cette demande par rapport aux autres initiatives déjà prévues dans la feuille de route ? Du point de vue métier, ces questions peuvent être perçues comme des freins. Le problème était évident, la solution souhaitée semblait logique, et soudain, les progrès semblent ralentir. Du point de vue informatique, cependant, la même situation apparaît sous un jour complètement différent. Une solution privilégiée a été proposée alors que certaines des hypothèses les plus fondamentales restent encore en suspens.

Aucune des deux parties n'a nécessairement tort. Le problème plus profond réside dans le fait que de nombreuses organisations tentent encore de passer trop rapidement de la demande métier à la mise en œuvre, en particulier lorsque le changement sous-jacent est nouveau, incertain ou dépasse les frontières organisationnelles. L’incertitude qui aurait dû être réduite plus tôt se répercute sur la planification du portefeuille et, à terme, sur la mise en œuvre. Une fois ce stade atteint, l’apprentissage a toujours lieu, mais il intervient au cours de la phase la plus coûteuse du processus.

C'est là que l'innovation peut jouer un rôle bien plus utile que celui qui lui est traditionnellement attribué.

L'innovation ne doit pas devenir un maillon supplémentaire dans la chaîne d'approbation entre les métiers et l'informatique. Elle ne doit pas s'approprier la conduite du changement métier et ne doit surtout pas devenir la porte d'entrée obligatoire pour toute nouvelle demande. Son rôle est plus précis : aider l'organisation à réduire l'incertitude avant que des ressources importantes ne soient engagées dans la mise en œuvre.

Cela modifie considérablement le débat traditionnel entre les services métier et l'informatique. La question n'est plus seulement de savoir si le service informatique est capable de mettre en œuvre ce que les services métier demandent. L'entreprise doit d'abord déterminer si elle comprend suffisamment bien le problème, si l'orientation proposée présente un intérêt suffisant et s'il existe de meilleures alternatives qui mériteraient d'être envisagées.

Le modèle traditionnel alliant affaires et informatique n'est pas défaillant

On serait tenté de présenter l'alignement entre les métiers et l'informatique comme un problème nécessitant un modèle opérationnel entièrement nouveau. En réalité, le modèle traditionnel fonctionne parfaitement bien pour une grande partie des changements organisationnels.

Un besoin métier est identifié, la demande est discutée avec le service informatique, les exigences techniques et fonctionnelles sont définies, le projet est intégré à un portefeuille et les priorités sont établies. Dès que des capacités sont disponibles, le changement est mis en œuvre. Pour les demandes prévisibles, cette approche est à la fois efficace et judicieuse. Si un service a besoin d’un nouveau rapport basé sur un modèle de données existant, si un workflow établi nécessite une légère modification ou si une application connue doit être dotée d’une fonctionnalité supplémentaire, une analyse approfondie n’apporterait que très peu de valeur ajoutée.

Le problème survient lorsque les organisations empruntent la même voie pour mettre en œuvre des changements de nature fondamentalement différente.

Une nouvelle proposition commerciale, l’introduction de l’IA dans un processus à forte intensité de connaissances, un changement opérationnel transversaux ou un nouveau service numérique peuvent, à terme, nécessiter des logiciels, mais il ne s’agit pas avant tout de questions liées aux logiciels. Ces projets impliquent des personnes, des processus, des hypothèses de valeur, une appropriation organisationnelle et, souvent, plusieurs pistes de solution plausibles. Les traiter comme des versions à plus grande échelle de demandes informatiques classiques engendre un problème prévisible : l’incertitude qui subsiste ne disparaît pas lorsque l’initiative est intégrée au portefeuille.

Cela évolue tout simplement au gré du projet.

C'est pourquoi les organisations peuvent disposer d'une gestion de portefeuille de plus en plus professionnelle tout en étant confrontées à des modifications de périmètre, à des projets au point mort, à la résistance des parties prenantes et à des résultats commerciaux décevants. Le processus de planification s'est peut-être amélioré, mais la qualité et la maturité des demandes reçues n'ont pas évolué au même rythme.

Cette distinction est importante. Une meilleure gestion de portefeuille aide une organisation à décider quoi faire et quand le faire. Elle ne peut toutefois pas, à elle seule, garantir que chaque initiative intégrée à ce portefeuille soit suffisamment bien comprise.

Le point de vue des entreprises : agir rapidement est une décision rationnelle

Du point de vue de l'entreprise, la rapidité n'est pas une exigence déraisonnable. Les responsables sont tenus de produire des résultats et leurs équipes sont souvent confrontées à ce problème au quotidien. Si les collaborateurs doivent regrouper manuellement des informations provenant de plusieurs systèmes, si les clients attendent trop longtemps ou si un processus engendre des coûts qui pourraient être évités, la pression pour y remédier est tout à fait compréhensible.

Ce sont naturellement les personnes les plus proches du problème qui trouvent des idées pour y remédier. Cette expertise est précieuse. L’erreur ne réside pas dans le fait que les équipes métier aient des opinions sur ce qu’il faudrait développer. L’erreur consiste à supposer que le simple fait de comprendre les difficultés opérationnelles signifie automatiquement que l’on connaît déjà la meilleure solution.

Les êtres humains passent rapidement d'un problème à une solution.

Imaginez une entreprise où les collaborateurs ont du mal à accéder aux informations dont ils ont besoin. Après plusieurs échanges en interne, le besoin s’énonce ainsi : « Nous avons besoin d’un tableau de bord. » Cela semble raisonnable et pourrait bien être, à terme, la bonne solution. Mais une analyse approfondie pourrait révéler que le véritable problème réside dans une saisie des données incohérente, une responsabilité floue quant aux informations, l’utilisation de définitions de processus différentes par plusieurs services, ou encore le fait que certaines données ne soient tout simplement pas collectées au bon moment.

Dans ce cas de figure, un tableau de bord d'une grande qualité technique permettrait de mettre en évidence un problème d'information sous-jacent, sans pour autant le résoudre.

Cet effet est devenu encore plus manifeste avec l’IA. Aujourd’hui, l’expression “ nous avons besoin d’un agent IA ” peut apparaître très tôt dans les discussions portant sur la productivité, la gestion des connaissances ou le service client. L’IA peut certes faire partie de la solution finale, mais un agent IA reste une réponse à une question. Ce n’est pas la question elle-même.

Les technologies modernes rendent les solutions de plus en plus accessibles, ce qui est positif, mais elles facilitent également le risque de négliger l'identification des problèmes. Plus l'obstacle perçu à la mise en œuvre d'une technologie diminue, plus les organisations doivent faire preuve de rigueur pour déterminer dans quels domaines la technologie apporte réellement de la valeur.

Le point de vue informatique : chaque requête est en concurrence au sein d'un système plus vaste

Le service informatique adopte une approche fondamentalement différente. Alors qu'un responsable opérationnel peut se concentrer sur un problème particulier, le service informatique examine les conséquences globales de dizaines, voire de centaines de demandes.

Toute nouvelle solution peut avoir des répercussions sur l’architecture, la gestion des identités, les intégrations, les données, la cybersécurité, la confidentialité, les fournisseurs, l’infrastructure, les modèles d’assistance et la maintenance à long terme. Même les solutions apparemment mineures entraînent des obligations futures. Les applications doivent être mises à jour, les interfaces doivent être surveillées, les accès doivent être gérés et les données doivent être protégées. Ce qui semble n’être qu’un simple projet du point de vue métier devient en réalité un élément permanent du paysage technologique.

Le service informatique fonctionne lui aussi dans un contexte de ressources limitées. Les capacités de développement sont restreintes. Les architectes, les experts en sécurité et les spécialistes des données sont peu nombreux. L'organisation doit continuer à assurer la maintenance de ses systèmes existants, tandis que les obligations réglementaires, de sécurité et d'infrastructure perdurent, quel que soit le nombre de nouveaux projets en cours d'élaboration.

C'est pourquoi l'affirmation selon laquelle « ce projet est extrêmement important pour notre service » ne suffit pas pour prendre une décision relative au portefeuille. La véritable question qui se pose pour les services informatiques et la gestion du portefeuille est de savoir si cette initiative est suffisamment importante pour mobiliser des ressources limitées par rapport à toutes les autres actions que l'organisation pourrait mener.

Ce n'est pas de la résistance à l'innovation. C'est de la gestion de portefeuille.

Les organisations informatiques matures investissent donc massivement dans des feuilles de route, des mécanismes de hiérarchisation des priorités, des dialogues sur le portefeuille et une responsabilisation métier plus claire. Il s’agit là d’améliorations importantes. Mais même le meilleur processus de gestion de portefeuille dépend d’un élément qui le précède : la qualité des initiatives qu’il est appelé à hiérarchiser.

Une demande peu claire ne devient pas plus claire simplement parce qu'elle figure dans une feuille de route sur dix-huit mois.

Cela nous amène à un principe particulièrement important concernant la relation entre l'innovation et les technologies de l'information :

Le service informatique devrait être informé dès le début, sans pour autant qu'on lui demande de s'engager trop tôt.

Le service informatique tire profit du fait de savoir qu’une initiative est en cours d’élaboration. Cette visibilité précoce permet de mettre en évidence les conséquences potentielles sur l’architecture, les dépendances, les problèmes de sécurité et les besoins futurs en matière de capacité. Elle donne aux équipes techniques le temps d’anticiper ce qui pourrait se présenter. Cependant, cette prise de connaissance ne doit pas automatiquement signifier que des ressources informatiques sont engagées ou qu’une initiative a été effectivement approuvée avant que l’analyse de rentabilité et l’orientation de la solution ne soient suffisamment abouties.

Distinguer la visibilité précoce de l'engagement précoce apporte un avantage précieux aux deux parties. Les équipes commerciales et d'innovation peuvent continuer à acquérir des connaissances sans faire de fausses promesses, tandis que le service informatique n'est pas pris au dépourvu par des initiatives d'envergure une fois que des décisions importantes ont déjà été prises.

L'innovation, une compétence qui fait défaut en amont

L'innovation est encore souvent associée aux ateliers de réflexion, aux campagnes d'idées, aux laboratoires d'innovation et aux technologies émergentes. Ces activités peuvent toutes avoir leur utilité, mais elles risquent de masquer une capacité plus fondamentale.

L'innovation offre aux organisations des moyens de faire face à l'incertitude.

Cela implique d'identifier les problèmes avant de définir des solutions, d'impliquer les parties prenantes avant la mise en œuvre, d'étudier les alternatives avant de s'engager dans une voie, de tester les hypothèses avant de les déployer à grande échelle et d'abandonner les initiatives avant qu'elles ne deviennent trop coûteuses si leur valeur sous-jacente s'avère insuffisante.

Sous cet angle, l'innovation n'est pas une alternative aux activités commerciales ou à l'informatique. C'est une capacité qui aide ces deux domaines à fonctionner plus efficacement.

L'entreprise reste responsable de l'identification du problème, de la valeur attendue et du changement organisationnel. Le service informatique reste quant à lui responsable de la faisabilité technique, de l'architecture, de la sécurité, de l'intégration et de la maintenabilité. L'innovation contribue à fournir les éléments concrets et la clarté nécessaires pour que ces responsabilités s'articulent plus tôt et plus efficacement.

C'est également pour cette raison que le service chargé de l'innovation ne doit pas chercher à s'approprier chaque nouvelle initiative. Si chaque demande doit passer par ce service, l'organisation ne fait que créer un nouveau goulot d'étranglement. Le travail courant doit rester courant. La valeur de l'innovation est maximale lorsque le degré d'incertitude est suffisamment élevé pour qu'une mise en œuvre immédiate entraîne des risques évitables.

La question pratique ne se pose donc plus ainsi : « S'agit-il officiellement d'une innovation ? », mais prend une tournure plus utile :

En savons-nous suffisamment pour nous engager de manière responsable dans la mise en œuvre ?

Cette question est beaucoup plus facile à mettre en pratique.

Trois itinéraires au lieu d'un seul

Un modèle moderne de gestion, d'informatique et d'innovation n'a pas besoin d'être compliqué. Dans la pratique, on peut considérer que les questions métier qui se posent s'inscrivent dans l'une des trois grandes catégories suivantes.

La première voie est celle de la mise en œuvre classique. Le problème est suffisamment clair, la solution est bien connue, le degré d’incertitude est faible et la responsabilité est clairement définie. Ces initiatives doivent se poursuivre dans le cadre du processus habituel de gestion des activités et du portefeuille informatique. L’innovation n’apporte pas grand-chose à ce stade.

La deuxième voie est celle de l'innovation pure et simple. L'organisation entreprend délibérément une initiative véritablement novatrice, comme le lancement d'un nouveau service, la mise en œuvre d'une nouvelle technologie, la conquête d'un nouveau marché ou l'adoption d'une méthode de travail fondamentalement différente. Dans ce contexte, une approche structurée de la découverte s'avère précieuse, car les hypothèses relatives à l'attrait, à la faisabilité et à la valeur du projet doivent encore être validées.

La troisième voie est la plus intéressante, car elle passe souvent inaperçue : le changement incertain ou complexe. Il se peut que cette initiative ne soit pas du tout qualifiée d’innovation. La technologie existe peut-être déjà. Elle peut même ressembler à une amélioration relativement banale. Mais si le problème réel reste flou, si plusieurs parties prenantes sont impliquées, si l’argumentaire de valeur est faible, si le changement organisationnel est important ou s’il existe plusieurs solutions plausibles, cette initiative peut tout de même bénéficier des mêmes méthodes d’innovation.

L'étiquette importe moins que l'incertitude.

Il s'agit là d'un changement important, car de nombreuses organisations passent trop de temps à se demander si un projet relève du service informatique, de l'innovation, du numérique, de la transformation ou d'un autre service. La question qu'il convient plutôt de se poser est la suivante : quels enseignements doivent encore être tirés avant que l'initiative ne soit prête à être mise en œuvre ?.

Commencez par un processus de collecte d'idées innovantes, et non par un projet d'innovation

Cela ne nécessite pas de mécanisme de gouvernance lourd. Un processus court de collecte des idées innovantes permet souvent d'obtenir suffisamment d'informations pour déterminer la bonne voie à suivre.

La phase d'analyse initiale doit remettre en question un certain nombre d'hypothèses fondamentales. Le problème est-il réellement bien compris ? L'initiative est-elle véritablement nouvelle pour l'organisation ? Combien de parties prenantes, d'équipes ou d'unités opérationnelles sont concernées ? Quel est le degré d'incertitude qui subsiste ? Existe-t-il plusieurs solutions plausibles pour résoudre le problème ? Y a-t-il un responsable métier clairement identifié, prêt à assumer la responsabilité du changement ?

Avant tout, la sélection doit permettre plusieurs issues.

Une demande peut s'avérer suffisamment claire et suivre simplement le processus habituel de gestion de portefeuille. Il peut apparaître clairement que le problème métier est trop mineur ou que la valeur attendue est trop limitée, auquel cas il est judicieux d'y mettre un terme. Il se peut également qu'il subsiste suffisamment d'incertitudes pour justifier un court sprint d'innovation.

Cette capacité à s'arrêter de travailler plus tôt est un signe important de maturité.

Les organisations célèbrent souvent les projets menés à bien, mais calculent rarement la valeur créée par ceux qui ont été interrompus à temps, avant que des ressources limitées ne soient gaspillées. Or, empêcher une initiative à faible valeur ajoutée d'accaparer pendant des mois les capacités opérationnelles et informatiques peut générer davantage de valeur que de précipiter le développement d’un autre projet.

L'innovation ne devrait donc pas être évaluée uniquement en fonction du nombre d'idées qui aboutissent finalement à la création de projets.

Parfois, sa plus grande contribution consiste à apporter suffisamment de clarté pour décider qu'un projet ne doit pas voir le jour.

Comment se déroule un sprint d'innovation ?

Lorsqu'une exploration plus approfondie s'avère justifiée, il n'est pas nécessaire qu'elle prenne la forme d'un programme de recherche de longue haleine. Un « sprint » ciblé d'environ quatre à six semaines permet généralement d'y voir beaucoup plus clair.

La première phase se concentre délibérément sur le problème plutôt que sur la solution proposée. L'équipe désigne le responsable du projet, identifie les parties prenantes concernées et mène des entretiens avec les personnes touchées par le problème. Les hypothèses sont remises en question et l'objectif opérationnel visé devient plus clair. C'est souvent à ce stade que la formulation initiale du problème commence à évoluer.

Dans le cadre de notre collaboration avec des équipes d’innovation, nous constatons régulièrement que des initiatives entament la phase d’exploration avec un problème qui semble évident, pour en ressortir avec une compréhension nettement différente de ce qu’il faut réellement résoudre. Cela ne signifie pas que les personnes à l’origine de la demande initiale avaient tort. Cela signifie simplement que l’organisation a tiré des enseignements avant de prendre des décisions coûteuses.

Une fois que le problème est suffisamment clarifié, le processus élargit délibérément l’éventail des solutions possibles. Plutôt que d’améliorer la première idée proposée par l’entreprise, les équipes génèrent plusieurs possibilités. Ces possibilités peuvent concerner la technologie, la refonte des processus, des changements organisationnels, de nouveaux services ou une combinaison de ces quatre éléments. L’objectif n’est pas de générer des idées pour le simple plaisir de la créativité. Il s’agit d’empêcher l’organisation d’investir des ressources importantes dans la première solution qui semblait plausible.

Les idées les plus pertinentes sont ensuite sélectionnées et validées. Les utilisateurs, les experts, les parties prenantes de l'entreprise et, le cas échéant, les spécialistes informatiques peuvent remettre en question les hypothèses relatives à la faisabilité, à l'intérêt et à l'impact attendu. L'éventail des solutions se réduit progressivement jusqu'à ce qu'il ne reste plus qu'un petit nombre d'orientations crédibles.

À la fin du sprint, le responsable métier ne devrait pas se voir présenter une seule recommandation sortie d’une « boîte noire ». L’organisation devrait être en mesure de comprendre les enseignements tirés, les alternatives envisagées, les éléments qui étayent les options retenues et les raisons pour lesquelles une orientation particulière mérite un investissement supplémentaire.

Cela constitue une base bien plus solide pour la prise de décision.

Le résultat doit être prêt à être intégré au portefeuille, et non pas approuvé automatiquement.

Une erreur courante consiste à penser qu’une phase de découverte réussie doit nécessairement aboutir à la mise en œuvre.

Cela ne devrait pas être le cas.

Le résultat de cette phase de découverte doit être une proposition prête à être intégrée au portefeuille, et non un projet automatique.

L'initiative permet désormais de décrire le problème avec plus de précision, d'identifier le responsable métier, d'expliquer la valeur attendue, d'indiquer quelles parties prenantes sont concernées, de mettre en évidence les dépendances et de préciser clairement l'orientation privilégiée pour la solution. Les implications potentielles en matière de TIC et les besoins en capacités devraient également être beaucoup plus visibles.

À ce stade, la gouvernance habituelle du portefeuille gagne en efficacité, car elle porte sur des initiatives plus abouties.

La question passe de « Que nous demande-t-on exactement de mettre en place ? » à « Est-ce suffisamment utile et important pour justifier que l'on y consacre des ressources dès maintenant ? »

Voilà ce qu'on appelle une véritable discussion sur le portefeuille.

Une initiative peut néanmoins ne pas être retenue lors de cette décision de hiérarchisation. Une autre initiative peut s'avérer plus urgente, plus utile ou nécessaire pour des raisons réglementaires. Les capacités nécessaires peuvent faire défaut. Le moment peut ne pas être opportun.

La procédure de communication des pièces ne supprime pas ces contraintes.

Cela garantit simplement que l'organisation prend ces décisions en s'appuyant sur des informations nettement plus fiables.

Il est d'autant plus important de définir clairement les responsabilités, et non l'inverse

L'introduction de l'innovation dans cette relation ne doit pas brouiller les responsabilités. Elle doit au contraire les rendre plus explicites.

L'entreprise reste chargée de définir le résultat souhaité, de s'approprier le problème métier, d'apporter son expertise dans le domaine concerné et d'assumer la responsabilité de la mise en œuvre et du changement organisationnel. La technologie peut permettre l'émergence d'une nouvelle façon de travailler, mais l'entreprise ne peut pas confier le changement proprement dit au service informatique.

L'innovation a pour rôle de faciliter la découverte, de remettre en question les idées reçues, d'impliquer les parties prenantes, d'élargir l'éventail des solutions possibles et de réduire l'incertitude. Son rôle est à la fois méthodologique et fédérateur. Elle doit permettre d'améliorer la qualité des décisions sans pour autant priver le responsable de la prise de décision finale.

Le service informatique reste responsable de l'aspect technologique. Cela inclut la faisabilité, l'architecture, la sécurité, les données, les intégrations, l'évolutivité, la facilité de maintenance et les implications pour l'environnement technologique dans son ensemble. Le service informatique doit être impliqué suffisamment tôt pour apporter ce point de vue sans pour autant se voir confier prématurément la responsabilité de la mise en œuvre d'une initiative qui est encore en cours de définition.

Enfin, la gouvernance du portefeuille a pour mission de déterminer où les ressources de l'organisation doivent être allouées. La valeur, la stratégie, les risques, le calendrier, les capacités et les interdépendances doivent en fin de compte être pris en compte à l'échelle de l'ensemble des initiatives plutôt qu'au sein d'un seul projet.

Les organisations modernes ne parviennent pas à améliorer la coordination en regroupant toutes ces responsabilités au sein d'une seule et même équipe.

Elles permettent d'améliorer la coordination en établissant plus tôt des liens entre des responsabilités distinctes.

Une meilleure identification des opportunités renforce la gestion de portefeuille

L'innovation et la gestion de portefeuille sont parfois considérées comme des disciplines distinctes. En réalité, elles apportent des réponses à différents aspects d'un même problème de gestion.

L'innovation consiste à se demander si une opportunité est suffisamment comprise et validée.

La gestion de portefeuille consiste à déterminer si l'organisation doit investir dans cette opportunité par rapport à toutes les autres possibilités.

L'absence de l'un des deux entraîne des faiblesses prévisibles.

Une organisation dotée de solides capacités d'innovation mais dont la gestion de portefeuille laisse à désirer peut générer de nombreuses opportunités validées, tout en manquant de la rigueur nécessaire pour faire un choix parmi celles-ci. Tout semble intéressant, trop de projets sont lancés et les ressources limitées sont dispersées entre un grand nombre d'initiatives.

Une organisation dotée d'une gouvernance de portefeuille solide mais dont le processus de découverte est défaillant peut être confrontée au problème inverse. Ses feuilles de route, ses réunions de gouvernance et ses plans de ressources peuvent être d'un grand professionnalisme, mais l'organisation continue de prendre des décisions concernant des initiatives dont la définition des problèmes et les hypothèses de valeur n'ont pas été suffisamment validées.

C'est le modèle le plus solide qui relie les deux.

L'innovation améliore la qualité des initiatives proposées. La gestion de portefeuille évite à l'organisation d'en mener trop de front.

Le changement commence avant la mise en œuvre

Il existe une autre raison pour laquelle la phase d'innovation peut améliorer considérablement les résultats : le changement organisationnel s'amorce plus tôt.

Dans de nombreux projets traditionnels, les utilisateurs ne sont fortement impliqués que lorsqu'une solution existe déjà. Ils sont invités à des séances de test, reçoivent des informations ou suivent une formation peu avant la mise en œuvre. À ce stade, les décisions importantes ont déjà été prises et toute résistance s'avère coûteuse.

La découverte modifie l'ordre des événements.

Les utilisateurs et les parties prenantes participent dès les premières étapes de l'analyse du problème. Ils apportent leur point de vue, remettent en question les hypothèses, proposent des idées et réagissent aux pistes de solution envisagées. Leur rôle ne se limite pas à accepter une solution élaborée ailleurs. Ils s'impliquent pleinement dans le processus par lequel l'organisation détermine les changements à apporter.

Cela présente des avantages concrets. Les résistances potentielles apparaissent plus tôt. Il est possible d’identifier les influenceurs informels et les futurs promoteurs du projet. Les différentes interprétations du problème sont mises en évidence avant qu’elles ne se transforment en conflits lors de la mise en œuvre. Les responsables commencent à s’approprier le projet alors que les options sont encore ouvertes.

Rien de tout cela ne rend superflue la gestion professionnelle du changement. Les changements organisationnels de grande envergure continueront de nécessiter une communication efficace, un leadership fort, des formations et une gestion active de l'adoption.

Mais la gestion du changement part d'une position nettement plus solide lorsque les personnes concernées par ce changement ont déjà participé à la définition de son orientation.

Comment se lancer sans remanier toute l'organisation ?

Les organisations n'ont pas besoin de mettre en place une nouvelle architecture de gouvernance avant de tester ce modèle.

Un bon point de départ consiste à se tourner vers le passé.

Prenez un échantillon d’initiatives récentes dans les domaines commercial et informatique, et examinez ce qui s’est réellement passé. Quelles demandes étaient claires dès le départ et ont été menées à bien sans surprise majeure ? Celles dont le périmètre a changé à plusieurs reprises ? À quel moment les parties prenantes se sont-elles manifestées trop tard ? Dans quels projets s’est-on rendu compte, au cours de l’exécution, que le véritable problème était tout autre ? À quel moment l’implication de l’entreprise s’est-elle affaiblie après le passage du projet aux mains de l’informatique ? Quelles initiatives ont mobilisé d’importantes ressources mais n’ont finalement eu qu’un impact limité sur l’activité ?

Cette analyse permet souvent de mettre rapidement en évidence des tendances.

Ces schémas peuvent ensuite être traduits en un petit nombre de questions permettant de définir le parcours à suivre pour les futures demandes. Les représentants des services opérationnels, les responsables de l’innovation et les gestionnaires de portefeuille informatique peuvent ainsi tester ensemble une procédure de prise en charge simplifiée, plutôt que de se lancer immédiatement dans la conception d’un processus d’entreprise formel.

Commencez par une ou deux initiatives où l'incertitude est réellement perceptible. Menez une phase d'exploration. Comparez ce que l'organisation comprenait avant et après ce processus. Examinez les changements intervenus dans la définition du problème, la valeur attendue, le paysage des parties prenantes, l'orientation de la solution, les dépendances et les implications en termes de capacités.

L'objectif n'est pas de démontrer que chaque projet nécessite de l'innovation.

L'objectif est presque tout le contraire.

Identifiez le groupe relativement restreint d'initiatives dans lesquelles l'apprentissage précoce permet d'éviter une incertitude qui, à terme, s'avérerait disproportionnellement coûteuse.

Si cela permet d'améliorer les décisions relatives au portefeuille et les résultats en matière de mise en œuvre, il devient alors beaucoup plus facile d'envisager de formaliser cette approche.

De « l'entreprise face à l'informatique » à « l'entreprise, l'informatique et l'innovation »

La tension entre les métiers et l'informatique ne disparaîtra jamais complètement, et ce n'est pas nécessairement un problème. Les métiers doivent privilégier la rapidité, les opportunités et les résultats. L'informatique doit quant à elle garantir la fiabilité, la cohérence, la sécurité et la pérennité à long terme. Les organisations saines ont besoin de ces deux forces.

Ce qui doit changer, c'est le lieu où l'incertitude est levée.

Lorsque des initiatives incertaines passent directement d’une demande métier à un engagement dans le portefeuille de projets, l’apprentissage s’opère au cours de la mise en œuvre. Le périmètre évolue, des dépendances apparaissent tardivement et la responsabilité peut devenir floue. On attend alors des équipes techniques qu’elles résolvent des problèmes qui relèvent en partie de l’organisation, tandis que les équipes métier s’impatientent car la livraison prend plus de temps que prévu.

L'innovation offre un moyen moderne de faire progresser cet apprentissage.

Ni en retirant des projets au service informatique. Ni en retirant la responsabilité aux services métier. Ni en créant une nouvelle étape de validation.

En aidant les deux parties à déterminer ce qu'elles savent réellement, ce qu'il leur reste à apprendre et si l'initiative est suffisamment aboutie pour justifier l'utilisation de ressources limitées.

Au fond, ce modèle est très simple.

L'entreprise est maître de la valeur et du changement. L'innovation réduit l'incertitude et génère des options validées. Le service informatique met en œuvre la technologie de manière responsable. La gestion de portefeuille détermine quand et où l'organisation mobilise ses ressources.

Lorsque ces compétences sont mises en œuvre dès le début, la conversation s'en trouve grandement enrichie.

La question de départ n'est plus simplement :

Est-ce qu'on peut le construire ?

On obtient alors :

S'agit-il du bon problème, y a-t-il suffisamment de potentiel pour agir, et comprenons-nous suffisamment bien cette opportunité pour y investir ?

C'est une question plus pertinente pour l'entreprise, une question plus pertinente pour le service informatique et, en fin de compte, un meilleur moyen de transformer l'innovation en résultats mesurables.

Réserver une démo pour découvrir comment Accept Mission peut vous aider dans la gestion de vos idées et dans vos processus de gestion de portefeuille de projets.