Avantages stratégiques d'une architecture de données robuste

Les bénéfices d’une architecture de données bien construite vont au-delà du processus opérationnel. Les avantages s’étendent à l’efficacité opérationnelle stratégique, à des connaissances commerciales plus approfondies et à la capacité d’atteindre des opportunités commerciales adjacentes, le tout exécuté de manière plus agile. 

L' application de livraison de nourriture, revisitée, 6 mois plus tard...

Dans un article précédent, nous avons présenté un service hypothétique de commande et de livraison de nourriture et présenté plusieurs flux de travail opérationnels quotidiens clés : le processus de commande client, le flux de travail de ramassage et de livraison de nourriture et le traitement des paiements. Nous avons exploré comment une stratégie de données intentionnelle autour des entrées de données clés dans les flux de travail donne lieu à des processus commerciaux plus robustes et plus agiles.

Dans cet article, je voudrais aller au-delà de l’efficacité opérationnelle quotidienne et démontrer les avantages à plus long terme et plus stratégiques d’une conception réfléchie de l’architecture des données. En avançant de 6 mois notre scénario initial, en supposant que notre application ait été retenue, les chefs d’entreprise ont désormais identifié de nouvelles opportunités émergentes. Ils demandent désormais aux technologues avec quelle rapidité et quelle facilité les systèmes sous-jacents peuvent s’ajuster et s’adapter à certaines opportunités spécifiques et aux défis qui y sont associés :

1. La croissance du service s’accélère et l’entreprise souhaite s’étendre à d’autres villes.
2. Dans le cadre de cette expansion, le service souhaite pénétrer le marché très lucratif de Californie, qui ajoute des exigences supplémentaires en matière de gouvernance des données.
3. Les délais de livraison s’allongent, souvent en raison de pics de demande imprévus. La technologie peut-elle aider à résoudre ce problème ?
4. L'entreprise est confrontée à la concurrence de startups émergentes, et certains restaurants ont évoqué l'idée de passer à un service concurrent. Pouvons-nous démontrer une valeur ajoutée à nos fournisseurs (restaurants) pour aider à les fidéliser ?

Les quatre exemples de défis énumérés peuvent être décomposés en deux grandes catégories :

         1. Ajuster et améliorer l’efficacité des processus commerciaux quotidiens clés (« tactiques »).

         Deuxièmement, créer de nouvelles perspectives qui génèrent une valeur à plus long terme (« stratégique ») pour l’entreprise directement ou indirectement, via les clients de l’entreprise. 

Les deux premiers nouveaux défis – l’expansion territoriale et les exigences de conformité associées – concernent les processus commerciaux tactiques et sont donc de nature plus opérationnelle. Les deux derniers défis sont de nature plus stratégique.

Commençons d’abord par examiner les préoccupations tactiques et opérationnelles. 

Améliorations de l'efficacité opérationnelle

Avec l’expansion géographique dans des villes supplémentaires, nous pourrions être confrontés à quelques problèmes différents. Un problème potentiel, pour le flux de travail de livraison, est qu'il pourrait y avoir un problème de désambiguïsation avec les adresses postales : la même adresse (par exemple, « 100 Main St. ») peut exister dans plusieurs villes. Un autre problème possible est que différentes villes peuvent s'étendre sur des fuseaux horaires ; si cela n'a pas été pris en compte, alors un ramassage à 18h00. Il se peut que MDT ait une heure de retard dans la livraison à une ville voisine PDT (à 18h30). PDT). L'architecture de données décrite dans notre article précédent intégrait l'idée d'une représentation « normalisée » (unique au monde) des éléments de données, répondant ainsi à ces deux problèmes potentiels, permettant ainsi à l' application de répondre implicitement à ces exigences supplémentaires.

La deuxième préoccupation tactique est le respect des exigences supplémentaires en matière de gouvernance des données pour l’État de Californie. L’ensemble des préoccupations concernant la loi californienne sur la protection de la vie privée des consommateurs (CCPA) constitue un ensemble complet d’articles à part entière, mais l’un de ses aspects concerne la possibilité de collecter toutes les données d’un client, annotées avec la date de leur collecte, ainsi que la source des données. Comme indiqué précédemment, la création d’un cadre d’architecture de données qui permet au pipeline d’ingestion de données principal d’ajouter des annotations de métadonnées, telles que des horodatages, permet de répondre simplement et avec un minimum d’effort supplémentaire aux exigences de gouvernance des données. 

Valeur stratégique

Outre la valeur commerciale générée par les améliorations apportées aux flux de travail et aux processus tactiques quotidiens de l’entreprise, un autre avantage, sans doute plus important, est la valeur stratégique de pouvoir à la fois faire pencher la balance en faveur de l’entreprise et ouvrir de nouveaux champs de jeu auxquels participer.

Réimaginer les flux de travail opérationnels pour les applications adaptatives

L’une des catégories d’avantages stratégiques est la capacité à « faire pencher la balance » en modifiant le schéma directeur des flux de travail opérationnels clés.  Cela va au-delà de leur simple optimisation, mais aussi de leur réinvention. Une architecture de données robuste et tournée vers l’avenir permet une exploitation agile et efficace des capacités clés (agrégation et analyse de données) nécessaires pour relever le défi susmentionné de la dégradation des délais de livraison causée par la variabilité de la demande, en utilisant une tarification dynamique.

Plus précisément, en raison de la réflexion préalable apportée à l’architecture des données, elle :

• Conserve l'horodatage de chaque commande et livraison, en utilisant une syntaxe et une sémantique cohérentes, même sur plusieurs tables de base de données
• Conserve un historique des lieux de ramassage et de livraison, en utilisant à nouveau une syntaxe et une sémantique cohérentes

Par conséquent, les données de deux flux de travail différents (commande et livraison) peuvent être corrélées, catégorisées et agrégées. De plus, l’architecture flexible des métadonnées peut être exploitée pour annoter les données collectées avec des informations contextuelles enrichies à des fins d’analyse. Tenez compte du délai de livraison global : le temps écoulé entre la commande et la livraison de la nourriture. La latence peut être calculée en établissant une corrélation entre les flux de commande et de livraison. De plus, comme la représentation des données de géolocalisation dans les deux flux de travail utilise également une syntaxe et une sémantique cohérentes, les calculs de latence de livraison et les corrélations peuvent être séparés par emplacement, par exemple par code postal. Ainsi, grâce à une réflexion préalable sur la stratégie de données, nous pouvons plus facilement créer un ensemble de données sur la latence globale de livraison, avec une granularité par heure et par code postal. Enfin, en tirant parti de notre approche flexible des métadonnées, les statistiques horaires peuvent être annotées avec des informations contextuelles supplémentaires, telles que les conditions de circulation et le total des précipitations.

À ce stade, nous disposons d’informations riches à alimenter dans un pipeline d’analyse, qui peut ensuite utiliser des méthodes d’IA prédictive pour reconnaître des modèles corrélés à un délai de livraison global accru, et même anticiper de telles conditions à l’avenir.

En guise d’étape finale de cette histoire, nous pouvons imaginer l’entreprise réimaginer désormais le flux de travail de livraison comme un problème d’offre et de demande, en utilisant la tarification pour faire correspondre l’offre à la demande. Un exemple concret est de permettre au chauffeur-livreur d’ajuster sa rémunération en fonction du temps et du lieu, soit selon un planning fixe, soit de manière dynamique, en fonction des conditions en temps réel. Cela permet de « boucler la boucle » dans le cycle de données, en exploitant les données pour prendre des mesures concrètes (ajustements de prix) afin de répondre à un problème commercial (gestion de la latence globale de livraison) et en utilisant un retour d'information en boucle fermée (ajustements de prix dynamiques, en fonction de la latence observée) pour rendre le flux de travail « adaptatif ».

Créer une valeur commerciale directement monétisable à partir des données

Un autre type de valeur tirée des données consiste à les utiliser pour « ouvrir de nouveaux terrains de jeu », créant ainsi une valeur commerciale qui peut être monétisée via un avantage direct pour les clients. Un exemple est mentionné dans notre scénario 6 mois plus tard : apporter de la valeur à nos partenaires fournisseurs, les restaurants. Une solution au besoin commercial de fournir des informations aux clients de notre application consiste à exploiter à nouveau les données collectées par les flux de travail opérationnels de notre application, cette fois comme matière première pour extraire des informations commerciales pour nos clients et partenaires. Ces informations commerciales peuvent prendre diverses formes ; en voici quelques exemples :

• Une prévision précoce d’une demande plus importante que la normale, afin que le partenaire puisse se préparer en conséquence.
• Un aperçu de leurs tarifs pour des éléments de menu spécifiques, à la fois pour comprendre la sensibilité de la demande et pour comparer leurs tarifs à ceux de leurs restaurants homologues.
• Des données quantifiables pour aider à la planification plus stratégique du restaurant, telles que l’impact prévu sur les revenus de l’augmentation ou de la réduction de ses heures d’ouverture.

La découverte de ces informations commerciales est rendue possible non seulement par la présence d'un grand magasin de données, mais également par la stratégie de données qui annote les données collectées de manière structurée, en utilisant un vocabulaire de métadonnées cohérent.  

En examinant de plus près une histoire commerciale spécifique, réfléchissez à la manière dont les informations sur les prix des menus pourraient être déterminées. En commençant par les matières premières (les données collectées de manière opérationnelle à partir du flux de commande), la valeur de la stratégie de données annotées par des métadonnées devient immédiatement évidente. Plus précisément, non seulement le prix d’un article dans un restaurant spécifique est enregistré, mais les métadonnées associées sont également conservées. Tenez compte des attributs descriptifs supplémentaires d’un aliment, tels que la taille de la portion, le « type » d’aliment (par exemple, « boisson gazeuse » ou « hamburger ») et les « améliorations » spéciales (par exemple, « comprend un plat d’accompagnement » ou « épicé »). Si l'architecture des données décore les données sur les aliments avec des métadonnées pour ces attributs, en utilisant un vocabulaire de balises de métadonnées cohérent (par exemple, « portion onces », « classe alimentaire », « améliorations ») et un ensemble normalisé de valeurs de métadonnées, alors les informations sur les aliments peuvent être comparées entre les restaurants. Par exemple, si tout ce que l'on sait de la base de données de codes est que le « Burger Basement » possède un Man Cave Burger et que le « Heart Attack Grill » possède le Double Bypass Burger , il n'y a aucune base pour une comparaison significative. Cependant, si nous ajoutons un vocabulaire d'annotation de métadonnées, nous pouvons effectuer des comparaisons et des analyses : le système comprendrait que les deux éléments sont comparables car ils appartiennent tous deux à la « classe alimentaire » de « hamburger ». De plus, les analyses peuvent également utiliser d'autres champs de métadonnées pour normaliser la taille de la portion (c'est-à-dire que la « Man Cave » peut être de 8 onces et le « Double Bypass » peut être de 12 onces). Enfin, l'utilisation d'un espace standard de valeurs « d'amélioration », telles que « inclut le fromage », peut également être utilisée pour effectuer des ajustements supplémentaires en fonction de similitudes et/ou de différences secondaires. Une fois de plus, la réflexion approfondie sur l’architecture des données (cette fois-ci autour de la stratégie des métadonnées) a permis à l’entreprise de saisir rapidement de nouvelles opportunités commerciales en exploitant simplement l’épuisement des données des flux de travail existants.

Résumé

La plupart des chefs d’entreprise sont parfaitement conscients que leur succès dépend de la planification de leurs flux de travail opérationnels critiques, ainsi que de la visibilité sur l’exécution de ces flux de travail. Les bons dirigeants d’entreprise comprennent également que la capacité à générer ces informations rapidement et efficacement, puis à prendre des mesures – tant en interne qu’en externe – sur la base de ces informations est essentielle à leur succès continu.

En tant que technologues, on nous demande de créer des solutions qui permettent d’atteindre les objectifs commerciaux d’amélioration continue de l’efficacité opérationnelle et d’agilité commerciale. Malheureusement, les ingénieurs se concentrent trop souvent sur les éléments logiciels de traitement des données de la solution, et pas suffisamment sur l’architecture des données elle-même. Cela entraîne souvent des efforts considérables et des retards dans le déploiement de l’amélioration des flux de travail internes et du lancement de nouvelles offres dérivées pour les clients. Comme le démontre cet article, l’attention portée en amont à l’architecture des données (le vocabulaire des données, les représentations et la stratégie des métadonnées) constitue la base technologique d’une entreprise agile et robuste axée sur les données.