La demora refleja la estructura de la organización

Una decisión lenta puede deberse al reparto del trabajo y la autoridad. Traza los traspasos antes de cambiar el organigrama y mide si reducir cruces ayuda.

organizational decision delay

¿Cuál es la respuesta corta?

A veces, la demora de una decisión está integrada en la forma de organizar el trabajo. Sigue una decisión recurrente desde la solicitud hasta la acción, identifica qué límites aportan un criterio independiente útil y acerca la autoridad rutinaria al equipo que tiene el contexto necesario. Cambiar el organigrama es una hipótesis que se puede probar. Compara el tiempo de decisión y las tasas de error o reversión antes de afirmar que hubo una mejora.

Saber más
En esta página

Un cambio de un solo campo en la vista interna de un pedido puede dejar al descubierto todo un recorrido de decisión. El equipo responsable de la vista conoce el campo, a las personas usuarias y la vía para revertir el cambio. Aun así, la solicitud espera en tres colas distintas porque tres departamentos tienen cada uno una parte de la aplicación. Es un caso ilustrativo, no un informe sobre una empresa.

¿Dónde está el trabajo? La implementación quizá lleve una hora. El recorrido de la decisión puede llevar una semana.

Una conversación sobre la burocracia organizativa plantea algo más preciso que «las reuniones son malas»: la estructura de una organización puede producir la burocracia que después su personal intenta eliminar. Es una afirmación sobre la estructura, no una solución demostrada para todos los equipos lentos. Nos da una pregunta útil: ¿qué tiempo de espera existe por la forma en que se reparte la autoridad?

Traza una decisión, no un organigrama

Elige una clase de decisión recurrente. Puede ser un cambio de esquema, una excepción a la política de soporte o un campo nuevo en una exportación. Empieza cuando alguien ya tiene información suficiente para solicitar un cambio. Termina cuando se acepta o se rechaza. Registra quién se encarga de cada paso, qué necesita decidir y cuándo puede actuar.

La distinción está entre un traspaso y una comprobación. Un traspaso envía una solicitud a otra persona responsable. Una comprobación verifica una restricción real. A menudo aparecen juntos, pero no tienen por qué.

En el cambio ilustrativo de la vista de pedidos, un equipo podría comprobar si el campo expone datos personales. Esa comprobación tiene un motivo. Otro grupo quizá repita el mismo debate sobre prioridades solo porque el equipo de implementación no puede organizar su propia cola. Ese es un límite de autoridad. Elimina la reunión y el límite sigue ahí.

CruceQué pregunta respondeConsérvalo si…
Producto a implementación¿Merece la pena hacer el cambio ahora?El equipo receptor tiene una perspectiva necesaria y distinta sobre las prioridades
Implementación a seguridad¿Cambia el acceso?El cambio cruza un límite de permisos o datos
Implementación a operaciones¿Se puede ejecutar y recuperar el cambio?Quien opera es responsable de una consecuencia real del despliegue o la recuperación
Traspaso entre equipos para informar¿Quién debe saberlo?Estar al tanto cambia una acción; una notificación no tiene que ser un veto

La tabla es un diagnóstico conceptual. No informa de efectos medidos al cambiar una organización concreta. Nuestra guía sobre productividad de equipos trata de herramientas; este diagnóstico pregunta si un traspaso debe existir.

La distancia de una decisión es una medida útil

Un organigrama indica quién reporta a quién. No muestra cuán lejos viaja una decisión antes de que alguien pueda hacerse responsable. La distancia de una decisión es la secuencia de transferencias de contexto, colas y vetos entre un problema y una acción responsable.

  1. Solicitud de cambio
    el problema está identificado
    espera
  2. Cola
    límite de responsabilidad
    reconstruye el contexto
  3. Traspaso de contexto
    hay que explicar el motivo de nuevo
    autoriza
  4. Decisión
    responsable que rinde cuentas
Recorrido conceptual de una decisión Una solicitud ilustrativa pasa por una cola y un traspaso de contexto antes de que un equipo responsable pueda decidir; cada cruce necesita una razón.

La distancia importa porque el contexto se pierde. Cada traspaso obliga a alguien a volver a explicar por qué importa el campo, qué puede salir mal y qué se ha descartado ya. Quien recibe la solicitud puede pedir una especificación más clara. Quien la envía puede redactarla. Ninguna de esas tareas elimina la necesidad de reconstruir la situación.

Por eso suele decepcionar «comunicarnos más». Unas notas mejores pueden hacer funcionar un límite necesario. No pueden convertir un límite innecesario en trabajo útil. Si se explican los mismos datos en tres reuniones, quizá falte un derecho de decisión, no una presentación.

En una sincronización entre una tienda y un sistema de correo electrónico, el coste es concreto. Puede que quien conoce el significado de negocio de «cliente activo» no forme parte del equipo responsable de asignar los campos. Si cada corrección espera una revisión general de la plataforma, la cola de asignaciones sustituye a una responsabilidad compartida. Los equipos pueden necesitar un acuerdo claro: las reglas locales del negocio pertenecen a quien es responsable del flujo; el transporte, la autenticación y la recuperación corresponden al equipo de la plataforma.

Cuándo una aprobación protege el trabajo

«Una aprobación adicional detecta errores». A veces es cierto. La seguridad, el consentimiento, los controles financieros y los cambios en interfaces compartidas pueden tener consecuencias que van más allá del equipo que realiza la solicitud. Eliminar esas comprobaciones para mejorar un gráfico sería imprudente.

La prueba más útil pregunta qué detecta cada cruce. Si una persona revisora encuentra errores de permisos con regularidad, conserva el control y mejora la información que recibe. Si solo le llega una solicitud para estar al tanto y nunca cambia la decisión, sustituye el veto por un registro o un aviso. Si dos equipos son responsables del mismo resultado, resuelve el conflicto de responsabilidad antes de acortar el calendario.

Un experimento acotado puede hacerlo visible. Elige una clase de decisión de bajo riesgo. Nombra al equipo responsable, las restricciones que no puede cruzar, las pruebas que debe conservar y cómo se revierte un error. Compara una muestra pequeña de solicitudes similares antes y después: tiempo total, tiempo de espera, retrabajo y reversiones. Son mediciones que hay que recoger, no cifras que aporte la fuente.

Reorganizar cuesta. La gente aprende funciones nuevas, pierde vías conocidas para pedir ayuda y puede descubrir restricciones que el organigrama anterior ocultaba. Empieza por el recorrido de la decisión. Quizá después convenga cambiar las líneas de responsabilidad, pero ese no debe ser el primer documento.

A veces, el recorrido más corto consiste en conceder el permiso que falta para decidir.

Preguntas frecuentes

¿Cómo puedes saber si la estructura está causando demoras?

Sigue una decisión recurrente concreta por cada responsable, cola y aprobación requerida. Busca límites que añadan espera sin aportar información, control ni responsabilidad. Mide ese recorrido antes y después de cualquier cambio.

¿Deberían pasar todas las decisiones a un solo equipo?

No. Los riesgos compartidos de seguridad, asuntos legales, consentimiento y finanzas pueden justificar una revisión independiente. Traslada la autoridad solo allí donde el equipo tenga el contexto, los permisos y las consecuencias para hacerse cargo de la decisión.

¿Qué debería medir una reorganización?

Para la misma clase de decisión, compara el tiempo total, los traspasos, el retrabajo y las reversiones perjudiciales. Aprobar más rápido con errores más costosos no es una mejora clara.

Solicita acceso anticipado

Escribe tu nombre y dirección de correo de trabajo. Te enviaremos un enlace para confirmar tu solicitud de acceso a Tajo.

Obtener Brevo