Una presentación de procesos debe ayudar a tomar decisiones. La audiencia necesita ver dónde empieza el trabajo, dónde espera, quién se responsabiliza de cada traspaso y qué evidencia demuestra que una etapa está terminada. Puedes partir de un esquema escrito para crear un primer borrador de diapositivas a partir de texto con Presenti. Después, revisa el mapa con las personas que ejecutan el proceso en la práctica.
Delimita el proceso
Define el evento de inicio, el evento final y quién recibe el resultado. «Del pedido al cobro» suele ser un alcance demasiado amplio para una sola reunión; «del pedido aprobado a la primera factura» ofrece un límite más manejable. Explica qué queda fuera del mapa para que nadie confunda una vista didáctica con un modelo operativo completo.
Elige el detalle adecuado para la audiencia. La dirección necesita etapas y decisiones; los equipos operativos, traspasos, sistemas y rutas de excepción. Utiliza una diapositiva general y unas pocas ampliaciones, en lugar de encoger todas las tareas hasta obtener un diagrama ilegible.
Usa una solicitud para delimitar el mapa
Este ejemplo describe un servicio interno de diseño ficticio. Una persona solicita un banner para una campaña; un coordinador comprueba el encargo; un diseñador prepara la pieza; la persona solicitante la acepta. El proceso empieza cuando llega la solicitud y termina cuando se acepta el archivo final. La planificación de la campaña, la aprobación de las normas de marca y la publicación quedan fuera de estos límites.
La pregunta de la presentación es: «¿Por qué esperan las solicitudes completas antes de que empiece el diseño?». No es: «¿Cómo podemos acelerar todo el trabajo de marketing?». Esa pregunta más concreta determina qué marcas de tiempo y traspasos deben aparecer en las diapositivas. Los registros siguientes se han creado para este tutorial; no son mediciones de Presenti ni de un cliente.
La guía de ASQ sobre diagramas de flujo recomienda definir los límites y recorrer el mapa con las personas que participan en el proceso. Utiliza ese recorrido para corregir el mapa de la situación actual antes de dibujar el proceso futuro que prefieres.
Representa los traspasos y las responsabilidades
Para cada paso, registra el responsable, la entrada, la salida y el siguiente destinatario. Dibuja un traspaso donde cambia la responsabilidad, no solo donde cambia la herramienta. Si dos equipos comparten un paso, distingue a quien decide de quien aporta las evidencias.
Usa verbos coherentes: validar, aprobar, programar, publicar o conciliar. Un sustantivo como «revisión» puede ocultar la acción esperada. Deja los nombres de los sistemas en una etiqueta secundaria para que el proceso siga siendo comprensible aunque cambie la herramienta.
El contenido de un diagrama por carriles, listo para una diapositiva
| Carril | Paso y entrada | Salida / siguiente destinatario | Flecha de excepción |
|---|---|---|---|
| Solicitante | Enviar finalidad, dimensiones, texto y fecha límite. | El registro de la solicitud llega al coordinador. | La información incompleta vuelve a este punto. |
| Coordinador | Validar el encargo y confirmar que está listo. | La solicitud lista para diseñar entra en la cola del diseñador. | Encargo incompleto → solicitante, indicando qué falta. |
| Diseñador | Tomar una solicitud lista y crear el banner. | Enviar una prueba con versión al solicitante. | Texto ambiguo → coordinador para aclararlo. |
| Solicitante | Comparar la prueba con el encargo acordado. | La aceptación del archivo cierra la solicitud. | Corrección dentro del encargo → diseñador; cambio de alcance → coordinador. |
En la diapositiva general, convierte cada fila en un carril y sitúa la cola de solicitudes listas para diseñar entre el coordinador y el diseñador. Etiqueta las dos salidas de «¿Está completo el encargo?» sin depender del color de las flechas. Conviene separar el bucle de corrección: corregir una errata no es lo mismo que pedir otro tamaño de banner cuando el trabajo ya ha empezado.
Muestra las esperas, las correcciones y los controles
Separa el tiempo de espera del tiempo de trabajo. Una cola puede causar la mayor parte del retraso aunque cada tarea se realice con eficiencia. Representa los bucles de corrección y el motivo de volver a una etapa anterior. Así la audiencia dispone de aspectos concretos que mejorar.
Haz visibles los controles sin darles más espacio del necesario. Añade la evidencia que confirma la finalización de un paso de riesgo elevado, como una autorización registrada o una conciliación. El diagrama no demuestra por sí mismo el cumplimiento de las normas; muestra dónde corresponde realizar la comprobación.
Separa el tiempo transcurrido del tiempo de trabajo
En un caso simulado, el encargo completo entra en la cola a las 09:00, el diseño empieza a las 11:00, la prueba se envía a las 11:45 y el solicitante la acepta a las 12:15 del mismo día. Han transcurrido 195 minutos: 120 de espera para el diseño, 45 de producción y 30 hasta la aceptación. Se pueden sumar porque este caso simplificado no incluye trabajo simultáneo ni correcciones.
No etiquetes los 195 minutos como «tiempo de diseño». Del mismo modo, eliminar una cola de 120 minutos no ahorra necesariamente dos horas de trabajo del personal: la espera y el esfuerzo laboral son medidas distintas. En un servicio real, acuerda si el cómputo incluye noches, fines de semana y solicitudes pausadas antes de comparar casos.
| Caso simulado | Listo → inicio del diseño | Producción | Prueba → aceptación | Tiempo total |
|---|---|---|---|---|
| R-01 | 120 min | 45 min | 30 min | 195 min |
| R-02 | 90 min | 60 min | 20 min | 170 min |
| R-03 | 150 min | 40 min | 30 min | 220 min |
El registro de apoyo necesita un identificador de caso, la hora en que queda listo, la hora de inicio del trabajo, la hora de envío de la prueba, la hora de aceptación y el motivo de cualquier excepción. Si un caso vuelve para una corrección, registra ese intervalo por separado en lugar de forzarlo a encajar en el ejemplo sin retornos.
Explica el cuello de botella con datos
Centra el argumento principal en un cuello de botella. Compara el tiempo de ciclo esperado con los casos observados e indica el periodo de medición. Si la muestra es pequeña, dilo. Un intervalo o una nota de incertidumbre es más honesto que una media aparentemente precisa sin contexto.
Presenta después dos cambios viables y las contrapartidas de cada uno. Acelerar un traspaso puede exigir otra regla de aprobación; automatizar puede trasladar trabajo a la gestión de excepciones. Un buen mapa permite debatir estas opciones sin prometer que un único rediseño resolverá todos los problemas.
Qué conclusiones permiten sacar los datos
Un título adecuado sería: «La cola de solicitudes listas es el intervalo más largo en estos tres ejemplos». Los tres casos simulados respaldan esa afirmación. «El diseñador es el cuello de botella» va más allá de lo que demuestran los registros. El retraso podría deberse a la hora de entrada, otras prioridades, falta de capacidad o una marca de tiempo registrada antes de que la solicitud estuviera lista.
Compara dos propuestas. Revisar la cola dos veces al día es fácil de probar, pero puede dejar solicitudes urgentes esperando entre revisiones. Un punto de recepción atendido de forma continua podría responder antes, aunque exige recursos cuya necesidad el equipo aún no ha justificado. Muestra ambas contrapartidas y prueba primero la intervención más ligera; no etiquetes una flecha futura como «instantánea» antes de probarla.
Conserva las medidas de producción y aceptación junto al tiempo de cola. Acortar la espera no supone una mejora si se trabaja con prisas y aumentan las correcciones. El mapa debe mostrar dónde recoger evidencias, no presentar un ahorro previsto como un resultado observado.
Termina con un responsable y una próxima prueba
Cierra con la decisión necesaria, la persona responsable, la prueba mínima útil y la fecha de revisión. Enlaza los datos o el procedimiento de apoyo en el apéndice. La siguiente versión del mapa debe registrar qué cambió y si el cuello de botella se desplazó.
Antes de presentar, pide a una persona del equipo operativo que siga un caso normal y una excepción sin tu ayuda. Si no puede seguir las flechas o discrepa de los responsables indicados, corrige el mapa antes de pedir a la dirección que apruebe un cambio.
La diapositiva final de decisión
Prueba propuesta: para las próximas diez solicitudes completas, el coordinador revisará la cola en dos momentos acordados de cada jornada laboral e indicará quién asume el siguiente paso. Responsable: el coordinador del servicio. Registros: las cuatro marcas de tiempo anteriores, más las correcciones y las excepciones urgentes. Revisión: tras aceptar la décima solicitud, comparar los tiempos de espera con una referencia inicial recogida por separado y con la misma definición del cómputo de tiempo.
Aquí, diez solicitudes constituyen una pequeña prueba operativa, no una muestra validada estadísticamente. Si las nuevas solicitudes difieren mucho en complejidad, sepáralas en vez de atribuir el cambio a la intervención. Una espera menor acompañada de más cambios de alcance indicaría que hay que revisar qué se considera una solicitud lista.
Presenta cuatro vistas: límites, traspasos actuales, datos de tiempos y prueba propuesta. Deja el registro detallado de casos como apoyo a la diapositiva de datos. La dirección tendrá una decisión concreta que tomar y el equipo operativo conservará suficiente detalle para cuestionar el mapa.
Para mostrar qué cambia con el rediseño propuesto, el ejemplo de presentación del antes y el después mantiene límites comparables y distingue un proceso más sencillo de una mejora medida.
