Retos reales de los proyectos Big Data

Factor_Humano_Formacion_Big_Data_Retos

Retos reales de los proyectos Big Data

La realidad de los proyectos Big Data es bastante dura. Es fácil ver el potencial del uso de la información pero qué pasa cuando una compañía decide poner en marcha su propia iniciativa de Big Data. Las estadísticas nos avisan: el 100% de los proyectos de Big Data se va de planificación y la mitad de ellos falla. Y sin embargo, según Gartner, el 80% de las empresas piensa realizar inversiones en este área.

¿A qué se debe esta alta tasa de fallo? Puede haber muchas causas distintas y específicas de cada empresa. Pero con la experiencia he detectado tres elementos que siempre están presentes en un proyecto fallido: no se consiguen mejoras operativas, fallan las herramientas de IT y/o no se tienen unos objetivos claros de negocio. A parte quedan las planificaciones poco realistas.

Conseguir mejoras operativas con un proyecto de Big Data implica que la información llegue a todas las personas y procesos que están implicados en una operativa concreta. Esto implica que las personas implicadas tengan un conocimiento y una experiencia mínima en el manejo de datos. Aquí encontramos un grave problema de formación. Para manejar datos, volúmenes enormes de información estructurada, no estructurada proveniente de fuentes distintas y encontrar patrones que tengan sentido hay que tener una formación sólida en estadística, matemática y estructuración de la información. No basta con manejar excel. La información debe de ser analizada, exprimida y comprendida. Estamos hablando de el rol de científicos de datos. Y no es fácil ni barato encontrarlos. Aparecen sucedáneos.

El segundo punto de fallo son las herramientas de IT, más concretamente las herramientas que se encargan de la Extracción, Transformación y Carga (ETL). Y fallan porque el problema con el que tratan es complejo. Empezando por la extracción encontramos con sistemas no documentados, mal mantenidos y con modelos de datos complejos. La transformación y la carga se encargan de que los datos lleguen a puerto pero por lo general las herramientas comienzan a tener problemas de rendimiento. Comienzan entonces la búsqueda de alternativas. Lo peor es que por lo general se va a ciegas.

El tercer punto son las estrategias de negocio. Generalmente el usuario de negocio tampoco tiene muy claro que es exactamente lo que necesita. La peor estrategia posible es la de “traerlo todo y ya veremos que hacemos”. Es decir, lo quiero todo (y cuando preguntas para qué, la respuesta es por si acaso). Con ese planteamiento lo que al final se consigue es tener un coste desorbitado, una necesidad de recursos (que como ya hemos dicho, baratos no son) y unos procesos ETL lidiando con un volumen de datos disparatado.

Esta es más o menos la situación a la que se llega con un proyecto de BiG Data que empieza a ir mal. Qué hacer para que no llegue ahÍ, esa es la gran pregunta No hay recetas infalibles, solo sentido común. Lo primero es asumir que los proyectos de BiG Data no son proyectos de tecnología. No deben ser liderados por los departamentos de tecnología. El área de negocio debe decidir una objetivo concreto, la pregunta qué voy a conseguir con esta información debe de ser la primera y no la última. Una vez planteado el problema podremos encontrar una solución. El cálculo del ROI es importante porque los proyectos Big Data no son baratos (ni cuando se ejecutan ni cuando no se ejecutan, siempre hay una consecuencia).

Una estrategia que funciona es la de usar herramientas de data analytics durante la definición del proyecto. Estas herramientas permiten analizar la veracidad y la calidad de la información antes de su extracción y carga. Aquí juega un papel muy importante el analista de negocio y el científico de datos. Juntos determinan (mediante un muestreo y técnicas de exploración de datos) si la información (la fuente de información) sirve para solucionar el problema de negocio planteado. Si la respuesta es sí, entonces planteamos la ETL, es decir, encendemos la luz antes de bajar al sótano. A estas técnicas se las está comenzando a llamar ágil analytics y son la principal arma para que el proyecto no esté en el temido 50% de los que fallan.

Ni que decir que el gurú de datos, aquel al que todo el mundo en la compañía ha de dirigirse para obtener información, está totalmente descartado. Con este planteamiento, lo único que se consigue es mantener un cuello de botella que impida que todo el esfuerzo llegue a materializarse en una mejora operativa. En lugar de eso, es necesario esforzarse por democratizar el uso de los datos. Para ello es necesario plantearse una estrategia de self-service analytics en la que los usuarios de negocio se conviertan en sus propios proveedores de información.

Sin comentarios

Publicar una respuesta