Dans un monde où les ruptures stratégiques, technologiques ou sanitaires s’accélèrent, les stratégies sont mises à rude épreuve. Ces stratégies intègrent de plus en plus de composantes digitales dans une logique où les business models ne sont plus « simplement » supportés par l’IT mais où c’est l’IT qui réinvente les business models. Aujourd’hui l’IT devient le business.

Imaginer et concevoir des innovations de valeur à fort contenu digital ne suffit plus car il est nécessaire d’organiser une mise en œuvre de l’IT à même de répondre avec flexibilité et rapidité aux enjeux tout en assurant sécurité et résilience des opérations IT. Dans ce contexte, il devient plus délicat de traduire ces nouvelles exigences du Run en capacités opérationnelles. Et sauf à vouloir se prendre les pieds dans le tapis , je ne recommande absolument pas de se « jeter » sur la construction d’organisations cibles avant d’avoir compris pour qui et comment ces organisations doivent créer et délivrer de la valeur.

Sur la base de mon expérience de conseil, j’ai ainsi souhaité partager dans ce billet une solution relativement élégante pour adresser cet enjeu. Il s’agit d’adapter le modèle opérationnel du Run en créant un modèle opérationnel cible (TOM) qui intègre les différents changements nécessaires au modèle existant afin de traduire les nouvelles exigences du Run en capacités opérationnelles. Ce billet aborde ainsi 3 points :

1. Qu’est ce qu’un modèle opérationnel et quels étaient jusqu’à présent les principaux modèles opérationnels pour les activités de Run ?
2. Quelles sont les principales tendances qui poussent à adapter le modèle opérationnel du Run ?
3. Quand et comment procéder pour adapter le modèle opérationnel du Run ? Quelles sont les nouvelles tendances en matière de modèles opérationnels du Run ?

1. Le modèle opérationnel du RUN

Un modèle opérationnel fait le pont entre stratégie et exécution et décrit comment l’organisation va créer et délivrer la valeur. On peut définir un modèle opérationnel à l’échelle d’une entreprise toute entière, d’une business unit ou même d’une fonction (ex. la DSI) ou encore une sous-fonction (ex. le Run de la DSI).
Comme il n’y a pas de définition vraiment standard, je vous propose 3 illustrations que j’ai adopté et qui permettent chacune d’aborder le modèle opérationnel sous un angle différent.

Illustration n°1 : si vous êtes familier avec le business model canvas de Alex Osterwalder et Yves Pigneur, on peut déjà considérer que le modèle opérationnel se positionne comme le back-end du business model en intégrant les activités clés, les ressources clés ainsi que les partenaires/partenariats clés.

Illustration n°2 : d’autres à l’instar de Andrew Campbell de l’université d’Ashbridge tentent de populariser l’operating model canvas en agençant avec plus de détails le back-end de l’illustration n°1

Ce qui est intéressant dans ce modèle, outre la mention des Locations (lieux géographiques d’exécution) et de Information (structures et flux d’information), c’est l’apparition des Value Delivery Chains censées traduire la logique des chaînes de valeur nécessaires au delivery des propositions de valeur. De mon point de vue, cette notion est fondamentale à tout modèle opérationnel.

Illustration n°3 : enfin, j’ai aussi dans mon attirail une autre façon de représenter les modèles opérationnels que j’ai peaufiné au fil du temps et à laquelle je tiens beaucoup.

Ce qui est intéressant dans ce modèle est la prise en compte de l’axe culture (organisation informelle et l’humain) qui rappelle que les opérations s’exécutent souvent sur la base d’habitudes de collaboration, de valeurs et de soft-skills spécifiques et ce indépendamment des structures organisationnelles et des processus. L’autre point fondamental est l’introduction de la gouvernance qui représente le système nerveux du modèle opérationnel et sa clé de voûte.

C’est donc en s’appuyant sur un certain nombre de modélisations que l’on se forge à la fois des convictions et des outils pour adapter les modèles opérationnels et plus spécifiquement dans ma pratique : les modèles opérationnels du Run.

Afin d’être plus spécifique et encore à titre d’illustration, je schématise ci-dessous les 2 modèles opérationnels du Run beaucoup rencontrés ces dernières années.

Le modèle des silos technologiques

L’organisation par silos technologiques n’a plus vraiment cours aujourd’hui car elle présente un certain nombre de challenges et inconvénients commentés dans l’illustration ci-dessus.

Le modèle PLAN-BUILD-RUN avec un RUN orienté par activité

Ce modèle opérationnel de Run intégré dans le modèle Plan-Build-Run de la DSI fait la part belle aux activités. Il organise en effet les opérations IT en usines qui regroupent les activités par niveaux d’interventions (N0 – Hébergement, N1 – Exploitation, N2 – Administration, N3 – Expertise) quelles que soient les technologies et métiers concernés. A l’instar des modèles déployés par les grands prestataires, ce modèle vise le plus souvent à industrialiser les opérations en déployant des processus standards ITIL. L’inconvénient majeur de ce modèle est de reléguer le Run en bout de chaîne, sclérosant ainsi toute la chaîne de delivery et ne favorisant ainsi pas l’agilité.

Certaines déclinaisons récentes de ce modèle tentent de fluidifier davantage la chaîne de Build pour conduire à des modèles un peu différents qui distinguent la gestion des socles techniques de celle des services.

Sur ces bases, on a pu voir se dessiner des modèles d’organisations détaillées ressemblants au schéma ci-dessous.

Alors disons le tout de suite, aucun de ces modèles n’est la panacée mais tous ont un intérêt pour exécuter les activités de Run. Il est donc important de capitaliser sur l’expérience des différents modèles et comprendre valeur et utilisation des briques de bases. C’est ainsi que l’on disposera de bonnes bases pour entamer une phase de réflexion et de conception quand il s’agira d’adapter le modèle opérationnel du Run aux nouveaux enjeux. Et justement comme nous allons le voir dans la prochaine section les raisons de changer sont multiples et souvent impérieuses.

2) Tendances d’évolution et d’adaptation des modèles opérationnels du RUN

Comme je le mentionnais en introduction, l’IT est aujourd’hui au coeur du business et les DSI doivent faire face (quand ce ne sont pas les Chief Digital Officer) à de nombreux impératifs pour rendre possible / faciliter la transformation du business et des métiers.

Au-delà de ces impératifs, s’ajoutent plus classiquement les demandes de réduction de coûts et des risques ainsi que le besoin de transparence accrue. Evidemment, et pour finir, on peut trouver les nombreuses tendances technologiques actuelles et à vernir et qui sont autant d’opportunités/leviers de transformation.

Ces impératifs pressurisent les modèles opérationnels en place et les tendances technologiques mettent le plus souvent en évidence l’impréparation et l’inadéquation des capacités d’IT Management. C’est donc sur ces bases que les organisations de type DSI doivent se réinventer en adoptant des modèles opérationnels plus adaptés.

3) Quand et comment adapter le modèle opérationnel du run ? quelles pistes d’évolution ?

Avant de s’engager dans un projet d’adaptation du modèle opérationnel du Run, il est nécessaire de bien cadrer les raisons qui poussent à changer et définir un tant soit peu les modalités du projet d’adaptation de TOM. Généralement cela passe par un cadrage stratégique permettant d’établir les éléments structurants du projet d’adaptation du modèle opérationnel :

• Objectifs du projet d’adaptation
• Évaluation des bénéfices attendus, impacts et facteurs de risques
• Définir les meilleures options organisationnelles pour mener le projet d’adaptation
• Éclairer la prise de décision

L’élément le plus important et difficile étant l’évaluation des bénéfices attendus et des impacts à anticiper. Sans révéler de secrets, c’est le plus souvent un timing particulier sous tendu par des forts enjeux / opportunités qui incite à se lancer dans l’adaptation d’un modèle opérationnel et ce principalement dans 4 situations types :

1. Vous démarrez quelque chose de totalement nouveau
2. Vous changez de stratégie
3. Vous avez des problèmes de performance
4. Vous mettez en oeuvre un changement majeur

Dans le contexte d’une DSI et des implications sur le Run, il peut s’agir de plusieurs structures qui fusionnent / se rapprochent avec chacune une organisation de Run; d’un programme structurant de modernisation IT, d’une globalisation des opérations IT pour delivrer des services IT à l’ensemble des pays d’une entreprise, ou encore d’une transformation agile de l’entreprise et/ou de la DSI.

Ensuite vient le travail à proprement parler sur la définition du TOM. La description détaillée d’une méthodologie ne rentre pas dans le cadre de ce billet mais néanmoins je recommande de toujours démarrer par la définition de la Value Chain Map ou chaîne de valeur permettant de délivrer la proposition de valeur attendue / en ligne avec la stratégie à exécuter. A titre d’illustration, ci-dessous la chaîne de valeur que l’on pourrait trouver dans une DSI classique

Cette étape, n’est pas facile car si – par exemple – on souhaitait redéfinir cette chaîne de valeur, il pourrait être difficile de choisir la meilleure manière de la segmenter l’offre de service et de définir l’enchaînement des différents macro-processus créateur de valeur. En général, il faudra choisir de segmenter les chaînes de valeur par type de clients internes/externes ou par besoin clients ou par pays ou par produits/services ou bien encore par technologies (l’exemple du modèle opérationnel par silos technologiques).

Dans tous les cas, il ne faut absolument pas jouer aux apprentis sorciers et improviser : une bonne dose d’analyse et de pragmatisme est nécessaire mais on peut aussi s’inspirer de tendances très actuelles (quoique peu documentées) dans la définition de modèles opérationnels adaptés aux enjeux décrits dans la section n°2.

Une piste qui me paraît intéressante étant de s’inspirer du standard IT4IT de l’Open Group qui propose un début de modèle opérationnel organisé autour d’une chaîne de valeur et de Value Streams spécifiques à L’IT à l’instar de certains domaines métiers qui ont développé des Value Streams maintenant connues comme : make-to-order, order-to-cash,…)

Ainsi le point de départ IT4IT se compose des Value Streams suivantes qui sont orientées besoins client et remplacent avantageusement la classique segmentation Plan, Build, Deliver, Run et sont de nature à casser un fonctionnement en silos peu propice à l’agilité. Ce découpage est d’ailleurs la clé pour évoluer vers un modèle où le Build est beaucoup moins prépondérant et est remplacé par une logique de Broker/Intégrateur/Orchestrateur.

Ce rôle de Broker/Integrateur/Orchestrateur sera principalement mis en oeuvre au travers des capabilities de la value stream « Request to Fulfill » qui seront en charge de cataloguer, mettre en oeuvre et suivre l’usage des différents services standards.

Les impacts de cette nouvelle « value chain » sur le Run sont structurants. Le Run ne sera plus isolé en bout de chaîne et participera aux autres value streams dans une logique de collaboration avec les autres parties prenantes. C’est cette logique d’agilité qui s’affranchit des frontières organisationnelles qui sera propice à la construction de modèles opérationnels Digital Ready intégrant nativement des mécanismes opérationnels comme DevOps et FinOps par exemple.

Une fois la colonne vertébrale de la value chain définie, on peut s’attaquer – sans dogmatisme – aux autres éléments (partenaires, géographies, modèle d’organisation ou capabilities map, culture,..) en fonction de leur importance dans la stratégie et des enjeux de valeur à délivrer.

En guise de conclusion

Voilà pour ce petit tour d’horizon de l’adaptation des modèles opérationnels DSI pour traduire les nouvelles exigences du Run en capacités opérationnelles. Pour conclure, il faut retenir que le modèle opérationnel n’est que le Blueprint de l’organisation cible et que cette logique s’inscrit dans une démarche plus globale de transformation

En attendant, de démarrer vos projets d’adaptation, vous pouvez toujours évaluer si votre modèle opérationnel (qu’il soit formellement défini ou pas) permet de délivrer la bonne valeur aux bons clients (internes ou externes).

La transformation des organisations est d’abord une question d’obtention de bénéfices

Professionnels de la transformation des entreprises, nous sommes amenés à intervenir pour accompagner nos clients dans la définition, le pilotage et la réalisation de leurs plans de transformation. Nous nous proposons dans une série d’articles à venir de vous faire découvrir comment tous les acteurs, tout au long de la chaîne de transformation, sont des acteurs de leur création de valeur.

Dans un contexte incertain, se concentrer sur l’essentiel

Historiquement les entreprises qui investissent dans des programmes et projets de transformation, définissent leurs réussites d’après leurs livrables et leurs tenues des engagements. Ce postulat centré sur la qualité des productions et des méthodes mises en œuvre ne correspond plus aux exigences de l’environnement actuel des entreprises. Celui-ci est de plus en plus volatile, incertain, complexe et ambigu, on dit qu’il est VUCA. Le fait est que la pertinence de l’activité économique des entreprises tient encore plus qu’avant de la cohérence de leur offre de produits et services à satisfaire les attentes de leurs clients. Ce sont donc les propositions et réponses faites aux clients qui déterminent l’avenir des organisations.

En ce sens, les projets et programmes doivent se définir et être jugés sur le niveau de bénéfices qu’ils permettent de réaliser par l’entreprise. Si la notion de valeur est souvent citée lorsque l’on évoque les nouveaux modèles de gestion de projets et d’organisation, c’est justement qu’elle représente l’unité élémentaire de la réalisation des bénéfices.

Les bénéfices : tout le monde en a une définition, suivant l’étape de la transformation

Avant de poursuivre, arrêtons-nous sur la notion de bénéfice. Dans l’entreprise sa définition est aussi variable que la définition de la « qualité », qui n’a cessé d’évoluer ces dernières décennies. Pour comprendre la difficulté à définir ce qu’est un bénéfice, il faut reprendre la métaphore des aveugles et de l’éléphant reprise par Henry Mintzberg (Safari en pays stratégie) :

Nous sommes des aveugles et la définition de la stratégie est notre éléphant. Puisqu’aucun de nous n’a une vision complète de la bête, chacun en perçoit une partie ou une autre et reste dans l’ignorance du reste.

Nous n’obtiendrons pas un éléphant en ajoutant les différentes parties. Un éléphant est plus que ça. Pour appréhender la totalité nous devons en comprendre les composants. C’est pour cela que nous vous proposons de vous partager notre vision commune de la réalisation des bénéfices, par rapport à 4 grands domaines d’expertise significatifs pour réussir une transformation.

Cadrage de la transformation (1/4)

L’élaboration du budget annuel des SI, la planification des projets (plan annuel), voire le « schéma directeur du SI » conduisent régulièrement l’entreprise à s’interroger sur les transformations à opérer et les montants à leur octroyer. Ces dernières années, ces opérations ont gagné en réalisme et sont devenues plus pragmatiques, plus opérationnelles : des projets aux résultats tangibles, sur des engagements à horizons de temps plus courts, avec des ressources allouées sur une base trimestrielle dans certains cas. La crise sanitaire n’a fait qu’accentuer ce trait en rendant les décisions plus incertaines et les budgets plus minces.

Quels bénéfices rechercher dans la situation actuelle : privilégier les pistes pour s’adapter rapidement ? Investir sur le Legacy comme garant de la pérennité du fonctionnement de l’entreprise ? Poursuivre l’investissement en R&D pour préparer la sortie de crise ? et comment ? sur quelles hypothèses ?

Ce que l’on peut faire de plus lors de ces opérations pour rendre la démarche plus efficace :

• Organiser la transformation comme un « véhicule du changement » pour mobiliser l’entreprise à tous les niveaux et la rendre capable d’exécuter les transformations dans un environnement incertain
• S’appuyer sur un cadrage stratégique rapide pour prendre des décisions en connaissance de cause et savoir quels bénéfices rechercher

Project portfolio management (2/4)

L’activité PMO-PPM est devenue une charnière entre les différents niveaux de l’organisation. La gestion de portefeuille au plus haut de l’entreprise en lien avec la direction générale et les directions fonctionnelles, tend à évoluer en une fonction à part entière de l’organisation. Elle est mandatée pour assurer l’alignement du portefeuille des projets à la stratégie et optimiser la valeur apportée par les investissements engagés pour ses clients (« customer centric »). Du fait de ce nouveau positionnement, ses activités et son rôle changent : elle devient un pivot d’optimisation de la réalisation des bénéfices entre sponsors et projets (et programmes).

Ce changement entraîne toute une série de questions :

• 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 ?
• Comment tirer parti des supports existant, et notamment l’instruction des Business Case et leur suivi dans le temps ?
• 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.

Maîtriser les transformations complexes (3/4)

Rapidité des évolutions technologiques, fort contexte concurrentiel et mondialisation s’imposent aux entreprises : des transformations de leur système d’information et de leurs organisations sont plus fréquentes et plus complexes. Pour développer ou conserver son leadership, il faut réussir à maximiser la réalisation des bénéfices attendus des projets quelle que soit leur taille, pour les clients internes et pour les clients finaux.

Les projets de transformation constituent des leviers essentiels pour délivrer les capacités nécessaires à cette réalisation des bénéfices (ex. un upgrade d’un outil de CRM qui permet de renforcer le lien avec les clients, un nouveau parcours client et de nouveaux modes de fonctionnement qui permettent d’augmenter la compétitivité, etc.). Ils reprennent à leur charge les espoirs de bénéfices identifiés dans le plan stratégique, pour les concrétiser.

La 1ère étape de la concrétisation des bénéfices passe par la production d’un Business Case qui permet principalement de valider la « rentabilité » du projet en se projetant sur ses conditions de réussite :

• Quels sont les résultats alignés sur les bénéfices attendus nécessaires à la maîtrise et à la réussite du projet ?
• Quels sont les facteurs clés de réussite du projet ?
• Comment réunir les conditions nécessaires à la réussite du projet ?
• Comment le Business case (argumentation des bénéfices) et l’analyse d’impacts associée doivent-ils être suivi par le Sponsor et le chef de projet au fur et à mesure de l’avancement du projet quel que soit la méthode appliquée ? 
• Comment doter le projet d’une conduite du changement adaptable à son contexte ?

Accompagner le changement (4/4)

La conduite du changement pour sa part, adresse les facteurs humains qui conditionnent les capacités organisationnelles en œuvrant sur le niveau de mobilisation, les relations et les conduites collaboratives, les compétences, le type de management et les pratiques professionnelles, voire la culture de l’entreprise.

À tout moment d’une transformation, elle permet d’identifier les impacts, d’évaluer et d’anticiper les « hauteurs de marche » que devront franchir les collaborateurs et leurs entités. C’est-à-dire qu’elle permet d’évaluer les efforts individuels et collectifs pour réaliser les bénéfices attendus des parties prenantes du changement tant internes qu’externes.

La conduite du changement partage, par des actions de communication « passive » auprès des collaborateurs, les bénéfices du projet et la vision cible, afin de les préparer aux changements. Ensuite par des outils de transformation « actifs », elle cherchera à les rendre acteurs des changements.

Plus qu’une activité de fin de projet, la conduite du changement est une préoccupation constante pour qu’un projet réussisse :

• Comment s’assurer que le triptyque habituel « collaborateurs – organisation – outils » sera correctement aligné pour permettre d’obtenir les bénéfices de la transformation ?
• Comment garantir que les collaborateurs contribuent au projet, plutôt que de le freiner ?
• Comment optimiser les bénéfices par l’action des collaborateurs ?

Comme on vient de l’évoquer, la notion de bénéfices est présente tout au long du cycle des transformations, car c’est autour de cette finalité que l’on peut mobiliser toutes les parties prenantes d’une transformation. C’est pourquoi chez Rhapsodies Conseil nous considérons comme essentiel de piloter les bénéfices comme moyen de maîtriser et d’optimiser les transformations. Nous vous retrouverons dans les prochaines publications pour développer tous les aspects de ce sujet.

Chez Rhapsodies, nous sommes tous focalisés sur la réalisation des bénéfices lorsque nous intervenons chez nos clients.

Découvrez-en plus concernant l’expertise de Karl : Transformation Office Management.

TOGAF est le Framework de l’architecture. Sa roue ADM est un classique. Le nombre de certifiés a explosé en France et dans le monde. Le but de cette série d’article est de voir avec vous, en se basant sur mon expérience de 13 années en tant qu’architecte, si ce framework doit être appliqué ou non, et sans renier la certification, réfléchir à comment l’appliquer et avec quel niveau d’investissement.

Nous allons donc commencer par explorer, dans cet article, les 2 premières phases, puis nous aborderons les autres phases dans de prochains articles.

Enfin certifié

Imaginons un plan de transformation du système d’information, vous êtes architecte et

on vous propose une formation. Comme vous êtes curieux, vous acceptez, et comme vous êtes travailleur vous réussissez l’examen final. Une fois la certification obtenue, et la satisfaction qui va avec, chacun s’est posé cette question : Qu’est-ce que je fais maintenant ? Et trop souvent, le résultat obtenu est décevant.

Il est décevant pour les certifiés qui ne savent pas comment mettre en œuvre ce qu’ils ont appris, mais aussi pour ceux qui ont financé cette certification et tout le monde a déjà entendu « TOGAF est trop loin de la réalité, cela ne sert à rien ». Alors, comment faire pour ne pas en arriver là ?

La phase préliminaire

Une phase primordiale

La première des phases de la roue ADM est celle qui, justement, est en dehors de la fameuse roue. C’est pourtant une phase vitale pour la suite de vos travaux. Elle sert à préparer l’entreprise aux travaux d’architecture (et pas uniquement la DSI). Les questions que l’on doit se poser sont « Où allons-nous faire de l’architecture ? avec Qui et Comment ? », mais également « Pourquoi ? ». L’odbjectif principal de cette phase est donc de construire une vue succincte des besoins, pour ensuite définir les capacités d’architecture que l’on pense nécessaire. Nous sommes en train de cadrer la mise en œuvre de l’architecture.

Capitaliser sur le sponsor

Lors de la formation, nous avons appris qu’il fallait commencer par définir la structure de l’entreprise puis les éléments métiers qui poussent au lancement de ce projet, de formuler la demande de travaux, de définir les principes d’architecture s’appliquant au projet, le référentiel à utiliser et les relations avec les autres référentiels de pilotage. Mais c’est également à ce moment qu’il faut évaluer la maturité de l’entreprise sur les notions d’architecture et que l’on peut adapter la méthodologie et l’ADM au projet.

Les « entrées », informations censées être collectées avant le projet, seraient : le modèle de l’organisation de l’entreprise, le référentiel méthodologique d’architecture, les outils, les principes d’architecture, le continuum d’entreprise, le référentiel d’architecture et le cadre de capacité… mais dans les faits, ces « entrées » sont rarement présentes.

Et pourtant, TOGAF préconise une première réunion avec le sponsor / commanditaire lors de cette phase et celle-ci est obligatoire. Lors de cette première réunion, les points cruciaux sont les entités / fonctions de l’entreprise pour définir le périmètre de l’étude, la gouvernance du projet d’architecture et bien sûr, le driver de la transformation. Sans cette réunion, il n’est pas utile d’aller plus loin, et si cela est difficile à organiser, vous avez déjà votre évaluation de la maturité.

Capitaliser sur ce qui existe pour ne pas consommer trop de temps

D’après TOGAF, il est possible, lors de cette phase, de modifier la roue ADM pour répondre au mieux aux besoins du projet de l’entreprise. Attention toutefois, il peut être dangereux de remettre en cause la roue ADM à chaque itération, et il faut absolument en garder le principe (l’enchainement des phases et les liens entre elles). Il est préférable d’avoir une roue stable sur un segment fonctionnel donné.

Nous allons donc commencer par la phase préliminaire elle-même : Le but est de de capitaliser sur ce qui a déjà été fait. Lors de la réunion avec le sponsor, vous avez identifié les grandes fonctions impactées. Pour identifier la capacité d’architecture nécessaire à votre projet, 3 situations peuvent se présenter à vous :

• Si vous être dans une grande entreprise, il y a déjà des architectes en charge de ces fonctions, il suffit de leur exposer les attendus métier et de collecter leurs retours.
• Si ce n’est pas le cas, il est possible de se baser sur des projets précédents. De façon native, de nombreuses étapes de la roue TOGAF sont déjà mises en place au sein d’un SI : des architectures applicatives ou techniques, parfois des processus sont déjà modélisés, des plans de migration sont mis à plat avec la gouvernance associée. Cela est tout à fait normal car TOGAF est un framework pour répondre à des besoins liés à une DSI et parfois, des réponses ont déjà été apportées à des besoins apparus lors des projets. Il faut alors se baser sur ce retour d’expérience.
• Si vous n’êtes dans aucun des cas précédents, Il ne reste plus qu’à construire vous-même vos hypothèses. Basez vous sur quelques concepts faciles à identifier : Combien de processus ? Sont-ils le cœur de métier de l’entreprise ou pas ? Quelle est l’application au cœur de la transformation et quelle est l’équipe qui en a la charge ? Ces hypothèses seront évidemment fausses mais cela permet de poser une première brique.

Savoir comment valider ses propositions

Pour finir cette phase, il reste à définir comment faire valider vos travaux. Pour cela rien de plus facile : Si un processus de validation existe déjà, demandez-le ainsi que le temps moyen de validation.  S’il vous semble imparfait, n’essayer pas de le faire modifier. Vous allez perdre du temps qui serait utile à votre projet. Si aucun processus n’existe, faites valider vos propositions par le sponsor et les parties prenantes, comme cela est préconisé par TOGAF.

Tout le monde sur la ligne de départ

A la fin de cette phase, vous aurez la structure de votre équipe d’architecture, qui valide les étapes et les résultats de l’étude, prête à démarrer votre projet.

La phase a : la vision de l’architecture

Les choses sérieuses commencent

La phase de vision de l’architecture permet de définir les impacts du projet sur le système d’information ainsi que les chantiers d’architecture à mettre en place. Elle est précédée de la phase préliminaire ou de la roue ADM précédente (en plus clair, la précédente phase du projet).

D’après TOGAF, a liste des étapes pour construire la vision d’architecture sont : identifier les parties prenantes et leurs exigences, les enjeux métiers (les bénéfices attendus par le métier), confirmer les objectifs, évaluer le niveau de motivation et de préparation des métiers, ainsi que les capacités des dits métiers, confirmer les principes d’architecture, définir les KPI pour mesurer les bénéfices d’architecture, les risques… Bien sûr, tout cela est logique dans un monde sans contrainte, mais cela arrive peu, pour ne pas dire jamais :

• Comment évaluer les capacités du métier à répondre aux attentes de l’architecture, son niveau de motivation ou de préparation ? L’architecture est habituellement intégrée à la DSI et à quoi bon faire cela ? Comment présenter au métier, qui finance la DSI et l’étude, qu’il n’est pas au niveau et quels seraient les critères pour dire cela ?
• Comment estimer la capacité du métier ? A partir des chaines de valeur ? Le contrôle de gestion de l’entreprise est le seul à avoir les informations nécessaires, mais les informations sont rarement partagées.
• Et pour les KPI, comment faire une évaluation des gains alors que les problèmes à résoudre sont noyés dans le reste des activités des utilisateurs ?

Se concentrer sur l’essentiel

En fait, tout cela s’ajuste au fur et à mesure de l’avancée de l’étude, car cela permet au métier de reprendre le contrôle sur ses outils et ses processus. Cependant, on peut rapidement réaliser quelques étapes de cette phase :

• Construire une carte des parties prenantes permet de faire une estimation rapide des influences de chacun.
• Faire une macro-cartographie pour définir les grands ensembles du projet ainsi que quelques scenarios métiers pour pouvoir « jouer » des cas pratiques lors de la conception de la solution.
• Si la mise en place des KPI n’est pas possible, on peut au moins demander au métier de faire une pondération « à dire d’expert » de ses attendus. En fait, il suffit souvent de demander les différents « pain points » à résoudre ainsi que les nouveaux besoins auxquels répondre, et de demander un ordre de priorité. A la fin du projet, vous pourrez demander au métier si la solution apportée lui convient.

L’état des lieux est terminé

Au final, cela permet à chacun de faire une évaluation plus fine de l’étude à réaliser et de compléter la note de cadrage. Comme dans toutes les épreuves, tous ces éléments vont s’affiner avec le temps et il est bon de garder le document pour le confronter au réel.

La suite

La grande force de la roue TOGAF est qu’elle traite toutes les problématiques liées à l’architecture et apporte une réponse, ou au moins un Framework pour répondre, à ces problématiques. Et comme tout framework, il est important de l’appliquer à un contexte. Suivre TOGAF c’est bien, savoir le faire sans oublier pourquoi, c’est mieux. Il n’est pas utile de tout faire exactement comme cela est préconisé – tous les acteurs du projet n’en saisissent pas forcement les bénéfices – mais il est tout à fait possible d’en extraire l’essentiel.  Apres avoir traité les deux premières phases, nous continuerons, dans les prochains articles, à parcourir les autres phases la roue ADM et explorer ensemble TOGAF IN REAL LIFE.

Des bâtiments aux systèmes d’information en passant par la santé, l’intelligence artificielle joue un rôle croissant dans la transformation de l’entreprise en ouvrant de nouvelles potentialités, mais aussi de nouvelles innovations. D’autre part, l’architecture d’entreprise (AE), historiquement au cœur des transformations de l’entreprise, est particulièrement concernée par les opportunités offertes par ces nouvelles capacités, notamment pour améliorer le fonctionnement interne de l’AE. L’hybridation entre l’intelligence humaine et l’intelligence artificielle (IA) sera la clé de voûte dans la mise en œuvre des capacités de l’IA, notamment au service de la transformation de l’AE et plus globalement au service de l’entreprise.

Cette hybridation se traduit notamment par…

Cartographie et contrôles de conformité

Avec les algorithmes de Machine Learning (ML), les architectes d’entreprise ont à leur disposition une nouvelle approche de cartographie des systèmes d’information au sein de l’entreprise. En effet, ces nouvelles capacités permettent à l’architecture d’entreprise d’automatiser (via un processus d’audit automatique) la cartographie des systèmes d’information en reliant les acteurs, l’organisation, les processus métier et les données. Cette cartographie automatique a le double avantage de permettre une accélération de l’ouverture du SI via une APIsation.

Dans le même sillage, les nouvelles capacités offertes par les algorithmes de l’IA permettront d’accélérer et de simplifier l’analyse des données dans le cadre règlementaire (RGPD par exemple) mais aussi pour les dictionnaires des données. Étant donné les nouvelles méthodes de travail (plus de collaboration, méthodes agiles, …), l’architecture d’entreprise aura à évoluer vers un modèle lui permettant de s’adapter rapidement aux changements continus. Elle aura aussi pour effet de libérer les architectes des tâches chronophages liées à la création et mise à jour des référentiels.

Proposer des modèles d’architecture en utilisant l’IA

Un des fondements des algorithmes de ML est de permettre de générer des solutions imitant la distribution statistique des données qui lui sont soumises pendant la phase d’apprentissage et de se soustraire des modèles statiques. Cette capacité permettra à l’AE de pouvoir présenter plus rapidement et plus efficacement des modèles d’architecture proche des besoins et des contraintes propres à l’entreprise. Certaines entreprises sont déjà dans le secteur.

Proposer des modèles de mise en oeuvre

Reconnaissances biométriques, recommandations personnalisées, Chatbots, autant de modèles de ML largement utilisés dans différentes entreprises dans le monde, dans ce contexte hautement disruptif. L’utilisation de ces fonctionnalités a un impact majeur sur les processus standards des entreprises allant du métier à la technique. A ce titre, l’architecture d’entreprise, garante de l’harmonisation des processus et des SI, se doit de prendre en compte les impacts de l’intégration de ces technologies. De par son rôle, l’architecture d’entreprise anticipe la mise en place de ces technologies via des recommandations stratégiques.

L’architecture d’entreprise soutient les initiatives d’IA

Les initiatives IA ne sont pas simplement un ensemble d’initiatives complexes et coûteuses dans un environnement complexe, ce sont aussi des accélérateurs de la transformation des processus métiers. Du fait de sa fonction première, l’architecture d’entreprise est une alliée des initiatives IA sur ce domaine. L’architecture d’entreprise apporte la structure et la transparence nécessaires à la planification et à l’exécution de changements complexes dans un domaine aussi vaste et diversifié qu’une entreprise moderne. Une méthode pouvant servir à la mise en place d’une IA :

• Identifier les éléments/capacités qui favorisent la satisfaction du client
• Evaluer l’impact de l’introduction d’une solution d’IA
• Planifier et gérer la mise en œuvre
• Analyser le REX
• Optimiser les prochaines itérations.

Conclusion

L’architecture d’entreprise a un rôle central à jouer dans l’expérimentation de futurs scénarios impliquant les algorithmes de ML. La connaissance transversale des flux de valeur, des processus, des technologies et des données de l’entreprise est un puissant vecteur de transformation et une opportunité pour toutes les entreprises. Adopter l’IA, c’est permettre à son entreprise de rester dans la course à l’innovation et pour délivrer un maximum de valeur.

Rhapsodies Conseil est un cabinet de conseil à taille humaine et ne peut donc pas se permettre de baser son commerce sur la production de conseil en masse comme peuvent le faire des ESN classiques. Sa philosophie est donc de produire une offre « sur mesure » pour ses clients et cela se retrouve dans sa manière de faire du commerce.

Rhapsodies Conseil comme un tailleur 

Le terme de « sur mesure » vient du monde de l’habillement classique pour homme. Un costume sur mesure veut dire que le patron est fait à partir des mensurations (besoins) du client et que les détails sont choisis par celui-ci.

Lorsque vous allez vous faire faire un costume sur Savile Row en Angleterre, le tailleur qui allait prendre vos mesures vous faisait parler pour bien comprendre ce qu’il vous fallait (quel type d’événement, ville / campagne, température, …). Le but de tout cela était de s’assurer que le costume réponde bien à votre besoin. Une fois cela terminé, il griffonnait le mot « BESPOKE » sur la liasse de tissu que vous aviez choisie pour la réserver et pour dire que le client avait parlé. 

Le commerce chez Rhapsodies Conseil fonctionne de la même manière. Bien sûr, il nous arrive de répondre à des appels d’offres sur des besoins déjà formalisés ou de fournir un CV pour une demande d’assistance avec des compétences attendues spécifiques mais dans tous les cas, la valeur du Cabinet se situe dans sa capacité d’écoute de ses clients. Cela nous permet d’ajuster notre proposition au « juste » besoin du Client. Ce principe de frugalité a été résumé ainsi par un ancien client : “Je ne veux pas que l’on me propose une Ferrari quand j’ai besoin d’une 4L”. En d’autres termes, les facteurs limitants doivent être pris en compte lorsque l’on mène une mission de conseil (temps, budget, besoins, …).

Construire de la confiance

Quand ce dialogue se met en place, une relation de proximité avec le client peut se créer et cette proximité est nécessaire pour connaître l’objectif derrière l’objectif. 

Avec votre tailleur, la confiance va vous aider à lui avouer que vous voulez apparaître plus grand, il va donc monter l’emplacement de votre cran, ou que vous voulez avoir l’air plus statutaire, il va alors élargir vos revers… Pour Rhapsodies Conseil, c’est la même chose. 

Et pour construire cette confiance, cela se fait plus facilement quand la mission se passe bien mais ce n’est évidemment pas toujours le cas. Plus la relation va durer, plus la probabilité de rencontrer un obstacle augmente et, dans ce cas, il est essentiel d’assumer les erreurs qui ont pu être faites et de les réparer. Le droit à l’erreur existe mais il faut tout faire pour que cela n’arrive plus.

On peut dire que la relation est de confiance quand elle est construite sur 2 niveaux de relation : Le premier niveau est évidemment celui du consultant qui mène la prestation. C’est la qualité de sa prestation qui est la première étape (ou le premier coup de ciseaux dans le cas de notre tailleur) dans la construction de la confiance. Mais que se passe-t-il si le consultant quitte le cabinet ?  Après tout, cela arrive dans une évolution de carrière, surtout quand on valorise votre travail. Et bien comme notre tailleur ne travaille pas tout seul (il y a celui qui travaille sur le patronage, celui qui coupe, celui qui confectionne, parfois vous avez un pantalonnier). 

Chez Rhapsodies Conseil c’est la même chose : Un consultant n’est jamais laissé seul en mission. Il a toujours accès aux connaissances acquises par le cabinet. Un client ne consomme pas la prestation d’un consultant mais bien celle du cabinet dans son entièreté. Et cette relation passe donc également par un deuxième niveau, le manager de mission. Son rôle n’est pas que de faire le suivi du consultant mais également de prendre du recul sur la mission, échanger sur ses besoins avec le client, comprendre ses contraintes et apporter son point de vue. Quand tout cela est réussi, nous pouvons être sûr que si un des deux niveaux est défaillant, le lien n’est jamais rompu. 

Une interaction biologique

Enfin, le but de chaque relation est qu’elle soit bénéfique à toutes les contreparties. Et pour que cela soit le cas, elle doit être envisagée comme un partenariat et pas uniquement comme une relation client – fournisseur. L’un apporte ses besoins, de potentiels projets à forte valeur et Rhapsodies Conseil apporte son expertise et son engagement. 

Pour changer de notre analogie avec le tailleur, nous pouvons utiliser le concept biologique qui désigne un processus impliquant des échanges ou relations réciproques entre plusieurs éléments. Il y a bien évidemment un échange, qui est contractualisé, une expertise contre rémunération mais cela ne doit pas être uniquement cela. Pour le client, il faut aussi qu’il puisse intégrer une partie de cette expertise, que les connaissances dont il a besoin soient acquises par ses équipes. Pour le cabinet de conseil, l’intérêt est de confronter le consultant à des problématiques qu’il n’a jamais rencontrées auparavant (nouveau domaine d’activité, nouveau domaine fonctionnel, nouvelle technologie, …) et ainsi élargir le champ de ses compétences.

Existe-t-il une durée de relation idéale ?

Quand votre garde-robe a atteint une taille nécessaire (ce qui est propre à chacun), ou quand votre budget ne vous le permet pas, il n’est pas dans l’intérêt de votre tailleur de vous faire commander tout de suite de nouveaux vêtements. Il risque de vous lasser, de vous décevoir car vous n’avez plus d’attente, voire de vous braquer. 

Si on garde le fil de notre analogie, le risque est le même dans le conseil. Il est indéniable qu’une relation à long terme avec un client est bénéfique : on le connaît de mieux en mieux et l’inverse est aussi vrai, en conséquence nous sommes de plus en plus performants collectivement. Mais une relation à long terme ne veut pas dire être toujours là mais être là quand il en a besoin. Nous disions tout à l’heure que pour qu’une mission de conseil soit une pleine réussite, il faut qu’une partie de l’expertise soit captée par le client, que le client monte en maturité sur le sujet.

Cela ne se fait pas en un claquement de doigts (ou un coup de ciseau). Il faut parfois savoir partir pour (mieux) revenir. Le risque à vouloir toujours être là est de trop s’écarter de son expertise, de ne plus justifier son budget et donc d’abîmer la confiance. La relation entre le client et Rhapsodies Conseil et la relation entre le client et le consultant ont des cycles de vie différents. Si la valeur ajoutée de la relation entre le client et le cabinet augmente avec le temps, nous estimons que la durée de vie de la relation entre le client et un consultant doit être comprise entre 1,5 et 3 ans. C’est le temps nécessaire à un consultant pour comprendre et maîtriser l’environnement du client et pour ce dernier d’en tirer les bénéfices. 

Comment définir un prix ?

Comme pour toute relation commerciale (tailleur ou conseil), le prix doit correspondre à la valeur perçue pour que la confiance soit maintenue. Si vous avez l’impression de surpayer un bien ou un service, vous ne serez pas enclin à faire un deuxième achat. 

Chez Rhapsodies Conseil nous proposons des prix justes, prix marché, par rapport à l’expertise fournie en regard du besoin. Nous n’essayons pas de faire le plus de marge possible au détriment du client et du collaborateur (car le client attendrait une expertise peut être supérieure à celle du collaborateur et cela le mettrait en difficulté)

En contrepartie, la marge de manœuvre pour des négociations est très faible et parfois inexistante. Il nous arrive de perdre des clients qui cherchent une baisse de prix infondée. La solution serait de faire intervenir des consultants avec une expertise insuffisante pour répondre au besoin du client et nous nous y refusons. Cela nous obligerait à baisser la qualité de service à laquelle nous tenons, au risque d’avoir des « casseroles » chez le client, or il est fondamental pour nous de maintenir la confiance.

Si le client n’a pas le budget nécessaire pour financer notre intervention, nous cherchons alors un moyen de baisser le montant total en travaillant sur la priorisation et ainsi apporter un maximum de valeur et cela le plus rapidement possible. Plutôt que de vouloir traiter 100% du spectre avec un budget insuffisant, nous préférons nous concentrer sur les 80% de fonctionnalités qui représentent souvent l’intégralité des attentes prioritaires venant du métier. Pour cela, notre expertise sur l’agilité est rentrée dans notre ADN et nous aide beaucoup dans la manière de mener nos prestations mais également dans notre commerce.

Rhapsodies Conseil commerce comme il travaille

Finalement, la vision de Rhapsodies du conseil est de ne jamais perdre de vue l’objectif dans ce que nous entreprenons. Que ce soit dans nos prestations ou dans notre commerce, le « quick win » n’est qu’un moyen pour atteindre l’objectif final et non une fin en soi. Nous ne voulons pas mettre en péril l’atteinte de cet objectif pour un contrat de plus courte durée. Votre tailleur vous accompagne au fil du temps en prenant en compte vos évolutions physiques, et Rhapsodies Conseil fait de même en prenant en compte les nouveaux défis à relever.

Les autres articles qui peuvent vous intéresser

29 juillet 2020

Direction Générale

Budgets glissants : Comment piloter en période de vents forts ?

En savoir plus

24 mai 2018

Direction Générale

Rester maître de sa croissance pour mieux cultiver son indépendance et… ses expertises

En savoir plus

Responsable d’application

Je n’ai rien contre vous, mais ça va prendre trop de temps de référencer et de compléter nos applis… Vous avez une ligne d’imputation ?

Chef de projet

C’est surtout un énième référentiel qui ne sera pas tenu à jour : beaucoup d’efforts d’initialisation au départ et pas de récompense à l’arrivée !

Directeur d’un domaine applicatif

Je monterai à bord seulement si on me prouve que ça marche et que les autres ont déjà complété leur part.

Indiana Jones

Damn…

En entendant ces retours, Indiana réalise à quel point le déploiement d’un référentiel d’architecture pour son entreprise d’archéologie ne va pas être chose facile… Surtout auprès des parties prenantes qui devront se charger de compléter les informations sur leurs applications.

L’arrivée d’un référentiel des applications, quel que soit l’usage qui en est fait (Application Portfolio Management, gestion de l’obsolescence, transformation du SI…), est majoritairement vu par les équipes opérationnelles comme une contrainte, en termes de temps, et donc de budget.

Armé de son chapeau fedora d’explorateur intrépide, Indiana se lance sur les eaux sinueuses de la mise en place d’un référentiel d’architecture et de la conduite du changement auprès de ses équipes.

Nous retracerons ses péripéties à travers ce retour d’expérience : que pouvons-nous faire concrètement pour lever les freins et faciliter ainsi le changement et l’acceptation de l’outil ?

Enfilez votre meilleur pantalon cargo et chaussez des boots en cuir confortables (nota bene : vous pouvez exclure le fouet de votre attirail) et… Action !

Pour bien se dérouler, l’expédition doit être bien organisée

Première étape, Indiana part à la recherche de recrues sur lesquelles il pourra compter pour mener à bien sa quête.

La mise en place d’un référentiel d’architecture ne s’effectue pas sans un fort sponsoring de la part de la direction. Ces sponsors seront les plus pertinents pour répondre au « pourquoi » (Simon SINEK, « How great leaders inspire action »), ce fameux adverbe qui, à défaut de nous laisser coi, doit au contraire éclairer les lanternes et permettre aux intéressés comme aux sceptiques de rallier la cause. Ainsi, le directeur du Système d’Information, de l’architecture, des études, voire de la sécurité et des différents pôles applicatifs, semblent tous désignés pour accomplir ce rôle de « parrain » (sorte d’Al Pacino corporate) du projet.

Si nos sponsors semblent désignés d’office, nous aurons besoin d’aventuriers au sein de notre organisation projet, de personnes qui promeuvent la démarche et qui veulent utiliser l’outil. Ils seront de préférence opérationnels ou auront une bonne connaissance des équipes, de leurs besoins et contraintes. Ces aventuriers devront également être capables d’aller vaincre les démons de la réticence et de prendre du recul sur la situation. Ce seront des ambassadeurs du projet : des responsables d’applications, des responsables de pôles, des PMO ou autres fonctions transverses, ou même des personnes qui connaissent peut-être l’entreprise et son SI depuis plus de 20 ans… En bref, ces opérationnels seront nos yeux et nos oreilles pour les remontées terrain, afin de permettre à l’équipe projet référentiel d’architecture de répondre aux attendus et de lever le plus tôt possible les principaux freins au changement.

Armé de cette équipe solide, Indiana est prêt à débuter son expédition auprès des responsables d’applications !

Équipement approprié + capacité d’adaptation = le kit du bon aventurier

Qui dit déploiement d’un nouvel outil dit nécessairement conduite du changement auprès des populations concernées. En l’occurrence, si nous arrivons avec un outil qui est vu comme une contrainte, il sera important d’adapter nos leviers à notre public. (Mettons momentanément de côté la méthode Indiana : le fouet n’EST PAS une solution adaptée à la conduite du changement. Est-ce bien clair ?)

En revanche, il conviendra de s’équiper d’un attirail adéquat en fonction de la situation. Qui sont mes utilisateurs ? Quels sont les canaux de communication les plus adaptés ?  Qu’est-ce qui fonctionne bien dans l’entreprise ? Sur quelles ressources puis-je m’appuyer ? sont autant de questions qui aideront à constituer l’équipement de l’aventurier.

Prenons l’exemple d’un kit qui a fonctionné :

• des kick-off courts auprès de chaque équipe pour présenter le « pourquoi » du projet, recueillir les besoins et premiers retours et convaincre à l’aide de cas d’usage adaptés en fonction de leurs objectifs ;
• des formations sur-mesure et interactives (cet accessoire indispensable est à calibrer en fonction  de l’ergonomie et de la facilité d’utilisation de l’outil choisi) ;
• du coaching à volonté à l’aide d’un point de contact et de support bien identifié et accessible par les utilisateurs (de ce fait, cela ne peut pas être un directeur, mais quelqu’un qui sera disponible pour les équipes) ;
• une documentation abordable, pas trop longue, pour ne pas décourager les élèves, et tenue à jour pour assurer la cohérence du discours ;
• des vidéos tutos pas-à-pas, avec une communication régulière, parfois légère ou informelle (via Workplace, SharePoint, mail, voire même papyrus antique).

L’une des composantes principales de la conduite du changement est la communication. L’enjeu sera d’apporter, avec pédagogie, toute la connaissance nécessaire à nos populations concernées, afin de les rendre autonomes et de les convaincre de l’utilité de la démarche. Pour cela, des formations adaptées, couplées à une communication régulière et orientée en fonction du public, seront nécessaires. 

La réussite du succès : itérer

Inutile d’arriver avec un schéma de déploiement trop préconçu : avoir des principes, oui, mais rigides, non ! Ce serait le meilleur moyen pour que les utilisateurs n’adhèrent pas. Il nous faudra faire preuve de souplesse et d’agilité pour éviter les écueils et nous emparer des idoles aztèques conservées dans les temples maudits sans se faire transpercer par les flèches piégées.

Plus encore, il faudra également donner la parole à ces parties prenantes de tout horizon et les inclure dans les décisions prises autour du référentiel (nomenclatures, règles de modélisation d’une application, ses instances, ses interfaces, ses composants techniques et les informations complémentaires utiles à renseigner).

Pour faciliter l’acceptation, nous prendrons en compte les points de vue et adapterons l’expédition en fonction des imprévus, qui ne manqueront pas d’arriver (cf. Indy dans « Les Aventuriers de l’arche perdue »), mais qui permettront à coup sûr d’enrichir la portée du référentiel ! 

Après avoir recueilli les doléances, il sera important de trouver des solutions, de les documenter et de les généraliser auprès de tous les utilisateurs. Les équipes se sentiront plus ainsi engagées et responsabilisées, d’autant plus qu’on aura itéré avec elles sur leurs besoins. 

Bien entendu, il faut savoir dire non à certaines demandes, afin de ne pas se retrouver avec une liste au Père Noël qui diluerait les objectifs premiers du référentiel.

Conclusion 

Intérieur – une deuxième salle de réunion dans une Université

Responsable d’application

Ça m’a pris du temps, mais j’ai mieux compris à quoi le référentiel allait me servir : partager la carte d’identité de mon application, visualiser ses flux d’échange, anticiper l’évolution de son état de santé technique, pour faciliter les études d’impacts.

Chef de projet

Je peux dorénavant avertir les autres responsables d’application de l’arrivée d’une nouvelle application dans la cartographie et afficher les impacts sur le système d’information. Associé au travail des architectes sur la vision future de l’entreprise, le référentiel prend une vraie valeur.

Directeur d’un domaine applicatif

Je dispose à présent d’une vue exhaustive de mon périmètre et d’informations de qualité sur les applications. Je me porte garant pour assurer la maintenance dans le temps de cette cartographie afin d’en faire bénéficier toutes les parties prenantes de la direction informatique.

Indiana Jones

Is this the real life? Is this just fantasy?

The end

Comme nous le constatons en cette fin de scénario, Indiana a pu lever les réticences majeures à l’aide de sponsors investis, de cas d’usage ciblés et d’une conduite du changement adaptée aux besoins des équipes opérationnelles. L’apport d’un tiers dans la démarche, neutre et indépendant, facilite cette conduite du changement.

Un exemple de la réussite de cette phase de déploiement est d’avoir fait entrer le référentiel d’architecture en tant que « réflexe » dans les mœurs de la direction du système d’information : « As-tu vérifié ce que dit le référentiel à ce sujet ? As-tu capitalisé ton étude SI dans le référentiel ? » Une fois que c’est fait, nous pouvons entrer dans une phase de mise à jour récurrente des informations, à l’aide d’un processus adapté et de KPI pour évaluer la qualité globale du référentiel dans le temps.

De votre côté, comment vous êtes-vous frayés un chemin à travers la végétation luxuriante de l’inventaire applicatif ? Comment avez-vous organisé l’expédition et quel kit du bon aventurier vous a le plus aidé ?

Sources images :

https://www.franceinter.fr/emissions/blockbusters/blockbusters-11-aout-2020

https://www.jones-jr.com/rotla_mo06_e_tournage.html

Image 2 Indiana Jones

https://fr.freepik.com/photos-gratuite/pere-noel-sac-montrant-pouce-vers-haut_9378888.htm#page=1&query=p%C3%A8re%20noel&position=4