Cómo pienso el valor de negocio en los datos

Trabajo en data warehousing desde el año 2000. En todo ese tiempo he visto tecnologías ir y venir, arquitecturas surgir y caer, y muchas «próximas grandes novedades» desaparecer en silencio. Lo que no ha cambiado es la pregunta que la gente sigue haciendo:

¿Cómo sacamos valor de los datos?

No valor teórico. No algo que prometemos para «la fase tres». Valor real que ayuda a una empresa a tomar mejores decisiones, ganar más dinero o gastar menos.

Cuanto más trabajo en este campo, más me doy cuenta de que la respuesta es mucho más sencilla de lo que la mayoría de las discusiones sobre datos hacen creer.

Por qué nos molestamos con los datos

No gestionamos datos porque sea interesante. No construimos plataformas porque sea divertido. Lo hacemos porque se supone que los datos ayudan al negocio.

En la práctica, esa ayuda casi siempre aparece de solo dos maneras:

• Aumentar los ingresos
• Reducir los costes

Hay, por supuesto, excepciones. El reporting regulatorio es un buen ejemplo. Nadie está entusiasmado con construir un informe de RGPD — pero lo hacemos porque debemos. Aun así, para la mayoría de iniciativas, el valor de negocio es el verdadero motor.

Cada vez que miro un proyecto de datos, siempre empiezo con una pregunta: ¿Qué resultado de negocio se supone que debe apoyar?

Qué hace realmente valiosos los datos

Con los años he notado que el valor no viene de la complejidad o la sofisticación. Viene de unas pocas cosas muy prácticas.

Por mi experiencia, los datos crean valor cuando:

• Llegan pronto: los insights valiosos se acumulan con el tiempo. Cada mes de retraso destruye silenciosamente potencial impacto.
• Se entregan eficientemente: incluso las grandes ideas pierden valor si tardan demasiado o requieren demasiado esfuerzo de implementación.
• Responden a las preguntas correctas: las prioridades de negocio cambian constantemente — fin de trimestre, cambios de estrategia, nuevas regulaciones. Los equipos de datos deben poder ajustarse sin empezar de cero.

Sumándolo todo, se reduce a esto: el valor viene de entregar las cosas correctas, pronto y sin desperdiciar esfuerzo.

Por qué «ágil» no es el punto

Se habla mucho de agilidad en los proyectos de datos, pero he dejado de usar la palabra cuando hablo con stakeholders de negocio. No porque la agilidad no sea importante — sino porque la palabra en sí no significa mucho fuera de IT.

Lo que sí entiende todo el mundo es el retraso.

Si un insight importante llega tarde, la decisión basada en él también es tardía. Y ese retraso tiene un coste. A veces son ingresos perdidos. A veces es gasto innecesario. A veces es simplemente una oportunidad perdida.

Así pienso la agilidad: se trata simplemente de reducir el coste del retraso. La automatización, las herramientas y los frameworks solo importan si nos ayudan a hacerlo.

Por qué las grandes soluciones «perfectas» rara vez sobreviven

Al principio de mi carrera, dedicábamos meses a diseñar modelos de datos a nivel de toda la empresa. Eran impresionantes — y a menudo irrelevantes para cuando se ponían en producción. El negocio se mueve más rápido que los documentos de diseño. Por eso ya no creo en las grandes soluciones definidas de antemano. Creo en:

• empezar pequeño

• entregar algo útil rápido

• ajustar continuamente según cambian las necesidades

Una solución ligeramente imperfecta y útil hoy supera a una perfecta que llega demasiado tarde.

La parte que todos intentan evitar

Muchos equipos intentan saltarse el lío del medio del trabajo con datos — integración, historia, definiciones compartidas — esperando que se resuelva solo más tarde. Rara vez lo hace. He visto lo que ocurre cuando cada uno define los conceptos clave por su cuenta. Aun cuando cada definición tiene sentido, el resultado es confusión, retrabajo y discusiones interminables. Sin importar qué arquitectura elija: data lake, data mesh, centralizada o descentralizada. Sigue necesitando:

• definiciones compartidas

• lógica consistente

• un sitio donde los datos se integran y se entienden

Esa capa intermedia es inevitable.

Cuando los equipos de datos se convierten en empresas de software

Otro patrón que veo a menudo empieza con buenas intenciones. Las empresas quieren flexibilidad, así que ensamblan un stack de herramientas open source y construyen su propia plataforma.

Lo que no siempre se dan cuenta es que acaban de firmar un segundo trabajo.

De repente, el equipo de datos no solo entrega insights. También mantiene frameworks, actualiza herramientas, documenta soluciones a medida y forma a nuevos compañeros en un setup que solo existe dentro de esa empresa.

Me gusta hacer aquí una pregunta simple: Si la gestión de datos es tan compleja como un ERP, ¿construiría su propio ERP?

La mayoría de empresas no lo haría — y por buenas razones. La misma lógica debería aplicarse a las plataformas de datos.

Por qué la automatización cambió mi perspectiva

La automatización no elimina toda la complejidad, pero quita mucho trabajo repetitivo y de poco valor. Bien usada, ayuda a los equipos a:

• entregar valor antes

• adaptarse más rápido a prioridades cambiantes

• reducir mantenimiento y riesgo a largo plazo

Y, lo más importante, libera a las personas para centrarse en entender el negocio en lugar de reconstruir la fontanería.

Lo que he aprendido tras todos estos años

Si hay algo que me gustaría que la gente se llevara, es esto:

Los proyectos de datos no fracasan porque la gente sea incompetente. Fracasan porque el valor llega tarde, en la forma equivocada o a un coste demasiado alto.

Si nos mantenemos cerca del negocio, mantenemos las cosas simples, entregamos pronto y automatizamos lo que no requiere creatividad humana, los datos pueden por fin hacer lo que se suponía que iban a hacer — ayudar a las personas a tomar mejores decisiones.

Y de eso, al final, es de lo que va realmente este trabajo.