La importancia de una auditoría de BI

La construcción de una solución de Business Intelligence (BI), podría compararse a la construcción de un edificio. Necesitamos cimentar esta solución sobre una base sólida, que nos permita construir los diferentes proyectos, con la seguridad de estar aposentados sobre una estructura que nos permita crecer.

Pero, si todo el mundo acepta esto en la construcción, ¿porqué hay organizaciones que optan por otra estrategia a la hora de construir una solución de BI?

Una base poco sólida

Hace tiempo, realicé un proyecto para un cliente que cometió un grave error. A este proyecto lo bauticé como “La torre de Pisa”.

Este cliente contactó conmigo porque en su organización tenían varios problemas con su solución de BI. El más importante de ellos era funcional. No conseguían obtener resultados correctos. Querían un servicio de consultoría experto, que les permitiese identificar y solucionar los errores existentes. Habían intentado solucionarlo con la consultora que les había construido la solución de BI, pero éstos fueron incapaces de hallar la solución a dichos problemas.

Dada la urgencia del cliente, mi objetivo se centró única y exclusivamente en la resolución de las incidencias detectadas. Por tanto, dejé de lado mi enfoque habitual (top-down), para focalizarme en los problemas identificados. Sin embargo, rápidamente pude observar que los problemas que causaban dichas incidencias, tenían su origen en fallos de diseño de la solución de BI existente.

Lo siguiente que hice, fue un informe detallando las implicaciones de estos errores de diseño dentro del sistema junto con un análisis de pros y contras del hecho de mantener o solucionar esos errores.

Pero también hice hincapié en el hecho de haber construido un sistema de BI sin ningún tipo de validación de la calidad de éste por parte de nadie. No habían hecho ningún tipo de indagación en clientes anteriores de esa consultora ni habían optado por la validación del diseño de un experto sobre el trabajo de su proveedor de servicios. Habían aceptado el proyecto con una fe ciega. Y se trataba de un proyecto con una visibilidad transversal en su organización, donde las repercusiones podían afectar a la toma de decisiones en todas las áreas y niveles de la organización.

Una decisión arriesgada

Estaban construyendo un gigante con pies de barro. En ese momento, les puse como ejemplo la torre de Pisa. Se encontraban en el punto en el que vieron como la torre estaba inclinada. Era el momento de decidir qué hacer. Si seguían adelante, corrían el riesgo de que la solución de BI fuera imposible de mantener en un futuro, teniendo que realizar una gran inversión para reconstruirla. Si decidían solucionar los problemas de base, tendrían un sobrecoste no presupuestado, pero a la larga, el coste sería mucho menor.

Mi cliente quería una solución rápida. Es por eso por lo que optó por seguir adelante con una resolución de las incidencias detectadas inicialmente, sin solventar los problemas de base en el diseño de su solución de BI. Así pues, me dediqué a solucionar las incidencias, no sin antes advertir del riesgo que ello podría suponer de cara al futuro, en el caso de que quisieran ampliar la solución de BI existente.

Una decisión errónea cae por su propio peso

Creo que fue al cabo de un par de meses de haber acabado el servicio por el que me contrataron, que recibí una llamada del mismo cliente. Estaban desesperados. Tenían un nuevo proyecto de BI en fase de desarrollo, pero no había manera de hacerlo funcionar. Ni su proveedor de servicios habitual ni su equipo interno eran capaces de seguir adelante con el proyecto. Cuando intentaban implementar una nueva funcionalidad, provocaban que otras funcionalidades ya existentes dejaran de funcionar. Se encontraban en un callejón sin salida. La torre de Pisa no podía crecer más.

Esta vez, mi cliente optó por un enfoque diferente. Me pidió que evaluara la posibilidad de finalizar el proyecto con el que estaban atascados, pero también una estimación del coste que supondría la reconstrucción de su solución de BI para poder disponer de un sistema escalable que pudiera crecer en el futuro de manera simple.

Al presentar mi propuesta, les indiqué la importancia de evaluar los costes a largo plazo. Ese había sido su gran error la primera de contactaron conmigo. En un proyecto de BI, es muy importante tener en cuenta los futuros proyectos a la hora de calcular el Retorno de Inversión (ROI). Así lo hicieron. Y llegaron a la conclusión más acertada en su situación. Decidieron reconstruir su solución de BI.

Tal fue la confianza que obtuve del cliente, que, en lugar de contratar los servicios de una consultora de más envergadura que StraBIA, decidieron encargarme el proyecto de reconstrucción de su solución de BI íntegramente. Aquello fue el principio de una satisfactoria relación profesional.

Conclusión

Una solución de BI es un sistema con una amplia visibilidad en una organización, ya que se utiliza para la toma de decisiones a todos los niveles y en todas las áreas de ésta. Al ser un sistema tan importante, es necesario estar plenamente convencido de que su construcción satisface los requerimientos de un sistema de BI. Esto goza aún de más importancia por el hecho de ser un tipo de proyecto con un número de expertos muy bajo si lo comparamos con proyectos de desarrollo de aplicaciones, por ejemplo.

Siempre que realizo un proyecto en un nuevo cliente con una solución existente de BI, intento dedicar un poco de tiempo a su análisis, identificando áreas de mejora. Sé que, haciendo esto, algunos de mis clientes han evitado situaciones desagradables en el futuro. Eso me anima a seguir haciéndolo, aunque no sea StraBIA quien acabe realizando el proyecto.

Afortunadamente, esto no es siempre así, y en ocasiones como la que os acabo de contar, sí que acabamos realizando el proyecto. Y en estos casos, una auditoría del nuevo sistema BI evaluaría la nueva solución con muy buena nota.

Quisiera finalizar con un par de preguntas:

  • ¿Crees que tu actual solución de BI está preparada para crecer manteniendo los niveles de rendimiento, efectividad y mantenibilidad requeridos por tu negocio?
  • ¿Crees que tu actual solución de BI superaría una auditoría?

Si has respondido “No” a alguna de estas preguntas, espero que este artículo te haga reflexionar sobre los riesgos a los que te puedes enfrentar en el futuro.

5 razones por las que necesitas una auditoría de tu sistema de BI

 

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.

Calidad en un sistema de BI – Un beneficio para todos

 

Hablar de calidad es hablar de algo que todo el mundo desea, tanto quien la ofrece como quien la recibe. Esto también es extensible a proyectos de Business Intelligence. Mi experiencia, sin embargo, me ha mostrado que la realidad difiere de esa imagen idílica que rebosa calidad por todos lados.

En este artículo quiero hacer especial hincapié en el concepto de calidad en la implementación de un proyecto BI y los beneficios que aporta a ambas partes: Cliente y proveedor de servicios (externo o interno, cuando se trata del departamento de IT).

El proveedor de servicios desea ofrecer calidad para así poder satisfacer a sus clientes, labrar una reputación y conseguir más proyectos futuros. Por su parte, el cliente desea obtener el máximo rendimiento a su inversión económica, y ésto pasa por obtener calidad.

Qué es calidad en un sistema de BI?

La calidad en un sistema de BI viene dada por los siguientes factores:

  • Rendimiento: Capacidad del sistema de obtener los resultados deseados en poco tiempo.
  • Efectividad: Uso de recursos inteligente y máximo rendimiento de los componentes.
  • Mantenibilidad: Facilidad de crecimiento y mantenimiento del sistema.

Vale la pena dedicar un tiempo a entender cada uno de estos factores.

Rendimiento

El principal objetivo de un sistema de BI es poder proporcionar al usuario la respuesta a un conjunto de consultas. Éstas, mayoritariamente deben analizar un gran volumen de datos. En el mundo actual, el tiempo es dinero. Y tener a un usuario esperando para obtener una respuesta puede tener un gran impacto económico. Aún más, si la frustración por la espera desemboca en un abandono de la solución de BI por parte del usuario. Es por eso que un sistema de BI debe minimizar el tiempo de espera de los usuarios.

Efectividad

Obtener el máximo rendimiento es esencial en cualquier tarea si queremos obtener una buena productividad. La economía de los recursos se halla en las prioridades de cualquier proceso de negocio y también en el día a día de nuestras vidas. En un sistema de BI no debería ser menos. Al aumentar la efectividad, conseguiremos el máximo rendimiento de los componentes del sistema. Y eso se traduce en una reducción de costes de hardware y posiblemente software.

Mantenibilidad

Una solución de BI no es estática, al igual que no lo són los requerimientos de análisis de datos en cualquier organización. Facilitar el crecimiento del sistema permite a las organizaciones poder responder a esos nuevos requerimientos. Pero para poder hacer eso de manera efectiva en tiempo y recursos, debemos construir el sistema de manera que nos permita esas futuras evoluciones.

Importancia de la calidad

Muy a menudo, rendimiento, efectividad y mantenibilidad no son factores que se hallan en la cúspide de las prioridades a la hora de implementar un sistema de BI. En su lugar, encontramos un único factor: la satisfacción de los requerimientos de negocio. Es decir, la funcionalidad del sistema.

La calidad es un concepto técnico. La funcionalidad es un concepto de negocio. El éxito de un proyecto de BI pasa por conseguir ámbos conceptos.

Si tan sólo nos centramos en la funcionalidad, el proyecto puede ser un completo fracaso. Veamos qué sucede en las siguientes situaciones:

  • Lentitud de las consultas: El usuario se frustra y deja de utilizar el sistema.
  • Sobrecarga del sistema informático: El crecimiento del volúmen de datos o la ejecución de consultas más pesadas provocan un desplome del rendimiento. La solución no debe pasar por la ampliación de los recursos hardware, ya que es una solución cara y posiblemente no prevista en los presupuestos de la organización. E inevitablemente, el hecho de padecer un tiempo de respuesta a las consultas alto, hace que el usuario deje de utilizar el sistema.
  • Ampliación de requerimientos de negocio: El coste de ampliación y mantenimiento del sistema es muy alto, con lo que algunos de los requerimientos no son satisfechos a corto plazo. En algunos casos, la falta de presupuesto puede hacer que estos requerimientos no sean implementados. Por lo tanto, el usuario deja de utilizar el sistema.

Y no hace falta decir que si el usuario deja de utilizar el sistema, el proyecto de BI es un completo fracaso.

Cómo asegurar la calidad en un proyecto?

Los factores de calidad anteriormente citados están claramente en conflicto. Por ejemplo, utilizar un código fácilmente mantenible (fácil de entender, estructurado, etc.) puede implicar una penalización en el rendimiento respecto a otros algoritmos más eficientes. Un claro ejemplo es el algoritmo de ordenación: Burbuja vs. QuickSort.

Para poder asegurar una buena calidad dentro de un proyecto, debe haber unas directrices bien establecidas desde el inicio del proyecto. Así como es clave definir la gobernanza de datos en un proyecto de BI, también lo debe ser el nivel de servicio en términos de rendimiento, el uso de los recursos y la facilidad de mantenimiento del sistema de BI.

Tener una estrategia clara y concisa de BI incluye la definición de los factores de calidad del sistema.

Dado el caso que el proyecto ya esté iniciado, una auditoría del proyecto, desde la definición a la implementación, ayudarán a determinar si la calidad se ha tenido en cuenta. Hay que tener en cuenta que suele ser mejor detectar un problema potencial antes de que éste aparezca que una vez ya se ha producido. Si el impacto en los usuarios de negocio ya se ha producido, su confianza en el sistema posiblemente estará amenazada.

Una auditoría puede ser iniciada tanto por el cliente como por el proveedor de servicios, como mecanismo de control interno a la calidad. Si es el proveedor de servicios quien inicia la auditoría, éste estará ofreciendo al cliente una mejor imagen por lo que respecta al servicio.

Resumen

La calidad de un sistema de BI aporta beneficios tanto al proveedor de servicios como al cliente. Con la calidad ganan ambas partes. Es una situación de win-win.

Hay tres factores esenciales en la calidad de un sistema de BI: Rendimiento, efectividad y mantenibilidad.

Estos tres factores entran en conflicto los unos con los otros, lo que requiere de un equilibrio entre ellos. Este equilibrio se consigue mediante la aplicación de mejores prácticas que aseguren que se cumplirán ciertos niveles mínimos identificados en la estrategia del proyecto de BI.

Una auditoría permitirá identificar el nivel de calidad de un sistema de BI.