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.

Anuncios

Cuando se desarrolla un proyecto para el apoyo a la toma de decisiones gerenciales, uno de los riesgos más grandes es llegar a los altos mandos con datos incorrectos. Esto podría deberse a errores en la lógica de negocio, datos desactualizados o cualquier otra omisión durante la implementación. De más está decir que la credibildiad de todo el equipo se verá seriamente comprometida si el CEO no ve los números que acostumbra ver.

No obstante, hay ocasiones en la que esta situación está fuera del control del grupo que realiza la implementación. Esto es, cuando la calidad de los datos de los sistemas fuentes no es adecuada o fiable. También puede ocasionarse cuando a los niveles ejecutivos se les genera la información de forma manual, la cual está propensa a manipulación.

Podría decirse que la probabilidad de materialización de este riesgo es directamente proporcional al tamaño de la organización o cliente. Mientras más compleja, más áreas de negocio, más historia, más usuarios, más procesos, más complejidad, más probable será que los datos transaccionales no sean coherentes.

Más grave aún cuando el cliente/organización no es consciente de de la problemática, o esta dolencia no es claramente identificada en los altos mandos y solo queda en los mandos medios u operativos.

¿Qué hacer?

La única técnica con efectos positivos para la mayoría de los casos parece ser la reactiva. Aunque se tenga la intención de mitigar el riesgo, normalmente es complejo que el negocio desatienda sus actividades principales (las que generan el dinero), para proceder a tomar las acciones necesarias para realizar las correcciones de forma preventiva.

La consecuencia suele ser que el proyecto de BI dejará en total evidencia los problemas de calidad de datos. Hasta entonces, los altos mandos contarán con una prueba contundente de la problemática.

Eso sí, para el caso anterior, se asume que se pudo realizar el desarrollo y entregar al menos una parte del proyecto. En caso contrario, será necesario tomar acciones correctivas de forma anticipada, concientizando a quienes tienen el poder de decisión en las etapas previas del desarrollo. ¿Fácil? No. Pero imprescindible si se quiere el éxito del proyecto.

Tendencias Actuales

Desde hace unos años se escucha en el mercado tendencias que buscan minimizar los problemas de la calidad de datos. Pero pareciera ser que no todas las organizaciones ven una oportunidad de mejora en este aspecto. Por ejemplo, ¿cuántas empresas están desarrollando, o tienen planeado desarrollar durante los próximos 12 meses, una iniciativa tipo MDM?

Peor aún, ¿qué es MDM?

MDM, o Master Data Management, es una tecnología que permite centralizar el mantenimiento o definición de entidades propias de negocio a través de todos los actores y sistemas involucrados, tanto de lectura como escritura.

Por ejemplo, en la mayoría de las empresas existe un catálogo de clientes. ¿Está usted seguro de que tiene un registro único de cada uno de sus clientes? ¿Están completos los datos? Si desea realizar una campaña vía email, correo tradicional o telefónica, ¿cuenta con las direcciones respectivas?

En conclusión, estos son ejemplos de proyectos que solo pueden ser ejecutados en empresas con cierta madurez en cuanto al manejo de la información. Hacer BI puede ser un gran paso para el apoyo a la toma de decisiones y probablemente el detonante de proyectos y procedimientos de aseguramiento en la calidad del dato.

Ese famoso cuadrito le saca las canas a mucha gente. Ese cuadrito es uno de los termómetros que usan muchas de las organizaciones para decidir qué tecnología adoptar.

Por experiencia sé que las grandes organizaciones limitan sus ofertas de implementación solo a aquellas empresas que representan a productos que están posicionados como líderes en Gartner.

Este es el cuadrante mágico de Gartnet para business intelligence con corte a enero 2011.

Cuadrante mágico de Gartner para Business Intelligence Enero 2011

Magic Quadrant for Business Intelligence

Algunos de los cambios importantes, es el retroceso de SAS en cuanto al eje visionario. En cuanto a Cognos, que el año anterior presentó la versión 10 de su suite, está bajando en el eje vertical y le ha dado paso a Microsoft, que cada vez se posiciona mejor, y a Oracle.

Otro que pareciera que está ganando mucho terreno es SAP gracias a la adquisición de Business Objects.

Al fin de cuentas, esta imagen es sumamente subjetiva. Cada proveedor se encarga de mostrar en su presentación una visión ligeramente de Gartner que milagrosamente les da una ventaja competitiva.

Al fin de cuentas, lo importante es que el área de BI cuenta con variadas e importantes opciones para realizar las implementaciones. Lo interesantes ya no es si el cubo hace algo bien o mal, o si es más fácil y difícil. La tendencia ahora va más orientada al valor agregado y posicionamiento en la nube.

Y en su organización, ¿qué prefiere?

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.

Cada vez que un analista pretende realizar el estudio del comportamiento del negocio, es inherente encontrar que más de una perspectiva que contextualice los datos.

Esta situación es completamente normal, ya que son muchas las variables que afectan el entorno. Así se encuentra cliente, país, producto, tiempo, canal de distribución, cuenta contable, escenario, venta neta, impuesto, descuento, costo, y un infinito etcétera que es imposible enumerar acá.

De ahí surge el concepto de análisis multidimensional. El cual será definido como la capacidad de contextualizar una variable o más variables (medidas) a través del empleo de perspectivas (dimensiones). Las medidas generalmente serán numéricas y las dimensiones generalmente serán alfanuméricas. Sin embargo, pueden presentarse excepciones a esta regla.

En un mercado tan competitivo como el que enfrentas las organizaciones actuales, la información se ha convertido en el activo más importante. No solo como secreto comercial, sino como indicador clave para tomar las deciones adecuadas en los momentos oportunos. La época en que era necesario esperar el cierre contable a fin de periodo del ejecutivo reactivo ha quedado atrás.

De ahí que, las compañías exitosas, grandes o pequeñas, apoyan sus decisiones en información fundamentada en los datos que sus sistemas transaccionales generan día con día. No tiene que ser un empresa de ingresos anuales multimillonarios. El BI hoy día es una forma sencilla de democratizar la toma de decisiones en todos los niveles de la cadena de mando.

OLTP

Desde hace ya más de 20 años se ha difundido la automatización de actividades. Desde lo más simple hasta lo más complejo. Es cada vez más y más común encontrar procesos automáticos con la finalidad aumentar la productividad y mejorar el servicio. Estos sistemas son excelentes para resolver el día a día. Están optimizados para responder a miles de consultas por segundo. La concurrencia en actividades de lectura y escritura son la regla. Estos son los entornos que se denominan OLTP, del inglés Online Transaction Processing.

Sin embargo, estos ambientes ver frustrados sus inteciones cuando se enfrentan a una situación inevitable: reporteo y apoyo a la toma de decisiones. Si se le suma a ello la heterogeneidad de aplicaciones, genera un escenario mucho más complejo.

Por ejemplo, en cualquier organización es común encontrar los siguientes niveles:

  • Nivel Operacional: estos utilizan sistemas informatizados para monitorear las actividades y transacciones elementales de la organización.
  • Nivel de Conocimientos: este es el primer nivel de análisis. Es común encontrar a trabajadores especializados en funciones o áreas específicas de la corporación. Realizan captura masiva de datos y los tratan a través de tareas específicas.
  • Nivel de Administración: este nivel toma los datos del nivel de conocimiento, da seguimiento, control y toma decisiones.
  • Nivel Estratégico: tiene como objetivo realizar las actividades de planificación de largo plazo.

OLTP está diseñado para que el nivel operativo cumpla a cabalidad sus funciones. Con un poco de trabajo es posible que el nivel de conocimiento pueda realizar análisis con base en la información obtenida. Sin embargo, no permite al nivel de administración y estratégico tomar las decisiones en los tiempo de respuesta que es necesario brindar hoy.

OLAP

Derivado del témino inglés Online Analytical Processing es un enfoque que viene a complementar a OLTP y ofrecer las herramientas que los niveles de conocimiento, administración y estrategia requieren.

El paso desde modelos OLTP a OLAP se presenta diferente en cada situación. La clave del éxito es presentar a los niveles superiores la información en términos de negocio, no técnicos.

Por ejemplo, en los sistemas transaccionales (OLTP), la información de los productos se almacena en diferentes tablas. Esto mejora el rendimiento en los sistemas operativos. Sin embargo, a nivel de tomadores de decisiones, es indiferente si la información está en una o veinte tablas. Es más, no interesa si la información está en tablas o archivos o en la web. El tomador de decisiones ve el negocio en términos de entidades, así que la información que se manipula debe respetar esos criterios.

Es así como a través de procesos ETL (del inglés Extraction, Transformation & Load), se realizan con una frecuencia establecida los procesos de carga de datos desde cada origen disponible (sistemas transaccionales, hojas de cálculo, internet, aliados de negocio, etc), se procesa, estandariza y se generan las entidades de negocio que serán las perspectivas (dimensiones) o variables cuantitativas (medidas).

En el próximo módulo del curso, “Diseño OLAP” se profundizarán los aspectos mencionados y se introducirá el concepto de datawarehouse.

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

Con ese lema, el próximo 21 de abril, Microsoft realizará un evento virtual de lanzamiento de muchas de sus principales herramientas, tales como Microsoft Office 2010, Microsoft SQL Server 2008 R2, Microsoft SQL Server Azure, Microsoft SharePoint Server 2010, Microsoft Visual Studio 2010, entre otros.

Con estas nuevas versiones, se espera seguir el proceso de democratización del acceso a la la información de forma sistematizada, business Intelligence, mejorando así los procesos y siendo más efectivos. Antes, BI era un lujo que solo se daban los altos ejecutivos de las organizaciones, en gran medida debido a su alto costo de licenciamiento.

Sin embargo, con la combinación entre SQL Server y Office 2010, ahora más que nunca, se puede permitir que tantos los niveles estratégicos, tácticos y operativos de las organizaciones cuenten con herramientas que apoyen sus decisiciones día a día.

Posteriormente se comentarán los resultados de estas nuevas versiones.