DATA #009. Los 3 ejes fundamentales de tu estrategia Data Driven

Ser una organización Data Driven debería estar en el centro de toda estrategia de datos de cualquier compañía, mediana o grande, que pretenda subsistir en un mundo tan competitivo y cambiante como el actual. Es un concepto que no para de repetirse desde hace algún tiempo en foros, presentaciones, eventos y debates relacionados con el mundo del dato. Muchos proveedores aprovechan el viento a favor para ofertar soluciones que cubren sólo una parte del camino o que ofrecen funcionalidades muy específicas, lo que puede llevar a muchas organizaciones a equivocar su estrategia de implantación de soluciones en relación al uso efectivo de los datos.

Como suele pasar, las cosas son siempre más complicadas de lo que parecen por lo que no basta sólo con implantar una tecnología concreta.

¿Cuál es el significado del término "Data Driven"?

Lo primero, antes de entrar en materia, es definir el concepto "Data Driven". Una definición inicial podría ser:

"Es Data Driven toda organización que toma decisiones basadas en datos"

Pero bajo este paraguas cabemos todos, ya que como seres racionales, tomamos decisiones basándonos en datos, que podemos extraer de nuestra propia experiencia (datos históricos), del entorno que nos rodea (datos de terceros) o de suposiciones (predicciones sobre lo que puede pasar). Entonces, si ya funcionamos así de forma natural, ¿Qué es ser una empresa Data Driven? ¿Qué las diferencia del resto de empresas?

Una compañía Data Driven es aquella que valora el dato como un activo y que lo utiliza como eje central en todos sus procesos de toma de decisiones, pero que, además, entiende el dato como parte importante de su cultura empresarial y como tal lo cuida, lo trabaja y lo difunde a lo largo de la organización de una forma gobernada.

Y bajando más al plano táctico, del día a día, también podemos definir las organizaciones Data Driven como aquellas en las que cualquier usuario y en cualquier momento o lugar tiene autonomía para encontrar respuestas a preguntas concretas, respuestas que han de estar basadas en información contrastada, que son completas, que le son servidas de forma ágil y que puede utilizar en los procesos de toma de decisiones. Y todo esto de una forma gobernada, asegurando un acceso seguro a la información. Pero construir un sistema como el anterior no es algo trivial, requiere de mucho esfuerzo, de madurez y de la colaboración de muchas áreas. No es algo que se pueda conseguir con una sola herramienta ni de forma exclusiva aplicando sólo tecnología.

Los 3 ejes de una organización para ser Data Driven

Desde mi punto de vista, existen tres ejes en los que se debería basar toda organización que pretenda ser Data Driven:

1. El eje de los Datos

Hace referencia a cómo trabajamos los datos en origen y a la capacidad que tenemos para acceder a ellos de forma óptima, de gestionarlos y transformarlos. Las preguntas que nos deberíamos hacer con respecto a este eje son:

• ¿Soy capaz de incorporar nuevos datos de forma ágil?

• ¿Puedo manejar cualquier tipo de datos?

• ¿Tengo capacidad para integrarlos con el resto de los datos ya existentes de forma rápida?

• ¿Puedo almacenar todo el volumen de datos requerido de forma eficiente?

• ¿Puedo acceder al dato con una performance adecuada?

No podemos ofrecer un acceso a datos de forma rápida y ágil si necesitamos mucho tiempo para ingestar nuevos datos, si tenemos limitaciones en cuanto a la capacidad de almacenamiento o de cómputo, o si no somos capaces de integrar las nuevas fuentes de forma rápida. Para poder hacer frente a este eje de forma adecuada vamos a necesitar lo siguiente:

• Plataformas de datos ágiles, flexibles y escalables, que nos permitan incorporar cualquier tipo de dato (estructurado y no estructurado), con cualquier tipo de frecuencia (desde cargas batch a near real time) y donde no tengamos limitaciones en cuanto a espacio o capacidad de cómputo de forma que podamos adecuarnos a los picos o valles de demanda.

• Equipos de Datos y/o IT que puedan acceder a los datos ingestados y que, mediante herramientas de integración de datos, sean capaces de aplicar las trasformaciones necesarias sobre los datos para integrarlos de forma rápida con los datos ya gobernados.

2. El eje del Gobierno

Hace referencia a aquellos procedimientos que tienen como objetivo garantizar la calidad del dato así como asegurar un acceso al dato de forma segura y controlada. Las preguntas que nos deberíamos hacer con respecto a este eje son:

• ¿Quién se encarga de verificar si un dato es correcto?

• ¿Quién define el significado de un dato?

• ¿Quién puede acceder a cada uno de los conjuntos de datos?

• ¿Por cuánto tiempo hay que almacenar cada dato?

• ¿Quién utiliza cada dato y para qué?

Sin un gobierno efectivo de los datos corremos el riesgo en nuestras organizaciones de operar con datos de mala calidad, de crear realidades paralelas en diferentes departamentos o incluso de generar brechas de seguridad donde datos personales puedan quedar al descubierto o donde información sensible para la organización pueda ser accedida por personal no autorizado. Para ejecutar el gobierno de la información es necesario que la organización cree las políticas de gobierno, donde queden claros los roles que participan y sus responsabilidades, y donde se definan los procesos que se han de seguir en cuanto a la gestión de los datos, pero también es importante que la organización asuma que una parte importante de esas nuevas responsabilidades ha de recaer en las unidades de negocio.

El dato es un activo para la organización, y como tal ya no es algo de uso exclusivo de IT, ha de ser la organización en su conjunto la que se responsabilice de él.

Algunas organizaciones, las más maduras, han incorporado un nuevo perfil en sus equipos directivos: el CDO o Chief Data Officer, que es el responsable de definir la estrategia de explotación y gobierno del dato, y por lo tanto de definir las políticas y procedimientos de gestión.

3. El eje de la Información

Hace referencia a la capacidad de la organización para poder acceder a los datos y aplicar sobre ellos determinadas técnicas de análisis para extraer información relevante que pueda ser utilizada en los procesos de toma de decisiones. Las preguntas que nos deberíamos hacer con respecto a este eje son:

• ¿Conocen nuestros usuarios los datos que están disponibles?

• ¿Cómo acceden a los datos?

• ¿Cómo los analizan?

• ¿Somos ágiles como organización a la hora de realizar nuevos análisis?

Puede parecer que este es un eje meramente tecnológico, de herramientas, y es verdad que la elección de las herramientas finales de análisis es importante, pero lo es mucho más la decisión sobre el enfoque. No es lo mismo apostar por un BI más tradicional donde un equipo centralizado lidera toda la analítica, que hacerlo por un BI enfocado al autoservicio, donde el objetivo es empoderar a las áreas de negocio para que sean autónomas a la hora de analizar los datos. Esta decisión sobre el enfoque es crítica, ya que condiciona el tipo de herramientas a implantar, el tipo de productos a desarrollar y sobre todo cómo se desarrollan. No hay una receta mágica, en organizaciones mas pequeñas, un BI tradicional con un equipo bien dimensionado puede funcionar, aunque tendrá problemas a la hora de escalar la solución, en cambio, en organizaciones más grandes o dinámicas el autoservicio es la clave, aunque puede generar problemas sino se ejerce el gobierno de forma adecuada. En mi opinión, lo ideal es implantar herramientas de BI enfocadas al autoservicio, que aseguren la necesaria autonomía de los equipos de negocio para poder realizar analítica en el momento y lugar adecuados, pero siempre siguiendo directrices de un equipo de datos centralizado que gobierna la plataforma, define las metodologías y asegura el cumplimiento de las buenas prácticas. Otro tipo de herramientas que juega un papel importante en el eje de la información son los Catálogos de Datos, donde se han de publicar todos los conjuntos de datos previamente gobernados de forma que sean accesibles para la organización, y donde se puedan ejecutar las políticas de acceso al dato.

Ejecución de la estrategia

Llegados a este punto disponemos de todo lo necesario para ser Data Driven pero eso no significa que hallamos alcanzado nuestro objetivo, todo lo contrario.

Empieza la fase de ejecución, y de las decisiones que tomemos a partir de ahora dependerá el éxito o fracaso de nuestra iniciativa.

No todos los usuarios tienen las mismas necesidades y, por lo tanto, no todas las soluciones analíticas son válidas para todos ellos, por ejemplo, no es lo mismo desarrollar un cuadro de mandos para un área directiva que una aplicación analítica enfocada a usuarios de negocio que han de tomar decisiones tácticas, por ejemplo, sobre el precio de venta de un producto. Mientras en la aplicación analítica seguramente hay que trabajar mucho en la parte de calidad del dato, de integración de varias fuentes, y de definición de conceptos, en el cuadro de mandos seguramente ya partimos de datos de calidad, con KPI's contrastados, y hay que hacer un ejercicio de agregación, de sintetización de la información más relevante, e incluso de selección del tipo de visualización más adecuada en función del perfil específico del usuario final. Otras veces la necesidad no es tanto la construcción de una aplicación analítica como tal, sino el poder disponer de ciertos datos de forma flexible para explorar ciertas ideas que nos puedan llevar a nuevas conclusiones, por lo que debemos trabajar más en la parte de definición de los conjuntos de datos y en su publicación en el catálogo de datos corporativo. Por último, a veces debemos balancear nuestras soluciones entre dos necesidades distintas y contrapuestas, la de agilidad a la hora de desarrollar y la del gobierno de la información, ya que cuantos más recursos dediquemos a las fases de validación y definición de los datos, más tiempo necesitaremos para desarrollar las soluciones. Esta contradicción nos podría llevar a renunciar a alguna de esas dos premisas iniciales, lo que sería un error. La solución a todas estas diferentes necesidades que se dan en toda organización es la definición de diferentes productos analíticos adaptados a cada una de ellas, donde han de quedar muy claros los prerrequisitos y limitaciones de cada uno definiendo su alcance y recorrido, por ejemplo: una solución de BI desarrollada de forma muy rápida, en cuestión de horas o días, se podrá utilizar sólo en el ámbito privado del departamento que la desarrolla ya que no habrá pasado por un proceso de certificación y puede haber cierta incertidumbre sobre la calidad de los datos o sobre el significado de algunas métricas (sobre todo para personal externo al departamento), mientras que una aplicación bien gobernada, definida y certificada podrá ser utilizada para radiar información de forma transversal a toda la organización. Una vez definidos los diferentes productos analíticos, es muy importante la elaboración de metodologías concretas de desarrollo para cada uno de ellos, capaces de involucrar a todas las áreas implicadas en su construcción (equipos de datos, IT y negocio), de forma que aseguren el necesario control, el gobierno y el seguimiento de estándares de desarrollo y buenas prácticas. Estas metodologías las ha de desarrollar un equipo de datos centralizado, por lo que, aunque hayamos apostado por herramientas de autoservicio y hayamos conseguido involucrar a las áreas de negocio en el desarrollo de soluciones, nos aseguraremos de que se hagan siguiendo un criterio común. El marco cultural y metodológico también es importante, no basta con definir cómo construir cada tipo de solución, también hay que refinar el método. Cada vez que iteramos, cada vez que desarrollamos una solución, aprendemos por el camino y es vital poder generalizar esas enseñanzas para retroalimentar a los equipos de desarrollo, y la mejor forma de hacerlo es plasmando lo aprendido en nuevas versiones o evoluciones de las metodologías de desarrollo. Sin duda alguna, el uso de metodologías ágiles ayuda en este proceso de refinamiento ya que favorece la comunicación entre los equipos, la implicación de sus miembros, la toma de decisiones de forma participativa y fomenta la mejora continua a través de las ceremonias retrospectivas. Por último, no podemos olvidarnos de la gestión de las personas y del cambio cultural, estamos hablando de definir nuevos roles, nuevas responsabilidades y de cambiar los procesos de toma de decisiones de las áreas de negocio, y nada de ello va a ocurrir porque sí. Es lógico que haya resistencia al cambio, que se ha de vencer desde la pedagogía de los beneficios y no desde la imposición. Debemos ser capaces de explicar el porqué de los cambios y sobre todo hacer hincapié en los beneficios concretos que esta nueva forma de operar nos ha de traer.

Conclusiones

Hay tres premisas imprescindibles para toda organización que quiera ser Data Driven: disponer de plataformas ágiles y flexibles de ingesta y procesamiento de datos, de una cultura de gobierno de la información capaz de crear las políticas adecuadas, y de herramientas analíticas para poder acceder y explotar los datos, orientadas al autoservicio, pero gobernadas por equipos centralizados de datos. Pero esto es solo la punta del iceberg, debemos también trabajar en la definición de los diferentes productos analíticos que cubran las diferentes necesidades de la organización y en crear las metodologías concretas de desarrollo que permitan generarlos de forma ágil, gobernada y siguiendo siempre las políticas y buenas prácticas definidas por los equipos centrales de datos.

El refinamiento y la optimización de estas metodologías, así como una eficiente gestión del cambio será lo que nos lleve, de forma natural a incorporar cada vez más los datos en los diferentes procesos de toma de decisiones y por consiguiente a ser una organización Data Driven.