¿Qué es lo primero que viene a su mente cuando lee Planning?

Para Enfoque Práctico, Planning se refiere a un concepto que abarca: la planeación financiera, pronóstico, estudio de escenario del tipo “¿qué pasa si…?“, presupuestación, pronosticos mensuales.

Si para usted ese concepto no le suena familiar, no se preocupe. La experiencia indica que el concepto de planeación está relacionado con madurez de negocio y explotación del análisis de datos.

Una organización que ha realizado y madurado una implementación de inteligencia de negocios (BI), encontrará que el ciclo necesita cerrarse con algo más. El BI me permite monitorear cómo va el negocio y comprender las razones del por qué pasó lo que pasó, pero a medida que se avanza en el tiempo, se adquiere experiencia suficiente como para comenzar a pronosticar qué debería pasar. Es ahí donde se da el siguiente paso y se comienzan a realizar ejercicios de planning en diversas áreas.

Ahora bien, probablemente usted estará pensando que en su organización ya se realiza un presupuesto. Y es tan formal que está asociado a una presentación de la junta directiva en donde se aprueban cada una de las partidas. En esa junta cada miembro tiene un gran libro que con un título como “Operating Expenses” o “Gastos Operativos” para el año 20xx.

Eso está muy bien. Pero esa misma formalidad hace que el proceso sea poco flexible. Generalmente esos procesos de presupuesto solo se basan en aspectos básicos de la organización, como gastos operativos o ventas.

El proceso de planning deberá abarcar los aspectos claves de su negocio, no simplemente los puntos operativos. Inclusive, si usted inicia su proceso de planeación con estos aspectos básicos, encontrará la planeación mucho más versátil. El solo hecho de eliminar las hojas de cálculo y contar con análisis multidimensional le brindará muchísimo valor agregado.

Probablemente pasará de tener uno o dos versiones anuales del presupuesto operativo a contar con 13 ó 14 (dependiendo de sus procesos de cierre o calendario no tradicional). Esta flexibilidad le permite controlar y optimizar esos rubros que, al verlos anualizados, no se les daba la importancia requerida.

Aventúrese a dar el paso hacia la planificación, aunque sea con el aspecto más simple de sus procesos. Verá como poco a poco podrá comenzar a hacer pronósticos mejores y más acertados de los aspectos más complejos de su organización.

La primera vez que estaba haciendo algo parecido a BI, la dimensión tiempo se generaba a partir de un campo de tipo datetime en la tabla de hechos. Para ese entonces estaba empleando Cognos y era lo único que necesitaba para generar la jerarquía, con todos los niveles e inclusive los típicos acumulados por año, mes, trimestre, etc.

No obstante, es mucho más útil tener una verdadera dimensión tiempo definida y cargada en el datawarehouse, lo cual, genera algunas dudas como ¿de dónde la cargo?, ¿cada cuánto la actualizo?, ¿qué atributos incluyo?, ¿cuál nivel de granularidad? Entre otras.

Y si a eso se le suma complejidad que podría presentar el tener una implementación en varios husos horarios o el hecho de que sea multilenguaje. Todos estos factores deben ser tomados en cuenta desde el inicio del diseño del datawarehouse.

Un parámetro básico del cual se puede partir para obtener los primeros atributos de la dimensión es considerar todos aquellos datos que podemos derivar desde el motor de base de datos. Para el caso particular de Microsoft SQL Server, todo lo que se puede obtener de la función datepart (mes, año, día, nombre de mes, etc.).

Independientemente al tipo de arquitectura o diseño empleado, hay un aspecto fundamental: el campo llave inteligente. Cruzar datos desde la tabla de hechos y la dimensión tiempo vía un valor date o datetime sería sumamente costoso. Por ende, debe realizarse un trabajo en el procesamiento de la dimensión (tiempo de ejecución ETL), en el cual se crea una llave especial para cada registro de esta dimensión. Por ejemplo, un registro con fecha 27-ene-2010, deberá tener como llave para el cruce con la tabla de hechos a un número entero, a saber: 20100127. También puede usarse la notación tipo offset, como la que emplea Microsoft Excel, en la cual la fecha se representa como la cantidad de días pasados desde el 01 de enero del año 1900. En cualquiera de los dos casos, un join con números enteros será mucho más eficiente que una operación comparativa con datetimes o dates.

Tipos de Calendarios

Hasta el momento no se ha profundizado sobre el tipo de calendario que se empleará. Para un diseñador sería mucho más fácil que toda organización que implementa una solución BI/DW cuente con un calendario de actividades uniformes, no obstante, eso está muy lejos de la realidad.

Las variantes generalmente son de dos tipos:

  • En granularidad
  • En distribución del tiempo

En el primer caso se tienen que tomar decisiones sobre cuál es la unidad de tiempo más pequeña en el DW. Día suele ser una buena decisión, pero algunas compañías, como telecoms, probablemente necesitarán realizar consultas con ventanas de tiempo más pequeñas, como minutos e inclusive segundos. Acá es donde el arquitecto debe encontrar el equilibrio entre rendimiento y funcionalidad. Mientras más pequeña sea la unidad de tiempo, mayor volumen de datos. Un día tiene 86400 segundos, así que un año con granularidad al segundo, contará con más de 31 millones de registros.

En el segundo caso, el problema radica en que la organización no emplea el calendario natural o Gregoriano para registrar sus transacciones. Se presenta comúnmente en empresas de manufactura, en las cuales los ciclos de producción están representados por 4 semanas (28 días) y el año cuenta con 13 periodos. Por ende, hay que personalizar la dimensión tiempo o bien crear las equivalencias en cada registro.

Ejemplo: diseño básico de dimensión tiempo

Supóngase que se tiene una empresa de producción. Por razones corporativas, todas las operación de la planta se basan en ciclos de 4 semanas y se agrupan en periodos. El año cuenta con 13 periodos y no siempre comienza el mismo día. El primer día del año 2010 comenzó el 28 de diciembre de 2009. Todos los reportes de producción, manufactura y logística deben ser realizados tomando en cuenta este calendario.

Por otro lado, los departamentos financieros y administrativos, realizan los cortes mensuales con base en el calendario Gregoriano o natural. Es de suma importancia determinar cuáles son los últimos días de mes, natural o corporativo, ya que se dan picos de actividades propias del negocio.

¿Cómo quedaría el diseño de esta dimensión?

En la imagen adjunta se aprecia un diseño, no exhaustivo, pero representativo de los campos básicos para crear una dimensión tiempo que cumpla con los requisitos de análisis, tanto para la perspectiva del usuario que emplea el calendario natural, como aquel que emplea el calendario corporativo.

Nótese que se incluyeron campos que indican si se encuentra en el último día de mes o si es feriado. Así como también la dualidad entre el calendario natural y el calendario corporativo.

La forma más práctica de llenar esta tabla es a través de un script de SQL o bien, sentarse algunas horas frente a una hoja electrónica y llenar manualmente cada campo, cosa poco remomendada y propensa a muchos errores.

En caso de que se usaran otros lenguajes, es probable que existiesen campos adicionales con los captions respectivos para cada uno de ellos.

Por último, si se cuenta con transacciones en más de un huso horario, es común incorporar una hora corporativa y una hora local en los registros de la tabla de hechos para ubicar correctamente en el tiempo el evento.

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.

Magic Quadrant BI 2009Comenzaremos este blog comentando una guerra que se está suscitando en el mercado actual: ser el número uno en el cuadrante mágico de Gartner.

Esta disputa, como la mayoría, deberían beneficiar a los clientes. Todos las casas fabricantes del software quieren aumentar su participación en el mercado. Aunque para ello deban prácticamente regalar sus licencias o servicios.

Para efectos de este artículo, se centrará el análisis en Cognos (recientemente adquirida por IBM) y en Microsoft (empresa que cada vez abarca más cuota de mercado en las áreas en que clásicamente no ha sido líder).

Si reducimos el mercado a Latinoamérica, se encuentra una situación muy particular: Cognos ostenta una grandiosa cuota de mercado en empresas grandes, pero, factores como la crisis financiera, la reducción de gastos y la aparición en el mercado de nuevos y mejorados productos como los de Microsoft, han provocado la migración.

Cognos siempre ha sido el Mercedes Benz del Business Intelligence y Performance Management. Esto por el precio y la funcionalidad. Es común encontrar soluciones de clientes donde emplean Microsoft SQL Server 2000 y DTS para el back-end y Cognos PowerPlay 6.x ó 7.x para el front-end.

La aparición de Cognos 8.x consolidó la arquitectura y brindó muchísima integración. Aunque le costó incluir Cognos Planning de forma eficiente con las demás aplicaciones. Esta nueva versión venía a tratar de eliminar a sus competidores. Y Cognos creó un atractivo plan de incentivación a sus clientes para que migraran a la nueva versión.

Microsoft también hizo su movida. Con la aparición de SQL Server 2005 se dio un paso gingatesco. Ya SQL Server era de verdad. Entre los principales y excelentes cambios se encuentran:

  • Sustitución de los anticuados DTS con el moderno y multifuncional Integration Services
  • Mejoras en Analysis Services, incluyendo más funcionalidad e integración con el proceso ETL
  • Primer intento de contar con una herramienta de reporteo, Reporting Services. Buen ensayo, pero aún inmaduro.
  • Además, múltiples mejoras al motor de bases de datos: eficiencia, nuevo esquema de seguridad, administración, etc.

Y ¿qué significa para un cliente contar con una licencia de SQL Server? Tener una suite de Business Intelligece a su disposición sin necesidad de incurrir en gastos adicionales de licenciamiento.  Y si a esto se le suma que la mayoría de las organizaciones ya cuentan con un SQL Server para algún sistema, era nada más cuestión de tiempo para que se diera el siguiente paso.

En el otro lado de la acera, Cognos tiene una interfaz muchísimo más amigable para el dearrollador de reportes o el consumidor de cubos. Report Studio es por mucho, la mejor herramienta para la creación de todo tipo de reportes. Permite consumir fuentes OLAP o relacionales. Y los reportes pueden tomar infinidad de formas. Todo, diseñado, implementado y ejecutado desde Internet Explorer (no es compatible con otros navegadores).

Pero tener este lujo de herramienta es caro. Implica un alto costo de licencias y un 25% de soporte pagados por adelantados cada año. No muchas organizaciones en estos tiempos de austeros están dispuestas a pagar el precio.

En conclusión, si se hace un comparativo byte-to-byte, Cognos será el ganador indiscutible, pero si se suma el factor monetario, es probable que Microsoft no tenga competidor (al menos entre estos dos contendientes).

Un escenario recomendado: Microsoft SQL Server 2005 ó 2008 como base de datos y como herramienta de extracción, transformación y carga (ETL). Para el consumo de información, elaboración de reportes, indicadores o planeación, Cognos.

En los próximos posts se estarán abordando temás más específicos. Por lo pronto dar la bienvenida nuestros lectores e invitarlos a formar parte del blog realizando sus comentarios y aportando de su experiencia.