Cómo visualizar un proceso de negocio

Cómo funciona

1. Escribe primero la pregunta

   Una frase: ¿qué va a poder responder alguien después de mirar esto? «¿Dónde pasa el tiempo un pedido?» y «¿quién aprueba la liberación de un lote?» producen diagramas distintos, y hacerse la pregunta antes es lo que evita que produzcas los dos y no satisfagas ninguno.

2. Elige la vista más pequeña que la responda

   Las preguntas de secuencia no necesitan carriles. Las de responsabilidad necesitan carriles pero no tiempos. Resiste la tentación de añadir una dimensión porque la herramienta la soporte: cada capa extra cuesta atención del lector que hacía falta para la respuesta.

3. Constrúyelo como filas para que las vistas salgan baratas

   En QueryChart el diagrama es una tabla: pasos, conexiones, formas y dos columnas de carril. Añadir o quitar la dimensión de responsabilidad es editar una columna, no volver a dibujar, y eso es lo que hace que producir una segunda vista sea razonable en lugar de un proyecto.

4. Pon los tiempos en los traspasos

   Cuando la pregunta es de duración, anota los cruces entre carriles en lugar de cada paso. El tiempo de espera entre equipos domina sobre el tiempo de trabajo en casi cualquier proceso de negocio, y poner los números donde están las colas lo hace visible de inmediato.

5. Muestra las excepciones o di que no lo has hecho

   Si estás dibujando a propósito solo el camino feliz —para una presentación de formación, por ejemplo—, etiquétalo como tal. Un diagrama de camino feliz sin etiquetar se acaba usando como si fuera el proceso, normalmente por alguien que está decidiendo una plantilla de personal.

6. Publica un enlace, no cinco exportaciones

   Comparte el diagrama en lugar de pegar una imagen en una presentación. Las imágenes exportadas son el mecanismo por el que cuatro vistas se convierten en cuatro versiones, cada una congelada el día en que alguien la necesitó.

Preguntas frecuentes

¿Cuál es la mejor forma de visualizar un proceso de negocio?

Empieza por la pregunta. Si la respuesta que se necesita es sobre el orden, basta un diagrama de flujo. Si es sobre responsabilidad o traspasos, usa carriles. Si es sobre modos de fallo, dibuja la ruta desafortunada de cada decisión hasta una conclusión real. Si es sobre tiempo, anota los traspasos en lugar de dibujar algo nuevo. La mejor visualización es la más pequeña que responde a la pregunta planteada, construida sobre una fuente de la que puedas sacar otras vistas después.

¿Debería usar BPMN para visualizar un proceso?

Solo si algo aguas abajo lo consume. La precisión de BPMN —eventos tipados, compuertas, flujos de mensaje— vale la pena cuando un motor de workflow o un proyecto de integración va a leer el modelo. Para un diagrama que lee gente, esa precisión es un impuesto: hay que enseñar la notación, y quien no la ha aprendido adivina. La mayoría de procesos de negocio se sirven mejor con carriles, formas simples y decisiones etiquetadas.

¿Cómo hago un diagrama de proceso que la gente use de verdad?

Que quepa en una pantalla, que responda a una sola pregunta y que esté donde ocurre el trabajo y no en una carpeta de documentación. Y después mantenlo al día: el motivo por el que los diagramas de proceso no se usan casi nunca es la comprensión, es que la gente ha aprendido que el diagrama está desactualizado. Un diagrama que se edita cuando cambia el proceso se consulta; uno que era perfecto en marzo, no.

¿Cuánto detalle debe tener la visualización de un proceso?

El suficiente para responder a la pregunta y nada más, con un nivel de detalle uniforme. De quince a veinticinco pasos caben en una pantalla y se sostienen en la cabeza del lector. Cuando de verdad hay más que contar, enlaza un subproceso en lugar de reducir la fuente: un diagrama que hay que ampliar para leerlo ya ha dejado de ser una visualización.