• Arcplan
• Años de 52 semanas
• Un paseo por el mundo de Microsoft Business Intelligence
• Falsas expectativas en proyectos Business Intelligence
• Datos, información y conocimiento
• Usuarios avanzados de Business Intelligence
• Business Intelligence, ¿Por dónde empezar?
• Business Intelligence activo
• Vídeo sobre las novedades de Microsoft BI
• Apesoft creará más de 100 empleos en el próximo año
• Tecnología "in-memory" para el Business Intelligence
• Artículos de Business Intelligence por categorías
• ¿Por qué el Excel sigue siendo la principal herramienta de Business Intelligence?
• Excel me parece una maravilla
• Excel caos 2.0
• Usabilidad en el Business Intelligence
• SAP Business Objects
• Debaeque entra en el capital de Apesoft
• Apesoft
• Breve historia del Business Intelligence
• Cómo no construir un datawarehouse
• Antes de empezar un proyecto Business Intelligence
• Las ecuaciones fundamentales del Business Intelligence
• Billage
• Informes para informar
• Más sobre spreadmarts
• BUSCARV Business Objects
• Spreadmarts
• "¿Problemas tecnológicos? ¿Qué problemas?"
• Trabajadores de la información

Arcplan es una compañía alemana fundada en 1993. Los clientes de Arcplan se encuentran casi exclusivamente en Europa, siendo su presencia en España también significativa. A diferencia de otros proveedores, Arcplan no ha intentado entrar en todos los segmentos del Business Intelligence, y se ha centrado históricamente en sus soluciones de "data visualization" (scorecards, dashboards, cuadros de mando...), sin ofrecer una solución específica ni de reporting ni de análisis OLAP. Esta especialización ha permitido a Arcplan presentarse como un complemento a cualquier otra solución de Business Intelligence que posean sus posibles clientes... Desde hace un par de años -tras la adquisición de LumenSoft- ha ampliado su visión, poniendo el foco también en las soluciones de "performance management" (y centrándose más en los "procesos" que en el "dato")...

Las plataforma principal de Arcplan (Arcplan Enterprise) destaca por las siguientes características:

• Conectividad a prácticamente cualquier fuente de datos, relacional o multidimensional. Destaca especialmente su integración con SAP (y en concreto con SAP NetWeaver BW), por lo que se ha visto en muchas ocasiones como un "front-end" natural en estas instalaciones...
• Facilidad de uso para el usuario final. El resultado de los desarrollos con Arcplan son unos "front-end" muy vistosos y fáciles de utilizar, y así lo valoran sus usuarios...
• Libertad estética. Cada instalación de Arcplan puede ser única, ya que los desarrolladores y diseñadores tienen libertad para rediseñar completamente el aspecto del cuadro de mando hasta el último detalle. Se trata de una característica muy interesante en proyectos donde sea importante una determinada "imagen corporativa".
• Flexibilidad funcional. Es posible construir aplicaciones analíticas complicadas, con cálculos o transformaciones intermedias completamente transparentes para el usuario, e incluso con la posibilidad de realizar escrituras en la base de datos (write-back). Con más o menos esfuerzo, todo se puede hacer.
• Programación gráfica. La manera de desarrollar las aplicaciones de Arcplan es francamente original, y como se ha dicho ofrece una alta flexibilidad estética y funcional. Como contrapartida, sin embargo, suele ser una programación muy poco estructurada, donde abundan las "ideas felices", y donde el resultado puede ser difícil de mantener (mantenimiento costoso).

Su catálogo de productos incluye los siguientes componentes:

• Arcplan Enterprise (antiguamente conocido como Insight/Dynasight): Es la plataforma tradicional de Arcplan para el desarrollo de aplicaciones analíticas, e incluye el "Enterprise Server", los conectores de datos, el diseñador de aplicaciones, y la consola de administración. Os dejo el folleto comercial de Arcplan Enterprise 6, y un diagrama sobre su arquitectura:

• Arcplan Edge: Es el producto de Arcplan para los procesos de Budgeting, Planning y Forecasting. Es una solución relativamente nueva (fruto de la adquisición de LumenSoft). Utiliza el Excel como interfaz para la introducción de datos, y aprovecha los productos tradicionales de Arcplan para publicar la información en un entorno web (reporting, scorecarding, y process monitoring...). Os dejo aquí la información comercial sobre Arcplan Edge.
• Arcplan Excel Analytics: Ofrece algún tipo de integración entre las pantallas de Arcplan Enterprise y las hojas de cálculo de Microsoft Excel...

Para finalizar, os dejo algunos pantallazos de aplicaciones desarrolladas con Arcplan Enterprise...

...y un par de vídeos. El primero sobre Arcplan Enterprise...

...y el segundo sobre Arcplan Edge:

¿Has trabajado con Arcplan? ¿Cómo ha sido tu experiencia? ¿Omite este artículo alguna característica buena o mala relevante? Deja tu comentario. O conoce otros productos Business Intelligence.

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... :-)

Como sabéis, las soluciones de Business Intelligence de Microsoft se centran fundamentalmente en SQL Server (como motor de base de datos) y Excel (como front-end del usuario), además SQL Server incluye una serie de servicios que completan y añaden funcionalidad a esta arquitectura.

El futuro de Microsoft Business Intelligence seguirá basándose en estas dos piezas básicas:

• Excel, con todas sus limitaciones, sigue siendo la herramienta preferida por los usuarios de negocio que deben generar informes, y por aquellos que necesitan analizar la información.
• SQL Server Analysis Services es el motor multidimensional de Microsoft, y proporciona buenos tiempos de respuesta y una estructura jerárquica fácil de utilizar.

A través de SQL Server Sí!, he encontrado un vídeo que hace una introducción de estas tecnologías. Se trata de una sesión que se realizó en el Codecamp 2009, en Tarragona. En el vídeo se muestra cómo se construye un cubo, y se mencionan las problemáticas habituales en los proyectos de Business Intelligence (calidad del dato, dimensión de tiempo, cálculos, etc.).

La presentación está dirigida a usuarios técnicos que no han trabajado con Business Intelligence, o que no conocen las soluciones de Microsoft Business Intelligence. El vídeo está bien, pero el presentador es la bomba. Hace la presentación muy amena gracias a un sin fin de bromas (y otros chascarrillos). Si quieres aprender un poco sobre Analysis Services y/o echarte unas risas, te recomiendo vivamente este vídeo de 1 hora de duración...

Una de los graves errores que se producen durante la fase de venta de un proyecto Business Intelligence son las elevadísimas expectativas que se crean, lo que provoca que los resultados finales se consideren decepcionantes.

Prometer promete cualquiera. Prometemos convertir datos en conocimiento útil (wow!), que todas las consultas irán rapidísimas, que el propio usuario se podrá hacer los informes, que el proyecto estará finalizado en 3 meses, que el caos de ficheros Excel será sustituido por una solución intregrada de acceso y análisis de la información... y como prueba de todo ello presentamos una bonita sonrisa, un traje de 600 euros, y un powerpoint lleno de imágenes espectaculares y una larga lista de referencias (donde siempre está Telefónica, La Caixa y las administraciones públicas, por cierto...).

Si me dieran un euro por cada vez que he oído estas afirmaciones por parte del equipo de ventas, me haría millonario, aunque me arrunaría si tuviése que devolver un céntimo por cada hora extra o por cada promesa incumplida...

No es una práctica novedosa, ni tampoco la hemos inventado nosotros. Son legendarios los vendedores de crecepelos milagrosos, o los zumos de naranja que están hechos 100% de naranja (pero que no saben a naranja). En esta ocasión, me ha llamado la atención el anuncio de la crema rejuvenecedora que encabeza este artículo, y que tuvo que ser retirado fulminantemente por generar falsas expectativas... Y tan falsas, este es el aspecto real de la top model en la actulidad:

Por supuesto, yo no quiero ser un vendedor de crecepelos milagrosos. Creo que la "gestión de las expectativas" es una parte importante de todo proyecto Business Intelligence. Si al iniciar el proyecto se crean unas expectativas irreales, al final, por mucho que se haya hecho, parecerá poco. Es preferible prometer poco, y cubrir las expectativas, e incluso es posible que finalmente podamos entregar un "algo más" que supere las expectativas del cliente...

Sabemos que la materia prima que utilizan los sistemas DSS para la toma de decisiones son los "datos". Sin embargo, no es suficiente. Es necesario aplicar BI. De hecho, muchas veces, para explicar lo que es Business Intelligence se recurre a describir la transformación que sufren los datos brutos hasta convertirse en conocimiento útil.

Es habitual describir los significados de las palabras "dato", "información" y "conocimiento" para evidenciar que es necesario un proceso de transformación de uno a otro, y que mediante estas transformaciones la información númerica va ganando valor (dinero). Y eso es precisamente el Business Intelligence, el uso de nuevas tecnologías para automatizar las transformación del dato en conocimiento útil para la gestión empresarial.

He encontrado un interesante blog que recurre precisamente a este concepto para definir Business Intelligence. Según esta aproximación, el "valor 5000" es sólo un dato, y cuando lo contextualizamos y decimos que son "5000 euros vendidos durante un mes" lo hemos transformado en información, y se convierte finalmente en conocimiento cuando lo comparamos con los meses anteriores, y con la evolución de otros productos y mercados, y nos sirve para mejorar nuestro negocio de alguna manera.

Sin duda, se trata de una visión interesante, aunque la distinción entre dato e información me parece un poco artificiosa. En la vida real, las palabras "dato" e "información" se pueden usar indistintamente, y así lo hago yo mismo habitualmente en este blog (para evitar reiteraciones de una misma palabra, por ejemplo).

La misma idea subyace al hablar del "ciclo de vida de la información", aunque en este caso se enfatiza el hecho de que las acciones que ejecutamos a partir del conocimiento obtenido, proporcionan nuevos datos, que son susceptibles de volverse a analizar, para obtener nueva información y nuevo conocimiento. Se trata del "ciclo virtuoso" del Business Intelligence:

En el mercado actual, las empresas necesitan sacar ventaja de la información que mantienen. Cualquier empresa que pretenda lograr la excelencia y que quiera alcanzar los niveles adecuados de competencia, necesita convertir los datos en conocimiento, analizando y utilizando la información para apoyar la toma de decisiones y la definición de estrategías de negocio, que le permitan diferenciarse de la competencia y, en suma, alcanzar el éxito.

¿Por qué se habla de "usuarios avanzados" cuando se quiere decir "herramientas complicadas"?

Efectivamente, uno de los términos del mundo Business Intelligence que menos me gusta es el de "usuarios avanzados", incluso en ocasiones lo he visto contrapuesto al de "usuarios de negocio".

Los usuarios de Business Intelligence son los trabajadores de la información, y si es necesario segmentar mejor este grupo, o establecer perfiles, deberíamos fijarnos en sus necesidades analíticas.

De esta manera, podemos dividir los trabajadores de la información en tres grupos:

• Jefes
• Analistas
• Estadistas

Esta división es especialmente interesante porque existe una correspondencia bastante exacta con las herramientas disponibles en el mercado:

• Cuadros de mando
• Reporting & OLAP
• Data mining

Reconozco que esta división se puede quedar corta si empezamos a hablar de "Business Intelligence operacional", o si queremos afinar el perfil de un "Product Manager", por ejemplo... ¿Es un "jefe" o es un "analista"? ¿O depende de las funciones que esté desempeñando?

En cualquier caso, ¿Qué diablos es un "usuario avanzado"? Lo único seguro es que el precio de su licencia de usuario será significativamente superior, y probablemente esa etiqueta le vendrá con un "regalo": La posibilidad de encargarse del diseño estético de los informes o los cuadros de mando.

Habitualmente, un "usuario avanzado" puede crear informes, mientras que un "usuario de negocio" sólo puede consultarlos y/o realizar análisis OLAP a través de un cubito o una estructura similar. A veces, los usuarios no-avanzados también pueden crear informes, aunque sencillos, y con las funcionalidades limitadas.

En ocasiones, también se habla de usuarios avanzados de Excel o Word, aunque en este caso se trata de usuarios que conocen y utilizan mejor las funcionalidades que tienen estas herramientas, aunque el software con el que trabajan es exactamente el mismo que el resto de usuarios. En el mundo Business Intelligence no es así; los "usuarios avanzados" utilizan unas herramientas diferentes, más complicadas, más técnicas, menos inteligentes.

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...

En el anterior artículo sobre DSS hablaba del "Business Intelligence activo", y lo definía como un sistema de información que utiliza modelos matemáticos o estadísticos para detectar patrones ocultos; mencionaba los modelos de optimización, proyección y clasificación como algoritmos paradigmáticos que ayudan activamente a la toma de decisiones. Y lo contraponía al Business Intelligence clásico, que sólo ofrece un soporte pasivo.

Al buscar el término en Google, me ha dado cuenta de ser el primero en hablar explícitamente de "Business Intelligence activo"... ¿Realmente es tan novedosa la idea? Bien, en realidad no tanto, Teradata hace tiempo que habla de "Active datawarehousing", y otros emplean la expresión "Pervasive Business Intelligence" para poner connotaciones semejantes.

En realidad, lo que trataba al utilizar esta expresión es quitar la connotación técnica y matemática que se ha formado detrás de todo lo referente a la "mineria de datos". Actualmente, hay que ser un estadista licenciado para sacar provecho a las herramientas existentes (SPSS, SAS, R, S-Puls...). Y, sin embargo, todos podemos entender que es una proyección, una optimización de recursos, o un ABC de clientes... ¿Qué herramientas estándar ofrecen los proveedores de Business Intelligence para este tipo de problemáticas? Nada, o casi nada, con Web Intelligence, con Cognos, o Microstrategy no es posible hacer ni una regresión lineal, y mucho menos una clusterización de clientes... ¡Y luego nos soprendemos que los usuarios prefieran el Excel!

Cuando estos proveedores incorporen estas funcionalidades podremos hablar de Business Intelligence activo.

Hace unos días comentaba como Microsoft Business Intelligence piensa incluir las características de DatAllegro en SQL Server 2008 y de este modo poder competir con soluciones tipo la de Teradata. Está integración forma parte del roadmap que ha planeado para su suite de Business Intelligence. En resumen, las características más interesantes están contempladas dentro de estos dos proyectos:

• Kilimanjaro: Se trata de nuevas funcionalidades que se añadirán a SQL Server 2008 (¿A través de un service pack?) mediante las cuales se pretende otorgar más autonomía a los usuarios de negocio, y mejorar las posiblidades que tienen los usuarios técnicos para administrar el sistema.
• Madison: Se trata de la integración de DataAllegro (compañía adquirida por Microsoft) con el motor relacional de Microsoft SQL. Con el tecnología MPP y el shared-nothing conseguirán sistemas altamente escalables, de alto rendimiento, gran capacidad, y a un coste por Tb reducido.

Es interesante destacar que estos productos (que finalmente tendrán otros nombres) saldrán al mercado a medidados del 2010, es decir, antes que el siguiente major release de SQL Server (SQL Server 2011, o el que sea...)

Sobre Madison, ya comenté algo el otro día, por lo que esta vez me centraré en Kilimanjaro.

Como se puede ver en la imagen, el foco de Kilimanjaro está en mejorar las posibilidades que tiene el usuario final para construir sus propios informes, con menor dependencia de IT. Una de las claves será el add-in de Excel denominado PowerPivot, y se caracterizará por su integración con Excel 2010 (como no podía ser de otra manera), el uso de tecnología BI in-memory, y la integración con Analysis Services y Sharepoint... Esto permitirá utilizar una tabla dinámica contra los datos de Analysis Services (¡pero con los datos comprimidos en el PC cliente!) y publicarlo en formato report. Observad esta imagen que pulveriza la limitación de 65.000 filas de Excel 2003 (o la de 1 millón de filas de Excel 2007):

Seguiremos atentos, después de lo de PerformancePoint (recordad), Microsoft no se puede permitir más titubeos. Yo creo que Kilimanjaro-Gemini-Madison pinta bien, aunque le encuentro a faltar la posibilidad de atacar directamente a un modelo relacional (prescindiendo de los cubos de Analysis Services). En fin, esteremos atentos...

Ah, os dejo el vídeo sobre el roadmap de Microsoft Business Intelligence que prometía el título de este artículo. Dura 55 minutos.

Como ya comenté, una compañía de capital riesgo ha aportado financiación por valor de 2,75 millones de euros a Apesoft, el principal proveedor español de soluciones Business Intelligence.

Entonces comentaban que con esta inversión esperaban convertir en realidad "muchas ideas" que tenían y, en concreto, querían invertir en I+D, para potenciar sus herramientas y añadir nuevas soluciones a su portafolio.

Ahora he leído en un portal de empleo que Apesoft creará más de cien empleos en los próximos doce meses.

Está claro es que se inicia un interesante periodo de cambios y novedades en Apesoft, aunque también me surge la duda de cómo afectará esto a los proyectos que tengan en marcha, o que estén a punto de comenzar. En el futuro, ¿Se seguirán focalizando en el Excel como frond-end? ¿apostarán por sus soluciones de planning? ¿O potenciarán la consultoria y los desarrollos a medida? Si alguien tiene ocasión de asistir al próximo congreso al que asistirá Apesoft, que se lo pregunte y que nos lo cuente en los comentarios.

En mi anterior artículo comentaba la relevancia que le están dando los proveedores de Business Intelligence a la tecnología "in-memory".

A través de Information Week, he sabido que el nuevo producto de SAP (SAP Business Objects Explorer) también utiliza esta técnica para ofrecer unos mejores tiempos de respuesta.

Creo que la idea es interesante y hemos estar atentos para ver su evolución. Sin embargo, de entrada, le veo algunas "pegas".

Principalmente, considero que los proveedores de bases de datos (Oracle, SQL Server, Teradata...) tienen unos productos excelentes, altamente optimizados, robustos, y que pueden gestionar volúmenes de información grandes y pequeños. También disponemos de bases de datos multidimensionales. ¿Realmente QlickView, Microstrategy o BO deben reinventar la rueda para ofrecer una manera mejor de realizar consultas? ¿A qué aspectos estaremos renunciando? Se me ocurren los siguientes:

• Volumen de información. Evidentemente, estos sistemas "en-memoria" estarán limitados en la cantidad de información que pueden gestionar. Aunque, de todos modos, es cierto que ni todos los datawarehouse tienen decenas de teras, ni las consultas habituales requieren todo el detalle de información.
• Modelo de datos. El modelo de datos de estos sistemas es extremadamente sencillo, no se defienen ni índices, ni relaciones, ni nada. En teoría, todo está optimizado. Sin embargo, ¿Puede nuestro modelo de negocio modelizarse de una manera tan sencilla? ¿Realmente podemos prescindir de relaciones n-m? ¿Todo puede incluirse en una sola tabla de hechos? Mi experiencia dice que no, y que las "consultas habituales" requieren modelos de datos más complejos. Y si no fuera asi, ¡¡Ya tenemos los cubos multidimensionales!! ¡¡Que sí que ofrecen respuestas instantáneas para un volumen de datos moderado!!

Mi conclusión es que estas soluciones pueden complicar un catálogo de productos ya excesivamente complejo, y que pueden generar nuevos problemas (duplicación de información y procesos, básicamente).

En los comentarios del artículo de Information Week alguien hacia algunas reflexiones interesantes:

I regularly hear the MPP database vendors bat down in-memory solutions as a transitory bump-up in scalability and performance, effective for now, but not on a long-term roadmap. They contend that when the data volumes and analytics workloads inevitably grow, in-memory hardware becomes less practical and economic, and ultimately has scalability limits. Of course, as SSDs become more economical and replace conventional disk drives, then MPP database vendors will become on a larger scale closer to what in-memory solutions provide now on a smaller scale. -–Mike

Efectivamente, los dispositivos en estado sólido (SDD) están a punto de revolucionar la tecnología del almacenamiento. De hecho, Teradata ya los incluye en su "roadmap"... Estos dispositivos de almacenamiento usan memoria no volátil tales como flash para almacenar datos, en lugar de los platos giratorios encontrados en los discos duros convencionales, por lo que su lectura es mucho más rápida. ¿Afectará esto a la naciente tecnología "in-memory"?

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

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

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

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

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

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

Encuentro a menudo literatura sobre BI que cuenta las maravillas del mundo web, y se suele dar por hecho que cualquier solución Business Intelligence debe tener necesariamente una arquitectura web. Hoy en día, todos los fabricantes de BI tienen su suite web, y es la única en la que siguen invirtiendo y potenciando...

Yo discrepo respecto este punto. ¿Qué importancia tiene para el usuario que su solución Business Intelligence sea web o desktop? Desde el punto de vista del usuario, ésa es una cuestión irrelevante. Lo importante es que tenga la funcionalidad y usabilidad requerida. La Web está muy bien, sí, pero por razones meramente técnicas (más fácil de instalar, actualizar, etc.).

Sin embargo, el coste que pagamos por utilizar aplicaciones Web es realmente alto. Se pierde –y mucho- en usabilidad y rapidez (también ha desaparecido la posibilidad de trabajar off-line). Las aplicaciones BI tradicionales han invertido millones en migrar a arquitecturas web, y ahora tienen una funcionalidad casi parecida a la que ya tenían sus versiones cliente-servidor 10 años antes.... ¿Realmente ha merecido la pena este viaje?

La aceptación global de la arquitectura basada en servicios (SOA), que define protocolos estándar para la comunicación de aplicación a aplicación, ha cambiado los paradigmas de desarrollo del software. La arquitectura SOA centraliza en un único punto la seguridad, el acceso a datos y la lógica de negocio, y permite que los distintos clientes (desktop, web, iPhone…) aprovechen sus características. Las ventajas de este paradigma se deberían reflejar en las herramientas y las tecnologías que los proveedores de software ofrecen (y los de BI en particular), y no está siendo así. El cliente desktop ha desaparecido de facto de sus portfolios, y se está renunciando a las ventajas inigualables que ofrece este entorno de trabajo.

Tal vez alguno crea que con este artículo estoy yendo contracorriente, yo pienso que hemos aceptado como dogma la arquitectura web, sin valorar convenientemente los pros (que son muchos) y los contras (que son bastantes)... Por ejemplo, en nuestra empresa, ¿Por qué no utilizamos un cliente web para enviar y recibir nuestros emails (¡¡los emails!!)? ¿Por qué los usuarios siguen prefiriendo el Excel como herramienta analítica?

No. La frase no es mía.

Y no me la tatuaría en el brazo. La he leído en el blog de un consultor y que por su intertés reproduzco íntegramente:

A Microsoft se le critica casi como deporte no nacional, sino mundial. Su software es malo, su posición es monopolística, tal, cual… pero me gustaría romper una lanza a su favor por haber desarrollado una maravilla como Excel.

No sé cuánto de otros habría en Excel. No sé si se habría basado en otras hojas previas (Lotus 1-2-3 y similares), o si se la han inventado ellos. Pero el hecho es que ahí está, como estándar de facto en materia de hojas de cálculo. ¡Y qué estándar!

De Excel me fascina, sobre todo, su versatilidad. Tengo la sensación, al usarla, que puedo hacer prácticamente de todo con ella. Cualquier cosa relacionada con datos y cifras relacionados, gráficos, etc. Es una herramienta fundamental para el análisis, y llego a creer que cualquier funcionalidad de un paquete de software estándar puede ser reproducida (y mejorada y ampliada) utilizando Excel.

Lógicamente, no es una herramienta fácil de explotar hasta sus últimas consecuencias. La multiplicidad de herramientas y funciones que tiene hacen que, para un “novato”, resulte complicado avanzar. Además, para utilizar la hoja de cálculo, hace falta pensar como ella, organizar la información de la forma adecuada y entender cómo la va a tratar, porque si no puede llegar a ser un caos. Desde luego, nada que se pueda poner en manos de la gente que quiere, simplemente, darle a un botón y “ya está”.

Pero para quienes, como yo, disfrutan explorando nuevas funciones, planteando de qué forma se pueden resolver los problemas que van surgiendo, adaptar las soluciones a las necesidades concretas y detalladas que cada uno tiene… esta herramienta supera con creces cualquier paquete con opciones “predefinidas”. Por muchas que traiga, siempre podrás hacerte el traje más a medida.

Claro, los defensores de la estandarización (que entiendo que también tiene sus ventajas, desde la facilidad de uso a la integridad de soluciones entre distintos usuarios) dirán que Excel es el demonio con cuernos. No sé, puede ser. Pero este demonio me permite sentirme poderoso.

Este enamorado del Excel destaca la versatilidad de la herramienta y su potencia. Observad como no menciona su facilidad de uso. Yo añadiría alguna otra cosa:

• En comparación con las herramientas BI, el Excel aporta la posibilidad de completar el informe con datos que no se encuentran en los sistemas informáticos de la compañía.
• Todo el mundo lo conoce. Es fácil compartir el informe Excel con cualquier compañero, cliente, o proveedor. Incluso el Director General puede abrirlo y analizarlo tranquilamente, y no debo preocuparme si tendrá una cuenta de usuario o los conocimientos necesarios sobre la suite de BI de turno.
• Existe otra diferencia que solemos olvidar y que creo que resulta clave para entender su éxito: Excel no es una aplicación web, es una herramienta de escritorio que aprovecha toda la potencia de los "desktop" de los usuarios, eso le otorga una velocidad y una usabilidad inimaginable aún en una aplicación web. Excel no se cuelga. Es rápida. No se pierde tiempo accediendo a un portal web, conectándome, navegando, y confiando que otros usuarios no estén compitiendo por los recursos del servidor web...

Todas las compañía de BI presumen de su "integración con Excel" y en la mayoría de las ocasiones eso quiere decir que los informes generados se pueden exportar a Excel. Una verdadera integración requeriría más, en mi opinión. Se debería poder desarrollar el informe directamente desde el Excel, y la información que se introdujese en el Excel se debería almacenar en una base de datos para su posterior explotación. Vaya, vuelvo a estar hablando sobre los "spreadmarts"...

Una asignatura pendiente de las soluciones BI es la lucha contra la proliferación de Excels. Hemos reconocer que, a pesar de las grandes inversiones en software y hardware, el Excel sigue siendo el rey en muchas empresas.

Tradicionalmente, hemos vendido proyectos datawarehouse y Business Intelligence como una medida para erradicar los problemas generados por el uso intensivo del Excel. Al trabajar con Excel, los usuarios duplican y manipulan la información, la comparten, mezclan información de diferentes fuentes, filtran, completan, ajustan, y aplican criterios que sólo ellos mismos conocen. El resultado de esta manera de trabajar es por todos conocido:

• La información nunca cuadra, cada departamento y cada usuario trabaja con unos números diferentes, diferentes entre sí, y diferente con los que devuelve el ERP corporativo.
• Otro inconveniente fundamental de esta manera de trabajar es el esfuerzo que requiere mantener los informes actualizados. Cada semana los datos cambian, por lo que se deben realizar nuevas extracciones de los sistemas informáticos, y recocinar los informes en Excel. Es un trabajo periódico (además de aburrido y proponeso a errores) que implica muchas horas de muchos recursos.

Este problema se soluciona con un datawarehouse y con una herramienta de BI, ¿verdad? Pues no exactamente...

No soy el primero en preparar un diagrama de este tipo para representar lo que se conoce como "excel caos":

Medio millón de euros después, la situación no ha cambiado mucho:

Evidentemente, el datawarehouse es una mejora importante en los sistemas informáticos de la empresa, y así se suele reconocer en la mayoría de implantaciones. El datawarehouse mejora la disponibilidad y la calidad de la información corporativa. Sin embargo, solemos pasar de puntillas sobre la promesa de erradicar el Excel caos.

Después de implantar un datawarehouse y una herramienta de BI, es común que los usuarios sigan prefiriendo el Excel para preparar y presentar sus informes. Innumerables instalaciones de los principales proveedores de BI (y no diré nombres por si alguno de mis queridos lectores trabajan en BO, Microstrategy o Cognos), utilizan la solución de reporting BI para generar la query, ejecutar la consulta, y exportarla rápidamente a Excel.

¿Por qué la funcionalidad más querida por los usuarios es la exportación a Excel? ¿O tal vez estoy exagerando?

Ocurre en todas las empresas: Independientemente de que trabajen con Business Objects, Microstrategy, Cognos o Microsoft, sólo los usuarios más expertos pueden sacar todo el provecho de la información, mientras que los demás se tienen que conformar con acceder a la información desde la herramienta BI corporativa, y exportarla en Excel. ¡Viva los spreadmarts!

Me ha gustado leer el siguiente comentario de Alfonso Royo, director de BI de IBM Cognos:

Aprovechar el potencial de sus datos sigue siendo una de las asignaturas pendientes para muchas empresas, a pesar de las fuertes inversiones realizadas en los últimos años para modernizar sus sistemas de Tecnologías de la Información (TI). Los enfoques más simples suelen ser el camino más corto hacia el éxito. En la última década, los ejemplos de productos tecnológicos sencillos que han alcanzado una enorme difusión entre los usuarios son numerosos.

La búsqueda por internet, el iPod o la mensajería instantánea, por ejemplo, demuestran el poder de la usabilidad, sin perder las funcionalidades sofisticadas que demandan los usuarios para ver, oír o experimentar los diferentes contenidos. Este mismo enfoque, combinando sofisticación y sencillez, puede aplicarse al despliegue de soluciones de business intelligence (BI) y gestión del rendimiento.

Es una visión que comparto completamente. A pesar de todas las promesas, los índices de usabilidad de las herramientas Business Intelligence dejan mucho que desear.

No comporto la solución, sin embargo. En lugar de simplificar lo que tienen, están sacando nuevos productos o creando nuevos interfaces. ¿Realmente la prioridad es el acceso desde un dispositivo móbil? ¿Realmente son estos los requerimientos prioritarios de las empresas? ¿Es imprescindible que reporting y dasboarding tengan dos front-ends completamente diferentes?

En el citado artículo, Alfonso Royo habla de “interfaces basadas en roles”, y entiendo que eso quiere decir que cada usuario tendrá un interfaz diferente según sus necesidades y su perfil... No me gusta la idea. ¿Por qué no pueden todos los usuarios tener un interfaz amigable y potente? (nota mental: La peor parte, como de costumbre, se la llevarán los técnicos).

Desde mi punto de vista, la referencia deberían ser el iPod, las herramientas ofimáticas, o las comunidades online (Messenger, Facebook, Blogger, ...). Todas estas herramientas han ganado en usabilidad y funcionalidad al mismo tiempo (y sin duplicar o triplicar los interfaces). ¿Pensáis que esto es posible en el mundo Business Intelligence?

SAP Business Objects es el proveedor líder según los últimos estudios. Tiene entre el 20% y el 25% de cuota del mercado Business Intelligence, con unos 42.000 clientes.

Business Objects era una empresa francesa fundada en 1990 que ofrecía soluciones de análisis y reporting. Rápidamente, gano presencia en el mercado BI que se estaba creando, y se convirtió en una referencia clave en este tipo de soluciones.

En 1997 sacó al mercado Web Intelligence, que desde un entorno web ofrecía prestaciones similares a las de su producto cliente-servidor (Desktop Intelligence). A partir del 2001, se fue de compras con el objetivo de completar su catálogo de soluciones. De este modo, adquirió Blue Edge, Acta Technolgies,Crystal (2003),SRC,ALG software, Nsite,Xcelsius (2006), entre otros). La mayoría de estos productos formaron parte del catálogo de productos de BO, pero finalmente fueron discontinuados (con las excepciones de Crystal y xCelsius).

A principios del 2008, SAP fue quien se fue compras y adquirió BO por 4.700 millones de euros, y en principio seguirá operando como un negocio independiente de SAP (lo que quiere decir que será una línea de productos más, aunque ha mantenido el nombre, pero no así su imagen corporativa).

SAP tiene una ventaja muy importante, y es que es capaz de vender sólo por el nombre, donde otros proveedores necesitan innumerables demos, un comercial de SAP puede vender con su tarjeta de visita. Además, ahora, tiene un buen producto de Business Intelligence.

Actualmente, el portfolio BI de SAP incluye:

• SAP BO Web Intelligence (o Webi): Es el producto principal de Business Objects. Proporciona un metamodelo de la información corporativa (le llaman “universo”) que permite a los propios usuarios construir informes de manera sencilla. Los informes generados pueden ser tan sencillos o complejos como se quiera, y por supuesto dispone de opciones para distribuir la información entre los usuarios y exportarlos a Excel. Se trata, sin duda, de un muy buen producto de query, reporting y análisis.
• SAP BO Desktop Intelligence: Es la versión cliente de Webi, y apenas ha cambiado desde 1997. BO ya ofrecía un buen producto entonces.
• SAP BO Live Office: Es un complemento de Excel que permite la integración de la información del universo de BO con la hoja de cálculo. Es decir, se puede generar una consulta utilizando el universo, y volcar el resultado en Excel.
• SAP BO Crystal Reports: Permite también la generación de informes corporativos a partir de cualquier fuente de información (y no únicamente desde el “universo” de BO). A diferencia de Webi, está enfocado a un perfil específico de “diseñador de informes”, más técnico, con muchas más opciones para personalizar la apariencia del resultado (y menos opciones para analizarla). Se integra muy bien con las diferentes suites de desarrollo (Visual Studio .Net, Java, etc.).
• SAP BO xCelsius: Permite crear dashboards, cuadros de mando o visualizaciones impactantes de cualquier información. El resultado son “flash” muy atractivos e interactivos (incluyen diferentes tipos de gráficos, tablas, etc.). El desarrollo del cuadro de mando requiere conocimientos técnicos, por lo que típicamente se hace desde el departamento de IT.
• SAP BO Explorer: Una nueva herramienta (otra) para analizar y explorar la información. Se trata de un "buscador empresarial" donde el usuario puede buscar sin conocer demasiado la estructura o el tipo de documentación disponible sobre un determinado tema. Se trata de un tipo de solución novedosa que habrá que ver como acoge el mercado...
• SAP BO Voyager: Navegación por cubos OLAP con funciones específicas para los departamentos de finanzas
• SAP BO Set Analysis: Ayuda a definir y crear segmentos a partir de un “data set” (para segmentación del Mercado, análisis ABC, etc.). Una vez segmentada la información, proporciona diferentes maneras para analizarla.
• SAP BO Dashboard Builder: Es el producto tradicional de cuadros de mando de Business Objects. Creo que han dejado de potenciarlo en favor de xCelsius.
• SAP BO Performance Manager (¿Strategy Managment?): Es el producto tradicional de performance management (BMP) de Business Objects. Facilita la definición de objetivos y estrategias, y permite el seguimiento y análisis de los diferentes KPI corporativos. Utiliza xCelsius como visualizador (desconozco el grado actual de integración).
• SAP BO Data Integrator: Herramienta ETL de BO.

Llama la atención que a su suite de productos le llaman “Intelligence plataform”, y que ofrecen una visión “unificada del negocio” a través de una “plataforma única e integrada”. Analizando su catálogo de productos, sin embargo, debemos entender estas afirmaciones como propias del lenguaje comercial.

Para finalizar, os dejo algunas demos y otra documentación sobre SAP Business Objects...

La siguiente aplicación "flash" desarrollada con xCelsius muestra el nivel de dinamismo y la apariencia de este tipo de soluciones SAP Business Objects:

En la página de SAP se pueden encontrar otras demos de xCelsius, aunque con similar apariencia y funcionalidad.

El siguiente vídeo muestra cómo se construye un informe con SAP BO Web Intelligence:

Y aquí dejo también algunos "White papers" sobre los distintos productos de SAP que comentaba anteriormente:

• SAP Business Objects Web Intelligence
• SAP Business Objects xCelsius 2008
• SAP Business Objects Dashboard Builder
• SAP Business Objects Performance Manager
• SAP Business Objects Data Integrator
• SAP Business Objects Explorer(vídeo YouTube)

¿Has trabajado con Business Objects? ¿Cómo ha sido tu experiencia? ¿Omite este artículo alguna característica buena o mala relevante? Deja tu comentario. O conoce otros productos Business Intelligence.

Hoy estoy perezoso, por lo que me limitaré a reproducir la interesante noticia que os comentaba ayer sobre las intenciones de crecimiento y expansión de Apesoft. Hablan de ampliar la plantilla en 80 personas, por lo que me imagino que tendrán importantes (e interesantes) proyectos en marcha. Buena noticia para el Business Intelligence, sin duda.

Con cuentagotas y a una escala más modesta, las firmas de capital riesgo siguen cerrando operaciones de inversión en el mercado catalán a pesar de la crisis económica.

Una de las últimas transacciones es la protagonizada por la gestora independiente Debaeque Venture Capital, que acaba de aumentar su cartera de participadas en el sector del software con su entrada en Apesoft, compañía con sede en el Parc Tecnológic del Vallès, en Cerdanyola (Vallès Occidental).

La aportación de nuevos recursos permitirá respaldar el desarrollo de la firma en EEUU

Debaeque ha cubierto una ronda de financiación de 2,75 millones de euros en Apesoft, que le otorga alrededor del 50% del capital. El fundador de la compañía, Jaume Juan, controla el resto junto a accionistas minoritarios.

Fundada en 1994, Apesoft está especializada en soluciones de software para business intelligence dirigidas a empresas e instituciones de diferentes tamaños.

La empresa opera en diez países de todo el mundo a través de una red de distribuidores y dispone de oficinas propias en Estados Unidos. Precisamente, el desarrollo de Apesoft en el mercado estadounidense es uno de los objetivos de la ronda cubierta por Debaeque.

La firma catalana está experimentando un fuerte ritmo de crecimiento. El año pasado alcanzó una cifra de negocio de 1,7 millones de euros, un 40% más que en 2007, con un beneficio neto de 150.000 euros. Las previsiones para 2009 apuntan a un incremento de la facturación del 64%, hasta 2,8 millones de euros, gracias a la expansión de la firma en los mercados internacionales, como EEUU.

Para hacer frente a su crecimiento, Apesoft, que tiene ahora una veintena de empleados, prevé crear cien puestos de trabajo en los próximos doce meses.

Apesoft incrementó su facturación un 40% el pasado año y en 2009 prevé crecer un 64%

Apesoft cuenta con 6.000 usuarios de 250 empresas e instituciones. Su producto estrella es DataCycle Reporting, un software que permite consultar y extraer directamente los datos del sistema de gestión corporativo y de las bases de datos de la empresa, integrando y formateando la información en informes que aprovechan las posibilidades de Excel.

Jaume Juan, fundador y director general de la firma, destacó el perfil de “inversores de alto valor añadido” de los nuevos socios y dijo que la ronda de financiación contribuirá a acelerar la expansión en todo el mundo.

Para Debaeque, cuyo primer ejecutivo es Patrick Raibaut, la entrada en el capital de Apesoft fortalece la posición de la gestora barcelonesa en la industria española del software.

En este sector, el grupo inversor está presente en otras dos firmas catalanas: NTRglobal y Oasyssoft. Debaeque gestiona tres fondos de capital riesgo y, al margen del negocio del software, participa en otras tecnológicas, como Lemonquest y Kimia.

Apesoft es el principal (¿el único?) fabricante español de software de Business Intelligence. Se fundó en 1994 a partir del producto que desarrollaron en una empresa cliente. Tenían un buen producto que permitía la generación de informes en Excel a partir de información almacenada en base de datos. En aquellos tiempos, esto era todo un logro, por lo que decidieron crear la empresa y ofrecer su producto a otras empresas. Actualmente, tiene una veintena de empleados y factura cerca de dos millones de euros al año.

Recientemente (julio 2009), según he leído en Expansión, una empresa de capital riesgo ha entrado en la compañía, con una participación cercana al 50%. Apesoft está teniendo un fuerte crecimiento, de hecho, están presentes en más de una decena de países y están empezando su expansión en Estados Unidos (de ahí la necesidad de capital).

Sus principales productos son:

• Apesoft Datacycle Reporting: Que permite generar informes en Excel a partir de una consultas predefinidas
• Apesoft Datacycle Planning: Que permite la gestión del flujo de cualquier proceso de presupuestación, también desde un entorno 100% Excel.

Tienen otros productos igualmente interesantes. Los principales puntos fuertes son siempre su buena integración con Excel, y la posibilidad de automatizar y distribuir dichos informes. Los usuarios de negocio conocen el Excel, y lo siguen prefiriendo para muchas de sus actividades diarias.

Y la principal desventaja es también el Excel. En ocasiones, es necesario incluir macros en sus informes o dashboards, con los problemas de mantenibilidad que eso implica. Los que hayáis utilizado VBA sabréis que el entorno de desarrollo de macros no es idílico...

Sus productos son una buena solución a PYMES o incluso en proyectos departamentales de grandes empresas. Además, su licenciamiento es independientemente del número de usuarios finales de los informes (¡son sólo usuarios de Excel!), por lo que el software se puede reutilizar fácilmente en otros proyectos inicialmente no previstos.

No he encontrado ningún vídeo en YouTube, así que únicamente puedo compartir este flash para que veáis el aspecto que pueden tener los dashboards creados con Apesoft:

Por cierto, a modo de curiosidad, me ha llamado la atención que en su página web enfocada al público español destacan el hecho de ser una empresa 100% española, mientras este hecho es ignorado en la página dedicada al público americano. De hecho, comercialmente, creo que sería positivo para ellos crear una sociedad en San Diego (California) y presumir de ser un software americano. Incluso en España lo veríamos como algo positivo. Somos así de tontos. :-)

¿Has trabajado con Apesoft? ¿Cómo ha sido tu experiencia? ¿Omite este artículo alguna característica buena o mala relevante? Deja tu comentario. O conoce otros productos Business Intelligence.

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?...

A través de TodoBI he encontrado un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse.

Se trata de un artículo excelente. Cada vez que he cometido alguno de estos errores, he tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien desde el principio.

Los doce errores más comunes en la construcción de un datawarehouse son:

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

En mi vida laboral he participado en la construcción de varios datawarehouses, y he visto muchos de estos errores. Durante los próximos días, analizaré una a una estas recomendaciones de Kimball, e intentaré justificar por que son errores graves y cómo debemos evitarlos.

A mis lectores menos "tekies", os pido perdón porque los próximos mensajes no los escribo pensando en vosotros. Van dirigidos al lado oscuro... :-)

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.

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.

Sólo los más observadores habrán visto que entre los links de la izquieda hay una novedad: Billage. Se trata de una comunidad de interesados en el Business Intelligence promovida por la UOC. No tengo claro si la participación está reservada a alumnos y ex-alumnos de la UOC, o si por el contrario está abierta a toda la comunidad BI. En cualquier caso, me parece una iniciativa excelente.

La Universistat Oberta de Catalunya (UOC) ofrece masters y postgrados en el ámbito BI, y creo que tienen bastante éxito. Yo mismo realicé uno de estos posgrados hace unos años, y fue una experiencia enriquecedora. Algún día me gustaría terminar el master. Aclaro -para los más mal pensados- que no cobro nada por escribir esto (y aclaro también que es una desgracia que así sea, y que no me importaría que me regalasen la matrícula para el próximo curso, o por lo menos unas vacaciones en Hawaii...).

Billage se acaba de fundar y, actualmente, está bastante despoblado. Tiene un par de blogs, y unos foros con poca participación. Habrá que ver cómo evoluciona. Al contar con el apoyo de la UOC, creo que tiene posibilidades de convertirse en un foro de referencia importante.

Un saludo,

Bi fácil

PD: Quería poner el link al master de BI pero no he sido capaz de encontrarlo. ¿Es que ya no se hace? ¿O sólo se publicita durante el periodo de matriculación?

Un amigo me ha hablado del Dr. Rolf Hichert, uno de los principales especialistas en el diseño y comunicación de información empresarial. Siempre he admirado la gente que puede vivir de dar conferencias, pero en este caso se da la extraña circunstancia que el tipo sabe perfectamente de lo que habla.

Los informes sobre gestión y las presentaciones empresariales son, junto con las conversaciones personales, los medios más importantes para transmitir los datos deseados a los directivos. Hichert en sus conferencias realiza una serie de recomendaciones (¡llenas de sentido común!) sobre el fondo y la forma que deberían tener estos documentos. De todos modos, sus reglas son fácilmente exportables a cualquier otro tipo de comunicación.

Entre sus trabajos destacan las “normas para realizar presentaciones de éxito”, y que se deletrean S-U-C-C-E-S-S:

• Say it: Decir lo que se debe decir
• Unify it: Estandarizar el contenido. Lo que tiene el mismo aspecto, debe tener también el mismo significado, y al revés
• Condense it: Una amplia densidad informativa facilita la comprensión
• Check it: Exigir exactitud
• Explain it: Proporcionar explicaciones
• Simplify it: Simplificar la presentación. Evita ruido y redundancias.
• Structure it: Estructurar, ordenar, clasificar.

Evidentemente, esto está íntimamente relacionado con el mundo del Business Intelligence donde el “reporting” juega un papel principal. Siempre me ha llamado la atención que un informe de BI casi nunca puede entregarse tal cual. Siempre es necesario exportarlo a Excel o cortarlo-y-pegarlo en un Powerpoint o en un Word… ¿Por qué no pueden completarse los informes (añadiendo el “mensaje”, proporcionando las pertinentes explicaciones, etc.) desde la misma herramienta de Business Intelligence? ¿Por qué se exige la integración con Excel y no se habla de la integración con Word? ¿Por qué decimos integración cuando en el mejor de los casos es una mera exportación?

Muchas preguntas. Ya no tengo claro cuál es el mensaje de esta entrada del blog. ¡Que me perdone el profesor Hichert!

Un saludo,

BI fácil

Hace unos días ya hablé sobre los spreadmarts. La palabra spreadmart sale de mezclar los "spreadsheets" con los "datamarts". Y el resultado, como comentaba en la otra ocasión, son aplicaciones en Excel que resultan problemáticas.

Actualmente, existen pocas soluciones perfectas ante este problema, y sólo se justifica su migración a otro entorno cuando la información contenida en los spreadmarts es realmente vital para el negocio y/o cuando genera un trabajo inasumible para los departamentos de negocio.

Creo que las mejores herramientas que existen actualmente para abordar este problema son las bases de datos multidimensionales (o cubos MOLAP). Los cubos proporcionan una visión muy fácil y dinámica de la información, y suelen tener una muy buena integración con Excel. Herramientas de este tipo son Microsoft Analysis Services, Infor Alea, PALO, o Oracle Essbase.

Pero tampoco son siempre la solución ideal. La información que se codifica en los "spreadmarts" no siempre cabe fácilmente dentro del cubo. Dependerá del proyecto...

He encontrado un artículo sobre los spreadmarts que creo que aporta una visión muy acertada y que comparto. Los spreadmarts están para quedarse. Pronostica que en el futuro aparecerán soluciones tecnológicas que resolveran la problemática mejor de lo que se está consiguiendo actualmente:

"However, imagine a data tool in which the end-user experience feels like a spreadsheet and the back end feels like a database--and includes some of the more traditional database features, such as security, scalability, versioning, multi-user access, rapid searching, and all of the rest of the features that database traditionalists have come to know and love? What if someone figured out a way to take the best parts of a spreadsheet and merge it with the best parts of a database by using new data-persistence technologies that might not even have been invented yet?"

Un saludo,

BI fácil

PD: ¿Soy el único que piensa que es complicado poner imágenes (con el tamaño deseado) utilizando blogger?

Me ha llamado la atención que varias personas han llegado a este blog después de buscar en Google "BUSCARV Business Objects"...

Supongo que serían usuarios de Excel que querrían saber la manera de hacer este tipo de búsquedas con esa herramienta de Business Intelligence. Y las respuesta es que no existe una función análoga, y que de hecho no es necesaria. Intentaré explicar por qué.

En primer lugar, es importante tener claro cómo funciona Excel, y cómo funcionan las herramientas tipo Cognos, Business Objects, o Microstrategy

En Excel la información se almacena en las celdas. Y se almacena de una manera bastante desordenada. Es decir, la aplicación Excel no sabe que la casilla D7 contiene las ventas de España, eso lo interpreta al usuario al mirar las celdas que rodean a D7...

En Excel, no existe diferencia entre los datos y las tablas. Y la manera de referirse a la información es indicando la posición de cada dato. Por ejemplo, si quiero saber los ingresos de España deberé pedirle a Excel que calcule D7*E7

En las herramientas de Business Intelligence esto funciona de una manera muy diferente. Es importante entender esta diferencia:

• Una cosa son los datos que disponemos para hacer el informe (se suele llamar "cubo")
• Y otra cosa muy distinta son las tablas o gráficos que construimos con esos datos

El "cubo" es una estructura invisible donde los datos están perfectamente ordenados en dimensiones (país, producto, tiempo...) e indicadores (unidades, precio...).

Cada tabla y cada gráfico es sólo una representación de ese "cubo". A diferencia de Excel, las tablas y gráficos no buscan los datos en otras tablas y gráficos, sino que siempre van a buscar los datos al "cubo". Por lo tanto, en lugar de apuntar a posiciones concretas del informe (D7*E7), se apunta al dato del cubo que queremos obtener [Unidades vendidas]*[Precio]) Donde ([País]="España").

Al usuario avanzado de Excel esto puede parecerle un inconveniente y una complejidad innecesaria. Sin embargo tiene una ventaja que por si sola justifica el esfuerzo de aprender la sintaxis de la herramienta BI que se utilice...

Hacer un primer informe con una herramienta de BI es complicado, tal vez más complicado que con Excel. Sin embargo, ese informe se podrá reutilizar indefinidamente. Cada semana, cada mes, o siempre que lo necesites, el informe estará actualizado y con la información correcta. En cambio, si se hace el informe en Excel, deberá actualizarse cada vez, deberán revisarse la fórmulas, añadir nuevos países o productos, repasar cada tabla y gráfico del informe... en definitiva, una tarea repetitiva que requerirá un tiempo considerable y que será muy propensa a errores...

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

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

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

Sin embargo, si existen, será por algo:

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

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

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

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

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

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

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

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

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

Otro interesante artículo de Gartner. En esta ocasión, Gartner presenta los 9 errores falates de un sistema BI… Destaco los siguientes puntos:

Flaw No. 3: "Data quality problem? What data quality problem"

Data quality issues are almost ubiquitous and the impact on BI is significant — people won’t use BI applications that are founded on irrelevant, incomplete or questionable data. To avoid this, firms should establish a process or set of automated controls to identify data quality issues in incoming data and block low-quality data from entering the data warehouse or BI platform.

Flaw No. 4: "Evaluate other BI platforms? Why bother"

"One-stop shopping" or buying a BI platform from the standard corporate resource application vendor doesn’t necessarily lower the total cost of ownership or deliver the best fit for an organisation’s needs. BI platforms are not commodities and all do not yet deliver all functions to the same level, so organisations should evaluate competitive offerings, rather than blindly taking the path of least resistance. Integration between the application vendor’s ERP/data warehouse and BI offerings is not a compelling reason for ignoring alternatives, especially as many third-party BI platforms are as well integrated.

Flaw No. 6: "Let’s just outsource the whole darn BI thing"

Managers often try to fix struggling BI efforts by hiring an outsourcer that they expect will do a better job at a lower cost. Focusing too much on costs and development time often results in inflexible, poorly architected systems. Organisations should outsource only what is not a core competency or business and rely on outsourcing only temporarily while they build skills within their own IT organisation.

Con las demás no estoy completamente de acuerdo, ya que asumen que los problemas no suelen ser tecnológicos. Seguramente será que han preguntado a los departamentos de IT… Yo creo que muchas veces el problema sí que es tecnológico y de las herramientas BI, y que los usuarios no son tontos al preferir el Excel.

Que en muchas ocasiones los problemas en un sistema BI sean tecnológicos no debería extrañarnos, ni avergonzarnos a los que nos dedicamos a esto. Un sistema BI debe tener un "frond-end" para el usuario extremadamente sencillo, pero detrás de esta sencillez tiene que existir una arquitectura tecnológica que lo permita...

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.