A través de BI Spain, he encontrado una noticia, que habla de un estudio encargado a Forrester Consulting que descubre por qué las herramientas BI no siempre cumplen con los objetivos esperados. El estudio es de pago (por lo que no puedo ponerlos el enlace), sin embargo, la nota de prensa deja entrever dónde está el problema:

De acuerdo con la encuesta a 226 profesionales de negocio e IT, un número significativo de trabajadores consideraran que sus aplicaciones de BI de apoyo a la toma de decisiones presentan limitaciones importantes. El 45% de los encuestados mencionan que las aplicaciones de BI son difíciles de aprender y de navegar.

El estudio también destaca la necesidad de ofrecer autonomía a los usuarios para acceder directamente a la información. Además del query y reporting tradicional, las compañías necesitan herramientas BI que combinen smiplicidad de uso y funcionalidades avanzadas de búsqueda y navegación:

Traditional lines of demarcation between information producers (traditionally IT staff) and consumers (traditionally business users) are now very unclear, as a significant portion of knowledge workers now fulfill both roles. BI tools and applications need to be cognizant and supportive of that trend and provide ways for knowledge workers to fulfill their information requirements via self-service. Companies need BI tools and applications that combine the simplicity, and resulting zero training, of a search-like UI on top of reporting, querying, and analysis to make BI pervasive throughout the knowledge worker community.

Estoy de acuerdo con estas conclusiones.

El problema a veces está en la propia herramienta BI seleccionada, y no sólo en los usuarios, técnicos, consultores y/o sponsors que han llevado el proyecto. A veces, decimos que la herramienta es algo secundario, y que las claves de éxito o las claves de fracaso en un proyecto de BI son otras. No estoy deacuerdo. La herramienta también es una decisión clave que debe tomarse antes de emprender un proyecto Business Intelligence. Y la facilidad de uso es un factor importantísimo a valorar.

Me permito poneros la siguiente imagen que compara tres filosofías de producto.... Si dispones de una herramientas de BI en tu organización, ¿A qué modelo se asemaja más la interfaz de tu suite de Business Intelligence? ¿Y cuál crees que preferirían los usuarios de tu organización?

Por si no está claro, aquí está la lista que alude el título de este artículo:

• Simplicidad
• Simplicidad
• Simplicidad

Perdón, pero no sabía como enfatizar la importancia de este punto...:-)

A través de Mala Prensa he encontrado un artículo de Expansión en el que analizan el precio teórico de las distintas selecciones que acudirán al próximo Mundial de Sudáfrica. La idea del estudio es analizar la relación entre las posibilidades de cada selección (ránking FIFA) con su valor económico, y mostrar las diferencias económicas entre los distintos equipos que acuden a la cita. Todo muy serio, y muy profesional, hasta que incluyen este gráfico sin pies ni cabeza:

Analicemos un momento este gráfico, y la información que muestra. Intentan representar los "millones de euros" que cuesta cada selección, y su posición en el "ránking FIFA". Veamos:

• El gráfico únicamente permite la comparación entre dos selecciones (una es fija, España, y la otra se debe seleccionar del listado de selecciones que aparecen en la parte superior).
• La barra de la derecha muestra los valores de España. Como "La Roja" es la selección fija, esta información no cambia. La selección de España cuesta 565 millones de euros, y es la primera en el ránking FIFA.
• La barra de la izquierda muestra los valores de la otra selección comparada. Observad que la barrita verde representa la posición FIFA. España, nº 1, tiene la barra verde llena hasta arriba; las demás selecciones, barras más vacías según su posición.
• En el centro del gráfico tenemos un enorme campo de fútbol, que junto con el listado de países ocupan la práctica totalidad del espacio.
• Y detrás del campo de fútbol, tenemos dos círuclos rojos que intentan representar el valor de las selecciones comparadas. Se supone que esto es lo novedoso del estudio. Y, encima de que los círuclos no caben en el área de dibujo, resulta que los millones de euros que cuesta cada selección no es proporcional al área de los círculos...

Efectivamente, tal como señala Mala Prensa, es un error gravísimo (y estúpido) hacer el radio proporcional al valor que se quiere representar. Por ejemplo, los jugadores de Serbia cuestan 185 millones de euros, que es un tercio de lo que cuesta la selección española. El círculo de España debería ser tres veces más grande que el de Serbia. Y sin embargo...

...observad cómo el círculo de Serbia cabe 3 veces "a lo largo" del círculo de España. Eso quiere decir que el círculo de España es 9 veces más grande que el de Serbia (cuándo sólo debería ser tres veces mayor).

Tal como he dicho otras veces, los gráficos son grandes aliados de los sistemas de Business Intelligence, pero deben utilizarse correctamente. La función de las gráficas no es estética. Un gráfico debe transmitir un mensaje, y por sus características visuales puede y debe hacerlo mejor que una tabla llena de números.

Por supuesto, tal como dice Mala Prensa, esta información se hubiera podido representar de manera más clara, y con mucho menos esfuerzo, de otra manera:

Realmente un ejemplo espectacular de cómo ocultar información a través de los gráficos. Con lo simple que hubiera sido un gráfico de barras, con banderitas o colores de uniforme, ordenando los países por ranking FIFA, y con las barras proporcionales al valor estimado. Ahí se verían perfectamente, de un sólo vistazo, tanto las diferencias de valor entre todos los equipos participantes (y no sólo en comparación con España), como la relación (o falta de ella) entre el valor de las selecciones y el ranking FIFA. Un caso para las antologías de cuánto daño puede hacer la infografía en malas manos.

En una entrada antigua comentaba que los informes están para informar. Con los gráficos pasa exactamente igual: La función de las gráficas no es estética. Un gráfico debe transmitir un mensaje, y por sus características visuales puede y debe hacerlo mejor que una tabla llena de números.

Últimamente los proveedores de Business Intelligence están mejorando mucho el aspecto y la tipología de sus gráficas. Empieza a ser habitual ver gráficas en movimiento o con un aspecto mucho más profesional y atractivo que los que disponían hace unos años. También se están popularizando nuevas representaciones que hace unos años escaseaban (gráficos de burbujas, mapas de calor, etc.).

Los gráficos deben ser sencillos, claros, y normalmente planos. Debemos huir de las representaciones 3D y sobretodo de rotaciones extrañas sobre los ejes. Cada vez que veo este tipo de efectos en las presentaciones comerciales (¡jamás lo he visto en un informe de verdad!) me revuelvo en la silla de dolor.

Fijaos también qué gráfico tan apasionante he encontrado en Mala Prensa. Apareció publicado en el País:

Vaya birria de gráfico. ¿Qué aporta a la noticia? Peor aún, ¿Qué diablos representa?

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?

"Caballo grande, ande o no ande"es un refrán medieval que empleaban los agricultores que necesitaban la fuerza de estos animales para su trabajo en el campo. Los caballos grandes eran más fuertes y podían arar la tierra mejor que un buey y sobretodo transportar más carga del campo a la ciudad.

¿Se puede aplicar este dicho en el mundo del Business Intelligence? Yo creo que no, y como saber refranes poco cuesta y mucho vale, os digo otro que nos puede ayudar a tomar una mejor decisión:“Más vale maña que fuerza”, o este otro:“Más vale asno que me lleve que caballo que me derribe”.

Los grandes proveedores Business Intelligence presumirán de ser líderes, y de tener los mejores productos, e insinuarán que adquirir el producto de un proveedor de segunda fila es un riesgo en cuanto a la continuidad de la herramienta o el soporte que puede ofrecer el pequeño proveedor. Sin embargo, la experiencia no nos dice eso, y ningún gran fabricante tiene las manos limpias en estos aspectos. También presumirán de la integración que ofrecen sus suites y todo eso. Pero del dicho al hecho hay mucho trecho.

En el ámbito del reporting corporativo Business Objects, Cognos y Microstrategy realmente tienen muy buenos productos desde hace años y nadie ha podido robarles cuota de mercado. Sin embargo, existen unos cuantos productos “pequeños” que ofrecen características comparables (o incluso mejores) en el área del análisis OLAP, de los dashboards, y de los cuadros de mando.

Un consejo; si quieres lo tomas y si no lo dejas. A la hora de decidirse por un software de Business Intelligence debe primar el producto por encima del proveedor. Compra un producto, no el proveedor. Si el producto es bueno, innovador, y pertenece a una empresa que apuesta por él, las probabilidades de éxito del proyecto son superiores, e incluso es más probable que tenga una mejor continuidad y un mejor soporte.

En cualquier caso, un proceso de selección es imprescindible. Analiza tus necesidades y las funcionalidades de cada producto. Debes evaluar y decidir, porque si pones lo tuyo en consejo, unos te dirán que es blanco y otros que es negro.

He encontrado un artículo de BARC titulado "Compre producto, no proveedor" que precisamente reflexiona sobre esta cuestión. Entre otras cosas interesantes dice:

Mayor no siempre significa mejor. Esto también es cierto en el caso de los proveedores de software. En proyectos de selección de software, la seguridad de la inversión resulta ser considerada como un criterio de gran importancia en la decisión sobre un fabricante determinado. Especialmente en el caso de proveedores de software pequeños, los clientes temen su insolvencia o adquisición por un competidor, que implicaría la necesidad de nuevas compras o proyectos de migración costosos. Tan comprensible es esta preocupación, como equivocadas son las conclusiones que sacan frecuentemente las personas con poder de decisión en el área de TI en una empresa […]

Ningún gran fabricante tiene las manos limpias con respecto a la continuidad de sus productos. IBM paró el desarrollo de sus herramientas de Business Intelligence y del DB2 OLAP Server (y no solo los componentes OEM, sino también la parte desarrollada por IBM); Oracle muestra actualmente una ruptura en su catálogo de productos integrando los frontends de BI recientemente adquiridos de Siebel. Asimismo, Microsoft dejó desaparecer del mercado el Data Analyzer adquirido en 2001.

Los usuarios tendrían que tener en cuenta también que supuestos fabricantes “grandes” pueden ser adquiridos por competidores todavía más grandes o fusionarse con otros. En caso de que IBM, Google o Microsoft adquiriera por ejemplo a SAP —lo que es absolutamente imaginable— ¿seguirían desarrollando los componentes de software que no forman parte de los productos clave para Enterprise Resource Planning (ERP)?

A buen entendedor, pocas palabras bastan.

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

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

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