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?

Acabo de leer un intersante artículo llamado "Agile Business Intelligence Governance". Creo que aporta una serie de ideas muy interesantes relacionadas con la manera en que deben conducirse los proyectos (o mejor dicho: las empresas) para obtener más valor de los Sistemas de la Información (especialmente, de los sistemas BI).

De todo el artículo, lo que mas me ha gustado es el concepto de "Metodologías ágiles", que se concreta en el siguiente "manifiesto ágil":

Estamos buscando mejores maneras para desarrollar software y ayudar a otras personas a desarrollarlo. En este trabajo valoramos:

• Al indivíduo y sus interacciones más que al proceso y las herramientas
• Desarrollar software que funciona más que obtener una buena documentación
• La colaboración con el cliente más que la negociación de un contrato
• Responder a los cambios más que seguir una planificación

De esta manera, mientras mayor valor tengamos en la parte de la derecha más apreciaremos la parte de la izquierda

Me gusta esta manifiesto porque pone en evidencia que las herramientas, la documentación, los contratos y la planificación son sólo los "medios" para conseguir unos "fines", y que por lo tanto deben ser adaptables y cuestionables en función del proyecto. Es decir: Los sistemas analíticos tienen una características distintas de los sistemas transaccionales, por lo que no debe extrañarnos que sus metodologías sean también distintas.

El artículo contiene otra serie de ideas interesantes por lo que recomiendo su lectura. Por cierto, al finalizar el artículo me he dado cuenta que lo ha escrito Jorge Fernández, el "slowgger" (¡vaya neologismo se ha sacado de la chistera!) de Sistemas Decisionales, y de hecho en su blog encontraréis otra documentación interesante sobre estos temas...

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

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

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

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

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

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

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

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

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

Habitualmente, sólo los entusiastas del “Open Source” hablan de “Open Source” y de “Software libre”. Yo no lo soy, por lo que espero disculpen la intromisión…

En primer lugar, decir que para un profano como yo ambos términos (Open source/software libre) son prácticamente equivalentes. Sin embargo, para los entendidos la diferencia es importante. El término “software libre” tiene connotaciones filosóficas mucho más fuertes, e incluso existen fundamentalistas del tema que poco menos querrían la inclusión del GNU en la Declaración Universal de Derechos Humanos. Yo me quedo con el término “Open source”, más pragmático, que suele implicar en mayor o menor grado estas tres características:

• Código fuente disponible
• Software gratis o de bajo coste
• Software colaborativo

Que un programa tenga el código fuente disponible es una buena cosa. Sin duda. Puestos a escoger, prefiero utilizar software del que pueda ver y/o modificar el código. Esto me dará independencia y me dará una cierta tranquilidad incluso en el caso de que el fábricante desaparezca. En la práctica, sin embargo, no creo que deba ser un criterio fundamental para la elección de software. Mi empresa (¿y la tuya?) no se dedica a fabricar software, por lo que no tiene ni los conocimientos, ni el interés, ni las ganas de modificar el código fuente de nuestros aplicativos. Aunque suene impopular: Tengo más asegurada la continuidad de Microsoft Word (de código privativo), que el de Pentaho (de código abierto). Por razones evidentes.

Que el software sea gratis o de bajo coste es una buena cosa. Sin duda. Puestos a escoger, prefiero utilizar software que sea gratis. Sin embargo, no debemos equivocarnos: los proyectos “open source” tampoco son gratuitos, ya que su negocio suele estar en la consultaría, en el soporte, o en otros servicios asociados. Personalmente, preferiría una aplicación que fuese tan fácil de utilizar que no requiriese consultaría (o que fuese lo menor posible), ya que a la larga los costes de consultaría y mantenimiento pueden superar con creces los costes de hardware y software. Es decir: Tampoco el coste es un criterio definitivo para la elección de una herramienta. Existen otros parámetros más importantes: Funcionalidad, facilidad de uso y administración, estabilidad, etc.

Finalmente, el concepto de “software colaborativo” es el que me resulta más extraño. ¿Qué me importa a mi, como comprador de software, que el software lo haya hecho un equipo de profesionales a sueldo de IBM o una comunidad de internautas en sus ratos libres? De hecho, éticamente, me siento más cómodo comprando algo cuyos autores han resultado debidamente pagados, y que genera empleo, y tal… No sé si me explico. El próximo comentario tratara sobre este asunto (después de haber leído ciertas cosas estoy cabreado, y prefiero no escribir en caliente)…

En definitiva, en mi opinión, la única viabilidad que tienen las empresas Open Source es entrar de lleno en mercado, y jugar con las reglas del mercado. Sólo si sus productos son mejores, podrán ganar terreno al software “privativo” (así denominan al software comercial habitual).

Sé que me dejo algunas cosas en el tintero. A veces los que ganan no son los mejores. La publicidad, la falta de competencia, y otros factores pueden alterar las reglas de juego. Pero esto lo dejo para otro día. Este comentario ya no da para más.

Un saludo,

BI Fácil