Experiencia Datalized: Proyectos con Diagnóstico inicial

Las empresas con las que trabajamos tienen distintos grados de madurez en torno al uso interno de datos. Algunas llevan años en esto y ya tienen varios modelos Machine Learning en producción. Otras están recién partiendo y quizás tienen alguna primera experiencia con algún panel de Power BI.

Nuestro trabajo consiste en realizar recomendaciones (y luego ejecutarlas!) en torno a la arquitectura tecnológica que necesitan para apoyar el uso de datos, a las herramientas analíticas que deberían estar construyendo y a la forma en que el área de datos se relaciona con el resto de la organización. Nuestras recomendaciones varían según el nivel de madurez y de las particularidades de la empresa.

Para poder hacer una recomendación precisa, partimos nuestros proyectos con un periodo de levantamiento. A este periodo le llamamos Diagnóstico. En este artículo te queremos contar cómo fue la experiencia de Lucho y Vicky en uno de estos diagnósticos.

¿En qué consiste un Diagnóstico?

Un diagnóstico suele ser un periodo breve, pero muy relevante, que dura un mes aproximadamente, al inicio del proyecto. El foco de este periodo es entender en detalle el problema de negocio que se quiere solucionar y suele terminar en un plan de trabajo y en una recomendación de arquitectura tecnológica.

En este periodo llevamos a cabo reuniones de levantamiento con áreas técnicas y de negocio, con el propósito de conocer a cada contraparte y su interacción con los datos e información. Esto nos permite no sólo conocer sus roles y responsabilidades, sino también los dolores que enfrentan en su día a día. Acá es donde jugamos un rol fundamental.

Gracias a que somos un partner externo, muchas veces hacemos preguntas y cuestionamientos que, por múltiples razones, se escapan del día a día en la operación. Esto, acompañado de la experiencia que tenemos dentro del equipo, tanto a nivel estratégico como técnico, son las principales herramientas que necesitamos para descomponer el problema y comenzar a diseñar/desarrollar sus soluciones.

También revisamos las fuentes de información que se han identificado como importantes y exploramos los desarrollos en torno a mundo de datos (si es que hubiesen) para tener una idea de dónde están parados. Nos referimos al Datawarehouse, a las herramientas de visualización, a reportes en Excel, etc.

Conclusiones del diagnóstico

Las conclusiones del diagnóstico suelen ser distintas de empresa en empresa, pero nos hemos encontrado con una serie de problemas que suelen repetirse:

• Alta dependencia de Excel para cruce y procesamiento de datos.
• Dificultad para cruzar datos de distintos sistemas transaccionales.
• Áreas de datos saturadas por un alto nivel de requerimientos de las áreas de negocios.
• Diferencias en la definición de KPIs clave para el negocio
• Desconocimiento de las fuentes de información que se incluyen en los reportes.
• etc.

En cada proyecto resolvemos problemas relativamente similares pero en contextos sumamente diferentes. Eso conlleva que cada uno trae sus propios desafíos intelectuales y nos ayuda a mantenernos vigentes. En palabras de nuestro querido Lucho: Esto es lo que nos enamora de la consultoría.

Diferencias en la definición de KPIs clave para el negocio

En esta experiencia, identificamos que el principal problema era el involucramiento del negocio en la definición de KPIs importantes para la organización. Este es un problema muy recurrente en las empresas con las cuales hablamos/trabajamos y su solución guarda relación con definir personas de la organización, a los cuales llamamos Data Champion, que sean los encargados de definir que representa y cómo se calcula un determinado KPI.

Los lineamientos del negocio son sumamente relevantes para que los KPIs se transformen en información fidedigna, relevante y coherente para apoyar en la toma de decisiones.

Después de la definición, es responsabilidad del equipo de datos calcular los KPIs según esta definición de manera correcta. Y para poder calcular estos KPIs de manera correcta, es aconsejable que la data esté centralizada en un repositorio central de información (Datawarehouse). En este caso sugerimos que el Datawarehouse Corporativo tenga cierta estructura que facilite el trabajo de los Data Engineer y Data Analyst para implementar de manera correcta la definición de los KPIs de los Data Champions.

En este sentido proponemos un esquema en donde se centralice la información cruda (en el formato que se encuentra en el origen) y se procese dentro del Datawarehouse para implementar las definiciones del negocio. Así que están disponibles para que cualquier persona de la organización las utilice.

Arquitectura propuesta

Propusimos una arquitectura donde el Datawarehouse almacena información cruda, extraída de los distintos sistemas transaccionales a través de Pentaho Data Integration (Community Edition).

Una vez centralizados los datos, los procesaremos para aplicar todas las lógicas de negocio necesarias, utilizando dbt para que el cálculo de estos KPIs sea transparente y auditable. Así queda la data procesada en el Datawarehouse, lista para ser utilizada para desarrollar herramientas analíticas.

Nota: Tenemos mucho que hablar de dbt. Les recomendamos darle un ojo si no lo conocen: https://www.getdbt.com/

Conclusión

El Diagnóstico es finalmente un periodo que nos permite empatizar con los problemas de negocio y con el contexto de la organización. Así podemos traer nuestra experiencia con otras empresas para proponer un plan de acción a la medida.

Pero como dicen por ahí, todo está en ejecución. De eso hablaremos en otra experiencia.