Reducir el fracaso en los proyectos de Business Intelligence (I)

El próximo miércoles 25 se celebra en Barcelona un Foro Profesional sobre Inteligencia de Negocio (1), en el que intervendrá el profesor Jordi Conesa, referente de la UOC en estos temas (2). Los últimos días nos hemos cruzado con él y con la profesora Isabel Guitart algún correo y comentarios sobre su intervención, dirigida a discutir los factores de éxito en la implantación de proyectos BI.

Por mi lado, no me atrevo a decir factores de éxito, la verdad. Pocos proyectos puedo imaginar tan caros, complejos, inciertos; pocos con tantos fracasos en calidad, tiempo, coste y, sobre todo, satisfacción de los clientes; pocos en que la promesa sea tan grande (aumentar la información y el conocimiento organizativo para conseguir mejores resultados y obtener ventaja competitiva) y el resultado tan pobre; pocos en que el enorme esfuerzo de la organización y los implantadores sea tan difícil de convertir en beneficios.

Apenas a partir de mi experiencia, la de otros que saben más que yo y alguna literatura, me atrevo a sugerir algunas prácticas que no van mal para hacer las cosas un poco mejor. Como quedará un poco largo, lo haré en un par de entregas (3).

1)     Para qué hace falta el proyecto. No es trivial. Según los objetivos que quiere conseguir la empresa, cada proyecto es distinto o a lo mejor ni siquiera hace falta. No es igual un cuadro de mando de dirección que un sistema de analítica de costes para los financieros que un portal de datos de toda clase para decenas de unidades de negocio y cuadros intermedios que un sistema de inteligencia comercial que un sistema de ayuda automática para tomar decisiones de producto y precio o hacer ofertas a cierta clase de clientes objetivo.

2)     Quién es el cliente. Aún lo es menos y suele ser menos claro. Yo creo que es un buen principio pensar que un sistema BI (cualquier cosa que eso acabe siendo: dashboards, cubos OLAP, datawarehouses departamentales o corporativos) es algo que debería usar alguien para tomar mejores decisiones sobre el negocio y alinear a la organización y los equipos en una cierta dirección. “Se mide lo que se hace, se hace lo que se mide”. Es imprescindible tener cliente, entender lo que necesita, qué información usa hoy y cómo la usa, qué otra le falta, por qué y para qué. Con quién trabajará y cómo, en qué soportes, qué clase de presentación o de formato les resultará cómodo, amistoso y sobre todo útil.

3)     Hacerlo fácil, hacerlo ágil. El cliente, si lo encontramos, muchas veces no sabe contestar la mayoría de las preguntas anteriores, no quiere escucharlas y tiende a delegarlas en algún subordinado que tampoco sabe. Por eso, si en algún ámbito de la informática tiene sentido utilizar metodologías ágiles, que permitan la interacción e iteración frecuente con el cliente, son los proyectos de BI. Presentar pronto mapas funcionales, prototipos, el lay-out gràfico y revisarlos sobre la marcha creo que son buenas ideas. Un proyecto BI no es un paseo militar y los enfoques de algún gran fabricante germánico son el camino a la perdición. Es también buena idea acostumbrar al cliente a trabajar con primeras versiones que pueden ser aún pobres o contener errores y aprender después monitorizando el uso. Un proyecto BI no se acaba (4).

4)     Pero la arquitectura es compleja. Y esta paradoja no es fácil de solucionar. El modelo de datos que facilita la extracción y explotación de la información es lento y complejo de construir, en especial en los grandes proyectos corporativos, que se alimentan de datos transaccionales de su padre y su madre que tienen poco que ver con la información que necesitan los directivos y el tratamiento que le darán. Por eso, lo importante es la primera pregunta, para qué. Entiendo las ventajas de la integración, de la única verdad tratada por todo el mundo de la misma manera, de la perfecta pirámide que relaciona la entrada de un dato en una tienda con el informe que verá el director general y que además permitirá un tratamiento cruzado y multidimensional. Guay. Pero cada vez me inclino más por sistemas y productos más pequeños y sencillos de construir, implantar y cambiar.

Seguimos otro día, si os interesa.

Notas:

1. http://inteligenciadenegocio.com/barcelona.html

2. Os recuerdo también la oferta educativa de la UOC en Business Intelligence, a la que podéis acceder desde este enlace http://www.uoc.edu/posgrado/matricula_abierta/web/informatica_multimedia_telecomunicacion/embusiness_intelligenceem/

3. Para una introducción al Business Intelligence con dos perspectivas diferentes podéis ver: Conesa J. y Curto J. (2010) Introducción al Business Intelligence (Editorial UOC). Otra lectura muy recomendable es el libro de Davenport T. y Harris J. (2007), Competing on Analytics (Harvard Business School Publishing), del cual hay una traducción castellana en editorial Profit.

4. En proyectos BI son especialmente aplicables,en mi opinión, algunos de los comentarios que presentábamos hace poco sobre la «visión extendida» del proyecto y la participación de los usuarios (http://blogs.uoc.edu/informatica/2012/04/16/como-y-cuando-escuchar-a-los-usuarios-2/)