.svg){kind=logo}
Par Charles Parat, Directeur Conseil Data
AGILE TRANSFORMATION :
Accompagner et supporter la transformation data-driven de l’entreprise par l’apport continu de nouvelles valeurs métiers
Dans les chapitres précédents nous avons passé en revue ce qu’il faut faire pour servir les besoins métiers d’une organisation en s’appuyant sur une utilisation vertueuse des données utiles :
• comprendre les enjeux métiers et identifier les données qui comptent pour piloter l’efficacité des processus et envisager leur amélioration
• maîtriser et partager ces données
• fournir des présentations et des analyses de l’information qui servent les métiers
• s’appuyer sur la donnée qualifiée pour prévoir ou prédire en pilotant les activités par l’anticipation
La Transformation Agile par la Business Intelligence, que nous évoquons à présent, est une affaire à la fois d’état d’esprit, de méthodes et d’organisation.
1. L’état d’esprit Transformation Agile
Si vous avez en tête qu’une entreprise doit s’améliorer et se transformer tous les jours sans attendre qu’elle dysfonctionne, alors vous avez l’esprit qu’il faut.
Donc dès qu’il apparait que quelque chose mérite d’être amélioré dans la fourniture du service de Business Intelligence, vous allez vouloir le répertorier, le comprendre et y apporter une solution au plus tôt et au meilleur coût des ressources mobilisées.
C’est le sens de la transformation agile.
Cela implique une vigilance business permanente et la certitude qu’un cas identifié trouvera écho auprès de tous les contributeurs concernés.
Cela pré-suppose aussi que la culture de l’entreprise soit homogène dans cette aspiration à s’améliorer en continu par la production d’une information à son meilleur niveau, et que chacun y connait son rôle et sa responsabilité pour la contribution qu’on attend de sa part au travers de process clairs et partagés.
Si ce n’est pas encore le cas dans votre organisation mais que vous la sentez mure pour cette mutation, alors vous comprendrez l’importance des sujets suivants.
2. Les méthodes de la Transformation Agile
Quand on entend « agile », l’esprit de l’informaticien comme celui de l’utilisateur qui a participé à des projets digitaux, entend « méthode agile, Scrum, sprint, … ». Il y a quelquefois de ça… mais ce n’est pas tout à fait ça et tout ne tourne pas uniquement autour de développement d’applications ou de data products.
Les méthodes de la Transformation Agile consistent à délivrer en permanence une valeur supplémentaire sans remettre en cause brutalement des acquis de nature culturelle, organisationnelle ou technologique.
Elles permettent aussi d’anticiper des chantiers plus structurants, pour les aborder en mode « conduite du changement », au rythme indispensable à leur appropriation par les acteurs clé pressentis, et en ménageant des sacrifices budgétaires trop brutaux.
Un maître-mot de cette transformation agile est « feuille de route ».
Il faut considérer que l’amélioration B.I. de l’entreprise est un chantier qu’on ouvre quand on a pris conscience de la multiplicité de ses projets et jalons… et qu’on ne le refermera jamais !
Il devient un processus de fond qu’il faut décrire, partager et surveiller pour assurer son adaptation aux évolutions du contexte des métiers, de l’organisation, de la technologie… et des moyens qu’on peut lui consacrer.
Les méthodes applicables à ce chantier sont celles qu’on retrouve dans l’industrie, dans l’urbanisme… partout où on cherche à assurer le progrès et la durabilité d’un système de production. Ainsi, pour le chantier Data, le système génère des Data Products qui doivent apporter une valeur de progrès tout au long de la vie de l’entreprise. Ces Data Products reflètent des usages de l’information qu’on a réussi à systématiser, et d’autres qu’on projette de servir par la B.I.
La feuille de route de transformation et le portefeuille de products
Le patrimoine métier que produit et entretient cette feuille de route est donc un portefeuille de Data Products et de Data assets sous-jacents.
Pour préciser, les data products sont plutôt des rapports, des tableaux de bord, des analyses guidées ou des points de vue en self-service.
Les data assets sont plutôt des ensembles de données documentés et qualifiés qui servent à nourrir les data products.
Certains sont spécifiquement construits pour un product particulier, les autres sont des « datasets » (ensembles de données) communs à un plus ou moins grand nombre d’usages directs (les products se sourcent directement sur eux) ou indirects (ils servent de données élémentaires à des traitements de transformation pour les précédents). Ces data assets sont documentés dans les fameux Data Catalogs qui sont devenus indispensables à la bonne tenue d’un système B.I.
La feuille de route est le chemin que l’entreprise prévoit pour mettre en œuvre et entretenir les data products et aussi pour transformer le contexte de l’entreprise pour tirer plus de valeur de ces products ; le portefeuille de Data Products représente en quelque sorte la « gestion du parc » des usages servis et à servir par la B.I.
Un peu à la manière d’une gestion de programme immobilier : quoi, pour qui, avec qui, quand, combien, quel bénéfice attendu, quel statut, quelle priorité …
Les deux outils pris ensemble sont le référentiel de coordination entre la direction, les métiers et la DSI. Les 2 premières méthodes évoquées sont donc, la gestion de la feuille de route et celle du portefeuille des data products.
La prise en compte des demandes métier
Le sens même de la B.I. est de satisfaire les besoins d’information des métiers. Dynamiser l’envie de progrès par plus d‘ information pour éclairer la prise de décision, passe par l’assurance que tous les besoins exprimés sont pris en compte et qu’ils sont traités au fil de l’eau.
Le processus global n’implique par l’émetteur métier à toutes ses étapes mais celui-ci doit rester informé des différentes étapes que suit sa demande quelle qu’en soit l’issue : une pleine satisfaction, un rejet, une adaptation négociée, un délai …
Chaque organisation déclinera le processus à sa convenance, selon sa stratégie et ses moyens, mais le traitement de la demande est un processus structurant pour déterminer les rôles et responsabilités de chacun des contributeurs, jusqu’à la livraison et au support du potentiel data product final.
Mais d’emblée, et pour ne pas développer de data products de manière désordonnée ou redondante, les premières étapes de la prise en compte d’une demande vont nécessiter :
- un owner du traitement de la demande
- un échange sur la définition précise de la demande
- une vérification des data assets/products existants pour la servir (voir méthode de documentation)
- une évaluation du bénéfice de la demande
- une évaluation de faisabilité du data product
- une évaluation du coût du data product attendu
Le système de prise en compte doit être documenté et traçable. Dès la demande acceptée, la data product potentiel est intégré au portefeuille de products.
La conception (et l’évolution) des Data Products
C’est lors de la conception qu’on va retrouver l’aspect collaboratif métier/IT des sprints chers aux méthodes agiles.
Il faut impliquer les utilisateurs les plus représentatifs de l’usage attendu et travailler sur l’experience qui correspond le mieux à l’ergonomie, la cinématique, la présentation, la sémantique qui fera la performance du service à délivrer par le data product.
On travaille sur de la maquette au plus proche du rendu de l’outil final, on montre les résultats le plus rapidement possible et on procède par itérations rapides jusqu’à une validation expresse.
Si le data product est complexe on multiplie les sprints pour régler chaque point précis de compréhension mutuelle, sans perdre de vue la cohérence globale du produit.
Le dispositif idéal est de constituer des binômes très impliqués métier/IT qui travaillent « au coude à coude » le plus souvent possible.
On met le produit à l’épreuve de l’usage au plus tôt, même s’il s’agit d’un MVP (minimum viable product) à partir du moment où il contient l’essentiel des fonctionnalités attendues ou au moins les plus critiques à la compréhension mutuelle métier/IT de l’enjeu du product.
On n’hésite pas à engager des phases pilotes surveillées de près. Et on réagit au plus vite aux problèmes rencontrés et aux suggestions remontées.
La mise en production agile (DevOps/DataOps)
Les « trains » de mise en production de nouvelles chaînes applicatives ou de modifications (évolutions/corrections) sont souvent un frein sévère à la perception par les métiers que la valeur nouvelle est disponible au fur et à mesure des validations fonctionnelles et ergonomiques.
C’est d’ailleurs un des arguments préférés de départements métiers sur-équipés en compétences mixtes fonctionnelles et techniques, pour entretenir une forme de shadow-IT ou de faire perdurer des situations de pilotes. C’est un moyen d’éviter le passage jugé trop lent en production, et pour garantir la réactivité des évolutions au plus près des utilisateurs. C’est une dérive fréquente qui pénalise la collaboration IT/métiers et qui peut s’avérer très coûteuse et constituer une certaine « dette » applicative insoupçonnée.
Ce processus de DevOps essentiellement technique est sans doute un des plus compliqués et méconnus de la Business Intelligence. Difficile pour les métiers d’apprécier l’impact en production de la nouvelle fonctionnalité désirée : de fait, la valeur apportée par un nouveau data product n’est pas forcément proportionnelle à la difficulté technique de son insertion dans le panorama de production informatique.
Evidemment, plus l’usage a nécessité de trouver de nouvelles données, de faire des transformations complexes, d’ajouter des composants logiciels ou d’infrastructure, et plus l’impact sur la mise en production se fera sentir dans les délais de mise à disposition.
L’entreprise doit donc souvent réformer ses capacités de réaction à ces mises en œuvre … sans sacrifier à la rigueur et à la sécurité de cette discipline qui fait souvent intervenir des compétences techniques pointues et très diverses.
Le pilotage des projets
Piloter un projet, c’est surtout assurer la livraison du résultat attendu dans les coûts et les délais prévus… voire mieux, plus rapide et moins cher !
En plus de l’utilisation d’outils appropriés à la complexité du projet, le pilotage tire son excellence de la détermination de faire intervenir à temps les bonnes ressources sur les différentes tâches du planning.
Lorsque le produit attendu a pu être parfaitement spécifié voire très avancé vers un niveau de conception détaillé et que le métier a été impliqué jusqu’au planning de réalisation, le pilotage est balisé.
Le plus souvent, le planning initial doit être adapté, pour de multiples raisons, et souvent très tôt si le pilotage est bien fait, puisque les éléments perturbateurs du planning sont souvent déterminables une fois seulement le projet commencé.
Toute l’habilité du chef de projet tient alors dans sa capacité à ré-agencer le planning, les ressources et… le budget, voire à ramener le projet à une plus simple expression, quitte à prévoir des lots successifs ou décalés.
Au plus près des correspondants métiers et IT qui doivent rester impliqués tout au long du projet, il doit assurer le maintien d’un cap qu’il faut quelquefois re-négocier, avec les clients et ressources internes et les immanquables ressources sous-traitées.
La chaîne de conception du data product est semée d’embûches et le pilotage de projet lui-même doit être à la fois rigoureux et flexible. Les priorités peuvent rapidement changer, comme la disponibilité des ressources.
Il est donc essentiel de considérer qu’il soit possible de définir tout ou parties du projet selon des modes de réalisation différentes. Ces modalités dépendent souvent de la nature de la contractualisation avec des fournisseurs de conseils et de services : en mode forfaité, en mode assistance technique, ou en mode « projet », ou en « centre de services ». ..
L’envisager au plus tôt et prévoir des plans B est un gage de flexibilité pour adapter le pilotage du projet à son contexte potentiellement évolutif.
La recherche et le design de nouveaux business cases
L’essor de la Datascience depuis une dizaine d’années a amené les décideurs d’entreprise à innover autour de la Data, voire à la « monétiser ». S’en est suivi une époque bénie pour les cabinets de conseils où il s’agissait d’aider les métiers à trouver de nouveaux « business cases » (cas d’usage), et si possible « disruptifs ».
Au-delà de l’effet de mode et de l’espérance d’une pépite business découverte par sérendipité (« lancez des algorithmes sur toutes sortes de données et vous trouverez des trésors que vous ne deviniez pas »), les organisations ont ressenti ce besoin d’exploration des données. Beaucoup ont constitué des équipes (squads, c’est plus chic) de data-engineers et de datascientists chargées d’aider ou d’inciter les métiers à travailler ensemble les données disponibles (internes mais surtout externes) qui pourraient révéler de nouveaux leviers d’amélioration du business, des process, voire des diversifications prometteuses.
Dans un contexte d’évolution externe et interne forte des entreprises et des mentalités, comptant sur l’apport de collaborateurs plus « digital-natives » et d’un volume de données contextuelles toujours plus impressionnant, il est important de prendre du recul pour sortir des habitudes.
Les ateliers de découverte ou les datalabs sont le support de ce type de démarche, et il est important de comprendre dans quelle mesure les principes du design thinking, par exemple, peuvent aider une organisation à remettre en cause ses process sur la base d’une meilleure compréhension des données.
C’est aussi un excellent moyen d’immerger des populations métiers dans les modèles logiques de données qu’ils utilisent souvent imparfaitement ou incomplètement : c’est un levier fort d’amélioration de leur culture Data appliquée à leur métier.
La communication, la formation et l’animation
J’en vois certains sourire : quand on parle de communication et d’animation dans un cadre informatique, on a vite tendance à passer pour des gens pas sérieux…, de gentils animateurs, des « gens de la comm’ » … !
En l’occurrence, c’est sans doute un des leviers les plus importants pour rendre l’entreprise efficace dès le démarrage du chantier Data, et pour soutenir l’effort sur le long terme :
- Communication : partager l’information sur la stratégie, les objectifs, la roadmap, les projets, les outils, les réussites, les retards, les modifications d’organisation, de process…
Et rendre tout un chacun autonome dans son accès à ces informations. A la fois organiser le « push » (publications périodiques, évènements internes, …) et favoriser le « pull » (portail, espaces collaboratifs, tutos, témoignages, gestion organisée de contenus) .
Rappeler sans cesse l’intérêt et la facilité d’accéder à la documentation complète du système B.I. Elle doit être organisée à la fois pour simplifier sa mise à jour par chacun des contributeurs métiers et IT au fil de l’eau, et pour rendre efficace et immédiate sa recherche exploratoire (structuration, moteurs de recherche, ergonomie des classements, …, glossaires, catalogues, portefeuille des produits, …)
- Formation : définir les cursus de sensibilisation et de formation à systématiser selon les différents profils et garantir que la culture Data de l’entreprise est réelle, partagée, voire unique.
Il ne faut pas négliger ce facteur intéressant de fierté des collaborateurs : reconnaissance, responsabilité, esprit d’entreprise, sensation de servir un collectif, découverte des « autres ».
Il faut aussi assurer la remise à niveau de formations oubliées, prévoir la montée en compétence quand les rôles changent et engager les nouveaux arrivants au juste niveau de compétence de leurs nouvelles attributions.
- Animation : amener l’engagement au niveau désiré, le maintenir sur la durée et assurer les immanquables rotations de contributeurs sur les différents rôles, traquer la perte de motivation et ne pas hésiter à re-distribuer les rôles pour éviter l’essoufflement.
Repérer les facilitateurs et les « locomotives », relancer les sponsors et les impliquer régulièrement.
Reconnaître et valoriser les apports de chacun.
Prendre le pouls des communautés et les aider à définir pour chacune sa propre roadmap vers la satisfaction de tous les usages !
3. L’organisation de la Transformation Agile
L’entreprise a défini une stratégie avec des objectifs, elle doit alors s’assurer des moyens qu’elle consacre pour les atteindre.
Le plus délicat des sujets est l’organisation et les ressources qui vont constituer le moteur de la transformation.
S’il n’y a pas d’organisation type, on peut noter une communauté de vision des entreprises les plus avancées autour de principes simples :
1. Si on veut que la culture soit commune et efficace, il faut :
- distribuer les rôles au plus grand nombre
- limiter à l’essentiel la création de postes full-time dédiés à la transformation continue du chantier Data
- reconnaître que cette transformation aura un coût supplémentaire par rapport à la situation de départ
2. Si on veut que la transformation permette une collaboration active et permanente entre métiers et IT et qu’elle serve la stratégie de l’entreprise, il faut que cette transformation soit pilotée par une autorité transverse :
- qui assume les objectifs posés par la Stratégie Data et en déduit ses propres jalons pour son action
- qui supervise et coordonne la collaboration des métiers et de l’IT
- qui rend compte à la direction de l’organisation (comex, board, …)
3. Si on veut que l’entreprise s’aligne sur le sujet Data derrière une autorité ad hoc, sans pouvoir hiérarchique sur les autres directions de l’entreprise, il faut un engagement fort de la direction et un sponsor identifié et engagé au sein même du Comex
4. Si l’enjeu est de distribuer les rôles de la transformation au plus grand nombre de contributeur•trices, il faut :
- organiser les groupes d’intérêt communs en communautés et s’assurer qu’elles poursuivent toutes des objectifs qui concourent à l’accomplissement de la stratégie Data de l’entreprise.
- admettre que ces rôles vont affecter la charge des contributeurs par rapport à leur charge de travail initiale et quantifier le temps alloué à ces rôles.
En quelques lignes, voilà résumés les principes qui ont permis de légitimer une organisation collaborative qui se superpose aux organigrammes hiérarchiques de l’entreprise et qui se centre autour du rôle-clé du Chief Data Officer et de son Data Office, tel que peut l’illustrer (très grossièrement) le schema ci-dessous.
Voici les principes posés. Nous espérons qu’ils sont une illustration facile à comprendre par tous dans votre organisation et que tout au long de cette série d’articles, nous vous aurons aidé à assimiler des concepts souvent cités, mais rarement présentés bout à bout.
Nous l’avons fait dans un souci de cohérence globale autour de ce que beaucoup appellent l’entreprise « data-driven ».
Vous aurez compris, qu’au-delà de l’incantation, il y a beaucoup de choses à penser et à mettre en œuvre pour atteindre ce bel objectif.
Nos clients savent que c’est un chantier essentiel et qu’il faut l’aborder avec réalisme et opiniâtreté, et que les gains visibles sont le résultat de nombreux petits pas de progrès. Un juste équilibre entre ambition et réalisme.
Lire également
La Business Intelligence en 3 étapes
Process Intelligence : comprendre comment les données circulent
Data Intelligence : rendre la data disponible
