Las nuevas generaciones y los datos

 

La historia se repite. Las nuevas generaciones pasan a las existentes a una velocidad inimaginable.

Si hace unos años éramos nosotros los que sabíamos cómo programar el vídeo para que nuestros padres pudieran graba una película, ahora son nuestros hijos los que nos tienen que enseñar cómo funcionan algunas de las tecnologías con las que no nos atrevemos a interaccionar.

Con la explotación de los datos pasa exactamente lo mismo.

 

Patrón de conducta

A lo largo de mi vida profesional he tenido la oportunidad de tener reuniones y entrevistas con directivos, cargos medios y empleados de todo tipo de organizaciones. Analizando las respuestas de los diferentes interlocutores, he visto que hay un patrón que se repite muy a menudo. Es el siguiente:

• Si la persona supera cierta edad, suele ser reacio al cambio que supone confiar en los datos para mejorar la toma de decisiones dentro de la organización, su departamento o su día a día.
• Si la persona se encuentra por debajo de cierta edad, está mucho más abierta a incorporar cambios en sus procesos con el fin de obtener mejoras en la toma de decisiones gracias al análisis de datos.

¿Porqué se da este patrón?

Llegados a este punto, mi hipótesis se basa en tres aspectos que considero claves:

  • La formación de personas por encima de cierta edad no incluyó en su día el análisis de datos como vehículo para la mejora en la toma de decisiones.
  • La reticencia al cambio en personas acostumbradas a lo largo de los años a trabajar de una manera concreta es contraproducente a la hora de incorporar nuevos procesos para la toma de decisiones.
  • La inseguridad producida por el miedo a perder esa importancia que la persona pueda tener en la organización al suponer que la toma de decisiones será basada en datos y no en la experiencia de la persona (cuando en realidad, la persona continuará tomando las decisiones, solamente que de forma más informada), hace que se vea el análisis de datos como una amenaza a su puesto de trabajo.

Esto no deja de ser una hipótesis, pero veamos cómo probablemente una persona de menor edad encajaría en cada uno de estos aspectos:

  • La formación superior actual incluye en muchos casos pinceladas sobre el análisis de datos y la transformación digital de las organizaciones gracias a las nuevas tecnologías, entre las que se incluyen las herramientas analíticas.
  • La reticencia al cambio desaparece a medida que disminuye la edad de la persona, ya que a menor edad es más evidente que la persona debe aprender cosas nuevas, incluyendo nuevos procesos y nuevas maneras de trabajar y tomar decisiones.
  • La inseguridad a tempranas edades se produce más por el hecho de no saber y no poder adquirir nuevos conocimientos que por otro hecho. Incluir nuevas maneras de trabajar no hace más que sumar capacidades y habilidades a la persona.

Para poder superar esa barrera que muestra el patrón, es necesario que los empleados reciban la formación adecuada. Esta formación incluye no solamente formación focalizada en los conceptos y herramientas de análisis de datos, sinó también con énfasis en los beneficios que puede suponer para el empleado el hecho de abrazar el cambio. Entre ellos destacan las oportunidades de promoción, mejora en la eficiencia en el trabajo, en los resultados y en la satisfacción en el puesto de trabajo.

Jóvenes, Aunque Sobradamente Preparados

Dando formación en la universidad y en escuelas de negocios he visto hasta qué punto la nuevas generaciones están preparadas. Cierto es que les falta cierta experiencia en muchos casos, pero los conocimientos que tienen algunos de los alumnos que he tenido ha llegado a sorprenderme.

A nivel tecnológico, tienen acceso a una gran cantidad de plataformas y herramientas. Disponen de ordenadores potentes donde poder ejecutar sus pruebas de concepto. Y si necesitan más recursos, los hallan en proveedores de servicios en el cloud.

A nivel teórico, Internet les proporciona todo aquello que necesitan, a menudo de forma gratuita.

A nivel de actitud respecto al análisis de datos, las nuevas generaciones creen en los beneficios que aportan a la toma de decisiones. Han crecido en la era digital. Han visto cómo los asistentes de sus teléfonos inteligentes, tabletas y ordenadores son capaces de utilizar todos los datos que recaban para ofrecerles servicios, para facilitarles tareas y para hacer que su vida sea más fácil, entretenida e interesante. Es por eso que no hace falta convencerles de los beneficios del análisis de datos.

Pero lo mejor de todo es que disponen de tiempo y energía para adentrarse en este fantástico mundo de la analítica de datos. Eso hace que nos encontremos con gente muy capacitada a pesar de su juventud.

Conclusión

La gente joven tiende a estar más receptiva a la hora de incorporar procesos de análisis de datos en la toma de decisiones que las personas de edad superior.

Es posible ayudar a las personas reticentes a incluir la toma de decisiones basada en el análisis de datos, para que se adhieran a esta realidad. Para ello es necesario una formación en diferentes aspectos, incluyendo tanto la tecnología como los beneficios que recibirá la persona.

Las nuevas generaciones han tenido acceso a formación y recursos, y han dispuesto de tiempo para experimentar con los datos. Eso les hace unos firmes creyentes en el análisis de datos. El futuro es suyo.

Ética y Big Data

 

Hablar de Big Data en un ámbito no tecnológico significa hablar de muchos datos, mucha información, y a menudo, de un cierto miedo debido a la información que puede extraerse de tantos datos.

Si nos centramos en este último aspecto, entramos dentro de las teorías conspiratorias de grandes corporaciones y gobiernos para poder espiar a los clientes y a los ciudadanos.

El objetivo de este artículo es ofrecer una visión general de esta realidad relacionando Big Data con la ética.

Análisis avanzado

Big Data permite analizar una gran cantidad de datos, más allá de los límites del Business Intelligence (BI) tradicional.

Disponer de un gran volumen de datos abre la puerta al análisis avanzado de éstos. Entre estos análisis avanzados encontramos la obtención de correlaciones entre variables, creación de modelos predictivos, agrupación en base a diferentes técnicas como clasificación, clustering, etc.

Con esta capacidad de análisis, es posible obtener información que en el pasado, por las limitaciones del BI tradicional, no era posible obtener. Esto significa un mejor conocimiento de las fuentes de información y sus relaciones, y una mejor base de conocimiento.

Mejor toma de decisiones

El hecho de disponer de más y mejor conocimiento implica una mejora en la toma de decisiones por parte de las organizaciones.

Es obvio que las organizaciones desean obtener el máximo nivel de detalle en su búsqueda de conocimiento. De esta manera, pueden tomar decisiones más ajustadas a cada uno de los individuos (clientes, habitantes, etc.) del estudio analítico.

El objetivo de las organizaciones está, en parte, en la eficiencia de sus procesos y la maximización de los beneficios, ya sea económicos (en empresas) como de servicio a los individuos (en la administración) y reducción de costes. Y esa eficiencia es directamente proporcional al nivel de detalle del conocimiento sobre el cual se basan las decisiones. Por ejemplo, no es lo mismo tomar decisiones a partir de datos globales sobre los clientes de una empresa que sobre cada uno de ellos.

Ante esta premisa, es evidente que el deseo de las organizaciones es el de llegar a un nivel de detalle alto para poder tomar las mejores decisiones.

Uso de la información

Un alto nivel de detalle puede llegar a suponer la trazabilidad de los individuos hasta la mínima expresión.

Un escenario donde queda patente este nivel de detalle es el de los datos que pueden ser obtenidos a partir de los teléfonos móviles. Algunos ejemplos de datos generados a partir de un teléfono móvil son las llamadas, la geolocalización, la navegación web y la actividad en redes sociales. El volumen de datos generado tan solo con estas aplicaciones es inmenso y está asociado a un individuo.

¿Implica ese nivel de detalle y la toma de decisiones sobre estos datos un problema ético? Veamos un ejemplo a partir de las llamadas de teléfono.

La compañía telefónica, el fabricante del móvil y hasta el fabricante del sistema operativo del móvil podrían tener acceso a las llamadas que realizamos y recibimos. El uso de esta información está totalmente prohibido por ley excepto en el caso de existencia de una orden judicial que autorice a las fuerzas del estado a monitorizar o analizar esa información y hasta a realizar escuchas. Por tanto, ¿es posible que las empresas con acceso a estos datos los usen con un nivel de trazabilidad a nivel de usuario? Posible es, pero el riesgo penal por el uso de esos datos es tan alto que es lógico pensar que una organización no hará uso de esa información. Es más, el mero hecho de almacenar esa información es un alto riesgo para la organización en caso de ataque informático que deje al descubierto esa información. Cierto es que las compañías telefónicas deben almacenar el registro de llamadas de manera centralizada como parte de su sistema de facturación, pero el resto de empresas citadas no lo necesitan. En su caso, su uso seguramente se restringe a la obtención de información agregada para la mejora de procesos en su hardware y software.

Permisos de explotación de datos

Otro tema a tener en cuenta es el de los permisos que los usuarios otorgan a las organizaciones para el uso de los datos.

¿Quién no se ha leído toda la letra pequeña a la hora de firmar un contrato? ¿Quién no ha aceptado las condiciones de uso de un dispositivo o de un software sin leerse todo el contrato? Os recomiendo, como curiosidad, este artículo sobre la letra pequeña.

En estos contratos, por lo general, el usuario acepta que el proveedor pueda recabar datos de uso con diversos fines. Entre éstos se puede encontrar el uso comercial y la venta de datos a terceros. Por tanto, al aceptar las condiciones estamos cediendo esos datos para su uso.

En otras palabras, parte de ese riesgo en la explotación de datos corresponde al usuario, que cede los datos generados de manera individual.

Conclusión

El potencial de Big Data al tratar datos masivos abre la puerta a la realización de análisis avanzado. Éste permite la toma de decisiones con un nivel de detalle mínimo.

La trazabilidad de los individuos es posible con este detalle mínimo, lo cual justifica la existencia de dudas respecto a la privacidad del individuo.

La cesión de datos corresponde únicamente al individuo y la realiza por voluntad propia.

Cualquier actividad que viole el contrato de aceptación de datos es punible, ya que la ley no permite el uso de datos personales sin el consentimiento del individuo.

La ética es un concepto ambiguo que depende de cada individuo. Ante la duda sobre la ética de la organización a quien cedemos nuestros datos, probablemente lo mejor sea no cederlos.

Una solución para cada problema

 

No existe una solución genérica que sea la mejor para todo tipo de situación. Cada escenario, cada situación tiene su propia solución más efectiva.

Hallar esa solución requiere una combinación de conocimiento, análisis y destreza a la hora de identificar los detalles del escenario y cuál de las posibles soluciones se adapta mejor a ese caso.

Para ilustrar esto, vamos a centrarnos en un problema concreto: la inserción registros en una tabla de una base de datos.

 

Definición del escenario

Nuestro objetivo es insertar registros en una tabla de base de datos.

Ante estos requerimientos debemos analizar con más detalle el escenario. Deberíamos plantearnos cuestiones como:

  • ¿De cuántos registros estamos hablando?
  • ¿De cuánto tiempo disponemos para realizar esa inserción?

Es evidente que insertar 1 registro o 50 millones es importante a la hora de definir el escenario.

En el caso de la inserción de un solo registro, el rendimiento (en la mayoría de procesos) no va a ser crítico, ya que la diferencia de ejecución de las diferentes alternativas de inserción posiblemente será imperceptible por el usuario.

Sin embargo, si el número de registros es elevado, una pequeña diferencia de tiempo por registro puede convertirse en una gran diferencia al final del proceso. Si la ventana para la realización de la inserción es corta, elegir la alternativa más lenta podría ser fatal para el proceso o sus procesos dependientes.

Conocimiento de la tecnología y los procesos

Supongamos que nuestra base de datos es Oracle. Esta tecnología tiene dos maneras diferentes de realizar inserciones:

  • La inserción registro a registro
  • La inserción multi-registro (bulk insert)

La inserción registro a registro inserta 1 único registro cada vez que se ejecuta. Su sintaxis en Oracle es:

INSERT INTO tabla (columna_1, columna_2, …) VALUES (valor_1, valor_2, …);

Cada una de estas inserciones se divide en dos tareas. La primera se ocupa de encontrar la posición dentro de la tabla dónde vamos a insertar esa fila. La segunda tarea se ocupa de insertar los datos en esa posición.

Por otra parte, al ejecutar un bulk insert, una sola instrucción insertará un número de registros que puede ser superior a 1.

Las instrucciones que utilizan bulk insert son:

INSERT INTO tabla (columna_1, columna_2, …) SELECT ...
CREATE TABLE tabla AS SELECT ...
SQL*Loader

Ante la necesidad de insertar potencialmente más de una fila, la búsqueda de una ubicación para los registros carece de sentido. Si fuese así, la inserción tendría un alto coste debido a la repetición de la primera tarea de la inserción para cada uno de los registros de la consulta. En este caso, lo que el motor de base de datos lleva a cabo es la inserción de todos los registros implicados, a partir de la última posición de la tabla.

Implicaciones de los dos métodos de inserción

La inserción registro a registro permite aprovechar mejor el espacio ocupado por la tabla, al ocupar espacio libre dentro de ésta (producido por la eliminación de registros de la tabla). Es decir, tenemos una mayor densidad de registros por espacio de disco (throughput). Este mejor aprovechamiento del espacio supone que, en un acceso secuencial a la tabla, el espacio de disco a escanear tiende a ser óptimo. Esto supone un mejor rendimiento en las consultas donde esta tabla sea accedida en modo secuencial. Sin embargo, la operación de inserción añade un sobrecoste debido a la búsqueda de un espacio libre en la tabla en cada instrucción (es decir, para cada registro insertado).

La inserción multi-registro tan solo realiza la acción de añadir filas a la tabla (sin buscar un espacio libre para cada registro insertado). Esto se realiza añadiendo los registros a partir de la última posición en la tabla a la cual podemos acceder mediante un puntero, . Al hacer esto, el sobrecoste de encontrar un espacio libre en la tabla desaparece. Sin embargo, el hecho de añadir registros siempre al final de la tabla significa que está crecerá cada vez que ejecutemos una inserción de este tipo. La consecuencia es que, en el caso de acceder a todos los registros de la tabla en una consulta, estaremos accediendo a una cantidad cada vez mayor de espacio en disco. En este caso, el throughput disminuirá progresivamente en la tabla a medida que vayamos realizando inserciones multi-registro.

Conclusión

Tal y como he comentado al inicio de este artículo, no existe una solución que se comporte siempre de manera óptima en todos los casos.

Es necesario identificar los detalles específicos de cada escenario que decantarán la decisión de utilizar una u otra solución.

El análisis previo al diseño de la solución nos aportará la información que necesitamos para poder elegir el diseño más adecuado en cada caso.

El conocimiento de la tecnología nos permitirá identificar las diferentes alternativas de diseño con sus beneficios e inconvenientes.

Y finalmente, la destreza a la hora de combinar toda la información disponible nos permitirá elegir la mejor solución dentro de toda la gama de grises disponible.

Analytics: Un juego de niños

 

A menudo me encuentro con personas en las empresas que dicen no tener datos suficientes para iniciar un proyecto de Data Analytics para la mejora de la toma de decisiones.

(… Sin comentarios)

Hoy os quiero presentar un caso basado en mi propia experiencia, para ilustrar como hasta los niños son capaces de obtener datos para así analizar sus actos y poder mejorar su rendimiento.

Escenario

El baloncesto, como cualquier otro deporte, nos da la oportunidad de capturar muchos datos. En las ligas profesionales, existe todo un ejército de personas dedicadas a la captura de estos datos, bien a través de tecnología sofisticada (como el posicionamiento de los jugadores y el balón a través de cámaras), bien manualmente (otorgar una asistencia a un jugador depende en cierto modo del criterio de una persona).

Durante un par de años tuve el privilegio de poder ejercer de entrenador asistente en equipos de categorías inferiores. Al asumir ese cargo, brotó en mí una idea: ¿Y si pudiéramos mejorar el rendimiento del equipo a partir del análisis de los datos obtenidos durante los partidos?

Desde el punto de vista de recolección de datos, solamente estaba yo para poder realizar esa tarea. Y lo cierto es que durante los partidos, un entrenador asistente tiene que estar atento a un sinfín de cosas para poder ayudar al entrenador principal. Por tanto, mi gozo en un pozo. Sin embargo, en algunos partidos sí que pude obtener algunos datos. Datos que terminaron convirtiéndose en información muy valiosa.

De los datos a la toma de decisión

La sensación es que el equipo tenía un gran problema: Perdíamos muchos balones. Pero, ¿realmente perdíamos tantos balones? Decidí hacer un estudio en base a los cuatro siguientes partidos.

Los datos que capturé durante esos partidos fueron:

  • Número de posesiones
  • Número de balones perdidos

De esta manera, pude obtener un porcentaje de balones perdidos.

El método de recolección de datos fue realmente «alta tecnología». Utilicé el método clásico de papel, lápiz y palitos.

Hay que tener en cuenta que, dependiendo del ritmo del partido, podíamos oscilar entre 70 y 100 posesiones por partido. Por tanto, el número de pérdidas era susceptible de una gran variabilidad.

Los resultados arrojaron un dato demoledor: El equipo perdía el balón en el 68% de las posesiones.

El trabajo que se hizo con esta información fue doble:

  • A nivel de entrenamientos se tomó la decisión de trabajar tanto la técnica como la táctica para minimizar las pérdidas.
  • A nivel de cada jugador, hubo una concienciación del problema con los balones perdidos, lo cual supuso un aumento de la concentración y la responsabilidad de los jugadores para minimizar ese número (esa fue la toma de decisión que los propios jugadores decidieron llevar a cabo).

Los resultados de los tres próximos partidos fueron demoledores. Por citar los dos más importantes:

  • Las pérdidas se redujeron al 47% de las posesiones.
  • El porcentaje de pérdidas en cada uno de esos tres partidos fue significativamente inferior al porcentaje de pérdidas mínimo de los cuatro partidos de la muestra inicial.

Querer es poder

Si un equipo de baloncesto integrado por niños es capaz de tomar decisiones para cambiar sus procesos a partir de cuatro palitos mal puestos en una hoja de papel, ¿qué puede llegar a hacer una organización en pleno siglo XXI?

Lo más importante a la hora de embarcarse en un proyecto de Data Analytics no es disponer de datos. La experiencia me dice que lo más importante es la actitud. El deseo de obtener datos y poderlos convertir en conocimiento para mejorar la toma de decisiones es lo que permite a las organizaciones avanzar en su camino hacia la toma inteligente de decisiones.

Es por eso que es tan importante que las personas que toman decisiones, los verdaderos sponsors del proyecto, estén convencidas de la necesidad de dar ese paso. Solamente de esta manera podrán generar un cambio en la cultura de la organización para la aceptación de este nuevo modelo de toma de decisiones.

Conclusión

Toda actividad es medible.

La recolección de datos siempre es posible… si hay voluntad para ello.

Cualquier persona de cualquier edad (incluidos niños de un equipo de baloncesto de nivel muy bajo) puede tomar decisiones de manera inteligente a partir de datos que aporten valor.

La existencia de sponsors fuertes convencidos de la necesidad de un cambio en la cultura de las organizaciones es clave para el éxito de los proyectos de Data Analytics.

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.

Conclusión

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.

Visualización efectiva de información

 

El objetivo de mostrar información es la fácil comprensión de ésta para poder realizar una toma de decisión.

La información puede presentarse en una gran variedad de formatos. Dar con el formato ideal es, en sí, una quimera (ya se sabe que para gustos, colores). Sin embargo, lo cierto es que la manera cómo se presenta la información puede facilitar en diferente grado la comprensión de ésta.

Es por esto que una visualización efectiva de la información es tan importante como el mismo tratamiento de los datos a la hora de diseñar una solución analítica.

Tablas: El A, B, C de la visualización

Los datos suelen ser tratados como una sucesión de información con una estructura concreta. Y su almacenados más habitual, al menos desde el punto de vista conceptual, es el de una matriz.

Esa matriz está compuesta de:

  • Filas: Cada uno de los sucesivos registros de información.
  • Columnas: Las diferentes unidades de información (datos) que componen ese registro.

Por tanto, la manera más simple e intuitiva de visualizar información es mediante su representación en una tabla.

A continuación se muestra un ejemplo:

Hasta aquí todo es fácil.

Sin embargo, esta tabla es un caso simple. Se trata de la visualización de una matriz de 2 filas por 3 columnas (6 celdas de información). Esta tabla es fácilmente interpretable debido a la poca cantidad de información a visualizar.

En muchos casos nos encontraremos con tablas con más registros de los que nos caben en pantalla, lo cual dificultará la visualización (scroll continuo para ver todos los registros o simplemente la línea de totales que podamos tener al final de ésta).

Si añadimos el mes a la tabla anterior, obtenemos la siguiente tabla:

Esta tabla ya no cabe en la mayoría de las pantallas.

Si la tabla fuera por año y semana en lugar de por año y mes, aún es más evidente (ahora podréis experimentar la agonía de tener que hacer scroll para poder seguir con el artículo):

Prosigamos.

Llegados a este punto, ¿crees que es fácil identificar el mes con más ingresos de 2018? Lo de la semana lo dejo para los que no tengáis nada más interesante que hacer.

En este caso, los datos están ordenados por año, lo cual facilita la búsqueda de la respuesta. Pero, ¿y si os pido el mes y año con un mayor objetivo? Ahora ya nos toca hacer un recorrido visual por toda la tabla.

Independientemente del número de filas de la tabla, nos encontramos con otra dificultad añadida. En este escenario, como en muchos otros, podemos necesitar la realización de cálculos para poder obtener un conocimiento que nos permita tomar decisiones.

En este escenario, queremos identificar los meses (dupla año, mes) donde el objetivo no se ha cumplido. Además queremos ver esa diferencia numérica.

Una solución fácil vendría a partir de la creación de una nueva columna con fórmula «= INGRESOS – OBJETIVO» nos daría esa diferencia. De esta manera podríamos identificar fácilmente los valores negativos, que son los que nos interesan. El uso de un filtro para eliminar los registros que no queremos visualizar permitiría reducir el número de filas, pero eso no siempre sería suficiente.

Queda claro que esta visualización no es efectiva.

Tablas dinámicas: Uso inteligente del espacio

El uso de una tabla dinámica nos permite tener valores de las dimensiones en las filas y las columnas. Esto supone una reducción del número de filas, lo que supone la posible supresión del scroll.

La siguiente visualización muestra la diferencia entre ingresos y objetivo por año y mes, a la cual se le ha añadido un formato condicional para identificar los meses que no han llegado al objetivo:

Hemos mejorado mucho, pero a la vez hemos perdido detalle. Al no disponer de los ingresos y los objetivos, no podemos cuantificar si estos números representan un desvío elevado respecto a los objetivos o no.

Podríamos usar porcentajes, pero éstos se ven altamente distorsionados cuando los valores son bajos.

Podríamos añadir las columnas «Ingresos» y «Objetivo», o únicamente una de ellas, pero esto implicaría añadir mucha información a la tabla dinámica, cosa que complicaría su comprensión.

Gráficos: Una imagen vale más que mil palabras

El uso de gráficos permite mostrar información en una imagen, de manera que ésta resalte aquello que queremos obtener del análisis.

En este caso, nos interesa identificar los meses en los cuales no se ha llegado a los objetivos, a la vez que queremos ver esos ingresos y objetivos.

El siguiente gráfico nos muestra exactamente eso:

En este gráfico podemos identificar fácilmente, mediante las barras verticales y su dirección, si la diferencia entre ingresos y objetivos es positiva o negativa.

Además, podemos ver también el valor numérico de estos dos valores, con lo cual tenemos una visión más completa de la realidad.

En esta imagen estamos mostrando un total de 108 valores (3 métricas x 3 años x 12 meses/año), todo concentrado en una sola pantalla.

Además, los gráficos de la mayoría de las herramientas analíticas nos permiten obtener más información de detalle al posicionarnos sobre un elemento del gráfico (normalmente en forma de ventana emergente).

Usuarios y organizaciones anclados en el pasado

Lo expuesto hasta aquí no es nada que quede fuera del conocimiento de la mayoría de los usuarios. De hecho, entra dentro de lo que se puede considerar «sentido común».

Siendo así, ¿porqué hay tantos usuarios en tantas organizaciones que continúan visualizando la información en forma de tablas? ¿Porqué estos usuarios pierden tanto tiempo interpretando los resultados cuando podrían ser más eficientes y obtener mejores respuestas con riesgo de error en sus interpretaciones mucho menor?

Es necesario que las organizaciones tomen el control del análisis de datos, formando a sus empleados y apoyándolos para que puedan obtener respuestas para la correcta toma de decisiones de la manera más simple y eficiente. Solamente de esta manera podrán modernizar sus procesos analíticos.

La creación de soluciones analíticas sin la correcta formación y soporte a los usuarios, es un error. Los usuarios son los que decidirán como usar las herramientas. Y si ellos deciden usarlas de la manera más ineficiente, la organización es incapaz de mejorar sus procesos internos de toma de decisión.

Conclusión

La visualización de información es clave para una toma de decisiones eficiente.

El uso de tablas como visualización por defecto genera grandes ineficiencias en las organizaciones, debido al alto coste temporal y al riesgo de errores en la interpretación de la información.

El uso de tablas dinámicas es una ligera mejora respecto al uso de tablas, pero arrastra ciertas limitaciones de éstas.

Los gráficos pueden ser una gran solución para la visualización de información. Existe una gran variedad de formatos, cada uno adecuado a resaltar cierto elemento de información. El hecho de no obligar a leer los resultados es una gran ventaja respecto a las tablas y tablas dinámicas.

Las organizaciones deben apostar en la visualización para poder facilitar la interpretación de la información por parte de sus empleados. De esta manera conseguirán una mayor eficiencia y un menor grado de error en la toma de decisiones.

Arquitecturas Lambda

 

En un sistema analítico basado en un Business Intelligence (BI) tradicional, los datos suelen estar disponibles en el repositorio analítica con una latencia típicamente de 24 horas (aunque la frecuencia de las cargas de datos puede aumentarse de diaria a varias -pocas- veces por día).

Esto supone que los usuarios no disponen de los datos para su explotación en los sistemas analíticos hasta que la carga de datos ha finalizado.

Existen escenarios en los que los usuarios deben tomar decisiones con una latencia cercana a tiempo real. En estos casos, una carga de datos tradicional no es capaz de dar respuesta a los requerimientos de explotación de la información.

Carga de datos tipo ETL

Una carga de datos en un BI tradicional es del tipo ETL (Extract – Transformation – Load). Esto significa que las transformaciones de datos se realizan durante la carga de datos para finalmente dejar los resultados en las tablas que los usuarios utilizarán para la explotación de datos.

Las transformaciones a realizar incluyen, entre otras, las siguientes:

  • Control de calidad de datos (mediante reglas de dominio y de negocio)
  • Estandardización de valores y formatos
  • Cambio del modelo de datos
  • Enriquecimiento de datos
  • Creación de agregaciones

Toda transformación requiere una inversión de recursos y de tiempo. Este último factor (el tiempo de carga) es el más determinante a la hora de decidir el diseño de las cargas de datos.

Límite en la frecuencia de las cargas de datos

Una carga de datos tradicional tiene una frecuencia establecida. El escenario más habitual es el de la carga diaria.

En ocasiones, los usuarios requieren de información actualizada con una latencia inferior a las 24 horas que proporciona la carga diaria. En este caso, es posible que los usuarios pidan que los datos se carguen con una frecuencia mayor.

Sin embargo, esto no siempre es posible. Y si lo es, el aumento de la frecuencia tiene un límite.

Las cargas de datos requieren tiempo para su ejecución. Durante ese periodo de tiempo, los datos disponibles pueden tener algún periodo donde muestren inconsistencias (e.g. Entre datos de detalle y agregados), a no ser que las cargas hayan sido diseñadas con este objetivo desde su inicio. Por tanto, la ejecución de una carga de datos en un periodo en el cual los usuarios pueden estar usando el sistema, podría dar lugar a inconsistencias en los datos.

Por otra parte, el consumo de recursos del sistema durante la carga de datos, podría restar recursos a la explotación de datos por parte de los usuarios. En otras palabras, las consultas de los usuarios se podrían ver afectadas negativamente por el hecho de cargar datos en ese mismo instante, lo cual provocaría un retraso en la obtención de respuestas desde el sistema analítico.

Es por eso que, si una carga de datos no ha sido diseñada inicialmente con miras a su ejecución en un entorno de disponibilidad continua de los datos, es un riesgo ejecutarla mientras los usuarios están utilizando la solución analítica. Además, la duración de la carga define un periodo durante el cual no deberíamos volver a lanzar la misma carga de datos para no entrar en conflictos de bloqueo o sobrescritura de resultados.

Por tanto, si bien es cierto que podemos aumentar la frecuencia de la carga de datos, si ésta no ha sido diseñada a tal efecto, el aumento de la frecuencia implica un riesgo adicional. El límite en la frecuencia está en el riesgo máximo asumible.

Una posible solución es la de definir ventanas de inactividad durante el día, durante las cuales el repositorio de datos no está disponible para consultas. Otra solución es el rediseño total de la carga de datos. Una tercera alternativa es la creación de micro cargas de datos que se ejecuten en paralelo a la carga de datos. Es lo que se denomina, arquitecturas Lambda.

Micro cargas de datos

Ante la necesidad de dar respuesta a los requerimientos de los usuarios que necesitan disponer de datos actualizados con una frecuencia superior a la de las cargas de datos, una solución es la creación de micro cargas de datos.

Estas micro cargas se caracterizan por lo siguiente:

  • Frecuencia elevada de ejecución
  • Bajo volumen de datos
  • Acceso rápido a los datos en origen
  • Mínima o nula transformación de los datos

Esto permite cargar los datos con un rendimiento muy alto en el sistema analítico, donde los usuarios podrán acceder a ellos.

Las micro cargas tienen algunas particularidades que es importante tener en cuenta a la hora de diseñarlas. Además, la aparición de micro cargas puede implicar cambios en la carga de datos existente. He aquí algunas preguntas a tener en cuenta:

  • ¿Los datos se cargarán en las tablas finales (utilizadas en la carga de datos diaria, por poner una frecuencia estándar) o en unas tablas específicas para esta segunda carga?
  • ¿Será una carga incremental o incremental a partir de la última carga diaria en todas las ejecuciones?
  • ¿Qué sucede con los datos previamente cargados cuando ejecutemos la siguiente carga diaria? ¿Sobrescribimos los datos o no los cargamos porque ya lo hemos hecho en las micro cargas?

Foto final: Arquitectura Lambda

La existencia de micro cargas en paralelo a una carga de datos es lo que se conoce como Arquitectura Lambda.

Los sistemas que usan este tipo de arquitecturas tienen un flujo periódico de datos a partir de una carga diaria (por ejemplo), y otro flujo de datos con una latencia mucho menor proveniente de una micro carga.

Conclusión

Cuando los usuarios requieren disponer de datos actualizados, las cargas de datos tradicionales de frecuencia diaria no permiten satisfacer esa necesidad.

Las cargas de datos, si han sido diseñadas a tal efecto, pueden ver incrementada su frecuencia, pero siempre con un límite que es función de la duración de la carga de datos.

En todo caso, hay que tener en cuenta el impacto en el sistema de la ejecución de cargas durante periodos en los que los datos sean explotados por los usuarios.

La creación de micro cargas de corta ejecución es la solución para complementar las cargas de datos tradicionales.

El escenario donde conviven estas dos cargas se denomina: Arquitectura Lambda.

Pensar en «Big»… Data no es siempre la mejor opción

 

Las limitaciones del Business Intelligence (BI) al tratar grandes volúmenes de datos, permitir el análisis en tiempo real y analizar tipos de datos complejos, son el origen de Big Data. Con este nuevo conjunto de tecnologías y procesos, podemos analizar datos en estas situaciones donde un BI tradicional no nos ofrece soluciones válidas.

Sin embargo, la aparición de Big Data está suponiendo un cambio de mentalidad, una simplificación en los diseños de soluciones técnicas, para hacerlas encajar en el mundo de Big Data. Y eso puede ir en detrimento de los intereses de las organizaciones.

En este artículo os presento un ejemplo.

Un requerimiento concreto

Una empresa a la cual llamaré X, precisaba analizar los ficheros de log de su sitio web (llamados comúnmente weblogs), para así poder extraer una información concreta. En este caso, se trataba de saber el porcentaje de visitas por idioma (catalán, español o inglés) a su sitio web.

El escenario era el siguiente:

  • Cliente internacional con tráfico web 24×7
  • Generación de 1 GB de weblog por hora, archivados en ficheros horarios (lo que supone casi 9 TB de weblog por año)
  • Estacionalidad en el tráfico del sitio web (el tráfico depende de la época del año)

Alternativa Big Data

Debido a la estacionalidad en el tráfico, era necesario analizar los datos de un año. La estimación del tamaño de los weblogs en un año de actividad (cerca de 9 TB), hizo que el cliente se posicionara a favor de una solución basada en Big Data desde un buen principio.

Estaban tan convencidos de que éste era el camino, que pronto contactaron con proveedores para sopesar la opción de adquirir hardware que les permitiera levantar una solución de Big Data. También habían estado mirando diversas tecnologías software para implantar la solución. Únicamente les quedaba elegir la opción más adecuada dentro del escenario Big Data.

Todo era excitación en la empresa X. El Departamento de Tecnología estaba muy emocionado por poder implementar una nueva solución, tan moderna, tan de la última tendencia… Esta emoción se extendió por la empresa. Los jefes de departamento soñaban con un futuro analítico con Big Data. No sabían exactamente qué podrían hacer con eso, pero sonaba muy bien, muy potente y muy moderno. Palabras como Machine Learning sonaban por los pasillos y en las reuniones de departamento. Hasta en las reuniones de Dirección, Big Data era un tema a tratar.

Solamente les faltaba la aprobación de un consultor externo experto en Big Data para poder tirar adelante el proyecto.

Los requerimientos mandan

Al enfrentarme a este escenario, lo primero que vi es que el cliente tenía muy decidido el camino a seguir, con lo cual sería muy importante justificar otra opción, si finalmente Big Data no era la mejor alternativa. Como veis, nunca parto de una alternativa única, sino que me gusta plantearme diferentes opciones para así hacer un análisis de pros y contras. De esta manera puedo elegir la más conveniente en cada caso.

Primera norma del consultor: Obtener los requerimientos.

Analizando este escenario, vi que el requerimiento se refería únicamente a un análisis concreto y específico. Al obtener requerimientos analíticos futuros, la respuesta fue que no había una necesidad de análisis posteriores de la información de los weblogs. Tampoco había nadie en la empresa que hubiera mostrado interés por extraer más información de esa fuente de datos en el futuro.

En este caso, el cliente se había inclinado por una solución muy potente para obtener una respuesta muy concreta. Pero esa inversión inicial no tenía en ese momento ninguna visión de futuro, ninguna continuidad que proporcionara un retorno de la inversión (ROI). Es sería la justificación a usar al plantear otra opción.

Propuesta de solución

Dado que los requerimientos presentes y futuros no justificaban una inversión tan grande, me planteé la alternativa de una solución a medida para obtener la respuesta a los requerimientos.

Esta opción consistía en dar una solución a la necesidad del proyecto, sin tener en cuenta la construcción de una plataforma analítica para su uso en futuros proyectos. Se trataba, pues, de un Quick Win.

Las opciones tecnológicas que planteé para esta alternativa fueron:

  • Servidor único, con ejecución serializada de larga duración en un servidor propio o en el cloud.
  • Cluster de Big Data, con ejecución distribuida en el cloud (eliminando la opción de cluster de Big Data propio).

En el primer caso, si el cliente disponía de un servidor donde poder ejecutar el proceso, el coste de hardware y software sería nulo. Únicamente tendrían que tener en cuenta el tiempo de ejecución del proceso, presumiblemente de larga ejecución por la serialización de éste.

El segundo caso, fue planteado únicamente en el cloud para pagar por uso computacional y reducir los gastos si lo comparamos con una solución on premise.

En este caso, la opción propuesta fue la de ejecución serializada en un servidor único disponible en el cliente, puesto que el cliente disponía del hardware necesario para ello. La ejecución del proceso se demoraría durante pocos días, pero daría respuesta a los requerimientos planteados al inicio del proyecto.

Conclusión

Big Data nos permite obtener soluciones a situaciones a las que el BI tradicional no puede dar respuesta.

Una solución de Big Data supone una inversión tanto tecnológica como de recursos humanos importante. Antes de realizar dicha inversión, es conveniente hacer un análisis del ROI para ver la conveniencia o no del esfuerzo económico.

Cuando una organización no dispone de una estrategia analítica o unos requerimientos que justifiquen la inversión de introducir Big Data, es importante explorar otras alternativas.

El uso de Big Data es un caramelo para las organizaciones, pero no siempre es la mejor solución a las necesidades corporativas. Un análisis de los requerimientos a corto, medio y largo plazo permitirá dictaminar la mejor opción.

El Valor de la información

 

Es habitual encontrar definiciones de Big Data basadas en las V’s: Volumen, Velocidad, Variedad, Veracidad… Una V que a menudo aparece en estas definiciones es la de Valor.

Los datos en sí carecen de Valor. Al otorgarles un contexto, estos datos proporcionan información. Y al combinar distintas informaciones aparece el conocimiento, que es el que permite tomar decisiones de manera inteligente.

¿Dónde aparece el Valor? ¿A qué se refiere la gente que habla del Valor en Big Data?

El dato contextualizado como fuente de Valor

El dato contextualizado aporta información. Por ejemplo, un sensor de temperatura puede darnos un conjunto de temperaturas en varias mediciones sucesivas. El contexto incluye las unidades de medida (°C) y la dimensión temporal, entre otras. Solamente con esta versión reducida del contexto, podemos ver la evolución de la temperatura a lo largo de un periodo de tiempo.

Si estas mediciones corresponden al proceso de vitrificación de ovocitos (técnica para la conservación de óvulos a temperaturas inferiores a -196°C), la información de la velocidad de enfriamiento aporta un gran Valor, ya que un proceso demasiado lento podría significar la creación de cristales de hielo que podrían dañar el óvulo.

Por tanto, queda claro que la información (la existencia de datos contextualizados), aporta Valor.

El Valor está en todo sistema analítico

Todo sistema analítico obtiene datos y los contextualiza. Por tanto, la aparición de Valor es propia de todo sistema analítico.

Hablar de Big Data como herramienta indispensable para aportar Valor es negar la posibilidad de que un sistema analítico tradicional (Business Intelligence) aporte Valor.

Big Data, como solución técnica dentro de un sistema analítico, también permite la aparición de Valor. Sin embargo, no aporta Valor por sí mismo. Es la información la que aporta Valor.

¿Qué aporta Big Data?

Big Data no hace que los datos adquieran Valor. Sin embargo, nos permite analizar datos y transformarlos en información, en situaciones en las que un sistema analítico tradicional se ve limitado.

Es aquí donde se halla la «aportación» de Valor de Big Data. En la posibilidad de obtener información que de otra forma no podríamos obtener.

Por tanto, Big Data es una solución que nos permite expandir el Valor global de los datos, por el mero hecho de que puede obtener más información que un sistema analítico tradicional.

Conclusión

El Valor aparece al obtener información a partir de la contextualización de los datos.

Un sistema analítico nos permite obtener información a partir de los datos. Esto significa que todo sistema analítico permite obtener Valor.

Big Data, al superar los límites de un Business Intelligence tradicional, permite obtener más información. Eso supone obtener un Valor adicional. Por eso, el uso de Big Data para obtener la misma información que un Business Intelligence tradicional, no aporta ningún Valor añadido.

Definición de Volumen en Big Data

Las 3 V’s de Big Data son Volumen, Velocidad y Variedad. El concepto de Volumen es fácil de entender. Sin embargo, lo que es más complicado es definir el límite a partir del cual dejamos atrás el Business Intelligence (BI) tradicional para adentrarnos en territorio Big Data.

¿Existe un Volumen máximo para un proyecto de BI? ¿Cuál es Volumen que nos lleva a la utilización de Big Data por la imposibilidad de obtener respuestas analíticas con una solución tradicional dentro de los requerimientos funcionales definidos?

Volumen y tecnología

El Volumen puede medirse en número de registros (miles, millones, miles de millones…) o en tamaño en disco (Gigabytes, Terabytes, Petabytes…).

Suele ocurrir que cuando alguien está acostumbrado a trabajar con cierto volumen de datos, oir hablar de volúmenes superiores en un par de órdenes de magnitud, genera cierto asombro. Es como si ese volumen fuera ir más allá de los límites del universo conocido. De hecho, mi experiencia me ha mostrado que la gente inicialmente suele plantearse cómo poder trabajar con esos volúmenes con la tecnología con la cual trabajan normalmente, es decir, con tecnología dimensionada para volúmenes más pequeños. Y como es de esperar, el rendimiento suele ser bastante pobre, según cuentan los propios afectados.

Pero si incrementamos las especificaciones de las máquinas donde se producen el proceso, almacenamiento y análisis de los datos, vemos que esos volúmenes imposibles de gestionar, pueden ser tratados sin ningún problema. Es decir, la tecnología da soporte al tratamiento de los datos. A mayor volumen de datos, mayor deberá ser la tecnología para dar respuesta a las tareas necesarias para lidiar con los datos.

En una situación así, incrementar la memoria (RAM, cache, etc.), la velocidad de los discos duros donde se almacenan los datos, de las controladoras de discos, del bus que conecta los diferentes componentes tecnológicos de un ordenador, y la velocidad de transferencia de la red, permite incrementar el poder computacional de una solución de BI.

¿Dónde está el límite?

He aquí la pregunta del millón.

Para la gran mayoría de organizaciones que disponen de una solución BI, la ampliación del hardware es una solución de recorrido relativamente corto. El incremento de la capacidad tecnológica va ligado a un incremento del coste del hardware. Y para esta gran mayoría de organizaciones, la inversión tecnológica tiene unos límites (basados en los presupuestos) que no les permiten obtener máquinas de alta capacidad computacional y alto rendimiento.

Para este grupo de organizaciones, se suele decir que el límite de una solución de BI tradicional, con un Data Warehouse como repositorio central de información analítica, está en los pocos Terabytes.

Existen algunas organizaciones (grandes corporaciones y administraciones públicas), que sí que pueden permitirse este tipo de tecnología. En este caso, los volúmenes que pueden llegar a procesar pueden llegar a ser muy grandes, pero puede ser que incluso esta tecnología no sea suficiente para según qué escenarios analíticos.

Para estas organizaciones, si disponen de tecnología punta, el volumen puede superar los pocos Terabytes citados anteriormente, aunque no va mucho más allá si se requiere obtener un buen rendimiento. ¿Cuánto más allá? Dependerá del diseño de la solución analítica, las consultas, la carga del sistema… En fin, depende de tantos factores y tan complejos, que es imposible dar un número a ciencia cierta.

Big Data como solución

Cuando la tecnología no puede incrementarse y el sistema no proporciona un buen rendimiento a las consultas analíticas, es el momento de plantearse un cambio. En este escenario, una solución de BI tradicional no puede dar respuesta debido a la gran cantidad de datos, por lo que es necesario explorar más allá del BI basado en un Data Warehouse.

Big Data, basado en el paradigma tecnológico de la computación distribuida, ofrece una solución a las limitaciones por grandes volúmenes de un BI tradicional.

La tecnología usada por un sistema analítico basado en Big Data no precisa ser de altas especificaciones, sinó que permite trabajar con hardware más modesto. El gran poder computacional de Big Data se basa en el trabajo cooperativo de los diferentes nodos que forman el cluster de Big Data. Además, esta red de máquinas puede crecer de manera flexible, lo que permite ver incrementadas las especificaciones del cluster y por tanto su capacidad de proceso de datos y cálculo.

Conclusión

El límite del Volumen de un BI tradicional no viene dado por un número sinó por la tecnología usada. A la hora de buscar un número, el más habitual ronda los pocos Terabytes.

Incrementar el poder computacional permite a una solución de BI procesar más datos de manera más eficiente, pero siempre encontraremos un límite (bien por rendimiento, bien por presupuesto en una organización).

Big Data aporta la computación distribuida como signo de identidad diferencial respecto al BI tradicional. Esto permite tratar con volúmenes de datos muy superiores al BI tradicional a la vez que lo hace con un mejor rendimiento.