El éxito de un proyecto de Business Intelligence (BI) suele medirse en función de las funcionalidades del sistema. Si el producto final cumple los requerimientos funcionales y técnicos, el proyecto es un éxito. Sin embargo, el éxito real de un proyecto dista bastante de esto.
En este artículo, puedes encontrar los 5 factores más importantes que considero que un sistema debe cumplir aparte del cumplimiento obligado de los requerimientos funcionales y técnicos del proyecto, para ser considerado un éxito.
1. Grado de implantación del sistema BI actual y de satisfacción del usuario final
Un proyecto cuyo uso esté por debajo de unos mínimos concretos no puede considerarse un éxito. Por tanto, hay que plantearse preguntas cómo:
- Cuántos usuarios utilizan el sistema de BI para la toma de decisiones inteligente?
- Cuántas decisiones toman los usuarios ahora que no podían tomar con anterioridad a la implantación del sistema?
- Qué impacto económico tienen esas decisiones?
Si los usuarios mayoritariamente no usan el sistema, lo usan a medias o no están contentos con las funcionalidades de éste, ya podemos haber creado una solución que cumpla el 100% de las especificaciones iniciales, que el proyecto no puede ser considerado un éxito.
Una auditoría permite tener visibilidad de estos indicadores de uso y satisfacción de los usuarios.
2. Uso de mejores prácticas para la facilitación del mantenimiento
Cuando se entrega el proyecto estamos tan solo en el principio de la vida de éste. En ese punto empieza una etapa en la que necesitaremos evolucionar la solución inicial. Ese mantenimiento puede ser de dos tipos:
- Evolutivo: Se añaden nuevas funcionalidades a la solución inicial debido a nuevas necesidades de los usuarios.
- Correctivo: Se corrigen incidencias detectadas en la versión actual.
Sea cual sea el motivo de este mantenimiento, un objetivo es que el coste de modificar el sistema sea bajo. Y esto tiene una especial relevancia en el caso del mantenimiento correctivo, ya que los usuarios no pueden utilizar ciertas funcionalidades del sistema que deberían estar disponibles.
El uso de mejores prácticas y estándares de BI en el diseño y desarrollo de la solución, facilitará la comprensión de ésta por parte del equipo de mantenimiento, reduciendo el tiempo dedicado a generar una nueva versión. Esta reducción de tiempo tiene una serie de implicaciones:
- Aumento de la aceptación del trabajo realizado por el equipo de mantenimiento por parte de los usuarios.
- Reducción de costes.
- Disminución de la frustración del equipo al no encontrarse con un diseño y un código difícil de entender.
Una auditoría permite identificar el uso de mejores prácticas y estándares de BI en el desarrollo de una aplicación. De hecho, una auditoría en una fase inicial como la de diseño y previa al desarrollo permitiría prevenir situaciones no deseadas de antemano.
3. Optimización de recursos del sistema que aseguren un mínimo TCO
En un post anterior titulado «Calidad en un sistema de BI – Un beneficio para todos«, ya os hablé de la efectividad como uso inteligente de los recursos para obtener el máximo rendimiento de los componentes del sistema.
Mi experiencia me dice que este concepto es a menudo obviado en los proyectos, que basan el éxito en términos de rendimiento en el sobredimensionamiento del hardware. Si bien es cierto que esta estrategia es efectiva, no es la que más interesa al cliente, ya que éste estará incrementando sus costes cuando hay otras alternativas para obtener un buen rendimiento.
Pongamos como ejemplo la transferencia de datos entre dos sistemas informáticos situados en dos ciudades distintas. Si el consumo de datos debe realizarse una vez al día (e.g. carga de datos nocturna), el volúmen no excede los 100 MB y hay la opción de transferir los datos mediante un FTP a través de una red pública de datos como Internet, es realmente necesario tener una conexión punto a punto entre los dos sistemas? No hay duda de que hay beneficios con esta opción, pero realmente vale la pena pagar un sobrecoste adicional?
Una auditoría permite analizar los componentes del sistema BI y su uso, para poder detectar sobredimensionamientos e infrautilizaciones de éstos que podrían significar un aumento indeseado del TCO.
4. Revisión de documentación técnica y de usuario
Partamos de la base de que hay cierta documentación. Cualquier proyecto sin documentación no debería ser aceptado.
La documentación es el legado que el equipo de trabajo que ha desarrollado una solución de BI deja al equipo de mantenimiento y a los usuarios. Si la calidad de la documentación es pobre o poco detallada, es solo cuestión de tiempo para que los problemas empiecen a surgir.
El equipo de mantenimiento necesita no solo tener acceso a la documentación sino a los motivos que llevaron al equipo de proyecto a tomar ciertas decisiones. Si ese conocimiento no está documentando, el equipo de mantenimiento posiblemente no entienda porqué las cosas se hicieron de una manera concreta, a priori mejor que la utilizada, en su momento. Y esto puede suponer avanzar por un callejón sin salida para finalmente ver el motivo por el cual algo se hizo en su día de una manera concreta, con la pérdida de tiempo que ello supone.
Por su parte, tanto el equipo de soporte como los mismos usuarios, se enfrentarán a dudas frente a una nueva solución. Y es obvio pensar que buscarán en la documentación la respuesta a estas dudas. Por tanto, la documentación de usuario debería estar escrita pensando en esas dudas, basándose en el perfil del lector (el usuario) y su capacidad de comprensión y asimilación. El lenguaje utilizado por personas técnicas y de negocio suele ser diferente, el nivel de detalle requerido para poder comprender ciertos conceptos, también. Si no se tienen en cuenta estos conceptos, la documentación puede llegar a ser críptica para los usuarios.
Una auditoría permite identificar situaciones en las que la documentación no aporta información útil al equipo de mantenimiento, carece de información clave y no se adapta al perfil del lector.
5. Valoración independiente del trabajo realizado por el equipo de BI
Uno de los mayores riesgos a la hora de realizar un proyecto informático, es el exceso de confianza. El hecho de tener un diseñador experto no implica que sus decisiones vayan a ser las más apropiadas. Hasta los más grandes genios se equivocan. Por tanto, porqué correr ese riesgo dejando toda la responsabilidad del diseño de un componente a una sola persona? La respuesta está en la reducción de costes para el implementador de la solución. Sin embargo, un fallo en el diseño puede tener grandes implicaciones a nivel de costes en el futuro (e.g. aumento de costes en el mantenimiento evolutivo).
Mi recomendación es que, especialmente en la fase de diseño, las decisiones deberían ir acompañadas de una lista de alternativas y un análisis de puntos a favor y en contra (por obvias que sean), para poder decidir de manera objetiva qué interesa más al proyecto. Este análisis nos permitirá ver opciones que de otro modo quedarían escondidas y que podrían aportar nuevas ideas y mejoras a una solución única.
Una auditoría independiente y libre de intereses permite analizar los requerimientos y la solución propuesta, identificando alternativas y planteando preguntas cuyas respuestas no estén documentadas, para así poder enriquecer el diseño de la solución final, cosa que revertirá en beneficios a medio y largo plazo.
Conclusión
Además de las funcionalidades del sistema y el cumplimiento de los requerimientos, existen otros factores que son decisivos a la hora de evaluar el éxito de un proyecto y que suelen pasar desapercibidos por la presión para cerrar y entregar los proyectos.
Una auditoría del sistema BI permite comprobar el grado de cumplimiento de estos factores, para asegurar el éxito del proyecto antes de darlo por concluido.
Si consideras que estos puntos son importantes y que tu solución de BI actual podría no tenerlos en cuenta, o si estás pensando en implementar o estás implementando en estos momentos una solución de BI y necesitas un experto que audite el trabajo realizado por el equipo de proyecto antes de que sea demasiado tarde, contacta conmigo para pedir una auditoría de tu sistema BI.