La mayor parte de la documentación sobre proyectos de Business Intelligence está pensada para un alcance de Organización, de manera que se recomienda no modelizarla toda, sino solamente una parte e ir ampliando el alcance del proyecto hasta abarcar toda ella. El carácter de los informes a que da lugar esta filosofía no se acostumbra a tener en cuenta. Es decir, modelizamos toda la parte financiera de la organización, pero no diseño la estructura de informes que voy a tener en función de responder a las preguntas de negocio o a las iniciativas que se desprenden del despliegue de la estrategia según el cuadro de mando integral – Balanced Scorecard -. La estructura de informes la diseñaré sobre la marcha. Lo despliego todo y luego ya veré con qué me quedo.

En este blog intentaré crear una documentación que atienda a cómo afrontar un proyecto enfocado a uno o dos informes muy específicos, incluso con el peligro que supone la falta de visibilidad de un objetivo tan pequeño.

Es importante que la parte de negocio, las personas que mejor conocen los entresijos de su actividad diaria y de los datos, expongan en una lista los objetivos que se pretenden conseguir con el proyecto. Es decir, las preguntas que hay que responder. Más adelante veremos qué propongo para conseguir esto y cómo se escoge por dónde empezar.

De toda la lista de preguntas habrá algunas que sean de fácil implementación, aunque de una relevancia menor, y otras que, siendo mucho más importantes, requiera de la mayoría de recursos y tiempo. Ante la disyuntiva, desde aquí se propone optar por las primeras: priorizar la entrega de resultados frente a la dilatación en el tiempo de la entrega de un informe importante.

Las ventajas que aporta esta visión –priorizar la capacidad de entrega de resultados-son las siguientes:

1. Entrega inmediata de resultados tangibles. Disminuye el peligro de parálisis por exceso de análisis del negocio. 
2. Evaluación por los usuarios de una parte del sistema. Esta evaluación se refiere tanto a la herramienta en sí misma –funcionamiento –como al análisis de la parte modelizada. Este análisis probablemente implicará que se generen nuevas necesidades en el proyecto o que se piense en variar algún proceso de negocio. Será necesario incorporar las nuevas necesidades al proyecto. 
3. Inicio del proyecto en un entorno controlado, de corto alcance pero que facilite la escalabilidad –diseño inicial limitado pero ampliable–de manera que permita tener pistas sobre los errores cometidos para ser subsanados, corregir las consultas a la base de datos para optimizar el rendimiento y obtener una curva de aprendizaje más plana. 

Optar por uno o dos informes que respondan a los puntos anteriores permite actuar en un entorno pequeño, controlable y controlado, en que los técnicos cuenten con cierto entrenamiento y pruebas fehacientes de que las cargas funcionan, son datos fiables y relevantes para el negocio. Desde él se podrá aprender más sobre la herramienta, se podrán solucionar los errores que se presenten más fácilmente y se podrán obtener resultados rápidamente y de valor para los usuarios.

Desgraciadamente, este enfoque no está exento de problemas: falta de visibilidad debido a su pequeño tamaño, usuarios que no quieren una parte del proyecto al inicio sino todo el proyecto al final... Más adelante mostraré cómo propongo afrontarlos.









Josep Manel Santos