Los beneficios de una arquitectura de datos bien construida van más allá del proceso operativo. Los beneficios se extienden a eficiencias operativas estratégicas, conocimientos empresariales más profundos y la capacidad de alcanzar oportunidades comerciales adyacentes, todo ello ejecutado de manera más ágil.
En un artículo anterior, presentamos un servicio hipotético de pedido y entrega de alimentos, y presentamos varios flujos de trabajo operativos diarios clave: el proceso de pedido del cliente, el flujo de trabajo de recolección y entrega de alimentos, y el procesamiento de pagos. Exploramos cómo una estrategia de datos intencional en torno a las entradas de datos clave para los flujos de trabajo da como resultado procesos de negocio más sólidos y ágiles y escalables.
En este artículo, me gustaría ir más allá de la eficiencia operativa diaria y demostrar los beneficios a largo plazo y más estratégicos del diseño anticipado de la arquitectura de datos. Adelantando nuestro escenario inicial por seis meses, suponiendo que nuestra aplicação haya sido exitosa, los líderes empresariales ahora han identificado algunas oportunidades nuevas y emergentes. Ahora preguntan a los tecnólogos con qué rapidez y facilidad los sistemas subyacentes pueden ajustarse y adaptarse a algunas oportunidades específicas y desafíos relacionados:
Los cuatro ejemplos de desafíos enumerados se pueden descomponer en dos categorías amplias:
Uno, ajustar y mejorar la eficiencia de los procesos comerciales clave del día a día ("tácticos").
Dos, crear nuevos conocimientos que generen valor a largo plazo ("estratégico") para la empresa, directa o indirectamente, a través de los clientes de la empresa.
Los primeros dos nuevos desafíos (la expansión territorial y los requisitos de cumplimiento asociados) giran en torno de procesos comerciales tácticos y, por lo tanto, son de naturaleza más operativa. Los dos últimos desafíos son de naturaleza más estratégica.
Veamos primero las preocupaciones tácticas y operativas.
Con la expansión geográfica a más ciudades, podemos encontrarnos con algunos problemas diferentes. Un problema potencial para el flujo de trabajo de entrega es que podría haber un problema de desambiguación con las direcciones postales: la misma dirección (por ejemplo, “100 Main St.”) podría existir en varias ciudades. Otro posible problema es que las diferentes ciudades pueden abarcar zonas horarias; si eso no se consideró, entonces una recogida a las 6:00 p.m. Es posible que MDT tenga un retraso de una hora en la entrega a una ciudad vecina en PDT (a las 6:30 p.m. PDT). La arquitectura de datos descrita en nuestro artículo anterior incorporó la idea de una representación "normalizada" (globalmente única) para los elementos de datos, abordando ambos problemas potenciales y permitiendo así que la aplicação se adapte implícitamente a estos requisitos adicionales.
La segunda preocupación táctica es el cumplimiento de los requisitos adicionales de gobernanza de datos para el estado de California. El conjunto completo de preocupaciones en torno a la Ley de Privacidad del Consumidor de California (CCPA) es un conjunto completo de artículos en sí mismo, pero un aspecto tiene que ver con poder recopilar todos los datos de un cliente, junto con la fecha de recopilación y la fuente de los datos. Como se mencionó anteriormente, crear un marco de arquitectura de datos que permita que la tubería de ingesta de datos principal agregue anotaciones de metadatos, como marcas de tiempo, lo que permite cumplir con requisitos de gobernanza de datos adicionales de manera sencilla y con un esfuerzo incremental mínimo.
Además del valor comercial generado por las mejoras en los flujos de trabajo y procesos tácticos diarios de la empresa, otro beneficio, posiblemente más importante, es el valor estratégico de poder inclinar el campo de juego existente y también abrir nuevos campos de juego en los que participar.
Una clase de beneficio estratégico es la capacidad de "inclinar el campo" modificando el modelo de los flujos de trabajo operativos clave. Esto va más allá de simplemente optimizarlos: se trata de reimaginarlos. Una arquitectura de datos robusta y con visión de futuro permite la explotación ágil y eficiente de las capacidades clave (agregación y análisis de datos) necesarias para abordar el desafío antes mencionado de la degradación del tiempo de entrega causada por la variabilidad de la demanda, mediante el uso de precios dinámicos.
Más específicamente, debido a la previsión prestada a la arquitectura de datos, se logró lo siguiente:
Como resultado, los datos de dos flujos de trabajo diferentes (pedido y entrega) se pueden correlacionar, categorizar y agregar. Además, la arquitectura de metadatos flexible se puede aprovechar para anotar los datos recopilados con información contextual enriquecida para su análisis. Tenga en cuenta la latencia general de la entrega: el tiempo que transcurre desde que se realiza el pedido hasta que se entrega la comida. La latencia se puede calcular correlacionando los flujos de trabajo de pedido y entrega. Además, debido a que la representación de datos de geolocalización en los dos flujos de trabajo también utiliza una sintaxis y una semántica consistentes, los cálculos y correlaciones de latencia de entrega se pueden segregar por ubicación, como por ejemplo por código postal. De este modo, gracias a una previsión de la estrategia de datos, podemos crear más fácilmente un conjunto de datos de la latencia de entrega general, con una granularidad por hora y por código postal. Por último, al aprovechar nuestro enfoque flexible de metadatos, las estadísticas horarias se pueden anotar con información contextual adicional, como las condiciones del tráfico y los totales de precipitaciones.
En este punto, contamos con información valiosa para alimentar un proceso de análisis, que luego puede usar métodos de IA predictiva para reconocer patrones correlacionados con un mayor tiempo de entrega general e incluso anticipar dichas condiciones en el futuro.
Como paso final en esta historia, podemos imaginar que la empresa ahora está reimaginando el flujo de trabajo de entrega como un problema de oferta y demanda, usando precios para adaptar la oferta a la demanda. Un ejemplo específico es permitir que la compensación del conductor de reparto se ajuste según el tiempo y la ubicación, ya sea a través de un cronograma fijo o de forma dinámica, según las condiciones en tiempo real. Esto "cierra el ciclo" del ciclo de datos al aprovechar los datos para tomar medidas prácticas (ajustes de precios) para abordar una inquietud comercial (administrar la latencia de entrega general) y usar retroalimentación de ciclo cerrado (ajustes de precios dinámicos, según la latencia observada) para hacer que el flujo de trabajo sea "adaptativo".
Un tipo diferente de valor de los datos es utilizarlos para "abrir nuevos campos de juego", creando valor comercial que se puede monetizar a través de un beneficio directo para los clientes. Un ejemplo se menciona en nuestro escenario seis meses después: brindar valor a nuestros socios proveedores, los restaurantes. Una solución a la necesidad comercial de brindar información a los clientes de nuestra aplicación es aprovechar una vez más los datos recopilados por los flujos de trabajo operativos de nuestra aplicación, esta vez como materia prima para extraer información comercial para nuestros clientes y socios. Estos conocimientos empresariales pueden adoptar diversas formas; algunos ejemplos son:
El descubrimiento de estos conocimientos empresariales es posible no sólo por la presencia de un gran almacén de datos, sino también por la estrategia de datos que anota los datos recopilados de forma estructurada, utilizando un vocabulario de metadatos consistente.
Al centrarnos en una historia de conocimiento empresarial específica, consideremos cómo se podrían determinar los datos sobre los precios del menú. A partir de las materias primas (los datos recopilados operativamente durante el flujo de trabajo de pedidos), el valor de la estrategia de datos anotados con metadatos se hace evidente fácilmente. En concreto, no solo se registra el precio de un artículo en un restaurante específico, sino que también se guardan los metadatos relacionados. Tenga en cuenta los atributos descriptivos adicionales de un alimento, como el tamaño de la porción, el "tipo" de alimento (por ejemplo, "refresco" o "hamburguesa") y las "mejoras" especiales (por ejemplo, "incluye guarnición" o "picante"). Si la arquitectura de datos decora los datos de los alimentos con metadatos para estos atributos, utilizando un vocabulario de etiquetas de metadatos consistente (por ejemplo, "onzas de porción", "clase de alimento", "mejoras") y un conjunto normalizado de valores de metadatos, entonces la información de los alimentos se puede comparar entre restaurantes. Por ejemplo, si todo lo que se sabe de la base de datos de códigos es que "Burger Basement" tiene una Man Cave Burger y "Heart Attack Grill" tiene la Double Bypass Burger , no hay base para una comparación significativa. Sin embargo, si agregamos un vocabulario de anotación de metadatos, podemos realizar comparaciones y análisis: el sistema entendería que los dos elementos son comparables porque ambos son de la "clase de comida" de "hamburguesa". Además, el análisis también puede utilizar otros campos de metadatos para normalizar el tamaño de la porción (es decir, la "Cueva del Hombre" puede ser de 8 onzas y la "Doble Bypass" puede ser de 12 onzas). Por último, el uso de un espacio estándar de valores de "mejora", como "incluye queso", también se puede utilizar para realizar ajustes adicionales en función de similitudes y/o diferencias secundarias. Una vez más, la previsión prestada a la arquitectura de datos (esta vez en torno a la estrategia de metadatos) ha permitido a la empresa aprovechar rápidamente nuevas oportunidades comerciales simplemente aprovechando el agotamiento de datos de los flujos de trabajo existentes.
La mayoría de los líderes empresariales son plenamente conscientes de que su éxito depende de la planificación de sus flujos de trabajo operativos críticos, junto con la visibilidad de la ejecución de esos flujos de trabajo. Los buenos líderes empresariales también entienden que la capacidad de generar esos conocimientos de manera rápida y eficiente, y luego tomar medidas (tanto internas como externas) basadas en esos conocimientos es clave para su éxito continuo.
Como tecnólogos, se nos pide que construyamos soluciones que posibiliten los objetivos comerciales de mejora continua de la eficiencia operativa y agilidad empresarial. Lamentablemente, los ingenieros a menudo se centran en los elementos del software de procesamiento de datos de la solución y no lo suficiente en la arquitectura de datos en sí. Esto a menudo genera importantes esfuerzos y demoras en el tiempo de implementación para mejorar los flujos de trabajo internos y el lanzamiento de nuevas ofertas derivadas para los clientes. Como demuestra este artículo, la atención inicial prestada a la arquitectura de datos (el vocabulario de los datos, las representaciones y la estrategia de metadatos) es la base tecnológica para un negocio ágil y sólido basado en datos.