Cómo definir reglas de prioridad para que las solicitudes internas no dependan de la​

En muchas pymes, una solicitud se vuelve urgente porque alguien llama, reenvía un correo o escribe varios mensajes. El equipo administrativo u operativo acaba reaccionando a la presión del momento: un pedido bloqueado compite con una petición sin fecha, y ambas pueden llegar con la misma etiqueta de «urgente». El problema no es solo la acumulación de trabajo, sino la ausencia de una regla compartida para decidir qué debe empezar antes.

La solución no exige comprar otra herramienta ni crear una fórmula compleja. Consiste en acordar criterios observables, hacerlos visibles y asignar a una persona o rol la capacidad de validar las excepciones. Así, la conversación deja de ser «quién lo ha pedido» y pasa a ser «qué operación, compromiso o riesgo queda afectado». En empresas que ya usan ERP, CRM u otras aplicaciones de negocio, esta política puede aplicarse sobre los sistemas existentes. En 2025, el 66 % de las empresas españolasde

El problema aparece cuando todas las peticiones parecen urgentes

Una prioridad operativa no debería expresar una preferencia personal. Debe explicar qué sucede si la tarea se retrasa: si se detiene una operación ya iniciada, si se incumple un compromiso verificable o si aumenta un riesgo concreto. Las clases de servicio de Kanban distinguen, entre otras, el trabajo urgente, el de fecha fija, el estándar y el preventivo. La elección puede basarse en valor, riesgo o coste de retraso, en lugar de en la jerarquía de quien solicita el trabajo. [2]

Por ejemplo hipotético, una responsable comercial pide actualizar una ficha de producto «para hoy», mientras que almacén comunica que un pedido confirmado no puede salir porque falta un dato. La segunda petición puede ser crítica si bloquea una expedición en curso; la primera será estándar o tendrá fecha si existe un compromiso real asociado. La diferencia no está en el cargo de quien la solicita, sino en la evidencia que acompaña a la petición.

Qué información necesita una prioridad que pueda revisarse

Antes de etiquetar una solicitud, conviene exigir cuatro datos: qué se bloquea o qué impacto se prevé; qué fecha o compromiso existe; quién valida la prioridad; y qué evidencia permite revisar la decisión después. Una solicitud que diga solo «lo necesita un cliente» no basta. Debe indicar qué cliente, pedido, entrega, incidencia o dependencia queda afectada.

También es útil separar la fecha solicitada de la fecha comprometida. Que una persona haya enviado una petición tarde no convierte automáticamente el trabajo en crítico. Si se mezcla la urgencia creada por una mala planificación con una incidencia que realmente detiene una operación, el equipo pierde capacidad para responder a las dos. Pedir un motivo concreto reduce discusiones y permite detectar patrones repetidos.

• Impacto: pedido, operación, cliente o equipo afectado.
• Fecha verificable: hito, entrega o compromiso concreto.
• Validador: persona o rol que confirma la clase asignada.

Una política simple de cuatro clases de prioridad

Una política práctica puede usar cuatro clases. Crítica o expedita: una demora causa un impacto alto e inmediato o bloquea trabajo ya iniciado; puede desplazar otras tareas y debe tener un motivo validado. Con fecha comprometida: existe un hito verificable a partir del cual el impacto aumenta de forma relevante. Estándar: es trabajo necesario sin bloqueo ni fecha crítica y se atiende por orden de entrada. Mejora o preventiva: no resuelve una urgencia actual, pero evita fallos, retrabajo o dependencia futura. [2]

Para evitar que la categoría crítica se convierta en un atajo, limite su uso. Puede acordarse, por ejemplo, que cada equipo tenga solo una solicitud crítica activa y que cualquier nueva petición de esta clase la valide un responsable definido. Las tareas con fecha deben planificarse hacia atrás: desde el compromiso hasta el momento en que hay que iniciarlas, teniendo en cuenta el tiempo habitual de resolución. Dentro de cada clase, el orden de entrada es una regla sencilla y defendible.

• Crítica: pedido confirmado bloqueado por un dato erróneo.
• Con fecha: documentación necesaria antes de una entrega pactada.
• Estándar: alta de una referencia interna sin dependencia inmediata.

Cómo implantar las reglas en cuatro semanas

La primera semana, revise entre 30 y 50 solicitudes recientes y clasifíquelas de forma retrospectiva. No se trata de juzgar a quien las pidió, sino de observar cuántas urgencias tenían un impacto inmediato demostrable y cuántas podían haberse planificado. En la segunda semana, redacte definiciones breves, ejemplos propios del área y el rol autorizado para cambiar una prioridad.

Durante la tercera semana, pruebe la política en un único flujo, como incidencias de pedido, altas de producto o solicitudes a administración. En la cuarta, revise los casos dudosos y corrija las definiciones ambiguas. La guía Kanban plantea que el flujo debe hacer explícitas las unidades de trabajo, sus estados, las políticas de circulación y las expectativas de servicio; además, recomienda gestionar activamente los elementos bloqueados y revisar el trabajo con regularidad. [3]

• Semana 1: analizar solicitudes recientes.
• Semana 2: acordar reglas, ejemplos y responsables.
• Semana 3: probar en un flujo acotado.

Mida si las urgencias son excepcionales o un síntoma

No hace falta un cuadro de mando complejo para saber si la política funciona. Empiece con cinco indicadores: porcentaje de solicitudes críticas sobre el total; porcentaje de críticas reclasificadas después; cumplimiento del plazo comprometido por clase; antigüedad de la solicitud más antigua de cada clase; y número de cambios de prioridad una vez iniciado el trabajo. La guía Kanban incluye como métricas básicas el trabajo en curso, el trabajo terminado, la antigüedad de los elementos abiertos y el tiempo de ciclo. [3]

Si el porcentaje de críticas crece de forma sostenida, no conviene responder creando más etiquetas rojas. Puede indicar un problema de planificación, datos incompletos de entrada, capacidad insuficiente o mala coordinación entre áreas. Reserve también una parte acordada de la capacidad para mejoras preventivas: si todo el tiempo se dedica a apagar fuegos, las causas de las incidencias nunca llegan a corregirse. La regla útil no es la más sofisticada, sino la que el equipo entiende, aplica y revisa con datos.

Preguntas frecuentes

¿Quién debe poder cambiar una prioridad?

Lo recomendable es definir un rol concreto, como la persona responsable del flujo o de la operación afectada. Así se evita que cada área cree su propia cola urgente. La decisión debe quedar registrada junto con el motivo y la evidencia.

¿Qué ocurre si dos solicitudes son críticas a la vez?

Hay que compararlas por el impacto inmediato y por el trabajo bloqueado, no por quién reclama más. Si ambas son realmente críticas, el responsable debe decidir cuál se atiende primero y registrar la excepción. Si esta situación se repite, conviene revisar la planificación o la capacidad.

¿Se necesita un programa nuevo para aplicar estas reglas?

No necesariamente. La política puede empezar en el ERP, CRM, gestor de tareas o una hoja controlada que ya use el equipo. Primero se acuerdan las definiciones y el canal de escalado; después, si aporta valor, se automatizan campos, avisos o informes.