Data Mesh vs Data Fabric: buscando la mejor arquitectura de datos

Data Mesh vs Data Fabric: buscando la mejor arquitectura de datos

 

Muchas empresas, a la hora de abordar la gestión del big data, han invertido en entornos tecnológicos que pasan por elementos como un data lake central y un equipo de datos. Todo ello con la expectativa de fomentar el crecimiento del negocio en función de los datos que de su actividad se obtiene. Sin embargo, es un problema común que, después de un alto rendimiento inicial, acabe convirtiéndose todo procedimiento data en un cuello de botella en el que quizás no se vea comprometida la calidad de los datos, pero sí la agilidad y la eficacia con la que se pone a disposición la información final a sus usuarios.

Es en torno a esta problemática donde ha surgido en los últimos años con fuerza un término: data mesh, que promete agilizar todos estos procesos en base a romper la tradicional arquitectura monolítica de los entornos data fabric, hacia una arquitectura basada en los microservicios pero, ¿podemos aplicar por igual a todos los entornos el data mesh?, ¿qué diferencias concretas existen con data fabric?, ¿cómo diseñamos un proceso data-mesh?, ¿cuándo conviene aplicarlo? Estas son algunas preguntas cuya respuesta os queremos ofrecer desde elternativa.

 

¿Qué es la arquitectura data mesh y cómo aborda los cuellos de botella?

 

Tal como hemos introducido, una arquitectura data-mesh ofrece un enfoque descentralizado frente al enfoque monolítico de otros procesos tradicionales, lo cual permite a los equipos de dominio realizar los análisis de datos por su propia cuenta, sin dependencias del equipo de datos. Eliminando estas dependencias, se reducen notablemente los cuellos de botella que puedan producir en este equipo peticiones desde diferentes departamentos no técnicos, como las que puedan solicitar marketing, ventas, RRHH, finanzas, etc.

 

Para una mayor profundidad del término Data Mesh y sus aplicaciones prácticas, visita nuestro artículo “Data Mesh: qué es, ventajas y cómo implementar esta arquitectura de datos

 

 

Este hecho no quiere decir que ante un enfoque data-mesh, los equipos técnicos centrados en los datos sean innecesarios o reduzcan su carga de trabajo: aplicar una arquitectura data-mesh requerirá un mayor compromiso con la transformación digital, tal como veremos posteriormente, así como la reparación de los data pipelines tras cambios en la base de datos operativa.

 

Diferencias entre Data Mesh y Data Fabric

Tal como ocurre con otros términos que forman parte de nuestro vocabulario (ETL vs ELT; datalake vs data warehouse, etc.), entre ambos procesos el fin es el mismo (obtener la máxima información de los datos a través de la incorporación de tecnología), pero con matices que hacen que cada uno sea la opción preferente para diferentes entornos, sobre todo a la hora de cómo presentamos los datos.

Por ello, es muy importante que antes de decidirnos por un proceso data mesh, data fabric o incluso ambos (veremos más adelante como no son excluyentes), auditemos nuestro entorno data y nos guiemos por profesionales que determinen cuál es la solución más adecuada para nuestra empresa.

Esto se debe a que tal como mencionábamos en el anterior apartado, es un error querer aplicar un proceso data mesh por el simple hecho de reducir la dependencia de los departamentos con el equipo IT con el fin de reducir sus funcionalidades, ya que precisamente puede sernos contraproducente si no reforzamos la inversión en el equipo data, que debe en todo momento garantizar la correcta calidad del dato.

Por este motivo y por otros tantos, conviene que conozcamos en detalle las diferencias entre data mesh y data fabric más allá de cómo se presentan los datos, centrándonos en otros aspectos como el cómo manejan los datos, sus mecanismos de almacenaje y su forma de gobernarlos.

 

Enfoque de datos como productos vs enfoque automatizado

Cada paso en el proceso de tratamiento de los datos de un Data Mesh se enfoca a reducir la fricción que pueda producir el acceso a éstos para quienes lo necesiten sin importar la experiencia técnica, mientras que en el caso de los procesos Data Fabric se centran en la automatización a través de múltiples herramientas con la finalidad de conectar datos disponibles desde varias ubicaciones, extrayendo la información de este entramado tecnológico mediante conexiones.

 

La descentralización frente a la centralización

Lo destacábamos como el primero de los principios del Data Mesh: la creación de múltiples dominios dedicado cada uno de ellos a una especialidad según el uso que se le de y la función que tenga según el consumidor a quien se dirige. Esto supone un enfoque descentralizado frente a la centralización que propone Data Fabric, que plantea la gestión y el gobierno de los datos desde una única fuente de datos. Ambos ofrecen datos de calidad en los puntos finales de cada una de sus redes, pero la diferencia radica en la procedencia más variada del Data Mesh frente a la procedencia unificada del Data Fabric.

 

Acceso a los datos

Esa descentralización vs centralización en cuanto a la gestión y gobierno cambia las tornas a la hora de hablar de puntos de acceso y control: el Data Mesh emplea conjuntos de datos controlados por los equipos especializados para ello (IT, Data Engineers, etc.), mientras que Data Fabric emplea el control a través de distintas APIs basadas en objetivos previamente configurados.

 

Arquitectura data

A la hora de hablar de arquitectura data en el caso de Data Fabric hay un concepto clave: metadatos, que son impulsados por la tecnología basada en herramientas para establecer conexiones entre las diferentes fuentes de datos para ponerlas a disposición a los usuarios finales a través de sistemas de entrega. En el caso de Data Mesh, usa un patrón organizativo y distribuido que crea diferentes dominios especializados, de menor tamaño dentro de una organización según la tipología de usuarios de estos datos.

 

Enfoque bottom up frente a top down en el gobierno del dato

Nos centramos ahora en el cuarto de los principios definidos para el Data Mesh: su enfoque bottom-up, que dista del enfoque top-down del Data Fabric. Esto es que mientras Data Mesh implica la entrada de todos los dominios a la hora de considerar las reglas y pautas que definirán la calidad y correcta gestión del dato, Data Fabric “impone” estas reglas y pautas desde los máximos responsables de los datos (equipos técnicos, ingenieros del dato, etc.) hasta los equipos que harán uso de su información.

 

DATA MESH DATA FABRIC
Datos organizados a través de los propietarios de dominios Datos organizados a través de la tecnología
Grupos distintos de equipos respecto a la administración de datos Una única capa de administración virtual sobre los datos distribuidos
Datos tratados, controlados y manipulados por los equipos data como producto al servicio de la organización Datos directamente controlados y presentados para el consumo de la organización mediante APIs
Estructura de propiedad de data lakes bottom-up (reglas marcadas por los consumidores de datos) Estructura de propiedad de data lakes top-down (reglas marcadas por los propietarios, desarrolladores y controladores del dato)

 

Factores determinantes de la arquitectura Data Mesh vs arquitectura tradicional

Simplificando, la arquitectura data mesh es el equivalente a lo que hasta ahora hemos conocido como microservicios de data. Es decir, pasar de las aplicaciones monolíticas (una aplicación software en la que la capa de interfaz de usuario, lógica de negocios y la capa de acceso a datos están combinadas en un mismo programa y sobre una misma plataforma) a las arquitecturas de microservicios (una aplicación software construida mediante un conjunto de pequeños servicios, independientes entre sí y en la que cada uno de ellos se encarga de implementar una funcionalidad completa del negocio).

 

 

Con ello, lo que el Data Mesh nos permite es asociar la estructura y el lenguaje de código (territorio de los departamentos técnicos de la empresa), con el resto de campos en los que se trabaja una empresa (departamentos ejecutivos). Es decir, tal como apuntábamos en la introducción del término Data Mesh: democratizar y descentralizar los datos para que cualquiera con necesidades sobre ellos, pueda usarlos según su propio contexto y no según se presentan de forma generalizada.

Este cambio de paradigma supone dentro de la cultura big data pasar de una visión data-driven (enfoque en el que los datos se ponen al servicio del usuario a través de equipos técnicos) a una visión domain-driven (los datos al servicio del usuario a través de la tecnología).

 

El término domain-driven no es contemporáneo al de Data Mesh, habiéndose descrito por primera vez por Eric Evans en su libro «Domain-Driven Design – Tackling Complexity in the Heart of Software» en 2003. Lo que sí que, mientras Evans realizó una conceptualización, el Data Mesh lo convierte en metodología en el contexto de la era big data.

 

 

En cuanto a la arquitectura seguida para el almacenaje de los datos, una metodología data fabric se sirve de un data lake único y centralizado desde donde parte la transformación de los datos, mientras que la metodología data mesh descentraliza este proceso y pone a cargo de cada sector su propio circuito de datos. Cada uno de estos circuitos tendrán sus propios data owners, compartiéndose la propiedad entre todos los que hacen uso de los datos.

Este hecho permite que no se requiera conocimientos técnicos a la hora de tratar los datos, teniendo el foco cada equipo en cómo debe hacer uso de aquellos que necesita para su analítica.

¿Y qué ocurre con los datos cruzados, aquellos que se hacen servir para diferentes sectores de la empresa? Data Mesh garantiza la interoperabilidad mediante la aplicación de estándares universales que permiten la colaboración. Tanto los formatos, la gobernanza, la disponibilidad y los metadatos se deben concretar para impedir caos entre los datos que afecten a su calidad.

 

Cuando aplicar procesos Data Mesh y cuando procesos Data Fabric

 

De forma muy resumida, basándonos en el anterior punto donde hemos tratado las diferencias entre ambos procesos, podríamos decir que, en el caso de Data Mesh, el fin es un cambio organizacional, mientras que en el caso de Data Fabric, el cambio es más tecnológico. Es decir, lo que se pretende con el Data Mesh es que toda la plantilla participe y tenga presente la producción de datos como fin máximo, aunque con el gobierno en manos de un equipo altamente especializado, mientras que con Data Fabric lo que se pretende es hacer el dato accesible a cualquier miembro de la plantilla a través de tecnología capacitada para ello.

Con estos puntos sobre la mesa, ¿es mejor un proceso Data Mesh que un proceso Data Fabric o viceversa? Para responder a esta pregunta tenemos que considerar dos aspectos. El primero de ellos el que hemos insistido a lo largo de este artículo: cada situación, cada empresa, cada contexto, requiere su propia solución, por lo que sería un error que indicáramos a priori que un proceso es mejor que otro basándonos en la generalidad, ya que la generalidad no existe en el mundo de los datos.

El segundo de los aspectos es que un proceso no es excluyente del otro:  de hecho, es útil a la hora de hablar de arquitectura de datos incluir tanto procesos de Data Fabric como Data Mesh. No son mutuamente exclusivos en cuanto deben ser tratados como marcos arquitectónicos, no arquitecturas sólidas de por sí. No tienes arquitectura de datos hasta que los marcos se adapten y personalicen a tus necesidades, tus datos, tus procesos y tu terminología, y para ello, tanto Data Mesh como Data Fabric tienen cabida en el tratamiento del big data.

De hecho, puede ser muy recomendable aprovechar las automatizaciones implícitas en los procesos de Data Fabric introduciéndolas en etapas concretas del Data Mesh, sobre todo en empresas que avanzan en su proceso de digitalización introduciendo nuevas tecnologías como las aplicaciones de aprendizaje automático o machine learning.

Siguiendo con este ejemplo, veríamos una mejora evidente de incluir ambos procesos en el uso de machine learning si lo acercamos a los usuarios finales (ventas, marketing, RRHH… fin que persigue el Data Mesh) mediante la automatización de las etapas que involucran la preparación de datos para el ML (fin que persigue Data Fabric). De esta forma se mejora la velocidad, la precisión y la disponibilidad mediante conjunto de datos controlados, a la par que los usuarios del dominio conocen qué hacer con los datos sin la necesidad de que tenga que intervenir IT, que por otra parte no requerirá la necesidad de conocer para qué se van a usar los datos para adaptar los procesos a cada fin.

No obstante, conviene destacar a la hora de inclinarnos por una opción, otra o ambas, aspectos como que un proceso Data Mesh requiere un compromiso con la digitalización más elevado, en el que se crean o se mantienen como personal indispensable equipos técnicos en data, mientras que un proceso Data Fabric puede ser abordado desde diferentes niveles de complejidad.

Este hecho se resume en que un proceso Data Fabric no requiere de ningún proceso Data Mesh si así lo solicitan las circunstancias. Sin embargo, un proceso Data Mesh sí requiere procesos Data Fabric, sea cual sea el contexto.

 

Cuando construir una arquitectura data mesh

 

Insistimos: no debemos basarnos en la aleatoriedad de “esta arquitectura puede funcionar en mi proceso digitalizador”, sino en el “esta arquitectura resuelve mis problemas con el tratamiento del dato de mi empresa”.

Esos problemas, en el caso del data mesh, los podemos identificar como resistencia a la hora de abordar la escalabilidad, dependencias complejas entre diferentes departamentos de la empresa, los mencionados cuellos de botella producidos por una desmedida solicitud de peticiones al equipo data o problemas de gobierno y seguridad del dato.

Problemas que, por otra parte, también aborda data fabric, pero que pueden inclinarse a favor de data mesh acorde a tres factores principalmente:

  • Numero de fuentes de datos de la empresa
  • Tamaño del equipo que trabaja con los datos
  • Cantidad de departamentos o dominios de negocio

Cuanto mayor sea la suma de estos tres factores en conjunto, más nos podría beneficiar la aplicación de un proceso data mesh.

 

Soluciones data mesh a nuestro alcance

La arquitectura data mesh se basa en abordar cuatro principios muy definidos: orientación específica de dominio, datos tratados como productos, infraestructura de autoservicio y enfoque bottom-up en el gobierno del dato.

Toda solución que permita un desarrollo óptimo de cada uno de estos cuatro principios será a priori apta para aplicar una arquitectura data mesh, lo cual no quiere decir que no existan diferencias entre ellas que nos puedan beneficiar en según qué entorno de datos nos movamos.

Nuevamente, será la asesoría y la auditoría de nuestros sistemas quienes mejor determinen qué solución es la más adecuada, pero sí podemos señalar como óptimas plataformas como Snowflake, Talend o Informatica al abordar estos principios en su totalidad y contar con herramientas y funcionalidades que responden al sentido de aplicar data mesh en nuestra empresa.

Así, como arquitectura distribuida, la composición básica recomendable de cualquier data mesh a aplicar desde cero o dispuesto para migrar, consiste en un data lake o data warehouse ya alojado en cloud, donde los datos se almacenen y transformen en una plataforma que permita estándares centralizados y propiedades descentralizadas a la par.

 

Snowflake Data Mesh

Una de las mayores ventajas que ofrece Snowflake a la hora de construir un data mesh en su considerable variedad de capacidades bajo un mismo paraguas. Capacidades que, con otras soluciones, requerirían la adición de diferentes colecciones de servicios, lo cual requeriría un mayor tiempo de adopción, una mayor complejidad y, en definitiva, un mayor número de profesionales del dato que adecuen las herramientas.

Tratando casos particulares, los usuarios de Snowflake pueden crear y automatizar la transformación de datos en pipelines para convertirlos en datos tratados como productos y gobernados, destacando un amplio tratamiento de diferentes formatos de archivo que van desde JSON, XML, Parquet, AVRO, Delta Lake2, Apache, Iceberg3 hasta otros menos comunes. Además, Snowflake da soporte a datos no estructurados como pudieran ser imágenes, videos u otros formatos binarios. Datos que pueden ser manipulados en la propia plataforma Snowflake usando SQL, Python4, Scala, Java y Javascript, o a través de funciones externas más amplias compatibles en su plataforma cloud.

 

Talend Data Mesh

El data Fabric de Talend es una de las soluciones más completas y flexibles a la hora de gestionar datos. Teniendo en cuenta esta flexibilidad como uno de sus puntos fuertes, esta arquitectura de Talend nos permite tanto integrar un data mesh como facilitar el gobierno y la calidad del dato, dos aspectos que son los puntos débiles de toda arquitectura de microservicios.

Así, contando con las necesidades previas que requiere tu empresa, se puede montar el data mesh sobre la arquitectura que ofrece Talend para atender el proceso de datos de cada dominio sin perder gobernanza, siendo altamente recomendable en este caso, la herramienta Talend Data Catalog, que permite a los dueños de cada dominio una gestión ágil basada en búsqueda por facetas, muestreo de datos y descubrimiento semántico, así como una categorización y perfilado automático de los datos.

 

Informatica Data Mesh

El punto fuerte de Informatica a la hora de montar un data mesh basado en su arquitectura es la excelente integración de datos que ofrece, admitiendo la analítica desde múltiples arquitecturas. Este hecho, sumado a una no menos potente escalabilidad, permite admitir situaciones de integración de datos complejas como las que el data mesh ofrece.

Por otra parte, la solución de Informatica es de las más avanzadas en el uso de inteligencia artificial y machine learning, lo cual faculta el uso de estas dos metodologías avanzadas para una integración de datos adicional y tratamiento de la calidad del dato.

 

¿Cuál es la mejor solución Data Mesh?

Insistimos una vez más: que el data mesh de Snowflake resulte mejor que el de Talend, o que el de Talend resulte mejor que el de Informatica o cualquier otra solución compatible del mercado, va a depender del entorno en el que se construya el data mesh y para las necesidades que se vayan a cubrir con él.

Sí que se pueden dar ciertas generalidades que inclinen la balanza hacia un producto u otro, como el grado de madurez digital en el que se encuentre tu empresa, su compromiso con los procesos de transformación digital, el entorno del que se parta (cloud, on premise o híbrido), el tiempo en el que se quiera cubrir la integración, etc.

Así, por ejemplo, podríamos recomendar el data mesh de Informatica en procesos de transformación digital en los que se incluya involucrar IA, con el hándicap de que este tipo de implementaciones y adopciones son complejas, requieren semanas y un presupuesto elevado, lo cual lo hace menos conveniente para digitalizaciones en primeras fases de adopción.

Esto último lo puede resolver la flexibilidad de Talend en cuanto a su variedad de opciones, lo cual abre un amplio abanico de entrada y compromiso con la arquitectura data mesh, siendo otro de sus puntos fuertes la analítica, indispensable para no perder gobierno sobre los datos. Sin embargo, podría perder la batalla en casos en los que se necesite un uso operativo de alto volumen por sus capacidades más limitadas de producción de datos.

Conocimiento y auditoria del entorno en el que trabajan nuestros datos, compromiso con el alto valor que ofrecen a los equipos que forman nuestra organización y herramientas adaptativas a cómo queremos tratar, transformar y organizar nuestras fuentes de información son tres claves que nos ayudarán a decidir si es mejor un data mesh, un data fabric o la combinación de ambos. Deja que desde elternativa te ayudemos con estos tres pilares para que juntos consigamos el único fin posible: devolver el valor de los datos a tu negocio.

Data Mesh: qué es, ventajas y cómo implementar esta arquitectura de datos

Data Mesh: qué es, ventajas y cómo implementar esta arquitectura de datos

 

Uno de los problemas más recurrentes que se encuentra una organización que invierte en la gestión del big data es cómo responden los diferentes equipos a la búsqueda y obtención de información dentro de los almacenes de datos dispuestos, sin que ello suponga sobrecargar a IT. De esta premisa parte la naturaleza del término Data Mesh, que de forma muy resumida supone “la democratización de los datos”: ofrecer a cualquiera de los usuarios de la información de empresa su acceso de forma rápida, así como una colaboración entre equipos más fluida.

En el siguiente artículo definiremos el término, diferenciándolos de otros conceptos similares e indicando cómo y cuándo conviene implementarlo, incidiendo sobre todo en los problemas que resuelve en el día a día de una empresa a la hora de trabajar con sus propios datos.

 

¿Qué es Data mesh?

 

Un primer acercamiento al término data mesh sería el uso de un enfoque centrado en los usuarios y en el producto a la hora de obtener información de fuentes de datos numerosas y heterogéneas, o de forma más técnica, el término que se ha adoptado para el proceso de descentralización de datos analíticos en un entorno big data dentro de una organización, con la finalidad de que cualquiera dentro de la estructura de la empresa, pueda compartir, acceder y gestionar la información de forma independiente y sin afectar al resto de la organización.

Todo ello supone un cambio en el tradicional rol que la gestión del dato había tenido hasta ahora en las organizaciones, donde los “dueños de los datos” residen en una parte de la empresa (normalmente ingenieros de datos o data scientists) para controlarlos y solo hacerlos accesibles al resto mediante la creación de data lakes o data warehouses.

 

“Acceso a datos más rápidamente y colaboración sencilla entre equipos en la era big data: los dos factores clave que persigue el Data Mesh”

 

Así, el data mesh lo que permite es la construcción de una infraestructura de autoservicio que valida a cualquier equipo (sea técnico o no) utilizar recursos y herramientas bajo demanda, para acceder a los datos correctos, procesarlos, prepararlos y analizarlos sin necesidad de formación previa o conocimiento de cómo se han producido.

 

   El término Data Mesh (malla de datos), fue introducido por primera vez en 2019, mediante la ingeniera, arquitecta de software, emprendedora y especialista en datos, Zhamak Dehghani a través de su artículo “Cómo pasar de un data lake monolítico a una malla de datos distribuida”. En él proponía un cambio de paradigma en el tratamiento de los datos a través de la enumeración de las características que debería tener una plataforma de datos moderna.  Estas características formarían la naturaleza de lo que hoy conocemos como Data Mesh.

Problemáticas que resuelve el uso de Data Mesh

 

Invertimos en gestión del big data porque nos damos cuenta de que el valor de los datos se pierde a medida que crece su tamaño si no se canaliza adecuadamente. Pero esa canalización, que llevamos a cabo mediante el uso de herramientas y la creación de equipos profesionales del dato, requiere de altos conocimientos técnicos y una alta disposición a resolver diferentes cuestiones, de diferente naturaleza y proveniente de diferentes fuentes.

Este hecho crea la paradoja de que la solución a una saturación de flujos de datos, pasa por una saturación del equipo técnico que los gestiona, que no solo se ven inmersos en la ya costosa a nivel de tiempo de dedicación, tarea de reparar canalizaciones de datos rotas, sino que también se deben preocupar de atender a las diferentes peticiones de información provenientes de diferentes departamentos, cada uno con unas necesidades diferentes y un lenguaje a la hora de trabajar los datos también heterogéneo. Peticiones que incluso se pueden llegar a cruzar e involucrar a diferentes estamentos de la empresa.

Es lo que ocurre por ejemplo con casos cotidianos en una empresa de venta de retail, la cual puede tener los deberes bien hechos a la hora de tener toda la información de productos, clientes y transacciones bien organizada y clasificada dentro de cada departamento implicado, pero que a la hora de responder a cuestiones interdepartamentales, la fluidez de la información se limita.

Así, el fin máximo (la calidad del dato) no se verá comprometido, pero sí la velocidad, la agilidad y la practicidad del tratamiento al encontrarse plenamente centralizada. Es este “el punto débil” de la gestión big data que aborda Data Mesh, resolviéndolo de la forma más evidente posible: si el problema viene de un dato centralizado, la solución viene de descentralizarlo.

 

 

Cómo facilitar la fluidez de datos en una empresa: los 4 principios del Data Mesh

 

Esa descentralización del dato que propone una gestión basada en Data Mesh no significa prescindir de los data lakes, que siguen siendo necesarios para garantizar el gobierno de los datos. Para posibilitar su aplicación dentro de una plataforma de datos, el Data Mesh establece cuatro principios que a su vez definen su naturaleza:

Orientación específica de dominio

En vez de usar una única capa virtual para administrar fuentes heterogéneas, el Data Mesh usa múltiples dominios, dedicado cada uno de ellos a las necesidades que se requieren específicamente. Es decir, en vez de tomar la información bruta de un único espacio común, un proceso Data Mesh trata previamente la información según su naturaleza y los separa para hacerlos disponibles de forma más rápida y eficaz a quienes lo necesitan.

De esta forma, en un Data Mesh quedarían separados por dominios los datos de ventas, finanzas, RRHH y marketing. Todos ellos tendrían accesibles los datos de unos y otros si así lo requieren, pero de forma instantánea, cada departamento podría acceder a su información y satisfacer necesidades inmediatas de forma mucho más ágil que mediante otro proceso data.

 

Denominamos dominio en arquitectura data a una colección independiente de clústeres implementables, que a su vez contienen múltiples microservicios que interactúan con usuarios u otros dominios a través de interfaces

Datos tratados como productos

 

El dato como centro de todo proceso, ese es el tratamiento que da el Data Mesh a cada información que entra en su flujo. Así, nos encontramos con que cada etapa o cada herramienta dentro de los procesos data mesh, clasifica claramente a los usuarios como productores y como consumidores, y según esta clasificación, el conjunto de datos resultante suele ser ampliamente controlado, que actúa como una API y es accesible para diferentes dominios y el público que lo requiera.

 

Data Mesh cambia la concepción tradicional de tratar los datos como recursos. Este tratamiento hace que se tienda a su almacenamiento como algo valioso, pero obviando su  utilidad. Al ser tratados como producto, una concepción Data Mesh alinea los datos con un proceso de creación y entrega de valor específico, procurando siempre la satisfacción del consumidor.

 

Infraestructura de autoservicio

Al igual que no prescinde de elementos como un data lake, Data Mesh no sustituye el trabajo de los ingenieros data, sino que reduce la dependencia que el resto de equipos tiene con estos profesionales a la hora de tratar datos, de forma que los encargados de la ingeniería de datos se pueden dedicar a otras tareas más productivas.

Para ello, Data Mesh facilita una infraestructura que de inicio es creada y mantenida por los data engineers, que ayudan a garantizar operaciones sencillas por parte de los miembros de cada dominio específico sin necesidad de poseer o necesitar conocimientos técnicos sobre el tratamiento de cada dato.

 

Enfoque bottom-up en el gobierno del dato

Hablamos desde el comienzo de “democratización de los datos”. Dentro de esta prosa es necesario para ello que sean los miembros de cada dominio quienes definan las reglas sobre las políticas, los accesos y el tratamiento que se le dan a los datos que consumen y producen, de forma que no solo tengan la disponibilidad de los datos, sino también su control.

Con este enfoque (denominado bottom-up porque determina el funcionamiento de abajo hacia arriba, es decir, a partir del consumidor final) que hace plenamente partícipe a cada consumidor de datos, se ayuda a garantizar los estándares de calidad del dato al apoyarse la guía creada por ellos con sistemas de verificación y control a lo largo de los flujos de trabajo.

 

Para saber más sobre las implicaciones técnicas y a nivel de arquitectura que tiene la aplicación de los procesos Data Mesh, consulta nuestro artículo: Data Mesh vs Data Fabric: buscando la mejor arquitectura de datos

 

 

Cómo implementar una arquitectura data mesh: primeros pasos

 

Data mesh parte de una concepción y de los principios que hemos definido como parte igualitaria. A partir de ahí, cada solución del mercado adapta sus productos a la arquitectura data mesh según la infraestructura que se disponga y las necesidades de cada compañía. Es por ello que la construcción no responde a una hoja de ruta concreta y replicable, aunque sí podemos marcar cuatro pasos como claves a la hora de implementar data mesh:

 

Mapear los procesos

 

Como todo proyecto ambicioso de gestión de big data, antes de implementar data mesh es imprescindible que marquemos nuestra hoja de ruta como empresa data. Es decir, los procesos AS IS / TO BE de la plataforma que queremos mejorar con la finalidad de reducir las limitaciones técnicas y que, en el caso de existir, podamos tenerlas resueltas previamente o de forma ágil cuando surjan.

 

Marcar los dominios de producto   

 

El tratamiento de los datos como producto es parte de la naturaleza del data mesh. Por tanto, un proceso fundamental previo sería definir los dominios: los clústeres en los que se producen los datos (clientes, contactos, productos, proveedores, etc.). De esta forma podremos proporcionarles una dirección y un directorio que permita su procesado.

 

Transferir los dominios de producto  

 

Con los diferentes dominios localizados, ya se ha llevado a cabo gran parte de la descentralización con la que trabajará la plataforma data mesh. Para que esta descentralización no produzca problemas con la calidad del dato y el hecho de que existan posibles duplicados, no afecte a su tratamiento y gobierno, debemos organizar los dominios y transferirles la propiedad de los datos, creando equipos data dentro de éstos y propietarios que se responsabilicen de su gestión y sepan transmitir reglas adecuadas y apropiadas para evitar caos.

 

Asegurar el gobierno de datos descentralizado

 

Para ello, los dominios deben ser autodescriptivos e interoperables. Descentralización no debe ser sinónimo de aislamiento: que cada dominio pueda actuar con independencia solo es posible si se hace bajo unas reglas comunes que permitan la interoperabilidad y el entendimiento entre ellos. Para ello son necesarios glosarios, controles de accesos y unos estándares previos globales para todos.

 

Con todo ello no estamos modificando toda la estructura, toda la arquitectura data de la empresa, sino implementando una concepción, la del productor como servidor de los datos frente a su anterior papel como simple colector, que nos permitirá un uso más cercano y práctico en el día a día de los datos que permiten el crecimiento como empresa. ¿Sabes por dónde empezar a transformar cómo se interpretan los datos en tu empresa? Nosotros te guiamos en el viaje de ganar competitividad a partir de tus bases.

 

 

Qué son las herramientas ETL y para qué las necesito en mi empresa

Qué son las herramientas ETL y para qué las necesito en mi empresa

Las herramientas ETL permiten una mejor relación con los datos, obteniendo información de calidad de ellos

Para ser una empresa data-driven, una empresa en el que el (buen) dato es el centro de cualquier decisión, dentro de la gestión del big data, se plantean dos procesos básicos: los procesos ETL y los procesos ELT. Pese a que ambos ofrecen de resultado un dato integrado, gestionado y de calidad, según las necesidades de cada estructura empresarial (mayor o menor agilidad de disposición del dato, mayor o menor capacidad de almacenaje, mantenimiento, etc.), será más adecuado el uso de una metodología u otra.

En este artículo nos centraremos en las herramientas ETL, detallando desde su definición, su importancia, hasta los beneficios que comportan y cómo aplicarlas.

 

Cómo trabajan las herramientas ETL

ETL viene de las siglas provenientes de los anglicismos “extract, transform y load”, o lo que es lo mismo: “extraer, transformar y cargar”, que hace referencia al orden exacto que sigue este proceso a la hora de desarrollar una estrategia data-driven.

Hablamos de “a la hora de desarrollar una estrategia data-driven” dado que por sus peculiaridades y las herramientas y procesos que implica, el despliegue de la metodología ETL precisa una firme voluntad de querer explotar y extraer conocimiento de valor de los datos en los que se trabaja dentro de una empresa.

Es por ello por lo que el inicio de una estrategia en la que se aplican procesos ETL, suele aplicarse en la actualidad a empresas que acumulan datos desde hace años, almacenados desde diferentes fuentes y con diversos formatos. Se activa por tanto cuando pretendemos organizarlos, limpiarlos y consolidarlos en un único lugar desde el cual hacerlos accesibles y comprensibles: el data warehouse.

Todo ese viaje desde los diferentes espacios en los que acumulamos datos, hasta que se organizan en un almacén de datos, es cuando se extraen, transforman y cargan, o lo que es lo mismo, cuando trabajan las herramientas ETL. Por tanto, éstas lo que nos permiten es consolidar los distintos datos que poseemos, independientemente de su tamaño, tipología o el tiempo que lleven entre nosotros, en un espacio, el data warehouse, donde se orientan a la analítica.   

Procesos ETL y ELT: ¿cuál conviene más a nuestra estrategia de gestión de datos?

Para conocer en mayor profundidad, cómo se trabaja en cada una de las fases de los procesos ETL, en qué se diferencian de los procesos ELT y cuándo conviene aplicar uno u otro, recomendamos la lectura del artículo: Procesos ETL y ELT: en qué se diferencian y cuál es el más indicado para mi estrategia de datos.

Qué beneficios aportan las herramientas ETL

 

Uno de los principales es el que acabamos de desvelar: la analítica. De nada sirve acumular ingentes cantidades de datos si no sabemos qué información valiosa extraer de ellos. Así, las herramientas ETL nos facultan a ser capaces de ordenar y acceder a datos que con anterioridad estaban ocultos o desorganizados y no solo eso: según qué herramientas ETL, también seremos capaces de obtener los insights necesarios a través de cómo y dónde se presentan estos datos.

De esta forma, otro de los grandes beneficios que aportan las aplicaciones ETL es el de coordinar e integrar diferentes herramientas; actualizarlas sin que se pierda información en el proceso, estabilizar el ecosistema data incorporando nuevas herramientas a las preexistentes… Es decir, conseguir que toda la tecnología al servicio de los datos en nuestra empresa, trabajen para un mismo fin: la calidad de la información.

 

Es recomendable que, a la hora de aplicar cualquier proceso en beneficio de una cultura data-driven en la empresa, no se aborde de forma unilateral (pensando en una única solución o herramienta para todo el ecosistema data), sino que se combinen diferentes metodologías para según la finalidad principal a la que queramos destinar la información extraída de nuestros datos. Así, un proceso ETL puede optimizarse si se le añaden tecnologías de business intelligence, data quality, etc

 

Adicionalmente, también podemos hablar de una ventaja muy positiva de las herramientas ETL la referente a la seguridad de los datos, tanto a la hora de protegerlos de ciberataques, como al cumplimiento de las leyes referentes a protección de datos (RGPD, LOPD, etc.). Esto se debe a que al encontrarse los datos perfectamente clasificados y estructurados en almacenes, se pueden proteger por capas de manera que solo sean accesibles a quienes realmente deben trabajar con ellos. De esta forma, se comparten únicamente aquellos datos que están en disposición de ello, y solo a quienes tienen autorización para ello.

Por último, dentro de las ventajas más notables que ofrece una herramienta ETL, está la de mejorar la gestión del tiempo, como consecuencia de contar con la información necesaria para el crecimiento de la empresa, mucho más al alcance, y también como consecuencia de realizar tareas de limpieza, depurado y corrección de datos que requerirían horas y horas de dedicación por parte de especialistas como data scientist, programadores o personal de IT, que podrán disponer de este tiempo ahorrado para otras tareas más productivas y beneficiosas.

 

Preguntas y respuestas sobre herramientas ETL

¿Podemos aplicar herramientas ETL en cualquier momento?

Indicábamos al comienzo del artículo que los procesos ETL son apropiados para empresas que inician una estrategia data-driven y cuentan con diferentes fuentes de datos, formatos y almacenados desde hace el suficiente tiempo como para no poder conocer de primeras su procedencia o el motivo por el cual se almacena. Un estado que dentro de la transformación digital denominamos como “data chaos”.

¿Quiere decir que los procesos ETL son únicamente recomendados cuando no tenemos organización ni control sobre nuestros datos? Quiere decir que da solución a este estado de incertidumbre sobre las fuentes de información que se manejan desde la empresa, estemos en un estado avanzado de la problemática (años y años recopilando datos sin un aparente “orden y concierto”) o inicial (comenzamos a trabajar con big data y/o conectamos diversas fuentes de captación, recopilación y almacenaje de datos como cámaras de visión artificial. CMS, campañas de marketing, etc.).

Así, tal como hemos ido insistiendo, las herramientas ETL son las recomendadas siempre que queramos desplegar una estrategia data-driven, que a su vez es lo más recomendable siempre que se trabaja con big data.

 

¿Cuándo es recomendable aplicar herramientas ETL?

O lo que es lo mismo, ¿cuándo desplegar esa estrategia data-driven a la que hemos hecho referencia? La respuesta más simple es la de el momento en el que queremos tener control absoluto sobre la información que extraemos de nuestros datos y la presencia de big data nos lo impide de una forma que no sea correctamente automatizada. Pero esta “simpleza” tiene trampa, ya que una estrategia data-driven es mucho más compleja que aplicar herramientas.

Así, es recomendable acudir a herramientas que nos faciliten procesos ETL en circunstancias como:

 

  • Siempre que se necesite o recomiende cargar datos desde una o múltiples fuentes a un mismo lugar: por ejemplo, en el caso de migraciones a cloud o a data warehouses.
  • Cuando se requiera una limpieza o reformateo de datos: campos incompletos que hacen inservible la información, caducos, de los que se desconoce su procedencia o utilidad…
  • Se quiera tener bajo control la ingesta de datos desde diferentes herramientas que operan bajo un mismo entorno, como cámaras de videovigilancia, bases de datos de clientes, etc.
  • Queramos analizar de forma conjunta o separada cada fuente de datos y la información que contienen, como cuando fusionamos la información obtenida de una campaña de marketing con la existente en nuestro ERP.
  • Pretendamos coordinar nuevas herramientas con las preexistentes y que trabajen de forma conjunta a la hora de obtener insights, que es el caso de aplicar inteligencia artificial.
  • Acudamos a campañas de marketing y queramos asegurarnos desde el cumplimiento de la normativa sobre protección de datos, hasta la máxima satisfacción de los destinatarios, evitando errores en envíos de mails o un uso inapropiado de la información recopilada.

 

¿En qué se diferencian de las herramientas ELT?

Para profundizar en este aspecto, recomendamos el artículo que explica las diferencias entre procesos ELT y ETL. No obstante, a modo resumen, cabe indicar que la principal diferencia que produce extraer, transformar y cargar en vez de extraer, cargar y transformar radica tanto en la velocidad que demandamos a cada proceso, como la infraestructura necesaria para ello.

Ambos procesos bien llevados a cabo, ETL y ELT, ofrecen el mismo resultado: un dato ordenado, gobernado y de calidad, solo que según las características de nuestro ecosistema de datos concreto, nos será más práctico un proceso u otro.

Así, por ejemplo, si trabajamos principalmente on premise y con sistemas de datos estructurados locales, y no concebimos migrar a cloud (algo por otra parte, muy recomendado en cualquier proceso data-driven), nos puede interesar más un proceso ETL, mientras que los procesos ELT están perfectamente diseñados para una escalabilidad más sencilla a cloud.

Es por ello por lo que, antes de decidirnos por un proceso ELT o un proceso ETL, conviene contar con asesoría especializada en data que nos audite nuestro entorno para, de esta forma, contar con la metodología y las herramientas adecuadas, sin caer en el sobredimensionado (contar con una suite donde se cubran procesos que no necesitamos o desconocemos) ni en un uso insuficiente (contar con una suite que necesite posteriores nuevas integraciones para dar servicio a nuestras necesidades del día a día).

 

¿Qué herramientas ETL son las más recomendables?

Con esta cuestión sucede exactamente lo mismo que a la hora de elegir un proceso ETL o un proceso ELT: dentro de la lógica de que hay herramientas que por especialidad, por recorrido en el mercado, por eficacia y/o por el respaldo con el que cuentan, resulten más puntera que otras, a priori no podemos afirmar que X producto sea mejor que otro.

X producto será mejor para X entornos. Es decir, si vamos a iniciar un proceso de transformación de datos, y ya trabajamos con infraestructura de Amazon, a priori (insistimos: toda solución depende de cada ecosistema, de cada forma de trabajar los datos, de cada tamaño de la empresa y sus necesidades, etc.) nos puede interesar más AWS Data Pipeline que cualquier otra. ¿Por qué sea mejor que otras herramientas ETL? Más allá del respaldo de una marca líder, la principal razón sería que la transición, escalabilidad y conexión entre otras herramientas será de menor intensidad entre marcas afines que entre diferentes proveedores.

Por otra parte, nuestra plantilla verá más reconocible y, con ello, con mayor usabilidad, una herramienta del entorno en el que suele trabajar que no otra distinta. De esta forma reducimos la curva de aprendizaje.

En resumen a la hora de responder a esta cuestión (extrapolable también a la aplicación de procesos ELT), en elternativa nos gusta trabajar con diferentes soluciones, sin predeterminar el uso de una herramienta sobre otra antes de estudiar cada caso. De esta forma, ofrecemos un catálogo de alianzas que va desde las mejores valoradas como Informatica PowerCenter (marcada como líder año tras año en el Cuadrante Mágico de Gartner dentro de la gestión de metadatos), hasta aquellas soluciones que durante nuestros años de experiencia en el mercado, nos han funcionado con notable eficacia y en diferentes entorno (caso de Talend, de la que somos el único partner Platinum en España y LATAM).

Principales diferencias entre Data Management y Data Governance

Principales diferencias entre Data Management y Data Governance

Diferencias entre data management y data governance

Un paso imprescindible en todo proceso data es la mediación entre el control y la implementación: no basta con detectar (y corregir) errores, sino desplegar toda una metodología que los evite y controle los procedimientos en los que se desarrollan. Esta dualidad entre detección y prevención/control es lo que hace que términos de negocio parezcan sinónimos pero tengan matices que los diferencien, como ocurre entre data management y data governance, o lo que es lo mismo entre gestión y gobierno del dato. ¿En qué se diferencian?

 

Data management y data governance: la parte por el todo

De forma muy resumida, hablaríamos de data governance como el mapeado de las diferentes estructuras en las que se organiza la producción de datos en la empresa; los propietarios de cada uno de ellos; y las políticas, reglas, metodologías y métricas que se aplican durante su ciclo de vida (que recordemos contempla los protocolos desde su producción hasta que se obtiene la información requerida de él, lo cual incluye su almacenamiento, protección o incluso eliminación).

En cuanto a data management, estaríamos hablando de la implementación técnica de todo lo que implica el gobierno del dato. Es decir, el gobierno del dato sería el plan, y la gestión del dato sería la ejecución: sin data management, data governance es solo documentación.

Un ejemplo sería el de la construcción de carreteras, donde el data governance sería el trazado de la vía que nos lleva de un punto a otro, mientras que el data management implicaría desde los operarios que la construyen, el tráfico rodado que soporta, el número de carriles adecuado, las limitaciones de velocidad, señales y semáforos, etc. ¿Sería posible construir una carretera sin estos elementos? Sí, pero resultaría mucho menos eficiente, presentaría problemas como atascos, su mantenimiento sería más costoso, etc.

 

Data management: maximizando el valor de los datos

Valorando cada uno de los términos por separado, hablaríamos de la gestión del dato (data management) como todo proceso mediante el cual se controla la entrada de datos y su transformación como información válida interviniendo en su integración, analítica y modelado. Todo ello con el fin de ofrecer datos precisos, controlados, seguros, revisados, legales y en definitiva, de calidad.

El resumen que hace DAMA DMBOK (la guía data-driven de referencia en el sector) es el siguiente: «Una función comercial de planificación, control y entrega de datos y activos de información».

No obstante no nos debemos quedar en la superficie y considerar el data management como un conjunto de procedimientos que se aplican para asegurar la calidad del dato: esos procedimientos están plenamente detectados y en ellos intervienen diferentes metodologías y herramientas, las cuales, a través del data quality, permiten beneficiarnos de:

  • Informes coherentes y precisos
  • Conocimiento sobre de dónde proviene cada información y la razón de encontrarse en nuestros conjuntos de datos.
  • Decisiones comerciales respaldadas.
  • Una empresa en la que cada departamento conoce cómo tratar cada dato y comprende los procesados por cualquier otro miembro de la plantilla.

Y, sobre todo… ventaja competitiva, ya que hoy en día, manejar un mayor y más preciso conocimiento del entorno en el que operamos, supone destacar por encima del resto de las empresas.

 

Data governance: guiando el valor de los datos

Para alcanzar cada uno de los puntos descritos en la gestión del dato, la coordinación entre cada uno de los agentes que implica debe ser precisa y no dar lugar a dudas o errores. Es aquí donde entra esa “guía” (lo entrecomillamos porque sería reducir al mínimo todo lo que implica) denominada data governance o gobierno del dato.

Así, una definición resumida de data governance sería la metodología que marca las políticas, los procesos, los estándares, los roles y las responsabilidades necesarios para garantizar una excelente calidad de los datos, o como lo define DAMA: “el ejercicio de la autoridad, control y toma de decisiones compartida (planificación, el seguimiento y la aplicación) a través de la gestión de activos de datos»

Todos estos controles se establecen sobre 10 áreas que la Asociación Internacional de Gestión de Datos (la encargada de crear la guía de referencia del sector antes mencionada, DAMA DMBOK) identifica de la siguiente manera:

  • Data Architecture
  • Data Modeling & Design
  • Data Storage & Operations
  • Data Security
  • Data Integration & Interoperability
  • Document & Content Management
  • Reference & Master Data
  • Data Warehousing & BI
  • Metadata Management

Así, el medio para llevar a cabo todos estos 11 procesos sería el data governance o gobierno del dato.

Data Governance según DAMA DMBOK

 

 

Gestión y gobierno del dato: la solidez que necesitan tus datos

La razón por la que hablamos de data governance y data management como metodologías separadas es porque por sí mismas, cada una complementa y asegura el ciclo del dato de forma diferente (data governance guiando su viabilidad, data management aplicándola). Así, deberemos acudir a una metodología u otra según el grado de avance que tengamos en nuestro plan de transformación digital data-driven, o ambas en el caso de que partamos de cero.

Es por este último punto por lo que a la implementación de la gestión y el gobierno del dato, se le suele acompañar una asesoría o auditoría data quality, ya que en más de una ocasión, debido a todas las partes y procesos que implica, resulta sencillo que quede algún “cabo suelto” en nuestro plan. En cualquier caso, el fin debe ser el mismo: disponer de una base de datos firme, confiable, sin errores en la que puedan intervenir cualquier miembro de la plantilla obteniendo siempre información 100% de calidad, o lo que es lo mismo, disponer siempre de datos gestionados y, por tanto, gobernados.

 

Analiza tus datos
Retos y principales aplicaciones de Inteligencia Artificial en empresas

Retos y principales aplicaciones de Inteligencia Artificial en empresas

Principales aplicaciones de inteligencia artificial en empresas

Las aplicaciones de inteligencia artificial en empresas son cada vez más comunes. La IA ha salido los últimos años de entornos ultratecnológicos y es la apuesta más fuerte para digitalizar servicios y resultar más competitivos en las organizaciones, en una democratización de su uso parecido al que experimentaron otras metodologías disruptivas como internet en los 90.

El principal “culpable” de esta aceleración del uso de inteligencia artificial (pese a contar la historia de la IA entre nosotros con cerca de un siglo) es el big data: la generación diaria de ingentes cantidades de datos imposibles de procesar manualmente, y las necesidades de las empresas de extraer información útil y de calidad para una correcta toma de decisiones hacen de la automatización de procesos la solución más inmediata y eficaz para ello, siendo la IA una metodología muy destacada en este sentido. ¿Cómo abordarla?, ¿qué retos nos supone como empresa?

 

Curación de información: clave para aplicaciones de  inteligencia artificial en empresas

En marketing, se denomina curación de contenidos a la acción de buscar, ordenar, depurar, seleccionar y presentar de forma comprensible las diferentes fuentes que informan sobre un tema concreto, de manera que se filtra y ofrece de forma coherente y organizada los contenidos más relevantes frente a la inmensa cantidad disponible en internet y en otros repositorios.

Mediante esta acción, el content (encargado de los contenidos), presenta la información accesible a cada perfil que lo demande y de una forma que pueda entenderla, a la par que sigue unos protocolos que maximicen su valor (por ejemplo el posicionamiento, visibilidad y usabilidad).

Esta metodología marketiniana se debe hacer extrapolable a la información que se maneja en la empresa: es necesaria una metodología que haga disponible la información contenida en los datos corporativos a cualquier agente que necesite trabajarla, sin necesidad de tener que “bucear” entre gigas y gigas de datos dispersos y la seguridad de que la información obtenida es de calidad y útil para su fin concreto.

Este fin es el que propone el uso de la inteligencia artificial en empresas: la curación de información de forma automática, liberando la dedicación para este fin de los data scientist, para que cualquier agente de la empresa pueda trabajar en todo momento y desde cualquier lugar con ella siempre estando seguros de su validez y eficacia. ¿El principal reto que presenta? Que esta información sea cada vez más novedosa y precisa como para que constituya un importante factor competitivo: de nada sirve incorporar metodologías si no resultan novedosas o no aportan un notable valor diferencial.

 

Principales retos de las aplicaciones de inteligencia artificial en empresas

Incorporar inteligencia artificial en empresas no es simplemente instalar software o aplicar herramientas: requiere de pasos previos como auditar los datos de la empresa, recibir asesoría sobre la metodología más conveniente y los procesos a llevar a cabo, etc. Tampoco es que se deba “revolucionar” el ecosistema de la empresa, pero sí debe haber una voluntad firme de colocar al (buen) dato en el centro de cualquier decisión. Estos son hoy en día los principales retos a los que se enfrenta la aplicación de inteligencia artificial en empresas:

 

La confianza en la metodología IA

Ya lo hemos mencionado y conviene recalcarlo. La lenta implementación que hoy en día se está llevando a cabo con las metodologías de inteligencia artificial es su mayor hándicap a la par que la mayor ventaja para quienes apuestan por ella. Según datos de El País, solo un 16% de las compañías que usan IA creen que están sacando el máximo partido de sus datos. ¿Quiere decir que la IA solo es eficaz en 1,6 de cada 10 empresas? Quiere decir que solo 1,6 empresas de 10 conocen cómo sacarle el máximo rendimiento.

¿En qué fallan el 8,4 de las empresas restantes? En adoptarla como metodología competitiva pero sin visualizar ni entender las razones de su implementación. Tal como indicábamos en los errores más comunes a la hora de digitalizar la empresa, el éxito de incorporar nuevos procesos en este sentido solo es posible si va acompañado de un cambio cultural, que desde la dirección hasta la plantilla entienda la importancia de los datos y cómo el uso de inteligencia artificial los potencia.

 

La integración con el resto de fuentes de datos

La digitalización no es usar herramientas: es aplicar procesos. Dentro de estos procesos, las herramientas son importantes, pero ni en ellas empieza, ni acaba el proceso de transformación digital. Por ello, para que la implementación de IA en la empresa resulte exitosa, se debe integrar en el ecosistema data preexistente, con la finalidad de enriquecerlo, a la par que aporta nuevas fuentes de valor.

Estas fuentes de valor deberán venir tanto de dentro (las bases de conocimiento interno y los datos recolectados previos) como de fuera (nuevas metodologías de captar información) para obtener el máximo rendimiento de la IA a partir de sumar la capacidad de extraer información compartiendo aquellos datos que generan otros actores del ecosistema de la empresa, como por ejemplo los clientes potenciales.

 

Innovar en la extracción de información

¿Y cómo obtener información novedosa de clientes potenciales añadiendo más información de la que se pueda conseguir con las técnicas tradicionales? Es común que construyamos los perfiles de nuestros clientes (fundamental para satisfacerlos y fidelizarlos) en base a cómo interactúan con nosotros o de la información que nos proporcionan en campañas de marketing (edad, género, lugar de residencia…) pero, ¿Y si metodologías como la visión artificial en sectores como el retail nos permitiera, sin ser invasivos y acorde a RGPD, obtener datos como el estado emocional, cuántas veces hace un mismo recorrido, dónde para su atención frente a nuestros productos, etc.?

Esta es una sola de las funcionalidades que podemos llevar a cabo con IA: aplicar visión artificial para hacer un seguimiento anónimo (que puede convertirse en un usuario plenamente identificado combinando esta estrategia con campañas de fidelización por ejemplo) de quienes visitan tu punto de venta, sumando a tus datos, información que no podrías obtener por otros medios no invasivos como el grado de satisfacción.

 

Establecer protocolos de seguridad y protección de datos

La implementación de la inteligencia artificial en empresas debe ir acompañada de expertos en la materia que aseguren un entorno operativo, práctico… y seguro. La seguridad no es un problema exclusivo de la IA, sino de toda materia que involucre big data. Por ello, existe un marco regulador común a todos en Europa, el RGPD, que indica con precisión el tratamiento correcto que le debemos dar a los datos que recopilamos con fines comerciales y de crecimiento empresarial.

Es por ello que en el anterior punto hacíamos referencia al “seguimiento anónimo” (X individuo de X rasgos y características, hace X recorrido por mi tienda) que puede ser transformado en seguimiento personal (Antonio López, hombre caucásico de 39 años que se ha parado hasta en 3 ocasiones en solo diez minutos frente al expositor de pantalones vaqueros) solo con el consentimiento del propio cliente, algo que se puede conseguir mediante técnicas de fidelización (un descuento del 5% rellenando el formulario de contacto y aceptando el tratamiento de sus datos para fines comerciales).

Con ello, queda patente que el uso de IA tiene las mismas implicaciones en cuanto a seguridad y protección de datos que cualquier otra herramienta que podamos usar para fines similares (analítica web, facturación, etc.). La seguridad la aporta el entorno, las metodologías y las aplicaciones que se usen para ello, de ahí a la necesidad de auditorías previas como ya habíamos insistido, y la asistencia profesional.

 

Demostrar (y buscar) el beneficio al cliente y la empresa

Es el reto “ético” del uso de inteligencia artificial en empresas y profundo tema de debate por el cual se llega a cuestionar su utilización por quienes no comprenden su funcionamiento: la IA no ha venido ni a eliminar puestos de empleo, ni a invadir la privacidad.

La inteligencia artificial simplemente se plantea para mejorar la productividad por parte de la empresa y el conocimiento que tenemos del cliente por parte de la actividad del negocio a la que la aplicamos.

Así, la inteligencia artificial resuelve el trabajo de filtrado, limpieza y presentación de datos en empresas en el que el volumen de éstos es tal, que sería imposible resolverlos de forma manual. Por ello, la IA se encarga de un trabajo que de por sí resulta inabarcable: no sustituye, mejora lo procesos. Así, la persona encargada de la gestión de datos no se ve reemplazada, sino que dispone de más tiempo y menos esfuerzo que le permite dedicarse a otros aspectos fundamentales de sus tareas.

En cuanto a la perspectiva del cliente, la recopilación de sus datos no se lleva a cabo para “invadir su privacidad” (hecho que, dicho sea de paso, ya se da en casos como la navegación web o el uso de aplicaciones en el smartphone), sino para aspectos que le suponen un beneficio, ya sea mejorando un producto hasta el punto de resolverle necesidades específicas cuando antes no lo hacía (gracias a la información recopilada); ya sea mejorando la comunicación que se lleva a cabo con él (evitando por ejemplo mails repetitivos, sin su interés a la hora de abordar campañas de marketing).

Podríamos resumir llegados a este punto con que el principal reto de la aplicación de inteligencia artificial en empresas por tanto no reside en sus facultades o las tareas que resuelve, sino conocer todas las implicaciones y beneficios de su uso. Un uso que tarde o temprano será mayoritario dado el crecimiento exponencial de todo lo que supone trabajar con datos, y que por tanto, cuanto antes resolvamos este reto, antes ganaremos en competitividad. ¿Dispuesto a dar el paso?