Una pyme de servicios profesionales de 60 personas armaba sus reportes mensuales en Excel: cada mes, una analista pasaba dos jornadas completas consolidando datos de tres sistemas, copiando-y-pegando entre planillas y formateando un PDF para enviar a gerencia. Cuando nos contactaron buscaban "algo en Power BI", pero lo que realmente necesitaban era responder a una pregunta más simple: ¿qué de todo esto tiene sentido automatizar y qué conviene dejar en Excel? En este artículo contamos cómo fue ese proceso, los 4 KPIs que terminaron en el dashboard, qué dejamos a propósito en Excel, y los aprendizajes que aplicamos en proyectos parecidos. El caso es real con detalles cambiados para preservar la confidencialidad del cliente.
El punto de partida: el "reporte mensual" que comía dos jornadas
El proceso real lo entendimos en la primera reunión. La empresa tenía tres fuentes de datos para sus reportes de gestión:
- Un sistema de gestión interno que exportaba facturación a Excel.
- Una planilla compartida donde los líderes de cada área cargaban horas trabajadas por proyecto.
- Un CRM donde llevaban el pipeline comercial.
Cada mes, la analista descargaba reportes de los tres, los abría en Excel, hacía VLOOKUP para cruzar datos, generaba tablas dinámicas y armaba un PDF con gráficos para gerencia. El trabajo en sí no era complejo — era repetitivo, y eso es lo que importa para decidir qué automatizar.
Los síntomas que se repiten en cada caso parecido al de esta empresa son siempre los mismos:
- Gerencia recibe el reporte tarde (siempre 8-10 días después del cierre del mes).
- Cuando alguien pregunta "¿y cómo veníamos hace 3 meses?", la analista tiene que abrir el Excel viejo y volver a hacer el mismo armado.
- Errores chicos (un VLOOKUP con rango mal seleccionado) generan números equivocados que se detectan dos semanas después.
- Si la analista se enferma o renuncia, nadie más sabe armar el reporte.
Lo que decidimos migrar — y lo que dejamos en Excel
El error clásico cuando una empresa quiere "modernizar reportes" es intentar pasar todo a Power BI de una. Eso suele terminar mal: tres meses de proyecto, un dashboard con 30 visualizaciones que nadie mira, y la analista igual usando Excel para hacer sus análisis de siempre. El criterio que aplicamos fue distinto:
| Tarea | RecurrenteVa a Power BI | ExploratorioQueda en Excel |
|---|---|---|
Reporte mensual a gerencia | Sí | No |
Comparación mes a mes / año a año | Sí | No |
Detección de proyectos con baja rentabilidad | Sí | No |
Forecast trimestral con escenarios "qué pasaría si" | No | Sí |
Análisis ad-hoc cuando gerencia pregunta algo raro | No | Sí |
Presupuesto anual de cada área (planificación) | No | Sí |
Cuadro de horas por proyecto (consulta diaria) | Sí | No |
La regla de decisión es: si la tarea se repite igual cada mes y muchas personas quieren verla, va a Power BI. Si la tarea es una vez y única (cada vez distinta), o si el valor está en la simulación y no en la visualización, Excel sigue siendo la mejor herramienta.
Los 4 KPIs que terminaron en el dashboard
En la primera reunión de definición listamos 11 indicadores que la empresa "quería ver". Después de cuestionar cada uno con la pregunta "si este número cambiara mucho, ¿qué decisión tomarías?", quedaron solo 4. Los demás eran información interesante pero no accionable — y un dashboard lleno de datos que no llevan a acciones es ruido, no señal.
1. Margen por proyecto activo
Para cada proyecto en curso: ingresos facturados menos horas cargadas valoradas al costo interno. Si un proyecto cae bajo cierto umbral, se enciende una alerta visual. Acción asociada: revisar con el líder del proyecto si hay scope creep o problemas de productividad.
2. Pipeline comercial ponderado por etapa
El CRM tenía 7 etapas; agrupamos en 4 y ponderamos cada una con una probabilidad de cierre (basada en el histórico de los últimos 18 meses, no en intuición). Esto le dio a comercial un número realista de qué esperar como ingreso en los próximos 90 días.
3. Utilización del equipo por área
Porcentaje de horas facturables vs horas totales por persona y por área. Acción asociada: redistribuir carga si un área está saturada y otra subutilizada.
4. Ratio de cobranza vs facturación
El número que más sorprendió a la gerencia ver visualizado: la diferencia entre lo facturado y lo cobrado en un período. Permitió detectar que un cliente representaba el 30% de las cuentas a cobrar viejas y disparar acción comercial específica.
Cómo fue el proceso de implementación
El proyecto duró 3 semanas calendario, con esta distribución:
- Semana 1 — Definición. Dos reuniones con gerencia y la analista para entender qué decisiones tomaba con cada reporte. De ahí salieron los 4 KPIs (después de descartar los otros 7). También definimos quién iba a poder ver qué — el dashboard tiene tres roles distintos con vistas diferentes.
- Semana 2 — Modelo de datos. Conectamos Power BI a las tres fuentes (sistema interno, planilla de horas en SharePoint, CRM via API). Limpiamos los datos con Power Query, creamos las medidas DAX, validamos contra el último reporte manual de la analista — los números coincidieron al peso, lo que dio confianza al equipo.
- Semana 3 — Visualización + capacitación. Armamos el dashboard final, lo publicamos en el workspace del cliente, y dimos una sesión de 1 hora a gerencia + la analista para que aprendieran a usar los filtros y el drill-down. La analista pasó a ser la "owner" del dashboard — la persona que ajusta cuando algo cambia en las fuentes.
El resultado, tres meses después
Volvimos a hablar con el cliente a los 90 días post implementación. Estos fueron los cambios concretos:
- La analista pasó de 2 jornadas mensuales a 2 horas semanales (mantenimiento del modelo + revisión de datos raros).
- Gerencia mira el dashboard 2-3 veces por semana en vez de esperar el reporte mensual. La velocidad de reacción a problemas (proyectos con margen bajo, cobranzas atrasadas) bajó de "lo veo a fin de mes" a "lo veo en cuanto pasa".
- Identificaron tres proyectos con margen negativo que no habían notado antes porque solo se veían cuando se acumulaba el reporte trimestral. Acción correctiva inmediata.
- La analista ahora usa Excel para los análisis especiales (presupuesto anual, simulaciones de aumento de tarifas). Esa parte sigue siendo Excel y va a seguir siéndolo, y está bien.
Lo que aprendimos haciendo proyectos como este
Después de implementar dashboards parecidos en varias empresas, estos son los patrones que se repiten:
Primera: el problema casi nunca es Power BI. El problema es que nadie definió qué decisiones se quieren tomar con los datos. Cuando un cliente dice "queremos un dashboard", lo que en realidad necesita es responder mejor a 4-5 preguntas concretas. Esas preguntas son las que definen el dashboard; la herramienta es secundaria.
Segunda: la "automatización completa" suele ser una mala idea. Hay tareas que se ven repetitivas pero en realidad cambian cada vez que se hacen (presupuestos, simulaciones, análisis ad-hoc). Forzarlas en un dashboard rígido es peor que dejarlas en Excel y volver más rápido al analista que sabe.
Tercera: el dueño del dashboard tiene que ser interno. Si el dashboard depende de que el consultor externo lo modifique cada vez que cambia algo, está roto. La capacitación es parte del proyecto — la analista del cliente tiene que poder agregar una columna, cambiar un color, agregar una visualización nueva sin llamarnos. Eso requiere que el equipo interno aprenda Power BI a un nivel razonable.
Cuándo conviene encarar un proyecto así
No todas las empresas necesitan Power BI mañana. Estos son los signos claros de que el momento llegó:
| Síntoma en tu empresa | Indica que es hora de Power BI |
|---|---|
Pasamos +1 jornada por mes consolidando reportes a mano | Sí — ROI claro en 3-6 meses |
El reporte llega 7+ días después del cierre del mes | Sí — Power BI puede actualizarse cada noche |
Más de 3 personas piden el mismo dato cada mes | Sí — un dashboard sirve a todos al mismo tiempo |
Encontramos errores en reportes ya enviados a gerencia | Sí — automatizar elimina los errores de copy-paste |
Solo una persona sabe armar el reporte (knowledge risk) | Sí — el dashboard sobrevive a rotaciones |
Los reportes son distintos cada vez (no hay patrón fijo) | No — quedate con Excel, no es el momento |
No tenemos las fuentes de datos digitalizadas todavía | No — primero digitalizá las fuentes |