Eliminando la diferencia entre analistas de Business Intelligence, analistas de datos o científicos de datos 🚀

Hubo un tiempo en que el analista de datos del equipo era la persona que escuchaba atentamente las hipótesis comerciales de un gerente. Poco tiempo después, el analista de datos inició una emocionante aventura: los datos se buscan en hojas de Excel, se consultan por correo electrónico o se consultan con SQL. El analista de datos se propone encontrar respuestas explorando los datos en busca de señales débiles. Uno por uno, un PowerPoint se llena con gráficos y títulos de acción para orientar decisiones o definir una estrategia comercial. El analista de Business Intelligence, o BI, estuvo a la vanguardia de la digitalización y fue una gran influencia en el impacto de los datos para la toma de decisiones.

Pero los avances tecnológicos rápidamente superaron el papel del analista de datos. Una empresa quiere ir más rápido, más grande y mejor. Los datos y, en consecuencia, la infraestructura de datos están creciendo, al igual que las demandas de habilidades técnicas: DevOps, DataOps, ML Engineer, Data Engineer y Full Stack Data Scientist. Los informes de PowerPoint han sido reemplazados por tableros. El rol del analista de BI se volvió menos definido.

En el peor de los casos, el Business Analyst se convierte en el ciudadano de datos de segunda clase en la empresa. Mientras que en el pasado un analista de BI podía analizar datos en Excel o MySQL y luego crear un informe, ahora es solo la persona que visualiza los datos, soluciona los problemas del tablero e informa al equipo de TI. Las interacciones con las partes interesadas del negocio se vuelven teóricas en lugar de pragmáticas y rápidas. Es el final de la búsqueda rápida e iterativa para encontrar la verdad en los datos. Las canalizaciones se integran en sprints prolongados y bucles de retroalimentación prolongados. Ahora es trabajo de ingenieros y no de Analistas de Negocios “McGyver” autodidactas. El analista de BI queda fuera y el departamento de ingeniería solo y sobrecargado de tareas.

Un síntoma de este cambio son los datos y los tableros mohosos. Mikkel Dengsøe lo resume en su artículo:

• Un tablero tiene definiciones de métricas obsoletas.
• Un tablero solo se carga parcialmente porque un modelo de datos subyacente está roto.
• Los objetivos de KPI se importan de una hoja de cálculo obsoleta.
• Un ejecutivo marcó como favorito un panel que usted creó con prisa el año pasado y todavía lo usa para tomar decisiones.

Necesitamos una nueva comprensión de un analista de BI para volver a las viejas fortalezas. Los analistas de BI deben poder crear canalizaciones, probar métricas y visualizaciones de forma rápida e iterativa a pesar de Modern Data Stack. El analista de BI debe dedicar más tiempo al análisis que a solucionar los problemas del tablero. Necesitamos una capa intermedia...

• ... que conecta datos sin procesar y métricas finales.
• .... que puede ser utilizado fácilmente por los que no codifican.
• ... que se integra con la pila de datos moderna.
• .... que los ingenieros pueden ampliar con las herramientas que les encantan.

Puede que nos conozcas a Matti ya mí. Estamos trabajando mucho con empresas en desafíos basados en datos y tratando de encontrar soluciones rápidas y de código abierto. Acabo de lanzar una herramienta de código abierto con Matti por este mismo motivo que permite a los analistas de BI crear canalizaciones de datos avanzadas directamente a través de una capa de abstracción . Los analistas de BI pueden crear flujos de trabajo a partir de bloques de datos (Fuentes de datos = Airbyte bajo el capó), bloques de transformación (Transformación = dbt) y bloques de ciencia de datos y conectarlos a un tablero. En última instancia, significa que un analista de BI puede iterar rápidamente las métricas y profesionalizarlas de alguna manera (con dbt bajo el capó) para que un ingeniero siempre pueda ampliar la herramienta.

Esto crea una base de código limpia debajo del capó. Por ejemplo, los proyectos DBT se crean y construyen automáticamente. Tenemos la idea de crear una herramienta para el espacio de análisis de datos similar a Webflow para diseñadores web. Un ingeniero experimentado puede personalizar los modelos dbt o crear nuevos modelos y ponerlos a disposición en el lienzo de Kuwala para los no programadores. ¿Mencioné que somos de código abierto? 😅 Sería increíble trabajar contigo en un PR. Si es una empresa, ¡sí, todavía estamos buscando clientes de diseño! ¡No mordemos!

Volver al tema: Esta flexibilidad es necesaria porque los proyectos de datos son individuales, crecen y deben ser personalizables.

Nuestro estado actual del proyecto cubre los siguientes puntos:

• 💯 La configuración de Kuwala ahora es sencilla. ¡Simplemente clone el repositorio y extraiga los acopladores!
• 🗂 Ahora puede conectarse fácilmente a Snowflake, PostGres o BigQuery.
• 🧱 +20 Transformaciones que cubren fusión, agregación y filtros de datos. Debajo del capó, ¡estamos generando modelos limpios de dbt Labs!
• 🛠 ahora también puede agregar fácilmente una nueva transformación usando dbt-core: ¡aquí hay una guía!

¡Puede iniciar fácilmente Kuwala en su máquina local a través de Github, aquí!

Ahora buscamos más personas que lo usen y construyan partes separadas para crecer como comunidad. Estamos listos, ¿y tú? ¡Empieza a hackear! ¡Envíanos tus problemas! ¡Empieza a contribuir! Y si algo no funciona, únete a nuestra comunidad de Slack y te ayudaremos 🚀

También publicado aquí