En este apartado se muestan todos los artículos sobre Definiciones.
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:
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...

Categoría: Definiciones
Palabras clave: Cuadros de mando
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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:
Categoría: Definiciones
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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:
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...
Categoría: Definiciones
Comentarios: Este artículo tiene 2 comentarios.¡Deja un comentario!
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:
Y tú, ¿A quién darías 3, 2 y 1 punto para quedarse una semana más en el reto blogger?
Categoría: Definiciones
Palabras clave: Excel
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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:
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:
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:
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...
Categoría: Definiciones
Palabras clave: Excel
Comentarios: Este artículo tiene 1 comentario.¡Deja un comentario!
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:
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:
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:
Categoría: Definiciones
Comentarios: Este artículo tiene 4 comentarios.¡Deja un comentario!

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?
Categoría: Definiciones
Palabras clave: Microsoft
Comentarios: Este artículo tiene 6 comentarios.¡Deja un comentario!

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...
Categoría: Definiciones
Palabras clave: Cuadros de mando · Excel
Comentarios: Este artículo tiene 7 comentarios.¡Deja un comentario!

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:
¿Qué os parece? ¿Os suena?
Categoría: Definiciones
Comentarios: Este artículo tiene 4 comentarios.¡Deja un comentario!
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:
Todo lo demás es filosofía (o técnicas de márketing).

Categoría: Definiciones
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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:
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?...
Categoría: Definiciones
Palabras clave: Oracle · Microsoft · SAP · Excel
Comentarios: Este artículo tiene 2 comentarios.¡Deja un comentario!
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:
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.
Categoría: Definiciones
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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?
Categoría: Definiciones
Palabras clave: Cuadros de mando
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
En el mercado de las soluciones BI existen tres tipos de aplicaciones principales:
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.
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:
Este enfoque me gusta porque permite explicar muchas cosas del mundo actual, pero deja demasiadas preguntas sin respuesta:
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.
Categoría: Definiciones
Palabras clave: Cuadros de mando · Excel
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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
Barreras económicas
Barreras culturales
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.

Categoría: Definiciones
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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…
¿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?
Categoría: Definiciones
Palabras clave: Gartner
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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":
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:
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.
Categoría: Definiciones
Palabras clave: Cuadros de mando · Excel
Comentarios: Este artículo tiene 2 comentarios.¡Deja un comentario!
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:
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.
Categoría: Definiciones
Palabras clave: DWH · Cuadros de mando
Comentarios: Este artículo tiene 1 comentario.¡Deja un comentario!
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:
Sin embargo, no todo son ventajas… Estos son algunos de los inconvenientes:
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:
Categoría: Definiciones
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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:
Categoría: Definiciones
Comentarios: Este artículo todavía no tiene ningún comentario.¡Deja un comentario!
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:
He intentado ser muy breve en las definiciones. Tal vez en otra ocasión me extienda en las características de cada solución...
Categoría: Definiciones
Comentarios: Este artículo tiene 2 comentarios.¡Deja un comentario!
Las metodologías Business Intelligence utilizan la información para mejorar la gestión de las empresas.
Gracias al software de BI, los usuarios pueden acceder y analizar los datos con facilidad, y tomar mejores decisiones.