Investigando los misterios del Big Data

Hace unos días la revista AutomationWorld publicó un interesante artículo sobre los futuros empleos que se van a generar debido a los procesos de transformación digital en los que estamos todos envueltos. Uno de ellos, que da nombre al artículo, es el de Data Detective, posición encargada de ‘investigating the mysteries of Big Data, uncovering secrets within the content by examining sensors, devices, fog computing and neural networks.’

Desde mi punto de vista, coincido que esta posición, con este nombre u otro, acabará existiendo, si bien es cierto que le añadiría un matiz. Un buen Data Detective deberá investigar porque los resultados extraídos de los datos no aplican o coincidan con la realidad.

Actualmente, todas las industrias de proceso e infraestructuras están trabajando o evaluando herramientas de análisis de datos, ya sean herramientas analíticas, de Business Intelligence, de mantenimiento preventivo, de optimización de recursos, etc. Pero la aproximación de estas integraciones, en su mayoría, se suelen hacer desde ‘las alturas’. Este tipo de herramienta se nutre de datos almacenados en BBDD, y son a partir de éstos de dónde extraen sus conclusiones a partir de grandes procesos y algoritmos complejos.

Para el mundo industrial y de infraestructuras existe un problema de base en ello. Estos datos guardados en BBDD no se han guardado allí con la finalidad de ser explotados por este tipo de herramienta, sino que se han generado y contextualizado para otro tipo de aplicación – un SCADA típicamente -. Este hecho diferencial implica que estas herramientas están trabajando sobre un campo de muestreo que no está debidamente diseñado o preparado para ello. En el mundo industrial hoy por hoy hay una máxima: el cuello de botella tecnológico para el uso de esas herramientas es una correcta adquisición de datos de campo.

Por poner un ejemplo, en una industria de fabricación de piezas de automoción se sabe que el 6% de las piezas salen defectuosas y son descartadas al momento. Esa información es la que llega a los repositorios utilizan su SCADA y ERP. Ahora bien, lo más interesante sería que esas herramientas pudieran saber más sobre las piezas descartadas, su recorrido de fabricación y los diferentes elementos que estuvieron implicados, material, proveedor, maquinaria de estampación, cintas de transporte, personal activo, etc. Pero para poder hacer estas correlaciones el sistema necesita cumplir unas características que no tendrá. Ante este escenario estas herramientas o no sabrán extraer una conclusión o, aún peor, la extraerán equivocada.

Es por ello que creo que llegaremos a la figura del Data Detective. No me aventuro en si será una posición interna de las compañías o consultorías externas, pero tengo claro su misión. Investigar el por qué las herramientas de explotación contratadas no están teniendo el ROI deseado, es decir, una vez revisada la herramienta y sus algoritmos y comprobado que todo es correcto a ese nivel, dónde están los fallos de contextualización de las fuentes de datos. ¿En su correcta adquisición, en su manipulación, en la frecuencia de muestreo, en su estampación temporal, en el volumen con el que se trabaja, en que me falta adquirir información de unos elementos clave…?

Este Data Detective lo más seguro es que deberá investigar, coordinarse y entender a los múltiples actores involucrados en el proceso y que, lo más seguro, es que en caso de que esas herramientas no tengan los resultados esperados ninguno se vaya a sentir responsable de ello. Y, mal que nos pese, seguramente tendrán razón todos. Si las fuentes de datos no han sido debidamente preparadas para ello, una aplicación de mantenimiento preventivo podrá trabajar con lo que pueda, pero es evidente que no podrá extraer las conclusiones más acertadas, por ejemplo.

Por ello, para evitar tener que necesitar un Data Detective podemos proponer varias iniciativas, no excluyentes entre ellas:

• Utilizar un Plan Director de transformación digital, es decir, trabajar en una estrategia conjunta que englobe todos los niveles de una industria, teniendo en cuenta las necesidades específicas de cada nivel, pero también las transversales – la ciberseguridad, por ejemplo -.
• Contar con partners de confianza, ya sea en las propias herramientas como en los servicios que subyacen detrás de cada proyecto. Es evidente que cuanto más actores, más gente a la que llamar, más gente que coordinar, más gente que se justifica, etc. Tener dos o un único partner como Main Director de los proyectos no implica que por debajo haya más gente involucrada, pero facilita mucho la labor del cliente final tener claro a quién llamar en caso de necesidad.
• Tener en cuenta que el proceso es largo. La tecnología y las soluciones avanzan a una velocidad inasumible de seguir, eso implica que seguramente nuestra planificación inicial deberá irse corrigiendo, modulando y estirando ya que, seguramente, también llegarán más necesidades desde los despachos. Eso implica, y se debe ser consciente que no habrá un único gran proyecto de Transformación Digital dentro de la compañía, sino que serán varios de tamaño pequeño y medio. Este hecho también servirá para probar la confianza que generan los partners comentados en el paso anterior.

De todos modos, si finalmente nos vemos irremediablemente abocados a los Data Detective, solamente espero que, por deferencia a los fans de la novela negra, éstos lleven sombrero y tirantes… “Cuando vi a ese responsable de IT en mi puerta, supe que no iba a tener una tarde tranquila…”

Fernando Campos, Logitek M2M & IoT Solutions Manager