Diagrama BPMN para la automatización de flujos de trabajo

Modelo y Notación de Procesos de Negocio (BPMN)

es una representación gráfica para especificar procesos de negocio en un modelo de proceso de negocio. Proporciona una forma estándar de modelar los pasos en un proceso de negocio. Este estándar es mantenido por el Object Management Group (OMG). BPMN está diseñado para ser entendido por todas las partes interesadas del negocio, incluidas las personas analistas de negocios que crean y refinan los procesos, los desarrolladores técnicos responsables de implementar los procesos y las personas de negocios que gestionan y supervisan los procesos.

Símbolos BPMN

1. Objetos de flujo:

2. • Eventos: Representar algo que ocurre (inicio, evento intermedio y final). Están representados por círculos.

   • • Evento de inicio: Círculo de línea delgada.

     • Evento intermedio: Un círculo de doble línea.

     • Evento final: Círculo con línea gruesa

   • Actividades: Representar el trabajo que se realiza dentro de un proceso de negocio. Son representados por rectángulos redondeados.

   • • Tarea: Una sola unidad de trabajo.

     • Subproceso: Un conjunto de tareas agrupadas en una sola actividad.

   • Puertas de enlace: Puntos de decisión que pueden dividir y fusionar el flujo del proceso. Están representados por diamantes.

   • • Gateway Exclusivo (XOR): Solo un camino puede ser tomado.

     • Gateway paralelo (Y): Todos los caminos están tomados.

     • Puerta de enlace inclusiva (OR): Se pueden tomar una o más rutas.

3. Conectando objetos:

4. • Flujo de secuencia: Muestra el orden de las actividades. Representado por una línea sólida con una flecha.

   • Flujo de Mensajes: Muestra el flujo de mensajes entre los participantes. Representado por una línea discontinua con una flecha.

   • Asociación: Vincula artefactos con objetos de flujo. Representado por una línea de puntos.

5. Carriles:

6. • Piscina: Representa a los principales participantes en un proceso.

   • Carril: Sub-particiones dentro de un pool para organizar actividades.

7. Artefactos:

8. • Objeto de datos: Muestra los datos requeridos o producidos por las actividades.

   • Grupo: Usado para agrupar diferentes actividades.

   • Anotación: Proporciona información de texto adicional.

Usos

• Mejora de procesos empresariales

• Desarrollo de software

• Cumplimiento y gestión de riesgos

• Capacitación e incorporación

• Gestión de proyectos

• Servicio y soporte al cliente

• Gestión de la cadena de suministro

• Procesos financieros

• Atención de la salud

• Gestión de recursos humanos

Ejemplo: Proceso de aprobación del diseñador de código

Participantes

1. Diseñador de Código: Responsable de crear y revisar el diseño del código.

2. Líder del equipo de desarrollo: Revisa el diseño para su viabilidad técnica y adherencia a los estándares.

3. Equipo de control de calidad: Prueba el diseño para asegurar que cumpla con los estándares de calidad.

4. Gestor de proyectos: Proporciona la aprobación final para el diseño.

5. Diseñador UX: Garantiza que el diseño cumpla con los estándares de experiencia del usuario.

6. Equipo de Seguridad: Revisa el diseño en busca de vulnerabilidades de seguridad.

7. Equipo de Operaciones: Revisa el diseño para la viabilidad de la implementación.

8. Partes interesadas: Proporciona comentarios y aprobación desde una perspectiva empresarial.

Explicación de cómo empezar a crear un diagrama BPMN

1. Evento de inicio: El proceso comienza cuando el Diseñador de Código empieza a trabajar en el diseño. Esto está representado por un círculo en el diagrama BPMN.

2. Crear diseño (Tarea 1): El diseñador de código crea el diseño inicial. Esto está representado por un cuadro de tarea rectangular.

3. Revisar diseño para viabilidad técnica (Tarea 2): El líder del equipo de desarrollo revisa el diseño para verificar su viabilidad técnica, su integridad y la adherencia a los estándares de codificación. A continuación, sigue un punto de decisión (forma de diamante) para determinar si el diseño está aprobado.

4. • Puerta de enlace de decisiones: Si se aprueba el diseño, pasa a la revisión de UX. De lo contrario, se proporcionan comentarios al Diseñador de Código.

5. Revisar diseño (Tarea 3): Si el diseño no es aprobado, el Diseñador de Código lo revisa en base a los comentarios. Esta tarea está representada por otra caja de tarea rectangular y está vinculada de nuevo a la tarea de revisión, formando un bucle.

6. Revisión de diseño para UX (Tarea 4): El diseñador de UX revisa el diseño para asegurarse de que cumpla con los estándares de experiencia del usuario. A continuación, sigue un punto de decisión para determinar si se aprueba el diseño.

7. • Puerta de enlace de decisión: Si se aprueba el diseño, pasa a la revisión de seguridad. Si no, se proporcionan comentarios al Diseñador de Código.

8. Revisar diseño (Tarea 5): Si el diseño no es aprobado, el Diseñador de Código lo revisa basándose en los comentarios del Diseñador UX. Esta tarea está representada por otra caja de tarea rectangular y está vinculada de vuelta a la tarea de revisión UX, formando un bucle.

9. Revisar el diseño para seguridad (Tarea 6): El equipo de seguridad revisa el diseño en busca de posibles vulnerabilidades de seguridad. Sigue una puerta de enlace de decisión para determinar si el diseño está aprobado.

10. • Puerta de Enlace de Decisiones: Si se aprueba el diseño, pasa a la prueba de control de calidad. Si no, se proporcionan comentarios al Diseñador de Código.

11. Revisar diseño (Tarea 7): Si el diseño no está aprobado, el Diseñador de Código lo revisa basado en los comentarios del Equipo de Seguridad. Esta tarea está representada por otro cuadro de tarea rectangular y está vinculada de nuevo a la tarea de revisión de seguridad, formando un bucle.

12. Diseño de Pruebas (Tarea 8): El equipo de control de calidad prueba el diseño para evaluar su funcionalidad, rendimiento y cumplimiento de los estándares de calidad. Un punto de decisión sigue para determinar si el diseño pasa el control de calidad.

13. • Puerta de enlace de decisiones: Si el diseño pasa la QA, pasa a la revisión de operaciones. Si no, los comentarios se proporcionan al Diseñador de Código.

14. Revisar diseño (Tarea 9): Si el diseño no pasa QA, el diseñador de código lo revisa basado en los comentarios del equipo de QA. Esta tarea está representada por otra caja de tareas rectangular y está vinculada de regreso a la tarea de prueba de control de calidad, formando un bucle.

15. Revisar el diseño para la implementación (Tarea 10): El equipo de operaciones revisa el diseño para la viabilidad de la implementación. Sigue una puerta de enlace de decisión para determinar si se aprueba el diseño.

16. • Puerta de enlace de decisiones: Si el diseño se aprueba, pasa a la revisión de las partes interesadas. Si no, se proporcionan comentarios al diseñador de código.

17. Revisar diseño (Tarea 11): Si el diseño no es aprobado, el diseñador de código lo revisa basándose en los comentarios del equipo de operaciones. Esta tarea está representada por otra caja de tarea rectangular y está vinculada de nuevo a la tarea de revisión de operaciones, formando un bucle.

18. Revisión de las partes interesadas (Tarea 12): Las partes interesadas revisan el diseño desde una perspectiva empresarial y proporcionan comentarios finales. Un punto de decisión sigue para determinar si el diseño está aprobado.

19. • Puerta de Enlace de Decisiones: Si el diseño es aprobado, pasa al gestor de proyectos para la aprobación final. Si no, se proporcionan comentarios al Diseñador de Código.

20. Revisar diseño (tarea 13): Si el diseño no es aprobado, el Diseñador de Código lo revisa en base a los comentarios de las partes interesadas. Esta tarea está representada por otro cuadro de tarea rectangular y está vinculada de nuevo a la tarea de revisión de las partes interesadas, formando un bucle.

21. Aprobación final (Tarea 14): El gestor de proyectos proporciona la aprobación final para el diseño. Sigue una puerta de enlace de decisiones para determinar si se aprueba el diseño.

22. • Puerta de Enlace de Decisiones: Si el diseño es aprobado, lo implementa el equipo de desarrollo. Si no, los comentarios se proporcionan al Diseñador de Código.

23. Revisar diseño (Tarea 15): Si el diseño no es aprobado, el diseñador de código lo revisa basado en los comentarios del gestor de proyectos. Esta tarea está representada por otra caja de tarea rectangular y está vinculada de nuevo a la tarea de aprobación final, formando un ciclo.

24. Evento final: El proceso termina cuando el diseño es aprobado por el gerente de proyecto e implementado por el equipo de desarrollo. Esto está representado por un círculo.

Este diagrama BPMN ampliado garantiza un enfoque integral e iterativo para el proceso de aprobación del diseñador de código, involucrando a múltiples partes interesadas y etapas de revisión exhaustivas para asegurar que el diseño cumpla con todos los requisitos técnicos, de experiencia del usuario, de seguridad, de implementación y de negocio.

Buena suerte y deja tus comentarios.

Saludos cordiales

Khawaja Rizwan