La data science est devenue un levier clé aujourd’hui, pour mettre les données au service de bénéfices et de problématiques métiers : Automatisation de tâches & de choix, Fourniture de nouveaux services « intelligents », Amélioration de l’expérience client, Recommandations, etc.
C’est aussi une discipline qui passionne par son caractère particulièrement « innovant », encore aujourd’hui, mais qui génère des croyances sur ce qu’elle peut réellement apporter à une organisation. Certains dirigeants ont souvent donné trop de valeur intrinsèque à la discipline, s’attendant à des retours importants sur leurs investissements (data lake & armées de data scientist / engineers).
En réalité, la Data Science n’est qu’une technique qui a besoin de méthodologie et de discipline. A ce titre, elle nécessite au préalable de très bien définir les problèmes métiers à résoudre. Et quand bien même le problème est bien défini, et le modèle statistique pour y répondre performant, cela ne suffit pas encore. Le modèle doit être utilisable « en pratique » dans les processus métiers opérationnels, s’intégrer parfaitement dans l’expérience utilisateur, etc.
Quels principes clés peut-on se proposer d’appliquer pour maximiser la valeur de cette capacité ? Essayons ici de donner quelques pistes.
Comprendre le métier : analyser les risques, les besoins d’optimisation, les nouvelles opportunités
L’identification d’usages métier, qui nécessitent des méthodes d’analyse de données avancées, est une étape clé. Ces usages ne tombent souvent pas du ciel. Une démarche proactive avec les métiers est nécessaire pour les identifier. C’est d’autant plus vrai lorsque le métier est encore peu familiarisé avec les techniques de data science, et ce qu’il est possible d’en tirer concrètement.
C’est un travail de “business analysis”, dont la Data Science n’a absolument pas le luxe de se passer contrairement à ce qui est pratiqué parfois : Comment travaille le métier aujourd’hui ? Quels sont ses enjeux, ses drivers, ses axes d’innovation, ses axes d’optimisations des processus opérationnels en place, et quelles données sont manipulées aujourd’hui, comment et pour quoi faire ? Quel est le niveau de qualité de la donnée, manque-t-il des informations clés pour répondre aux problèmes quotidiens, ou pour innover ? etc.
Quand on est au clair sur toutes ces questions, on est prêt à identifier des usages concrets avec le métier, qui pourraient bénéficier de techniques d’analyse avancée.
Comprendre l’usage et le système concerné : adopter le point de vue systémique !
Imaginons que nous cherchons à prédire le flux de patients sur un jour donné dans un hôpital, afin d’adapter les ressources, les processus, les dispositifs pour limiter le temps d’attente. Il convient, avant de foncer tête baissée dans l’analyse des données, de comprendre l’ensemble de la problématique. Par exemple, les approches de « system thinking » peuvent être tout à fait adaptées pour que le data scientist s’assure de ne pas oublier de paramètres clés dans la dynamique du problème qu’il veut résoudre. Ainsi, il n’oubliera pas non plus des données clés pour son modèle (existantes ou dont il faudrait organiser la collecte à l’avenir pour améliorer le modèle).
Ce type de représentation (ici : Causal loop diagram), peut permettre au métier de s’exprimer sur le processus, sur l’identification des variables clés, et de formuler ses intuitions sur les paramètres et les dynamiques en jeu qui peuvent influer sur la variable à prédire ! (ici les influences positives ou négatives entre les variables structurantes décrivant la dynamique du système).
Le diagramme ci-dessus n’est qu’un exemple de représentation systémique, on peut adopter d’autres types de représentation du système au besoin. L’important étant d’étendre la compréhension du système, qui peut nous amener à identifier des variables cachées (non intuitives a priori).
Concrétiser un usage : prototyper au plus tôt avec le métier, dans son environnement de travail, au risque de rester éternellement au statut de POC !
Une fois que le système est bien défini, et que les hypothèses et intuitions sont posées, il faut comprendre : comment le modèle analytique sera concrétisé en pratique, qui sera l’utilisateur final, quel est son environnement de travail actuel et comment on pourra intégrer les résultats d’un modèle statistique dans son travail quotidien.
Une technique simple et confortable pour le métier : faire un prototype rapide, même avec des fausses données pour commencer, des faux résultats de modèles statistiques. Bref, l’idée est rapidement de se projeter dans l’usage final de la manière la plus concrète possible, pour aider le métier à s’inscrire dans sa future expérience. Évidemment, nous ne resterons pas éternellement avec des fausses données.
L’objectif est d’être tout à fait au clair, dès le départ, sur le produit fini que l’on veut atteindre, et de s’assurer que le métier le soit tout à fait (ce qui est loin d’être toujours le cas). Ensuite, nous pourrons pousser le prototype plus loin (des vrais données, des vraies conditions pour évaluer la performance, etc.).
Cette méthode permet au data scientist de se mettre à la place de l’utilisateur final, et de mieux comprendre comment son modèle devra aider (est-ce qu’il doit apporter juste une classification, un niveau de probabilité, des informations contextuelles sur la décision prise par le modèle, est-ce qu’il doit favoriser le temps de réponse, l’explicabilité, la performance du modèle, etc.). Toutes ces questions trouvent rapidement une réponse quand on se projette dans le contexte d’usage final.
Interagir par itération avec le business, éviter l’effet Kaggle
Nous pouvons rencontrer parfois un comportement (compréhensible), qui est de vouloir faire le modèle le plus performant possible, à tout prix. On passe des heures et des jours en feature engineering, tuning du modèle, on tente toutes combinaisons possibles, on ajoute / teste des données exotiques (au cas où) qui ne sont pourtant pas identifiées en phase de “business analysis”. Je l’appellerai l’effet « Data Challenge » ou l’effet « KAGGLE*».
Et après avoir passé des jours enfermés dans sa grotte, on arrive tout fier devant le métier en annonçant une augmentation de 1% du score de performance du modèle, sans même avoir songé que 1% de moins pourrait tout à fait répondre aux exigences du métier… Comme on dit… « Le mieux est l’ennemi du bien ». Pour éviter cet effet tunnel qui peut être tentant pour l’analyste (qui veut annoncer le meilleur score à tout prix ou qui joue trop sur Kaggle*), des itérations les plus fréquentes possibles avec le métier sont clés.
Arrêtons-nous au bon moment ! Et cela vaut pour toutes les phases du projet. Commençons par chiffrer le système décrit en phase de business analyse, avec des données réelles, et itérons avec le métier sur cette base. Cela permet d’améliorer déjà la compréhension du problème du data scientist, et du métier concerné. Et cela a déjà une vraie valeur pour le métier ! Alors qu’aucun modèle statistique n’a été conçu pour le moment.
Si un modèle nécessite des données inexistantes, organisons la collecte de ces données avec le Chief data officer, dans le temps. Mais ne nous battons pas à vouloir faire un modèle avec des miettes, si nous savons que cela ne permettra pas d’être à la hauteur des attentes opérationnelles.
Le Data Scientist peut avoir aussi ce réflexe un peu étrange de dire « On va essayer, on va faire avec ce qu’on a et on verra ! » comme s’il croyait lui-même que son métier relève de l’incantation.
Evidemment, je ne fais là aucune généralité. Le rôle d’expert nous oblige à prendre nos responsabilités, et à dire « Non, après examen et quelques tests, je ne suis pas confiant du tout pour répondre à votre besoin avec les données qu’on a aujourd’hui ». Humilité, responsabilité et transparence, à chaque itération avec le métier, sont de mise.
On trouve souvent ce risque de dérive dans la relation Expert vs Métier. Ne tombons pas dans le piège de jouer sur l’ignorance de l’autre pour se créer un travail inutile !
Ces quelques principes sont peut-être évidents pour certains, utiles pour d’autres ! En tous les cas, chez Rhapsodies Conseil, au sein de notre équipe Transformation Data, nous essayons d’appliquer cela systématiquement, et nous pensons que c’est le minimum vital.
Pour éviter de faire perdre du temps à nos clients (et de l’argent), nous commençons nos missions BI & Analytics, systématiquement avec une « micro mission » préliminaire qui nous permet de valider la réelle valeur & la faisabilité de l’innovation recherchée (avec toutes les parties prenantes, en faisant des analyses flash des données…) avant d’aller plus loin !
Nous considérons que dans tout projet de Data Science, le prototype métier, tel que décrit dans l’article, est obligatoire. Nous proposons systématiquement un prototypage métier, toujours dans le soucis de bien projeter la valeur attendue pour le métier !
Nous allons plus loin sur la solution que l’analyse avancée des données. Notre expertise globale sur la transformation data, nous permet y compris sur des missions BI & Analytics, de ne pas hésiter à relever si pertinents des axes clés d’amélioration sur la gouvernance de certaines données, l’organisation, la data quality, la stratégie data long terme de l’organisation ou la culture data de l’entreprise, qui pourraient être profitables ou indispensables à l’usage traité.
Pour nous, traiter un usage BI & Analytics, c’est le traiter dans son ensemble, de manière systémique ! Notre solution finale n’est pas un modèle statistique. Notre solution finale est potentiellement un modèle statistique, mais aussi une gouvernance adaptée pour avoir la qualité de données nécessaire, un modèle qui s’adapte à l’expérience utilisateur souhaitée (et pas l’inverse), et un suivi du ROI de l’usage analytique et de sa pertinence par rapport à la stratégie de l’entreprise.
Les entreprises de tout secteur industriel cherchent à maîtriser et améliorer les processus de gestion des données de leurs produits. Ce sujet comporte de nombreux défis car les produits n’arrêtent pas d’évoluer pour satisfaire les besoins des clients d’une part et pour être conformes aux exigences réglementaires et normatives d’autre part.
Si l’on veut exploiter les données de ses produits, il s’agit là d’une difficulté supplémentaire qui ne peut être surmontée à l’aide d’un simple référentiel de données générique (un outil de Master Data Management par exemple).
Mais avant d’en arriver là, tachons déjà de définir ce qu’est un référentiel Produit et de faire un tour d’horizon des solutions existantes sur le marché. Nous verrons ensuite ce qui fait la différence dans un référentiel produit.
Référentiel de données produit
Qu’est-ce qu’un référentiel produit ?
Le référentiel Produit constitue la base de données centrale dans laquelle est intégrée, stockée et liée toute l’information liée aux produits vendus par l’entreprise. Il est nourri à chaque étape du cycle de vie du produit par les différentes équipes qui travaillent dessus et permet de diffuser simplement une information qui a été qualifiée, unifiée et normée. Chaque intervenant peut ainsi travailler sur une base commune d’informations Produit fiable et complète.
Prenons l’exemple d’une enseigne de bricolage, elle propose à ses clients un catalogue de produits variés avec une grande différence entre eux (Boulon, Vis, Marteau, Clé à molette, Perceuse sans fil ou avec fil, Compresseur d’air, etc.). Dans son référentiel, chaque produit a sa propre nomenclature de composants qui peut être basique pour des produits comme les marteaux ou les clés à molette ou complexe comme dans le cas d’un compresseur d’air ou d’une perceuse et chaque composant de la nomenclature a ses propres caractéristiques. Grâce à son référentiel Produit, l’entreprise peut aussi gérer les multiples variantes associées à une perceuse par exemple (Perceuse rouge sans fil, Perceuse noire avec fil 2m, Perceuse jaune avec fil 4m, etc.). L’enseigne peut ainsi gérer les informations liées aux différentes étapes du cycle de vie de ses produits depuis leur conception jusqu’à leur retrait du marché.
L’importance d’un référentiel produit
Lorsqu’une entreprise possède un portefeuille produits étendu et/ou en constante évolution, la quantité de données liées aux produits ne cesse d’augmenter elle aussi. Il devient essentiel de les centraliser, les normer et finalement de les gérer plus simplement pour gagner en efficacité et en fiabilité.
Le référentiel Produit permet de réaliser cet objectif en concentrant dans un outil flexible et transversal toutes les données associées. Il permet de les unifier afin d’assurer leur cohérence et de les lier entre elles pour créer un maillage produit pertinent pour l’utilisateur et un produit fini de qualité et à temps pour le client final.
Exemple et types de référentiels produit
PIM : Abréviation anglaise de Product Information Management. Il permet de centraliser, d’organiser et de gérer les données produit. Le PIM est une sorte de catalogue des produits de l’entreprise et il est très orienté pour des utilisations marketing. En effet, il centralise les données destinées à être diffusées aux prospects / clients telles que les données marketing, les données commerciales, les données techniques.
PLM : Abréviation anglaise de Product Lifecycle Management. Il permet, comme son nom l’indique, de gérer le cycle de vie du produit depuis sa conception, jusqu’à sa fin de vie (fabrication, gestion des stocks, logistique et transport, vente, éventuellement recyclage). Il centralise ainsi toutes les données liées au produit, et permet ainsi de gérer d’une manière plus transversale les données du produit.
Qu’est-ce qui différencie un référentiel produit d’un référentiel générique de données ?
Avec la capacité croissante d’enregistrement des données industrielles, plein de nouveaux concepts caractérisant la gestion des données produit ont vu le jour chez les entreprises. Contrairement aux référentiels génériques, les référentiels Produit ont été conçus pour maîtriser ces concepts et répondre aux enjeux des entreprises en proposant des fonctionnalités et des outils, spécialement, dédiés à la gestion des données Produit.
1. La gestion des cycles de vie des produits :
Les cycles de vie diffèrent d’un produit à un autre. Chacun possède un cycle de vie qui caractérise son développement, sa production, sa commercialisation et sa fin de vie (Exemple ci-dessous)
Dans un référentiel de données Produit la notion de cycle de vie pour un produit fini est liée à la notion de la chaîne de valeur industrielle. Cette dernière permet de supporter les différentes phases de vie d’un produit depuis l’idéation jusqu’à son recyclage ou son retrait du marché.
Le référentiel Produit permet de gérer ces phases sous mode projet avec des jalons et des livrables précis associés à chaque phase.
Quant aux composants de la nomenclature du produit final, ils ont un cycle de vie qui leurs est associé et qui, à l’aide des boucles ou workflows de validation, permet le passage d’une version N à une version N-1 en cas de modifications appliquées à quelques éléments de la nomenclature comme le montre l’illustration basique ci-dessous. Il faut savoir que les cycles de vie des composants peuvent avoir plus de complexité en fonction du secteur d’activités de l’entreprise (Défense, Aérospatial, etc.) ou de l’utilisation finale du produit (Nucléaire, Sous-marin, etc.)
Exemple de cycle de vie d’un composant de nomenclature :
Exemple de cycle de vie d’un produit :
2. La favorisation du co-développement interne et externe :
Le co-développement interne est la collaboration entre les acteurs métiers impliqués dans le développement d’un nouveau produit.
Le co-développement externe est la collaboration d’une entreprise avec ses clients et fournisseurs pour développer de nouveaux produits et services. C’est un vecteur d’innovation et de performance dans un modèle gagnant pour les trois acteurs.
Un référentiel Produit permet de supporter le co-développement interne en mettant à disposition des outils de collaboration entre tous les métiers autour de la nomenclature du produit avec une vue dédiée pour chaque métier. Par exemple, le bureau d’étude veut voir le matériau, les dimensions et les contraintes mécaniques liés au produit alors que les bureaux des achats et des ventes veulent voir les coûts de production, de montage et de maintenance, etc. Le référentiel Produit permet d’avoir une appropriation du contenu et du discours de chaque produit et la création d’un vocabulaire commun. Les entreprises peuvent ainsi avoir des propositions de valeur concrètes répondant aux besoins évolutifs des clients.
Le référentiel Produit permet aussi de favoriser le co-développement externe entre une entreprise, ses clients et ses sous-traitants en donnant la possibilité de partager en toute sécurité les informations qu’elle souhaite avec ces acteurs via une plateforme dédiée. Cela permet d’avoir un gain considérable dans le temps de mise sur le marché des produits car la plateforme permet aux entreprises d’avoir des boucles d’itérations et d’échange avec ses clients et ses fournisseurs lors de la phase du développement du produit et non pas à sa fin comme le montre l’illustration ci-dessous.
Grâce au co-développement les entreprises peuvent minimiser le temps de mise sur le marché des produits et donc réduire leur coût de développement.
3. La gestion des options/variantes et des bom 150% (bill of materials)
La BOM 150 % ou la nomenclature à 150 % n’est qu’un autre nom pour une structure à variantes, ou plus précisément, une nomenclature configurable. Les nomenclatures configurables comportent un ou plusieurs composants optionnels et/ou sous-ensembles modulaires qui, lorsqu’ils sont correctement configurés, définissent une variation spécifique d’un produit. En fait, une nomenclature configurable est constituée de plusieurs nomenclatures possibles chargées dans une seule structure de produit. Lorsqu’elle n’est pas configurée, la nomenclature contient plus de pièces et de sous-ensembles que nécessaire, c’est-à-dire plus de 100 %. D’où l’expression « nomenclature à 150 % ». Cette approche est un moyen pour les ingénieurs de gérer la complexité de la structure et de la variation des produits.
La différence entre les options et les variantes dans un produit est que l’option est un système qui s’ajoute sans impact sur l’architecture du produit et les autres variantes et options choisies (Exemple : Climatisation dans une voiture) alors qu’une variante est un choix obligatoire et exclusif parmi des sous-ensembles et peut impacter l’architecture produit et même la structure de gamme d’assemblage (Exemple : Voiture 3 portes ou 5 portes)
Le référentiel Produit a la capacité de supporter toute la complexité liée à la gestion des BOMs 150 % en gérant non seulement les nomenclatures configurables associées à chaque produit mais aussi les règles de compatibilité entre toutes les options et les variantes possibles.
La gestion des nomenclatures configurables dans les référentiels Produit permet aux entreprises la possibilité de réutiliser les données de définition d’un produit et éviter d’avoir des doublons avec plusieurs numéros d’article pour un même composant.
L’illustration ci-dessous montre un exemple de déclinaison d’une BOM 150 % d’un stylo en deux nomenclatures du même produit mais avec des options et des variantes différentes.
4. Le support des différents types de processus de vente et de production
L’un des atouts majeurs d’un référentiel Produit est le fait qu’il puisse gérer la définition du produit pour les différents processus de vente et de production. Ces derniers varient entre les entreprises et peuvent même coexister pour différents produits au sein de la même entreprise, ce qui ajoute une couche de complexité à la gestion des données de ces produits.
Il existe divers processus de vente et de production dans le marché, on peut en citer :
Make To Stock : Lorsqu’un produit peut être vendu à partir d’un catalogue et qu’il est défini et spécifié par une fiche. La fabrication du produit peut être planifiée en se basant sur les prévisions.
Make To Order : Cette stratégie s’applique toujours aux produits standard dont les spécifications sont clairement définies. Pour ce type de produit, il n’est pas possible d’établir des prévisions et les produits sont fabriqués sur commande.
Configure To Order : C’est le processus le plus complexe du marché car le produit standard comporte un grand nombre de variantes. Il n’est donc pas possible de créer un numéro de produit pour chaque nomenclature à cause des nombreuses combinaisons possibles. Comme le montre l’illustration ci-dessous, la gestion des produits de ce type nécessite 3 briques essentielles que le référentiel Produit comporte :
Architecture produit : C’est le squelette générique du produit.
Familles de diversité : à chaque élément de l’architecture est attachée une famille de diversité donnant le champ des choix possibles pour chaque composant.
Règles de configuration : Les règles de configuration sont un mélange de règles de compatibilité entre les éléments des familles de diversité et de règles de productions qui permettent de configurer une produit fini réalisable par l’entreprise. Elles doivent être définies dans le référentiel et elles sont exécutées lors de la configuration du produit final.
Engineer To Order : C’est une approche de la production caractérisée par plusieurs activités d’ingénierie et soumis à un délai de livraison défini à la réception d’une commande du client accompagné d’un cahier de charge. (Exemple : Fabrication de câble pour un projet de construction d’un pont)
Avoir un outil capable de couvrir les différents processus, comme le référentiel Produit, permet aux entreprises d’optimiser et de centraliser la gestion des données de chaque produit. Par exemple, pour le processus CTO, le référentiel Produit aide les entreprises à éviter les retards de fabrication et les rejets des commandes en empêchant une mauvaise configuration du produit grâce aux règles de compatibilité entre les différents éléments. Chaque produit configuré dans un référentiel Produit est donc réalisable par l’entreprise.
5. La gestion de la conformité par rapport aux exigences
Les référentiels Produit permettent d’améliorer et d’optimiser la gestion de la conformité par rapport aux exigences. Il est possible de stocker, classifier et ordonner les métadonnées liées aux exigences (Client, Réglementaires, etc.) et cela permettra d’avoir une arborescence d’exigences (Requirements Breakdown Structure) qui est en lien direct avec la nomenclature du produit (BOM) comme le montre la figure ci-dessous. Chaque composant ou sous-ensemble est alors attaché aux exigences auxquelles il doit répondre et sa conformité est vérifiée en temps réel.
Cette méthode permet aux ingénieurs d’avoir une couverture totale des sous-ensembles et des exigences qui leurs sont associées. Le développement du produit devient ainsi plus efficace et sa commercialisation sera plus rapide.
6. La gestion des processus de modifications
Dans les référentiels Produit, les boucles de modification sont constituées d’une séquence d’événements comme le montre le logigramme ci-dessous. Les étapes principales de cette boucle sont :
Rapport d’incident ou Problem Report (PR) : c’est un signalement de problème ou une source potentielle de panne dans le produit. Le PR peut déboucher sur une demande d’évolution technique (modification) du produit ou d’un processus.
Demande de modification ou Engineering Change Request (ECR) : Un problème, si retenu, peut donner lieu à une ou plusieurs demandes de changement. Cette étape consiste à consolider les analyses sur les objets potentiellement concernés et impactés.
Ordre de modification ou Engineering Change Order (ECO) : Si l’ECR est accepté, on passe à un ordre de changement pour valider la liste complète des objets impactés devant être modifiés.
Grâce aux référentiels Produit, les processus de modification sont automatisés en suivant une logique d’étapes qui garantit une efficacité et une rapidité dans la réalisation des changements sur un produit donné. L’outil permet de gérer les passages de versions majeures et mineures sur chaque composant de la nomenclature et peut même produire une matrice d’impact sur le reste de la structure du produit et proposer d’appliquer des modifications sur d’autres composants.
Conclusion
Depuis son arrivée, le Digital a eu un impact de plus en plus important sur le monde de la Data avec un besoin croissant de garantir la consistance des données sur l’ensemble des canaux. Grâce à lui, le rythme ne cesse pas d’accélérer et il demande encore plus de rigueur dans la gestion des données Produit. Cette dernière, en plus de sa particularité, est devenue plus challengeante pour les entreprises avec des clients de plus en plus exigeants, des contraintes réglementaires en évolution continue et dans un marché de plus en plus compétitif.
Contrairement aux référentiels génériques de données, les référentiels de données Produit permettent aux entreprises de surmonter ces défis en leurs offrant un panel étendu de fonctionnalités et en introduisant plusieurs concepts pour les aider à améliorer les processus de gestion des données produit et à maîtriser les étapes du cycle de vie.
Si vous avez des questions sur les référentiels produits ou souhaitez être accompagnés sur le sujet ? Contactez transfodata@rhapsodiesconseil.fr
Découvrez-en davantage concernant l’expertise de Zied : Transformation Data.
Transformation de l’entreprise : tout le monde doit être focalisé sur la réalisation des bénéfices
Transformation de l’entreprise : tout le monde doit être focalisé sur la réalisation des bénéfices
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.
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.
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.
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é ?
