En pocas palabras: El trabajo sobre el trabajo es el conjunto de actividades de coordinación —buscar información, compartir estados y decidir quién hace qué— que consumen tiempo sin producir, por sí mismas, el resultado para el que se contrató a esa persona. Según el Asana Work Innovation Lab, los trabajadores del conocimiento dedican más de la mitad de su tiempo a este tipo de actividad.
Considera un escenario ilustrativo, no un caso real de cliente: una directora de operaciones compara dos informes internos en la misma semana. El primero muestra un equipo con la agenda llena todos los días. El segundo revela que las tres entregas estratégicas del trimestre siguen retrasadas. La diferencia entre estar ocupado y avanzar suele esconderse en algo que no aparece en los informes de horas: el trabajo sobre el trabajo.
Este contenido forma parte de Insights de TaskWork, orientado a decisiones prácticas sobre la gestión del trabajo.
Un problema de diseño organizativo, más que un fallo individual
Es tentador tratarlo como una cuestión de disciplina personal: «Si cada persona organizara mejor su agenda, esto no ocurriría». La experiencia en implementaciones de herramientas de gestión del trabajo muestra otro patrón. Cuando personas de distintos equipos describen los mismos síntomas —buscar repetidamente la misma información, esperar aprobaciones sin un responsable claro o rehacer trabajo por falta de criterios—, el problema está en el diseño del flujo, más que en la persona.
Este es el argumento central del artículo: el exceso de trabajo sobre el trabajo es, ante todo, un problema de diseño organizativo, distribución de responsabilidades y estructura del flujo de trabajo, más que un fallo individual de productividad.
Esto no significa que las herramientas sean irrelevantes. Significa que solo resuelven parte del problema, y únicamente después de diseñar el proceso subyacente con intención. Una implementación estructurada sobre un proceso mal diseñado solo digitaliza la confusión; no la resuelve.
Productividad laboral: qué muestran los datos
El Asana Work Innovation Lab encuestó a más de 13.000 trabajadores del conocimiento en Estados Unidos, Reino Unido, Alemania, Japón, Australia y Francia para el informe State of Work Innovation 2024.1 El hallazgo central: el trabajo de coordinación —intercambiar estados, buscar información y comunicarse sobre tareas— consume el 53 % del tiempo de estos profesionales, dejando el 47 % para el trabajo cualificado y estratégico para el que fueron contratados.1
El mismo informe señala que el 94 % de los trabajadores sigue dependiendo de hojas de cálculo para gestionar su trabajo, y el 64 % afirma que las herramientas de colaboración elegidas por su organización dificultan el trabajo en lugar de facilitarlo.1 Además, el 63 % señala que el exceso de herramientas interrumpe su trabajo.1 El informe describe esta búsqueda fragmentada como parte de un «coste de velocidad» asociado a los cuellos de botella de información.2 En una página oficial dedicada a las limitaciones de las hojas de cálculo y los silos de datos, Asana indica que los trabajadores pierden nueve horas semanales buscando la información que necesitan en esos entornos.3
Estas cifras proceden de una muestra internacional patrocinada por la propia Asana, que tiene un interés comercial directo en el tema. Esto no invalida los datos, pero exige dos matices. Primero, no existe una medición pública equivalente, con la misma metodología, específica para el mercado brasileño; las cifras sirven como referencia de una tendencia internacional, no como estadística nacional. Segundo, la organización que financia la investigación también vende la solución presentada como parte de la respuesta, un dato relevante para valorar cuánto peso dar a los resultados.
| Indicador | Valor | Fuente |
|---|---|---|
| Tiempo dedicado al trabajo de coordinación | 53% | Asana Work Innovation Lab, State of Work Innovation 20241 |
| Tiempo dedicado al trabajo cualificado | 47% | Asana Work Innovation Lab, State of Work Innovation 20241 |
| Dependencia de las hojas de cálculo | 94% | Asana Work Innovation Lab, State of Work Innovation 20241 |
| Las herramientas de colaboración dificultan el trabajo | 64% | Asana Work Innovation Lab, State of Work Innovation 20241 |
| Interrupciones por exceso de herramientas | 63% | Asana Work Innovation Lab, State of Work Innovation 20241 |
| Tiempo buscando información en hojas de cálculo y silos | 9 horas por semana | Asana, «Lee esto si todavía gestionas tu trabajo con hojas de cálculo»3 |
Diagnóstico de las tres fugas
El marco siguiente es una elaboración editorial de TaskWork para organizar patrones observados en la implementación y adopción de herramientas de gestión del trabajo. No representa una investigación estadística y no debe confundirse con un estudio académico ni con una metodología del Work Innovation Lab.
Fugas de información
Síntoma: la misma pregunta se repite porque la respuesta no está registrada en un único lugar accesible. Impacto: se pierde tiempo reconstruyendo el contexto y se depende en exceso de personas que «saben dónde está todo». Pregunta de diagnóstico: si la persona responsable se fuera de vacaciones hoy, ¿alguien encontraría el historial sin preguntarle? Acción inicial: identificar dónde está hoy la información crítica de una rutina concreta, no de toda la empresa a la vez. Posible aplicación de una plataforma como Asana: centralizar tareas, comentarios y archivos relacionados en un único espacio de trabajo, reduciendo la fragmentación entre correo, chat y hojas de cálculo paralelas. Limitación de la herramienta: ninguna plataforma resuelve las fugas de información si las personas siguen tomando decisiones y registrando acuerdos fuera de ella, en conversaciones informales sin rastro.
Fugas de decisión
Síntoma: las tareas quedan «pendientes de aprobación», sin plazo visible ni responsable claro de decidir. Impacto: los retrasos en cascada se acumulan a lo largo del flujo, aunque cada etapa se haya ejecutado rápidamente. Pregunta de diagnóstico: antes de preguntar «cuándo estará listo», ¿se puede afirmar con certeza quién toma la decisión final? Acción inicial: enumerar los puntos de decisión de un proceso y asignar un único responsable a cada uno; una persona, no un comité. Posible aplicación: campos de estado y reglas de aprobación visibles para todos, eliminando la ambigüedad sobre dónde está detenida una tarea, una necesidad especialmente habitual en estructuras de PMO y estrategia. Limitación de la herramienta: asignar un campo de «aprobador» en el sistema no sustituye la autoridad formal para decidir dentro de la organización. Si la persona designada no tiene en la práctica esa autoridad, el campo se vuelve decorativo.
Fugas de responsabilidad
Síntoma: entregas inconsistentes porque no existe una definición objetiva y compartida de «esto está terminado». Impacto: retrabajo recurrente y conflictos sobre quién debía detectar el problema antes de la entrega. Pregunta de diagnóstico: ¿existe hoy un criterio objetivo de aceptación para este tipo de entrega o cada persona aplica su propio estándar? Acción inicial: revisar las últimas entregas problemáticas y comprobar si tenían un único responsable identificado y un criterio de aceptación por escrito. Posible aplicación: asignar un responsable único por tarea, junto con campos obligatorios de criterios de aceptación antes de marcarla como completada. Limitación de la herramienta: asignar una tarea en el sistema no crea por sí solo responsabilidad; eso depende de la cultura de gestión y de consecuencias reales por cumplir o incumplir los compromisos.
La conexión entre las tres fugas
Las tres fugas rara vez aparecen aisladas. Una fuga de información alimenta una de decisión porque quien debe decidir no tiene los datos necesarios para hacerlo con confianza. Una fuga de decisión alimenta a su vez una de responsabilidad porque nadie quiere asumir el resultado de una decisión que no fue claramente suya. Esta cadena explica por qué las soluciones aisladas —solo formar al equipo, comprar una herramienta o crear otro informe— rara vez resuelven el problema de forma duradera. Atacan un síntoma mientras la cadena sigue activa en otro punto del flujo.
Señales de alerta en la productividad del equipo
Algunas señales aparecen antes de que el problema se refleje en métricas formales de productividad. Las reuniones de estado que se repiten cada semana sin nuevas decisiones suelen indicar fugas de decisión. Las preguntas recurrentes sobre «dónde está el archivo más actualizado» indican fugas de información. Las discusiones sobre «de quién era la responsabilidad» después de un error indican fugas de responsabilidad ya consolidadas. Ninguna señal aislada es motivo de alarma, pero sí su repetición sistemática en varios equipos.
Lista práctica: diagnóstico de las tres fugas
- ¿Existe un único lugar donde se registra la información crítica de cada rutina?
- ¿Cada punto de decisión tiene un único responsable identificable?
- ¿Hay criterios de aceptación documentados para las entregas más habituales?
- ¿Las últimas tres entregas problemáticas tenían un responsable claro?
- ¿El equipo puede identificar, sin buscarlo, quién aprueba cada tipo de solicitud?
Qué suele fallar al intentar aumentar la productividad
Un patrón habitual es intentar resolver las tres fugas comprando y configurando una herramienta antes de mapear el proceso real. El resultado suele ser una versión digital del caos anterior: las mismas decisiones sin responsable, ahora en un sistema más atractivo. Otro patrón es automatizar demasiado pronto. Automatizar un flujo sin consenso sobre las responsabilidades solo acelera un proceso deficiente y entrega el mismo problema con más rapidez.
Plan de 30 días como ciclo inicial de diagnóstico
El plan siguiente es un ciclo inicial de diagnóstico y ajuste, no una promesa universal de resultados. El tiempo necesario varía según el tamaño del equipo, la complejidad del proceso y la resistencia al cambio, factores que solo pueden evaluarse caso por caso.
Semana 1 — Mapear: documentar el flujo real de un proceso concreto, no de toda la empresa, identificando dónde está la información, quién decide qué y quién es responsable de cada entrega.
Semana 2 — Definir: para cada fuga identificada, asignar un único responsable, criterios de aceptación explícitos y un lugar único donde registrar la información relevante.
Semana 3 — Probar: aplicar las definiciones de la semana 2 con un grupo controlado, con apoyo de prácticas de gestión del cambio, no con toda la organización a la vez. Un piloto fallido a pequeña escala cuesta mucho menos que un despliegue completo fallido.
Semana 4 — Medir: comparar las señales de alerta antes y después del piloto mediante indicadores concretos, no solo impresiones, como el tiempo hasta la aprobación, las preguntas repetidas o la tasa de retrabajo en entregas específicas.
Por qué la medición es la parte más descuidada del ciclo
De las cuatro semanas del plan inicial, la medición suele ser la etapa que más se omite. Tras un piloto de tres semanas, es habitual que el equipo declare «funcionó» o «no funcionó» según una impresión general, sin haber registrado cifras de referencia antes del cambio. Sin una línea de base, es imposible distinguir una mejora sostenida del efecto temporal de la atención adicional durante el piloto. También resulta difícil justificar la ampliación ante quienes financian la iniciativa.
Una medición útil no necesita ser sofisticada. Registrar antes del piloto cuántas veces se repitió una pregunta por semana en un canal, o cuánto tardó en promedio una aprobación concreta, basta para hacer una comparación honesta después. El objetivo no es crear un panel permanente en la primera ronda, sino disponer de una referencia lo bastante sencilla como para mantenerla sin esfuerzo adicional.
Este ciclo puede y debe repetirse. La primera ronda rara vez lo resuelve todo; revela dónde están realmente las fugas y crea una base de evidencia para decidir los próximos pasos. Estos pueden incluir ampliar el piloto, ajustar el proceso antes de volver a intentarlo o reconocer que la causa raíz está en otro nivel de la organización.
El papel de la consultoría en este proceso
Una consultoría especializada en gestión del trabajo no sustituye las decisiones de la dirección sobre cómo distribuir responsabilidades; esa es una decisión de gestión, no de configuración del sistema. Una consultoría como TaskWork aporta valor en tres ámbitos: realizar el diagnóstico con una mirada externa menos condicionada por la política interna; traducir los requisitos del proceso en configuración técnica de una plataforma como Asana; y acompañar el piloto con una metodología explícita, evitando que el entusiasmo inicial se pierda durante las primeras semanas de uso real. Esto presupone que el diagnóstico y el diseño del proceso ocurran antes o, como mínimo, en paralelo a la configuración de la herramienta, no después.
Conclusión ejecutiva
Reducir el trabajo sobre el trabajo es un ejercicio de diseño organizativo apoyado en herramientas, no un proyecto de compra de software. Las empresas que tratan Asana u otra plataforma de gestión del trabajo como un fin en sí mismo suelen digitalizar los mismos cuellos de botella que ya tenían. Las que tratan la herramienta como consecuencia de un proceso bien diseñado suelen conseguir lo que buscaban desde el principio: menos tiempo coordinando el trabajo y más tiempo para el trabajo que importa.
Preguntas frecuentes
¿Qué es exactamente el «trabajo sobre el trabajo»?
Es el conjunto de actividades de coordinación —buscar información, comunicar estados y decidir responsabilidades— que consume tiempo del equipo sin generar directamente el resultado esperado del trabajo.
¿El trabajo sobre el trabajo es lo mismo que el retrabajo?
No exactamente. El retrabajo consiste en repetir algo que se hizo de forma incorrecta o incompleta. El trabajo sobre el trabajo es más amplio: incluye coordinación, búsqueda de información y actualización de estados, aunque no haya que rehacer nada.
¿Comprar una herramienta de gestión del trabajo resuelve el problema?
No por sí sola. La herramienta puede reducir la fricción de coordinación, pero solo funciona bien sobre un proceso con responsabilidades y criterios claros definidos antes de la configuración.
¿Cuánto tiempo se necesita para reducir el trabajo sobre el trabajo en un equipo?
Varía según el tamaño del equipo, la complejidad del proceso y la resistencia al cambio. El plan de 30 días de este artículo es un ciclo inicial de diagnóstico, no una garantía de plazo.
¿Los datos del 53 % y el 47 % se aplican a Brasil?
Los datos proceden de una muestra internacional del Asana Work Innovation Lab, sin un desglose específico de Brasil disponible públicamente. Sirven como referencia de una tendencia, no como estadística nacional.
¿Cuál es la diferencia entre un proceso mal diseñado y una herramienta mal configurada?
Un proceso mal diseñado carece de responsabilidades y criterios claros, independientemente de la herramienta. Una herramienta mal configurada puede reflejar un buen proceso, pero de forma técnicamente inadecuada. Los dos problemas requieren diagnósticos distintos.
¿TaskWork garantiza menos retrabajo después de la implementación?
No. Ninguna consultoría puede garantizar ese resultado, porque depende de factores organizativos, adopción, cultura de gestión y apoyo de la dirección que van más allá de la configuración técnica.
¿Quieres identificar dónde pierde tiempo tu equipo con el trabajo sobre el trabajo? Habla con TaskWork para un diagnóstico inicial de procesos.
Asana Work Innovation Lab. State of Work Innovation 2024, Global Report. 2024. Disponible en: https://assets.asana.biz/m/7247625de89a76e6/original/State-of-Work-Innovation-2024_Global.pdf. Consultado el 1 de agosto de 2026.↩
Asana Work Innovation Lab. State of Work Innovation 2024, Global Report, sección «Information hide-and-go-seek» («Velocity Tax»). 2024. Disponible en: https://assets.asana.biz/m/7247625de89a76e6/original/State-of-Work-Innovation-2024_Global.pdf. Consultado el 1 de agosto de 2026.↩
Asana. Lee esto si todavía gestionas tu trabajo con hojas de cálculo. Publicado el 5 de noviembre de 2025. Disponible en: https://asana.com/pt/resources/asana-versus-spreadsheets. Consultado el 1 de agosto de 2026.↩
