Monetización de los datos

 

El análisis de datos es usado principalmente para la obtención de respuestas que permitan mejorar la toma de decisiones dentro de una organización.

Un aspecto muy importante a tener en cuenta sobre ese análisis es el de los diferentes usos que se pueden dar a esos datos, tanto dentro como fuera de esa organización. Y es ahí, en el uso de los datos por entidades externas a dicha organización, donde el término “monetización de datos” adquiere una gran relevancia.

 

Ámbitos de aplicación de la información

Podemos distinguir dos ámbitos de aplicación de la información:

  • Interno (dentro de una organización)
  • Externo (fuera de ésta)

En el ámbito interno, los datos disponibles en la organización deben ser tratados y analizados para obtener información valiosa para los diferentes actores de los procesos de negocio internos. Es muy conveniente exponer esos datos en bruto y esa información derivada de éstos de manera transversal, para que todas las áreas de negocio puedan disponer de ellos. De esta manera, democratizando el acceso a la información, poniéndola al abasto de todos los empleados, se dispone de más herramientas para encontrar respuestas a nuestras preguntas. Y esto permite una mejor toma de decisiones.

Sin embargo, no hay que descuidar el ámbito externo en la explotación de esa información. Es decir, el uso de esos datos por organizaciones externas.

Monetización de los datos

Empecemos con unas preguntas:

  • ¿Pueden ser esos datos en bruto o esa información (producto del refinamiento de los datos) útiles para alguna organización externa?
  • ¿Qué valor tienen esos datos para esas organizaciones?
  • ¿Puede la organización propietaria de los datos beneficiarse de la venta de esos datos a terceros?

La monetización de datos o información consiste en la venta de éstos a organizaciones, y es la respuesta a las preguntas anteriores.

Cuando se dispone información que puede ser útil para otras organizaciones, ésta debe ser considerada como un producto con valor propio, que puede ser comercializado. Por tanto, es importante realizar un ejercicio visionario para encontrar ese mercado para los datos.

Por ejemplo, un municipio que disponga de sensores en la calle que permitan calcular el número y flujo de peatones en las calles, podría vender esa información a empresas de publicidad estática para poder determinar las mejores ubicaciones para la instalación de paneles publicitarios.

Respecto a cómo comercializar la información, el modelo puede ser el de venta puntual (e.g. Venta de todos los datos de un año en concreto) o por suscripción (e.g. Mensualmente se distribuyen los nuevos datos al comprador). Eso dependerá de las necesidades de los nuevos clientes y de la disponibilidad de los datos.

Aspectos éticos y legales

La venta de información debe ceñirse tanto a la ética como a la legalidad.

La cesión de información personal a terceros está regulada por la ley (ver GDPR – General Data Protection Regulation), con lo cual, las transacciones de intercambio de información deben cumplir los requisitos establecidos.

Además, hay que tener también en cuenta los aspectos éticos de la cesión y venta de información. El individuo debe dar consentimiento para la cesión o comercialización de sus datos personales, y debe ser capaz de modificarlos en cualquier momento. En este punto, afloran cuestiones como el hecho de cómo repercute esto sobre los datos previamente comercializados.

Estas cuestiones quedan fuera del alcance de este artículo y debe ser consultados con un profesional del ámbito legal.

En cualquier caso, si los datos personales no son necesarios, lo mejor es eliminar esa información en la distribución de información o anonimizarla para evitar riesgos innecesarios.

Conclusión

Los datos aportan la capacidad de mejorar la toma de decisiones. Pero también tienen un valor económico.

La venta de datos e información supone en sí un nuevo producto que puede ser comercializado.

Es de vital importancia cumplir con las normas legales y éticas a la hora de comercializar los datos de que disponen las organizaciones. La violación de éstas puede suponer la imposición de sanciones económicas muy importantes.

Efectividad de un proyecto de Business Intelligence

 

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

 

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.

¿Porqué necesitas una estrategia de BI?

 

 

La gran mayoría de las empresas han oído hablar de Business Intelligence. Es un tema muy interesante y la vez atractivo, por el hecho de poder tomar decisiones basadas en información que a menudo puede escaparse de la percepción de quienes deben tomar esas decisiones.

Y eso hace que las empresas quieran innovar dentro de este campo.

 

Palos de ciego

Sin embargo, la mayoría de empresas carecen del personal y la experiencia necesaria para desarrollar proyectos de Business Intelligence. Y por tanto, su enfoque suele ser el de empezar con un proyecto piloto para ver los beneficios que un proyecto de estas características puede beneficiar a su organización. No es un mal enforque inicial. Lo malo es que después de este primer proyecto, aparecen nuevas necesidades abordadas directamente, sin una visión de futuro, sin un objetivo a medio o largo plazo en mente.

Esa visión a medio y largo plazo es la estrategia de Business Intelligence.

A menudo me encuentro en situaciones en las que tengo que exponer a mis clientes que esa manera de abordar proyectos de Business Intelligence no es la que les va a aportar más beneficios a medio y largo plazo.

Buscando un símil

En estos casos, siempre les planteo un par o tres de situaciones para que vean el sinsentido de su enfoque.

Por ejemplo, ¿qué sucede cuando queremos decorar nuestra sala de estar y no tenemos una idea clara del estilo a seguir?

El resultado puede ser que acabemos con una mezcla de estilos, siendo ésta más perjudicial que beneficiosa. Podemos acabar con una mesa de madera de teka, un mueble de estilo rococó, unas lámparas de estilo minimalista y un sofá digna de una película de los años 50. A la vista está que una sala de estar con esta decoración carece de sentido. Es posible que haya satisfecho esos deseos individuales por lo que se refiere a cada uno de los elementos decorativos. Sin embargo, el conjunto no nos proporcionará una experiencia consistente que realce sus cualidades y que aporte un alto valor visual.

Beneficios de tener una estrategia

Definir una estrategia de Business Intelligence que permita que todos los desarrollos realizados aporten un alto valor añadido a una parte y a todo el conjunto de la organización es esencial para el buen gobierno de la información de ésta

Una estrategia de Business Intelligence permite identificar las prioridades a nivel de análisis de información en una organización, organizar esos requerimientos en proyectos y finalmente priorizarloos en función de la necesidad y los recursos disponibles.

Las organizaciones que disponen de una estrategia de Business Intelligence consiguen una mayor eficiencia en el desarrollo de sus proyectos a la vez que minimizan los cambios en los diferentes componentes analíticos debido a su previa planificación.

Carecer de una estrategia de Business Intelligence suele implicar, en la mayoría de los casos, un sobrecoste en el desarrollo de soluciones. Además, supone un aumento del riesgo respecto a la eficacia de la solución como respuesta a los requerimientos analíticos de toda la organización.

Conclusión

La definición y adopción de una estrategia de Business Intelligence en las organizaciones no solamente responde al gusto por el seguimiento de un enfoque organizado y premeditado. Supone un beneficio para la organización en términos económicos y funcionales.

Optar por un enfoque sin una estrategia de Business Intelligence es claramente un error que puede tener graves consecuencias económicas.

Las pruebas de concepto y proyectos piloto son una muy buena opción para determinar la viabilidad de un proyecto y los beneficios aportados por éste. Sin embargo, continuar con el desarrollo de proyectos sobre prueba de concepto, y evolucionar una plataforma de manera no planificada, es una mala decisión estratégica.

La decisión de que pertenece a las organizaciones. Como consultor y asesor en el área del Business Intelligence, mi labor es el de comunicar a mis clientes los beneficios e inconvenientes de ambos enfoques. Y cuando se me pregunta por una recomendación, lo tengo claro. Es esencial tener una estrategia de Business Intelligence.

Big Data y el uso de datos personales

 

En la sociedad actual, estamos constantemente generando datos de carácter personal como son nuestra localización, intereses, gustos, preferencias y relaciones sociales, por citar algunos.

El simple hecho de utilizar un teléfono inteligente (smartphone) o un ordenador conectado a Internet, provoca que ciertos datos puedan asociarse al usuario de estos dispositivos.

 

¿Quién, dónde y para qué se almacenan mis datos?

Estos datos son almacenados por compañías que ofrecen servicios o por los fabricantes de los productos que utilizamos y que generan estos datos.

Su destino es desconocido para nosotros, algo que suele causar inseguridad, incluso malestar. Éste suele ser un Centro de Proceso de Datos (CPD) privado o la nube (cloud), aunque en ambos casos, los datos se hallan bajo sofisticados mecanismos de seguridad (en teoría).

Y su uso suele ser, típicamente, para obtener un beneficio para la compañía que los almacena, bien por la explotación directa de los datos o por la venta de éstos a terceros.

¿Cómo perciben los individuos que esos datos personales estén en manos de estas organizaciones? Básicamente, podemos distinguir tres maneras diferentes de percibir esa misma realidad:

  • Una amenaza a la privacidad
  • Una simbiosis
  • Una oportunidad

Amenaza a la privacidad

Posiblemente, la opinión más generalizada acerca del Big Data es que, gracias a éste, los individuos vemos amenazada nuestra privacidad.

Los buscadores en Internet almacenan información acerca de nuestras búsquedas, incluido desde dónde las realizamos. Solamente con esta información y basándose en correlaciones con millones de búsquedas de otros usuarios, es posible deducir con bastante precisión información personal de los usuarios (el género, rango de edad, estado civil, zona del domicilio habitual, lugar de trabajo, itinerario seguido durante el día y un largo etcétera). Y como más busquemos en Internet, más refinado será nuestro perfil y más fácil será poder ser identificados.

Pero Internet no es la única fuente de generación de información personal. Las aplicaciones para smartphones y los diferentes dispositivos tecnológicos que nos rodean, también generan grandes cantidades de información. Ejemplos de estos dispositivos son el ordenador de un coche, pulseras medidoras de pasos, pulsómetros, contadores de la luz de última generación, etc.

Claramente, en este escenario, tanto la privacidad como el anonimato se ven comprometidos.

En el libro “Big Data. La Revolución De Los Datos Masivos” de Viktor Mayer-Schönberger y Kenneth Cukier, se habla de un caso en el cual, a pesar de haber anonimizado los datos, fue posible identificar a una persona a través de las diferentes búsquedas realizadas por ésta. Claramente, un caso de vulneración del anonimato a pesar de que los datos personales (nombre y apellido, edad, domicilio, etc.) fueron eliminados.

Sin embargo, no hace falta llegar a tal extremo. El mero hecho de que quien posee nuestros datos de actividad en Internet pueda pensar que una persona tiene la intención de comprar un ordenador portátil (esto es lo que sucede al hacer un par de búsquedas sobre portátiles, por ejemplo), suele provocar un aluvión de anuncios en las diferentes páginas web con anuncios específicos dirigidos a esa persona para que compre un ordenador portátil. Y eso puede ser identificado como una violación de la privacidad personal.

Generalmente, las empresas no tienen como objetivo principal identificar al usuario. Lo que les interesa es segmentar el conjunto de usuarios de Internet o de sus productos, para así poder dirigir campañas de marketing específicas a esos usuarios, con el fin de aumentar su efectividad. Y esto se puede traducir en una reducción de los costes y aumento de los ingresos en ventas.

A pesar de ello, el fantasma de poder ser identificado y de tener al Gran Hermano (que ya introdujo George Orwell en su novela “1984” en el año 1949) observando nuestros movimientos y decisiones, planea por encima de nuestras cabezas. Y para un grupo de gente, eso es claramente una amenaza a su privacidad.

Simbiosis

Otra manera de percibir esta realidad es la de sacar provecho de ésta. Es decir, identificar una situación de win-win entre las diferentes partes. Lo que se conoce en el mundo natural como una simbiosis.

Partamos del ejemplo anterior: La búsqueda de ordenadores portátiles en Internet. Se trata de un ejemplo real que me contó un amigo. Al hacer la búsqueda, le empezaron a aparecer anuncios con ofertas de portátiles al cabo de poco tiempo. La verdad es que fue muy útil, porque descubrió modelos de portátiles que desconocía, todos ellos con unas características muy similares al portátil que estaba buscando. Se trataba de campañas de marketing para un producto muy concreto (no aparecían portátiles con características muy alejadas de lo que buscaba), que le aportaron información muy útil para decidir sobre qué modelo comprar. Descubrió opciones que ni siquiera sabía que existían, algo que, a la postre, acabó siendo clave en su decisión final.

En este escenario, el usuario está obteniendo un beneficio del hecho de ofrecer información sobre sus intereses. Por tanto, se produce una situación en la que tanto éste, como la empresa recolectora de datos (que los utiliza para mostrar la campaña de marketing), como el propietario de la página donde aparece la campaña de marketing, como el vendedor del producto final, obtienen un beneficio.

Además, depende de cómo lo veamos, podemos pensar que este modelo de interacción, de alguna manera no solo no es una amenaza a nuestra privacidad, sino que la salvaguarda. Internet proporciona el anonimato desde el punto de vista en que no hace falta salir de casa para comprar algo. Pero cuando vamos a una tienda a mirar ordenadores (por seguir con el mismo ejemplo), todas las personas que nos han visto entrar en la tienda y los que hay dentro, pueden deducir que tenemos cierto interés en los productos ofrecidos por esa tienda. Es más, los vendedores de la tienda nos observarán y vendrán a ofrecer su ayuda cuando nos paremos frente a algún modelo. Y ellos nos verán la cara, sabrán cómo vestimos, el rango de precios de los portátiles que estamos mirando, etc. ¿Dónde está mi privacidad en ese momento?

Oportunidad

Generar ingentes cantidades de datos personales puede llegar a ser muy útil para el individuo si éste es capaz de explotar esos datos de manera inteligente.

En el artículo “Big Data no es solo para grandes empresas”, ya introduje este tema en la sección “Big Data personal”.

Una persona, por norma general, es consciente de sus movimientos, sus preferencias, sus amistades, sus gustos, etc. Sin embargo, el individuo no tiene la capacidad de cálculo necesaria para buscar correlaciones entre estos datos y obtener conclusiones interesantes. Podemos deducir algo, pero nunca llegaremos a la altura de los algoritmos de Inteligencia Artificial (IA).

Existe información de carácter público que desconocemos y que podría ser muy interesante para nosotros. Los algoritmos de IA amasan grandes cantidades de datos y los mezclan para deducir y predecir información para la toma inteligente de decisiones. En este escenario, ¿podemos utilizar el potencial de los datos y la IA para mejorar nuestra toma de decisiones e influir de manera positiva en nuestras vidas? La respuesta es que sí.

Aún en una fase incipiente, el Big Data personal trata precisamente de esto. El individuo debería tener acceso a toda su información personal para, a través de algoritmos de IA, poder influir de manera positiva en su vida.

Por ejemplo, si al individuo le gusta la comida vegetariana, ha hecho pagos en restaurante vegetarianos y visita páginas web de dietas vegetarianas, muy posiblemente agradecerá que su Big Data personal le informe de la apertura de un restaurante vegetariano a dos calles de su domicilio.

Éste es solamente un ejemplo de lo que el Big Data personal puede hacer. Pero las utilidades son infinitas. Tan solo hay que disponer de datos, almacenarlos y tratarlos de manera efectiva. Y eso es lo que hace Big Data.

Resumen

Vivimos en una sociedad donde la captura de información es constante. Cada vez existen más dispositivos electrónicos en nuestras vidas que miden lo que sucede a nuestro alrededor.

La captura, almacenamiento y uso de esta información para el beneficio de quien la gestiona es una realidad.

La percepción que los usuarios tienen de esta realidad suele ser de una amenaza para su privacidad. Sin embargo, existen otras maneras de ver el uso de los datos personales y su explotación mediante Big Data.

El usuario puede beneficiarse de la generación de esos datos por terceros (simbiosis), y en un futuro cercano será capaz de sacar provecho de toda esta información, obteniendo beneficios personales (Big Data personal).

La evolución tecnológica nos depara un futuro lleno de cambios. La actitud del individuo frente al cambio es lo que hace que se interprete éste como un riesgo o una oportunidad. Y tú, ¿cómo ves el futuro?

Big Data no es solo para grandes empresas

 

Existe una creencia bastante generalizada de que Big Data es solo para grandes empresas. Sin embargo, lo cierto es que Big Data es una solución tecnológica para todo tipo de organizaciones.

En este artículo os quiero mostrar cómo cualquier organización es susceptible de necesitar una solución Big Data, y cómo el hardware no es una limitación cuando hablamos de tecnología en este tipo de proyectos.

 

Cualquiera puede usar Big Data

La necesidad de utilizar Big Data viene dada por los datos y el uso que se haga de éstos, no por el tamaño de la organización que tiene esa necesidad.

En mi artículo “¿Qué es Big Data?” podéis leer acerca de las 3 V’s que dictan la necesidad de implementar una solución basada en Big Data. En ningún momento hablo del tamaño de la organización ni de su presupuesto. Todo gira alrededor de los datos y el uso que se haga de ellos.

Cualquier organización de hoy en día es susceptible de necesitar Big Data. Tan solo hace falta tener procesos que capturen la información, y una firme voluntad de explotarla.

La generación de grandes volúmenes de datos es posible en una gran cantidad de procesos. La velocidad necesaria para explotar la información dependerá del uso que se le quiera dar y del tiempo de vida útil de ésta. Y el uso de tipos de datos complejos como imágenes, vídeos, etc. es algo que también está al alcance de la mano de las organizaciones de hoy en día.

Big Data personal

Un claro ejemplo de que cualquiera puede usar Big Data es el de las personas físicas.

En la red ya se empieza a encontrar información acerca de lo que se ha denominado el “Big Data personal”. Este término responde a la idea de que los propios individuos generan cada vez más información. Y esta información se almacena tanto en nuestros dispositivos, los que generan la información, como en la nube (cloud). Esto es lo que se denomina la huella digital (digital footprint).

En nuestro día a día usamos móviles, ordenadores, relojes con sensores que están constantemente midiendo nuestra actividad… Toda esta información es susceptible de ser utilizada. Pero no solamente por los fabricantes de los dispositivos y las empresas del software y las Apps que usamos, sino también por nosotros mismos.

La cantidad de datos que generamos la podríamos utilizar para obtener un beneficio propio. Por ejemplo, la ruta recomendada para ir al trabajo para una persona con sobrepeso e hipertensión a quien le guste la arquitectura, podría ser adaptada para dar un rodeo de 5′ a pie, aprovechando para ver un par de edificios de modernistas un día, una iglesia otro día, etc.

Big Data en las PYMEs

Si una persona genera suficientes datos y puede obtener resultados útiles para sí misma, ¿qué no puede hacer una organización?

Todo proceso es medible. He estado en muchas empresas hablando con directivos sobre la importancia del análisis de datos para la toma de decisiones. A menudo me comentan que no generan datos suficientes, y que por eso no ven viable implementar una solución analítica. Es una lástima por ellos, porque seguro que sus competidores sí que estan capturando información. Y quizá la estén analizando para mejorar su posicionamiento en el mercado y su eficiencia interna.

La no existencia de datos es un punto de incio a partir del cual las organizaciones deben tomar consciencia de lo que están dejando de lado. Una vez una organización se da cuenta de esta situación, debe empezar a capturar datos para así poder explotarlos.

Los datos que potencialmente se pueden obtener en la gran mayoría de las empresas (por no decir todas), está por encima del límite que separa el Business Intelligence (BI) tradicional del Big Data. Así pues, cualquier PYME puede tener la necesidad de una solución analítica basada en Big Data.

No es necesario un superordenador

Llegados a este punto, otra de las creencias extendidas es que para utilizar Big Data necesitamos una máquina con un poder de cálculo inmenso, inasumible desde el punto de vista económico para la gran mayoría de empresas. Esa es una creencia errónea.

A diferencia del BI tradicional, Big Data puede trabajar sobre lo que se conoce como commodity hardware. Es decir, hardware de baja capacidad computacional. Por lo tanto, hardware con un coste medio o bajo. Esto permite que organizaciones sin un gran presupuesto para hardware, puedan incorporar Big Data a su conjunto de herramientas tecnológicas.

Supone esto un hándicap para las organizaciones que trabajan con hardware de media o baja potencia? En absoluto. Big Data permite añadir ordenadores a su red computacional de Big Data, permitiendo ampliar la potencia de cálculo de todo el sistema. En otras palabras, una organización será capaz de ampliar su capacidad de análisis de datos con el tiempo, a partir de pequeñas inversiones. Esta flexibilidad que ofrece Big Data, permite que las organizaciones puedan crear un cluster de Big Data (un conjunto de ordenadores que colaboran entre ellos para obtener unos objetivos comunes) de manera progresiva, sin tener que realizar una gran inversión inicial.

Conclusión

Big Data es una solución tecnológica que surge como respuesta a unas necesidades. Todas las empresas, por muy pequeñas que sean, trabajan con procesos que generan datos. Si las organizaciones son capaces de capturar esos datos, éstos pueden crecer hasta llegar a límites más allá de lo que un BI tradicional puede gestionar de manera eficiente. En ese momento es en el que aparece la necesidad de usar Big Data.

Por otra parte, Big Data es capaz de funcionar en entornos de sistemas muy variados, bien sea un superordenador o un conjunto de ordenadores de gama baja. Esta flexibilidad permite que cualquier organización ya sea grande, mediana o pequeña, pueda implementar una solución de Big Data.

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.

Generando confianza con el cliente

 

 

Una de las cosas que más me gusta de mi trabajo es el trato con el cliente. Conseguir una relación de confianza, ir más allá del mero trato profesional… realmente no tiene precio. Y eso se consigue con implicación y sinceridad, aunque a veces pueda ir en detrimento de la facturación.

Para ilustrar esto, voy a exponer una situación en la que se encontró un colega mío hace unos años.

Houston, tenemos un problema!

Todo empezó, como es habitual, con un correo electrónico (o una llamada). Un cliente de un partner de la consultora donde mi amigo estaba trabajando, tenía una necesidad urgente. Se trataba de un problema que el equipo de Business Intelligence (BI) del cliente era incapaz de resolver. La solución en ese momento fue la siguiente:

“Vamos a mandar a un consultor experto para que os ayude a resolver el problema!”.

Lo cierto es que así fue. Mi amigo fue capaz de resolver el problema. Pero, ¿cuál fue el coste para el cliente? Lo cierto es que no lo sé, pero fueron cinco días en el Reino Unido (no sabían cuál era el problema y se contrató una semana de trabajo por lo que pudiera ser), incluyendo los vuelos, los taxis, el hotel, las dietas… Y a eso hubo que añadirle el margen del partner!!

El foco del problema

El coste puede ser lo de menos si el problema y su resolución lo justifican. Pero en este caso, el “gran” problema era que el cliente no sabía cómo visualizar una línea horizontal en un gráfico, para indicar una constante que venía a ser el límite entre un buen y un mal rendimiento de cierto proceso.

Es decir, que todo el coste del servicio (una semana de un consultor experto desplazado en el Reino Unido) vino por la visualización de una línea.

El cliente quedó contento (supongo que el dinero, al tratarse de una Administración Pública, no era un problema). El partner quedó contento. Y la consultora por la que trabajaba mi amigo también quedó contenta.

Nadie se planteó si era correcto o no lo que se hizo, puesto que se solucionó un problema y todas las partes quedaron satisfechas.

Hasta aquí hemos llegado

Es curioso pero esa fue la última vez que mi amigo trabajó para ese cliente. Había trabajado para ellos en el pasado, pero después de esa semana, nadie de su consultora volvió a trabajar para ellos. Podría ser que su equipo de BI no necesitara más soporte de ningún tipo? Podría ser. Pero también podría ser que, una vez analizado el proyecto, se hubieran dado cuenta del enorme coste que tuvo para ellos añadir una línea.

Por lo que me comentó mi amigo acerca del equipo de BI del cliente, me decanto más por la segunda opción y la consiguiente pérdida de confianza en su proveedor de servicios de BI (el partner de la consultora). O quizá fuera del partner con la consultora. ¿Quién lo sabe?

Porque tú, ¿cuánto pagarías por una línea?

Generando confianza

Afortunadamente para mí, soy yo quien gestiona mi cartera de proyectos. Y eso me permite tomar decisiones sin deberme a ninguna obligación contractual. Sin compromisos.

En un caso así, antes de cerrar un encargo de consultoría, me gusta saber exactamente cuál es el objeto del proyecto. Porque si no lo hago, corro un doble riesgo: Puedo cobrar por un servicio sobreestimado (como en el caso del escenario planteado) o puedo estar mandando a alguien de mi equipo a un campo de minas. Y ninguna de las dos situaciones es conveniente para generar una relación satisfactoria con un cliente.

Lo primero que hago es hablar con el cliente, entender cuál es el problema y analizarlo desde todos los puntos de vista. Y esto puede suponer tener que decirle al cliente que, bajo mi más humilde opinión (apoyada, eso sí, sobre muchos años de experiencia), lo que pretende hacer no es lo que más le conviene. Aunque esto signifique echar por la borda un contrato.

Es la diferencia entre querer obtener beneficios a corto plazo matando a la gallina de los huevos de oro (el cliente), o querer generar confianza con éste a partir de una ética profesional.

Cuidando las relaciones personales y profesionales

Mi opinión es que debo cuidar a mis clientes, tanto a los actuales como a los potenciales.

Con esta forma de actuar, consigo generar confianza y tener un trato más humano y personal con mis clientes. De esta manera, sé que cuando se acuerden de mí, lo harán en positivo. Ese es el legado que quiero dejar a mis clientes, junto con un buen servicio.

Con esta forma de actuar sé que pierdo contratos a corto plazo, pero gano algo mucho más valioso: La satisfacción personal de actuar de manera íntegra con respecto a los valores de StraBIA (que son los míos, claro está).

El coste de no usar Business Intelligence

 

 

A la hora de abordar un nuevo proyecto siempre debemos tener en cuenta el Retorno de Inversión (ROI, en inglés). Un proyecto de Business Intelligence no debería ser menos.

Hoy quiero hablaros de un caso que me encontré hace unos años, que muestra una parte de la ecuación: la del coste asociado a no usar Business Intelligence.

El escenario

Hace unos años tuve un cliente que quería que le hiciese un estudio sobre la necesidad de introducir procesos de BI en su negocio. Como es habitual en este tipo de estudios, el proyecto fue corto pero muy intenso, lleno de reuniones con directivos y responsables de diferentes áreas de negocio.

En estas reuniones, mi objetivo era analizar sus procesos de obtención y explotación de la información, para su posterior aplicación a la toma de decisiones en todos los niveles de la empresa. Por tanto, las reuniones cubrían procesos de decisión tanto ejecutivos, como tácticos y operacionales.

El cliente fue exquisito desde el punto de vista de un consultor. Hubo una gran predisposición a la colaboración y los interlocutores vinieron muy preparados, cosa que facilitó mi trabajo. De hecho, hubo tanta apertura y sinceridad, que su Director de Finanzas (CFO) me explicó a qué se dedicaba cada día desde hacía más de 20 años.

Obteniendo información clave

Cada mañana, el CFO de la empresa obtenía de su equipo un listado con las órdenes de venta de los últimos tres meses. Ese listado contenía más de 100 páginas (lo pude sostener en mis manos y pesaba mucho, había muchas páginas).

Su tarea principal para empezar el día y poder asignar el trabajo a su equipo era el de revisar cada una de las órdenes de venta de ese informe. En concreto, marcando con un bolígrafo aquellas que requerían una atención especial (ya fuera por retrasos en el pago, por descuentos no aplicables, etc.), y pasando a su equipo la responsabilidad de hacer un seguimiento de éstas.

Un coste para la empresa

El hombre, un empleado con un alto nivel de seniority y muy respetado en la empresa, se mostraba orgulloso de poder realizar esta tarea cada día. Es más, creía que gracias a su trabajo revisando el informe, el departamento funcionaba con un alto nivel de calidad y eficiencia. Eso no se lo negué.

Pero lo que sí que hice fue preguntarle a qué dedicaría su tiempo si ese informe pudiera hacerse siguiendo exactamente sus criterios, sin necesidad de estar un par de horas cada día revisando todas esas líneas. Me contestó que tenía mucho trabajo y que siempre le faltaban horas para poder realizar todas sus tareas, con lo cual tenía que alargar su jornada laboral.

El coste de ese ejercicio diario era de 2 horas. Y esas horas eran contabilizadas y suponían un coste para la empresa.

Calculando el Retorno de Inversión

Al finalizar esa reunión, le comenté que esa tarea repetitiva que él se dedicaba a hacer cada mañana podía realizarse a partir del análisis de las órdenes de ventas. Que podía seleccionar el rango de fechas (incluso más allá de tres meses), y que podía filtrar por cualquier campo relativo a clientes, productos, descuentos, vendedores, etc., para así dirigir su atención allí donde más le interesase. Y que la lógica a aplicar para seleccionar las órdenes de venta sobre las que trabajar podía ser tan compleja como quisiera, incluso teniendo en cuenta información no disponible en ese informe.

Y lo mejor de todo, que una vez realizado ese análisis, podría planificarse para que se ejecutara periódicamente (por ejemplo, cada día antes de empezar la jornada laboral), y para que enviara ese informe a cada uno de los responsables de verificar esos datos y hacer un seguimiento de las órdenes de venta.

De esta manera, es cierto que habría un coste inicial de creación del análisis, pero se ahorraría las dos horas diarias para el resto de su vida laboral.

Pusimos unos números rápidos en una hoja de papel. Si en un año tenemos unos 220 días laborales, en 20 años obteníamos unos 4.000 días. A razón de 2 horas diarias, eso arrojaba una cifra de 8.800 horas. No me dijo su coste por hora, pero yo lo puse en 100 €, cantidad que no rebajó (seguramente era superior). El coste total era de 880.000 €. Y eso solo en un proceso de negocio.

Finalmente, el CFO vio que era una buena idea eso de introducir BI en la empresa.

Conclusión

Calcular el Retorno de Inversión no es una tarea fácil. A veces no es tanto cuestión de intentar poner números a los beneficios obtenidos (a menudo basados en una predicción sin una base objetiva), como de obtener la reducción de coste de los procesos actuales que serán obsoletos.

En la gran mayoría de organizaciones (por no decir todas), hay procesos de obtención manual de información. Si conseguimos eliminar ese tiempo mediante la explotación inteligente de la información, reduciremos ese coste.

Es más, podremos dedicar el tiempo de esos analistas de datos a pensar en cómo mejorar el negocio, haciendo que se incremente su satisfacción y su productividad.

El Business Intelligence nos ayuda a obtener conocimiento a partir de la explotación de los datos. Y ese conocimiento permite la toma de decisiones inteligentes para la mejora de los procesos de las organizaciones. Si a ello añadimos una reducción en los costes de obtención de la información, estamos haciendo que el ROI de los proyectos aumente, cosa que justifica la realización de esos proyectos de BI.