El paisaje IT de supply chains es casi siempre complejo. De hecho, por naturaleza, los supply chains involucran múltiples actores, múltiples sitios, múltiples sistemas, etc. Como resultado, generar insights basados en datos en supply chains es un desafío debido a la gran heterogeneidad del paisaje IT. Con demasiada frecuencia, la analítica de supply chain entrega resultados sin sentido precisamente por problemas de garbage in, garbage out.

En Lokad, no solo hemos desarrollado una práctica que examina a fondo el paisaje IT y los conjuntos de datos que lo habitan, sino que también hemos creado algunas piezas de tecnología para facilitar las operaciones de inspección en sí mismas. En este post, detallamos un paso de nuestra metodología de inspección, que se basa en la entropía de Shannon. Aprovechamos con éxito el análisis de entropía para varias iniciativas de supply chain a gran escala.

Nuestro proceso de inspección comienza revisando todas las tablas de bases de datos que se consideran relevantes para la iniciativa de supply chain. Los supply chains son complejos y, en consecuencia, los sistemas IT que operan los supply chains reflejan esa complejidad. Además, es posible que los sistemas IT hayan evolucionado durante varias décadas, y las capas de complejidad tienden a acumularse en dichos sistemas. Como resultado, no es raro identificar docenas de tablas de bases de datos, siendo cada tabla compuesta por docenas de columnas, es decir, campos en la terminología de bases de datos.

Para supply chains de gran tamaño, hemos observado situaciones en las que el número total de campos distintos supera los 10,000. Al aprovechar el análisis de entropía, somos capaces de eliminar inmediatamente la mitad de las columnas y, en consecuencia, reducir significativamente la cantidad de trabajo restante.

Lidiar con tantas columnas es una tarea importante. El problema no son las capacidades de procesamiento de datos: con computación en la nube y un almacenamiento de datos adecuado, es relativamente sencillo procesar miles de columnas. El verdadero reto es darle sentido a todos esos campos. Como regla general, estimamos que una documentación bien elaborada de un campo ocupa alrededor de una página, cuando se cubren casos de uso interesantes y casos límite. Sin una documentación adecuada de los datos, se pierden las semánticas de datos, y las probabilidades son muy altas de que cualquier análisis complejo realizado sobre los datos sufra dolores de cabeza masivos por problemas de garbage in, garbage out. Así, con 10,000 campos, nos enfrentamos a la producción de un manual de 10,000 páginas, lo que requiere un esfuerzo realmente monumental.

Sin embargo, hemos observado que esos grandes sistemas IT también cargan con una enorme cantidad de lastre. Aunque el número bruto de campos parece ser muy alto, en la práctica no significa que cada columna encontrada en el sistema contenga datos significativos. En el extremo, la columna podría estar completamente vacía o ser constante y, por lo tanto, no contener ninguna información. Algunos campos pueden descartarse de inmediato porque están realmente vacíos. No obstante, hemos observado que los campos completamente vacíos son en realidad bastante raros. A veces, la única información no constante en la columna data del día en que se activó el sistema; el campo nunca fue reutilizado posteriormente. Si bien los campos verdaderamente vacíos son relativamente infrecuentes, generalmente observamos que los campos degenerados son extremadamente numerosos. Estos campos contienen columnas con casi ningún dato, muy por debajo de cualquier umbral razonable para aprovechar estos datos con fines de producción.

Por ejemplo, una tabla PurchaseOrders que contiene más de un millón de filas podría tener una columna Incoterms que no está vacía en apenas 100 filas; además, todas esas filas tienen más de cinco años de antigüedad, y 90 filas contienen la entrada thisisatest. En este caso, el campo Incoterms es claramente degenerado, y no tiene sentido siquiera intentar darle sentido a estos datos. Sin embargo, un filtro SQL ingenuo no logrará identificar tal columna como degenerada.

Por lo tanto, se necesita una herramienta para identificar columnas degeneradas. Resulta que la entropía de Shannon es una candidata excelente. La entropía de Shannon es una herramienta matemática para medir la cantidad de información contenida en un mensaje. La entropía se mide en Shannons, que es una unidad de medida algo similar a los bits de información. Al tratar los valores encontrados en la columna misma como el mensaje, la entropía de Shannon nos proporciona una medida de la información contenida en la columna, expresada en Shannons.

Aunque todo esto pueda sonar altamente teórico, poner este conocimiento en práctica es extremadamente sencillo. Solo es necesario utilizar el agregador entropy() proporcionado por Envision. El pequeño script a continuación ilustra cómo podemos usar Envision para producir el análisis de entropía de una tabla con 3 campos.

read "data.csv" as T[*]
show table "List of entropies" with
  entropy(T.Field1)
  entropy(T.Field2)
  entropy(T.Field3)

Cualquier campo asociado con una entropía inferior a 0.1 es un muy buen indicador de una columna degenerada. Si la entropía es inferior a 0.01, se garantiza que la columna es degenerada.

Nuestra experiencia indica que realizar un filtrado inicial basado en mediciones de entropía elimina de forma confiable entre un tercio y dos tercios de los campos iniciales del ámbito de interés. El ahorro en tiempo y esfuerzo es muy sustancial: para proyectos de supply chain de gran envergadura, estamos hablando de años hombre ahorrados mediante este análisis.

Descubrimos de manera no intencionada un efecto secundario positivo del filtrado por entropía: reduce la fatiga IT asociada con el (re)descubrimiento de los sistemas IT. De hecho, investigar un campo degenerado suele resultar ser una tarea agotadora. Dado que el campo no se utiliza —a veces, ya no se utiliza—, nadie está del todo seguro de si el campo es realmente degenerado o si está desempeñando un papel crítico, pero oscuro, en los procesos de supply chain. Debido a las complejidades de los supply chains, con frecuencia no hay nadie que pueda afirmar con certeza que un campo dado no se utiliza. El filtrado por entropía elimina de inmediato a los peores culpables, que se garantiza nos llevarán por una búsqueda infructuosa.