Talently
Talently
Business Analyst

Business Analyst

Transforma los datos de la organización en inteligencia de negocio que permite a los líderes tomar decisiones estratégicas con visibilidad completa.

Un BI Analyst (Business Intelligence Analyst) diseña, construye y mantiene los sistemas de inteligencia de negocio que proveen a la organización una visión integrada de su rendimiento. Su trabajo abarca desde el modelado de datos en el data warehouse hasta la construcción de dashboards ejecutivos y la definición de las métricas que miden el éxito del negocio. A diferencia del Data Analyst que responde preguntas ad-hoc, el BI Analyst construye infraestructura analítica reutilizable que permite a múltiples equipos acceder a datos confiables de forma autónoma. Trabaja en estrecha colaboración con el equipo de datos, los líderes de negocio y los equipos operacionales.

Power BITableauSQLData ModelingDAXETL

Recluta al mejor Business Analyst aquí

Empieza ahora

Responsabilidades Principales

  • •Diseñar y construir modelos de datos dimensionales en el data warehouse que soporten los requerimientos analíticos de la organización.
  • •Desarrollar y mantener dashboards y reportes en herramientas de BI que permitan a los equipos monitorear sus KPIs de forma autónoma.
  • •Definir y estandarizar las métricas de negocio garantizando que toda la organización usa las mismas definiciones y cálculos.
  • •Colaborar con el equipo de datos para diseñar las transformaciones y los modelos que alimentan las soluciones de BI.
  • •Gestionar el ciclo de vida de los reportes: desde el relevamiento de requerimientos hasta la publicación, el mantenimiento y la capacitación de usuarios.
  • •Garantizar la calidad y la confiabilidad de los datos presentados en los dashboards mediante validaciones automáticas y procesos de reconciliación.

Habilidades Clave

Technical Skills

  • Herramientas de BI y visualización: Power BI con DAX y Power Query, Tableau con cálculos y LOD expressions, o Looker con LookML
  • Modelado dimensional: diseño de esquemas estrella y copo de nieve con tablas de hechos, dimensiones y métricas calculadas
  • SQL avanzado para extracción y transformación de datos desde múltiples fuentes hacia el data warehouse
  • DAX (Data Analysis Expressions) o Tableau Calculated Fields para métricas calculadas complejas en la capa semántica
  • ETL básico y conocimiento de pipelines de datos para entender cómo los datos llegan al warehouse y diagnosticar problemas de calidad
  • Diseño de visualizaciones efectivas: principios de percepción visual, elección del tipo de gráfico correcto y diseño de dashboards jerarquizados

Soft Skills

  • Traducción de requerimientos de negocio a modelos de datos y visualizaciones que respondan exactamente las preguntas correctas
  • Comunicación con líderes de negocio para entender qué decisiones necesitan tomar y diseñar los dashboards en función de esas decisiones
  • Rigor en la definición de métricas para evitar que distintas áreas usen definiciones distintas del mismo KPI generando datos inconsistentes
  • Capacidad de documentar los modelos de datos y las métricas con claridad para que otros puedan usarlos y mantenerlos
  • Gestión de múltiples stakeholders con necesidades distintas sobre el mismo dataset sin crear dashboards duplicados que luego divergen
  • Criterio para simplificar: la mayoría de los dashboards se benefician de mostrar menos métricas con más claridad que más métricas con más complejidad

Casos de uso reales

Contexto

Los dashboards ejecutivos son la herramienta que permite a los líderes de la organización monitorear el estado del negocio y detectar desviaciones de los objetivos sin depender de reportes manuales.

Ejemplos reales

  • Dashboard de CEO con los KPIs financieros, operacionales y de producto integrados en una sola vista
  • Scorecards por área de negocio con semáforos de estado versus objetivos del período
  • Vista de rendimiento comercial con pipeline, conversiones y forecast de cierre
  • Dashboards de operaciones con métricas de eficiencia, capacidad y calidad en tiempo real

Contexto

Un modelo de datos bien diseñado es la base de todas las soluciones de BI. Sin él, los reportes son inconsistentes, difíciles de mantener y lentos de construir.

Ejemplos reales

  • Diseño del modelo estrella para análisis de ventas con dimensiones de tiempo, producto, cliente y canal
  • Modelado de Slowly Changing Dimensions para mantener el historial de cambios en entidades de negocio
  • Construcción de una capa semántica con métricas calculadas reutilizables entre distintos reportes
  • Documentación del modelo de datos con el diccionario de métricas para los equipos de negocio

Contexto

Cuando distintas áreas calculan los mismos KPIs de forma distinta, los debates sobre los números reemplazan a los debates sobre las decisiones. La estandarización de métricas es el prerequisito de una cultura de datos coherente.

Ejemplos reales

  • Definición formal de métricas críticas: revenue, churn, CAC, LTV con la fórmula exacta y las exclusiones documentadas
  • Implementación de una capa semántica centralizada donde todas las métricas se calculan una sola vez
  • Proceso de governance de métricas para que los cambios en las definiciones sean aprobados y comunicados
  • Reconciliación de discrepancias históricas entre reportes de distintas áreas que usaban definiciones distintas

Contexto

Cuando todos los reportes pasan por el equipo de BI, se convierte en un cuello de botella. El self-service analytics empodera a los equipos de negocio para responder sus propias preguntas con datos confiables.

Ejemplos reales

  • Diseño de semantic layers en Looker o Power BI que exponen métricas pre-calculadas sin exponer el SQL subyacente
  • Capacitación de usuarios de negocio en el uso de herramientas de BI con los datasets disponibles
  • Documentación de los datasets y las métricas disponibles para que los usuarios sepan qué pueden explorar
  • Proceso de certificación de reportes que distingue los reportes oficiales de los exploratorios

Contexto

Los datos del negocio viven en múltiples sistemas: ERP, CRM, plataforma de e-commerce, herramientas de marketing. Integrarlos en una vista unificada permite análisis cross-funcionales que ningún sistema individual puede proveer.

Ejemplos reales

  • Integración de datos de ventas del ERP con datos de comportamiento del CRM para análisis de ciclo de vida del cliente
  • Dashboard de marketing unificado que combina datos de Google Ads, Meta, email y SEO en una sola vista
  • Vista 360 del cliente que combina transacciones, comportamiento web, tickets de soporte y NPS
  • Análisis de rentabilidad por producto que combina datos de ventas, costos del ERP y datos de logística

Preguntas básicas

Esquema estrella: tabla de hechos central rodeada de dimensiones desnormalizadas. Más simple de consultar, mejor rendimiento en queries analíticas porque requiere menos JOINs. Esquema copo de nieve: las dimensiones se normalizan en subdimensiones (por ejemplo, la dimensión de producto se divide en producto, categoría y subcategoría como tablas separadas). Ahorra espacio de almacenamiento y reduce la redundancia de datos de dimensión, pero requiere más JOINs y mayor complejidad de queries. En la práctica, el esquema estrella es preferible para la mayoría de los casos de BI porque el rendimiento de query y la simplicidad de uso para el negocio superan el beneficio de normalización del copo de nieve.
Establecer un proceso de reconciliación periódica: comparar las métricas clave del dashboard con las del sistema de referencia (ERP, sistema de facturación) para los mismos períodos y verificar que coinciden dentro de una tolerancia definida. Documentar las diferencias conocidas y su justificación: el dashboard puede excluir devoluciones mientras el ERP las incluye, y esa diferencia debe estar documentada. Automatizar las validaciones donde sea posible con alertas que notifican cuando el dashboard diverge del sistema de referencia más allá del umbral. Publicar la definición exacta de cada métrica junto al dashboard para que los usuarios entiendan qué están viendo.
Comparación entre categorías: gráfico de barras horizontales ordenado de mayor a menor. Evolución en el tiempo de una métrica: línea. Partes de un todo: gráfico de barras apiladas o treemap para muchas categorías, nunca pie chart con más de cinco segmentos. Distribución de valores: histograma o boxplot. Correlación entre dos variables: scatter plot. Tablas para cuando el usuario necesita ver los valores exactos y hacer sus propios cálculos. La regla es elegir el tipo de gráfico que comunica el mensaje con mayor claridad para el usuario específico, no el que parece más sofisticado o el favorito del diseñador.
Una columna calculada se evalúa fila por fila en el momento de la carga del modelo y se almacena en la tabla. Útil para valores que se necesitan en filtros o slicers, o para enriquecer las dimensiones. Una medida calculada se evalúa en el momento de la consulta en el contexto del filtro activo. Útil para métricas agregadas que deben calcularse dinámicamente según los filtros del usuario. Las medidas son más eficientes en memoria porque no almacenan valores precalculados. Para métricas como revenue total, promedio por cliente o tasa de conversión, siempre usar medidas. Las columnas calculadas son apropiadas para clasificaciones fijas como segmentos de cliente o rangos de precio.
No añadir las 15 métricas sin evaluación. Hacer las preguntas correctas primero: ¿cuál es la decisión que necesita tomar con cada métrica? ¿cuáles son las tres más importantes para empezar? Frecuentemente, después de esa conversación, el número de métricas verdaderamente necesarias se reduce a cinco o seis. Si hay más métricas legítimas, evaluar si el dashboard actual es el lugar correcto o si se necesita un dashboard adicional más específico. Un dashboard con 20 métricas produce parálisis por análisis; uno con cinco métricas focalizadas produce acción. Documentar las métricas que se propusieron y no se incluyeron con el razonamiento para futuras referencias.
Las SCD gestionan los cambios en los atributos de las dimensiones a lo largo del tiempo. Tipo 1: sobreescribir el valor anterior sin mantener historial. Útil cuando el historial no tiene valor (corrección de un error tipográfico en el nombre de un cliente). Tipo 2: crear una nueva fila con el nuevo valor y marcar la anterior como inactiva con fechas de validez. Mantiene el historial completo y permite analizar el comportamiento del cliente bajo el segmento que tenía cuando realizó una compra. Tipo 3: añadir una columna adicional para el valor anterior. Mantiene solo el cambio inmediatamente anterior, útil cuando solo interesa comparar con el estado previo. En la mayoría de los casos de BI analítico, el tipo 2 es el más valioso por preservar el historial completo.
No resolver la discrepancia técnicamente antes de resolver la discrepancia de definición con el negocio. Facilitar una reunión con representantes de ambas áreas donde se documenten las dos definiciones con sus fórmulas exactas y sus inclusiones y exclusiones. Evaluar cuál definición es más correcta para el propósito de cada área: pueden ser ambas válidas para propósitos distintos. Si se requiere una definición unificada, trabajar con el negocio para acordarla formalmente. Implementar la definición acordada en la capa semántica centralizada y deprecar los reportes que usaban las definiciones antiguas con un período de transición comunicado. La inconsistencia de métricas es un problema de gobernanza, no solo técnico.
Implementar alertas automáticas que detectan: ausencia de datos para un período esperado, volúmenes significativamente distintos al histórico, valores fuera de rango esperado en métricas clave. Establecer tests de calidad de datos en el pipeline que alimenta el warehouse y que bloquean la actualización del dashboard si los datos no pasan las validaciones. Documentar las dependencias del dashboard con sus fuentes para saber qué puede verse afectado cuando cambia un sistema upstream. Coordinar con el equipo de datos para ser notificado de cambios en los pipelines o en el schema de las fuentes antes de que ocurran, no después.

Preguntas técnicas

Usar la función SAMEPERIODLASTYEAR de DAX que maneja automáticamente la inteligencia de tiempo: Revenue LY = CALCULATE([Revenue], SAMEPERIODLASTYEAR('Calendario'[Fecha])). Requiere tener una tabla de calendario marcada como tabla de fechas en el modelo. Para mayor control, usar DATEADD: Revenue LY = CALCULATE([Revenue], DATEADD('Calendario'[Fecha], -1, YEAR)). La variación YoY se calcula como: YoY % = DIVIDE([Revenue] - [Revenue LY], [Revenue LY]). Envolver en DIVIDE en lugar de dividir directamente gestiona automáticamente la división por cero cuando no hay datos del año anterior.
Una relación muchos a muchos no puede modelarse directamente con una tabla de hechos y dimensiones en un esquema estrella tradicional. Opciones: crear una tabla puente (bridge table) que contiene las combinaciones pedido-promoción como filas individuales, con las métricas de impacto de cada promoción en cada pedido (descuento aplicado, líneas afectadas). Otra opción en Power BI es usar la relación many-to-many nativa con una tabla de hechos de asignaciones. La tabla puente es más explícita y portable entre herramientas. El análisis de efectividad de una promoción agrega los pedidos a través de la tabla puente usando la clave de la promoción.
Diagnosticar con Performance Analyzer de Power BI qué visualizaciones generan las queries más lentas. Revisar el modelo de datos: eliminar columnas innecesarias que no se usan en visualizaciones ni en métricas, reducir la granularidad si el nivel de detalle no es necesario para las preguntas del dashboard. Verificar que las relaciones entre tablas usan columnas de enteros y no de texto para los joins. Revisar las medidas DAX: reemplazar FILTER con CALCULATETABLE cuando sea posible, evitar iteradores como SUMX sobre tablas grandes cuando una medida simple alcanza el mismo resultado. Considerar materializar las métricas más costosas como columnas calculadas si se usan frecuentemente en filtros y no requieren contexto dinámico.
La capa semántica abstrae la complejidad técnica del modelo de datos exponiendo métricas y dimensiones en términos de negocio. En Power BI: un modelo publicado en el servicio con roles de seguridad y métricas DAX precalculadas que los usuarios consumen desde Excel o desde reportes de Power BI sin ver el modelo subyacente. En Looker: LookML que define explores, dimensiones y medidas con joins predefinidos. En dbt: métricas definidas en el schema.yml que se pueden consumir desde herramientas de BI conectadas. La clave del diseño: nombrar todo en términos de negocio (Revenue en lugar de sum_amount_excl_tax), documentar cada métrica con su definición, y ocultar los campos técnicos que no deben usarse directamente.
Definir roles de seguridad en Power BI Desktop con filtros DAX por rol: el rol 'Gerente Regional' filtra la tabla de regiones con [Region] = USERPRINCIPALNAME() si hay una tabla que mapea usuarios a regiones, o con una expresión que compara el campo de región con el valor del atributo del usuario en Azure AD. Publicar el modelo con los roles definidos. En el servicio de Power BI, asignar los usuarios o grupos de Active Directory a cada rol. Los usuarios asignados a un rol ven automáticamente solo los datos que el filtro DAX permite. Para modelos con RLS complejo (un usuario puede tener acceso a múltiples regiones), usar una tabla de mapeo usuario-región y un filtro que verifica si el usuario está en la lista de accesos para cada fila.
El análisis de cohortes requiere calcular, para cada grupo de usuarios definido por su fecha de adquisición, cuántos siguen activos en cada período posterior. En SQL: calcular la cohorte (mes de primer evento) y el período relativo (diferencia en meses entre la fecha de actividad y la fecha de cohorte) para cada evento de usuario activo. En el data warehouse, este cálculo se hace antes de importar al BI. En Power BI, crear medidas DAX que calculan los usuarios activos por cohorte y período usando CALCULATE con filtros de período relativo. La visualización resultado es una matriz con las cohortes en filas, los períodos en columnas, y las tasas de retención como valores, con formato condicional que colorea de verde a rojo según el porcentaje.
Implementar un modelo de gobernanza en capas. Workspace de datos certificados: solo el equipo de BI puede publicar, todos pueden leer. Workspaces departamentales: cada área puede publicar pero con una naming convention y proceso de revisión. Workspaces personales: solo para exploración, sin distribución a otros usuarios. Implementar el proceso de certificación de reportes con criterios claros: validación de métricas, documentación de fuentes, aprobación del data owner. Usar las APIs de Power BI para auditar el inventario de reportes, sus fuentes de datos y su uso real (cuántos usuarios los abren). Los reportes sin uso en los últimos 90 días se archivan o eliminan. La gobernanza sin automatización no escala; las APIs de administración de Power BI son el habilitador técnico del control a escala.
Mapear los requerimientos analíticos nuevos contra el modelo existente: ¿qué dimensiones de análisis (por qué cliente, por qué producto, por qué canal) necesita el nuevo requerimiento? ¿existen esas dimensiones en el modelo? ¿las métricas necesarias se pueden calcular desde las tablas de hechos existentes? Los gaps identificados son de tres tipos: dimensiones faltantes (requieren nueva tabla de dimensión o enriquecer una existente), granularidad insuficiente (la tabla de hechos no tiene el nivel de detalle requerido), o métricas que requieren cruzar hechos de distintas tablas (requieren una nueva tabla de hechos o una vista que combine ambas). Con este análisis, la estimación de esfuerzo de la extensión del modelo es precisa antes de comprometerse con el stakeholder.

Preguntas avanzadas

Arquitectura en capas. Capa de ingesta: pipelines que replican los sistemas de origen al data lake con mínima transformación. Capa de transformación (dbt sobre Snowflake, BigQuery o Redshift): modelos staging que limpian y estandarizan cada fuente, modelos intermedios que combinan entidades de negocio, y modelos mart que exponen los datos listos para BI por dominio de negocio. Capa semántica: métricas certificadas definidas una vez y consumibles desde cualquier herramienta de BI. Capa de presentación: dashboards certificados para casos de uso comunes más la capacidad de self-service para los equipos que quieren explorar. La clave es que cada capa tiene un owner claro y un proceso de governance definido antes de que la organización escale.
Métricas de adopción: usuarios activos por semana, número de reportes consultados, departamentos con usuarios activos. Métricas de calidad: tasa de incidentes de datos reportados por los usuarios, tiempo medio de resolución de discrepancias. Métricas de eficiencia: tiempo del equipo de BI dedicado a reportes ad-hoc versus a mejoras de plataforma (una plataforma madura libera tiempo del equipo). Métricas de impacto de negocio: entrevistar trimestralmente a los líderes sobre decisiones que tomaron usando los dashboards y el valor estimado de esas decisiones. La métrica más difícil pero más valiosa es conectar el uso de los dashboards con mejoras en las métricas de negocio que monitorizan: si el equipo de ventas empezó a usar el dashboard de pipeline y la tasa de cierre mejoró, hay una correlación que vale documentar.
Inventariar todos los reportes existentes con su frecuencia de uso, su audiencia y su criticidad antes de tocar nada. Clasificar en tres categorías: críticos (migration priority 1), usados pero no críticos (priority 2), y reportes que nadie recuerda haber pedido (candidatos a no migrar). Comenzar con los reportes de menor complejidad para desarrollar la metodología y ganar confianza del negocio. Para cada reporte migrado, ejecutar ambas versiones en paralelo durante un período de validación donde el negocio confirma que los números coinciden antes de desactivar el reporte legacy. Comunicar el plan y el timeline a los usuarios con anticipación. No intentar migrar todo a la vez: la migración en fases reduce el riesgo y permite ajustar el proceso con cada lote.
La consolidación financiera multi-entidad es el caso de uso de BI de mayor complejidad. Prerequisitos: una tabla de dimensión de tiempo que soporte múltiples calendarios fiscales simultáneamente con períodos equivalentes entre entidades. Una tabla de tipos de cambio históricos para la conversión de monedas en la fecha de reporte requerida. Un modelo contable unificado que mapea los planes de cuentas de cada subsidiaria al plan de cuentas corporativo. En el warehouse, las transacciones de cada entidad se cargan con su moneda original y con la conversión a la moneda de reporte calculada en el momento de la ingesta. La capa de BI opera siempre en la moneda consolidada. La complejidad de la eliminación de transacciones intercompany debe gestionarse en el warehouse antes de exponer los datos al BI.
Un cambio en el modelo de datos es equivalente a un breaking change en una API: afecta a todos los consumidores. El proceso: documentar el inventario completo de reportes y dashboards con sus dependencias de tablas y campos (las APIs de administración de Power BI y Tableau pueden automatizar parte de esto). Antes de cualquier cambio, ejecutar un análisis de impacto que identifique qué reportes se verán afectados. Comunicar el cambio con anticipación a los owners de los reportes afectados con tiempo suficiente para que actualicen sus reportes antes de que el cambio se aplique en producción. Usar versionado en el warehouse (schema versioning) para que los reportes puedan seguir usando la versión anterior durante la transición. Automatizar los tests de regresión que verifican que los reportes siguen produciendo los mismos valores después del cambio.
En 50 empleados, un BI analyst generalista atiende todas las necesidades. En 500, la especialización es necesaria. Estructura recomendada: un equipo central de BI (3-5 personas) que gestiona la infraestructura de datos, el modelo dimensional, la gobernanza de métricas y los dashboards ejecutivos. BI analysts embebidos en las áreas de negocio principales (comercial, producto, operaciones) que entienden el dominio en profundidad y construyen los reportes específicos de su área usando la infraestructura del equipo central. El equipo central establece los estándares, las herramientas y los procesos. Los analysts embebidos tienen autonomía dentro de esos estándares. Sin esta estructura, el equipo central se convierte en un cuello de botella que no puede atender todas las necesidades; con ella, el self-service se vuelve posible con gobernanza.

Errores comunes en entrevistas

Un dashboard bonito que nadie usa para tomar decisiones es un fracaso de BI, no un éxito. Los entrevistadores de empresas con equipos de BI orientados al impacto preguntan qué decisión cambió el stakeholder después de tener acceso al dashboard. Un BI Analyst que no puede responder esa pregunta está midiendo su trabajo en outputs estéticos, no en outcomes de negocio.
Las métricas de negocio complejas que se calculan en el visual (con DAX o con Tableau calculated fields directamente sobre tablas crudas) producen lógica de negocio dispersa y difícil de mantener. Los entrevistadores técnicos preguntan dónde vive la lógica de cálculo de las métricas críticas y por qué. Un BI Analyst que no puede articular esa distinción producirá modelos difíciles de mantener y métricas inconsistentes.
Cuando distintos departamentos tienen dashboards con métricas del mismo nombre calculadas de forma distinta, la organización pierde la confianza en los datos. Un BI Analyst que construye dashboards en silos sin un proceso de definición y estandarización de métricas está creando el problema que los entrevistadores más maduros identificarán inmediatamente.
Un modelo de datos que funciona bien con un millón de registros puede volverse inutilizable con cien millones. Un BI Analyst que no considera el volumen de datos, la frecuencia de actualización y el rendimiento de las queries al diseñar el modelo producirá soluciones que escalan mal y que requieren rediseño costoso cuando el negocio crece.
Power BI, Tableau y Looker tienen fortalezas y limitaciones distintas. Un candidato que dice que puede usar cualquiera sin poder articular las diferencias fundamentales (modelo semántico de Power BI vs el enfoque de servidor de Tableau vs la capa LookML de Looker) demuestra un conocimiento superficial de las herramientas que usa.
Los datos en producción tienen problemas: duplicados, nulos inesperados, cambios de schema no comunicados. Un BI Analyst que no tiene un proceso de validación de la calidad de los datos que alimentan sus dashboards producirá reportes con errores que los usuarios detectarán antes que el analista, destruyendo la confianza en la plataforma.