12.2 ¿Cómo convertirse en una organización que toma decisiones basadas en datos?

Algo que es común observar (al menos en este hermoso país) es que los datos generados por las agencias gubernamentales terminan en un sin fin de reportes, rara vez se utilizan para la toma de decisiones. Se van publicando paulatinamente datos y reportes pero su impacto sobre decisiones futuras y ,por ejemplo, política pública, no es claro. Estos reportes son, generalmente, una mera declaración de hechos presentes o pasados, sin mucho contexto y sin una explicación causal de por qué algo ha sucedido o no ha sucedido. Por supuesto sin recomendaciones de qué hacer después. Sin duda los datos y los reportes son escenciales para la toma de decisiones, por sí solos no logran mucho.

Cuando una organización está impulsada por datos diremos que es data-driven. No existe una palabra en español para referise a esto así que usaremos el término en inglés.

La Data-drivenness emerge de múltiples cosas, pero final del día hay que tener en mente que volverse una organización impulsada por datos es una decisión estratégica y operacional, no es sólo una cuestión tecnológica. Es crucial generar una cultura en la que las personas actúan con base en datos. Por supuesto que para lograr esto hace falta construir herramientas y habilidades que permitan lo anterior.

Tómense 10 minutos para leer la siguiente carta.

12.2.1 Recolección y acceso a datos

Una organización debe estar recolectando datos.

No se deben estar recolectando cualquier tipo de datos. Deben ser los datos, potencialmente, correctos. Esto es, que al menos en potencia, puedan permitir contestar preguntas o abordar temas de interés. Por otro lado, idealmente, deben ser datos oportunos, exactos, limpios e insesgados.

Los datos deben ser consultables.

Debe haber un mecanismo estándar y lógico para acceder y buscar subconjuntos de interés del universo de datos disponible.

Los datos deben poder unir (joinable).

Sobretodo cuando se quiere trabajar con datos de fuentes diversas, se debe de poder asociar los datos para colocarlos en una misma estructura que permita generar reportes o análisis.

Los datos se deben poder compartir.

Debe existir una cultura de compartir datos dentro de la organización, muchas veces entre diferentes organizaciones. Esto para que datos diversos puedan unirse.

Poniendo un ejemplo un tanto simple, supongamos que un paciente es tratado en un hospital pero al ser dado de alta debe ir a revisiones periódicas en otra clínica. El paciente recibirá peor servicio al cliente y, más importante aún, un peor tratamiento si el hospital y la clínica no comparten datos.

12.2.2 Reportes y alertas

Supongamos que tenemos un grupo que hace analítica y que este tiene acceso a datos relativamente limpios y consultables. El grupo extrae datos de ventas y reporta:

Tómense 10 minutos para pensar en qué tan informativa es esta gráfica y qué tan fuerte la conclusón ¿por qué?

Una alerta es un reporte de algo que está sucendiente EN ESTE MOMENTO. Sufre de las mismas desventajas que un reporte, esto es, no da nada de información contextual. Pero puede ser sumamente útil e incluso necesario para lograr ciertos propósitos ¿Quién no quisiera una alerta de deforestación en casi tiempo real? Desgraciadamente, la complejidad tecnológica que implica producir alertas es generalmente significativamente mayor que la de reportes.

12.2.3 De reportes y alertas a análisis

Por supuesto la capacidad de generar reportes y alertas es una condición necesaria para ser una organización impulsada por datos. Pero no es suficiente, los reportes y alertas son descriptivos, pero muchas veces se necesita algo prescriptivo.

En el año 2009, Jim Davis, el senior vice president y chief marketing officer del instituto SAS postuló ocho niveles de analítica:

Reportes estándar: ¿Qué pasó? ¿Cuándo?
Reportes Ad Hoc: ¿Cuántas veces ha pasado? ¿Qué tan seguido pasa?
Consultas especializadas: ¿Exactamente en qué población se dió el problema?
Alertas: ¿Cuándo debería de reaccionar?
Análisis estadístico: ¿Por qué está sucediendo esto?
Previsión: ¿Qué va a suceder si estas tendencias continúan? ¿Cuánto se va a necesitar? ¿Cuándo?
Modelos predictivos: ¿Qué va a suceder después?
Optimización: ¿Cómo podemos hacer mejor las cosas? Ante un problema complejo ¿Cuál es la mejor estrategia?

Tómense 10 minutos para pensar en un análisis de cada uno de estos tipos desde el contexto en el que laboran (como científicos, trabajadores en una agencia gubernamental, etc)

12.2.4 Tecnología

Ya se mencionó que convertirse en una organización impulsada por datos no es meramente una cuestión tecnológica, pero sin duda la tecnología es un factor necesario para lograrlo. Para llegar a los distintos niveles de analítica antes propuestos se requieren de flujos de trabajo que generalmente se separan en tres componentes:

Back-end (el punto de partida, las bases de datos y procesos de gestión, transformación y consulta de las mismas)
Middleware (lo que une el Back-end con aplicaciones)
Front-end (lo que se presenta al cliente, por ejemplo un dashboard)

Cada uno requiere habilidades especiales para desarrollarse y utilizarse, en una organización se requieren especialistas que sepan sobre estas componentes, muchas veces de una manera no-disjunta.

Por si fuera poco, los componentes anteriores se refieren a cosas distintas dependiendo de la aplicación en cuestión. Por ejemplo un desarrollador back-end:

Si estás trabajando para una compañía que hace su propio back-end, entonces se refiere a alguien que genera la infraestructura donde se alojan datos (base de datos).
En una compañía que trabaja con Big Data podría significa alguien que sabe utilizar los distintos productos que ofrece una compañía de cómputo en la nube.
En una compañía que hace web apps es la persona que escribe el código para interactuar con las bases de datos.

Una empresa moderna de analítica mantiene cada vez roles más especializados.

Backend engineering: Diseño y construcción de bases de datos. Así como la gestión de las mismas. Debe poder entregar datos requeridos por clientes internos en formatos que faciliten el trabajo de los mismos.
Machine learning engineering: Desarrollo de modelos de inteligencia artificial que sirvan tanto para llevar a cabo análisis de datos (predicción e inferencia) como para la automatización de tareas.
Data science: Entendimiento profundo de problemas de negocio para poder generar insights a través de métodos analíticos y visualización de datos. “Genera sus propias preguntas”.
Data analytics: Entendimiento profundo de problemas de negocio para poder llevar a cabo una curaduría fina de insights. “Propone respuestas novedosas a preguntas dadas”.
Dev ops: Alguien que diseña y supervisa el conjunto de prácticas que tienen como intención reducir el tiempo entre que se propone un cambio a un sistema y que el cambio se implementa.
Data engineering: Su rol principal es desarrollar herramientas que hagan que los datos crudos sean más útiles para la empresa. Es responsable de desarrollar, mantener y optimizar las herramientas que permiten el acceso y consulta de datos para clientes internos.

Para estos momentos debe ser evidente que una gran parte de lo planteado se centra en ejercicios que son primordialmente desarrollo de software.