Si la question de la digitalisation ne se pose plus, celle de sa mise en œuvre est quant à elle au cœur des stratégies actuelles des entreprises. (Tout le monde en parle mais le passage à la mise en œuvre n’est pas facile) Le décalage croissant entre l’IT et les attentes des métiers est un DÉFI à la transformation numérique, les efforts des DSI pour moderniser l’outil informatique apparaissent parfois en décalage ou en deçà des attentes des utilisateurs.
La transformation numérique n’est plus un choix mais un impératif, une obligation
On a longtemps délaissé (du moins, ce n’était pas une priorité) l’environnement de travail (workplace) des salariés demain il fera partie des priorités (50% des DSI français ont un projet digital autour de l’environnement de travail utilisateur sur 2019 sources IDC), une évolution qui doit être attribuée aux attentes et à la pression des métiers/utilisateurs en matière d’expérience utilisateur.
Les DSI se déclarent majoritairement insatisfaits des performances des partenaires auxquels ils font appel (support très classique drivé par les coûts et dont la Qos est portée par les individus). Entre 55% et 68%* (Source IDC) des responsables se déclarent déçus et près de la moitié d’entre eux (49%) envisagent de changer de partenaire. Un pourcentage plutôt alarmant.
L’enjeu donc pour l’IT (donc les DSI) consiste à équilibrer innovation et excellence opérationnelle. Voire à les combiner. Les nouvelles générations d’outils numériques sont d’une aide précieuse : big data, réseaux sociaux, cloud, mobilité, Internet des Objets, agents conversationnels, etc. dissimulent un potentiel d’innovation quasiment illimité pour améliorer l’expérience client, mettre à disposition des services hyper-personnalisés et instantanés. Ne pas oublier la génération millenium constituera la moitié de la population active d’ici 2020 donc juste après demain.
Priorité à l’amélioration de l’expérience client
La mise en place d’une « Digital Workplace » représente ainsi la première étape d’une stratégie de Transformation Digitale orientée utilisateur et unifiant les technologies nécessaires à la productivité des utilisateurs.
Une définition simple à retenir de la Digital Workplace : Offrir à l’utilisateur une interface moderne facilitant le travail au quotidien, personnalisée, plus fluide, plus simple, plus rapide, efficace et multi accès.
Repenser le Support IT au sens large en intégrant la dimension digitale liée à des innovations technologiques et des nouvelles pratiques est une réelle opportunité pour la DSI. Elles verraient ainsi leur service support amélioré et leur relation client renforcée.
L’orientation usage, la meilleure façon de faire
Avoir une vision usage et non techno ni innovation pour de l’innovation
Être en adéquation avec les réelles attentes des utilisateurs
Avoir une stratégie d’écoute des métiers/utilisateurs, afin qu’ils puissent se projeter dans les nouvelles solutions qu’on leur apporte
Donner aux utilisateurs le temps d’exprimer leurs frustrations
Avoir une approche par métier par profil par besoin
Réconcilier ROI pour la DSI et Satisfaction pour les utilisateurs
Cibler des services à l’usage
Avoir un accompagnement quasi permanent des métiers est la clé essentielle de la réussite
Segmenter et Profiler l’accès aux services informatiques
Analyser le marché et identifier parmi la richesse du marché IT la les solutions les plus adéquates au contexte métier-
Les entreprises ayant des services IT modernes et orientés métier récoltent rapidement les fruits
Pour y aller, un accompagnement peut sembler nécessaire, pour :
Avoir une vision des usages & des tendances et les acteurs du marché
Accompagner le développement du Digital et la transformation du Service dans votre contexte
Repenser l’environnement de travail de demain
Placer les usages au centre des initiatives ET concrétiser la valeur
Co-Construire les scénarios des trajectoires de transformation
Mise sous contrôle du projet de transformation
Et l’accompagnement au changement avec un plan marketing de la transformation très tôt dans le processus.
GoldenData – La voie pour augmenter la valeur des données
#GoldenData - La voie pour augmenter la valeur des données
30 novembre 2018
– 1 minute de lecture
Data & IA
Albert Bendayan
Directeur Architecture, Data & Transformation
Le 27 novembre, à l’hôtel Peninsula, plus de 50 participants de tous les secteurs d’activité ont assisté à notre événement « Maîtriser et Augmenter la valeur des données ».
Cette table ronde était l’occasion de faire un 360° sur les usages faisant des données un actif majeur pour les organisations. Rythmée par les témoignages exceptionnels de Lydia Bertelle de Paris La Défense, Laurent Drouin de la RATP, Isaac Look de Malakoff Médéric et l’artiste Filipe Vilas-Boas, nos intervenants ont pris le temps de, partager leur vision, présenter leurs cas d’usage et détailler les leviers et les freins afin de structurer une approche pragmatique pour augmenter la valeur des données.
4 temps forts ont rythmés cette matinée:
Le regard Artistique et Numérique porté par Filipe Vilas-Boas, un artiste citoyen qui a installé un Casino permettant à tout un chacun de réfléchir et comprendre l’impact des données sur nos vies.
Les choix et investissements de Malakoff Médéric en temps et en ressources sur le sujet de la Gouvernance des Données porté par Isaac Look
Les Usages comme les vecteurs de la valeur de données, éclairés par des exemples de la RATP, portée par Laurent Drouin
L’approche choisie par Paris La Défense et Lydia Bertelle pour augmenter la valeur des données illustrant la feuille de route, le fonctionnement, les difficultés et les résultats concrets atteints.
Rhapsodies Conseil a pu, à cette occasion, présenter et remettre aux participants un exemplaire de son Livre-Blanc « Augmentez la valeur de vos données ! » détaillant sa méthodologie de mesure et d’identification des actions permettant d’augmenter la valeur des données.
Revivez les moments forts de l’évènement sur nos médias:
Vidéo
Podcast
Photos
Accueil de l’Hôtel Peninsula
Introduction de la Table Ronde
Casino Las Datas
Evénement DATA – Témoignage Isaac Look de Malakoff Médéric
Vous gérez un produit : apprenez à prioriser et à mesurer la valeur de votre produit !
Comment choisir entre développer un « bot de messagerie » sur votre application ou bien un nouvel onglet ? Peut-on mesurer en amont la valeur de ces fonctionnalités ? Quelles sont les approches pour calculer, voire traduire cette valeur en € ?
Voilà les problématiques auxquelles font face les Product owner pour qui les métriques sont devenues une obsession.
Nous allons aborder les concepts et les outils à maitriser pour y arriver, accrochez-vous, c’est parti !
Prioriser, méthode 1 : Moscow
Ci-dessus un exemple d’application de la méthode MOSCOW sur le sprint backlog d’un site de vente quelconque.
La première approche qui se veut pragmatique n’est jamais très loin de la méthode MoSCoW (Must have, Should have, Could Have et Won’t Have). On affecte un niveau de priorité aux « actifs / features / fonctionnalités* » que l’on veut intégrer au produit. Pour le faire bien, on essaie de le faire souvent, en travaillant uniquement ce qui est le plus prioritaire. * pour un produit qui n’est pas informatique ou qui comporte des contenus sans développements (vidéos, …), on pourra parler d’actif ou de feature
Par exemple, imaginons que vous ayez 3 mois pour développer un site de vente, comment s’y prendre ?
On liste l’ensemble des grandes fonctionnalités : accéder au catalogue de produits, visualiser l’historique des achats, acheter, etc …
On assigne une priorité à chacune
Les Must have : acheter, accéder au catalogue de produits
Nice to have : accéder à l’historique de ses achats…
Le planning reste clair : les « must have » seront développés en premier et les « nice to have » restants, etc … si jamais il nous reste du temps !
Prioriser, méthode 2 : orientée données
La seconde, orientée données, s’inscrit une démarche Lean Startup (Build, Measure, Learn).
Ci-dessus un exemple d’application orientée données sur le développement de facebook connect pour un site de vente quelconque.
Facebook Connect est un module social externe ousocial loginpermettant à un site web de proposer à ses visiteurs d’utiliser leur compte Facebook pour s’identifier sur le site visité. On fait des hypothèses basées sur notre compréhension du marché, on mesure notre adéquation et on apprend de ses choix. Pour le faire bien, on met en place des standards de calcul, on identifie au préalable les métriques à suivre pour un actif donné et on les suit. La dernière étape permet de savoir dans quelle mesure valider ou invalider ses choix. Dans notre exemple ici, on estime que la valeur (ou BV : « Business Value ») de développer Facebook Connect pour que nos visiteurs s’identifient sur notre site de vente est de 10 000€ par jour. Une fois la fonctionnalité priorisée/développée, on suit notamment le taux de conversion : pourquoi n’atteint-il pas les 20% d’augmentation estimés ? Le taux d’abandon en page d’identification a lui fortement diminué, le taux d’abandon sur une autre page a t il augmenté ? Où ? … A mi-chemin entre les 2 approches ? Toutes les méthodes de priorisation/mesure que l’on appellera « par scoring ».
Ce n’est pas indispensable d’être orienté données
Tout d’abord, la force de l’approche orientée données réside dans sa capacité à adresser des problématiques business globales et complexes. C’est donc dans ce type d’environnements (où la connaissance des usages est particulièrement importante) qu’elle prend tout son sens, ce n’est peut-être pas le cas de votre environnement… La deuxième variable est temporelle, il faut savoir qu’un produit suit un cycle de vie :
Tant qu’il n’a pas atteint sa forme minimale viable, ça n’a peu/pas de sens de chercher à valoriser les actifs qui le composent. Le MVP est par définition le premier ensemble qui constitue le produit que l’on peut valoriser et le produit finit sa vie lorsqu’on ne peut plus le valoriser.
Enfin la dernière composante est le rapport à la concurrence. « Combien va me rapporter tel service ? Telle feature ? Quel est la « business value » de passer maintenant sur telle technologie ? Ou au contraire, combien est ce que ça va me couter de ne pas faire cette migration pendant 1 an ? » Ce sont des questions qu’il est d’autant plus naturel de se poser que la capacité d’une entreprise à mettre sur le marché très rapidement un produit ou une nouvelle version est devenu un facteur concurrentiel à part entière. L’approche garantit des retours fréquents et qualitatifs permettant de s’adapter d’autant mieux dans ce type de contexte.
Quels sont les outils pour calculer la valeur d’une fonctionnalité de son produit ?
La valeur « business » représente ce que vaut une fonctionnalité ou un service en embrassant tous les aspects qui font sa force. Par défaut il ne faut pas perdre de vue qu’il y aura toujours certains aspects qui seront mal appréhendés par ces méthodes : comme la valeur qui est créée lorsque des utilisateurs interagissent avec notre contenu ou alors la « prime au premier » que l’on obtient à délivrer un service qui n’existait pas auparavant… L’important est donc de savoir que cette mesure ne se substitue pas à l’intuition et d’utiliser des métriques de calculs comparables pour chacun de vos actifs :
Pour une fonctionnalité ou un service qui est supposé générer des revenus ou une réduction de couts, c’est bien ce que l’on cherchera à estimer pour calculer un ROI (cf. 2nde image)
Idem pour un actif qui contribue à ce qu’un autre rapporte : si un actif ne peut fonctionner sans un autre, c’est que cet actif contribue à la valeur générée : Imaginons (si on reprend notre exemple) que le développement de FB Connect pour notre site de vente nécessite le développement d’une autre fonctionnalité ou d’un autre actif. On parlera alors d’un « enabler » et il s’agira d’estimer dans quelles proportions il contribue à notre hypothèse d’augmentation de BV portant sur l’augmentation de taux de conversion (et potentiellement à d’autres) pour en estimer la valeur.
Pour d’autres fonctionnalités, services ou contenus, liés à une échéance, comme une amende réglementaire (Hello GDPR) ou un spot publicitaire, on estimera à l’inverse ce que cela nous coute de ne pas faire, on appelle ça le cout du délai :
Exemple d’application du coût du délai sur 2 contenus comparables
Quantifier la valeur d’une feature n’a pas de sens si l’on ne suit pas les résultats …
L’AB Testing ou Split Testing est un bel exemple d’utilisation bout en bout de la donnée. Le procédé est notamment poussé par de nombreux designers pour affiner leurs choix et leur compréhension des usages. Il s’agit de tester plusieurs variantes d’un même élément directement face à des utilisateurs : les utilisateurs sont renvoyés aléatoirement vers chacune des variantes pendant un temps donné. On garde à la fin la meilleure variante : celle qui a les meilleurs taux de conversion, de transformation ou n’importe quelle métrique que vous voulez améliorer.
Exemple d’AB Testing sur une page web
A ce jeu, les principaux leaders sur des services numériques excellent (75 % des sites ayant un trafic supérieur à 1 million de visiteurs font de l’A/B Testing). Au-delà d’optimiser la décision, le procédé permet d’en apprendre plus sur ses visiteurs et ce qui fonctionne, d’en connaitre finalement plus sur la « capitalisation » vue de l’utilisateur de son produit. Même si l’on n’est pas dans une logique d’AB Testing, lorsque l’on déploie une fonctionnalité ou un service, il faut suivre :
l’impact sur les métriques identifiées auparavant, on cherche les « tendances »
l’écart avec ses hypothèses, cela permet de se poser les bonnes questions et de tirer les bons enseignements au moment de refaire des hypothèses
l’évolution de la valeur des différents actifs qui composent le produit,
C’est tout l’intérêt de l’approche qui en dépend… Pour finir, il faut garder en tête que cette démarche orientée données est intéressante parce qu’elle pousse à la réflexion autour de vous, améliorant ainsi votre compréhension du marché et celle de vos équipes. Pour autant, nous travaillons tous dans des organisations dont la valeur générée ne correspond pas à la somme des valeurs individuelles de ses produits. Contribuer à, collaborer avec d’autres équipes vous mèneront parfois à faire des choix qui ne favorisent pas la valeur de son produit, ce sont pourtant souvent de bons choix !
Tout comme une dette financière choisie intelligemment peut être synonyme de succès financier, toutes les dettes techniques ne sont pas nécessairement handicapantes pour l’entreprise, et peuvent aussi être un levier de croissance rapide. Cela se vérifie tout particulièrement lorsqu’on ajoute un nouveau système pour prendre des parts de marché : la dépense présente pour répondre au « time-to-market » est faite dans l’espoir d’un gain futur.
Attention cependant, tout comme les dettes financières non maîtrisées, les dettes techniques peuvent devenir un « poids mort » pour l’entreprise. En cas de difficultés trop importantes, elles accaparent les équipes et engendrent une évolution défavorable du rapport Run / Projet. Cela est synonyme de baisse dans la capacité à livrer de nouvelles fonctionnalités, mais aussi souvent de démobilisation des équipes, voire de turn over. Dans les cas extrêmes, par exemple pour les entreprises avec des ressources limitées, cela peut devenir léthal si la direction n’est pas vigilante à cet indicateur Run/Projet.
C’est pourquoi dans ce premier article, nous avons identifié 3 types de dettes IT et 3 parades pour les traiter :
Dette technique opportuniste et plan de remédiation
Un concepteur sait, en général, qu’il y a deux façons de créer une fonctionnalité : la bonne ou la rapide. La manière rapide n’est pas nécessairement la mauvaise, car elle consiste à ne pas faire de sur-qualité. Cependant, l’économie peut très bien avoir été faite au détriment de la scalabilité : la bonne idée d’un jour se révèle être un choix non pérenne. Bien souvent le concepteur est contraint de faire ainsi pour réduire le time-to-market.
Ce choix est parfaitement acceptable, mais il faut l’accompagner d’un plan de remédiation, pour assurer la pérennité du nouveau système une fois que celui-ci en sera en production. Dans le cas contraire, les dettes techniques vont s’accumuler petit à petit, ce qui entraînera inexorablement la baisse de la qualité de service pour les utilisateurs, la frustration des équipes en charge de la maintenance applicative et l’accroissement des coûts d’exploitation du fait des incohérences techniques et fonctionnelles à corriger continuellement.
Ce type de dette doit donc être tracé, pour permettre des actions de remédiation. En parallèle, un sponsor / product owner doit être tenu responsable de l’évolution de la dette technique sur son périmètre, et donc être objectivé sur ce sujet. La cohérence n’est pas un artifice.
Dette technique liée à l’innovation et pilotage des exigences
Dans le monde de l’IT, de nouveaux patterns et technologies apparaissent sans cesse. Il en va de même pour les usages.
Un choix de conception, à un moment donné, peut être remis en cause soit par une évolution des usages métiers, soit par l’apparition d’une nouvelle technologie entraînant une obsolescence fonctionnelle.
Ce type de dette finit toujours par apparaître qu’on le veuille ou non. Il est donc important de sensibiliser le sponsor / product owner à la nécessité de suivre la satisfaction des exigences sur son périmètre, afin de déclencher des actions de remédiation le cas échéant.
Dette technique « endémique » et vastes chantiers de modernisation
Ce type de dette est relatif aux vieux systèmes, sur lesquels ont été empilées au fur-et-à mesure des demandes d’évolution de nouveaux traitements complexes, sous forme de « verrues », jusqu’à créer une complexité telle que les systèmes deviennent impossibles à maintenir / faire évoluer, sans parler du turn over, entraînant inexorablement une amnésie informatique.
Dans le cas de fonctionnalités critiques pour le métier, cela constitue un risque opérationnel pour l’entreprise.
Ce type de dette doit être évité autant que possible, et faire l’objet de vastes chantiers de modernisation. Souvent, cela implique un remplacement pur et simple du système par un nouveau, plus adapté, et surtout mieux conçu.
Il existe aussi d’autres types de dettes, notamment celles créées inconsciemment …
Dans tous les cas, un système de classification des dettes techniques va permettre de les identifier et de sensibiliser les donneurs d’ordre, et leur proposer des plans de résolution adaptés :
Plan de remédiation pour favoriser la scalabilité et la pérennité au fil de l’eau
Pilotage des exigences pour accompagner l’évolution technologique
Vastes chantiers pour faire face à la dette « endémique »
Le sujet vous intéresse ? Restez à l’écoute, dans un prochain article, nous discuterons des différents impacts de la dette technique sur l’entreprise, et pourquoi cela n’est pas qu’une question « d’informaticiens ».
Dette technique : 3 types, et 3 approches pour la maîtriser
Avec l’arrivée récente de différentes réglementations impactant les données (RGPD, Bâle III, Bâle IV, BCBS 239), il est devenu primordial de connaître son patrimoine de données afin de pouvoir identifier et appliquer les bonnes politiques de gouvernance de la donnée (qualité, sécurité, accessibilité). Il faut que les entreprises voient cette contrainte comme une opportunité qui leur permettra à terme de faciliter leurs différents projets de transformation et de mieux valoriser leurs données.
Quel Data Scientist ou Responsable de Traitementmétier ne s’est pas interrogé sur la source d’une donnée à utiliser pour son cas d’usage ? Comment connaître son origine et son cycle de vie et s’assurer de sa qualité ? Comment savoir, au sein d’une entreprise, qui est le Data Owner sur une donnée en particulier ? Ou trouver le glossaire des termes métier associés à cette donnée ? Comment montrer à un RSSI, un DPO ou un Régulateur que les mesures de sécurité liées à une réglementation ont été associées à une donnée et mises en œuvre ?
C’est là où une solution de Data Catalog (ou catalogue de données) devient essentielle et peut vous aider à répondre à ces différentes questions. Celui-ci deviendra la base d’information centrale, un peu comme une bibliothèque, qui vous permettra de rechercher, trouver et connaître les bonnes sources de données pour vos cas d’usages Big Data ou vos traitements métiers. Ceci permet de regrouper les données au sein d’un même référentiel, de collecter, d’enrichir et de partager toutes les métadonnées associées.
Figure 1 – Exemple de métadonnées
Mais comment faire pour s’y retrouver ? Les différentes offres du marché se vantent toutes de pouvoir gérer et maîtriser votre patrimoine de données, générant, ainsi, de la valeur. Il faudra d’abord définir le périmètre de la gouvernance de données à mettre en œuvre et recueillir les exigences fonctionnelles et techniques. Ce qui suit vous aidera ensuite à comprendre ce que pourra couvrir une solution « Data Catalog ».
La fonctionnalité de base est déjà de pouvoir récupérer automatiquement les métadonnées techniques, c’est-à-dire les informations décrivant vos données d’un point de vue infrastructure (fichier, base de données, table, colonne, etc). Les éléments différenciant pour le choix de la solution vont dépendre de votre écosystème et des connecteurs nécessaires. Est-ce que vos données sont structurées, non structurées ou sont-elles sous format document ? Est-ce que vos données sont contenues dans des bases de données SQL ou noSQL ? Quel socle technologique Big Data utilisez-vous ? Avez-vous des données dans des Cloud Public ? Comment transporter ou partager vos données ? Via des traitements spécifiques, un ETL, un ESB ou via une API Gateway ?
Ces métadonnées décrivant vos données techniques comme un dictionnaire devraient être reliées à une donnée logique et une donnée métier qui sera elle-même à l’aide d’un glossaire métier.
Figure 2 – Architecture de Donnée
Un cadre de gouvernance des données avec une organisation, des acteurs, des processus et des livrables documentaires doit aussi pouvoir être décrit et déployé via un métamodèle opérationnel .
Ce métamodèle implémenté dans l’outil devra permettre de gérer des rôles et des organisations afin de pouvoir définir des responsabilités pour appliquer cette gouvernance de données. Celle-ci ne pouvant être mise en œuvre que si la donnée a d’abord été classifiée et que des politiques de gouvernance liées à un référentiel d’entreprise ou demandé par un Régulateur ont été identifiées et reliées à cette donnée métier. Tout ceci n’étant possible que si l’outil permet de gérer un modèle opérationnel de gouvernance des données personnalisables.
Parmi les autres fonctionnalités attendues pour cet outil il y a également la capacité de générer des états de Data Lineage.
Figure 3 – Exemple de Data Lineage
Cette fonctionnalité est majeure et permettra de traduire visuellement la vision 360° de vos données. Ceci vous habilitera par exemple à réaliser des analyses d’impact en cas de changement sur un système aval vous fournissant la donnée. Ces états peuvent vous aider également à analyser l’écart entre deux KPIs ou de répondre à une exigence réglementaire demandant de documenter de bout en bout comment tel indicateur aura été généré. L’outil vous permettra aussi d’avoir une vision sur la qualité de ces données via par exemple du data profiling ou des indicateurs. Ceci permettra de faire gagner du temps à vos Data Scientist pour sélectionner l’algorithme le plus approprié ou motivera votre Data Steward à sélectionner le jeu de données le plus approprié pour votre cas d’usage ou traitement métier.
Figure 4 – Exemple de Data profiling
Enfin pour terminer, cet outil devra être accessible via une application web, fournir un moteur de recherche et proposer un référentiel de cas d’usages avec les sources de données associés. Ceci activera le partage de la connaissance de ce patrimoine au travers de votre organisation et l’identification des sources de données critiques à vos traitements métiers. A terme, ce patrimoine permettra plus facilement aux métiers de générer de la valeur pour votre entreprise tout en maitrisant les règles de sécurité et accessibilité de cette donnée.
Voilà pourquoi le Data Management ne peut plus se faire via un tableau Excel et qu’un catalogue de donnée devient essentiel.
