Operational Analytics – Une nouvelle approche pour réellement actionner vos données

Si vous voulez mettre en place une organisation vraiment data-driven, vous devez adopter l’approche operational analytics. Les données ne doivent pas seulement servir à comprendre votre business, elles peuvent être exploitées pour améliorer les actions de vos équipes en temps réel. À la différence de l’approche classique qui consiste à produire des tableaux de bord et des reportings, l’operational analytics est l’art d’actionner directement vos données en les poussant dans les outils métiers au bon moment et bon endroit.

L’operational analytics repose sur une nouvelle famille d’outils : les Reverse ETL, dont le rôle est de faire redescendre les données du Data Warehouse dans les outils métiers (par distinction donc avec les outils ETL classiques, qui font remonter les données de vos sources et applications vers l’entrepôt de données).

Dans ce guide introductif, nous allons vous présenter les fondamentaux de l’operational analytics et la famille d’outils qui lui est associée : les Reverse ETL.

Qu’est ce que désigne le terme Operational Analytics ?

L’operational analytics est l’approche analytics moderne.

Quelle est la différence entre l’analytics traditionnel et l’approche « operational analytics » ?  L’approche analytics traditionnelle consiste à utiliser des données pour comprendre les opérations business, tandis que l’operational analytics utilise la donnée pour piloter les opérations business, pour driver les actions de vos équipes en temps réel. À première vue, la différence peut sembler subtile. Elle est en fait profonde. Ce sont deux manières très différentes d’utiliser les données.

L’analytics traditionnel, ce sont les fameux tableaux de bord en temps réel et les reportings périodiques créés dans ou à partir des outils de BI et de Data Visualization. Grosso modo, le travail de l’analytics traditionnel est d’utiliser les données pour mieux comprendre votre business afin de prendre des décisions stratégiques plus éclairées et de plus en plus pertinentes au fil du temps. L’analytics traditionnel répond à des questions du type : « Est-ce ce produit génère des revenus ? ».

L’operational analytics est l’art de faire parvenir aux équipes métiers (sales, marketing, support, customer success) les données dont elles ont besoin pour prendre leurs décisions. L’operational analytics donne des réponses à des questions telles que : « Quel ticket faut-il que je traite en premier ? ».

L’operational analytics évolue dans le temps court, dans le moment présent, dans l’immédiat. Il s’agit d’apporter la donnée là où il faut quand il le faut, c’est-à-dire quand les utilisateurs métiers en ont besoin. L’analytics traditionnel travaille sur le temps long.

Operational Analytics vs l’approche traditionnelle – Une question d’actionnabilité

Prenons un exemple concret pour bien comprendre la différence d’approche. Prenons l’équipe Customer Success d’une startup en pleine croissance. Cette équipe va utiliser l’analytics traditionnel pour mesurer la performance de l’activité et planifier les prochaines actions à déployer dans le futur. Le responsable de l’équipe aura besoin d’un tableau de bord de BI pour, par exemple, connaître le temps moyen de résolution d’un ticket client. C’est une métrique importante pour mesurer les performances passées. Elle fournit aussi une indication approximative pour évaluer la charge de travail future des CS. Les enseignements tirés des tableaux de bord aideront à prendre les décisions en matière de staffing et d’amélioration des process…mais ils ne seront d’aucune utilité pour les collaborateurs de l’équipe. Cela ne les aidera pas à résoudre plus de tickets dans l’heure qui vient.

Pour résoudre plus de tickets dans l’heure qui vient, le Customer Success Manager peut avoir besoin de prioriser les tickets. C’est là qu’intervient l’operational analytics. Cette approche va permettre de prioriser les tickets à partir de quelques caractéristiques clés, en allant chercher des informations dans la base de données : le client est-il membre du programme VIP ? A-t-il manifesté un risque d’attrition ? Est-il ouvert à de l’upsell ?

Pour un CSM, l’operational analytics se traduira certainement par l’ajout de quelques champs dans les tickets, mais la liste des tickets sera automatiquement classée par ordre d’importance. Il n’aura plus à se demander quel ticket prioriser. L’operational analytics aura répondu à la question à sa place.

Il s’agit bien entendu d’un des nombreux cas d’usage de l’operational analytics. Cette approche est aussi celle qui permet par exemple :

• De pousser dans Salesforce la liste mise à jour en temps réel des clients ayant la plus haute lifetime value (ou bien les clients qui achètent pour plus de XX€ / mois).
• De pousser dans Intercom les données d’usage du produit pour enrichir les interactions clients en personnalisant les messages avec des métriques d’usage.
• …/…

L’operation analytics vise l’amélioration de la performance opérationnelle de vos équipes.

En résumé :

• L’approche traditionnelle se focalise sur la compréhension du business à moyen et long termes.
• L’operational analytics se focalise sur l’actionnabilité des données par les équipes métiers.

Notre message n’est clairement pas de dénigrer l’approche traditionnelle. Les deux sont complémentaires et n’ont pas la même fonction. L’approche traditionnelle permet de prendre de la hauteur et de faire évoluer la stratégie globale de l’entreprise grâce à une meilleure compréhension de son activité. A tête reposée. Malgré tout, l’un des intérêts de l’approche opérationnelle, c’est qu’elle permet de mettre l’accent sur cette idée clé : la donnée client n’a d’intérêt que si elle est actionnée ! Collecter de la donnée pour collecter ne sert à rien. Créer des tableaux de bord n’a pas d’intérêt s’ils ne sont pas exploités pour prendre des décisions. Lorsque l’on se plonge dans cette nouvelle approche « opérationnelle » de l’analytics, on se reconnecte avec cette réalité très concrète !

Les Reverse ETL – une nouvelle famille d’outil data pour structurer cette pratique

Cette nouvelle pratique implique une nouvelle famille d’outils data et une nouvelle organisation des outils entre eux. Dans l’analytics traditionnel, qu’avons-nous en général ? Un Data Warehouse Cloud qui récupère les données de toutes les sources via un outil ETL Cloud (comme Fivetran par exemple) et les redistribue ensuite à un outil de BI (comme Tableau par exemple) utilisé pour créer les tableaux de bord et les reportings. Sauf que la plupart des utilisateurs métiers préfèrent utiliser leurs propres outils plutôt que l’outil de BI. C’est l’une des limites de l’approche traditionnelle. Comme nous le disions tout à l’heure, avoir de beaux tableaux de bord ne sert à rien s’ils ne sont pas utilisés par les équipes métiers.

Dans l’approche moderne (l’operational analytics), l’idée est de synchroniser les données du Data Warehouse Cloud directement dans les outils métiers utilisés par les équipes. Les outils qui rendent possible cette synchronisation renvoient à une nouvelle famille d’outils, appelés « Reverse ETL ». Pourquoi ? Parce que ces outils font exactement l’inverse des outils ETL classiques. Un outil ETL classique récupère les données à partir des applications (sources de données) pour les intégrer, après transformation, dans l’entrepôt de données. Un Reverse ETL est à l’inverse un outil qui va piocher les données du Data Warehouse pour les délivrer aux outils / systèmes opérationnels des équipes métiers : CRM, solution de Marketing Automation, outil d’A/B Tests, outil de GRC, etc. Le Reverse ETL se base sur du SQL.

Le Reverse ETL est la famille d’outils qui rend possible la pratique de l’operation analytics telle que nous l’avons décrite tout à l’heure. Nous disions tout à l’heure que les approches traditionnelle et moderne de l’analytics se complétaient. On peut dire la même chose au niveau de l’infrastructure IT, des outils. L’ETL ne s’oppose pas au Reverse ETL. Pour que le Reverse ETL récupère les données du Data Warehouse, il faut bien qu’elles aient au préalable été extraites des sources et transformées…via un outil ETL. La transformation de la donnée intervient avant l’entrée en jeu du Reverse ETL, même si le Reverse ETL peut également réaliser quelques opérations de transformations pour adapter la donnée au système opérationnel cible.

Une extension du rôle du Data Warehouse

Le rôle du Data Warehouse devient absolument pivot dans l’architecture IT de l’organisation :

• Il est utilisé pour intégrer, stocker, transformer et unifier les données en provenance de tous les data sources (via les outils ETL). Le Data Warehouse est source unique du vérité, il est la base de référence. Il joue le rôle de Référentiel Client Unique.
• Les équipes métiers (ventes, marketing, digital…) peuvent exploiter au mieux les données contenues dans cette source unique de vérité qu’est le Data Warehouse grâce au Reverse ETL.

Avec le Reverse ETL, l’organisation se donne les moyens de rendre les données directement actionnables par les équipes métiers. Si l’on se représente le Data Warehouse comme le sommet de la pyramide de l’infrastructure IT, on pourrait dire de façon imagée que :

• L’ETL est l’outil qui fait remonter les données issues des diverses bases et applications dans le DWH. L’ETL répond à cet enjeu.
• Le Reverse ETL est l’outil qui permet de redescendre une information actionnable par les équipes métiers dans les applicatifs métiers.

De l’ETL à l’ELT et de l’ELT au Reverse ETL

Le processus ETL (Extract – Load – Transform) est vieux comme le monde. Enfin, en tous cas il existe depuis une bonne trentaine d’années. Nous en avons décrit le fonctionnement. Ce fonctionnement est inscrit dans son nom et surtout dans l’ordre des verbes dont ETL est l’acronyme. Depuis quelques années, on parle de plus en plus d’ELT. C’est un nouveau process qui consiste à charger d’abord les données dans la base, dans l’entrepôt, bref dans le Data Warehouse, avant d’opérer les transformations. On charge (L) avant de transformer (T). Cette inversion du L et du T permet d’augmenter les cas d’usage de la donnée. C’est une question clé que nous avons longuement abordé dans notre article « Data Warehouse Vs Data Lake  – Quelle base de données pour quel besoin ?« . Lorsque l’on transforme avant de charger, on transforme en vue de certains cas d’usage prédéfinis et on se prive par conséquent d’autres cas d’usage possibles de la donnée.

Sauf que les ELT sont des outils plus complexes à manier que les ETL. Ils fonctionnent avec des Data Lakes qui stockent toutes les données en vrac de l’entreprise et sont plus difficilement exploitables par les équipes métiers. Les Reverse ETL permettent d’augmenter les cas d’usage des données tout en conservant une architecture Data Warehouse. Connecter les données du Data Lake aux outils d’activation métiers est un vrai challenge et suppose pour chaque outil la création de connecteurs sur-mesure. Les Reverse ETL proposent quant à eux de multiples connecteurs natifs qui vous permettent de connecter rapidement votre Data Warehouse à vos outils métiers.

Octolis – Le reverse ETL développé par Cartelis

Octolis est une Customer Data Platform légère conçue pour unifier vos données et les redistribuer à vos outils métiers en temps réel. Les créateurs d’Octolis (d’anciens de chez Cartelis) ont voulu, en créant cette solution, répondre aux enjeux data concrets qui se posaient aux équipes métiers. Comment mieux exploiter les données pour augmenter la performance business ? C’est cette question qui a guidé la réflexion dans la conception de cette solution qui est à la fois base de données cloud et outil de redistribution des données vers vos outils d’activation – Customer Data Platform et Reverse ETL. Pour en savoir plus, nous vous invitons à vous rendre sur le site d’Octolis et à demander une démo. Les équipes d’Octolis se feront un plaisir de vous montrer comment fonctionne la solution et surtout comment celle-ci peut répondre à vos attentes et objectifs concrets.

CRM / Data - Plus de 15 ressources & templates gratuits à télécharger.

Découvrir