Enfoque Práctico

Business Intelligence

Desde hace varios años es un término muy de moda en las organizaciones. Suele ocurrir que los altos ejecutivos recibían algún tipo de charla o inducción y luego instruían a sus departamentos de tecnología la implementación de «eso» lo antes posibles (claro está, había una promesa de un fuerte retorno de inversión).

Ya la idea no es tan extraña. Ya BI no es algo tan abstracto. Cada día se convierte en un activo intangible tecnológico más con que la organización, a cualquier nivel, debe contar.

Business Intelligence puede definirse como el conjunto de habilidades, tecnologías, aplicaciones o prácticas que se emplean para obtener un mejor entendimiento de los negocios. Este mecanismo hace evidente lo que de otra manera no lo sería. De ahí la importancia en el soporte a la toma de decisiones, y no solo a nivel estratégico, sino a nivel táctico como operacional.

Más importante que la tecnología, el verdadero alcance de BI lo define la cultura. Si no existe cultura de análisis en los usuarios finales, se pueden gastar millones de dólares en consultoría, licencias e infraestructura, mas no se logrará obtener el ROI esperado. Al usuario debe inculcársele la necesidad de información y capacitarlos de forma tal que explote aquellos recursos que se le pongan a su disposición.

¿Qué puede obtenerse de BI?

Sea una organización pequeña, mediana o grande, siempre estará inundada de datos. Un sistema de call center, inventarios, facturación, contabilidad, producción, legal, de cualquier industria siempre será una buena fuente de información para entender el negocio.

Las estrategias de BI, que pueden ser profundizadas en este artículo, buscan proveer a la organización del mecanismo de análisis que le permita tomar mejores decisiones. Una vez implementado, debería contarse con:

• Una única versión de la verdad.
• Un repositorio único de donde extraer información consolidada.
• Datos consolidados con una frecuencia mucho menor a los cierres contables/financieros.
• Poder de previsión.
• Mejor uso de los recursos.
• Mejor visibilidad de hacia dónde debe ir la compañía.
• Lo más importante: una cultura de análisis.

Adicinalmente, es probable que una vez establecido y desarrollado el proyecto, deje en evidencia algunas debilidades de los sistemas fuentes. Por ejemplo, falta de validación, problemas de integridad, reduncia, en general, falta de calidad del dato.  Estos hallazgos servirán como insumo para que la organización tome las acciones correctivas necesarias para paliar la situación. Algunas serán procedimentales, otras conllevarán modificaciones en los sistemas fuentes, o ambas.

¿Qué no se puede obtener de BI?

Una solución de BI nunca debe verse como un producto mágico. Si no es acompañada de un adecuado desarrollo de cultura de análisis los esfuerzos serán en vano. El manejo de las expectativas es básico, todos los involucrados deben tener certeza de que los siguientes no son parte del alcance de una solución de BI típica:

• Limpieza de datos: aunque la solución expondrá los problemas de calidad de datos, ésta por sí misma no puede solucionarlos. Este es un tema complejo que es abordado en este artículo.
• Sustitución de expertos de negocio: tampoco puede esperarse que por tener un datawarehouse o datamart ya los expertos de negocio no son necesario. Completamente alejado de la realidad. Más bien es el momento en que estos conocedore apliquen ese know-how en el empleo correcto de la solución de BI.
• Incremento inmediato de las utilidades: es muy difícil pensar en cuantificar los beneficios del proyecto en el ejercicio fiscal inmediatamente posterior. Principalmente en grandes organizaciones, es necesario que la absorción de estos nuevos recursos se dé a gran escala para impactar positivamente los estados financieros. De ahí la importancia de iniciar desarrollos focalizados que permitan una medición más clara de los beneficios de un desarrollo BI.

Una vez claro el panorama de qué es y qué no es BI, se procede a planear la estrategia de BI. Iniciar por un área específica e ir expandiendo el concepto es la clave. Los desarrollos tipo big bang suelen ser contraproducentes. De la misma forma, es recomendable aplicar una metodología iterativa, que permita que el usuario comprenda durante el proceso, el alcance de la herramienta y mejore la definición de sus requerimientos.

Para tener una idea clara de qué tipo de estrategia seguir, se recomienda la lectura del artículo Estrategias BI.

Continuando con el curso, el siguiente concepto por desarrollar será el diseño OLAP. Este concepto fue introducido en el capítulo anterior. Se define como el procesamiento analítico. También puede ser visualizado como una estructura que le permite al analista enfocarse en la información de negocio contextualizando desde múltiples perspectivas. Este análisis será denominada como tren de pensamiento.

¿Datamart o Datawarehouse?

Una datamart se puede definir como una base de datos desnormalizada, que se enfoca en un área específica de negocio. Puede encontrarse el datamart de ventas, finanzas, recursos humanos, producción, mercadeo, entre otros. Un datawarehouse consistiría en un conjunto de datamarts.

La estructura que conforma un datamart será objeto de análisis en este mismo módulo más adelante. Ahora bien, si el datamart es un componente del datawarehouse, ¿es lógico pensar en que el orden de contrucción es primero los datamarts y luego el datawarehouse? No necesariamente. Si hubiese que tomar una decisión, se recomendaría iniciar por un enfoque de datawarehouse, y a partir de este, derivar los datamarts.

Pero eso es la teoría. La realidad indica que el enfoque correcto no existe y dependerá de las circunstancias de cada organización en la que se esté implementando la plataforma de business intelligence. Por ejemplo, si una empresa ya ha desarrollado su datamart de ventas y finanzas, sería un poco ilógico tirar por la borda ese esfuerzo para comenzar a diseñar e implementar un datawarehouse corporativo empresarial.

La justificación para iniciar con un diseño integral se basa en que, al no tener el detalle de las necesidades de cada área o departamento es posible, al menos en el diseño, la reutilización de componentes.

Seguidamente se definirán algunos elementos o conceptos que son necesarios para el diseño de un datamart:

• Dimensión: corresponde a un conjunto de elementos con características comunes que responden a una pregunta de negocio, tal como el qué, quién, dónde, cuándo, cómo, etc. Por ejemplo, la dimensión cliente (quién), producto (qué),  tiempo (cuándo), ubicación (dónde), canal (cómo), entre otras.

• Jerarquía: una dimensión debe contener al menos una jerarquía. Esta puede contener a su vez uno o más niveles. Por ejemplo, la dimensión cliente puede tener una jerarquía que organiza los clientes por su ubicación geográfica. Por ejemplo, un nivel regional, luego se encuentran los países, ciudades y finalmente el nombre del cliente. Por otro lado, es posible que esa misma dimensión también organice los clientes por una clasificación con base en el volumen de compras, así se tienen solo dos niveles: la clasificación y el cliente como tal.

• Nivel: Si una dimensión contiene una jerarquía que se ha estructurado tipo árbol, se denominará nivel a cada peldaño de la estructura. Continuando con el ejemplo indicado anteriormente, la dimensión cliente, en la jerarquía por ubicación geográfica tiene el nivel Región, el nivel País, el nivel Ciudad y el nivel Cliente.

• Categoría: por último, las categorías corresponde a los elementos individuales que van a poblar los niveles. En el ejemplo anterior, en el nivel País, se encuentran las categorías USA, Costa Rica, Colombia, Venezuela, etc. En el nivel ciudad se tiene New York y Miami (como descendientes de USA); San José, Heredia y Cartago (para el caso de Costa Rica); Bogotá y Medellín (Colombia); y finalmente Caracas, Barquisimeto, Valencia y Maracaibo para el caso de Venezuela.

El secreto de un buen diseño es contar con las dimensiones correctas conformadas por las jerarquías correctas. Es recomendable comenzar con un diseño sencillo y posteriormente agregar jerarquías y niveles a medida que el negocio va asimilando la funcionalidad del BI. No es conveniente comenzar con un diseño complejo que más bien generará rechazo en los usuarios finales.

También es buena práctica incluir al usuario final en las pruebas de los cubos que se van generando. Es sumamente valioso la retroalimentación que se puede obtener en esta etapa. Cambios tan sutiles como la etiqueta (caption) de un nivel o el fundir o dividir una dimensión. Esto solo es posible si el usuario está comprometido con el proyecto desde una etapa temprana.

El concepto de dimensión tienen la característica de que las categorías generalmente van a ser alfanuméricas. Es una tendencia mas no una regla. Es posible que bajo algunas circunstancias estas correspondan a valores numéricos.

Para completar de responder las preguntas de negocio (cuándo, qué, quién, dónde, cómo, etc.) es necesario cuantificar. Para ello, existe una dimensión particular que se conoce como Medidas.

Esta dimensión (algunos expertos no consideran las medidas como una dimensión) se encarga de enlazar todas las anteriores. Por ejemplo, un tren de análisis puede dar como resultado que se encuentre que el cliente ABC, compró el producto XYZ, en los meses Ene, Feb y May en los últimos dos años con una tendencia de Precio creciente en un 20% para le mercado local.

Por lo tanto, las medidas son categorías de la dimensión que responden a la pregunta de negocio ¿cuánto? Al unir dimensiones con medidas, se obtienen objetos que se denominarán cubos, y los cubos conformarán un área de análisis particular del negocio, la cual se denominará datamart.

Arquitectura OLAP

Los datamarts han venido implementándose con modelos de datos tipo estrella. Es decir, una tabla de hechos (medidas) central y las tablas de dimensiones alrededor. Bajo este esquema deberían existir al menos dos dimensiones, siendo 10 el número máximo recomendado.

En las tablas de hechos deberán encontrarse valores numéricos de dos tipos:

• Surrogates keys: o llaves surrogadas. Corresponde a un valor numérico que sirve de llave para obtener el valor respectivo de la dimensión en la tabla correspondiente. Habrá solo un surrogate key por dimensión por cada registro indicado en la tabla de hechos.
• Medidas: como se indicó en la sección anterior, corresponden a los valores que cuantifican el análisis.

Además de estar formada por valores numéricos en un 99% de las ocasiones, las tablas de hechos también tienen las siguientes características:

• Son tablas de alto volumen de datos. Se manejan valores en el orden de los cientos de miles hacia arriba.
• Es frecuente encontrarlas fraccionadas por tiempo. El particionamiento con base en el tiempo tienen la ventaja de permitir trabajar con los valores recientes del contexto de una forma práctica y mantener los históricos aislados. Esto no quiere decir que se modifiquen datos.
• La relación con la dimensión tiempo se hace a través de una llave (surrogate key) inteligente. Este punto fue discutido anteriormente acá.

Una variante poco utilizada, pero existente es el empleo de modelos tipo copo de nieve (snow flake), los cuales permiten tener más de una tabla físicamente en la base de datos para una dimensión. Dependerá de la experiencia del arquitecto durante el diseño para identificar la circunstancia adecuada para implementar un diseño de copo de nieve.

Si se está realizando un diseño datamart-datawarehouse, se notará a partir de la implementación del segundo datamart que algunas dimensiones pueden ser utilizadas en más de un área de análisis. Por ejemplo, la dimensión Cliente podría ser utilizada tanto por el área de ventas como por finanzas. De ahí surge el concepto de dimensión compartida.

Por el contrario, si se está diseñando un datawarehouse, todas las dimensiones serán compartidas desde el momento inicial. No es sino hasta entrar en los detalles de cada datamart que se identificarán particularidades que evitan compartir una dimensión en más de un lugar.

¿Cuál es la forma correcta de hacer? Dependerá de las circunstancias. Parece ser más escalable un enfoque que considera toda la organización desde su concepción, no obstante, no implica que dos o más datamarts ya implementados no puedan ser unificados en un gran datawarehouse.

Una vez realizado el diseño de los componentes tipo estrella o copo de nieve en papel, es hora de realizar el diseño físico. Ese tema será desarrollado en el próximo módulo.

Dada la retroalimentación obtenida, se realizará una serie de artículos que abarcarán los conceptos básicos del business intelligence (BI).

No pretende ser exhaustivo, sino dejar claro conceptos básicos que deben ser dominados por quienes interactuan en este sitio. También se hace para servir como base de discusión de los demás artículos.

Los temas serán organizados en módulos y se describen a continuación:

Módulo #1: Introducción a BI

• ¿Qué es business intelligence (BI)?
• ¿Qué puede y qué no puede hacer BI?
• Posibles escenarios para implantar soluciones de BI
• Planeación de una estrategia de BI

Módulo #2: Modelo de Análisis Multidimensional

• Sistemas transaccionales (OLTP)
• Sistemas OLAP
• ¿Cómo pasar de OLTP a OLAP vía ETL?
• Transformación de estructuras de negocio a modelos de análisis

Módulo #3: Diseño OLAP

• Datamart o datawarehouse, ¿por cuál comenzar?
• Estructuras de implementación (copo de nieve, estrella)
• Dimensiones, tablas de hechos y medidas

Módulo #4: Implementación

• MOLAP, ROLAP, HOLAP, ¿cuál es la diferencia? ¿cuál emplear?
• Definición de frecuencia de actualización
• Particionamiento

Modulo #5: Reporteo

• Reportes estándar
• Reportes de propósito específico (ad hoc)
• El negocio expresado como modelo para reportear.
• Autoservicio

Módulo #6: Mantenimiento

• Actualización del datawarehouse o datamart
• Crecimiento de la iniciativa de BI dentro de la organización
• BI como herramienta de toma de decisiones
• Siguientes pasos
• Conclusiones

Cuando se toma la decisión de implantar una sistema de inteligencia de negocios se puede estar seguro que se ha hecho una gran elección. No obstante, ese primer paso está lejos de ser el único y se vienen una serie de decisiones de arquitectura, diseño y alcance que tienen que ser seriamente valoradas.

La experiencia indica que los proyectos que más éxito tienen, son aquellos en los que se emplea el divide y vencerás. En lugar de inmiscuir a toda la organización en el proyecto, se define un alcance, generalmente, departamental o funcional, para implementar una solución BI.

Un sistema puntual bien implementado será el generador e inspirador para contagiar la filosofía del apoyo en la toma de decisiones al resto de la organización.

Independientemente de si es localizado o de gran alcance, el siguiente artículo tiene como objetivo analizar los diferentes enfoques de arquitectura que comúnmente se encuentran en implementaciones de inteligencia de negocios.

Para efectos didácticos, vamos a dividir el análisis en función de la cercanía, o lejanía del sistema implementado, que para este caso será un cubo, y el o los sistemas fuentes (bases de datos de aplicaciones ERP, CRM, MRP, desarrollos a la medida y hasta hojas de cálculo).

Primer Escenario: Fuentes – Cubo

En este caso se encuentran los datos y el cubo fuertemente relacionados. Es tan intrínsico que no hay mayor mediación o herramientas entre ellos. Dependiendo de la tecnología empleada, la generación o consulta del cubo puede crear una gran sobrecarga en los recursos del sistema fuente o transaccional.

Estas implementaciones suelen encontrarse en organizaciones que no han madurado la cultura BI y es posible que estén desarrollando su primer cubo.

Su arquitectura suele estar reducida a una, dos o máximo tres aplicaciones, a saber: las fuentes de datos, el modelador o diseñador de cubo (quien tendrá la sobrecarga de fungir también como herramienta ETL) y el visualizador del cubo.

A su vez, el cubo puede estar en línea con los datos, es decir, se procesa cada vez que el usuario realiza un análisis o puede ser una foto en el tiempo de los datos transaccionales, en este caso hay un mayor tiempo de procesamiento, y un mejor tiempo de respuesta al usuario final.

Entre las ventajas que conlleva serían:

• Rápida implementación.
• Sencillez de arquitectura: no hay mayor cantidad de componentes involucrados, por lo que las interfaces y elementos relacionados son mínimos.
• Es ideal para la implementación de pruebas de conceptos y evaluación de nuevas tecnologías OLAP.

Entre las desventajas se puede enumerar:

• Mantenimiento constante: al estar tan ligado al sistema transaccional, y ser este por naturaleza dinámico, es probable que en poco tiempo sea necesario aplicar labores de mantenimiento.
• Podrían generarse inconsistencias de datos ya que no hay tratamiento o transformación de los mismos.
• Es un enfoque poco escalable y no reutilizable.
• La generación del cubo puede degradar sustancialmente el rendimiento de las aplicaciones fuentes debido a la gran cantidad de consultas.

Esta última desventaja suele ser la principal causa para desestimar este enfoque en un ambiente de producción. Máxime si el cubo lee información de sistemas críticos que no deberían afectar su rendimiento en ningún momento.

Segundo Escenario: Fuentes – Staging- Cubo

En el segundo escenario encontramos un repositorio intermedio denominado staging area. No se denominará datawarehouse porque en este punto aún no cumple con las características de uno.

Esta situación suele ser el paso natural que dan las implementación una vez que han confirmado que el escenario uno no es funcional. Sin embargo, no se cuenta aún con la esperiencia para pasar a un modelo más avanzado.

Su arquitectura involucra los siguientes elementos:

• Datos: serán las múltiples fuentes desde las cuales se leerá la información transaccional.
• Staging: área de consolidación de las fuentes de datos.
• Modelador o diseñador del cubo.
• Visualizador.

En este esquema es común encontrar por primera vez algún proceso, aunque sea informal, de ETL, el cual se encargará de alimentar el staging. Estos procesos ETL tendrán pocas validaciones, y en su mayoría, se limitarán a la copia de datos, más que a su procesamiento.

Entre sus ventajas:

• Es una clara señal de madurez.
• Se hace el primer intento de validación, consolidación y transformación de datos.
• Las cargas se harán en momentos en que no se afecte los sistemas fuentes.
• Se comienza a abstraer los conceptos de análisis de las tablas y columnas originales. Es decir, en esta etapa ya se habla de entidades como CLIENTE, FECHA o PROVEEDOR.

Algunas desventajas:

• No se contará con una correcta administración de la historia.
• Al inicio puede ser funcional, pero comenzará a decaer el rendimiento debido al volumen.

Tercer Escenario: Fuente – Staging – Datawarehouse – Cubo

Considerado como una etapa de madurez. No es común encontrarla en los primeros años de implementación. Su arquitectura suele ser más compleja, pero más robusta.

Se caracteriza por la abstracción de las entidades de negocio de las particularidades de los sistemas de almacenamiento transaccional. También hay un correcto manejo de la historia.

Formalmente se tiene:

• Fuentes: sistemas desde los que se leerá la información transaccional.
• Staging: repositorio intermedio.
• Datawarehouse: corazón del sistema.
• Modelador o diseñador del cubo.
• Visualizador.

La introducción del datawarehouse implica la consolidación de las mejores prácticas. Un buen diseño garantizará robustez, integridad, escalabilidad, y la preparación para la siguiente etapa. El proceso ETL, involucrado en la carga de datos crudos de los sistemas transaccionales al staging, procesamientos, transformaciones y por último escritura de los mismos en el datawarehouse, será el motor que le dará la vitalidad y dinamismo al sistema en su totalidad.

Son muchas las ventajas de contar con un datawarehouse, algunas de ellas son:

• Consolidación de datos en entidades de negocio (cliente, proveedor, país, fecha).
• Transformación y estandarización de datos: corregir aspectos tan simples como el género (H o M vrs Hombre o Mujer vrs 1 ó 0), unidades de medida, etc.
• El proceso de construcción del cubo se simplifica al no tener que realizar depuración de datos.

Siempre existen algunas desventajas en cualquier sistema, y este no es la excepción:

• El sistema será mucho más complejo, y por ende su mantenimiento dependerá de una excelente documentación.
• Implicará el uso de herramientas especializadas para la implementación del ETL, lo que acarreará costos económicos y de recursos de hardware.
• Suele crearse dependencia. El datawarehouse se convierte en la única versión de la verdad. Por ende cualquier caída del sistema generará sentimiento de dependencia e impotencia.
• El tiempo que transcurre entre el dato en el sistema transaccional y su incorporación al cubo suele ser mucho mayor que el del primer escenario.

Este es el mínimo esquema al que deberían apostar las organizaciones, son muchos los beneficios, pero tendrán que pasar por un proceso para llegar al él. Es utópico pensar que en una implementación de 3 meses se tendrá un arquitectura robusta como la descrita en este último punto.

Cuarto Escenario: Fuente – Staging – Datawarehouse – Datamart – Cubo

La culminación de la madurez en el proceso debería alcanzarse con la especialización del datawarehouse. Estos sistemas suelen crecer y tomar enormes proporciones. Por ende, y por motivos de seguridad es conveniente el particionamiento de los datos en segmentos más manejables denominados datamarts.

Estos entes contendrán la información para una única área de análisis, funcional o departamental, pero siempre, derivada de la fuente única denominada datawarehouse.

¿En cuál escenario se encuentra su organización? ¿Cuál es su escenario ideal? Todo depende del tiempo dedicado a la cultura business intelligence. Eso sí, podrá estar seguro que estará apoyando la toma de decisiones.