Efectividad de un proyecto de Business Intelligence

Posted on by Àlex Caminals

 

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.

Top 3 errores en el diseño del modelo de datos de un Data Warehouse

Posted on by Àlex Caminals

 

El componente principal de una solución de Business Intelligence es el Data Warehouse, el almacén de datos donde guardamos toda la información que vamos a analizar. ¿Cómo saber si el diseño del modelo de datos de tu Data Warehouse, y por extensión de tu solución de Business Intelligence es de calidad o no? ¿Cómo puedes saber si el dinero que has invertido en esta tarea ha revertido en una solución de calidad?

En este artículo te presento los 3 errores más comunes en el diseño de modelos de datos de un Data Warehouse. Esta lista ha sido elaborada a partir de mi experiencia a lo largo de más de 17 años diseñando soluciones de Business intelligence. Es posible que haya otros errores de gran calado que se repitan en otras implementaciones de soluciones de Business Intelligence. Pero yo os hablaré de las que me he encontrado más a menudo a lo largo de mi carrera como consultor.

#1 Un elevado número de joins

Una solución de Business Intelligence tiene como objeto analizar un gran número de datos de manera eficiente. La operación más costosa en el acceso a las tablas donde se encuentran los datos es la join entre dos tablas (lo que se conoce como «cruzar» la información de dos tablas). Por tanto, minimizar el número de joins es vital para obtener un gran rendimiento en las consultas.

Para ello existe el modelo dimensional. Al utilizar esta técnica de diseño del modelo datos, minimizamos el número de joins aumentando así el rendimiento de las consultas respecto al diseño de datos transaccional. En contraposición, una solución de Business Intelligence que trabaje directamente sobre el modelo transaccional (con un elevado número de joins), implicará un alto coste en el acceso a los datos.

En varias ocasiones me he encontrado con aparentes diseños dimensionales basados en realidad en vistas y no en tablas. Es decir, sobre el papel el modelo era dimensional. Pero, sin embargo, en vez de tablas se estaban utilizando vistas. Por tanto, las consultas acababan accediendo a una gran cantidad de tablas, realizando a la vez una gran cantidad de operaciones de join. En este caso, el rendimiento de las consultas es, evidentemente, muy bajo.

#2 Diseñar las tablas a partir de los informes finales

Cuando diseñamos el modelo de datos es importante tener en cuenta las necesidades de acceso a la información de los usuarios. Al hacer esto, somos capaces de identificar las métricas e indicadores por una parte, y las dimensiones necesarias para el modelo de negocio que vamos a diseñar. Sin embargo, basar nuestro diseño únicamente en los informes, suele acarrear errores de diseño.

Por una parte nos alejamos de la metodología de diseño que nos proporcionará esas dimensiones y esas tablas de hechos sobre las cuales basamos el modelo dimensional. Por otra estaremos ligando nuestro modelo de datos a una visión particular de los datos (la de los usuarios). Y en el momento en que los usuarios quieran modificar esa visión de los datos, la tabla que habremos creado sobre unos informes específicos, deberá ser modificada para poder incluir la nueva información que el usuario quiera visualizar.

El mero hecho de añadir una columna a un informe puede conllevar la modificación de una tabla, y por tanto de la carga de datos. Y el coste de realizar ese cambio será muy elevado.

Cierto es que el hecho de disponer de tablas con toda la información necesaria para un informe nos permite acceder a esa información sin necesidad de hacer ninguna join. Sin embargo, diseñar un modelo de datos en base a este sistema de trabajo, no permite reaprovechar las distintas tablas del Data Warehouse, ya sean de dimensiones o de hechos. De esta manera, el modelo de negocio que vamos a diseñar en nuestras herramienta de Business Intelligence, estará ligado no a un modelo de datos genérico sino a los diferentes informes de usuario.

#3 No usar claves sinteticas (surrogate keys)

Es común que las diferentes tablas de nuestros sistemas transaccionales dispongan de claves primarias (claves que identifican unívocamente los diferentes registros de la tabla y que a la vez no pueden ser nulos).

Los diseñadores inexpertos suelen cometer un grave error confiando en estas claves primarias para ejercer como claves primarias del Data Warehouse. Sin embargo, hay varias razones por las cuales utilizar estas claves primarias de los sistemas transaccionales no está recomendado a la hora de diseñar un Data Warehouse.

Estas claves primarias transaccionales pueden variar con el tiempo. Situaciones como migraciones y cargas masivas de datos de otros sistemas informáticos, pueden modificar los valores de esas claves primarias o producir duplicados. Esto puede ser algo relativamente sencillo de corregir en las tablas dimensiones. Pero adaptar esos nuevos valores en las diferentes tablas de hechos (cabe recordar que son las tablas con más volumen de registros en un Data Warehouse), supone un gran esfuerzo, que a menudo resulta demasiado grande.

Además, esas claves primarias transaccionales pueden contener valores alfanuméricos. Este hecho penaliza el rendimiento del sistema ya que la longitud del registro de las tablas de hechos se ve incrementado y por tanto el throughput (número de registros por unidad de espacio en disco) de acceso a los datos disminuye.

El uso de claves sinteticas con valores numéricos (de tamaño mucho menor que las claves alfanuméricas) permite optimizar el acceso a las tablas de hechos mejorando así al rendimiento de las consultas.

Conclusión

El diseño del modelo de datos de un sistema analítico es esencial para obtener un buen rendimiento en las consultas. Un elevado número de joins, un diseño orientado a los informes finales, y el uso de las claves primarias del sistema transaccional son tres grandes errores evitar en nuestra solución de Business Intelligence.

Para evitar caer en estos errores es primordial contar con un equipo de expertos con una amplia experiencia en el diseño de soluciones de Business Intelligence. Si una solución existente no ofrece el rendimiento esperado y es difícil de mantener, es posible que contenga alguno de estos errores.

Si una solución de Business Intelligence incluye alguno de estos diseños erróneos, estos deberán estar debidamente justificados. De no ser así, sabremos que se trata de un error de diseño.

¿Realmente sabes cómo está diseñada tú solución de Business Intelligence por dentro? Si tu respuesta es «No», una auditoría puede ayudarte. Y si estás pensando en crear una nueva solución de Business Intelligence, te recomiendo que acudas a un experto que pueda verificar los diseños generados por tu proveedor de servicios. Una segunda opinión, una verificación de los diseños antes de que sea demasiado tarde, te puede salvar de males mayores en el futuro.

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

Posted on by Àlex Caminals

 

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.

¿Necesitas a alguien que te asesore en el área del Business Intelligence?

Posted on by Àlex Caminals

 

En la gran mayoría de clientes a los cuales he ofrecido servicios de consultoría, me he encontrado con personas con un entendimiento del Business Intelligence (BI) bastante limitado. No los culpo. Supone un cambio de paradigma respecto a la manera tradicional de gestionar una organización, que es lo que la gran mayoría había aprendido.

En estos casos, mi experiencia me dice que lo mejor es abrirles la mente, haciéndolos reflexionar.

 

Hoy quiero que dediques unos minutos a leer este artículo y a reflexionar un poco. Seguramente es un tiempo precioso para ti, pero te aseguro que bien invertido puede reportarte grandes beneficios.

¿Has necesitado una solución de BI en el pasado?

A continuación encontrarás seis preguntas.

Te pido que después de cada una, dediques un tiempo a pensar en ocasiones en tu vida en las que esa situación se ha dado, si ha habido alguna. Y después, contesta cada pregunta siendo consciente de esas situaciones.

  • Alguna vez has necesitado información sobre tu negocio y no la has tenido a tu disposición?
  • Crees que la información en tu negocio no fluye de manera ágil?
  • Alguna vez has sufrido algún contratiempo en tu negocio por falta de información?
  • Eres consciente de que con acceso a información útil, los empleados de tu empresa podrían tomar más y mejores decisiones?
  • Alguna vez has recibido información demasiado tarde como para poder reaccionar a tiempo y revertir una situación o tendencia negativa?
  • Has tomado alguna vez alguna decisión basada en suposiciones y no en hechos contrastados?

Si has contestado “Sí” a alguna de estas preguntas, es que en esa situación necesitabas una solución de BI.

Piensa en el futuro

Ahora que ya sabes cómo identificar si necesitas una solución de BI, piensa en el futuro.

La toma de decisiones dentro de una organización, cuando se hace de manera racional, basándonos en hechos reales, proporciona resultados más efectivos. Piensa en cómo tener una solución de BI podría mejorar los procesos de tu organización a todos los niveles de decisión.

Es un proceso que requiere, tal y como he indicado al principio del artículo, un cambio de paradigma, un cambio de mentalidad. Pero lo bueno que tienes es que, si te has tomado tu tiempo reflexionando sobre las preguntas anteriores, estás abriendo tu mente a ese cambio. Y cuando entiendas la necesidad, verás el amplio espectro de posibilidades que BI te puede ofrecer.

Conclusión

A pesar de los años que el BI lleva en el mercado, aún hay muchas lagunas acerca de lo que puede aportar a las organizaciones, por parte de los directivos de éstas.

Como asesor de empresas en el ámbito del análisis de datos, me veo en la necesidad de ejercer como evangelizador del BI en muchos casos. Es decir, una de las tareas iniciales consiste en abrir la mente de mis clientes acerca de los beneficios que el BI puede aportar a su organización. Y esto lo consigo a partir de preguntas como las que habéis visto en este artículo.

Finalmente, una vez el cliente ha entendido qué es el BI y qué beneficios puede conllevar su implantación, podemos empezar a hablar de casos concretos.

Y ahí es donde empieza la asesoría. ¿Hablamos?