Desafíos para la monetización de productos de datos

No cabe ninguna duda acerca del enorme valor de los datos y lo que un adecuado tratamiento de los mismos puede aportar a una organización.

Una buena disponibilidad de datos en cantidad y calidad, y un adecuado e intenso aprovechamiento de los mismos mediante indicadores, informes y análisis, incluyendo en los casos más avanzados el uso de inteligencia artificial, puede mejorar enormemente la gestión, la detección de tendencias y problemas, la toma de decisiones y por todo ello la posición competitiva de esa organización.

Pero el uso de los datos no tiene por qué limitarse a su empleo interno para la mejora de la propia operación sino que, en algunos casos, productos basados en datos pueden incorporarse al porfolio de productos y servicios de la empresa, ya sea como un complemento a los, digamos, productos y servicios 'nucleares' o incluso convertirse en la parte principal de ese porfolio haciendo que todo el modelo de negocio gire entorno a esa 'producción' y comercialización de 'insights', análisis o incluso datos 'per se'.

Pero, claro, si vamos a monetizar los datos, si éstos van a formar parte importante de nuestra proposición de valor, debemos estar preparados para ello.

En su libro 'A Data-Driven Company: 21 lessons for large organizations to create value from AI', Richard Benjamins identifica, en efecto, tres retos que hay que afrontar si se quiere ir a una monetización de datos. Son estos:

• Madurez: Con independencia de la forma en que evaluemos esa madurez, cosa no tan sencilla y de la que hablamos en el post anterior, lo que está claro es que si queremos ofrecer productos o servicios basados en datos debemos tener 'la maquinaria bien engrasada' en cuanto a la disponibilidad tanto en cantidad como en calidad de esos datos, así como en el procesamiento y  gestión de los mismos (obtención, gobierno, seguridad, etc). En cierto modo, esto es obvio.


• Privacidad: Un aspecto muy importante desde el punto de vista ético legal. Dado que con mucha frecuencia los datos disponibles y los que aportan información relevante incluyen datos personales o sensibles en algún sentido, se deben aplicar adecuadamente las técnicas de agregación y anonimización y respetar las regulaciones y legislaciones existentes, muy en especial el famoso GDPR.


• Reputación: Aunque se trate en este caso de un intangible, no basta sólo con cumplir escrupulosamente todo lo relativo a privacidad y todas las normativas existentes, sino que además es importante que se perciba entre el público y los clientes ese tratamiento ético y legal de los datos y su uso para el bien.

Como suele pasar en estos casos, formular los retos es mucho más fácil que resolverlos. Muy especialmente, el primer reto, el poner a punto toda la maquinaria de identificación, captura, limpieza y procesamiento de datos, puede ser realmente trabajoso. Pero si vamos a monetizar los datos, no cabe duda que se gestión pasa a formar parte de nuestro 'core business', así que no queda otra.

Síntomas de madurez en la gestión de datos

La madurez de una empresa en una determinada disciplina nos indica, de alguna forma, el grado en que esa disciplina se aplica dentro de la empresa, hasta qué punto ha penetrado en ella, la calidad e incluso excelencia de  dicha aplicación y la estabilidad en su uso, hasta qué punto esa disciplina ya forma parte del día a día de la empresa.

La madurez en ingeniería software

Creo que el primer ámbito donde se aplicó esta idea de la madurez, al menos del primero de que yo fui conocedor, fue en lo relativo al desarrollo software. Quizá porque la ingeniería software, y pese a ese nombre de ingeniería, se resistía (y en cierto modo se sigue resistiendo) a ser una disciplina completamente ingenieril, difícil de encajar en procesos y procedimientos perfectamente definidos, se buscó, al menos y como alternativa, esa idea de la 'madurez' en su aplicación como un conjunto de mejores prácticas que identificaban un uso estable y excelente de la ingeniería del software. 

Y ello culminó en la definición del CMMI (Capability Maturity Model Integration) que cristalizaba y daba forma más concreta a lo que significaba esa madurez y cómo identificarla y clasificarla dentro de una empresa.

Otros casos de madurez

Posteriormente he oído habla de madurez en otros ámbitos que, en general, también se refieren a disciplinas de gestión que son importantes pero difíciles de formalizar en procesos cuasi-industriales. Así, por ejemplo, también he oído hablar de madurez en el ámbito de la gestión de procesos de negocio.

La verdad es que no me causan entusiasmo sino, más bien, un cierto escepticismo, esas ideas de madurez porque me parece que, pese al loable esfuerzo que suponen, al final se siguen quedando en el campo de lo inconcreto, de lo abstracto e incluso parcialmente subjetivo.

La madurez en la gestión de datos

Leyendo el libro libro 'A Data-Driven Company: 21 lessons for large organizations to create value from AI' de Richard Benjamins me encuentro con esa idea de madurez aplicada en este caso a la gestión de los datos en la empresa, a la búsqueda de ese concento de 'data-driven'. 

En una aportación del experto Daniel Rodríguez Sierra, director de Big Data y Analítica Avanzada de Vodafone, éste afirma que la madurez en datos ('data maturity') es más un proceso que un estado y reconoce que esa madurez en los datos es difícil de definir así que renuncia en cierto sentido a aportar esa definición y, en su lugar, propone, y sólo a modo de ejemplo, una serie de efectos o síntomas que pueden indicar esa madurez en la gestión de los datos. Son estos:

• El núcleo del negocio, el llamado 'core business' va de datos y éstos constituyen su materia prima sobre la que se construye


• Aunque el negocio no sea un negocio nativo de datos, sí que se gestiona de manera continua mediante decisiones apoyadas en datos, soportadas por analítica avanzada y machine learning y éstas se encuentran embebidas en los procesos de negocio con una automatización creciente.


• Existe unicidad de datos, es decir, la organización es rica en datos pero en su nivel más granular, existe una única versión de cada dato.


• Los datos y conclusiones ('insights') se acceden de manera mayoritaria como un autoservicio para los empleados.


• El diseño y ejecución de las actividades de cara a cliente se apoyan en predicciones y análisis causales de patrones de comportamiento de esos clientes.


• Los datos se transforman en conocimiento valioso siguiendo unos estándares comunes que la propia organización evalúa de manera regular.


• Existe un órgano dedicado a la cadena de valor del dato extremo a extremo que asegura la disponibilidad y adquisición de los datos y la calidad en la integración de resultados obtenidos vía machine learning en los procesos adecuados, incluyendo salvaguardas de seguridad y privacidad.

Como se puede observar, no se trata de una receta concreta medible o automatizable directamente sino de una serie más bien cualitativa de buenas prácticas o síntomas de un buen y avanzado uso de los datos.

Los ejemplos que propone Daniel Rodríguez nos hablan de organizaciones realmente avanzadas y maduras en el uso de datos, siendo el primer punto aplicable a compañías cuyo negocio son los datos y el segundo compañías (la mayoría) cuyo negocio no son los datos pero hacen un uso avanzado de ellos. 

Y me parece muy importante la idea de la unicidad del dato y la disponibilidad en modo autoservicio para los empleados que encaja muy bien con la idea de la fuente única de la verdad que comentábamos en un post anterior y con mi propio entendimiento de lo que es una buena gestión de datos.

Iniciando el camino

La imagen que traslada Herrera es avanzada, quizá muy avanzada, pero tampoco hay que asustarse. En cierto modo esa es la visión final, la aspiración. 

Cualquier empresa puede iniciar su camino hacia la gestión basada en datos con objetivo inicialmente más modestos, identificando fuentes de datos, construyendo los primeros datawarehouse o datalakes, construyendo cuadros de mando mediante sencillos visualizadores de datos, etc. Sólo con eso, se puede obtener mucho valor e iniciar ese camino hacia el data-driven en el que ya habrá tiempo de buscar la madurez.

Datos corporativos y la fuente única de la verdad

Con el avance de la digitalización, a medida que las empresas se dotan de más sistemas y a medida, también, que existen más fuentes de información externas, las posibilidades de desarrollar capacidades de reporting y analíticas crecen en gran medida.

Crece, por tanto, la capacidad de obtención de indicadores y KPIs, de realización de informes, de implementación de cuadros de mando incluso en tiempo real o cuasi-real y también de realización de análisis, algunos incluso sofisticados empleando técnicas de machine learning.

Esa posibilidad debería caso ser considerada como una obligación de gestión y competitividad por parte de cualquier empresa. Conocer de forma sistemática y exacta la propia situación o la del mercado y disponer de datos en que basar decisiones parecen capacidades inexcusables hoy día en el entorno corporativo aunque, en mi percepción, bastante insuficientemente implementadas todavía. Unas capacidades que, además, y dentro de lo que cabe, son de una sencilla y poco arriesgada implementación.

Supuesto que la empresa decide, en efecto, aprovechar los datos de que dispone para la realización de cuadros de mando, informes y análisis, puede surgir la pregunta de quién debería procesar esos datos, quién debería realizar los análisis. Puede considerarse que debe tratarse de una actividad centralizada, que debe realizarse a nivel de compañía, o bien puede entenderse que es una función que es mejor llevar a cabo de manera distribuida, a nivel de unidad de negocio, departamento, etc,

Este es uno de los temas que trata Richard Benjamins en su libro 'A Data-Driven Company: 21 lessons for large organizations to create value from AI'. El autor analiza las características, pros y contras, de un enfoque centralizado con base en el concepto de centro de excelencia y de uno distribuido.

Y como conclusión, quizá porque es un reflejo de lo que es mi propia opinión, me quedo con la siguiente frase:

The data function always needs some notion of centralization because there should be a single source of the truth within an organization.

Según se entiende de la frase, puede existir un cierto nivel de distribución de las capacidades analíticas pero siempre con una cierta dosis de centralización que garantice una visión única, la así llamada fuente única de la verdad.

En mi propia experiencia profesional he trabajado en una empresa grande, con muchos sistemas y fuentes de datos y también con una capacitación e incluso cultura que posibilitaban y hasta favorecían los análisis departamentales e incluso individuales, algo que por sí mismo hay que valorar positivamente.

Y en ese contexto me he encontrado en diversos debates precisamente sobre si los indicadores deberían centralizarse o distribuirse y mi posición, que mantengo, es convergente con la frase de Benjamins, advirtiendo, eso sí, que ni siquiera, en el caso real que describo, hablábamos de verdaderas capacidades analíticas, sólo de indicadores e informes.

Realizar análisis a nivel de departamento, grupo o persona puede tener como ventaja un conocimiento más profundo de la realidad analizada y, quizá, una mayor creatividad y rapidez. Por tanto, no creo que se deba cerrar la puerta a esta forma de trabajo ni mucho menos, especialmente si hablamos no tanto de indicadores e informes operativos como de analítica, de análisis profundo.

Sin embargo, descentralizar la medición y obtención de indicadores puede llevar a KPIs no disponibles para toda la organización sino sólo para algún departamento que tal vez los guarde celosamente para sí. Puede llevar también a indicadores que, queriendo medir lo mismo, están basados en diferentes fuentes de datos, con denominaciones y criterios de cálculo quizá incoherentes entre sí lo que dificulta la visión conjunta y la comparativa. Y, en el peor de los casos, los indicadores y análisis pueden estar sometidos a riesgo de una cierta manipulación interesada. 

Y no puede ser así. Y no puede ser especialmente si hablamos ahora, no tanto de analítica avanzada como de reporting básico, de indicadores de desempeño empresarial, especialmente los indicadores clave, los KPI.

La descripción de la realidad objetiva de una compañía, la que proviene de datos, debería ser única. Debería existir esa fuente única de la verdad, una visión compartida en toda la compañía.

Aquellos indicadores fundamentales de la compañía, indicadores financieros, comerciales y operativos estoy convencido de que deberían obtenerse de manera centralizada y, en la medida de lo posible, y sin desvelar nada sensible, ser públicos y notorios para toda la organización constituyéndose así en esa fuente única de la verdad, una fuente de la verdad, además, trasparente, explicada, documentada y objetiva. 

Es la forma más razonable de fundamentar las decisiones de la alta dirección. Y es la forma también de que el resto de la compañía pueda entenderlas e incluso aportar ideas en un enfoque más bottom-up. Es una forma de alineamiento de empleados y unidades con la realidad de la empresa, es una forma de comunión de entendimiento e intereses y casi, casi, y bien hecha, es una forma de gestión del cambio cuando esos indicadores nos den pistas de que debemos cambiar y por qué.

Diez recomendaciones para innovar en modelos de negocio

Quizá la forma más profunda de innovación y de transformación sea la innovación en modelos de negocio. Al fin y al cabo, un modelo de negocio define la forma de operar y competir de una compañía por lo que cualquier cambio en él es importante, estratégico y, normalmente, profundo.

Se trata, por tanto de un proceso clave pero para el cual no es fácil encontrar metodologías ni recetas.

En algún post reciente ya hemos tocado algunas ideas sobre innovación en modelos de negocio con base en el libro 'The business model navigator' de Oliver Gassmann, Karolin Frankenberger y Michaela Choudury. En concreto, por ejemplo, vimos un 'decálogo para la toma de buenas decisiones estratégicas'. Hoy, y con base en la misma fuente bibliográfica, vamos a esbozar unas ideas en cierto modo complementarias de las vistas en ese artículo, mediante la revisión de un nuevo decálogo, en este caso, la propuesta con que los autores cierran el libro y donde identifican diez recomendaciones a modo de 'take away' de su obra.

Las diez recomendaciones de cara a una efectiva innovación en modelos de negocio serían las siguientes:

• Obtener el apoyo de la alta dirección: Los autores apuntan a incrementar la conciencia sobre todo el tema de la innovación en modelos de negocio, a ser persistentes y a referirse a las mejores prácticas tanto internas como externas. Diría, sin embargo, que, en el caso de la innovación de modelos de negocio no es tanto que se deba obtener el apoyo de la alta dirección sino que debe ser ésta realmente la primera impulsora. Al fin y al cabo, modificar un modelo de negocio es pura implementación estratégica y eso es, indudablemente, tarea fundamental y característica de la alta dirección.


• Establecer un equipo diverso: Como todo proceso innovador, también en el caso de la innovación en modelos de negocio, se beneficia de la existencia de diferentes puntos de vista que pueden aportar personas de diferentes áreas funcionales e incluso personas externas.


• Estar preparado para el cambio y abierto a aprender de terceros: Adoptar la filosofía de que se puede y debe estar orgulloso de adoptar ideas procedentes del exterior (como alternativa al síndrome del 'no inventado aquí') y monitorizar permanentemente los cambios en el ecosistema de la compañía.


• Desafiar la lógica dominante en la organización: Para lo cual los autores proponen la confrontación del modelo de negocio actual de la compañía con los 60 patrones de modelos de negocio que ilustran en su libro, en busca de ideas que se puedan incorporar.


• Crear una cultura de apertura: Evitar la existencia de 'vacas sagradas' y la emisión de juicios negativos acerca de ideas de cambio en las primeras etapas de ideación.


• Usar un enfoque iterativo con varias iteraciones: Ser conscientes de que no es fácil encontrar la idea más brillante nada más empezar así que persistir y, en el proceso, intentar identificar bien cuándo se debe pasar de la fase divergente (generación de ideas) a la convergente (selección y detalle de una opción). Además, asegurarse de validar cuanto antes las diferentes hipótesis que se usen.


• Evitar calcular en exceso los casos de negocio: La realidad suele desmentir los planes de negocio así que no hacer cálculos en exceso y, en su lugar, aparte del proceso iterativo anterior, pensar en diferentes escenarios y definir los umbrales que el modelo de negocio debe alcanzar para considerarlo exitoso.


• Limitar los riesgos mediante el uso de prototipos: Intentar siempre que sea posible, materializar las ideas en prototipos e intentar obtener realimentación rápida sobre el modelo de negocio y, con base en ella, modificarlo si es necesario.


• Proporcionar al nuevo modelo de negocio suficiente contexto para que crezca exitosamente: Hacer de la innovación de modelo de negocio un proceso continuo, dando tiempo a los equipos para desarrollarlo y mirando más los objetivos a largo que a corto.


• Gestionar de manera activa el proceso de cambios: Promover la comprensión dentro de la compañía del proceso de innovación en modelo de negocio, asegurar un proceso de cambio justo y transparente, desarrollar las habilidades que sean necesarias en el equipo humano y asegurar una actitud positiva hacia la innovación.

No se trata, como se puede ver, de una recomendación metodológica, para lo cual los autores ya hacen una propuesta al inicio de su libro. Se trata, más bien de una filosofía y unas actitudes y prácticas subyacentes, algunas más cercanas a lo metodológico y conectadas con tendencias como Lean startup como son el enfoque iterativo o el uso de prototipos, pero otras propuestas tienen más que ver con la cultura de la innovación, el liderazgo y, sobre todo, la gestión del cambio en el proceso de innovación e implementación y, en ese sentido, no son muy diferentes de las que podemos encontrar en otros tratados sobre innovación o transformación.

No son, por tanto, en sí mismas, ideas que nos sorprendan. Se trata eso sí, no sólo de 'que nos suenen', que ya nos suenan, sino de aplicarlas realmente.

Gestión del cambio y economía de la atención

Desde hace muchos años sabemos que cualquier gran cambio en una empresa, un gran cambio que puede incluir una transformación digital, debe ir acompañado de acciones orientadas a las personas, acciones pensadas para conseguir las aptitudes necesaria y alinear actitudes hacia el objetivo, acciones de formación y comunicación, acciones que consigan que las personas acepten e incluso deseen la transformación y que estén preparadas para ello. Y en eso es, justamente, en lo que consiste la así llamada gestión del cambio.

Como acabamos de mencionar, uno de los ingredientes nucleares de esa gestión del cambio es la comunicación, que se constituye como el arma principal para el alineamiento de actitudes.

Sin embargo, se puede producir un fenómeno curioso, una paradoja. Quizá porque se es consciente desde hace muchos años de esa necesidad de comunicación, quizá porque los medios tecnológicos actuales, incluyendo intranets, correos electrónicos o redes sociales, facilitan mucho las acciones de comunicación, quizá porque nos hemos acostumbrado a estar permanentemente conectados, lo cierto es que las personas vivimos sometidos actualmente a una fuerte presión de comunicación, a un flujo constante e intenso de comunicaciones de todo tipo tanto en el ámbito doméstico como en el profesional. Con ese panorama, puede ser difícil captar la atención de los empleados en las acciones de gestión del cambio e incluso, quién sabe, puede resultar hasta contraproducente el insistir en comunicar en según qué casos.

Así nos lo hacen notar Oliver Gassmann, Karolin Frankenberger y Michaela Choudury en su libro 'The business model navigator' que habla de innovación en modelos de negocio (un cambio profundo que sin duda necesita gestión del cambio) cuando nos dicen: 

But the cause of failure is usually not too little communications, but rather too much. Today's employees are flooded with information: emails, interoffice memos, weekly meetings and more, and it is often difficult for them to understand what is important and what isn't.

Y esto me hace pensar en la llamada economía de la atención, un concepto que hace referencia a la lucha que establecen las marcas por conseguir captar la atención de los usuarios, los clientes, el público en general. En efecto, la atención de las personas es un bien importante para las empresas para crear conciencia de marca y sobre ventas, pero un bien que se ha convertido en recurso escaso dada la altísima demanda por parte de las marcas, y no solo las marcas, de esa atención.

Así que, en cierto modo, la gestión del cambio, aunque se produzca dentro de una empresa y no hacia clientes externos, se ve de alguna manera inmersa en esa misma economía de la atención, en esa lucha por conseguir la atención de los propios empleados saturados ya de mensajes y comunicaciones.

No es tarea sencilla. La transformación y gestión del cambio a ella asociada no puede renunciar a comunicar a los empleados sus motivaciones, objetivos e impacto, pero debe conseguir hacerlo sin saturar y captando realmente la atención y no convirtiéndose en mero ruido de fondo. 

Quizá, lo que las empresas deban hacer es rebajar la comunicación de aspectos menos relevantes, más accesorios, y también evitar la sobre-actuación, la exageración o el triunfalismo en comunicaciones menores, para dejar espacio en la mente y atención de sus profesionales para aquellas otras que son realmente importantes y transformadoras.

No es fácil, desde luego, pero es importante conseguir gestionar adecuadamente esa atención. Va mucho en ello.

Tres razones por las que Internet de las Cosas cambia la forma de hacer negocios

Una de las cuatro tecnologías clave para la transformación digital, en la visión que propone Tom Siebel en su libro 'Digital Transformation : survive and thrive in the era of mass extinction', es Internet de las Cosas.

Ya hemos dedicado un breve artículo a otras dos, Cloud computing y Big Data. Ahora revisamos la capacidad transformadora de Internet de las Cosas. En concreto, el autor identifica tres factores que le otorgan ese poder transformador. Son estos: 

• Volumen de datos: Los sensores que se incorporan en IoT captura informaciones de su entorno que convierten en datos procesables en un enorme volumen. El autor aporta una referencia numérica en que haba que en 2020 se esperaba (no he podido comprobar si se ha conseguido) la generación de 600 zettabytes anuales.


• El valor de esos datos: No solo se generan datos sino que estos, además, son muy valiosos dado que, en el fondo, se trata de medidas del propio negocio y, aparte de su aportación de naturaleza operativa, esos datos también permiten tomar mejores decisiones.


• Efecto red: El valor se Internet de las Cosas se incrementa a medida que hay más dispositivos o sensores incorporados. En concreto, el autor menciona en este punto la ley de Metcalfe según la cual el valor de una red aumenta con el cuadrado del número de nodos (en este caso dispositivos o 'cosas' conectadas)

Diría que, aparte de estos factores, hay que tener en cuenta también la enorme variedad de soluciones que la incorporación de dispositivos inteligentes interconectados, unos dispositivos que permiten la interacción con el mundo físico, permiten construir y que afectan a casi cualquier sector.

Seguro que iremos cada vez más soluciones tanto en en las empresas como en el mundo doméstico.

Cinco retos clave para organizaciones que quieren afrontar Big Data

Nadie dijo que hacer analítica o Big Data fuese a ser fácil. En realidad, hay factores que han facilitado mucho las cosas, factores como la aparición de herramientas libres como Hadoop y todo su ecosistema o la disponibilidad en la nube de soluciones avanzadas, hechos ambos que democratizan y simplifican enormemente la entrada en el mundo del Big Data. 

Pero a pesar de esos avances, a pesar de la evidente viabilidad e interés de abordar este tipo de sistemas, su implantación práctica, especialmente en grandes organizaciones con mucha historia, con muchos sistemas y fuentes de datos, con muchos legados y con su tradición cultural no es sencillo.

En su libro 'Digital Transformation : survive and thrive in the era of mass extinction', el autor Tom Siebel, identifica, en concreto, cinco retos clave a los que hay que hacer frente.

Son estos:

• Gestionar la multiplicidad de fuentes de datos: Las grandes empresas suelen disponer de una variedad de sistemas, amplia y heterogénea y que incluye desde sistemas empresariales como ERP o CRM hasta versiones menores de este tipo de software como, quizá, sistemas de nóminas o recursos humanos; o también sistemas muy específicos como los SCADA o MES de las empresas industriales o los sistemas de supervisión en telecomunicaciones; o herramientas más laxas en cuanto a datos como las soluciones colaborativas o de gestión documental; productos comerciales o desarrollos a medida; sistemas en mainframe o sistemas web. Y así un largo y variado etcétera. Conseguir con ese punto de partida una visión de datos unificada, integrada y explotable no es sencillo en absoluto. 


• Incorporar y contextualizar datos de alta frecuencia: En algunos casos, como cuando estamos en entornos ciberfísicos o de Internet de las Cosas, en que los datos provienen de sensores, la entrada de datos es de tiempo real o alta frecuencia. Se trata de una complejidad adicional, una complejidad para la que algunas bases de datos NoSQL y soluciones de Big Data están especialmente bien preparadas, pero que añade, en cualquier caso, un punto de complejidad adicional. 


• Trabajar con 'data lakes': Se refiere al autor al uso de sistemas de ficheros distribuidos (como el famoso HDFS de Hadoop) y al hecho de que su adopción aún es relativamente baja y también menciona la necesidad de normalización de datos o de eliminar duplicados, algo que ya nos acerca al siguiente reto. Un reto que, quizá, el autor no define bien y que lo que implica, en el fondo es la necesidad de emplear una tecnología avanzada, HDFS y MapReduce en este caso, que va más allá de lo que las soluciones de Business Intelligence más tradicionales podrían ofrecer.


• Asegurar la consistencia de datos, la integridad referencia y el uso continuo aguas abajo: quizá, junto con el reto de la diversidad de fuentes, y en el fondo derivado de él, el mayor problema práctico. Al tomar datos de partida procedentes de diferentes fuentes, cada una con un modelo de datos diferente, no coordinado, resulta complejo y, sobre todo, muy laborioso, conseguir una imagen unificada de los datos, una imagen en que el mismo dato se represente de la misma forma (mismo tipo de dato, misma longitud, mismos valores posibles, misma semántica,...) algo que suele precisar farragosas traducciones desde modelos de partida al modelo unificado. Y algo que se complica al hablar de la referencialidad, de las relaciones entre entidades muchas veces no evidentes o sin información suficiente o suficientemente consistente.


• Habilitar nuevas herramientas y habilidades para nuevas necesidades: Esto incluye el uso de nuevas herramientas (visualizadores de datos, machine learning, etc) y por tanto, la necesidad de disponer de esas herramientas y de formar a los equipos en su uso o bien incorporar a personas con esas capacidades.

En mi experiencia personal, diría que la diversidad de fuentes y la dificultad para asegurar la consistencia son, con diferencia, las problemáticas más importantes y generalizadas. Dos problemáticas entrelazadas y, además, carentes de 'glamour' pero a cambio sí necesitadas de mucho trabajo, mucho esfuerzo, que se abordan mediante lucha de guerrillas y de trincheras, sistema a sistema, dato a dato.

La verdad es que siempre he considerado más fácil implantar una solución informacional o analítica que una solución operacional o de automatización de procesos. 

Pero, a pesar de ello, a pesar del avance tecnológico, a pesar de la disponibilidad real de avanzadas tecnologías y herramientas, no hay que confiarse: implantar una solución informacional, analítica y ya no digamos de Big Data en una empresa real, con tamaño e historia es todo un reto. 

Eso sí, la recompensa vale la pena.