Guía de éxito para El Director proyectos de Business Intelligence.

Muchos proyectos de Business Intelligence han fracasado en conseguir sus objetivos iniciales. Son tres los pilares sobre los que se sustenta el éxito o el fracaso de los sistemas de BI: Usuario, Organización y Metodología.

En un estudio realizado por la Universidad de Monash se concluye que un alto porcentaje los proyectos de BI (el 85%) han fracasado en conseguir alguno sino todos sus objetivos iniciales. ¿De qué depende el éxito y el fracaso de este tipo de sistemas? No creo que exista una fórmula milagrosa que haga que todo vaya bien, o una serie de errores que te dirigan al fracaso estrepitoso, en lo que si creo es que hay unas variables que bien contraladas nos puede andar grandes resultados.

Todo este conocimiento lo pongo en esta mini-guia, fruto de mis años de experiencia acumulada en este tipo de sistemas. Es un método que se basa principalmente en el sentido común y en la identificacion precoz de factores de riesgo, consiste en una serie de cuestiones que me planteo antes de empezar cada nuevo proyecto y que me permiten reflexionar sobre los diferentes obstaculos que pueden aparecer durante el mismo y así planificar previamente la forma de sortearlos o de intervenir cuando el problema salte a la palestra. Yo lo llamo la Guía de éxito para proyectos de Business Intelligence.

Son tres los pilares sobre los que se sustenta el éxito o el fracaso de los sistemas de BI: Usuario, Organización y Metodología.

Primera Reflexión: ¿Cómo es la organización en la que se va a implantar el proyecto?

Una de las características básicas para el éxito de los sistemas de Business Intelligence es sin duda la cultura organizativa y el nivel de madurez en el que se encuentre la organización en la que se va a implantar. Crear y gestionar una cultura de la medición de indicadores necesita de tie

Si no hay una cultura de la medición, haz que tu proyecto se fundamente en el reporting operacional, en el reporting táctico, y en análisis multidimensionales controlados.

Si la cultura de la medición está presente pero no arraigada, da paso a los cuadros de mando tácticos, fomentando que los mandos intermedios, comiencen a utilizar métricas de control. Si hay una cultura de la medición, muy arraigada, centra tu proyecto en madurar el reporting, el análisis y los cuadros de mando estratégicos, estableciendo roles y reponsables de métricas y madurando un data warehouse de uso estratégico, crea indicadores de causaefecto, y focaliza en la interdependencia de indicadores y en el seguimiento de las acciones correctivas.

Segunda Reflexión: ¿Como se gestiona el conocimiento?

Otro punto a tener en cuenta a la hora de determinar el éxito de las soluciones BI se encuentra en los déficits organizativos del propio departamento de Sistemas de Información, sobre todo en la gestión del conocimiento de los departamentos de Business Intelligence. Lo primero que tenemos que evaluar es la dificultad en definir estructuras adecuadas de localización de la información. ¿Dónde están los documentos? ¿Qué información contienen? El 30% de los documentos con información acaban almacenándose y manipulándose en pc's locales, quedando así inaccesibles para el resto de usuarios de la organización.

También debes plantearte dentro del proyecto la definición y consolidación de la “Verdad Corporativa”, has de definir unos informes estándar que sean los oficiales y definir los caminos de análisis básicos sobre esos informes. De manera que todo el mundo sepa donde y como se debe acceder a la información. Otro punto a tener en cuenta es la uniformidad de la organización semántica de la información. Por ejemplo, si yo pregunto a varios usuarios qué entienden por margen de la organización, y uno nos lo define como antes de aplicar impuestos, otro que después, y otro incluye que hay que descontar los abonos, entonces deberemos crear un documento de semántica común antes de empezar el proyecto, deberemos saber “qué se entiende por ….” y asegurarnos de que todo el mundo utilice la misma semántica.

Por último mirar iceberg de los procesos de análisis personal, las necesidades analíticas siempre han existido dentro de las organizaciones, y los empleados han tenido que utilizar seguro su ingenio para sacar esa información de una manera u otra. En ausencia de un sistema de Business Intelligence, la dificultad de acceder al conocimiento personal de cada empleado de la organización y la dependencia de ese conocimiento, que ha necesitado de tiempo y dinero de la empresa para crearse, que reside en una persona y que es de muy dificil reutilización, hace que un proyecto de BI se encuentre con dos tipos de barreras a solventar:

Procesos de análisis desconocidos que se deben integrar en el sistema para que ese conocimiento no se pierda.
Defensas de nichos de poder que dificulten la implantación del proyecto.
No os digo nada si lo juntamos con una alta rotación de empleados, las pérdidas de información y de control de procesos son considerables.

Tercera Reflexión: ¿Cómo evaluaremos el éxito?

Si todos habéis pensado, que con plazos de entrega, funcionalidades, volumen de informes, o métricas o cuadros de mando, etc., estáis muy pero que muy equivocados. El éxito de una solución BI también tiene una parte puramente de carácter intangible que debe ser evaluada, especialmente cuando se trata de sistemas de información estratégicos. Evaluar los beneficios intangibles de los sistemas de Business Intelligence, es quizás la parte más difícil de todas, pero se tiene que hacer el ejercicio mental antes de empezar a desarrollar.

MUY IMPORTANTE: Es más fácil conseguir un quick win con un intangible, sobretodo si ese intangible es importante para algún alto cargo de la compañía que pueda ser reacio al proyecto.

Así pues debemos saber que se espera del proyecto ANTES de empezar, definir sus objetivos tangibles y especialmente los intangibles, que posiblemente nos generen más fácilmente un éxito en el proyecto, que luego nos permita trabajar con una mayor renta de confianza en el éxito.

Durante la ejecución del proyecto, en cada reunión de seguimiento se deben de poner encima de las mesas los objetivos que se han ido alcanzando para que veamos realmente la evolución del Sistema de Business Intelligence, así al final de proyecto podremos evaluar fácilmente si ha sido un éxito o si ha sido un fracaso.

Cuarta Reflexión: ¿Cómo vamos a ejecutar el proyecto?

Otro factor a tener en cuenta en el éxito o fracaso de los sistemas de BI, son las personas que ejecutan y lideran el proceso de implantación y desarrollo. Los niveles de educación, la experiencia, y otros factores tienen una influencia más que notable. Siempre que empiezo un proyecto intento hacer un checklist mental de todo lo que tengo que tener en cuenta para ser un buen director de proyecto.
Son estos 6 pasos.


Check 1.-Misión, Visión y Valores de la compañia. ¿Todos los miembros del equipo tenemos claros cual es la misión de la compañía? ¿Somos conscientes de ella? ¿Actuaremos en consecuencia a estos valores? Es muy recomendable dedicar una sesión inicial a recordar o plantearlos para que todos sean conscientes de ellos. Refrescar y reflexionar antes que actuar permite evitar errores y focalizar los objetivos.

Check 2.-Prioriza CONSENSUADAMENTE los objetivos a alcanzar. Es vital, centrar los objetivos del proyecto en las necesidades urgentes de tu organización, así se verán los resultados antes. Y el consenso y la complicidad con los usuarios de negocio han de ser una garantía para conseguir ese primer quick win. Esto intenta hacerlo durante las primeras reuniones. Pero ANTES de iniciar estas reuniones tienes que tener claro la tercera reflexión: ¿Cómo se evalúa el éxito dentro de la organización?

Check 3.-Intenta ser un antropólogo gallego de tres años de edad. Por un lado intenta identificar las necesidades del negocio y quienes las están ejecutando y proveerles de herramientas que sean fáciles de usar según sus características personales, por el otro has de ser como un niño de tres años, siempre preguntando el porqué de todo. Y recuerda que no hay nada mejor que “ser gallego” (responder a las preguntas con más preguntas) para obtener la información del porqué de las cosas. A veces es sorprendente la cantidad de cosas que hacemos que no tienen sentido y que simplemente repetimos porque cuando nos enseñaron el proceso nos lo enseñaron de esa manera y no nos atrevemos a cambiarlo.

Check 4.-Recuerda que el proyecto no es tuyo. La involucración que los ejecutivos y directores de línea, que estos ayuden a coliderar el proyecto, y que lo hagan suyo. Garantiza la utilidad y facilita el camino eliminando obstáculos. Intento siempre hacer que vea el proyecto como algo suyo, un éxito de su trabajo y de su forma de controlar los procesos. Son ellos los que finalmente dictarán sentencia sobre el proyecto decidiendo usarlo o dejarlo en el olvido, así que lo mejor es que lo vean como suyo desde el inicio.

Check 5.-Haz el proyecto contagioso. Después del primer quick win, llega el momento de hacer que el proyecto de BI se propague a todas las áreas decisionales de la compañía. Es el momento de hacer que el proyecto sea una iniciativa de cambio fundamental para TODA la organización. En este paso, lo más importante es ser PROACTIVO, anticipar la resistencia al cambio y evitar convertirse en un paladín de la causa del BI. Si tienes que defender tres veces la necesidad de BI, entonces estarás condenado y el proyecto acabará en fracaso. Para ello justo después el primer quick win, pon encima de la mesa el coste que supondría para la organización no usar Business Intelligence. De esta manera facilitarás no tener que estar justificando el proyecto.

Check 6.-Ten una metodología de trabajo. Da igual si es buena o si es mala, pero ten una. Si es buena pues perfecto, y si es mala no te preocupes ya la mejoraras con el tiempo la experiencia y los proyectos. Pero ten presente que la anarquía en los proyectos de Business Intelligence acaba condenando a los mismos al desuso.

Quinta Reflexión: ¿Cómo actuar ante las crisis Seldon?

Lo que yo llamo las Crisis Seldon son momentos del proyecto en los que se identifica algún hecho que puede poner en serio peligro el éxito del proyecto y que por lo tanto hace que tengamos que intervenir con contundencia resolver el problema antes de que comprometa el resultado final.
Ejemplos de Crisis Seldon a superar durante un proyecto de BI.


CRISIS 1: Detectamos que los usuarios finales no apoyan el proyecto.

La acción realizar es parar inmediatamente el proyecto, hasta que se hagan las acciones de marketing interno y las sesiones pertinentes que hagan que el usuario final se sienta involucrado en el mismo. Si aún así no se consigue, lo mejor es abandonar el proyecto, hasta que la organización o los usuarios estén más maduros en la cultura de la medición.

CRISIS 2: Detectamos que la directiva no apoya el proyecto.

La acción a realizar es garantizar el apoyo incondicional de los usuarios finales, si lo conseguimos podemos seguir adelante con el proyecto, si los usuarios están tibios mejor dejarlo correr como en el caso anterior.

CRISIS 3: Detectamos que los usu-arios no entienden la relación entre el proyecto de BI y sus procesos de negocio.

El Business Intelligence provee de información analítica y de reporting que debe servir para controlar los procesos de negocio. Cada métrica o indicador que muestra o al que se puede acceder solo tiene sentido para proveer de información a los usuarios de negocio. Si estos no lo saben usar corremos el riesgo de que acabe en el desuso con lo que la acción a realizar es formarles en la APLICABILIDAD de la información al NEGOCIO. Con ejemplos concretos de su dia a día, y con formaciones específicas que les ayuden a incorporar el proyecto a su rutina diaria.

CRISIS 4: Detectamos que los usuarios no perciben al departamento de IT como soporte para resolver sus tareas.

En este punto hay que fomentar los entornos colaborativos dentro del proyecto y hacer ver como uno debe apoyar al otro.

CRISIS 5: Detectamos que la calidad del dato de los sistemas operacionales es muy mala.

En este punto lo mejor es parar momentáneamente el proyecto e iniciar un subproyecto previo de Calidad del Dato en los operacionales, o al menos plantearlo. Si no se admite, entonces lo que hay que hacer es dimensionar el sobrecoste que supondrá la mala calidad del dato en la creación del proyecto de BI y en su posterior mantenimiento.

CRISIS 6: No tenemos un “power user” por grupo de usuarios.

Cada grupo de usuarios finales debe tener entre ellos a uno que sea un power user, que sepa mucho de la estructura del proyecto, de cómo se aplica la información obtenida al área de negocio y de cómo se utiliza la herramienta que se esté utilizando. Si no existe este perfil, debemos asegurarnos que todos los usuarios tengan una referencia cercana de este tipo.

CRISIS 7: Un usuario pone en duda la información que recibe como resultado del proyecto de BI.

Punto crítico y con el que hay que actuar con mayor contundencia. Si esta actitud propaga nadie creerán en los datos, todos se creeran en el derecho de ponerlos en duda y nadie los utilizará, así que hay que erradicar de raíz esta situación. Si el problema es real-mente cierto, hay que mejorar la calidad del dato y aumentar los controles para que no vuelva a ocurrir. Si el problema no es cierto… machacadlo, que no cree precedente, que no siembre la sombra de la duda. Hay que demostrarle al usuario (y a su superior) en que se equivoca, haciendo un informe exhaustivo y una vez demostrado poner el coste que ha supuesto poner en duda la información, tanto de validación (el informe que salga caro) como de peligro de fracaso de la inversión en el proyecto. La idea es poner sobre la mesa que “tu duda injustificada nos ha costa-do X euros y nos podía haber costado X a la 3.”

Estos son algunos ejemplos muy útiles, pero cada organización tiene su propia intríngulis, lo que hay que hacer es prever cómo actuaremos en las posibles situaciones conflictivas.

Sexta Reflexión: ¿Y la herramienta?

¿Cómo?¿No he dicho herramientas? Pues no. La herramienta final de un proyecto de Business Intelligence no es un punto crítico del éxito, indudablemente, tener una buena herramienta ayuda, en el tiempo de implantación, en el mantenimiento posterior y en las potencialidades de análisis, pero NO es fundamental. La herramienta simplemente ha de poder estar en disposición de facilitarnos tres puntos principales:

1. Visualizar y reportar qué ha pasado;
2. Comprender por qué ha pasado;
3. Pedecir qué pasará.

Si la herramienta los cumple, entonces podemos olvidarnos de ella como factor de riesgo, ya puedo afrontar cualquier proyecto de BI con garantías, sea cual sea el fabricante.

¿Existen mas reflexiones?

Obviamente sí, son reflexiones sobre el uso de los metadatos, sobre las estructuras arquitectónicas, sobre la gestión del cambio, etc., aunque esas me las reservaré para cuando hagamos un proyecto conjunto.

Las más importantes son estas seis que os he transmitido en este artículo, y de gestión de proyectos, la clave es dialogar, dialogar y dialogar.