Existen varias tendencias tecnológica que van ganando fuerza (y tomando forma) a gran velocidad... Me refiero a aspectos como la virtualización, la tecnología in-memory y muy especialmente el "cloud computing"... Es curioso que algunas de estas tendencias son contradictorias entre sí, ¿No es la tecnología "in-memory" lo contrario al "cloud computing"? Bueno, no exactamente, y creo que pueden coexistir. La cuestión es determinar que aspectos son más fáciles de administrar desde la "nube", y cuales se gestionan mejor localmente.

El "cloud computing", en realidad, no es ninguna idea nueva. Hace años que con distintos nombres nos estamos refiriendo a prácticamente lo mismo. Hace 15 años ya se hablaba de los "Application Service Provider" (ASP), luego se popularizó el concepto "On Demand", posteriormente oí la expresión "Software as a Service" (SaaS). Tal vez existan pequeños matices entre estos conceptos (o tal vez no, o tal vez no tan pequeños), pero fundamentalmente son equivalentes: Consiste en hospedar las aplicaciones fuera de nuestra organización (en internet, en la "nube"), y pagar por el mantenimiento y el uso de esta plataforma externa.

En otras ocasiones, he hablado de las ventajas del modelo SaaS, hoy quiero comentar las objeciones típicas de este modelo. En este artículo de Adysa Group ya mencionan tres de las objeciones típicas...

• Geolocalización: ¿dónde están mis datos?
• Seguridad: ¿Cómo sé que mis datos van a estar seguros?
• Pago recurrente: ¿Por qué tengo que pagar todos los años por algo que ya tengo?

...y el mismo artículo responde muy bien a estas tres objeciones. Recomiendo su lectura. Básicamente, dice que no debería importarnos donde están los datos, lo importante es que están guardados por una empresa especializada precisamente en eso, y que de eso depende su negocio. Cuando se analiza el modelo desde un punto de vista económico, también resulta más barato que el modelo tradicional, que tiene muchos costes ocultos (o no tan ocultos)...

Esas tres objeciones, sin embargo, son sólo las que haría un gestor de negocio, desde el punto de vista técnico también pueden hacerse objeciones adicionales:

• Tiempos de respuesta. ¿La aplicación en la nube irá tan rápida como si la hospedo localmente?
• Amigabilidad del entorno. ¿Una aplicación web tendrá un entorno tan rico y amigable como una aplicación de escritorio?
• Carga de datos. En una aplicación Business Intelligence, ¿Quién, cómo y cuando carga los datos en la nube?¿Cómo de grande puede ser un datamart en la nube?

De hecho, las aplicaciones web no son especialmente rápidas, y si se trata de aplicaciones potentes y complejas (como las que necesita un usuario de Business Intelligence) pueden llegar a ser desesperadamente lentas. No se trata, por lo tanto, de un problema del modelo SaaS, sino de la tecnología web. Contratando el ancho de banda adecuado, y con un proveedor SaaS competente, los tiempos de respuestas pueden y deben ser suficientes. Como en el caso de la seguridad, el negocio de un proveedor SaaS depende fuertemente de este punto.

La amigabilidad del entorno tampoco es una limitación del modelo SaaS, y vuelve a ser una característica de los estándares web actuales. Una aplicación web nunca jamás será tan rica y amigable como una aplicación de escritorio. (Aclaración: cuando digo "nunca jamás será" quiero decir que "nunca jamás ha sido", que yo el futuro lo desconozco).

La tercera de las objeciones técnicas es, para mí, la más difícil de replicar, y tal vez explique porque el Business Intelligence SaaS se haya desarrollado más tarde y más lentamente que otro tipo de aplicaciones SaaS. ¿Tiene sentido poner un DWH de varios Teras en la nube? Probablemente, no. ¿Es complicado cargar un DM de varias decenas de Gigas? Probablemente, tan complicado o tan sencillo como cargarlo en un servidor interno.

Mi conclusión es que el Business Intelligence SaaS tiene su mercado. Especialmente en la PYME. Y que crecerá. Que las ventajas que ofrece son muy buenas y hay que tenerlas en cuenta. Y prueba de ello es que ya existen proveedores especializados en este modelo de negocio (tipo Litebi o GoodData), y que los proveedores de Business Intelligence tienen o están desarrollando soluciones SaaS dentro de su catálogo de productos (como Microstrategy, Business Objects o Bingo Intelligence).

Un poco de humor para finalizar... Os dejo una viñeta de Geek & Poke sobre lo que no soluciona la nube... :-)

Gartner ofrece regularmente dos estudios que resultan especialmente interesantes para los profesionales del Business Intelligence. Me refiero, naturalmente, al cuadrante sobre las plataformas Business Intelligence y al cuadrante sobre los sistemas datawarehouses.

Ayer mencionaba el cuadrante mágico para plataformas Business Intelligence, y hoy comparto con vosotros el segundo estudio. Aquí lo tenéis:

• Magic Quadrant for Data Warehouse Database Management Systems (2010)

Las diferencias respecto el cuadrante análogo del 2008 son mínmas. Teradata lidera claramente el mercado DWH, y le siguen los pasos Oracle, IBM y Microsoft... Este año, además, aparecen muchos nuevos competidores, pequeños y poco conocidos en España, y sobre los cuales deberemos estar alerta...

Aunque el gráfico ha cambiado poco, el mercado está evolucionando rápidamente. De esta manera, se popularizan las "appliances" (combinaciones de software y hardware preconfigurados y listos para usar), y se va extendiendo el uso que se hace de los datawarehouses actuales. Ya no son sólo repositorios donde se almacena la información para hacer informes, sino que se aprovecha la arquitectura para otras muchas funcionalidades (BI operacional, performance management, planning, monitorización del negocio [BAM], etc.). Es decir, poco a poco vamos activando nuestros DWH, y vamos reduciendo la distancia entre el dato y la acción... El DWH ofrece un soporte activo a la toma de deciciones (decisiones de todo tipo, y a todos los niveles de la organización). A esta evolución algunos la han denominado como "active datawarehousing", "BI pervasivo", o simplemente "Business Intelligence activo"...

Técnicamente, también se están popularizando cuestiones como la carga contínua de información, el acceso por columnas, el paralelismo hardware y el paralelismo masivo, la "temperatura" de la información... y pronto hablaremos de unidades en estado sólido (SSD)... y todo ello en busca de mayor rendimiento a un menor coste...

Otro aspecto interesante que menciona el estudio es el resurgimiento de los datamarts. A pesar del protagonismo que está adquiriendo el datawarehouse corporativo, los "datamarts" siguen existiendo y siguen teniendo su utilidad. El "datamart" es la manera más sencilla y rápida para obtener un buen rendimiento (sin comprometer otros sistemas corporativos), por lo que resulta adecuado en aplicaciones analíticas independientes (por ejemplo, para sistemas de cuadros de mando...).

Desde hace unos pocos años, se oye hablar de una serie de ideas o metodologías que mucha gente piensa que son el futuro inmediato del Business Intelligence. Al principio, era sólo un rumor que surgía de algún proveedor en particular, pero con el paso de los meses la tendencia se ha ido generalizando y ya aparece en los mensajes comerciales de los principales proveedores de Business Intelligence.

En concreto, me estoy refiriendo a:

• Análisis predictivo.
• Análisis en tiempo real.
• Análisis en memoria.

En BI-Spain han publicado un artículo de Information Week que describe estas tres funcionalidades y explica como distintas empresas lo han aprovechado para su negocio. Es un artículo interesante para conocer las tendencias en el Business Intelligence.

Veamos en que consisten...

Análisis predictivo

En efecto, el "análisis predictivo" viene a ser una realización práctica del data mining. Aunque la minería de datos siempre ha bordeado los limites del BI (y no sé si bordeaban por dentro o por fuera), pocas implantaciones reales se han hecho en España, y siempre con proveedores con un fuerte enfoque matemático-estadístico (SPSS, SAS). La situación ha cambiado significativamente en los últimos años... por los siguientes motivos:

• La empresas ya tienen experiencia en soluciones BI, quien más quien menos, ya tiene un datawarehouse, y varias herramientas Business Intelligence. Ahora, se conoce el poder de la información, y nos atrevemos a iniciar proyectos de previsión de la demanda, de análisis de riesgo, etc.
• Consolidación del mercado. SPSS ha sido adquirida por IBM, Information Builders ha integrado R-Stats en Web Focus, y el resto de jugadores han comprado una o varias soluciones de planificación. Todos tienen, por lo tanto, interés en la integración de estas soluciones en sus plataformas BI.

Análisis en tiempo real

El datawarehouse ya no es sólo un destino de información, sino que es una fuente de decisiones y nuevos datos son extraídos del DWH y gestionados por el ERP corporativo.

Para ser eficaces, ya no es suficiente con cargar el DWH una vez al día, ni detectar una incidencia en el stock unas horas después de que ocurra. Desde el DWH se generan alertas que afectan directamente al negocio, y estas alertas se deben activar automáticamente y con los datos completamente actualizados.

Análisis en memoria

La ley de Moore se sigue cumpliendo. Cada pocos meses tenemos unos ordenadores más rápidos, con más memoria RAM, y con más disco duro. Actualmente, es posible tener un datamart completo (o un pequeño datawarehouse) en la memoria RAM de un servidor, o incluso en la memoria del ordenador del usuario. Varios proveedores (TM1, QlickView, Spotfire) aprovecharon esta circunstancia para crear soluciones analíticas que dejaban en evidencia arquitecturas mucho mayores (e infinitamente más caras). Con datos precalculados en memoria, ya no debemos esperar 1 minuto, ni siquiera unos pocos segundos, para obtener el resultado. Ahora, el resultado puede ser instantáneo. Microstrategy ha sido el primero de los grandes en añadir este tipo de soluciones a su catálogo, pero los demás irán detrás...

Pues bien, estas son las tendencias... Sin embargo, son sólo eso: tendencias. Y creo que aún deberemos esperar bastante tiempo para que se generalice su uso. De hecho, en el mismo artículo aparece un ránking de las cosas más importantes en un software de Business Intelligence, y el podium lo encabezan las tres cosas que siempre menciono en este blog:

• Facilidad de uso para cualquier usuario
• Facilidad de implantación
• Capacidades analíticas (tiempos de respuesta, dinamismo...)

Las tendencias que mencionaba anteriormente, sin embargo, aparecen en la segunda mitad de este ránking:

Y por eso creo que en el futuro inmediato debemos esperar una combinación de ambos aspectos... Las herramientas deben ser más sencillas y más dinámicas, y deben incorporar nuevas capacidades predictivas....

Camino del segundo año de este blog, ya llevo 70 artículos sobre Business Intelligence. Si no he contado mal, este será el artículo número 71, por lo que ya es momento de clasificar adecuadamente todos estos artículos.

Repasando las diferentes entradas, he visto que en mis reflexiones (o lo que sea) han ido apareciendo unos temas recurrentes. En este tiempo, he hablado sobre la usabilidad en las herramientas BI (el nombre del blog ya apuntaba esa dirección: ¡yo quiero un Business Intelligence fácil), he hablado bastante sobre el Excel, e incluso he hablado sobre productos BI de verdad y sobre el mercado en general... No me olvido de la serie sobre cómo construir un datawarehouse (que tantas visitas me ha traído), ni de otros artículos donde trato de explicar de qué va esto del Business Intelligence... Y alguna cosilla más.

Al final, me ha quedado un "decálogo"...

• Sobre el blog
• Definiciones Business Intelligence
• Excel vs BI
• Mercado BI
• Productos BI
• Usabilidad BI
• Serie DWH
• OSBI
• Humor
• Varios

Ahora, después de cada artículo encontraréis un listado de artículos relacionados (de la misma categoría), para que podáis seguir leyendo si os ha interesado. Y si no os ha resultado interesante, tal vez podéis probar con los artículos del resto de categorías :-)

De esta manera, espero que la navegación por el blog sea más sencilla.

La entrada de hoy es un poco especial. Tengo el placer de anunciar que el blog ha cambiado de dirección, y que probablemente dentro de unos días cambiará también de estrucutra y/o formato. Estad atentos :-)

La nueva dirección creo que es más fácil de recordar y representa mejor lo que este blog quiere ser... Un blog de Business Intelligence para seres humanos...

http://www.businessintelligence.info/

Por otra parte, el contenido del blog seguirá siendo el de siempre. En este blog encontrarás mis impresiones personales sobre el mundo Business Intelligence y las tecnologías y las no-tecnologías que giran a su alrededor: DWH, OLAP, informes dinámicos, cuadros de mando, software BI, tendencias BI, etc.

Con este blog quiero obligarme a mi mismo a estar al día de lo que ocurre en el mundo BI, y estaría encantado de que fuese un punto donde cualquier interesado en el BI pueda también mantenerse informado.

Recuerda: BUSINESS INTELLIGENCE (punto) INFO

Como siempre, intentaré no aburriros demasiado :-)

Un saludo,

BI fácil

En la definición de datawarehouse de Bill Inmon (y en todas las definiciones posteriores de cualquier menda aficionado al BI, como el autor de este blog de Business Intelligence en español) se señala que un DWH es un repositorio donde la información corporativa se encuentra "integrada".

A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of managements decision making process (Bill Inmon, 1990)

Efectivamente, cualquier empresa tiene múltiples sistemas operacionales, cada uno de ellos con sus propios maestros y su propia información. Uno de los objetivos del DWH es unificar toda esa información dispersa en un único repositorio. Sin embargo, no se trata sólo de juntar todos estos datos, el objetivo es unificarlos, integrarlos y conformarlos, es decir, dar la misma forma y el mismo significado a dimensiones y hechos aparentemente distintos (en inglés dicen "conform information").

Por ejemplo, una empresa de distribución puede tener dos canales de ventas a través de los cuales vende los mismos productos (venta al mayor y venta retail). Habitualmente, la gestión de estos dos negocios la realizarán personas diferentes de diferentes departamentos, y cada uno de ellos tendrá sus sistemas informáticos con diferencias significativas entre ellos. Es muy diferente el negocio minorista del negocio mayorista.

Pues bien, en este ejemplo, uno de los retos de la creación del DWH sería la unificación de estos dos negocios, porque sin duda existirán usuarios que querrán conocer la "facturación", y la facturación evidentemente incluye las ventas al mayor y al ventas retail. Para realizar esta unificación, las dos tablas de hechos deberán compartir las mismas dimensiones, y deberán definirse con precisión los términos de cada negocio para que resulten agregables entre sí… Incluso, podría ser recomendable unificar los dos hechos en una misma tabla de hechos, donde la dimensión "tipo de venta" permitiese diferenciar las ventas al mayor de las ventas retail.

A esta unificación se refiere el penúltimo error de esta serie sobre cómo construir un datawarehouse:

Error 2: No unificar los hechos entre distintas tablas de hechos

Tal como comentaba, independientemente de que los hechos se modelicen en una o varias tablas de hechos, estos deben tener la misma forma. Deben tener dimensiones compartidas que permitan la comparación y/o agregación entre sí. Si se quiere sumar o dividir la información de distintos hechos, estos deben tener la misma forma y deben haberse cargado aplicando los mismos criterios.

Otro ejemplo de "conformar" adecuadamente los hechos sería aplicar los mismos criterios al cargar las compras y las ventas. Si se quiere calcular el cociente de ventas sobre compras, deberemos asegurarnos que en los dos indicadores se están considerando los mismos productos. No debemos, por ejemplo, olvidarnos de aquellos productos que sólo se venden por Internet o que forman parte de un negocio secundario de la compañía. Si estos productos se incluyen en las ventas, deben incluirse también en las compras (aunque provengan de fuentes distintas).

En la anterior entrada de esta serie sobre cómo construir un datawarehouse se describía la importancia de unificar los hechos. Ahora hablaremos de unificar las dimensiones. No es más importante una cosa que la otra. Las dos son imprescindibles.

Sabemos que es normal que dentro de una compañía convivan muchas aplicaciones informáticas, cada una de ellas con sus propios maestros. Una función importante del DWH es la unificación de estas aplicaciones en unos maestros únicos.

Por ejemplo, la aplicación de recursos humanos puede utilizar los códigos "M" y "F" para indicar el sexo de los empleados, mientras que la aplicación de CRM puede estar utilizando los códigos "H" y "M". Es sólo un ejemplo tonto, pero es la realidad de todas las empresas. Incluso puede haber diferencias entre los códigos de las tiendas y productos que utilizan las distintas aplicaciones o módulos del ERP.

En el DWH, evidentemente, debe existir un solo maestro de género. Y un solo maestro de tiendas. Y un solo maestro de productos. Y un solo maestro de cualquier cosa. En el proceso de carga del datawarehouse, deben identificarse los códigos equivalentes, y asignarles una única clave subrogada.

Un caso especial, y muy problemático, es el maestro de clientes. Se puede captar información de los clientes a partir de un formulario en la página web, o un carnet de afiliación que solicita el cliente en la tienda, o una llamada al departamento de reclamaciones… Es importante identificar las personas entre distintos aplicativos. Ni el nombre y los apellidos del cliente, ni el email, ni la dirección, ni siquiera el DNI son métodos fiables para detectar una misma persona en diferentes aplicaciones. Para identificar adecuadamente un cliente debe utilizarse una combinación de todos los anteriores e incluso puede ser necesaria la intervención manual. Existen herramientas y compañías especializadas en esta tarea, y no suele considerarse una responsabilidad del modelizador del DWH. Normalmente, para realizar una identificación fiable resulta necesario modificar las aplicaciones orígen, para realizar el "matching" cuanto antes.

En todos los demás casos, el equipo del DWH debe estar obsesionado por entender y unificar todos los maestros de la compañía.

El primer error, el más grave según Raplh Kimbal, se refiere precisamente a este aspecto de la modelización:

Error 1: No compartir dimensiones entre diferentes tablas de hechos.

Efectivamente, por falta de tiempo y recursos, se pueden cargar los diferentes maestros tal cual llegan de los distintos operacionales. Es un error muy grave. Las dimensiones compartidas entre diferentes hechos permiten navegar por la información, o cruzar información de distintos orígenes.

Si se realiza correctamente, daremos mucha potencia y funcionalidad a los usuarios de negocio, el mantenimiento del sistema será más sencillo, y podrá añadirse nueva información al sistema Business Intelligence de manera paulatina y harmoniosa.

Si no se realiza correctamente, el datawarehouse perderá mucha de su utilidad y sentido.

Finalmente, he terminado de recorrer la lista de Ralph Kimball sobre cómo no construir un datawarehouse. A lo largo de estos artículos he intentado introducir los conceptos más importantes relativos a la modelización de un datawarehouse (base de cualquier entorno Business Intelligence).

Para finalizar esta serie, incluyo el índice de todas las entradas:

• Introducción: Cómo no construir un datawarehouse
• Artículo 1: Datawarehouse
• Artículo 2: Dimensiones
• Artículo 3: Jerarquías
• Artículo 4: Dimensiones lentamente cambiantes
• Artículo 5: Claves subrogadas
• Artículo 6: Tablas de hecho
• Artículo 7: DWH organizado por temas
• Artículo 8: Tablas agregadas
• Artículo 9: Máximo nivel de detalle
• Artículo 10: Rendimiento
• Artículo 11: Unificar los hechos
• Artículo 12: Unificar las dimensiones

Cada artículo, analiza uno de los 12 errores que justificaron esta serie:

• Mistake 12: Place text attributes in a fact table if you mean to use them as the basis of constraining and grouping.
• Mistake 11: Limit the use of verbose descriptive attributes in dimensions to save space.
• Mistake 10: Split hierarchies and hierarchy levels into multiple dimensions.
• Mistake 9: Delay dealing with a slowly changing dimension (SCD).
• Mistake 8: Use smart keys to join a dimension table to a fact table.
• Mistake 7: Add dimensions to a fact table before declaring its grain.
• Mistake 6: Declare that a dimensional model is "based on a specific report."
• Mistake 5: Mix facts of differing grain in the same fact table.
• Mistake 4: Leave lowest-level atomic data in E/R format.
• Mistake 3: Eschew aggregate fact tables and shrunken dimension tables when faced with query performance concerns
• Mistake 2: Fail to conform facts across separate fact tables.
• Mistake 1: Fail to conform dimensions across separate fact tables.

Y que traduje de esta manera...

• Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
• Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
• Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
• Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
• Error 8: Crear "smart keys" para relacionar una tabla de dimension con una tabla de hechos.
• Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
• Error 6: Crear un modelo dimensional para resolver un informe en particular.
• Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
• Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
• Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
• Error 2: No unificar los hechos entre distintas tablas de hechos
• Error 1: No compartir dimensiones entre diferentes tablas de hechos.

Aunque existen varias opiniones al respecto, yo soy de los que cree firmemente que en el DWH debe estar disponible el máximo nivel de detalle de la información. Se debe guardar cada ticket, cada venta, cada transacción.

Si se dispone la información detallada, cualquier consulta posterior podrá resolverse en cualquier de las agrupaciones disponibles. Tal vez, de entrada, puede parecer suficiente ver las ventas diarias de cada familia, sí, ¿Pero y si luego quiero verlo por grupo social? ¿O por hora de venta? ¿O si lo quiero segmentar por precio de venta? ¿O por tipo de subfamilia? Sólo si inicialmente se diseñó y cargó el datawarehouse con la información detallada podrán contestarse estas preguntas.

En general, dentro del DWH se distinguen tres áreas principales:

• Área de staging: Que contiene las información bruta extraída de los sistemas operacionales. Es un área temporal donde los datos se preparan y normalizan antes de cargarse definitivamente en el DWH.
• Modelo relacional: Es una base de datos donde la información se encuentra normalizada. Contiene todo el detalle de información. Y toda la historia posible. No hay tablas agregadas. En este punto la información ya está limpia e integrada, y ya se han creado las claves subrogadas. Es preferible un modelo en "copo de nieve" o incluso normalizado totalmente.
• Modelo dimensional: Es la base de datos que utilizan las herramientas de Business Intelligence para obtener la información y hacer los informes o análisis. El modelo dimensional está optimizado para conseguir un buen rendimiento. Existen tablas agregadas. Se prefiere el modelo en estrella. Y, en mi opinión, también debe tener todo o casi todo el detalle de información.

Soy consciente que el máximo nivel de detalle implica cargar muchos datos, y hacerlo por triplicado, lo que requiere tiempo de carga y espacio en disco. Ya. Conozco las desventajas. Y debemos asumirlas si queremos un datawarehouse que se útil para las necesidades actuales y para las necesidades futuras.

El error 4 de esta serie sobre cómo construir un datawarehouse trata este asunto:

Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.

Efectivamente, el máximo detalle no lo debemos dejar ni en el operacional, ni en la staging, ni en el modelo relacional. Todo el detalle debe propagarse hasta el modelo dimensional. Sólo de esta manera el sistema Business Intelligence superará el ataque de las consultas ad-hoc.

Habitualmente, esta manera de trabajar sólo la cuestionan los consultores que han intervenido en excesivos proyectos de cuadro de mando. Es habitual que las empresas soliciten un cuadro de mando sin tener antes un datawarehouse ni un sistema de reporting aceptable. En estos casos, cargar todo el detalle puede parecer difícil de justificar. ¿Cómo voy a proponer un DWH de 500Gb si el gerente sólo quiere 4 pantallitas para hacer el seguimiento mensual de un puñado de indicadores? En mi opinión, hay que proponerlo. Sólo disponiendo de un buen DWH podrá asegurarse la continuidad del proyecto BI.

Recuerda: Por lo menos carga el máximo nivel de detalle en el modelo relacional, y podrás mostrarlo cuando te des cuenta de que también lo necesitas en el modelo dimensional.

Otra de las características importantes que debe tener un DWH es estar "organizado por temas" (subject-oriented). Bill Inmon es considerado uno de los padres del concepto DWH, y fue el quien introdujo esta característica en su definición:

"A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of managements decision making process" (Bill Inmon, 1990)

La organización temática de la información se refiere a que los datos que están cargados incluyen los indicadores relevantes de diferentes áreas de información de la compañía. Además, deben poder cruzarse los indicadores relativos al mismo objeto o evento del mundo real.

Esta organización temática de la información facilita posteriormente la construcción de informes ad-hoc, ya que permite obtener y cruzar información que se generó en procesos de negocio muy diferentes (aunque de una misma temática). Observad que esta manera de organizar la información es muy distinta de la existente en un sistema OLTP tradicional, donde la información está organizada por transacciones y procesos.

Modelizar adecuadamente la estructura del sistema Business Intelligence es fundamental para que posteriormente el usuario puede generarse cualquier informe que necesite. En particular, es un error grave y frecuente el error número 6 de esta serie sobre cómo construir un datawarehouse

Error 6: Crear un modelo dimensional para resolver un informe en particular.

Efectivamente, el modelo dimensional debe ser independiente de cualquier informe en particular. Una de las razones que habitualmente justifica la creación de un sistema Business Intelligece es la necesidad de otorgar a los usuarios la capacidad de realizar informes ad-hoc. No tendría sentido, por lo tanto, que el equipo de IT tuviese que adaptar el datawarehouse para cada informe necesario.

Al iniciar un proyecto de datawarehouse, muchas veces he visto cómo se gastan demasiados esfuerzos en definir los informes que se necesitan, y se hacen interminables reuniones con los usuarios de negocio con este objetivo. Es un error que puede costar muy caro. Me explico: Esas reuniones son necesarias, pero el objetivo debería ser entender los indicadores y los conceptos con los que trabajan los usuarios de negocio, y no conocer particularidades intrascendentes de informes determinados.

En particular, si se trabaja con consultores externos, conviene evitar que la aceptación del proyecto esté vinculada a la realización de unos informes en particular. Si esos son los términos de tu contrato, existe el riesgo de que los esfuerzos se focalicen en la construcción de esos informes, cuando lo correcto sería modelizar el DWH de tal forma que fuese viable consturir cualquier informe.

No digas que no te lo advertí :-)

En la anterior entrega de esta serie sobre cómo construir un datawarehouse ya introducía el concepto de las “claves subrogadas”.

Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio. Son siempre de tipo numérico. Preferiblemente, un entero autoincremental.

Habitualmente, el sistema operacional ya utiliza sus propias claves, aunque suelen ser de tipo carácter y tienen un sentido específico para los empleados de la compañía. Por ejemplo, el código BCN puede utilizarse para referirse a Barcelona, o el DNI de cada empleado puede ser la clave única de la tabla de empleados. O el código de barras para referirse a un producto. ¿Por qué necesitamos, entonces, crear unos nuevos identificadores en el sistema Business Intelligence? Por varios motivos:

• Fuentes heterogéneas. El DWH suele alimentarse de diferentes fuentes, cada una de ellas con sus propias claves, por lo que es arriesgado asumir un código de alguna aplicación en particular. ¿Qué ocurriría si en el futuro se añade información de una aplicación que tiene su propio maestro de ciudades? Seguro que nos generará un problema, aparecerán ciudades que no existían en nuestro maestro…¿Cómo lo gestionaríamos? No sé. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
• Cambios en las aplicaciones origen. Puede ocurrir que cambie la lógica operacional de alguna clave que hubiésemos supuesto única, o que siempre debería estar informada. ¿Qué pasará cuando llegue un empleado sin DNI? ¿Qué pasará cuando se de de alta una ciudad extranjera con el código BCN? Prefiero no saberlo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
• Rendimiento. En la base de datos, ocupa menos espacio un entero que una cadena. Identificar una ciudad con 5 bytes, o una persona con 9 bytes es un desperdicio considerable de espacio. De hecho, no debe preocuparnos el espacio que ocupa, sino el tiempo que se pierde en leerlo… Recordad que las claves subrogadas las llevaremos a las tablas de hechos, por lo que cada código es susceptible de repetirse cientos de millones de veces. Conviene optimizarlo al máximo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.

Por supuesto, también se pueden cometer errores al generar una clave subrogada…

Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.

En ocasiones, nos puede parecer útil aprovechar la lógica que subyace a los elementos para generar nuestras propias claves. Por ejemplo, si queremos crear una jerarquía de ciudades, nunca debemos caer en la tentación de crear una simple concatenación (y generar el código ESP-CAT-BCN para referirnos a Barcelona)… También es un error crear una clave compuesta de varios campos. Aunque en el operacional la terna país-CCAA-ciudad sea única, en el DWH debemos crear una clave subrogada formada por un solo campo entero autoincremental.

Recuerda: Sustituye cualquier clave física por una clave entera numerada secuencialmente desde 1 hasta N.

En los anteriores comentarios de esta serie sobre cómo construir un datawarehouse, explicaba las características de las dimensiones y las jerarquías. Sin embargo, estaba omitiendo un aspecto principal de estas tablas.

La información de las dimensiones no es estática, ya que puede modificarse en el operacional por diferentes motivos. Por ejemplo, puede corregirse la fecha de nacimiento de un cliente, o éste puede cambiar de ciudad, o una delegación puede asignarse a un delegado diferente, etc. ¿Cómo debe gestionarse esta información?

En primer lugar, debe tenerse en cuenta que el tratamiento que se realizará dependerá de cada dimensión y de las necesidades del negocio. Por ejemplo, si se actualiza la fecha de nacimiento de un cliente se puede asumir que ese cambio aplica a toda la historia de ese cliente. Sin embargo, existen casos donde la información dimensional histórica es importante. Considera estas dos situaciones:

Previsión de ventas: Para realizar una previsión de ventas para el próximo año, deberemos considerar las ventas históricas de las tiendas que actualmente tiene asignado cada delegado.

Análisis de márgenes: Si queremos analizar los descuentos que aplica cada delegado, deberemos considerar las ventas de aquellas tiendas que han tenido asignadas a lo largo del tiempo.

Por lo tanto, en este ejemplo, deberemos modelizar la información de tal modo que seamos capaces de conocer el "delegado actual" y el "delegado/s histórico/s".

Para conseguir este objetivo se introducen las "claves subrogadas", que son identificadores sin ningún significado específico para el negocio. Aunque existen diferentes maneras de modelizar estos datos, lo habitual es trabajar con las "fechas de vigencia". Por ejemplo, esta sería la estructura de la tabla de DELEGACIONES en el modelo relacional:

Ampliar imagen

Analizando cuidadosamente los valores de esta tabla, puede observarse que Pedro era el responsable de las delegaciones de Madrid y Barcelona, y que sus funciones fueron asumidas posteriormente por Juan y María. En el modelo dimensional, la tabla podría modelizarse de este modo:

El sistema funcionaría de manera similar con cualquier otra dimensión que pudiese tener la jerarquía de delegaciones, o cualquier otra jerarquía. Evidentemente, se trata de un tema complejo y que debe considerarse, o caeríamos de lleno en el error número 9:

Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes

En cualquier definición del término datawarehouse se menciona que es un repositorio de información histórica, y con ello se pretende enfatizar que contiene:

• Historia de los hechos: En el operacional existe registro de los "hechos" del negocio de los últimos meses o de unos pocos años. Sin embargo, en el DWH se intenta que exista un histórico mucho mayor.
• Historia de las dimensiones: El operacional sólo suele guardar la situación actual de las dimensiones. En el DWH, sin embargo, debe mantenerse toda la evolución de los cambios dimensionales.

Pues bien, este segundo punto se suele olvidar (o ignorar) en algunas implantaciones de DWH por las siguientes razones:

• La "visión actual" parece suficiente. Al fin y al cabo, es lo que siempre se ha hecho en el sistema operacional.
• El usuario no siempre entiende la diferencia entre la "visión actual" y la "visión histórica". Y por lo tanto no sabe concretar sus necesidades reales.
• La gestión de cambios en las dimensiones nunca aparece en los requerimientos que motivaron el proyecto. De entrada, no parece importante (pero lo es).

No nos dejemos engañar. A pesar de todo esto, la gestión de dimensiones lentamente cambiantes es imprescindible. Personalmente, acostumbro a guardar toda la historia de las dimensiones en el modelo relacional (incluso algunos datos que inicialmente no parecen necesarios como la "fecha de nacimiento"). En el modelo dimensional, de entrada, sólo publico la visión actual, y sólo cuando lo solicita explícitamente el usuario de negocio, añado la visión histórica de esa dimensión.

Las dimensiones se agrupan en jerarquías mediante relaciones uno-a-muchos. Una población agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una región está formada por varias provincias. Etcétera. Las jerarquías típicas, que aparecen en cualquier sistema Business Intelligence, son:

• Jerarquía geográfica o de clientes (país del cliente/región/ciudad/cliente)
• Jerarquía de producto (marca/familia/producto/presentación)
• Jerarquía comercial (país/zona/punto de venta)
• Jerarquía temporal (año/trimestre/mes/día)

Evidentemente, pueden existir jerarquías adicionales, o incluso puede haber diferentes maneras de jerarquizar una misma información. En particular, es habitual la existencia de diferentes jerarquías de producto (lo que es una "pesadez" muchas veces necesaria, otro día lo comentaré…).

Esta manera de visualizar jerárquicamente la información resulta muy natural y cómoda para los usuarios de negocio.

Y, como siempre, podemos cometer errores modelizando las jerarquías. Éste es el error número 10 de esta serie sobre cómo construir un datawarehouse:

Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones

Existen dos maneras principales de modelizar las jerarquías:

• Modelo en estrella: Donde una única tabla contiene toda la información de la jerarquía.
• Modelo copo de nieve: Donde se crea una tabla para cada nivel de la jerarquía

En la base de datos de presentación (también llamado modelo dimensional) del DWH debe preferirse siempre el modelo en estrella. Es decir, debe crearse una única tabla para cada jerarquía. La misma tabla de PRODUCTOS debe tener toda la información relativa a los productos (presentación, producto, familia, marca).

El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence, por lo que interesa que las consultas generadas sean sencillas (con pocas tablas y pocas relaciones). El modelo en estrella es perfecto para conseguir este objetivo. Además, desaparece el problema que generan las diferentes jerarquías en que se pueden agrupar los productos.

Sin embargo, por desgracia, no siempre es posible tener un modelo en estrella perfecto. La herramienta de explotación puede requerir normalizar parte de una jerarquía en una tabla independiente. Esta limitación aparece cuando diferentes "hechos" están definidos con diferente granularidad. Por ejemplo, las ventas están a nivel de "producto", pero los objetivos de venta se marcan a nivel de "familia". En este caso, muchas herramientas BI exigirán la existencia de una tabla de FAMILIAS.

Finalmente, es importante destacar que además del "modelo dimensional" el DWH debe mantener un modelo normalizado de la información (llamado "modelo relacional"). En este otro modelo, la información sí que debe estar normalizada, unificada y limpia.

El datawarehouse (DWH) es una pieza básica, fundamental e indispensable de todo sistema Business Intelligence. Tal vez alguien no comparta la anterior afirmación, y crea que se puede construir un cuadro de mando, o un sistema de reporting, a partir de un datamart o unos cubitos. Perdónales, porque no saben lo que dicen... :-)

La pieza fundamental de un sistema Business Intelligence es el DWH porque todos los listados y análisis que se hagan se harán a partir de esta única base de datos. En el DWH la información está limpia, unificada y verificada, y gracias a esto todo lo que hagamos después cuadrará.

Tal como decía en mi anterior mensaje, voy a analizar los 12 errores más comunes que enumera el gurú Ralph Kimball. Tal como hace él, haré la cuenta regresiva del 12 al 1, aunque intentaré hacerlo en positivo, añadiendo ejemplos y experiencias personales, y explicando las bases sobre cómo construir un datawarehouse:

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.

En un modelo dimensional se deben diferenciar claramente las tablas de hecho de las tablas de dimensiones.

• Las tablas de hecho contienen los indicadores numéricos provenientes de los orígenes transaccionales.
• Las tablas de dimensión contienen los atributos (normalmente textuales) que nos permiten filtrar y agrupar los indicadores.

En ocasiones no es evidente si un dato es dimensional o si se trata de un indicador. Por ejemplo, la hora de la venta (hh:mm:ss) puede considerarse un dato mas del hecho de venta (como el precio, o las unidades vendidas), o una dimensión temporal muy detallada. O la matrícula del camión que subcontratamos para realizar los transportes. Si no tenemos un maestro de los miles de camiones que utilizan nuestros transpostistas, ni queremos analizarlo por las características del camión, podríamos considerar la matrícula como una especie de indicador e incluirlo en la tabla de hechos.

En caso de duda:

• Evita colocar texto largos (como comentarios, o nombres de ciudades o personas) en las tablas de hecho. Estos campos ocuparían un espacio precioso de nuestras tablas de hechos, que pueden tener cientos de millones de registros, y que por lo tanto ocuparían mucho espacio en disco y las consultas serían lentas por el IO generado. Hoy en día, los gigas son baratos, pero el tiempo para leerlos, no.
• Si el “dato” es compartido entre varias tablas de hecho, ponlo siempre como una dimensión. Por ejemplo, un mismo cliente puede tener pedidos, ventas, devoluciones, quejas, …

Aunque cada vez son menos, aún existen muchas medianas y grandes empresas que no disponen de un sistema de BI. Si ese es su caso, y está leyendo este blog, seguro que ya ha se ha dado cuenta que realmente necesita Business Intelligence en su organización.

Los proyectos de Business Intelligence no son especialmente sencillos. De hecho, son complejos y sólo unos pocos tienen un éxito rotundo a corto plazo. Parte de la dificultad está en la intervención de múltiples factores tecnológicos y no tecnológicos. En concreto, es necesario diferenciar estos tres aspectos o subproyectos:

• Proyecto Definición. Donde deben identificarse los conceptos de negocio que requieren atención. Identificar las necesidades de negocio de los usuarios, los indicadores y dimensiones con las que se trabajan. Conocer la estrategia y objetivos de la empresa, ya que los indicadores que permitan su gestión y seguimiento deben estar contemplados y perfectamente definidos dentro del proyecto. Determinar las limitaciones actuales y aquellos aspectos en los que se desea mejorar.
• Proyecto Datawarehouse. El DWH es una pieza clave del proyecto. Es la base de datos donde se centralizará la información corporativa y será el origen de todas las consultas y necesidades analíticas. Debería diseñarse con independencia de la herramienta de explotación, ya que el mismo DWH será explotado progresivamente por distintas soluciones analíticas (reporting, OLAP, CdM, etc.). A partir de este DWH único, es posible que sea aconsejable diseñar distintos “datamarts” con el objetivo de asegurar el rendimiento en aplicaciones críticas (por ejemplo, el CdM).
• Proyecto Herramienta. En el mercado existen diferentes aplicaciones de BI que permiten la explotación del DWH corporativo. Cada solución tiene unas características y cubre necesidades diferentes. Lo habitual es comenzar con un proyecto de reporting y posteriormente completar el sistema añadiéndole soluciones de OLAP, CdM y data mining.

En la publicación AltoNivel señalan una serie de puntos clave para conseguir que los proyectos de BI sean exitosos:

• Aunque el área de tecnología es actor fundamental en el proyecto, no debe ser responsable del aprovechamiento del mismo, pues cada área es la que conoce su propio negocio y debe aprovechar al máximo las ventajas de manejo de información y herramientas de análisis que le provee la Inteligencia de Negocios. Por ejemplo, los analistas financieros, los comerciales deben hacer sus propios análisis porque son ellos quienes tienen la experiencia.
• Antes de pensar en herramientas tecnológicas, se debe ser una estructura al proyecto y conocer mejores prácticas. Comprar una excelente tecnología de apoyo es indispensable, pero es un paso posterior.
• El proyecto de Inteligencia de Negocios debe responder a la estrategia corporativa de crecimiento, optimización, productividad, competitividad, entre otros aspectos; no debe hacerse porque sí, porque está de moda o porque la competencia ya lo desarrolló.
• Evalúe la calidad de la información que su compañía maneja. Haga esto como un proyecto paralelo o previo al de Inteligencia de Negocios, pues de nada valdrá la inversión en este tipo de iniciativa, si el sistema no tiene como insumo información correcta, completa y oportuna.
• En cuanto a la infraestructura de hardware analice con cuidado aspectos como capacidad de procesamiento y de almacenamiento, a mediano plazo. Adquiera plataformas robustas, acordes a sus necesidades. Piense en la capacidad de crecimiento que seguramente va a necesitar según la demanda de las diferentes unidades del negocio.
• Como último punto apóyese en quienes ya han vivido este proceso, aliméntese de sus experiencias y consúlteles sus inquietudes. El aporte de quienes ya recorrieron el camino, le ahorrará tiempo, le permitirá tomar mejores decisiones, minimizar los errores y sacar el mayor provecho de la Inteligencia de Negocios.
• A propósito de la inversión en tecnología, específicamente en el software, debe evaluar de forma detallada las opciones disponibles en el mercado. Además de los resultados que puede brindar, pregunte cuáles compañías la usan, averigüe la experiencia de ellas, revise las opciones de capacitación, consultoría y soporte técnico en el país.Revise sus características técnicas, por ejemplo.

Leyendo el resumen del año 2008 sobre el mercado BI que ha hecho la prestigiosa publicación TDWI, he aprendido una nueva palabra. Spreadmart. Detras de esta extraña palabra se esconde sin embargo una conocida situación en muchas empresas.

El término "Spreadmart" se refiere a soluciones de reporting o análisis que existen localmente en los ordenadores de los usuarios (típicamente en hojas de cálculo, o bases de datos tipo Access). Este tipo de soluciones proliferan sin el control del departamento IT de la compañia, y generan una serie de problemas:

• Información inconsistente. Pueden existir multitud de Excel con información redundante e incoherente. Los usuarios crean estos estudios tomando diferentes fuentes de datos, y aplican sus propios criterios, cálculos, filtros y convenciones. Inevitablemente, esto genera informes con información discordante.
• Tiempo de preparación y mantenimiento. Los usuarios crean estos Excel y los mantienen a lo largo del tiempo. Periódicamente, el propio usuario necesita actualizar el informe y emplea un tiempo considerable para hacerlo.
• Deficientes soluciones técnicas. Los "spreadmarts" se actualizan manualmente, lo que genera errores que pasan desapercibidos (falta de exactitud). Estas soluciones sólo sirven para un reducido grupo de usuarios (falta de escalabilidad). Y la lógica de informe suele estar escondida entre fórmulas y macros que sólo el usuario creador conoce (falta de mantenibilidad).

Sin embargo, si existen, será por algo:

• Falta de alternativas. La soluciones de BI de la compañía no son adecuadas para las necesidades de los usuarios. Habitualmente, por la imposibilidad de realizar data-input. Y el departamento de IT no puede ofrecerles una solución técnica en un tiempo razonable (creando una nueva aplicación de gestión, etc.).
• Barato, rápido, fácil. Crear este tipo de informes Excel resulta sencillo. Aunque no sean soluciones "elegantes", ni gusten al departamento de IT, bastan unas pocas horas o días para crear un informe de este tipo.

El informe de TDWI menciona algunas ideas para gestionar o reducir los "spreadmarts" pero al final termina con algo que parece una confesión:

Of course, if there are no operational systems capturing this data, then a spreadmart is the only alternative

Es decir: El DWH y las herramientas de BI de la compañía no sirven para nada si el usuario necesita introducir algún dato manualmente.

Creo que aquí hay material para la reflexión. ¿Hemos asumido como un dogma que una solución BI no puede ni debe permitir la introducción manual de datos?

No sé si queda clara la idea. Tal vez con un ejemplo se entienda mejor. Suele ser habitual que alguien necesite hacer un informe agrupando los países de una manera particular (que no está codificada en el sistema operacional de la empresa). En este caso, el usuario tiene pocas alternativas:

• O pide una modificación del ERP para añadir esta codificación, y traspasar luego este dato al datawarehouse corporativo. Esta opción puede demorarse meses (debido a la carga de trabajo y las prioridades de IT)
• O se genera un Excel y se hace él mismo el informe. Lo que puede hacer en unos pocos minutos, pero deberá asumir el mantenimiento de por vida.

Para el usuario de spreadmarts, la mejor cosa después del Excel, es el Excel integrado con el BI corporativo.

...y me parece que a las herramientas de BI tradicionales les falta una verdadera integración con Excel. Para un proveedor de BI, integración con Excel significa poder exportar el informe a Excel... ¿Y qué pasa con el sentido contrario?

En mi anterior comentario hablaba de tres tipos de usuarios de BI. Era una visión muy tradicional. Las cosas están cambiando. Hoy he recibido un mail de un usuario de negocio en el que literalmente decía…

"Quiero hacer servir nuestra herramienta de Business Intelligence para dar las órdenes directamente a nuestro ERP"

No se trata de ningún visionario de BI, ni de un vendedor de humo. Ni siquiera es un consultor de Accenture. Pero resume muy bien una tendencia importante en este mercado. Esta tendencia se ha denominado “Pervasive Business Intelligence”, que se podría traducir como “Business Intelligence omnipresente”.

El DWH ya no es sólo un sistema para que los analistas generen sus listados, sino que se dirige a unas áreas y a unos usuarios que tradicionalmente habían quedado excluidos. El Business Intelligence se acerca a los procesos operacionales y a los trabajadores que están en el front-end del negocio (atendiendo a proveedores y clientes). Todos los trabajadores necesitan información para su trabajo. Todos son “trabajadores de la información”. Desde el directivo, hasta los operadores del call center, o los trabajadores de fábrica.

El reto actual de los sistemas de Business Intelligence es ser capaz de proporcionar a cada trabajador la información necesaria en cada momento. Todo un reto.

• A cada trabajador
• La información necesaria
• En cada momento

Un reto enorme.

Enormísimo.

Es habitual observar como dentro de una misma empresa han nacido y crecido distintos proyectos de Business Intelligence de manera aislada. Sin saber éxactamente cómo, nos encontramos en situaciones donde cada departamento se ha construído su "cuadro de mando", o se han montado diferentes datamarts que luego se tratan de explotar como buenamente se puede. Es un error.

Desde mi punto de vista, debe existir un único "Proyecto BI", aunque éste debe dividirse en miniproyectos o fases independientes. De hecho, un proyecto BI lo veo como un desarrollo a largo plazo que debe hacerse de manera ordenada y en el cual deben irse incorporando nuevas piezas hasta conseguir montar el puzle completo…Sin prisas pero sin pausas...

Este puzle tiene dos ejes:

• Por un lado, está la información disponible en el sistema. Es fundamental tener un datawarehouse que luego será explotado por diferentes herramientas. Es un error tener distintos repositorios para resolver las necesidades de distintos departamentos. En este repositorio se deben ir añadiendo áreas de información de manera ordenada, y no pasar a la siguiente área hasta que la información previa esté convenientemente validada y en producción. Por ejemplo, se podría empezar cargando la información de ventas, posteriormente la de compras, luego la de la cadena de suministro, etc.
• En el otro eje, están las herramientas que hacen uso del datawarehouse, y también aquí se debe crecer de una manera ordenada. Aunque el objetivo final sea proporcionar información a la Dirección, creo que lo correcto es empezar por el extremo opuesto. La evolución natural de un sistema Business Intelligence comienza con un sistema de reporting, continua con soluciones OLAP de análisis de información, y sólo finalmente se deben incorporar cuadros de mando departamentales y sistemas EIS para la Dirección…

Entiendo que este acercamiento no siempre coincide con las prioridades de los que toman las decisiones, que querrían tener un bonito cuadro de mando en 3 meses, ni gustará a muchos departamentos que verán cómo no se contempla incorporar esa información vital suya que querrían YA en el DWH… En estos casos, se tiene que hacer notar que si se ha podido sobrevivir todos los años anteriores sin DWH, muy bien se podrá aguantar unos cuantos meses más… A la larga, creo que los usuarios se benefician de un crecimiento racional y ordenado del sistema.