A investigar os mistérios do Big Data
Data Detective? A AutomationWorld publicou um artigo interessante sobre os futuros empregos que vão ser gerados devido aos processos de transformação digital em que todos estamos envolvidos...

Há uns dias, a revista AutomationWorld publicou um artigo interessante sobre os futuros empregos que vão ser gerados devido aos processos de transformação digital em que todos estamos envolvidos. Um deles, que dá nome ao artigo, é o de Data Detective, posição encarregada de ‘investigating the mysteries of Big Data, uncovering secrets within the content by examining sensors, devices, fog computing and neural networks.’
Do meu ponto de vista, concordo que esta posição, com este nome ou outro, acabará por existir, ainda que seja certo que lhe acrescentaria uma nuance. Um bom Data Detective deverá investigar por que razão os resultados extraídos dos dados não se aplicam ou coincidem com a realidade.
Atualmente, todas as indústrias de processo e infraestruturas estão a trabalhar ou a avaliar ferramentas de análise de dados, quer sejam ferramentas analíticas, de Business Intelligence, de manutenção preventiva, de otimização de recursos, etc. Mas a abordagem destas integrações, na sua maioria, costuma ser feita de ‘alto’. Este tipo de ferramenta nutre-se de dados armazenados em BBDD, e é a partir destes que extraem as suas conclusões a partir de grandes processos e algoritmos complexos.

Para o mundo industrial e de infraestruturas existe um problema de base nisto. Estes dados guardados em BBDD não foram guardados ali com a finalidade de serem explorados por este tipo de ferramenta, mas sim gerados e contextualizados para outro tipo de aplicação – um SCADA tipicamente. Este facto diferencial implica que estas ferramentas estão a trabalhar sobre um campo de amostragem que não está devidamente concebido ou preparado para tal. No mundo industrial, hoje em dia, há uma máxima: o gargalo tecnológico para o uso dessas ferramentas é uma correta aquisição de dados de campo.
Para dar um exemplo, numa indústria de fabrico de peças de automóvel, sabe-se que 6% das peças saem defeituosas e são descartadas no momento. Essa informação é a que chega aos repositórios que utilizam o seu SCADA e ERP. Ora bem, o mais interessante seria que essas ferramentas pudessem saber mais sobre as peças descartadas, o seu percurso de fabrico e os diferentes elementos que estiveram implicados, material, fornecedor, maquinaria de estampagem, cintas de transporte, pessoal ativo, etc. Mas, para poder fazer estas correlações, o sistema necessita de cumprir umas características que não terá. Perante este cenário, estas ferramentas ou não saberão extrair uma conclusão ou, ainda pior, extrairão uma conclusão errada.
É por isso que creio que chegaremos à figura do Data Detective. Não me aventuro em se será uma posição interna das companhias ou consultorias externas, mas tenho clara a sua missão. Investigar o porquê de as ferramentas de exploração contratadas não estarem a ter o ROI desejado, ou seja, uma vez revista a ferramenta e os seus algoritmos e comprovado que tudo está correto a esse nível, onde estão as falhas de contextualização das fontes de dados. Na sua correta aquisição, na sua manipulação, na frequência de amostragem, na sua estampagem temporal, no volume com que se trabalha, em que me falta adquirir informação de uns elementos-chave…?

Este Data Detective, o mais certo é que deverá investigar, coordenar-se e entender os múltiplos atores envolvidos no processo e que, o mais certo, é que, caso essas ferramentas não tenham os resultados esperados, nenhum se vá sentir responsável por isso. E, por muito que nos custe, seguramente todos terão razão. Se as fontes de dados não foram devidamente preparadas para tal, uma aplicação de manutenção preventiva poderá trabalhar com o que puder, mas é evidente que não poderá extrair as conclusões mais acertadas, por exemplo.
Por isso, para evitar ter de necessitar de um Data Detective, podemos propor várias iniciativas, não excludentes entre elas:
- Utilizar um Plano Diretor de transformação digital, ou seja, trabalhar numa estratégia conjunta que englobe todos os níveis de uma indústria, tendo em conta as necessidades específicas de cada nível, mas também as transversais – a cibersegurança, por exemplo -.
- Contar com parceiros de confiança, quer seja nas próprias ferramentas, quer nos serviços que estão subjacentes por detrás de cada projeto. É evidente que, quanto mais atores, mais gente a quem chamar, mais gente para coordenar, mais gente que se justifica, etc. Ter dois ou um único parceiro como Main Director dos projetos não implica que, por baixo, haja mais gente envolvida, mas facilita muito a tarefa do cliente final ter claro a quem chamar em caso de necessidade.
- Ter em conta que o processo é longo. A tecnologia e as soluções avançam a uma velocidade impossível de acompanhar, isso implica que, seguramente, o nosso planeamento inicial deverá ir sendo corrigido, modulado e esticado, já que, seguramente, também chegarão mais necessidades dos escritórios. Isso implica, e deve-se estar consciente de que não haverá um único grande projeto de Transformação Digital dentro da companhia, mas sim vários de tamanho pequeno e médio. Este facto também servirá para provar a confiança que os parceiros comentados no passo anterior geram.
De todos os modos, se finalmente nos virmos irremediavelmente votados aos Data Detective, somente espero que, por deferência aos fãs do romance negro, estes usem chapéu e suspensórios… “Quando vi aquele responsável de IT à minha porta, soube que não ia ter uma tarde tranquila…”
Fernando Campos, Logitek M2M & IoT Solutions Manager





