Customización vs. Mantenibilidad

 

Toda solución analítica tiene como objetivo satisfacer los requerimientos de obtención de información de los usuarios para la toma de decisiones. Sin embargo, este no es el único objetivo a tener en cuenta. Existen otras cuestiones que debemos tener en cuenta y que son tan o más importantes que el mero hecho de satisfacer los requerimientos de los usuarios.

Uno de ellos es la mantenibilidad de la solución tecnológica, tal y como se indica en el artículo «Calidad en un sistema de BI – Un beneficio para todo«. En este artículo se plantea el conflicto entre estos dos objetivos.

 

Satisfacción del usuario

La importancia de satisfacer al usuario va más allá del mero hecho de que la solución tecnológica cumpla con los requerimientos.

Un proyecto que no dé al usuario aquello que necesita, es un proyecto que no será utilizado por el usuario. Y por tanto, un fracaso rotundo. De ahí la importancia de satisfacer los requerimientos de usuario.

No obstante, debemos plantearnos siempre la necesidad real de ese requerimiento si no queremos estar altamente condicionados por los requerimientos. Es decir, el mero hecho de que un usuario indique que algo es importante no significa que realmente lo sea. Una lista de deseos del usuario no es motivo suficiente para hipotecar otros objetivos de un proyecto que pueden ser tan o más importantes que los requerimientos de usuario.

En el caso de una solución analítica genérica, podemos aplicar customizaciones para satisfacer algunos requerimientos de usuario concretos. Pero, ¿cómo afectaría esto al proyecto en el futuro?

Mantenibilidad

Un proyecto tecnológico no se acaba en el momento en que éste se entrega. Después de poner el proyecto a disponibilidad de los usuarios, empieza la fase de mantenimiento.

En esta fase, hay que realizar tareas correctivas y evolutivas que requieren la modificación de la solución tecnológica. Estas modificaciones tienen un coste que se cuantifica en términos de mano de obra y a la postre en un coste económico.

La mantenibilidad indica el grado de facilidad del mantenimiento de una solución. A mayor grado de mantenibilidad, menor coste de mantenimiento. Por tanto, es muy importante mantener un grado de mantenibilidad alto. De esta manera, conseguimos reducir el coste de las tareas de mantenimiento, tanto correctivo como evolutivo. Y debemos tener en cuenta que esta fase acaba siendo la que se dilata más en el tiempo, por muy largo que haya sido el periodo de desarrollo de un proyecto.

Conflicto entre objetivos

La mantenibilidad está reñida con otros objetivos de todo proyecto informático como pueden ser la eficiencia y la satisfacción completa de los requerimientos de usuario.

Un ejemplo clásico de requerimiento de usuario en una solución analítica es el de la construcción de un informe que obtenga una información concreta en el mínimo tiempo posible.

Ante este requerimiento es importante plantearse un par de cuestiones:

  • ¿Es posible reducir el tiempo de ejecución de una consulta concreta creada por una solución analítica genérica? Las consultas creadas a partir de soluciones genéricas suelen no ofrecer el mejor rendimiento posible, ya que una solución a medida estará más ajustada. Por tanto, sí es posible reducir el tiempo de consulta.
  • ¿Cuál es el tiempo máximo que un usuario puede esperar para tener la información que obtiene de la consulta, que le permitirá tomar una decisión con valor para su organización? Esta respuesta la tiene que proporcionar el usuario. Lo que sucede a menudo es que el tiempo máximo que pide el usuario no es para la toma de decisiones sin pérdida de la oportunidad de la información, sino que responde al tiempo máximo que el usuario quiere esperar delante de la pantalla a obtener los resultados.

Ante estas dos cuestiones, debemos valorar qué es más importante: Ofrecer una respuesta rápida al usuario (reduciendo el grado de mantenibilidad de la solución analítica) o mantener un grado de mantenibilidad alto en nuestra solución (aunque ello implique la no satisfacción del usuario).

Mi opinión es que, dentro de lo que sea posible, se debe hacer un esfuerzo por mantener el grado de mantenibilidad de una solución analítica, intentando minimizar las customizaciones. Para ello es muy importante comunicar correctamente los objetivos tanto a los usuarios como a los sponsors del proyecto (para buscar su apoyo en la mediación con los usuarios). De esta manera conseguiremos contener el coste de mantenimiento de la solución analítica, que no deja de ser otro objetivo clave.

Conclusiones

La satisfacción de los requerimientos de usuario es uno de los objetivos primordiales en todo proyecto de creación de una solución analítica, aunque no el único.

Mantener un grado de mantenibilidad alto permite reducir los costes en la fase de mantenimiento de un proyecto. Y reducir los costes es un objetivo de vital importancia.

Existen conflictos entre objetivos, como puede ser entre la satisfacción de los requerimientos de usuario y la mantenibilidad de una solución.

La comunicación efectiva de los objetivos a sponsors y usuarios nos permite negociar las posibles situaciones de conflictos entre objetivos.

Efectividad de un proyecto de Business Intelligence

 

El éxito de un proyecto de Business Intelligence (o de Big Data) es una puerta a la continuidad. Es la diferencia entre seguir evolucionando una plataforma analítica de acuerdo con una estrategia bien definida o la siembra de dudas respecto a la conveniencia de seguir con esa línea.

La situación en la que nos hallamos es la siguiente: Después de muchos esfuerzos, nuestro proyecto de Business Intelligence ha llegado a su fin. Los usuarios ya tienen acceso a todas las funcionalidades analíticas estipuladas en los requerimientos. Pero, ¿cómo saber si el proyecto ha sido un éxito?

 

Factores de medida de éxito

Tradicionalmente el éxito de un proyecto se mide en base a los siguientes factores:

  • Cumplimientos de fechas indicadas en la planificación
  • Cumplimiento de los requerimientos
  • Ajuste sobre el presupuesto inicial

Estos tres actores suelen ser la vara de medir utilizada para determinar el éxito de un proyecto.

Sin embargo hay un par de factores muy importantes que suelen ser obviados.

  • Adopción de la solución por parte de los usuarios
  • Incremento de la efectividad en la toma de decisiones

Adopción de la solución por parte de los usuarios

Si después de realizar un proyecto los usuarios no utilizan la solución proporcionada, el proyecto debe considerarse un fracaso.

La inversión realizada tanto económicamente cómo en recursos humanos bien merece dar su fruto. Sin un beneficio para la organización el proyecto se convierte en un foso donde se han arrojado horas y dinero. Y esto es cierto, independientemente de que se hayan cumplido todos los objetivos de negocio detallados en los requerimientos del proyecto.

En ese caso el retorno de inversión (ROI) del proyecto será nulo. Y por tanto, desde el punto de vista de gestión económica del proyecto, éste será un gran fiasco. Todo proyecto debe proporcionar un retorno. Y un proyecto que no sea usado por los usuarios no tendrá un retorno de la inversión.

Incremento de la efectividad en la toma de decisiones

Si el punto anterior mide de manera cuantitativa la introducción de la solución en la base de usuarios ahora no centraremos en un análisis cualitativo.

En este caso, queremos medir cómo afecta a la toma de decisiones y sus resultados la introducción de la nueva solución analítica.

Para poder realizar el análisis comparativo es necesario disponer de datos de efectividad en la toma de decisiones con el modelo antiguo (antes de la introducción de la nueva solución). Estos datos son necesarios porque los utilizaremos como grupo de control sobre el que podremos comparar los resultados.

Una vez la nueva solución esté en uso, deberemos obtener datos de eficiencia para así comparar el rendimiento de los empleados antes y después de la adopción de la nueva solución.

Sin embargo también es necesario realizar ese análisis con los usuarios que no hayan adoptado la nueva solución. ¿Por qué? Porque pueden darse situaciones ajenas a la nueva solución que afectan por igual a los grupos. Este análisis del grupo de control y del nuevo grupo nos permitirá identificar si las diferencias se deben única y exclusivamente a la nueva solución adoptada o a otros factores.

Si nuestro análisis muestra que el segundo grupo obtiene mejores resultados podremos deducir que éstos se deben a la adopción de la solución. En cambio si los resultados son peores que los del grupo de control, podremos deducir que la nueva solución está empeorando los resultados.

Además podremos cuantificar esa mejora o pérdida en función de la diferencia de los resultados antes y después de la adopción de la nueva solución en ambos grupos. Podría darse que ambos mejoraran su rendimiento. En este caso, el análisis porcentual de la mejora nos permitiría identificarla cuantitativamente.

Consideraciones

En la fase incial de la adopción de la nueva solución, es posible que los resultados obtenidos sean inferiores a los que puedan obtenerse a medio plazo. Este hecho deberá tenerse en cuenta a la hora de valorar el éxito del proyecto. Por eso es conveniente realizar estos análisis de manera periódica, y realizar un seguimiento y dar formación a los usuarios para que puedan obtener el mayor rendimiento de la solución. De esta manera, es posible conseguir mejorar los resultados obtenidos inicialmente.

Conclusión

El éxito de un proyecto de Business Intelligence es de vital importancia para la continuidad de proyectos en una organización. Y para poder determinar el éxito real del proyecto, es necesario utilizar los indicadores adecuados.

La adopción y la productividad son esenciales para medir el éxito de un proyecto de BI. Si los pasamos por alto, podríamos tener una percepción errónea de la realidad. Y eso sería un estrepitoso fracaso en lo que se refiere a gestión de proyectos.

Definición de requerimientos en un proyecto de Business Intelligence

 

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.