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.

Veracidad: ¿La 4ª “V” de Big Data?

En el artículo “¿Qué es Big Data?“, os expliqué las tres situaciones que pueden definir un escenario donde es necesario aplicar una solución de Big Data. Éstas se definen como las 3 V’s. Hay gente que incluye otras V’s al hablar de Big Data.

Hoy os hablaré de la V de veracidad, puesto que una lectura errónea de ésta puede llevar a malas interpretaciones.

Calidad de datos

Para realizar el mejor análisis de datos que podamos imaginar, necesitamos disponer de un conjunto de datos completo y con una calidad de datos impoluta.

Estas condiciones son las ideales, pero lo cierto es que la realidad nos presenta escenarios que difieren de esta situación ideal. Es por eso que, durante la carga de datos (ETL), hay que realizar un proceso de verificación de los datos. Es lo que se conoce como el proceso de limpieza de datos, durante el cual se intentan arreglar los datos incorrectos o incompletos para así poder disponer de un conjunto de datos útil para su análisis posterior.

Este proceso de limpieza de datos incluye la aplicación de normas de dominio sobre los datos (e.g. Verificar que la provincia informada corresponde al país informado), de formato (e.g. Los números de teléfono empezarán todos con el código internacional con un “+” al principio y solamente contendrán números a continuación, sin espacios, puntos, guiones, etc.), y de negocio (e.g. El descuento “ABC” no aplica a clientes que compren por un valor inferior al millón de euros anuales).

Así pues, los datos que pueden ser arreglados durante la carga de datos, serán modificados para asegurar una buena calidad, mientras que los que no puedan ser arreglados, serán descartados y marcados como pendientes de arreglar en el sistema origen. De esta manera, conseguimos aumentar la calidad de datos no solo en el repositorio de datos destino de la carga, sino también en los sistemas origen.

Un gran coste en un escenario Big Data

El problema de realizar un proceso de limpieza de los datos durante la carga de éstos, es que es un proceso costoso. Muy costoso.

Sabemos que Big Data trabaja en muchos casos con datos masivos o con la necesidad de disponer de los datos con una latencia (retraso) muy baja. Por tanto, no puede perder ese tiempo en un proceso de verificación y limpieza de datos.

Y aquí aparece la contraposición de intereses. ¿Es Big Data incompatible con el hecho de tener un buen análisis de datos? La respuesta es que no es incompatible, aunque deberíamos analizar qué entendemos por “buen análisis”.

En un escenario tradicional de Business Intelligence (BI), por ejemplo, basado en el análisis de información comercial, es importante que la calidad de datos sea correcta, sin errores. Si el importe de una venta es incorrecto, o si una venta no se carga en el repositorio analítico, no podremos obtener análisis de ventas que muestren un resultado correcto. Es decir, para obtener una visión exacta de la realidad, es necesario aplicar un proceso de limpieza de datos para evitar la pérdida de información durante la carga de datos.

Pero, por otra parte, en un escenario de Big Data, por ejemplo, basado en la obtención de lecturas de temperatura cada 5″ mediante 100 sensores repartidos por toda la ciudad, ¿es necesario tener una visión exacta de esa realidad? ¿Necesito saber la temperatura media exacta? Seguramente no. Por tanto, situaciones anómalas pueden ser aceptadas sin la necesidad de limpiar los datos.

Incertidumbre

Estas situaciones anómalas pueden introducir errores en los datos. En otras palabras, provocan que la veracidad de los datos y de los resultados del análisis de éstos sea incierto. Pero en Big Data trabajamos con grandes volúmenes de datos. Y tener errores en algunos de ellos, no tiene porqué distorsionar en gran manera el resultado del análisis. Por ejemplo, ¿una temperatura ambiente media de 20,375°C (incluyendo anomalías) sería aceptable si la temperatura real fuese 20,384°C? Estoy convencido de que así es para la gran mayoría de personas.

En Big Data, podemos distinguir entre los siguientes tipos de incertidumbre en función de dónde y cómo se genera ésta:

• Adquisición de los datos: Como ejemplo, pensemos en un sensor, un trozo de hardware, susceptible a errores de lectura. Si la temperatura leída es de 20°C durante 1 hora pero nos encontramos con una única lectura durante este periodo con un valor de 28°C (con su predecesor y sucesor, separados 5″, marcando 20°C ), podemos considerar que se trata de un error de lectura, un error de funcionamiento del sensor.
• Proceso de los datos: Imaginemos ahora, que hay un fallo de comunicación en un sector de la ciudad y no nos llega información durante 30′ de los 20 sensores que hay desplegados en esa zona. Los datos se perderán y no podremos hacer nada al respecto. Pero podemos continuaremos analizando los datos recibidos y mostrándolos en tiempo real. De hecho, para los datos no disponibles, podría mostrar la última información recibida o hacer una previsión en función de datos históricos y los datos del resto de sensores.
• Análisis de datos: El tipo de análisis de datos a realizar también puede introducir incertidumbre. En el caso de una predicción, existe un grado de confianza que debemos elegir. Si utilizamos un algoritmo de clustering para agrupar datos, también introducimos incertidumbre en el análisis. Es decir, el propio algoritmo utilizado incluye cierto nivel de incertidumbre.

Por tanto, Big Data, por sus propias características, introduce de por sí elementos que pueden provocar que el resultado del análisis de los datos no sea fiable al 100%.

Cuando pensamos en Big Data no debemos pensar en el análisi de todos los datos disponibles como en un BI tradicional, mostrando resultados exactos y 100% fiables. Debemos verlo como un análisis con un alto grado de fiabilidad (obtenido a partir del uso de datos masivos), pero con cierto grado de incertidumbre, que proporcionará información útil para la toma de decisiones.

Conclusión

El uso de Big Data viene precedido por una necesidad, ya sea de tratar un escenario con un gran volumen de datos, con una velocidad de tratamiento de éstos muy elevada o con variedad de tipos de datos, entendiendo ésta como el uso de tipos de datos no convencionales. Esto se conoce como las 3 V’s del Big Data.

Incluir una cuarta V para la veracidad puede causar confusión, puesto que no se trata de una necesidad de veracidad la que hace que tengamos que aplicar Big Data, tal y como sucede con el volumen, la velocidad y la variedad.

La realidad es que Big Data introduce cierto grado de incertidumbre durante el proceso de adquisición, proceso y análisis de datos.

Sin embargo, a pesar de este grado de incertidumbre, el hecho de trabajar con datos masivos nos permite obtener análisis de datos con una fiabilidad muy alta, lo cual justifica el uso de Big Data.

¿Qué es Big Data?

 

El Big Data está de moda. Es interesante comprobar como la gran mayoría de la gente ha oído hablar del Big Data alguna vez aunque no pertenezcan ni al mundo empresarial ni tecnológico.

Pero también es muy interesante oir la gran variedad de definiciones que afloran cuando la gente es preguntada acerca del Big Data. En este artículo voy a intentar resolver esa duda que muchos tenéis: ¿Qué es Big Data?

 

Definición de Big Data

Big Data es un conjunto de técnicas y tecnologías que permiten el análisis de datos.

Estas técnicas y tecnologías nos permiten almacenar, transformar, analizar y visualizar los datos de manera eficiente. Y gracias a esto, podemos satisfacer las necesidades de análisis de existentes hoy en día, con un nivel de exigencia mucho más elevado que el que existía hace unos años.

Es decir, utilizaremos Big Data en escenarios donde una solución de BI tradicional (usada para el análisis de datos) no nos permite satisfacer los objetivos del cliente.

Definición de un escenario Big Data

Big Data debe utilizarse en situaciones en las que el análisis de datos no es posible de manera eficiente mediante una solución de Business Intelligence (BI) tradicional. Estas situaciones se han asociado históricamente a lo que se conoce como las 3 V’s: Volumen, velocidad y variedad. Cierto es que hay personas que incluyen otras V’s como la veracidad, la volatilidad, la validez, la visibilidad y la variabilidad, pero la definición más extendida sigue siendo la de las 3 V’s.

Volumen

Por volúmenes masivos se entiende una cantidad de datos muy elevada, que deja de ser manipulada de manera eficiente por los repositorios de datos tradicionales. Éstos son, en la gran mayoría de casos, bases de datos relacionales, que aunque hayan evolucionado en los últimos años para ser más eficientes y puedan ejecutarse en un hardware más potente que antaño, siguen siendo un cuello de botella para el almacenaje de grandes volúmenes de datos.

El uso de este tipo de sistemas de almacenaje para el análisis de grandes volúmenes de datos, puede llevarlos más allá de los límites para los que fueron diseñados, produciendo un descenso en el rendimiento en el almacenaje y acceso a la información. Estos límites varían en función del hardware y el software utilizados, por lo que se hace casi imposible trazar una línea para delimitar el inicio de lo que se puede considerar volúmenes masivos. Hace unos años este límite era del orden de gigabytes, mientras que hoy en día, con las innovaciones recientes en el hardware y el software, estamos hablando del orden de los pocos terabytes.

Velocidad

Cuando alguien analiza datos, lo hace con el objetivo de hallar una respuesta a una pregunta, dentro de un espacio temporal en el cual esa respuesta le aportará un beneficio. Si esa respuesta llega fuera de ese margen de tiempo, carece de valor.

Por ejemplo, el análisis de la localización de vehículos y dispositivos móviles puede proporcionar información sobre la fluidez del tráfico. En este escenario, la pregunta sería: “¿A qué velocidad se desplazan los vehículos por las vías en las que están circulando?”. Si estos datos proporcionan en un corto espacio de tiempo la respuesta a esta pregunta, pueden ser muy útiles, ya que las podemos mostrar en un navegador para ofrecer información “actualizada” de la densidad del tráfico en cada vía (urbana o interurbana) de la que dispongamos datos. Sin embargo, si esta respuesta la obtenemos con una hora de retraso, no nos será útil para mostrar en un navegador.

Por tanto, queda claro que la velocidad es un factor clave a la hora de tomar decisiones.

Esta velocidad para obtener una respuesta a partir de los datos puede desglosarse en dos componentes: la velocidad de carga del dato (obtención, transformación y almacenamiento) y la velocidad de análisis de la información (explotación del dato mediante técnicas de análisis de datos como son la estadística o la inteligencia artificial).

Si alguna de estas velocidades es baja, se corre el riesgo de sobrepasar el límite de validez de la respuesta, con lo que ésta carecerá de valor para el usuario.

Un sistema de BI tradicional, debido a su diseño y arquitectura, tiene una velocidad de respuesta desde la aparición del evento que genera un dato, que suele ir de entre algunos minutos (en casos concretos como es el caso de arquitecturas lambda) a las 24 horas (en un escenario de cargas de datos diarias), aunque podría llegar a ser superior. Si tomamos el escenario del ejemplo del tráfico, un BI tradicional claramente no podría satisfacer los requerimientos de los conductores.

Variedad

Los tipos de datos tradicionales son tres: numéricos, cadenas de caracteres y fechas. Históricamente, cuando había necesidad de analizar tipos de datos más allá de éstos, se recurría a aplicaciones especializadas, que quedaban fuera de lo que se consideran las herramientas de BI.

Por ejemplo, hace años que existían aplicaciones y librerías que permitían analizar imágenes y poder obtener respuestas a preguntas como “¿Aparece algún color verde en la imagen?” (que podría ser muy útil para saber el tiempo transcurrido en el crecimiento de un hongo en un cultivo de laboratorio). Pero esas aplicaciones y librerías no estaban integradas en una herramienta de BI tradicional.

Por tanto, el análisis de tipos de datos más allá de los tradicionales no se consideraba, en el pasado, como algo factible dentro de una solución de BI.

En la actualidad, con el crecimiento de los datos disponibles en las organizaciones y en Internet, cada vez hay más necesidad de encontrar respuestas a partir de datos no básicos, entre los que se incluyen audios, fotografías, vídeos, geolocalizaciones, etc. Cuando este es un requerimiento, nos encontramos delante de un escenario donde es necesaria la aplicación de Big Data.

Diferencias entre un BI tradicional y Big Data

Sin entrar en tecnicidades, la siguiente tabla intenta resumir las diferencias más importantes entre un BI tradicional y Big Data:

FactorTradicionalBig Data
VolumenPocos TerabytesTerabytes y superior
VelocidadCargas periódicas (típicamente diarias)Reducción del tiempo entre cargas de datos → Tiempo real
VariedadTipos de datos básicosVirtualmente, cualquier tipo de datos
ComputaciónCentralizada en una única máquinaDistribuida
HardwareAltas especificacionesCualquiera (Commodity hardware)
EscalabilidadDifícilSimple
Calidad de datos (veracidad)Muy importanteImportancia relativa (se asume cierto grado de incertidumbre)

Conclusión

El Big Data nos permite llegar más allá en el análisis de datos de lo que podemos con un BI tradicional. Se trata de una respuesta a unas necesidades de los usuarios, al igual que en su tiempo lo fue el BI. Eso no significa que el BI deba eliminarse como una opción a tener en cuenta a la hora de analizar datos. Al contrario, deberá ser siempre una opción.

Sin embargo, cuando las necesidades de los usuarios incluyan el uso de datos masivos (volumen), con respuestas obtenidas en un tiempo muy corto (velocidad) u obtenidas a partir de tipos de datos complejos (variedad), deberemos descartar el BI tradicional por sus limitaciones tecnológicas, y decantarnos por el uso de una solución con Big Data.