Cómo hacer un diagrama de flujo de un SOP
Cómo hacer un diagrama de flujo de un SOP: un procedimiento por diagrama, pasos numerados, decisiones con criterios escritos y una versión aprobada bajo control de cambios. Con un ejemplo de gestión de incidencias.
Un diagrama de flujo SOP es un procedimiento operativo estándar dibujado como flujo: pasos numerados que alguien puede seguir bajo presión, decisiones con criterios escritos y una única versión aprobada.
En resumen
- Un procedimiento por diagrama. Dos puntos de inicio significan dos SOP.
- Los pasos van numerados y son lo bastante cortos para leerlos en voz alta bajo presión.
- Cada decisión indica sus criterios o nombra al rol que decide.
- Las vías de escalado y de reapertura se dibujan, no se dan por supuestas.
- Un SOP solo está controlado si tiene una versión aprobada, un responsable y una fecha de revisión.
Lo que diferencia a un SOP de un mapa de procesos
Un diagrama de flujo SOP se lee en una situación muy distinta a la de un mapa de procesos. El mapa de procesos se lee en una reunión; el SOP se lee a las dos de la madrugada, por alguien que nunca ha gestionado esto antes y necesita saber cuál es el paso siguiente. Esa diferencia condiciona todas las decisiones de diseño: pasos cortos, numerados para poder dictarlos por teléfono, decisiones con los criterios escritos encima y ninguna rama dejada al criterio personal, salvo que quien decide sea un rol con nombre.
Delimítalo a un solo procedimiento. El defecto más frecuente en los diagramas de flujo de SOP es que en realidad son tres procedimientos compartiendo página, y así se vuelven tan largos que la gente deja de abrirlos. Si tu diagrama tiene dos puntos de inicio, o un apartado que solo aplica a un equipo, divídelo. Las referencias cruzadas entre SOP no cuestan nada; un SOP de veinte páginas que nadie abre, sí.
La otra mitad de un SOP es el control. Un procedimiento sin registro de aprobación, sin versión y sin fecha de revisión es una sugerencia, y en un entorno regulado un SOP sin versionar es por sí solo una no conformidad. El ejemplo de abajo es un procedimiento de gestión de incidencias con una rama para incidencias graves, un escalado por incumplimiento de SLA y un bucle de reapertura, además del texto del procedimiento generado a partir de las mismas filas.
Un SOP como diagrama de flujo
Un procedimiento de gestión de incidencias, construido en cuatro etapas. El texto numerado del procedimiento sale de las mismas filas que el diagrama.
Registra antes de diagnosticar
Detectada, registrada con su impacto, clasificada y priorizada. Un SOP empieza en el punto donde está de verdad quien lo lee, y en una incidencia eso es antes de que nadie sepa qué falla: por eso el registro va antes que el diagnóstico.
La bifurcación al valorar la gravedad
«¿Incidencia grave?» parte el procedimiento en dos: declarar, abrir sala de crisis e informar a los interesados, o seguir con el diagnóstico inicial en primer nivel. Los criterios de esa valoración van en la propia decisión, porque se toma con prisa y la toma quien esté de guardia.
Escala por una regla, no por una corazonada
Investigación en nivel 2, una comprobación explícita del objetivo de SLA con su rama de escalado por incumplimiento y, después, restablecer el servicio y confirmarlo con el usuario. Fíjate en la vía de reapertura: una solución sin confirmar vuelve al diagnóstico en lugar de cerrarse con optimismo.
Ciérrala y devuelve lo aprendido al proceso
Notas de resolución y después una decisión sobre si la causa raíz sigue siendo desconocida; si lo está, se abre un registro de problema. Un SOP que termina en «servicio restablecido» pierde justo el resultado que impide que la misma incidencia vuelva a ocurrir.
Cómo funciona
Delimítalo a un único procedimiento
Escribe el disparador en una sola frase: «se detecta o se notifica una incidencia». Si el disparador necesita un «o» que cubre una situación realmente distinta, eso es un segundo SOP. Mantener cada diagrama en un solo procedimiento es lo que lo deja lo bastante corto como para abrirlo en plena urgencia.
Escribe los pasos como instrucciones
Verbo primero, una acción por paso y dirigido a quien lo ejecuta: «Registrar la incidencia con el impacto», no «La incidencia se registra». La formulación pasiva esconde al responsable, y un SOP cuyos pasos no tienen dueño es la razón de que dos personas hagan el mismo paso y una tercera no haga ninguno.
Pon los criterios en las decisiones
«¿Incidencia grave?» necesita una definición al lado: número de usuarios afectados, nivel de servicio, impacto económico, lo que use tu organización. Utiliza el campo de comentarios del paso para la regla. Las decisiones sin criterios se toman de forma distinta por cada persona que lee el diagrama, y entonces la palabra «estándar» no significa nada.
Añade las vías de escalado y de reapertura
Dibuja qué ocurre cuando el SLA está a punto de incumplirse, cuando la solución no aguanta y cuando quien hace esto habitualmente no está disponible. Son precisamente las vías por las que se consulta un SOP. Cada una vuelve al flujo o termina en su propio punto final.
Reparte las calles y recórrelo con el equipo de guardia
Coloca cada paso en la calle del rol que lo ejecuta (mesa de servicio, gestor de incidencias, soporte de nivel 2) y léelo con quienes van a usarlo. Pregúntales dónde dudarían. Cada duda es un paso al que le falta un criterio o al que le falta una división.
Apruébalo, versiónalo y fija una revisión
Pasa el diagrama por el flujo de aprobación para que la versión vigente tenga un revisor y una fecha, y ponle un disparador de revisión: después de cualquier incidencia grave y, como mínimo, una vez al año. En QueryChart la aprobación y el historial de cambios viven junto al diagrama, así que «qué versión estaba vigente en marzo» tiene respuesta.
Errores que debes evitar
Un SOP que en realidad son tres
Dos puntos de inicio, o un apartado que solo aplica a un equipo, significan que el diagrama hay que dividirlo. La longitud es lo que impide que un SOP se abra justo en el momento en que importa.
Juicios sin criterios
«Escala si es grave» no es un procedimiento estándar. Escribe el umbral o nombra al rol que decide: son las dos únicas formas de hacer que la valoración sea repetible.
Sin vías de excepción
El camino feliz ya se lo sabe todo el mundo. Un SOP que omite el incumplimiento de SLA, la reapertura y la ausencia del responsable habitual calla exactamente donde hacía falta.
Sin control de versiones
Sin una versión aprobada y un historial de cambios, nadie puede demostrar qué procedimiento estaba vigente cuando algo salió mal, y en un entorno regulado eso es una no conformidad en sí misma.
Crea tu propio diagrama de flujo SOP
Abre el ejemplo de gestión de incidencias como diagrama propio, o empieza en blanco y escribe tu procedimiento dentro de las filas.
Guías relacionadas
Preguntas frecuentes
¿Cuál es la diferencia entre un SOP y un diagrama de flujo de proceso?
Un SOP es una instrucción controlada para ejecutar una tarea concreta: numerada, con responsable, aprobada, versionada y escrita para quien hace el trabajo. Un diagrama de flujo de proceso es una imagen de cómo circula el trabajo, a menudo entre varios roles, y puede ser descriptivo en lugar de obligatorio. Dibujar un SOP como diagrama de flujo te da las dos cosas (la legibilidad del diagrama con las propiedades de control del procedimiento) siempre que la aprobación y el historial de versiones vayan con él.
¿Un SOP debe ser un diagrama de flujo o un texto?
Las dos cosas, desde una única fuente. El diagrama se sigue más rápido bajo presión y deja a la vista los huecos en las ramificaciones; el texto guarda el detalle que un diagrama no puede sostener, como valores exactos de un campo o advertencias de seguridad. El fallo típico es mantenerlos como dos documentos separados, porque acaban divergiendo. Genera el texto del procedimiento a partir de las mismas filas que el diagrama, para que un cambio en uno sea un cambio en los dos.
¿Cuánto debe ocupar un diagrama de flujo SOP?
Lo justo para caber en una pantalla a un tamaño legible: en la práctica, de quince a veinticinco pasos. Si te pasas, busca una transferencia natural y divídelo en dos procedimientos que se referencien entre sí. Los SOP largos no son más rigurosos; simplemente se abren menos, y un SOP que nadie abre aporta exactamente el mismo control que no tener ninguno.
¿Quién aprueba un SOP?
El propietario del proceso, más quien responde del riesgo que el procedimiento controla: a menudo calidad, compliance o el responsable del servicio. Lo decisivo, en términos de procedimiento, es que la aprobación quede registrada sobre una versión concreta con un nombre y una fecha, para que no haya ambigüedad sobre qué texto estaba vigente en cada momento del pasado. Ese registro es lo que convierte un documento en un documento controlado.
