Enfoque Práctico

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.