Dirección de proyectos BI: El éxito y el fracaso

No paguéis el rescate, pero la crisis me está matando a trabajar (por suerte).
Así que a pesar de ir muy desbordado, hoy os pongo una pequeña reflexión sobre dirección de proyectos BI.

¿Éxito y/o Fracaso? Son palabras que surgen muy a la ligera de la boca de muchos usuarios cuando quieren juzgar el resultado de un proyecto de Business Intelligence, pero... ¿a que nos estamos refiriendo? ¿Qué es éxito y qué es fracaso?. Y lo mas importante... ¿Cómo lo medimos?

Seguramente estáis pensando la respuesta es fácil, que con plazos de entrega, cumplimiento de funcionalidades, volumen de informes que se esperaban, métricas aportadas por el proyecto, cuadros de mando, etc.,

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

Pensad que si usamos una metodología ágil en la que involucremos al usuario desde el inicio en el proyecto nos permitirá aumentar sustancialmente el éxito del proyecto, por dos razones, la primera es que conoceremos mejor las necesidades del usuario y como quiere utilizar la información, y la segunda es porque difícilmente el usuario dirá que ha sido un fracaso si él es parte del equipo :-D

7 Intervenciones para el éxito de un DWH (3ª Parte)

Con este post terminamos con las 7 intervenciones.

El punto de Intervención 5 es asegurarse de que los usuarios finales saben como aplicar la información extraída del DWH a sus tareas diarias. Si no saben como les puede ayudar el DWH obviamente no lo utilizarán y el DWH caerá en desuso y posteriormente en el olvido. Si no hay que realizar formaciones específicas con los usuarios para garantizar la aplicabilidad de la información.

En esta linea creo que no solo es necesario que los usuarios finales entiendan como aplicar la información a sus tareas diarias, sino que comprendan la globalidad del proceso del negocio (del cual estas tareas forman parte), el objetivo del mismo y las perturbaciones a las que puede ser sometido, tanto internas como externas a la organización.

Tener un mapa conceptual de lo que pueden significar diferentes metricas y valores en el ámbito del negocio es útil, pero si nos limitamos a repetir esa aplicabilidad sin entender el significado global nos arriesgamos a caer en la paradoja que a veces explico en clase la de "Los 12 monos" que repiten un proceso sin comprender el significado de lo que hacen. (El link aprovecho la adaptacion de Antonio Valle de esta paradoja que me llegó hace años por internet y que no se quién es el autor)

El punto de Intervención 6 es asegurarse que la relacion entre el departamenteo de sistemas de información y los usuarios finales es fluida. Si no encontramos con hermetismo por alguno de los dos lados, seguramente la implanción será un fracaso, es mejor retrasarla hasta propiciar un entorno colaborativo.

Fijaos que este punto es plenamente coincidente con las metodologías ágiles en los que los usuarios finales forman parte del equipo del proyecto, participando en las reuniones periodicas, aportando ideas, añadiendo o eliminando funcionalidades, pero como uno mas, no como el usuario al que se le pregunta cuando se tienen dudas y que lo que el diga luego nos servirá de excusa o de salvoconducto.

El punto de Intervención 7 es asegurarse que entre los usuarios finales va a haber uno que conozca muy bien tanto las capacidades del DWH como el uso de las herramientas de explotacion, lo que los autores llaman el "Power User" y a lo que yo llamo "el empollón gafotas" . Si queremos tener éxito en el uso continuo y a largo plazo del DWH es necesario una persona de negocio que explore todas las posibilidades y que ayude e incentive al resto de compañeros. No hay nada como un usuario que consigue maravillas con el DWH para que los demás imiten su camino.

Los autores dicen que si ese perfil no éxiste hay que crearl, en una metodología ágil ese usuario ya se crea durante el proyecto, ya que forma parte del equipo.

Ya hemos visto los 7 puntos de intervención que nos garantizarán el éxito ( o mejor dicho el no fracaso) de un DWH, muchos de ellos tienen coincidencias con las metodologías ágiles como hemos podido ver, con lo que mi propia conclusión de este artículo es que la aplicacion de una metodología ágil en la implantacion de un DWH nos acerca un poco mas al éxito que no las tradicionales.

Cuatro de la siete intervenciones están incluidas ya en las metodologías ágiles.

¿No os da eso qué pensar?

7 Intervenciones para el éxito de un DWH (2ª Parte)

El cuarto punto de intervención está en elegir la herramienta de explotación del DWH.
La cuarta pregunta que os debeis hacer es :

¿Los usuarios necesitan herramientas restrictivas o no restrictivas ?

Usar herramientas restrictivas (es decir herramientas que limitan las opciones del usuario final) sin duda nos ayudará a reducir la complejidad y la ambigüedad semántica, pero nos limitan las posibilidades.

Usar herramientas no restrictivas (es decir herramientas que dan una amplia gama de opciones al usuario) nos permitirán acceder a información menos estructurada, pero son mas complejas de usar por los usuarios y es facil que generen conflictos semánticos.

Obviamente los investigadores detectaron que aquellos que tenian un repositorio simple como DWH (sin datamarts) y que habían tenido éxito habían optado por herramientas no restrictivas, preferian invertir en aprender la complejidad de este tipo de herramientas antes que utilizar una mas simplificada.

Ahora me gustaria hacer una pequeña reflexión: ¿somos conscientes de que cuando utilizamos un Datamart estamos "semiestructurando" nuestros tipos de análisis?. ¿Somos conscientes que al simplificar, al crear dimensiones, jerarquías y hechos de análisis, dejamos algunas manzanas fuera del cesto?.

Unas herramientas que nos simplifiquen la interacción tambien nos harán mas sencillos los tipos de análisis que podamos hacer, perdiendo parte de ese capacidad por el camino. Si nos limitamos a decir "no, mejor todas las posibilidades" entonces introducimos complejidad innecesaria, dificultamos el aprendizaje del DWH, e incentivamos a los usuarios a que busquen la información por otro lado, en algún listado del ERP combiando con un Excel que les pasa su vecino de mesa.

No es lo mismo acceder a la informacion mediante informes realizados en herramientas específicas de BI, diseñadas para el análisis y el reporting (Business Objects, Cognos, MicroStrategy, MIS, etc...), que hacerlo directamente con sentencias SQL. Seguro que con sentencias SQL podemos acceder a cualquier posibilidad que exista en el DWH, pero la complejidad de su uso quizá no merezca la pena.

Por lo tanto este equilibrio entre lo que pierdo de capacidad de análisis y lo que gano en sencillez es vital para el éxito del DWH. Pensad que los usuarios finales son generalmente bastante vagos (lo digo por experiencia) y siempre encontrarán la manera mas sencilla y mas cómoda para acceder a la información.

Desde el punto de vista de las metodologías ágiles, la utilización de una herramienta restrictiva creo que es la más adecuada, ya que la famosa regla del 80-20 se cumple inexorablemente. Quizás podamos dejar un 20% de análisis no típicos que al semiestructurar perderemos, pero el 80% restante lo tendremos con solo el 20% de esfuerzo. ¿Merece la pena aplicar otro 80% de esfuerzo por esos análisis?. Pues generalmente no. Pensad que uno de los principios básicos de las metodologías ágiles es potenciar la puesta en marcha rápida de todo aquello que sea útil desde la perspectiva de negocio, eliminando lo superfluo.

Fijaos que si ya tenemos la información "semiestructurada" en un Datamart, esa pérdida ya la hemos cometido con lo que el uso de la herramienta restrictiva apenas nos quitará juego y nos aportará simplificación del uso y reduccion de la ambigüedad semántica (esto último se consigue al crear el Datamart y luego ponerle una capa de abstracción o semántica o de metadatos con la herramienta de explotación del usuario que escojamos).

Por el contrario, si no tengo la informacion "semiestructurada", es decir, si tengo un repositorio simple, al introducir una herramienta restrictiva estoy poniendo mucho en juego, estoy perdiendo esa amplitud de análisis que precisamente me habian llevado a elegir un repositorio simple. No es de extrañar entonces que los investigadores detectasen que para estos casos se eligieran herramientas no restrictivas.

Podriamos pues deducir, que si tenemos un repositorio con información semiestructurada y elegimos una herramienta no restrictiva, seguramente llegará un momento en que deberemos completar esos "huecos" con información no estructurada, para permitir recuperar esa pérdida de capacidad de análisis. ¿ Esta situación no se parece mucho a la arquitectura HOLAP (Hybrid On-Line Analitical Process) ?.

Obviamente en el artículo no se nombra nada de esto, pero creo que cae por su propio peso, sacar como conclusion el siguiente esquema decisional para el cuarto punto de intervención.

Si alguno de los lectores estais en alguna de estas situaciones me gustaria que lo comentarámos para confirmar este esquema.

Hemos visto el 4º punto de intervención, me he extendido demasiado así que dejaré los tres últimos puntos para la tercera parte de este artículo.

7 Intervenciones para el éxito de un DWH (1ª Parte)

Ayer saque algo de tiempo para leerme un artículo que prometía mucho: "Seven Key Interventions for Data Warehouses Success" , articulo de Tim Chenoweth, Karen Corral y Haluk Demirkan publicado en enero de este año 2006 en Communtications of the ACM.

El punto de partida es brillante "The success of data warehouses depends on the interaction of technology and social context [...].The trick is knowning when and how to intervene."

Son las interacciones de la tecnología con el contexto social y corporativo lo que determina el éxito (que se use) o el fracaso (que no se use) de un data warehouse.

¿No os recuerda esto algo?, ¿no es recuerda al primer párrafo del Manifiesto Agil.?
"En este trabajo valoramos:· Al individuo y sus interacciones más que al proceso y las herramientas."

Si estos investigadores tienen razón en su estudio, podremos responder ya a una de las preguntas que me hacía anteriormente: ¿Son aplicables las metodologías ágiles para los sistemas decisionales?

Los tres primeros puntos de intervención los tenemos en el inicio del proyecto del data warehouse. Os lo resumo en este esquema.

Los puntos de intervención 1 y 2 son de sentido común. Si no tienes alguien que esponsorice el proyecto desde la alta dirección o si en su defecto no tienes a los usuarios a favor, difícilmente tendrás éxito con una implementación de DWH o de un ERP o de un CRM. Son puntos de intervención que caen por su propio peso, pero a veces se nos olvidan. De hecho yo no estoy del todo de acuerdo con la posibilidad de seguir con el proyecto con solo un "Champion" de dirección que apoye el proyecto (sin tener en cuenta a los usuarios finales). Soy de la opinión de que hay que buscar el respaldo de los usuarios finales durante las primeras fases del proyecto. Un usuario boicoteador puede hacer muchísimo daño, mientras que un usuario implicado en el proyecto desde el inicio difícilmente echará a perder su propio esfuerzo. Por eso me gusta tanto la posibilidad de aplicar metodologías ágiles en los sistemas decisionales.

Sin embargo el punto 3 ya nos da una nueva visión sobre si es bueno o no el uso de los datamarts multidimensionales o si podemos aplicar un modelo de data warehouse mas al antiguo estilo, al de "Almacén" de datos sin estructurar excesivamente, sin encorsetarlos en unas jerarquías pre-establecidas.

Así pues tenemos dos alternativas de éxito para un sistema decisional, para lo que hasta ahora muchos creen que es él único paradigma válido, el modelo multidimensional, nos encontramos que con aproximaciones mas clásicas y menos elaboradas podemos obtener el mismo éxito.

La pregunta que nos tenemos que hacer es ¿tenemos un amplio abanico de información a la que acceder?, si la respuesta es sí y atacamos con un modelo multidimensional iremos directamente al fracaso. Si por el contrario no tenemos esta necesidad, entonces el modelo multidimensional nos es muy válido.
En las conclusiones del artículo los autores reflexionan que en muchos de los casos estudiados una aproximación simplista y "One-dimensional" llevaba al éxito en la mayoría de casos.

¿A que os recuerda esto?. Al Décimo principio de la metodologías ágiles.

"X. La simplicidad es esencial. Se ha de saber maximizar el trabajo que NO se debe realizar."

Otra reflexión que se me ocurrió mientras leía el artículo es si no tendría relación los usuarios que tienen que acceder a una gran cantidad de información con los perfiles decisionales de los que ya os hablé sistemas decisionales y estilos de tomas de decisión. Por desgracia no encontré ninguna referencia en el artículo que me pudiera justificar que para decisiones estratégicas se necesite este amplio abanico de información, mientras que para decisiones operacionales y tácticas no. La verdad es que tiene la pinta y encajaría perfectamente con mi teoría, pero eso ya es mucho pedir.

Os dejo con estos tres primeros puntos, nos faltan cuatro, pero espero que estos nos den juego para reflexionar.