• Gráficos en Business Intelligence
• Usabilidad en el Business Intelligence
• En Business Intelligence, ¿Caballo grande ande o no ande?
• Informes para informar
• Manifiesto Ágil
• "¿Problemas tecnológicos? ¿Qué problemas?"

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