Español

Errores comunes del Business Analyst (y cómo superarlos)

El mes pasado tomé un café con una BA. Catorce meses en el puesto. Aguda, rápida, bien valorada. Me dijo que estaba "ahogada en solicitudes": más de sesenta tickets por trimestre, los fines de semana se fundían con los lunes, sin final a la vista.

Le hice una sola pregunta: nombre una decisión que su trabajo haya cambiado el trimestre pasado.

No pudo. Ni una. Había entregado 47 paneles de control, respondido 312 mensajes de Slack, escrito consultas que harían asentir a un ingeniero senior. Y no podía nombrar una sola decisión que hubiera resultado diferente gracias a su trabajo.

Esa brecha es el núcleo de este artículo. También es la diferencia entre el BA que asciende en el segundo año y el que sigue respondiendo solicitudes ad hoc en el cuarto.

Por qué el segundo año es la bifurcación

La mayoría de los BAs sobreviven el primer año por puro esfuerzo. Aprenden el esquema, memorizan los paneles de control, descubren quién es realmente el responsable de cada cosa. El resultado parece progreso porque todo es nuevo.

El segundo año es diferente. El esquema ya no es nuevo. El resultado parece el mismo que el del primer año (mismas consultas, mismos paneles, mismos hilos de Slack), pero ahora es lo esperado. El esfuerzo deja de traducirse en visibilidad. O se multiplica (su trabajo empieza a eliminar decisiones de la agenda de otras personas) o se estanca (se convierte en una versión más rápida del servicio de asistencia).

La bifurcación ocurre silenciosamente. La mayoría de las personas no se da cuenta de que tomó el camino equivocado hasta la temporada de evaluaciones, cuando su manager dice algo como "estás haciendo un trabajo excelente, pero necesito ver más impacto estratégico". Eso es el manager diciéndole, en el lenguaje más cortés posible, que no puede identificar qué cambió gracias a su trabajo.

Aquí están los siete errores que lo ponen en el camino del estancamiento. Cada uno tiene un síntoma que puede detectar en su propia semana, un número que puede medir y una solución que puede aplicar el lunes.

Error 1: Convertirse en el servicio de asistencia

Síntoma. Sus mensajes directos parecen una cola de tickets. "Pregunta rápida, ¿puedes extraer X?" "Perdona que te moleste, ¿Y incluye Z?" Responde porque responder es rápido y decir no se siente descortés. Luego se pregunta por qué no puede avanzar en el proyecto estratégico.

El número. Según mi experiencia, un BA que se convierte en servicio de asistencia gasta entre 12 y 18 horas semanales en solicitudes ad hoc. Eso es entre un cuarto y un tercio de su semana, cada semana, evaporado en preguntas que tienen en su mayoría las mismas cinco respuestas.

La solución. Deje de responder mensajes individuales. Cree un canal #analytics-help y redirija cada mensaje directo allí con una línea: "Lo publico en #analytics-help para que todos vean la respuesta". En dos semanas verá las mismas cinco preguntas repetirse. Cree un documento de autoservicio o un panel de Looker que las responda, comparta el enlace y observe cómo su cola se reduce.

La parte difícil no es el canal. Es decirle a un VP "esto debería ser autoservicio" sin sonar como si rechazara trabajo. La frase que funciona: "Con gusto extraigo esto una vez. Para que no bloquee sus próximas diez solicitudes, lo añadiré al [panel del equipo] antes del viernes para que pueda consultarlo usted mismo." Respondió la solicitud. También movió el trabajo de "su cola para siempre" a "su cola una vez".

Error 2: Saltarse la aprobación formal de requisitos

Síntoma. Una parte interesada describe lo que quiere en una llamada de 20 minutos. Usted asiente, toma notas, va a construirlo. Dos semanas después lo miran y dicen "ah, pero también necesito que esté desglosado por región" o "espera, esto es mensual. Lo necesitaba semanal." Reconstruye. Están "casi ahí". Reconstruye de nuevo.

El número. Cada reconstrucción cuesta entre 4 y 12 horas. Tres ciclos de reconstrucción en un solo panel de control equivalen a una semana completa de su tiempo, y la parte interesada aún no está segura de confiar en los números.

La solución. Antes de escribir una sola consulta, envíe un documento de requisitos de una página con tres secciones: Decisión (qué acción habilitará este trabajo y quién la toma), Definición (qué cuenta como un "lead", "usuario activo", "abandono de clientes", acordado por escrito) y Listo (cómo se verá cuando se entregue, con un boceto). Obtenga una confirmación por escrito de las tres secciones. Si la parte interesada no va a leer una página, esa es su señal de que la solicitud no es lo suficientemente seria para construirla.

El documento de aprobación formal no es burocracia. Es una función de forzado que convierte "quiero un panel de control" en "quiero decidir X cada lunes y necesito Y para hacerlo". El 90% de la expansión del alcance muere en esa traducción.

Error 3: Construir paneles antes de definir la decisión

Síntoma. Entrega un panel de control. Tiene 14 gráficos, 6 filtros, todo codificado por colores. La parte interesada dice "esto es increíble, gracias". Tres semanas después, cuando verifica, se ha abierto dos veces. Ambas veces por usted.

El número. En la mayoría de las herramientas de BI, el panel de control mediano recibe menos de 5 visitas al mes después del primer mes. Si "al cliente le encantó" no coincide con "el cliente lo usa", el panel no tenía una decisión real adjunta.

La solución. Antes de abrir Tableau o Looker, escriba una oración al inicio de su borrador: "Este panel existe para que [rol] pueda decidir [acción] cada [cadencia]." Si no puede completar los tres espacios en blanco, no tiene un panel de control. Tiene una solicitud vaga para hacer algo.

Ejemplos que pasan la prueba:

  • "Este panel existe para que el VP de Ventas pueda decidir a qué dos regiones asignar headcount este trimestre cada lunes por la mañana."
  • "Este panel existe para que el líder de CS pueda decidir a qué 5 cuentas llamar esta semana cada martes a las 9am."

Ejemplos que no la pasan:

  • "Este panel existe para que el liderazgo tenga visibilidad del funnel."
  • "Este es un panel de rendimiento de marketing."

Si la decisión no está nombrada, el panel se convierte en papel tapiz.

Error 4: Depender demasiado de las exportaciones a Excel

Síntoma. Extrae datos a Excel porque la parte interesada quiere "jugar con ellos". Construye una tabla dinámica. Agrega una búsqueda con vlookup. Envía el archivo por correo. Dos semanas después la parte interesada lo comparte en una reunión y los números son incorrectos, pero lo son de una manera que nadie puede reproducir porque están anidados en una hoja que vive en la carpeta de Descargas de alguien.

El número. Excel como fuente de verdad le cuesta más reputación que horas. Un número incorrecto en una presentación para el directorio y su estatus de "socio de datos" tarda seis meses en reconstruirse.

La solución. Excel está bien para una exploración puntual. No está bien como reporte recurrente. La regla que uso: si ha enviado el mismo archivo de Excel dos veces, la tercera versión tiene que vivir en la herramienta de BI, con el SQL comprometido en algún lugar donde un colega pueda encontrarlo.

Las herramientas de productividad de Rework y la mayoría de las plataformas de BI pueden reemplazar el 80% de las exportaciones recurrentes de Excel con un reporte programado. El 20% restante es análisis genuinamente ad hoc, y ahí es donde Excel gana su lugar. No luche contra Excel. Luche contra Excel como pipeline.

Error 5: Sin control de versiones en SQL y modelos de dbt

Síntoma. Abre su carpeta de consultas y encuentra customer_metrics.sql, customer_metrics_v2.sql, customer_metrics_FINAL.sql, customer_metrics_FINAL_USE_THIS.sql y un perturbador customer_metrics_old_DO_NOT_USE.sql. Ninguno produce los mismos números. No recuerda cuál ejecutó en la presentación para el directorio del trimestre pasado.

El número. El tiempo dedicado a reconciliar "por qué mi número no coincide con el tuyo" fácilmente llega a 3-5 horas al mes. Más si usted es el analista que tiene que defender el número en una reunión de liderazgo.

La solución. Ponga su SQL en git. No importa si es un repositorio privado, un proyecto compartido de dbt o una carpeta sincronizada con una unidad en la nube. Versionela, comprometala y deje de usar los nombres de archivo como control de versiones. Si ya usa dbt, esto es gratuito; solo tiene que dejar de evitarlo con consultas puntuales en la herramienta de BI.

Una configuración mínima viable para un BA en solitario:

ba-queries/
  models/
    revenue/
      monthly_revenue.sql
      arr_by_segment.sql
    customers/
      active_customer_definition.sql
  README.md   # qué significa cada modelo, quién es responsable de cada definición

Comprometa cada cambio. Haga referencia al hash del commit cuando alguien pregunte "¿de dónde vino este número?" Ese hábito por sí solo lo transforma de "el analista" a "el analista que puede defender sus números en una reunión del directorio". Son dos trabajos diferentes y se pagan de forma diferente.

Error 6: Ignorar las revisiones de retirada progresiva

Síntoma. Abre Looker. Cuenta sus paneles. Hay 47. Mantiene activamente 9. Puede nombrar 3 de memoria. Los otros 44 siguen "activos", siguen extrayendo datos cada mañana, siguen apareciendo en el catálogo cuando las partes interesadas buscan.

El número. En los equipos con los que he trabajado, entre el 30% y el 50% de los paneles no se han abierto en 90 días. Siguen costando cómputo, siguen confundiendo a los nuevos empleados, siguen creando momentos de "espera, ¿cuál es el correcto?" en las reuniones.

La solución. Ejecute una revisión trimestral de retirada progresiva. Lleva una tarde. Extraiga un informe de uso de su herramienta de BI, ordene por last_viewed_at y para cualquier cosa con más de 90 días haga una de tres cosas:

  1. Archivar si nadie es responsable.
  2. Promover si es la versión canónica de una métrica recurrente (muévalo a una carpeta "core", bloquee las definiciones).
  3. Fusionar si hay tres cuasi-duplicados que deberían ser uno.

La primera vez que haga esto archivará más de 20 paneles y no pasará nada malo. Ese es el punto. El catálogo queda más limpio, sus consultas se ejecutan más rápido y los nuevos empleados pueden encontrar el panel correcto sin preguntarle a usted.

Error 7: Medir el uso sin medir el impacto en las decisiones

Síntoma. Su manager pregunta cómo va la función de analítica. Usted dice "el panel ejecutivo tuvo 1.200 visitas el mes pasado". Ella asiente y hace una pregunta diferente.

El número. "1.200 visitas" impresiona hasta que pregunta: visitas de quién, que llevan a qué acción, con qué resultado. Si la respuesta es "no lo sé, pero el gráfico sube hacia la derecha", medió la cosa equivocada.

La solución. Cambie su reporte de métricas de uso a métricas de decisión. Para sus cinco paneles más vistos, nombre:

  • La decisión que el panel apoya (Error 3, mismo ejercicio)
  • La cadencia de esa decisión (semanal, mensual, trimestral)
  • Un ejemplo, en el último trimestre, en que el panel cambió la decisión tomada

Este último punto es determinante. Si no puede nombrar un solo ejemplo en que el panel cambió una decisión, el panel es decoración. Si puede nombrar tres o cuatro entre sus cinco principales, ya no es un creador de reportes. Es un analista cuyo trabajo cambió el dinero.

Cuando llegue la temporada de evaluaciones, "el equipo de liderazgo de marketing reasignó $400K de publicidad pagada a orgánico en marzo basándose en el panel de atribución de canal que construí" es una oración que le da una promoción. "1.200 visitas" es una oración que le da un agradecimiento y el mismo título.

El patrón subyacente

Si relee los siete errores, todos comparten una raíz: optimizar los resultados en lugar de las decisiones.

  • Servicio de asistencia = resultados (tickets cerrados)
  • Sin aprobación formal = resultados (construir rápido, construir mal)
  • Paneles antes de decisiones = resultados (gráficos entregados)
  • Exportaciones a Excel = resultados (archivos enviados)
  • Sin control de versiones = resultados (consultas escritas, no comprendidas)
  • Sin retirada progresiva = resultados (catálogo crece, nunca se reduce)
  • Uso sin impacto = resultados (vistas medidas, no valor)

Reencuadre el trabajo. No le pagan por escribir consultas, entregar paneles o cerrar tickets. Le pagan por reducir la latencia de decisiones del negocio. Tome decisiones que antes requerían una reunión y hágalas posibles desde un gráfico. Tome decisiones que antes tardaban una semana y hágalas posibles en un día.

Cada hora de su semana debería mapear a eso. Si no lo hace, es sobrecarga, y la sobrecarga no se multiplica.

Un plan de 30 días para salir del estancamiento

No puede corregir los siete a la vez. Intente esto en su lugar:

Semana 1: Detenga el sangrado. Configure su canal #analytics-help. Mueva cada mensaje directo allí. Escriba una plantilla de una página para la aprobación formal de requisitos. Comprométase a usarla en las próximas dos solicitudes, sin excepciones.

Semana 2: Recupere la confianza. Elija sus tres paneles más vistos. Para cada uno, escriba la oración "este existe para que [rol] decida [acción] cada [cadencia]". Si no puede completarla, programe una conversación de 20 minutos con el responsable para averiguarlo. Actualice la descripción del panel con la oración.

Semana 3: Limpie la casa. Ponga su SQL en un repositorio git, aunque sea privado. Mueva al menos las consultas que alimentan sus tres principales paneles. Ejecute una revisión de retirada progresiva. Liste cada panel que posee, marque cada uno como Archivar / Promover / Fusionar.

Semana 4: Muestre el trabajo. Revise el último trimestre y escriba tres oraciones de "impacto en la decisión". Reales. ("El equipo X reasignó Y basándose en el análisis Z que entregué.") Si no puede escribir tres, eso es diagnóstico. El plan del próximo trimestre es hacer que suceden tres reales.

La auditoría personal del viernes. Cada viernes, antes de cerrar sesión, hágase tres preguntas:

  1. ¿Qué decisión cambió mi trabajo esta semana?
  2. ¿Qué solicitud recibí que debería haber sido autoservicio?
  3. ¿Qué panel debería archivar la semana que viene?

Tres minutos, tres preguntas. Las preguntas no cambian. Sus respuestas, a lo largo de seis meses, sí lo harán.

Cierre

La BA del inicio de este artículo, la que no podía nombrar una decisión que su trabajo hubiera cambiado, no era mala en su trabajo. Era excelente en él. Era excepcional en el trabajo superficial (cerrar el ticket, entregar el panel, responder el mensaje) y estaba bajo el agua en el trabajo real (reducir la latencia de decisiones del negocio).

Los errores de este artículo no son problemas de inteligencia. Son problemas de atención. Uno cae en ellos no porque sea perezoso, sino porque el trabajo superficial se siente productivo en el momento y el trabajo real se siente invisible hasta la temporada de evaluaciones.

Elija un error esta semana. Corrígalo antes del viernes. La promoción no vendrá de hacer más. Vendrá de hacer las cosas que cambian decisiones y de decir que no (cortésmente, por escrito) a todo lo demás.

Aprenda más