¿Por que este blog?
Sabemos que los proyectos de datos a veces pueden ser complejos, especialmente para definirlos y abordarlos desde las áreas ejecutivas en las organizaciones. Algunas de las tecnologías más novedosas se popularizan porque las empresas más grandes en tecnología las aplican y se vuelven la hoja de ruta para muchos entusiastas en organizaciones y consultoras por igual. No obstante, la mayoría de las necesidades en las empresas siguen estando por ahora fuera del dominio de la inteligencia artificial y de los modelos de analítica avanzada. Esto fue evidente con el boom de las ciencias de datos, en el que todas las empresas querían científicos de datos para generar modelos predictivos y prescriptivos que les permitieran tomar las mejores decisiones, para finalmente darse cuenta que sus datos no tenían la calidad adecuada y era más importante “organizar la casa” y contar con métricas fiables.
Adicionalmente, en el área de datos encontramos información actualizada y desactualizada por igual, que puede resultar confusa e incoherente. Por ejemplo, a veces escuchamos que las bodegas de datos (data warehouses) y los modelos dimensionales son cosa del pasado y que ya no tienen utilidad. Sin embargo, también se habla de bodegas de datos de segunda generación, de lakehouses, arquitecturas data mesh y plataformas de datos híbridas que abordan datos transaccionales y analíticos. ¿A quién creer entonces?
Entre todos estos conceptos y prácticas, a veces se pierde la visión de la necesidad de negocio, se abordan los proyectos de manera incorrecta, o se diseñan de la manera equivocada, generando reprocesos y pérdida de capital. No son pocas las empresas que han quedado con mal sabor en proyectos de datos y analítica. Por esta razón, en BigView hemos decidido generar un blog que aborde todos estos temas para que las organizaciones puedan abordar estos retos con un mayor conocimiento de las diferencias y similitudes entre los diferentes conceptos y paradigmas que se tienen hoy en el mercado.
Introducción a los proyectos de datos y analítica
En esta entrada, se exploran diversos conceptos en proyectos de análisis y analítica de datos. Teniendo en cuenta que existen diferentes términos y tecnologías en el mercado, se espera brindar mayor claridad a los roles no técnicos (de negocio) y técnicos de los diferentes aspectos involucrados iniciando con una perspectiva de arquitectura empresarial, es decir, abordando estos proyectos con los equipos de trabajo, procesos y recursos esperados. En entradas posteriores se abordarán otros escenarios de interés con mayor detalle y profundidad.
Con el fin de lograr un mejor entendimiento entre los equipos de negocio y los equipos técnicos, se utilizará un lenguaje principalmente de negocio, incluso cuando se aborden algunos conceptos técnicos clave en el proceso. Finalmente, se brindarán algunas recomendaciones especiales basadas en nuestra experiencia de consultoría,
La necesidad de Negocio
Los proyectos de datos responden a las necesidades del negocio, quien normalmente cuenta con datos de alto valor para la organización y que se deben analizar para optimizar la operación, brindar nuevos servicios y mejorar la experiencia de usuario.
Estos datos se almacenan en diferentes fuentes de datos, de las cuales se espera generar servicios de datos que responden a dos necesidades principalmente:
· Datos para analistas de negocio: A través de reportes interactivos, fijos, o reportes tabulares.
· Datos para otras aplicaciones: A través de interfaces entre sistemas informáticos que se denominan API (Application Programming Interface)
En ambos escenarios, se considera relevante contar no solo con datos organizados y de calidad, el primer reto de muchas empresas; sino además contar con datos enriquecidos, que son nuevos datos generados a partir de reglas de calidad, reglas de transformación y modelos de análisis avanzados que permitan realizar predicciones, categorizaciones, entre otros. Estos procesos apoyan en última instancia la toma de decisiones, tanto de analistas humanos, como de máquinas a través de servicios de recomendación, por ejemplo.
Lo anterior, se puede resumir en el siguiente modelo, donde se puede evidenciar que el requerimiento del negocio es finalmente utilizar los datos que con tanto esfuerzo ha recopilado en los diferentes procesos. A partir de este requerimiento el objetivo es ofrecer entonces servicios de datos de alto valor para el negocio, donde el valor se refleja básicamente en el apoyo a la toma de decisiones y la automatización de procesos, las cuales generan a su vez, ventajas competitivas más específicas.
Nota: El modelo está generado en Archi y utiliza el lenguaje Archimate, un lenguaje de modelado que permite modelar diferentes aspectos de una organización. Si desea conocer más sobre Archimate el link official es The ArchiMate® Enterprise Architecture Modeling Language | The Open Group Website
En las fuentes de datos, se puede evidenciar que al NEGOCIO le interesan principalmente las entidades de su negocio (clientes, productos, oficinas, etc) y los eventos que ocurran a esas entidades y que se registran como transacciones (creación, adquisición, retiro, compra, etc). Por otro lado, desde una perspectiva TÉCNICA, es importante validar la disponibilidad de los datos y los tipos de datos que pueden ser estructurados (filas y columnas fijas con tipos de datos definidos), semi estructurados (estructura esperada con posibles variaciones) o no estructurados (sin estructura o patrón).
Recomendación 1: Valide si los datos que quiere analizar son los correctos y se encuentran
disponibles en el formato correcto
Siempre es importante validar el tipo y formato de los datos desde una perspectiva de procesos y no meramente técnica. En algunos escenarios, es necesario mejorar la calidad de los datos desde la fuente definiendo la estructura correcta de captura de los datos, ya que algunas veces se cuentan con datos no estructurados en procesos que deberían recopilar datos de manera más estructurada y exacta. Por ejemplo, cuando un sistema de solicitudes de soporte cuenta solo con correos electrónicos (datos no estructurados) y es conveniente contemplar un proceso que permita clasificar la solicitud e identificar la prioridad de la solicitud según el rol del usuario que crea la solicitud (datos estructurados de la solicitud). La estructuración de estos datos requiere además definir categorías a nivel de procesos de negocio. En estos casos se recomienda primero trabajar en la sistematización de ese proceso para tener datos más precisos desde el origen y evitar un proceso de analítica que no genera valor: basura entra, basura sale.
Lo contrario también puede suceder, a veces se recolectan datos estructurados que resumen o generalizan información subyacente y por lo tanto se genera perdida de información relevante. Por ejemplo, al categorizar imágenes desechando la imagen original. En este caso, debería considerarse la captura de los datos completos en su formato original no estructurado además de los datos adicionales estructurados que puedan tenerse. Cada organización puede tener ejemplos concretos en sus procesos internos.
La priorización de los requerimientos de datos debe considerar en primera instancia, el valor para el negocio a partir de las entidades y eventos identificados. No obstante, también es importante evaluar el esfuerzo requerido para dar respuesta a esos requerimientos según los tipos de datos disponibles. Ambos criterios permitirán definir en última instancia los primeros requerimientos que serán abordados desde una perspectiva ágil que permita brindar resultados tempranos a la organización.
Finalmente, los servicios de datos que se ofrezcan serán normalmente para reportes en diferentes niveles de decisión: operacional, táctica, estratégica; así como datos a otras aplicaciones a través de API. La frecuencia en que se sirven estos datos puede ser en línea (cuando el dato origen se genera o cambia) o por lotes (en batch): cada minuto, hora, diario, semanal, mensual, etc. La decisión de tener datos actualizados en línea o en lotes obedece aún hoy a los costos asociados y a los tipos de análisis, por lo que normalmente se tiene una mezcla de ambos escenarios.
Recomendación 2: No olvide que los servicios de datos son para personas y máquinas
En muchos escenarios, los proyectos de analítica se enfocan en producir reportes exclusivamente y se deja a un lado la necesidad de integración con otras aplicaciones a través de API. En estos casos, son proyectos de reportería que en realidad no crean una capa de datos que soporten las diferentes necesidades organizacionales. Esto causa que, en el futuro, cuando se quiera compartir estos datos a otras aplicaciones, se debe volver a generar un proyecto de datos porque las métricas y los datos de calidad quedaron implementados en herramientas de reportes (Power BI, Tableau, Qlik, etc) que no pueden compartirse a otras aplicaciones. Esto sucede bastante cuando las empresas empiezan abordar proyectos de analítica por primera vez y solo cuentan con algunas herramientas de reportería.
¿Un proyecto de datos o una capacidad
Muchas empresas han abordado la necesidad de gestionar y analizar sus datos como un proyecto, razón por la cual este blog inició con el supuesto de proyectos de datos y analítica. Sin embargo, gestionar los datos para generar valor es una capacidad organizacional que se mantiene en el tiempo y que debe madurar. Por lo cual, si bien se pueden tener proyectos que aborden requerimientos específicos y transiciones en los niveles de madurez en un tiempo definido; la capacidad se debe mantener en el tiempo a través de un equipo de personas dedicado con recursos disponibles y procesos definidos.
Por lo tanto, una organización no puede delegar permanente a consultores externos su capacidad organizacional de gestionar los datos, pues se vuelve insostenible en el mediano plazo. Es importante que las organizaciones cuenten con equipos propios, e incluso pueden contar con consultores que fortalezcan la capacidad, pero sin generar dependencia.
Por lo anterior, de ahora en adelante cuando se aborde el concepto de proyecto de datos, se asume que hace parte del desarrollo y madurez de la capacidad de gestión de datos en la organización y no se limita a un conjunto de actividades y entregables con un tiempo definido.
¿ Como empezar a habilitar esta capacidad organizacional?
A continuación, se muestran las diferentes áreas y roles en cada área que son relevantes para desarrollar la capacidad de datos y analítica. Los datos son responsabilidad del negocio y no del área de TI, quien se encarga de custodiarlos y de asegurar que las condiciones del negocio se cumplan. Por esta razón en los esquemas de gobierno de datos se recomienda tener equipos de trabajo de datos dedicados que no estén dentro del área de TI, aun cuando requieren alinearse constantemente.
Los roles identificados se nombran en inglés para facilitar la analogía con marcos de gobierno, proveedores de servicios y cloud. Estos roles pueden ser asumidos por una o varias personas, así como una misma persona puede tener varios roles y por lo cual es importante saber el rol que ejerce según la actividad que desempeñe.
Equipo de negocio
Equipo propietario de los datos que vela porque estos aporten el valor esperado al negocio.
Sponsor
Financiador y principal interesado en el proyecto. Normalmente se tiene un grupo de sponsors que incluyen perfiles directivos en el área misional y estratégica de la compañía. También puede incluir al CIO y se recomienda incluir al director financiero, con el fin de proyectar los datos como un activo organizacional.
Business Analyst – Analista de negocio
Experto en los procesos y operaciones de la organización, con énfasis en las temáticas asignadas. Con orientación al logro de objetivos basado en indicadores, conocimiento deseado en riesgos, calidad y excelencia operacional. Toda organización ya cuenta con analistas de negocio que analizan el resultado de sus procesos y buscan la mejora continua de los mismos. Por esta razón, todo líder de proceso se considera por defecto un analista de negocio que es el último responsable (accountable) de los datos de su proceso. El líder de proceso puede apoyarse en otros analistas de negocio y custodios de datos sin delegar su responsabilidad.
Data Steward – Custodio de datos
Apoya al analista de negocio y define en detalle las reglas y condiciones que deben tener los datos para asegurar su calidad y seguridad. Este rol es clave para el gobierno de datos y asegura que el negocio se responsabilice de los datos de la organización.
Equipo de datos
Equipo que se encarga de desarrollar la capacidad de análisis y gestión de los datos, alineándose a las necesidades de negocio y considerando los aspectos técnicos involucrados.
Recomendación 3: Conformación del equipo de datos
En muchas ocasiones, sabemos que las organizaciones cuentan con solo una persona o un equipo pequeño que empieza a explorar técnicamente la explotación de los datos, por lo que posteriormente brindaremos un mapa de ruta de las capacidades que se suelen desarrollan dependiendo de los niveles de madurez y la capacidad organizacional.
Para una organización, es clave contar internamente al menos con los roles: Data Lead y Data Analyst. Los otros roles pueden ser provistos o apoyados por consultores o terceros, aunque dependiendo de la misión y retos de la organización, estos roles se pueden volver indispensables internamente. En general, lo ideal es contar con personal propio que mantenga la capacidad y apoyarse con consultores externos para aumentar los niveles de madurez y mejorar los niveles de servicio.
Data Product Owner / Data Lead – Líder de datos
Encargado de definir el mapa de ruta de los servicios de datos. Conoce los dominios de gestión de datos según los marcos de referencia y tiene la visión completa de las necesidades de datos más allá de los escenarios de reportería. Participa en las decisiones de negocio respecto a los datos y eventualmente será el responsable de presentar resultados en el comité de gobierno de datos.
En un nivel de madurez inicial, este rol puede ser asumido por un coordinador o director de un área de negocio o de TI, con el fin de presentar resultados preliminares y lograr financiamiento para fortalecer la capacidad con un equipo dedicado como se ilustra.
Data Analyst – Analista de datos
Analista con mayor orientación a los aspectos técnicos, encargado de definir requerimientos de datos, pruebas, publicación y desarrollo de tareas bussiness intelligence: extracción, modelado, generación de indicadores y construcción de reportes.
Si bien este rol trabaja con los equipos de negocio y especialmente con los analistas de negocio quienes definen y/o priorizan las necesidades, se recomienda que se tengan algunos roles con alta especialidad técnica en la construcción de los servicios de datos que pueda guiar y definir estándares a los demás analistas de datos.
Data Scientist – Científico de datos
Encargado de modelamiento estadístico, modelamiento predictivo o de optimización. Es un rol que debe ser cuidadosamente seleccionado, pues este rol normalmente se contrata para ejecutar actividades principalmente de ingeniero de datos o de analista de datos, perdiendo el valor real de generar hipótesis y modelos de decisión avanzados.
Data Engineer – Ingeniero de datos
Encargado de construir y orquestar flujos de datos, procesos de movimiento, transformación y almacenamiento, modelado e implementación de repositorios o bodegas de datos, generación de modelos lógicos y físicos de datos según necesidad. Ofrece servicios de datos a los analistas de datos.
DataOps Engineer – Ingeniero DataOps
Encargado de la automatización de los diferentes ambientes y operacionalización de los flujos de datos. Este ingeniero normalmente está vinculado con las actividades de un ingeniero de datos, pero en organizaciones más grandes se pueden tener ingenieros DataOps especializados para acelerar el desarrollo de capacidades de datos.
Data Architect – Arquitecto de datos
Encargado de comprender los datos y la información de la organización a través de la guía y apoyo en la generación modelos conceptuales y lógicos de datos. Define arquitecturas de plataformas de datos y apoya al Data Lead en las arquitecturas propias de la gestión y gobierno de datos.
Equipo de TI
Equipo con roles que soportan la operación tecnológica y apoyan la implementación técnica de la plataforma de datos. Estos roles y las interacciones se abordarán en una siguiente entrada ya que requiere detallar más conceptos técnicos de los que se esperan en esta introducción.
Conclusiones
En esta entrada se abordaron conceptos relevantes para desarrollar la capacidad de análisis de datos en una organización, que más adelante nos permitirá comprender por qué surge la necesidad de gobernar y gestionar los datos en un sentido más amplio. Se identificaron algunos elementos clave y se realizaron aclaraciones importantes respecto a los objetivos generales de los proyectos de datos y analítica, así como la descripción de algunos de los roles usuales en estos tipos de proyectos.
Si bien las interacciones entre los roles son más complejas y existen diferentes procesos que habilitan esta comunicación dentro de marcos de gobierno de datos, en esta primera entrada esperábamos brindar una visión general que nos permita entrar en mayor detalle en nuevos escenarios.
Por ejemplo, según los esquemas anteriores, vamos a detallar el escenario de trabajo a través de casos de uso que definen necesidades de inteligencia de negocios con sus respectivos criterios de aceptación. En este escenario, se incluyen componentes adicionales en las fuentes de datos, componentes en la capa de transformación de datos y componentes para ofrecer reportes a usuarios.
Este modelo derivado se presenta a continuación y será abordado con mayor detalle en nuestra siguiente entrada.
En BigView estamos comprometidos con brindar nuestro conocimiento y experiencia a nuestros clientes. Estamos convencidos que nuestro objetivo es guiarlos y apoyarlos en el mejoramiento de sus capacidades en gestión y analítica de datos a través de las mejores prácticas en la industria.