Inteligencia de Negocios (BI)

BI (Business Intelligence) se refiere a una clase de software empresarial dedicado a la producción de informes analíticos basados principalmente en los datos transaccionales recopilados a través de los diversos sistemas empresariales que la compañía utiliza para operar. BI está diseñado para ofrecer capacidades de generación de informes de autoservicio a usuarios que no son especialistas en TI. Estas capacidades de autoservicio pueden ir desde ajustar parámetros en informes existentes hasta la creación de informes completamente nuevos. La mayoría de las grandes compañías tienen al menos un sistema de BI en operación encima de sus sistemas transaccionales, que con frecuencia incluye un ERP.

Origen y motivación

El informe analítico moderno surgió con los primeros pronosticadores económicos^{1 2}, predominantemente en EE.UU., a principios del siglo XX. Esta primera iteración resultó sumamente popular, recibiendo atención de la prensa general y una amplia circulación. Esta popularidad demostró que existía un marcado interés en informes cuantitativos de alta densidad informativa. Durante la década de 1980, muchas grandes compañías comenzaron a preservar sus transacciones comerciales como registros electrónicos, almacenados en bases de datos transaccionales, aprovechando típicamente algunas de las primeras soluciones ERP. Estas ERP estaban destinadas principalmente a agilizar los procesos existentes, mejorando la productividad y la fiabilidad. Sin embargo, muchos comprendieron el enorme potencial no explotado de estos registros y, en 1983, SAP introdujo el lenguaje de programación ABAP ³, dedicado a la generación de informes basados en los datos recopilados dentro del propio ERP.

Sin embargo, los sistemas de bases de datos relacionales, tal como se vendían típicamente en los años 80, presentaban dos limitaciones principales en lo que respecta a la producción de informes analíticos. Primero, el diseño de los informes debía ser realizado por especialistas en TI altamente capacitados. Esto hacía que el proceso fuera lento y costoso, limitando severamente la diversidad de informes que se podían implementar. Segundo, la generación de los informes exigía mucho al hardware informático. Por lo general, los informes sólo podían producirse durante la noche (y en batch), cuando las operaciones de la empresa habían cesado. En cierta medida, esto reflejaba las limitaciones del hardware informático de la época, pero también reflejaba limitaciones de software.

A principios de la década de 1990, el avance del hardware informático permitió la aparición de una clase diferente de soluciones de software ⁴, soluciones de Business Intelligence. El costo de la RAM (memoria de acceso aleatorio) había estado disminuyendo de forma constante, mientras que su capacidad de almacenamiento había estado aumentando de forma constante. Como resultado, almacenar una versión especializada y más compacta de los datos empresariales en memoria (en RAM) para un acceso inmediato se convirtió en una solución viable, desde el punto de vista tanto tecnológico como económico. Estos avances abordaron las dos limitaciones principales de los sistemas de informes implementados una década antes: las interfaces front-end de software más recientes eran mucho más accesibles para los no especialistas; y las nuevas arquitecturas back-end de software – que incorporaban tecnologías OLAP (discutidas a continuación) – eliminaron algunas de las mayores restricciones en TI. Gracias a estos avances, al final de la década, las soluciones de BI se habían vuelto comunes entre las grandes compañías.

A medida que el hardware informático continuó avanzando, una nueva generación de herramientas de BI surgió ⁵ a finales de la década de 2000. Los sistemas de bases de datos relacionales de los años 80, que eran incapaces de producir informes de manera conveniente, se volvieron, en la década de 2000, cada vez más capaces de albergar el historial transaccional completo de una empresa en RAM. Como resultado, consultas analíticas complejas podían completarse en segundos sin un back-end dedicado de OLAP. Así, el enfoque de las soluciones de BI se desplazó al front-end, ofreciendo interfaces de usuario web aún más accesibles - predominantemente SaaS (software-as-a-service) - mientras incorporaban paneles de control cada vez más interactivos que aprovechaban la versatilidad del back-end relacional.

OLAP y cubos multidimensionales

OLAP significa procesamiento analítico en línea. OLAP se asocia con el diseño del back-end de una solución de BI. El término, acuñado en 1993 por Edgar Codd, agrupa una serie de ideas de diseño de software ⁶, la mayoría de las cuales son anteriores a la década de 1990, e incluso algunas se remontan a la década de 1960. Estas ideas de diseño fueron fundamentales para el surgimiento de BI como una clase de productos de software distintiva en la década de 1990. OLAP abordó el desafío de poder producir informes analíticos frescos de manera oportuna, incluso cuando la cantidad de datos involucrados en la producción del informe era demasiado grande para ser procesada rápidamente.

La técnica más sencilla para producir un informe analítico fresco implica leer los datos al menos una vez. Sin embargo, si el conjunto de datos es tan grande ⁷ que leerlo en su totalidad toma horas (si no días), entonces producir un informe fresco también requerirá horas o días. Por lo tanto, para producir un informe actualizado en segundos, la técnica no puede implicar volver a leer el conjunto de datos completo cada vez que se solicite una actualización del informe.

OLAP propone aprovechar estructuras de datos más pequeñas y compactas - que reflejen los informes de interés. Estas estructuras de datos específicas están diseñadas para actualizarse de forma incremental a medida que se dispone de nuevos datos. Como resultado, cuando se solicita un informe fresco, el sistema de BI no tiene que volver a leer el conjunto de datos históricos completo, sino únicamente la estructura de datos compacta que contiene toda la información necesaria para generar el informe. Además, si la estructura de datos es lo suficientemente pequeña, puede mantenerse en memoria (en RAM) y, por lo tanto, accederse más rápidamente que al almacenamiento persistente utilizado para los datos transaccionales.

Considera el siguiente ejemplo: imagina una red de distribución que opera 100 hipermercados. El director financiero (CFO) quiere un informe con las ventas totales en euros por tienda por día durante los últimos 3 años. Los datos históricos brutos de ventas de los últimos 3 años representan más de 1 mil millones de líneas de datos (cada código de barras escaneado en cada tienda durante este período) y más de 50GB en su formato tabular original. Sin embargo, una tabla con 100 columnas (1 por hipermercado) y 1095 líneas (3 años * 365 días) suma menos de 0.5MB (a razón de 4 bytes por número). Además, cada vez que ocurre una transacción, las celdas correspondientes en la tabla se pueden actualizar en consecuencia. Crear y mantener una tabla así ilustra cómo es un sistema OLAP por dentro.

Las estructuras de datos compactas descritas anteriormente suelen tomar la forma de un cubo OLAP, también llamado cubo multidimensional. Las celdas existen en el cubo en la intersección de las dimensiones discretas que definen la estructura general del cubo. Cada celda contiene una medida (o valor) extraída de los datos transaccionales originales, a menudo referida como la tabla de hechos. Esta estructura de datos es similar a los arreglos multidimensionales que se encuentran en la mayoría de los lenguajes de programación convencionales. El cubo OLAP se presta a operaciones eficientes de proyección o agregación a lo largo de las dimensiones (como sumar y promediar), siempre que el cubo se mantenga lo suficientemente pequeño como para caber en la memoria del ordenador.

Informes interactivos y visualización de datos

Hacer que las capacidades de generación de informes sean accesibles para los usuarios finales que no eran especialistas en TI fue un factor clave en la adopción de herramientas de BI. Como tal, la tecnología adoptó un diseño WYSIWYG (lo que ves es lo que obtienes), basándose en interfaces de usuario ricas. Este enfoque difiere del método habitual para interactuar con una base de datos relacional, que consiste en componer consultas utilizando un lenguaje especializado (como SQL). La interfaz habitual para manipular un cubo OLAP es una interfaz matricial, como las tablas dinámicas en un programa de hoja de cálculo, que permite a los usuarios aplicar filtros (denominados slice and dice en la terminología de BI) y realizar agregaciones (promedio, mínimo, máximo, suma, etc.).

Excepto por el procesamiento de conjuntos de datos especialmente grandes, la necesidad de cubos OLAP disminuyó a finales de la década de 2000, en paralelo con los enormes avances realizados en el hardware informático. Se introdujeron herramientas de BI “delgadas” con un enfoque exclusivo en el front-end. Las herramientas de BI delgadas fueron diseñadas principalmente para interactuar con bases de datos relacionales, a diferencia de sus predecesoras “gruesas” que aprovechaban back-ends integrados con cubos OLAP. Esta evolución fue posible porque el rendimiento de las bases de datos relacionales, en ese momento, permitía generalmente que consultas complejas se ejecutaran sobre el conjunto de datos completo en segundos – de nuevo, siempre que el conjunto de datos se mantuviera por debajo de cierto tamaño. Las herramientas de BI delgadas pueden ser vistas como editores WYSIWYG unificados para los diversos dialectos SQL que soportaban. (De hecho, por detrás de escena, estas herramientas de BI generan consultas SQL). El principal desafío técnico fue la optimización de las consultas generadas, con el fin de minimizar el tiempo de respuesta de la base de datos relacional subyacente.

Las capacidades de visualización de datos de las herramientas de BI dependían en gran medida de la presentación de los datos en el lado del cliente, ya sea a través de una aplicación de escritorio o web. Las capacidades de presentación progresaron de forma constante hasta la década de 2000, cuando el hardware del usuario final (por ejemplo, estaciones de trabajo y portátiles) comenzó a superar ampliamente (en términos computacionales) lo que se necesitaba para propósitos de visualización de datos. Hoy en día, incluso las visualizaciones de datos más elaboradas son procesos poco exigentes, opacadas en escala por el consumo de recursos informáticos asociados con la extracción y transformación de los datos subyacentes que se están visualizando.

El impacto organizacional de la BI

Si bien la facilidad de acceso ha sido un factor decisivo para la adopción de la mayoría de las herramientas de BI, navegar por el panorama de datos de las grandes empresas es difícil, aunque sea solo por la gran diversidad de datos disponibles. Además, incluso si la herramienta de BI es bastante accesible, la lógica de generación de informes que implementan las empresas a través de las herramientas de BI tiende a reflejar la complejidad del negocio y, como resultado, la propia lógica puede ser mucho menos accesible que la herramienta que la respalda.

Como resultado, la adopción de herramientas de BI llevó – para la mayoría de las grandes empresas – a la creación de equipos de análisis dedicados, que suelen operar como una función de soporte junto al departamento de TI. Como predice la Ley de Parkinson, el trabajo se expande para llenar el tiempo disponible para su finalización; estos equipos tienden a expandirse con el tiempo junto con el número de informes generados, independientemente de los beneficios obtenidos (percibidos o reales) por la empresa al tener acceso a dichos informes.

Límites técnicos de la BI

Como suele ser el caso, existe un compromiso entre virtudes en lo que respecta a las herramientas de BI, es decir, que una mayor facilidad de acceso tiene como costo una menor expresividad; en este caso, las transformaciones aplicadas a los datos se limitan a una clase relativamente estrecha de filtros y agregaciones. Esta es la primera limitación importante, ya que muchas – si no la mayoría – de las preguntas empresariales no pueden abordarse con esos operadores (por ejemplo, ¿cuál es el riesgo de churn de un cliente?). Por supuesto, es posible introducir operadores avanzados en la interfaz de usuario de la BI, sin embargo, dichas funciones “avanzadas” contradicen ⁸ el propósito inicial de hacer la herramienta fácilmente accesible para usuarios no técnicos. Así, diseñar consultas avanzadas de datos no es diferente a construir software, una tarea que resulta inherentemente difícil. A modo de evidencia anecdótica, la mayoría de las herramientas de BI ofrecen la posibilidad de escribir consultas “en crudo” (típicamente en SQL o en un dialecto similar a SQL), recurriendo al camino técnico que se suponía debía eliminar la herramienta.

La segunda gran limitación es la performance. Esta limitación se presenta en dos variantes distintas para las herramientas de BI delgadas y gruesas, respectivamente. Las herramientas de BI delgadas típicamente incluyen lógica sofisticada para optimizar las consultas a la base de datos que generan. Sin embargo, estas herramientas están, en última instancia, limitadas por el rendimiento que puede ofrecer la base de datos que actúa como back-end. Una consulta aparentemente simple puede resultar ineficiente de ejecutar, lo que conduce a largos tiempos de respuesta. Un ingeniero de bases de datos ciertamente puede modificar y mejorar la base de datos para abordar esta problemática. Sin embargo, una vez más, esta solución contradice el objetivo inicial de mantener la herramienta de BI accesible para usuarios no técnicos.

Las herramientas de BI gruesas tienen su rendimiento limitado por el diseño de los propios cubos OLAP. Primero, la cantidad de RAM requerida para mantener un cubo multidimensional en memoria aumenta rápidamente a medida que se incrementan las dimensiones del cubo. Incluso un número moderado de dimensiones (por ejemplo, 10) puede conducir a problemas severos asociados con el uso de memoria del cubo. Más generalmente, los diseños en memoria (siendo los cubos OLAP los más frecuentes) suelen sufrir de problemas relacionados con la memoria.

Además, el cubo es una representación con pérdida de los datos transaccionales originales: ningún análisis realizado con el cubo puede recuperar la información que se perdió en primer lugar. Recuerda el ejemplo del hipermercado. En tal escenario, las cestas no pueden ser representadas en un cubo. Por lo tanto, se pierde la información de “comprados juntos”. El diseño global del “cubo” en OLAP limita severamente qué datos pueden incluso representarse; sin embargo, esta limitación es precisamente lo que hace posible la propiedad “en línea” en primer lugar.

Límites empresariales de la BI

La introducción de herramientas de BI en una empresa es menos transformadora de lo que podría parecer. En pocas palabras, producir números, por sí solos, no tiene valor para la empresa si no se asocia ninguna acción a esos números. El propio diseño de las herramientas de BI enfatiza una producción “ilimitada” de informes, pero dicho diseño no respalda ningún curso de acción real. De hecho, en la mayoría de los casos, la escasa expresividad de las herramientas de BI resulta demasiado limitada a la hora de automatizar cualquier cosa basada en los informes de BI.

Además, la herramienta de BI tiende a exacerbar las tendencias burocráticas de las grandes empresas. La evidencia anecdótica, cifras aproximadas y un buen juicio a menudo son suficientes para establecer prioridades en una empresa. Sin embargo, la existencia de una herramienta analítica de autoservicio – como la BI – brinda amplias oportunidades para procrastinar y enturbiar las aguas con un flujo incesante de métricas cuestionables y no accionables.

Las herramientas BI son vulnerables a los problemas de design by committee en los que se incluyen las ideas de todos en el proyecto. La naturaleza de autoservicio de la herramienta enfatiza un enfoque ampliamente inclusivo cuando se introducen nuevos informes. Como resultado, la complejidad del panorama de informes tiende a crecer con el tiempo, independientemente de la complejidad del negocio que esos informes se supone deben reflejar. El término vanity metrics se ha vuelto ampliamente utilizado para reflejar métricas –usualmente implementadas a través de una herramienta BI– como estas que no contribuyen al resultado final de la empresa.

La perspectiva de Lokad

Considerando las capacidades del hardware de computación moderno, utilizar un sistema de informes para generar 1 millón de números por día es fácil; producir 10 números por día que valga la pena leer es difícil. Mientras que una herramienta BI utilizada en dosis pequeñas es algo bueno para la mayoría de las empresas, en dosis mayores se convierte en veneno.

En la práctica, solo se pueden obtener tantas perspectivas de la BI. La introducción de cada vez más informes resulta en rendimientos decrecientes rápidamente en términos de nuevas (o mejoradas) perspectivas obtenidas a través de cada informe adicional. Recuerde, la profundidad del análisis de datos accesible desde una herramienta BI está limitada por diseño ya que las consultas deben permanecer fácilmente accesibles para los no especialistas a través de la interfaz de usuario.

Además, incluso cuando se adquiere una nueva perspectiva a partir de los datos, ello no implica que la empresa pueda convertirla en algo ejecutable. La BI es, en esencia, una tecnología de informes: no enfatiza ningún llamado a la acción para la empresa. El paradigma de la BI no está orientado a automatizar las decisiones empresariales (ni siquiera las mundanas).

Las características de la plataforma Lokad incluyen amplias capacidades de informes a medida, como en la BI. Sin embargo, a diferencia de la BI, Lokad está orientado a la optimización de las decisiones empresariales, más específicamente de aquellas relacionadas con supply chain. En la práctica, recomendamos contar con un Supply Chain Scientist a cargo del diseño, y posteriormente del mantenimiento, de la receta numérica que genera – a través de Lokad – las decisiones de supply chain de interés.

Notas