En todo proyecto de Business Intelligence existe una fase inicial que proporciona la base sobre la que debe definirse el proyecto: La definición de requerimientos.
Se trata de la fase más importante de todo el proyecto. Una mala definición de requerimientos tendrá implicaciones negativas en el resto del proyecto. Y para eso, es crucial disponer de los conocimientos y la experiencia necesaria para abordar esta fase.
Hay que tener en cuenta que los proyectos de Business Intelligence tienen grandes peculiaridades que los hacen especiales, difíciles de gestionar. Es por eso que la gestión de proyectos llevada a cabo por personas sin experiencia previa en la gestión de proyectos de Business Intelligence conlleva un alto riesgo. Todo ello provoca que el índice de éxito de este tipo de proyectos sea, en comparación con proyectos de desarrollo de software, mucho menor.
Requerimientos genéricos y acordados
Obtener los requerimientos a partir de documentos generados por los usuarios puede, a primera vista, verse como algo altamente positivo, ya que permitiría cerrar la fase de obtención de requerimientos de manera simple. Sin embargo, utilizar esta metodología conlleva un gran riesgo: Obtener requerimientos demasiado específicos.
La obtención de requerimientos se debe realizar a partir de reuniones con los distintos usuarios del sistema. Durante estas reuniones, los usuarios deben exponer sus necesidades mientras que el encargado de obtener los requerimientos deberá interponer preguntas cuestionando estos requerimientos y dirigiendo a los usuarios a un punto de convergencia, a un acuerdo donde sus necesidades se vean cubiertas por los diferentes requerimientos definidos.
La documentación de los requerimientos por parte de los usuarios, previa a estas reuniones, es de gran ayuda para que los usuarios tengan claro qué necesitan de la solución de Business Intelligence. Sin embargo, esa información no debería pasar directamente a la lista de requerimientos del proyecto sin antes efectuar esta serie de reuniones con el objetivo de refinar y acordar esos requerimientos, para así amoldarlos a todos los usuarios.
A continuación se presentan un par de ejemplos sobre especificidad de requerimientos como muestra del riesgo que esto supone.
Sobrecoste del proyecto
El primer ejemplo trata del aumento de coste del proyecto a partir de una mala toma de requerimientos.
Imaginemos un usuario qué necesita disponer de un informe de ventas para el mes en curso para así poder monitorizar posibles desviaciones respecto a los objetivos definidos. El fin de este informe es el de poder disponer nuevas medidas para reconducir la situación en caso de desviaciones negativas.
Ahora imaginemos otro usuario que necesita información de las ventas del mes anterior para poder hacer el informe mensual de cierre de ventas.
La obtención de requerimientos directamente de los usuarios sin la posibilidad de modificación de aquellos, supone la definición de dos informes diferentes:
- Ventas del mes actual
- Ventas del mes anterior
Sin embargo, podría ser que estos dos informes pudieran ser fusionados en uno solo. En el caso en que ambos informes necesitaran diferentes columnas, es muy probable que podamos llegar a un acuerdo para fusionar ambos informes y generar uno solo con la fusión de ambos conjuntos de columnas. De esta manera, un solo informe sería suficiente para poder dar servicio a ambos usuarios. Esto significaría una reducción en la carga de trabajo en la fase de diseño y desarrollo, en la gestión del proyecto, en las pruebas y en la puesta en marcha del proyecto. Asimismo, también reduciría el coste de mantenimiento del proyecto una vez éste estuviera en producción.
El uso de personal con experiencia en proyectos de Business Intelligence durante la toma de requerimientos permitiría detectar escenarios como éste.
Mi experiencia personal me remite a casos en los que, a partir de una lista original de más de 200 informes, se pudo reducir el número de informes final a poco más del 50 (una reducción del 75%).
Gracias a esto se pudo llevar a cabo el proyecto. Si hubiésemos tenido que hacer una valoración del proyecto a partir de los requerimientos iniciales, se habría superado el presupuesto y por tanto el proyecto no se habría llevado a cabo.
Definición incompleta de dimensiones
El segundo ejemplo trata de la definición de dimensiones a partir de los informes específicos requeridos por los usuarios.
La definición de los informes basados en las necesidades de un usuario suele ser muy específica. Es decir, el usuario se concentra en las columnas necesarias únicamente para su informe. Por tanto, los requerimientos obtenidos a partir de informes de usuario suelen ser pobres, limitantes y poco generalistas.
El diseño de una solución a partir de estas especificidades supone tener una visión incompleta del ámbito global del sistema. Lo cual significa que definir los requerimientos de un sistema de Business Intelligence a partir de los informes de usuario o de la visión que los usuarios pueden tener de la solución a partir de los informes que necesitan, es un enfoque erróneo.
Volviendo al ejemplo de las ventas por mes, la toma de requerimientos realizada por una persona inexperta podría limitar la dimensión temporal a una granularidad a nivel de mes (y, otorgándole un voto de confianza, con agregaciones a nivel de trimestre, semestre y año).
Esta definición de la dimensión temporal es claramente limitante y erróneo, puesto que las transacciones de venta están definidas a un nivel más bajo (por supuesto a nivel de día, o quizá a nivel de hora, minuto y segundo).
Lo mismo puede suceder con cualquier otra dimensión asociada a una tabla de hechos. Si basamos los requerimientos en los informes o en lo que los usuarios creen que necesita el nuevo sistema de Business Intelligence, podemos caer en el error de definir dimensiones con una granularidad superior a la real, y podemos obviar información útil que podría proporcionar un análisis con un alto valor añadido en el futuro.
Conclusión
La obtención de requerimientos en un proyecto de Business Intelligence es una tarea clave para el éxito del proyecto.
Su ejecución requiere un alto nivel de experiencia en proyectos de Business Intelligence para poder llevarla a cabo con las máximas garantías de éxito. En caso contrario, estaremos poniendo trabas al proyecto, incrementando las posibilidades de fracaso.
El sobrecoste del proyecto y la definición errónea de dimensiones son dos de las consecuencias de una mala definición de los requerimientos. La primera puede ser la causa de cancelación del proyecto. La segunda supone un sobrecoste en las tareas de mantenimiento evolutivo y la pérdida de confianza en la solución de Business Intelligence.
A la hora de definir un proyecto de Business Intelligence y definir los requerimientos de éste, vale la pena invertir en experiencia. En caso contrario, este error puede salir muy caro.