Hace 24 semanas escribí un artículo analizando el problema de numerar las semanas del año. Se trataba de un artículo extenso, y denso, y sin embargo sigue recibiendo muchas visitas de gente que busca información sobre las "52 o 53 semanas del año", "las semanas del 2010", "semanas ISO", "cómo numerar semanas del año" u otras búsquedas semejantes...

Intentaré hoy ser más claro y conciso, ya que se trata de un tema que tarde o temprano aparece en los proyectos de Business Intelligence... (en mil informes y cuadros de mando se comparan las ventas con las fechas equivalentes del año anterior...)

En aquella ocasión comentaba que la ISO intentó ordenar los diferentes criterios que habitualmente se utilizan definiendo que:

• Todas las semanas tienen 7 días.
• Las semanas comienzan los lunes.
• La primera semana del año incluye al primer jueves del año

Este criterio presenta la deficiencia de que no todos los años tienen el mismo número de semanas. La mayoría de años tienen 52 semanas, aunque algunos años tienen 53 semanas. Por ejemplo, según la ISO, la semana 53 del 2009 transcurrió placidamente entre el 29 de diciembre del 2009, y el 4 de enero del 2010. ¿Acaso la semana 53 del 2009 no tendrá una semana comparable en el 2010?

Se trata de una deficiencia relevante desde el punto de vista analítico. Si no podemos comparar la semana 53 con la semana 53...¿Qué sentido tiene comparar la primera con la primera? ¿O la 29 con la 29?

En mi opinión, desde el punto de vista analítico, debemos olvidarnos del criterio ISO y de cualquier sistema de numeración que conlleve los mismos problemas (y esto incluye a todas las funciones "week number" que ofrecen los motores de bases de datos)…

Comenzaba el artículo diciendo que hace 24 semanas escribía un artículo similar a éste. Lo puedes comprobar cogiendo un calendario y contando hacia atrás 24 semanas. Con este sencillo método, si sigues contando hacia atrás, verás que hace exactamente 52 semanas era jueves 23 de julio del 2009. Casi como hoy.

Y ésa es precisamente la semana “equivalente” a la actual. Que diga la ISO lo que quiera. Para comparar semanas de años consecutivos, debemos avanzar o retroceder 52 semanas. De la misma manera, podremos comparar con la semana equivalente de hace 2, 3, 4… años… (restando 104, 156, 208 … semanas respectivamente).

Tal vez, con una imagen se ve mejor. Observad la equivalencia lógica entre las semanas del 2010 y la del 2009… Las flechas azules relacionan semanas con 52 semanas de diferencia...

Ayer comentaba que Scrum era una metodología ágil, y destacaba su capacidad de responder ante requerimientos inestables y ofrecer entregas frecuentes e incrementales.

Pero, ¿Qué es Scrum? El término viene de una jugada de Rugby en la que los jugadores de los dos equipos de apiñan para sortearse el balón. Y, supongo, que la metáfora subyacente es que todo el equipo empuja para conseguir el mismo objetivo.

Una vez demostrada mi erudición sobre el mundo del rugby, contesto:

Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia, y se centra en producir software que funcione y en ofrecer resultados visibles cada pocas semanas, incluso ante requerimientos inestables. Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo...

Quedará más claro si describimos el día a día de un proyecto con Scrum...

Al iniciar el proyecto se crea el "listado de funcionalidades" (o product backlog, según los puristas), que es un listado actualizado, incompleto y priorizado de los requerimientos del proyecto-producto.

El "cliente" (o product owner, según los dichosos puristas) es el encargado de mantener este "listado de funcionalidades" actualizado y priorizado.

La idea básica es que el desarrollo se hace de manera cíclica e incremental. En cada "ciclo de desarrollo" (sprint, dicen), el "equipo de desarrollo" (scrum team) selecciona el subconjunto de funcionalidades (sprint backlog) que se incorporarán al producto, y durante el siguiente ciclo se centrarán únicamente en completar esas funcionalidades y entregárselas al cliente. Los equipos son pequeños (máximo 8 u 9 personas…) pero experimentados (¡No intentes utilizar metodologías ágiles con equipos juniors!). Los ciclos de desarrollo son cortos (entre 3 y 5 semanas, habitualmente), por lo que se tiene una buena visibilidad sobre el avance del proyecto.

El "jefe de proyecto" (o scrum master) se encarga de ayudar al equipo en sus necesidades y evitar distracciones inútiles (coordinando reuniones, recabando información, ¡eliminando obstáculos!...). No ejerce exactamente de jefe (ya que es el propio equipo de desarrollo el que selecciona, estima y gestiona su tiempo, y se hace responsable del diseño, de la implantación, y del resultado). El equipo de desarrollo tiene una gran autonomía.

Tal como comentaba ayer, esta metodología se adapta muy bien a las características típicas de los proyectos Business Intelligence. Que son llevados a cabo por equipos relativamente pequeños. Que se pueden fraccionar los requerimientos y las entregas (incorporando áreas de información, mejorando rendimientos, "pintando pantallas", creando cubos…). Y que el cliente nunca sabe bien lo que quiere. Si asumes de entrada que habrá cambios, huirás de arquitecturas rígidas, y no darás nada por sentado, sabrás que te mueves en aguas pantanosas y eso te hará reflexionar, hecho fundamental para aumentar las probabilidades de éxito de cualquier proyecto...

Además, con Scrum, podrás ofrecer resultados tangibles de una manera continua, lo cual es deseable en todo tipo de proyectos, y también en los de BI … ¿Serán las metodologías ágiles una generalización de los tradicionales prototipos?

Os dejo un vídeo donde explican estos conceptos básicos de Scrum (...y con la terminología correcta). Entiendo que el vídeo está realizado en clave de humor, y que los equipos Scrum no han de ser tan frikis como pueda parecer.

Más info:

• Presion Blogosférica
• Proyectos ágiles
• Agile Spain

Hace unos días decía que el Scrum era una metodología para el desarrollo de software. Esa definición no es exacta. Scrum se define como una metodología ágil para el desarrollo de proyectos (de todo tipo de proyectos). Sin embargo, sí que es cierto que donde más se ha utilizado, y donde tiene más éxito, es en el desarrollo de software.

Sin entrar ahora en los detalles metodológicos, sus dos características más destacables son:

• Se acepta de entrada que los requerimientos son por definición cambiantes, y por lo tanto se evitan muchas discusiones estériles. ¡Los usuarios pueden cambiar de idea sobre lo que quieren y necesitan!. Punto. Se acabó la discusión.
• Entrega frecuente y progresiva de resultados, por lo que en todo momento se tiene una visión clara de la evolución del proyecto.

Esta metodología se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad (situaciones frecuentes en el desarrollo de software... y en los proyectos de BI).

Los proyectos de Business Intelligence no son propiamente "proyectos de desarrollo de software". Las aplicaciones de BI son las que son, y los proyectos suelen consistir en analizar las necesidades de los usuarios, y configurar las aplicaciones y los informes para cubrir esas necesidades. En un proyecto de BI, no se crea software, se crean "cubos", "pantallas", "informes", "indicadores", "dimensiones"... y toda una manera nueva de trabajar con la información. ¿Es aplicable la metodología de Scrum en los proyectos de Business Intelligence? Sí, un rotundísimo sí.

Lamentablemente, siguen abundando los proyectos de BI que se planifican con las clásicas fases de análisis, diseño, desarrollo, pruebas, y paso a producción (y a cruzar los dedos). Lo habitual es repartir arbitrariamente estas fases entre los meses que pensamos que el cliente está dispuesto a pagar. La realidad es que nunca se cumplen esas planificaciones, y que todo el mundo sabe y asume que no se cumplirán los plazos fijados.

Me estoy acercando peligrosamente al límite de las 400 palabras por artículo, por lo que temo que pueda estar perdiendo lectores a cada frase. Como aún tengo cosas que decir, dejaré para mañana la explicación de la metodología Scrum...

Para lo que quieran más, os dejo una divertida presentación que explica muy bien los problemas habituales que se encuentran los desarrolladores de software (perfectamente extrapolables a los implantadores BI), y la solución con Scrum...

Un grupo de amigos (eso dicen) están enfrascados en un juego con formato de experimento sociológico. Cada semana uno de los participantes escoje un tema, y todos los jugadores deben escribir en sus respectivos blogs sobre dicho tema. Luego, hay nominaciones, expulsiones, y tal. Para que veais que esto va en serio, y que no reparan en gastos, os dejo el vídeo de presentación de los concursantes... No tiene desperdicio... :-)

Pues bien, la cuestión es que la semana pasada el tema elegido fue precisamente el Business Intelligence... Al culpable de la elección, lo tacharon de estratega, y otras cosas peores, y de hecho ya tiene que andar con guardaespaldas. Yo, desde aquí, quiero agradecerle su granito de arena en la popularización de la cosa... ya que además nos ha dado la posibilidad de conocer la visión (o la falta de ella) que tienen personas ajenas al mundo del Business Intelligence sobre el Business Intelligence. Se trata de unos artículos impagables, que obviamente huyen de los topicazos que podemos leer en este u otros blogs... Ni siquiera han dicho aquello de que el BI convierte información en conocimiento, o que al Excel sólo le faltan los cuernos para ser el mismísimo Belcebú...

Algunos artículos son positivos y valoran las cualidades que ofrece el BI a la empresa; otros artículos son más críticos, y otros son abiertamente escépticos. Pero todos -todos- aportan cosas nuevas que merecen ser tenidas en consideración.

En fín, aquí os dejo los 12 artículos en cuestión:

• ¿Qué es para mi el Business Intelligence?
• Business Emotional Intelligence
• Business Intelligence y el sentido práctico
• Midiendo para decidir
• El sexto sentido
• Sobre el Business Intelligence y otras utopías
• ¿Quién se ha llevado mi queso?
• BI perdón IE
• Cuatro peligros del Business Intelligence
• ¿Qué he hecho yo para merecer esto?
• Dos ferreterías y el Business Intelligence
• Dos problemas generales en los sistemas informáticos de gestión

Y tú, ¿A quién darías 3, 2 y 1 punto para quedarse una semana más en el reto blogger?

En cualquier sistema de reporting o de cuadro de mando se trabaja habitualmente con semanas, y se requiere numerar las semanas del año desde la primera hasta la última. A pesar de ser algo requerido en todos los proyectos Business Intelligence, y ser habitual en todas las empresas, existe poco consenso sobre la manera de numerar de las semanas.

Esta problemática aparece por varios motivos:

• En algunos países las semanas comienzan los lunes, y otros consideran que el primer día de la semana es el domingo. En España, las semanas van de lunes a domingo.
• Los años tienen un número variable de días (365 o 366), y en ningún caso es múltiplo de siete. Esto provoca que cada año tenga 52 o 53 semanas, y que irremediablemente existan semanas a caballo entre 2 años diferentes...

Por lo tanto... ¿Cuál es la primera semana del año?

Existen dos respuestas habituales: Podemos considerar que el 1 de enero pertenece a la primera semana del año, por definición. O podemos decir que la primera semana del año es aquella en la que la mayoría de los días pertenecen al nuevo año. Se entiende mejor con un ejemplo concreto... ¿Cuál es la primera semana del año 2010? ¿La del 1 de enero? ¿O la del 4 de enero?

Afortunadamente, alguien intentó ordenar la situación estandarizando todo esto... Según la ISO 8601:

• Las semanas comienzan los lunes
• La primera semana del año incluye al primer jueves del año
• Cada año tiene 52 o 53 semanas

Por cierto, la condición de que "la primera semana del año incluye al primer jueves del año" es completamente equivalente a estas dos:

• El día 4 de enero siempre pertenece a la primera semana del año
• La primera semana del año es aquella en la que la mayoría de días pertenecen al nuevo año

Desafortunadamente, nadie ha hecho demasiado caso a esta definición ISO. Prueba de ello, es que el Excel no tiene una función para calcular el número de la semana ISO, ni tampoco la incluyen la mayoria de bases de datos (SQL Server, por ejemplo, no ha definido ISO_WEEK hasta la versión SQL Server 2008). Seguramente, la falta de aceptación de este criterio se debe a que en Estados Unidos no tiene ningún sentido comenzar a numerar las semanas un lunes. En Europa, sigue siendo común considerar que el 1 de enero pertenece a la primera semana del año.

Desde el punto de vista analítico, además, las semanas ISO tampoco nos resultan útiles. Para entender por qué, es necesario comprender primero para que necesitan los usuarios el "número de semana"... Esta dimensión se utiliza en los informes semanales, donde se mira la evolución de un indicador respecto la semana anterior y/o respecto la semana equivalente del año anterior. En informes diarios también se utiliza un criterio similar... y se compara las ventas del día, respecto el mismo día de la semana anterior, y el día equivalente del año anterior. ¿Y cuál es el día equivalente del año anterior? ¡¡Pues el del mismo número de semana!!

Veamos un caso concreto. Hoy es jueves 4 de febrero del 2010. Según el criterio ISO, hoy es el jueves de la quinta semana del año 2010. El día equivalente del año anterior es el jueves de la quinta semana del año 2009... que según el criterio ISO corresponde al jueves 29 de enero del 2009...mmm... Esta respuesta nunca ha gustado a mis usuarios de negocio. Desde hace años, a mi tampoco (creo que fue en el 2005 cuando me convencieron). Según mis usuarios de negocio, el día equivalente es el jueves 5 de febrero del 2009.

Este problema aparece porque el año 2009 tuvo 53 semanas ISO... Es un problema recurrente. Ocurrió en 1998 y en el 2004, y volverá a ocurrir en 2015, 2020 y 2026... Que sólo ocurra cada 5 o 6 años, no impide que debamos afrontarlo... ya que durante todo el 2010 deberemos comparar las semanas con las equivalentes del 2009... ¿Cómo debemos, entonces, calcular la semana equivalente? Además, ¿Cuál seria la "semana equivalente" a la semana 53 del año 2009?

En un sistema Business Intelligence, con un objetivo analítico, considero que da igual como se numeren la semanas. Lo principal, lo imprescindible, es que cada año debe tener exactamente 52 semanas. De esta manera, para calcular el día equivalente del año anterior debemos restar 364 días (=52x7), para calcular el día equivalente de hace 2 años debemos restar 728 días (=2x52x7), etc. Una vez decidamos cual es la primera semana del año actual, ya podemos numerar todas las semanas pasadas y futuras, en grupos de 52...

Podemos considerar que la primera semana del año es la de 1 de enero, o la del primer jueves. Es igual. Si suponemos que la primera semana es la del primer jueves, numeraríamos las semanas pasadas y futuras de la siguiente forma (SQL Server):

(floor(datediff(d,CONVERT(datetime,'20100104',112),@fecha)/7.0)+52000)%52+1

Evidentemente, este "número de semana" debe estar precalculado en la tabla de tiempo de nuestro datawarehouse... Observad que en esta fórmula he tenido en cuenta que el lunes de la primera semana del año actual fue el 4 de enero del 2010... Esta formula funcionará sin problemas hasta el 2015....

Esta manera de numerar las semanas es útil en sistemas analíticos. La problemática descrita anteriormente es habitual en la industria del retail y en el de las telecomunicaciones, y en todos aquellos casos en los que se trabaja con informes diarios o semanales. La solución propuesta es una solución personal, heterodoxa, por lo que aprovecho para ponerla a vuesta consideración. ¿Existe el "número de semana" en vuestro datawarehouse? ¿Cuál es la primera semana del 2010? ¿Trabajas con el concepto de "semana equivalente"? ¿Cuál es la semana del 2009 equivalente a la primera semana del 2010?

Buff... Veo que me ha quedado un artículo algo denso... Quien no haya desayunado bien, no entenderá nada de nada... :-)

ACTUALIZACION: He escrito otro artículo sobre las semanas del año. He intentado ser más conciso...

La semana pasada Josep Curto, de Information Management, publicó un vídeo de introducción al Business Intelligence para sus estudiantes de la UOC. Esta introducción al Business Intelligence dura 40 minutos, por lo que tiene ocasión de analizar los distintos aspectos con cierto detalle. La UOC es pionera en la enseñanza del BI y vídeos como éste lo demuestran (¡existe muy poca literatura independiente sobre BI!).

En primer lugar, se define el concepto de Business Intelligence, y se destacan las características fundamentales de estos sistemas:

• Facilitan el acceso a la información
• Apoyan a la toma de decisiones
• Orientación al usuario final (information workers)

Es interesante, también, el concepto de "ciclo de vida de la información". Con el Business Intelligence, los datos son un "activo" de la compañía, un activo cada vez más fundamental, y tienen su propio ciclo de vida, transfromándose en información, en conocimiento, y finalmente en acciones, resultados y valor. Según este enfoque, los datos son un activo en el mismo sentido que las materias primas, y pueden convertirse en valor para la compañía.

Luego, se explica como es un proyecto de Business Intelligence típico, y cómo los datos de las diferentes fuentes, se unifican y centralizan en el datawarehouse, que después es utilizado por las herramientas de análisis para acceder a los datos y aportarles valor.

También se explica la terminología del BI, prestando especial atención a los elementos de un datawarehouse, a los tipos de tablas de hecho, los tipos de dimensiones, y los tipos de indicadores. Muy interesante.

A continuación, se mencionan las necesidades que las empresas esperan cubrir con el Business Intelligence (listados, consultas ad-hoc, OLAP, previsiones, reglas de negocio, dashboards, scorecards, mapas estratégicos, data mining, simulaciones, modelos estadísticos, planes de actuación, etc.), y se extraen 4 lecciones de la experiencia en este sector:

• Existen diferentes tipos de usuarios con diferentes necesidades
• Ninguna plataforma cubre el 100% de las necesidades
• Actualmente, pocos sistemas de BI utilizan datamining
• La información en tiempo real también es crucial (BAM). Y no sólo la histórica.

En la parte final del vídeo, se analizan los beneficios que aporta una solución de Business Intelligence, y se comenta la situación actual del mercado y las tendencias para los próximos años. Sumamente interesante, y hablaré sobre ello en otra ocasión.

Como he dicho, el vídeo dura 40 minutos (¿no era 10 minutos el límite de YouTube?). Aquí lo tenéis:

He encontrado un nuevo blog de un responsable de Microsoft Business Intelligence que se se llama precisamente "What is Business Intelligence?". En general, me gusta el discurso BI de Microsoft, por lo que seguiré con interés sus artículos, aunque sus soluciones actuales sean aún limitadas.

Parece que el objetivo del blog será aclarar y concretar lo que se esconde detrás de este polisémico término. Le deseo mucha suerte en el intento. Yo ya llevo casi 2 años y casi 100 artículos con este mismo objetivo :-)

He aportado mi granito de arena escribiendo un comentario e intentando responder su pregunta de una manera concisa:

Business Intelligence is about accessing data and analyzing information.

El autor del blog me ha respondido con nuevas preguntas, como si de un Sócrates cualquiera se tratara, lo que me ha llevado a completar mi definición inicial:

Business Intelligence is about accessing data and analyzing information... to make better decisions.

¿Incluye esta definición lo esencial del término? ¿Pensáis que estoy obviando algo importante o descentrando el verdadero objetivo? ¿Cómo definirías tú BI con menos de 140 caracteres?

Hoy escribo agradecido y orgulloso; me siento como Michael Phelps, incluso me parece oír unos crujidos. Parece como si mi caja torácica estuviese a punto de estallar o algo. :-)

Resulta que acabo de leer un artículo de SQL Server Si! que recomienda precisamente este blog como punto de inicio para el aprendizaje de las técnicas de Business Intelligence. En especial, Salvador Ramos recomienda la serie sobre cómo construir un datawarehouse que escribí el pasado verano, entre otros artículos, y considera que "Business Intelligence fácil" es un buen lugar donde conocer la teoría relativa al Business Intelligence.

La serie sobre "cómo construir un datawarehouse" incluye mis artículos más tecnológicos, y recogen mi experiencia en la construcción de bastantes datawarehouses y datamarts en diferentes empresas. Debo confesar que lo errores que menciono, y que animo a evitar, los he cometido en primera persona, e incluso algunos de manera reiterada. Al final, los errores de modelización siempre se acaban pagando, y tarde o temprano se tienen que rectificar para volver a la ortodoxia. Hay otros errores que también se pagan caros: Seleccionar la herramienta incorrecta, o pensar que con pagar las voluminosas facturas de consultoría es suficiente. Y no, no es suficiente. Es necesaria una fuerte involucración por parte de nuestra empresa (de técnicos, de usuarios y de dirección).

Para mí, el éxito de un proyecto Business Intelligence puede medirse a partir de un único indicador, y es el uso que se hace del mismo. Por lo tanto, ese debe ser el primer criterio que debe considerarse en el momento de añadir una funcionalidad al sistema. ¿Conviene precalcular este indicador? ¿Creo esta tabla agregada? ¿Completamos el sistema de reporting con una solución alternativa de cuadros de mando? ¿Es suficiente un cubito y unas tablas dinámicas en Excel para analizar la información? Todas estas preguntas se pueden contestar respondiendo esta otra... Si lo hago, ¿Facilitaré la vida al usuario?

Por lo tanto, para empezar la implementación de Business Intelligence considero que se debe comenzar por identificar aquellos problemas que tienen actualmente los usuarios. ¿Cómo acceden a la información? ¿Tienen la información que necesita? ¿Protestan porque la calidad del dato es insuficiente? ¿Se dedica excesivo tiempo a la realización de los informes?...

Una vez identificado el problema, la teoría es relativamente sencilla, y he tratado de exponerla en muchos de los artículos de este blog. Con la teoría clara, sólo es necesario un poco de experiencia para que el proyecto sea un éxito. Afortunadamente, las cosas han cambiado mucho en los últimos 15 años, y ya existe experiencia y conocimiento suficiente en el mercado español. Actualmente, la mayoría de proyectos de datawarehouse o reporting terminan con éxito, cosa que hace unos años sólo ocurria esporádicamente y casi por casualidad...

Esta entrada ha sido muy difícil de escribir, pues he tenido que seleccionar de este blog sólo diez de los veinte mangíficos consejos para fracasar como jefe de proyecto informático. He intentado seleccionar aquellos 10 que me han parecido más imprescindibles para conseguir el objetivo, y especialmente en un proyecto de Business Intelligence, pero es recomendable la lectura de la lista completa. Ahí va mi selección:

• Cuando visites al cliente dile que sí a todo, sea lo que sea. Tu trabajo es complacer al cliente y lo haces muy bien, si los programadores no saben hacer el suyo, es su problema.
• A la hora de preparar un plan de proyecto sé muy optimista con los tiempos, sobre todo con los de desarrollo, los programadores tardan en desarrollar los módulos lo que tú dices que se tarda, por algo eres su jefe, aunque jamás hayas programado ni el vídeo. Sobre todo no consultes tiempos con ellos, no vaya a ser que te digan que necesitan más horas.
• Jamás, y digo jamás, reserves horas del proyecto a una fase de pruebas con usuarios reales ajenos al desarrollo. Ya se encargarán los programadores de ir probando lo que hacen.
• Cuando un programador tenga una iniciativa creativa o una buena idea, recházala de inmediato. Las cosas se hacen como tú lo dices y punto, para sus creatividades ya tienen los fines de semana.
• Cuando un miembro del equipo haga algo mal, díselo delante de todos sus compañeros y sobre todo, no te sientes con él para solucionar el problema.
• No dejes que el equipo tenga una visión global del proyecto, si un programador está encargado de la impresión de informes, no tiene porque saber de que va el resto del proyecto ni de que partes se ocupan sus compañeros.
• No motives a tu equipo, su sueldo debería de ser su motivación. Nunca les digas la importancia que tiene su trabajo en el proyecto y en la empresa. Tampoco les felicites, para eso les pagan.
• Cuando tu equipo necesite algún recurso de la empresa (o fuera de ella), que lo busquen ellos. Tú no tienes tiempo de solicitar compras o peticiones al departamento de sistemas, y mucho menos de justificarlas por ellos. Desentiéndete.
• Cuando haya problemas con los plazos, échale la culpa al equipo en general, y a ese programador que hizo algo mal en particular. Recuerda, tú escribiste un plan que era perfecto, si no lo han seguido es su problema.
• Cuando un superior te pida explicaciones acerca del proyecto, nunca saques la cara por tu equipo, tu responsabilidad no llega a tanto y si alguien tiene que ponerse colorado que sean ellos.
• Si por algún casual tienes éxito en un proyecto, no traslades ese éxito a tu equipo no vaya a ser que se motiven. El éxito es solo tuyo, házlo saber a tus superiores.

¿Qué os parece? ¿Os suena?

Las herramientas de BI surgieron a finales de los 80 para facilitar el acceso a las bases de datos. Hasta entonces, la única manera de realizar una consulta era mediante el lenguaje SQL(extrañísimo lenguaje de programación que sólo los técnicos conocen).

En esencia, nada ha cambiado desde entonces. Las herramientas de Business Intelligence son meros visualizadores, y lo que ofrecen (o deberían ofrecer) es:

• Facilidad de uso
• Opciones de visualización

Todo lo demás es filosofía (o técnicas de márketing).

He encontrado este vídeo de Microsoft donde explica brevemente la evolución del Business Intelligence desde sus orígenes hasta ahora. El vídeo es simpático y no tiene carácter comercial (no mucho, por lo menos). La presentación dura 10 minutos.

Si no dispones de 10 minutos para ver el vídeo, aquí tienes un resumen:

El vídeo comienza hablando sobre la confusión que genera el término BI, y explica que el Business Intelligence hace referencia a la toma de decisiones por parte de las personas a partir de la información. Esas son las tres palabras claves según Microsoft: Personas, información y decisiones.

Luego, hace un recorrido sobre los distintos hitos históricos que nos han llevado hasta la situación actual. Menciona los siguientes:

• 1969: Creación del concepto de base de datos (Codd)
• 1970’s: Desarrollo de las primeras bases de datos y las primeras aplicaciones empresariales (SAP, JD Edwards, Siebel, PeopleSoft). Estas aplicaciones permitieron realizar “data entry” en los sistemas, aumentando la información disponible, pero no fueron capaces de ofrecer un acceso rápido y fácil a dicha información.
• 1980s: Creación del concepto Datawarehouse (Ralph Kimball, Bill Inmon), y aparición de los primeros sistemas de reporting. A pesar de todo, seguía siendo complicado y funcionalmente pobre. Existían relativamente potentes sistemas de bases de datos pero no había aplicaciones que facilitasen su explotación.
• 1989: Introducción del término Business Intelligence (Howard Dresner).Ejem.
• 1990s: Business Intelligence 1.0. Proliferación de múltiples aplicaciones BI. Estos proveedores resultaban caros, pero facilitaron el acceso a la información, y en cierto modo agravaron el problema que pretendían resolver (¡Había aún más versiones de la verdad!)
• 2000s: Business Intelligence 2.0. Consolidación de las aplicaciones BI en unas pocas plataformas Business Intelligence (Oracle, SAP, IBM, Microsoft). A parte de la información estructurada, se empieza a considerar otro tipo de información y documentos no estructurados.

Pero, a pesar de todos los “fracasos”, sigue siendo un buen momento para el Business Intelligence, es una prioridad en todas las empresas, que mueve mucho dinero.

Según Microsoft, el BI se ha preocupado poco de las personas, y muchos de los sistemas y la tecnología (opinión que comparto, por cierto).

Espero tener otro día la posibilidad de hacer una pincelada sobre la oferta de Microsoft en el ámbito Business Intelligence. Según dicen, las herramientas ya las tenemos, ¿Se referirán al Excel?...

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.

Se ha escrito mucho sobre los cuadros de mando. Los consultores, los jefes de Business Intelligence, los vendedores de herramientas necesitamos estar al día, y conocer los conceptos teóricos que nos permitirán mejor "vender" nuestros proyectos. De esta manera, no hemos tenido problema en consturir todo un armazón conceptual de cómo ha de ser un CdM, de la tipología de indicadores que han de presentarse, y del tipo de decisiones que se tomarán en función del CdM.

Se ha escrito mucho, y sin embargo se ha leído mucho menos. Los destinatarios de los CdM han leído muy poco, y conocen muy poco la terminología que empleamos los "expertos"... Han de fiarse de nosotros, y han de confiar en que nos les vendemos excesivo humo.

¿Qué es un cuadro de mando? En el sentido más genérico posible, un cuadro de mando es una aplicación informática que facilita el acceso a la información corporativa con el objetivo de mejorar la toma de decisiones y que se caracteriza por ser muy rápida y visual y por ser extremadamente sencilla de utilizar, sin necesidad de tener conocimientos técnicos.

En esta definición, he intentado dejar la básico, y he ignorado lo accesorio. Por ejemplo, no digo que esté dirigido a la dirección o a cargos de responsabilidad. Para mi, eso es accesorio, y sólo es una consecuencia del coste de desarrollo. Si fuera fácil, rápido y económico contruir un cuadro de mando, cada empleado tendría el suyo propio. Tampoco hablo de indicadores, ni de KPI, ni de objetivos, ni nada de eso. Eso también es accesorio; se trata de una característica particular de unos determinados CdM dirigidos a unas determinadas personas. Lo importante es que aparezca la información que se necesita, y que te permita tomar mejores decisiones en tu trabajo diario. Por supuesto tampoco hablo de si ha de ser una aplicación web, lo cual es totalmente secundario. Ni se han de aparecer las 4 perspectivas de Kaplan... eso lo decidirá el cliente según sus necesidades. Y no digo si es sencillo o complicado construirlo y mantenerlo, ni la libertad que tiene el usuario para personalizarlo, ya que todo eso es dependiente del estado de la técnica actual.

¿Qué os parece esta definición de cuadro de mando? ¿Simplifico demasiado? ¿Me dejo alguna característica fundamental?

En el mercado de las soluciones BI existen tres tipos de aplicaciones principales:

• Reporting
• Análisis OLAP
• Cuadros de mando

Existe cierta confusión entre estos conceptos, y en demasiadas ocasiones los "expertos" tenemos dificultades en explicar qué solución necesita la empresa cliente y por qué. Los requerimientos suelen ser similares... Todos los usuarios quieren acceder a la información corporativa, de una manera rápida y sencilla, y por supuesto con datos fiables, exactos y actualizados. La respuesta del "experto" es siempre la misma:

"Usted necesita una herramienta de Business Intelligence"

"Sí, ¿Pero cuál?"

Para responder a esta pregunta, intentaré explicar las características fundamentales de estos tres tipos de soluciones.

• Reporting: Los informes que se generan son básicamente estáticos, y su mayor dinamismo suele ser la existencia de “filtros dinámicos”, que permiten ejecutar el informe de manera parametrizada. El usuario avanzado tiene capacidad de realizar informes ad-hoc. Otra característica fundamental es la posibilidad de incluir varias tablas o gráficos, es decir, el informe tiene distintos “bloques de información”.
• Análisis OLAP: Son las tablas dinámicas de Excel de toda la vida, que han evolucionado hasta convertirse en “cubos”. Tanto las tablas dinámicas como los cubos proporcionan una manera muy fácil y dinámica de navegar por la información. Invariablemente, estas soluciones sólo permiten navegar por un único “bloque de información” (tabla o gráfico). El usuario tiene total autonomía para navegar libremente por el cubo.
• Cuadros de mando. Se trata de unos informes predefinidos, y muy visuales, con los que cualquier persona (habitualmente cargos con responsabilidad) puede hacer el seguimiento de los indicadores de su interés sin ningún tipo de conocimiento técnico. Actualmente, el desarrollo de estos cuadros de mando es costoso, se requieren conocimientos técnicos, y es necesario un importante análisis funcional para definir la navegabilidad deseada. Son, por lo tanto, informes dinámicos, pero predefinidos.

Teniendo en cuenta estas consideraciones, es fácil ver las diferencias entre los diferentes productos (y entre las diferentes necesidades de los usuarios), y permite entender el confuso catálogo de productos que ofrecen todos los fabricantes de software. Estas reflexiones se pueden formular con las tres ecuaciones fundamentales del Business Intelligence del s.XX:

• Reporting = Informe estático
• Análisis OLAP = Tabla dinámica
• Cuadro de mando = Informe dinámico predefinido

Este enfoque me gusta porque permite explicar muchas cosas del mundo actual, pero deja demasiadas preguntas sin respuesta:

• ¿Por qué un informe no puede ser tan dinámico y visual cómo un cuadro de mando?
• ¿Por qué no puedo navagar por varias tablas dinámicas simultáneamente?
• ¿Por qué el jefe no puede crear su propio cuadro de mando?
• ¿Por qué seguimos utilizando masivamente el Excel cuando llevamos 15 años tratando de sustituirlo con inversiones en BI?

El futuro pasa sin duda por la unificación de estas tres fuerzas en una única ecuación fundamental del Business Intelligence. Esta unificación, en mi opinión, y teniendo en cuenta la situación en el mercado Business Intelligence 2009, sólo puede venir de fuera de los agentes principales del mercado.

En ocasiones, desde IT tenemos la tentación de atribuir los fracasos en los proyectos BI a razones estrictamente extra-tecnológicas (gestión de proyecto, indefinición de requerimientos, falta de apoyo de Dirección, etc.). Personalmente, niego la mayor. Es decir, comparto que es necesaria una implicación de los usuarios de negocio y un apoyo decidido de la compañía, pero considero que existen una serie de barreras, muchas de ellas tecnológicas, que dificultan la adopción de soluciones BI y que terminan generando desconfianza, incredulidad, y en definitiva, falta de apoyo a este tipo de proyectos.

En uno de los blogs de Billage, he encontrado una muy interesante reflexión sobre las barreras existentes en la adopción de soluciones Business Intelligence. Se citan las siguientes:

Barreras tecnológicas

• Facilidad de uso para los usuarios.
• Falta de estándares del mercado.
• Problemas de integración y compatibilidad.
• No integración con soluciones de BPM.
• Problemas de escalabilidad.
• Problemas de calidad de datos.

Barreras económicas

• ROI no claro.
• Las licencias de software son caras.
• Coste de formación.
• Coste del equipo de Business Intelligence.

Barreras culturales

• No existe una cultura de la información.
• No se comprende en qué consiste Business Intelligence.

Me gusta y comparto esta lista de barreras. Aunque el autor del blog no ordena estas barreras por su importancia, ni indica cuales considera que son las determiantes, se observa que ganan por goleada las barreras tecnológicas. Por algo será.

Creo que los proveedores de software deberían reflexionar sobre estas cuestiones. Falta innovación en este sector. Faltan alternativas. Faltan proveedores que hagan cosquillas a los grandes dinosaurios del mercado Business Intelligence.

Tal vez se trate de algo conocido por todos los del mundillo BI… pero yo me he quedado de piedra al enterarme que el término “Business Intelligence” se remonta a 1958 (sic).

Efectivamente, en octubre de 1958 H.P. Luhn (de IBM) escribió un artículo llamado “A Business Intelligence System” donde describe las características que debe tener un sistema de este tipo.

En muchos aspectos, el paralelismo entre lo que escribió hace 50 años y lo que entendemos hoy en día por BI es absoluto…

• Cientos de veces hemos leído que cada vez hay más información y que crece a un ritmo más rápido, y lo atribuimos a la globalización de las compañías y su continua especialización. Exactamente igual que hace 50 años: "Information is now being generated and utilized at an ever-increasing rate because of the accelerated pace and scope of human activities and the steady rise in the average level of education. At the same time the growth of organizations and increased specialization and divisionalization have created new barriers to the flow of information. "
• También nos quejamos de que aumenta el número de decisiones que debemos tomar, y se reduce el tiempo para analizarlas. Igual que hace 50 años:"There is also a growing need for more prompt decisions at levels of responsibility far below those customary in the past."
• La solución a estos problemas pasa por distribuir la información adecuada a la gente que lo necesita. Igual que hace 50 años:"disseminate the data promptly to the proper places and furnish information on demand."(¡incluso utiliza la expresión information on demand!)
• El objetivo final es que usuario sea capaz de acceder lo más directamente posible a la información. Como hace medio siglo:“Although the service of a librarian is considered a convenience to the action point, in certain cases, means may be provided at the action-point location to permit direct access to the system.”

¿Cuantos conferenciantes han (habremos) explicado esto mismo con tono solemne como si estuviésemos descubriendo la penicilina?

Por cierto, según tengo entendido, el mérito actual del término “Business Intelligence” no se atribuye a Luhn (IBM, 1958), sino que se suele atribuir a Howard Dresner (Gartner, 1989)… Desconozco lo motivos, ya que ni siquiera he podido encontrar aún el texto de 1989 donde Dresner definía el Business Intelligence como…

“concepts and methods to improve business decision making by using fact-based support system.”

Para finalizar, puntualizar que la mayor divergencia entre lo que escribía Luhn y lo que entendemos actualmente por BI está en que Luhn no pensaba en información estructurada en bases de datos, sino que se refiere siempre a documentos textuales en un sentido mas genérico… ¿falta de clarividencia o es que todavía no hemos desarrollado completamente su idea?

Hola de nuevo,

Por trabajo, por la WOC, y por varios proyectos en los que estoy metido, he tenido este blog un poquito olvidado... Vuelvo para seguir "diseccionando" el mundo BI... jeje

Como en toda clasificación, sacrifico muchos matices distinguiendo sólo tres tipos de "trabajadores de la información":

• Jefes: Que no tienen tiempo ni ganas de generar informes. Solicitan información que sus colaboradores les preparan. Aunque existen unos informes estándar que piden habitualmente, también solicitan muchos estudios ad-hoc para tratar de comprender la situación del negocio.
• Analistas: Expertos en Excel. Analizan la información existente, y la transmiten a los verticalmente por la compañía, o bien a sus superiores, o bien al personal de oficina (técnicas para vender mejor, definir productos con mayor aceptación, detectar tendencias en su zona de responsabilidad, etc.)
• Estadistas: Son unos analistas con unas características muy especiales. En lugar de emplear "tablas dinámicas" y BUSCARV, utilizan criterios matemáticos para construir modelos de la realidad…

Los sistemas Business Intelligence pueden cambiar completamente la manera de trabajar de estos tres grupos de usuarios. La idea es sencilla... un datawarehouse para todos, y una herramienta BI para cada uno:

• Cuadros de mando para jefes
• Reporting y análisis OLAP para los analistas
• Data mining para los estadistas

Con la implantación de una solución Business Intelligence, muchos usuarios dejarán de "perder tiempo" preparando y cocinando Excels, y podrán dedicarse a comprender y cambiar el negocio.

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.

Una de las formas más populares de analizar la información es mediante el uso de cubos OLAP (o bases de datos multidimensionales). Básicamente, un cubo es una estructura de datos organizada mediante jerarquías. Cada indicador se puede evaluar en cualquiera de los niveles de las jerarquías. Así, por ejemplo, se pueden obtener las "ventas" a nivel diario, mensual, o a anual, para un cliente, una provincia, o un país…

El uso de cubos OLAP tiene dos ventajas fundamentales:

• Facilidad de uso. Una vez construido el cubo, el usuario de negocio puede consultarlo con facilidad, incluso si se trata de un usuario con escasos o nulos conocimientos técnicos. La estructura jerárquica es sumamente fácil de comprender para la mente humana, y si ésta coincide con el modelo de negocio, los resultados suelen ser espectaculares, ya que el cubo se convierte en una gran "tabla dinámica" que el usuario puede consultar en cualquier momento.
• Rapidez de respuesta. Habitualmente, el cubo tiene precalculados las distintas agregaciones, por lo que los tiempos de respuesta son muy cortos. Si el cubo está bien diseñado, resultará igual de rápido consultar las ventas de una ciudad, o las ventas de todo el país, o incluso el total de ventas de la compañía.

Sin embargo, no todo son ventajas… Estos son algunos de los inconvenientes:

• El cubo es estructura adicional de datos que mantener y actualizar, eso supone un gasto extra de recursos (servidores, discos, procesos de carga…).
• El modelo de negocio no siempre se adapta bien en un modelo jerárquico. Por poner algunos ejemplos típicos: Una semana no pertenece a un único mes, o las zonas de venta corporativas no tienen porqué coincidir con la estructura provincial de cada país, o varios responsables pueden encargarse de una misma tienda, o distintos departamentos de la compañía pueden utilizar distintas agrupaciones de los productos... Estas casuísticas, que pueden parecer triviales, son habituales en cualquier compañía, y dificultan enormemente la construcción y uso de los cubos OLAP…

La alternativa a los cubos son las habituales bases de datos relacionales. En estos casos, se suele hablar de cubos o herramientas ROLAP, donde el usuario tiene la sensación de estar trabajando con un cubo, aunque internamente existe una base de datos normal y corriente… Estos sistemas son bien conocidos, y siguen unos estándares más aceptados que en el caso de las bases de datos multidimensionales, por lo que -en mi opinión- siempre debería ser una opción a evaluar dentro de cualquier proyecto de Business Intelligence.

Desgraciada a afortunadamente, no existe una única solución que valga para todos las compañías y proyectos… Cada caso se tiene que estudiar y decidir, según las necesidades, si realmente vale la pena utilizar cubos OLAP. Me atrevo a lanzar la siguiente recomendación:

• Un cubo no puede sustituir a un modelo relacional. Detrás de cada cubo, debería existir un único repositorio con la información normalizada… Es decir, primero normalicemos la información que queremos analizar y después, si en necesario, construyamos uno o varios cubos para los usuarios…

He leído por ahí que crear listas es una buena manera de potenciar un blog. Pues ahí va mi primer decálogo. Las diez características imprescindibles de un sistema Business Intelligence dirigido a la dirección:

• Sin curva de aprendizaje. Funcionamiento extremadamente sencillo.
• Rápidos tiempos de respuesta, del orden de segundos o menos.
• Herramientas de visualización avanzadas (gráficos, tablas, velocímetros, etc.)
• Información semafórica, que permita detectar anomalías o situaciones excepcionalmente buenas o malas.
• Navegable, que permita profundizar o segmentar la información libremente (por países, zonas, por familias de producto, etc.)
• Las unidades en que se muestran los indicadores deben ser configurables, es decir, debe permitir ver los indicadores en euros o en divisa, el dato mensualizado, o acumulado, etc.
• Debe combinar adecuadamente información agregada y detallada, y que el paso de una visión a otra sea opcional e inmediata.
• Dato de calidad. Tanto o más importante que la obvia necesidad de tener datos correctos y completos es que éstos sean coherentes con información que se pueda consultar por otros medios (reporting, ERP…)
• Interfaz de usuario robusto y humano, sin tecnicismos informáticos.
• Imprimible, que al final es el único formato que se puede compartir en una reunión informal en la cafetería…
• Que se resumen en dos: Mostrarás la información relevante en cada momento, y facilitarás la vida al usuario

En mi anterior mensaje descubrí mis cartas: Soy un entusiasta del Business Intelligence, pero al mismo tiempo soy crítico con algunos aspectos de este mundillo... Espero poder desarrollar mi pensamiento en futuras aportaciones, ya que este blog de Business Intelligence será básicamente un blog de opinión, aunque también aportaré noticias, novedades, curiosidades o cualquier cosa que me parezca interesante... Las opiniones aquí vertidas son fruto de mi humilde parecer y no representan a nadie más que a mi, por lo que harás muy bien en tomarlas, desecharlas o criticarlas abiertamente. Estaré encantado si aportas tu propio comentario en este blog.

Pero antes de eso, empezemos por el principio... ¿Qué es Business Intelligence?

Business Intelligence es un mercado que tiene como objetivo facilitar el acceso y análisis de la información corporativa y proporcionar las herramientas tecnológicas adecuadas para la toma de decisiones. Desde mi punto de vista, la palabra clave en todo esto es "análisis", y es lo que lo diferencia esencialmente de otros sistemas donde lo primordial es ejecutar los procesos operacionales de la compañia (crear pedidos, emitr facturas, dar de alta clientes, etc...).

Existen muchas maneras de analizar la información, y por este motivo existen un conjunto de soluciones que resuelven las diferentes necesidades analíticas. Concretamente, las soluciones que se encuadran dentro del amplio concepto BI son las siguientes:

• Reporting: Herramientas para generación de listados, etc.
• Analisis OLAP: Exploración, tablas dinámicas, etc.
• EIS: Soluciones que permiten visualizar, de una forma rápida y fácil, el estado de una determinada situación empresarial, presente o pasada, y que permite detectar anomalías o oportunidades.
• DSS: Aplicación informática que basándose en modelos matemáticos y mediante análisis de sensibilidad permite ayudar a la toma de decisiones (What-if?, etc.)
• Data mining (¿o sistemas expertos?): Herramientas diseñadas para resolver problemas concretos que requieran muchos cálculos y análisis . Por ejemplo, una entidad financiera podría tener un ES para valorar la concesión o denegación de un crédito. Otro ejemplo: Un supermercado podría tener una aplicación de “basket analysis” diseñada para detectar productos que se compran conjuntamente.
• KMS: Incipiente tecnología que pretender facilitar el acceso la información corporativa (¡incluyendo la información no estructurada!). Me lo imagino como un "Google" donde poniendo el nombre de la cliente, por ejemplo, devolviese toda la información relevante de ese cliente (últimas compras, documentos donde se hable de dicho cliente, noticias, estado de sus pedidos, etc.).

He intentado ser muy breve en las definiciones. Tal vez en otra ocasión me extienda en las características de cada solución...