Una Tarea es una Actividad que no se divide en un nivel de detalle más fino en términos gráficos (lo que sí ocurre en el caso de un Subproceso). El detalle de la Tarea se modela con una descripción textual.
Una Tarea, como toda Actividad, se representa con un rectángulo de esquinas redondeadas, dibujado con una línea delgada. El tipo de una Tarea se indica colocando una figura (marcador) en su esquina superior izquierda.
Póliza de Seguros (Proceso con Tareas Abstractas)
El Proceso contiene solo Tareas, esto quiere decir que su detalle (es decir, las instrucciónes que debe seguir el Agente) está descrito en términos textuales. Todas las Tareas son Abstractas, es decir, su naturaleza está determinaa por su nombre y su descripción.
Proceso con Tareas Abstractas
Póliza de Seguros (Proceso con Tareas Tipificadas)
En esta versión del Proceso las Tareas tienen tipos que indican su propósito. Por ejemplo, Revisar la solicitud es de tipo Usuario, esto quiere decir que la ejecuta el Agente con el apoyo de una aplicación de SW. La Tarea Solicitar monto de la prima es de tipo Servicio, esto significa que el Agente le pide a un ente externo que determine el monto. Por último, Solicitar monto de la prima es de tipo Envío, esto significa que el Agente envía un mensaje al Solicitante.
Proceso con Tareas tipificadas
Tipos de Tareas
Dentro de BPMN, hay diferentes tipos de Tareas para describir distintos comportamientos. Por ejemplo: enviar un mensaje, solicitar un servicio, o realizar una transacción en un aplicación de SW. El tipo de una Tarea se indica colocando una figura (marcador) en su esquina superior izquierda.
BPMN define 7 tipos de Tareas: Manual, Usuario, Recepción, Envío, Servicio, Regla de Negocio y Script. Además, están las Tareas Abstractas que no tienen un tipo específico.
BPMN puede ser usado con diferentes propósitos, desde la descripción informal de un proceso en una pizarra hasta una descripción detallada para crear una aplicación de SW que dé soporte a un proceso.
Los dos usos principales de BPMN son el Modelado de Procesos y la Ejecución de Procesos. Los distintos tipos de Tareas se usan de manera diferente en ambos casos.
Modelado de Procesos vs Ejecución de Procesos
| Modelado de Procesos | Ejecución de Procesos | |
|---|---|---|
| Propósito | Identificar a quienes participan en un Proceso, describir qué actividades realizan y qué recursos utilizan para el logro de los objetivos organizacionales. | Describir el funcionamiento de una aplicación de SW como un flujo de trabajo (workflow) que será implementado en un BPMS (Business Process Management System). |
| Destinatario | Todos los involucrados en el Negocio. | Desarrolladores de Software. |
| Modelador | Analistas de Negocio. | Desarrolladores de Software. |
| Ciclo de Vida |
Está sujeto a revisiones periódicas como parte de la documentación de un Sistema de Aseguramiento de Calidad, un Proceso de Certificación y/o una Iniciativa de Arquitectura Empresarial.
Normalmente, está incorporado en un documento que describe el Proceso de Negocio (Procedimiento). |
Ciclo de Vida de desarrollo de software. |
Las Tarea Abstracta y Manual solo tienen sentido en el Modelado de Procesos. Por su parte, la Tareas Usuario, Recepción, Envío y Servicio pueden ser usadas tanto en el Modelado de Procesos como en la Ejecución de Procesos. Por último, las Tareas Script y Regla de Negocio solo se usan en la Ejecución de Procesos.
Indicadores de Tipos de Tareas
| Tipo | Marcador | Descripción | Modelado de Procesos | Ejecución de Procesos |
|---|---|---|---|---|
| Abstracta | N/A | Una Tarea Abstracta no tiene un tipo específico. Su naturaleza está definida por su nombre y su descripción. | Sí | No |
| Manual | Una Tarea Manual la realiza una persona sin la ayuda de una aplicación de SW. | Sí | No | |
| Usuario | Una Tarea de Usuario la realiza una persona con la ayuda de una aplicación de SW. | Sí | Sí | |
| Recepción | La Tarea de Recepción espera la llegada de un Mensaje desde otro Participante (otra Piscina). Una vez que ha recibido el Mensaje, la Tarea termina. | Sí | Sí | |
| Envío | La Tarea de Envío entrega un Mensaje a otro Participante (otra Piscina). Una vez que ha enviado el Mensaje, la Tarea termina. | Sí | Sí | |
| Servicio | Una Tarea de Servicio solicita a otro Participante (otra Piscina) que le preste un servicio. La solicitud la realiza enviándole un Mensaje, y se queda a la espera de un Mensaje con la respuesta. | Sí | Sí | |
| Regla de Negocio | Una Tarea Regla de Negocio se comunica con un Motor de Reglas de Negocios. Le entrega al Motor los datos para que éste ejecute la Regla de Negocio y recibe los resultados. | No | Sí | |
| Script | Una Tarea Script es una actividad automatizada que es ejecutada por un BPMS. | No | Sí |
Tarea Abstracta
|
Una Tarea Abstracta no tiene un tipo específico, su naturaleza está definida por su nombre y su descripción. Como toda Actividad, es un rectángulo con esquinas redondeadas, dibujado con una línea delgada. Puesto que no tiene un tipo específico, no tiene ninguna figura en la esquina superior izquierda. |
|
Crear Producto (Proceso con Tareas Abstractas)
Proceso con Tareas Abstractas
En el Modelado de Procesos, las Tareas Abstractas son usadas para crear diagramas más simples, que no se complican con la tipificación de las Tareas. De hecho, las Tareas Abstractas son multipropósito, es decir, pueden realizar acciones propias de Tareas especializadas (como el envío de mensajes o la solicitud de servicios), lo que ocurre es que no queda reflejado en la figura de la Tarea.
En la Ejecución de Procesos, la Tarea Abstracta no tiene uso práctico: termina de inmediato al ser activada. Según la Especificación de BPMN: "This is a conceptual model only; an Abstract Task is never actually executed by an IT system" (BPMN 2.0, p. 430).
Tareas Manual y Usuario
|
Una Tarea Manual la realiza una persona sin la ayuda de una aplicación de SW. Como toda Actividad, es un rectángulo de esquinas redondeadas y línea delgada. Tiene la figura de una mano en la esquina superior izquierda. |
|
|
Una Tarea de Usuario la realiza una persona con la ayuda de una aplicación de SW. Como toda Actividad, es un rectángulo de esquinas redondeadas y línea delgada. Tiene la figura del torso de una persona en la esquina superior izquierda. |
|
En muchos procesos se necesita la participación de personas para completar algunas Tareas. En BPMN hay dos tipos de Tareas que siempre son ejecutadas por personas: Manual y Usuario.
Ejecución de Orden de Trabajo
El Proceso de Negocio incluye dos Participantes: el Cliente y la empresa Comunicaciones. Las Actividades dentro de la empresa de Comunicaciones las realiza una persona que cumple el Rol de Técnico.
- El Cliente se comunica con una central de atención cuando tiene un problema. Un operador recibe el reclamo y crea una Orden de Trabajo (OT) en el sistema.
- Los Técnicos en terreno acceden a una aplicación donde aparecen sus tareas pendientes, entre las que están las nuevas OT.
- El Técnico toman la OT más cercana al lugar donde están en ese momento, y se traslada al domicilio del Cliente.
- El Técnico se presenta con el Cliente, le explica quién es y el propósito de su visita. El Cliente permite el ingreso al domicilio.
- El Técnico realiza la reparación en sí y, una vez terminada la reparación, le explica al Cliente lo realizado.
- El Técnico registra en el sistema el inicio y cierre la reparación, en ambos casos solicita la autorización del Cliente por medio de su firma (en el dispositivo móvil del Técnico).
La comunicación del Cliente con la central de atención y la creación de la OT ocurren en una etapa previa. El diagrama muestra lo que ocurre desde el momento en que el Técnico escoge una OT.
Proceso con Tareas Manuales y Usuario - Modelado de Procesos (i)
Es relativamente fácil identificar las Tareas Usuario, pues son los puntos donde se usa TI. Las Tareas Revisar y aceptar OT, Registrar inicio de reparación y Cerrar OT indican cuándo el Técnico debe ingresar los datos que registran lo acontecido, en términos administrativos, con la OT.
En el caso de las Tareas Manuales, el principal criterio para identificarlas es la importancia que le otorga la organización dueña del proceso. Lo que, a su vez, está determinado por las políticas, normas y estándares que deben cumplirse.
Por ejemplo, Contactar a cliente es una Tarea porque la organización quiere que el Técnico haga una serie de acciones siguiendo unas pautas claras. Habrá un instructivo para esta interacción y los Técnicos tendrán actividades de capacitación para que logren los conocimientos y habilidades requeridos. Si, por otro lado, la organización no lo ve como algo separado y controlado, entonces el contacto con el cliente (saludo y presentación) puede incluirse como la primera acción de la Tarea Registrar inicio de reparación Usuario.
Algo parecido ocurre con Explicar reparación que, en el ejemplo, es una Tarea aparte, y no solo la última acción de Reparar conexión: “El Técnico explica al Cliente lo realizado”.
En el ejemplo, la organización considera que Trasladarse a destino es un Tarea diferenciada, y que es Manual porque no hay uso oficial de TI. Sería de tipo Usuario si los Técnicos tuviesen acceso a una aplicación de enrutamiento provista por la organización. Otra organización podría considerar que el traslado ni siquiera es digno de mención, o —en el otro extremo— proveer vehículos con conducción autónoma.
Inscripción de Asignaturas
El Proceso de Negocio incluye tres Participantes: el Alumno, Profesor y la Facultad universitaria. Las Actividades dentro de la Facultad las realiza una persona que cumple el Rol de Tutor.
- Al comienzo de cada semestre la Universidad ofrece una serie de asignaturas.
- Cada Alumno tiene un Tutor asignado.
- Cada Alumno revisa las asignaturas ofrecidos y decide cuáles inscribirá, considerando las restricciones reglamentarias (número de créditos, prerrequisitos, etc.).
- El Alumno realiza la inscripción de asignaturas en el sistema. Si la inscripción cumple con las restricciones, la autorización es automática. En caso contrario, la inscripción pasa al Tutor para revisión y autorización.
- El Tutor analiza el caso y, si lo considera necesario, se contacta con el Alumno y consulta a Profesores.
- El Tutor realiza cambios en la inscripción, si lo considera necesario, y la autoriza.
- El Alumno recibe la inscripción y la confirma.
- El Alumno podría no estar de acuerdo con las modificaciones y apelar.
- El Alumno puede realizar varias inscripciones y renuncias de asignaturas durante el período habilitado. En cada ocasión el conjunto total de asignaturas debe cumplir con el reglamento o pasar por la revisión del Tutor.
La oferta de asignaturas se hace en una etapa previa. El diagrama muestra los casos más comunes: la inscripción de asignaturas cumple las restricciones y la autorización es automática; o no las cumple y pasa a revisión y el Alumno acepta lo decidido por el Tutor.
Proceso con Tareas Manuales y Usuario - Modelado de Procesos (ii)
Un Proceso de Negocio involucra una entidad de negocio (banco, universidad, hospital, etc.) que presta un servicio o genera un producto para un cliente (cliente del banco, alumno, paciente, etc.). Puesto que el modelado del Proceso de Negocio es hecho por y para la entidad de negocio, lo normal es que los detalles de las actividades del cliente no sean relevantes para el diseño y la documentación del Proceso de Negocio. (Además, la entidad de negocio no tiene injerencia ni control sobre lo que hace o no hace el cliente). Por este motivo, el cliente es representado por una Piscina "caja negra" como en Ejecución de Orden de Trabajo.
En algunos casos, como en Inscripción de Asignaturas, el quehacer del cliente (en este caso el Alumno) es relevante para el diseño y la documentación del Proceso de Negocio. Esto ocurre porque el cliente hace uso de de los sistemas de la entidad de negocio de manera activa: realiza transacciones completas (incribe asignaturas, transfiere dinero, etc.), y no solo envía solicitudes y recibe respuestas. Además, el Alumno es un "cliente especial", en el sentido que su relación con la entidad que "le provee servicios" (la Universidad) es más profunda que la de un cliente con un banco, o la de un comprador con un supermercado. De hecho, la Universidad sí tiene injerencia —a través de normas y reglamentos— en lo que el alumno hace en el marco de los Procesos de Negocio.
La Tarea Revisar y autorizar es de tipo Usuario porque el Tutor debe registrar en el sistema la autorización, pero también incluye una serie de acciones "manuales": estudiar el caso, contactar al Alumno y consultar con Profesores. Se optó por colapsar todas estas acciones en una sola Tarea porque es el Tutor quien decide si las hace o no, y en qué orden. Usando el mismo criterio, se podría haber incluido en Inscribir asignaturas la acción de estudiar la oferta académica. Se tomó la decisión (de diseño) de dejarla como una Tarea Manual previa para resaltar que el Alumno debe hacer una selección informada de las asignaturas que inscribirá.
Tareas Manual y Usuario en el Modelado de Procesos
Hoy en día, la mayoría de las Tareas en un ambiente laboral usan alguna forma de tecnología de información (TI): desde una sofisticada aplicación de inteligencia artificial (IA) hasta una calculadora en un dispositivo móvil. ¿Significa esto que casi no hay Tareas Manuales? La respuesta hay que buscarla en la relevancia que tiene la TI en el realización de la Tarea.
Las personas acceden a la TI a través de aplicaciones de sw, las que puede ser o no controladas por la organización dueña del proceso:
- La persona es usuario de un aplicación de SW controlada por la organización dueña del proceso. Por ejemplo, un bodeguero que usa el Sistema de Reposiciones para registrar la recepción de un producto, o el cliente que usa el Portal Web del banco para realizar una transferencia de fondos.
- La persona es usuario de un aplicación de SW externa a la organización dueña del proceso. Por ejemplo, un contador —debidamente autorizado— que accede al Portal Web de un banco para administrar una cuenta bancaria institucional, o un conductor de una empresa de transportes que accede a una aplicación de SW para elegir y seguir rutas dentro de una ciudad.
Normalmente, las aplicaciones utilizadas en los Procesos son de tipo administrativo, es decir, aquellas que manejan información de personas, bienes y transacciones, donde los usuarios acceden a través de formularios. Pero también pueden ser aplicaciones con interfaces más sofisticadas: voz, movimiento…
Para que la Tarea sea considerada de tipo Usuario debe cumplir dos criterios:
- La organización dueña del proceso provee los mecanismos para acceder a la TI.
- La TI es indispensable para realizar la Tarea.
Si se cumplen estos criterios, entonces la organización dueña del proceso debe exigir que las personas utilicen la TI. (Nótese que si la TI es indispensable para realizar la Tarea y la organización no provee los mecanismos para acceder a ella, entonces el proceso está mal diseñado).
En el caso de las aplicaciones de tipo administrativo (controladas o no por la organización) se cumplen ambos criterios: la organización entrega las credenciales para acceder a la TI (porque es dueña de ellas, o porque las negocia o las compra) y —por definición— es indispensable usarla para que los datos queden correctamente registrados en las bases de datos.
Si la organización considera que la TI no es indispensable y no provee acceso a ella, entonces el uso de la TI queda a criterio del ejecutante y la Tarea será Manual. Por ejemplo, si una empresa de transporte no provee acceso a una aplicación de enrutamiento (es decir, no contrata un plan para la aplicación y da acceso a ella a los conductores), entonces la Tarea será de tipo Manual. Quedará a criterio de cada conductor acceder o no a una aplicación de enrutamiento cualquiera. Pero si la empresa provee acceso oficial y exige su uso, entonces la Tarea será de tipo Usuario.
La organización puede proveer acceso a TI de uso general (procesador de texto, planilla electrónica, visualizador de documentos, videoconferencia, etc.) para ser usada a discreción de las personas en Tareas Manuales. Por ejemplo, un técnico puede revisar un manual de operaciones (en formato pdf) en un dispositivo móvil mientras realiza una reparación, o un grupo de personas puede realizar una reunión presencial o por videoconferencia, según sean las circunstancias.
También puede ocurrir que TI de propósito general sea indispensable en un determinada Tarea. Por ejemplo, una Tarea que involucra un análisis complejo de un conjunto de datos puede exigir el uso de una planilla electrónica. La Tarea será, por lo tanto, de tipo Usuario.
Mientras la persona utiliza la TI también realiza "acciones manuales". Por ejemplo, cuando un supervisor revisa y autoriza un documento no solo interactúa con la pantalla (ingresando datos y oprimiendo botones), sino que también analiza el documento, toma decisiones y —si es necesario— consulta a terceros. Es decir,
Tareas Manual y Usuario en la Ejecución de Procesos
En la Ejecución de Procesos, la Tarea Manual no tiene uso práctico. Un BPMS no realiza el seguimiento del inicio ni término de estas Tareas. Según la Especificación de BPMN: "This is a conceptual model only; a Manual Task is never actually executed by an IT system" (BPMN 2.0, p. 430).
En la Ejecución de Procesos, la típica Tarea Usuario consiste en que la persona selecciona una Tarea de una lista de pendientes (de los varios Procesos en los que participa), luego el sistema le presenta un formulario donde debe ingresar datos y realizar acciones. Por ejemplo, un ejecutivo preaprueba un crédito que requiere la revisión de su supervisor, en la lista de pendientes del supervisor aparecerá como "una Tarea pendiente" la revisión de la solicitud de crédito. Al seleccionar la Tarea, al supervisor se le presenta un formulario donde debe llenar algunos datos y registrar su decisión: aprobar, rechazar o devolver (al ejecutivo) la solicitud.
En la Ejecución de Procesos solo importa lo técnico-informático: datos, interfaz de usuario, usabilidad, etc. A diferencia del Modelado de Procesos, donde lo importante es la información, la interacción entre personas, criterios de decisión, etc. Por ejemplo, en la Ejecución de Procesos, hay que preocuparse de que el supervisor tenga a la vista todos los datos de la solicitud de crédito, que el formulario esté bien diseñado y que tenga todas las opciones (botones y similares) para realizar las acciones. Por otro lado, en el Modelado de Procesos, lo relevante es definir: criterios para tomar la decisión, información que se necesita, políticas y estándares que hay que cumplir, entre otros.
La asignación de las Tareas las realiza un Gestor de Tareas, que es parte de un BPMS (Business Process Management System). El BPMS gestiona varios Procesos. A medida que los Procesos van progresando, el BPMS determina qué Tareas hay que realizar y quién debe realizarla, de este modo el Gestor de Tareas va creando las listas de "pendientes" para cada usuario. En algunos casos, el usuario que puede realizar la Tarea es único (p. ej., el supervisor específico de un determinado ejecutivo); en otros casos, varios usuarios potenciales pueden tomar la Tarea (p. ej., realizar un viaje en un servicio tipo Uber).
Ejecución de Orden de Trabajo (Ejecución de Procesos)
La Piscina Sistema de Reparaciones representa una aplicación de SW que tiene un usuario: Técnico. Esta aplicación da soporte informático al Proceso de Negocio Ejecución de Orden de Trabajo. Nótese que el Ciente, que es un Participante del Proceso de Negocio, no es usuario de la aplicación.
El Gestor de Tareas le presenta al Técnico las Tareas (Revisar y aceptar OT, Registrar inicio de reparación y Cerrar OT) a medida que el flujo de trabajo va avanzando.
- El Técnico toma la Tarea Revisar y aceptar OT.
- El Técnico se traslada al domicilio de Cliente y se presenta (no está en el diagrama, son actividades manuales).
- El Técnico toma la Tarea Registrar inicio de reparación.
- El Técnico realiza la reparación y explica lo realizado al Cliente (no está en el diagrama, son actividades manuales).
- El Técnico toma la Tarea Cerrar OT.
El propósito de este ejemplo es mostrar el funcionamiento de la Tarea Usuario en el Ejecución de Procesos, no un modelo de ejecución completo, que puede ser muy complejo. Por este motivo, el diagrama muestra una versión simplificada del flujo de trabajo. Una versión completa debería considerar —a lo menos— que el Técnico libera la OT (queda disponible para otro Técnico), que el Cliente no permite la reparación, y que la reparación no es exitosa.
Proceso con Tareas Usuario - Ejecución de Procesos (i)
Cuando el flujo de trabajo llega a una Tarea, el Gestor de Tareas se la presenta al Técnico en la lista de pendientes. El Técnico, cuando considera que ya está listo para realizarla, la toma de la lista y el sistema le presenta una pantalla con el formulario que debe completar. Por ejemplo, después de terminada la Tarea Registrar inicio de reparación el proceso pasa a Cerrar OT, esto significa que esta aparece en la lista de Tareas pendientes. Cuando el Técnico considera que ya puede realizar la Tarea (es decir, ya terminó la reparación), la toma de la lista y se abre el formulario donde coloca un comentario, le pide al cliente que ponga su firma y oprime el botón Cerrar.
- El Gestor de Tareas agrega Revisar y aceptar OT a la lista, el Técnico la toma.
- El Técnico completa el formulario de Revisar y aceptar OT, la Tarea termina.
- El el flujo continúa, el Gestor de Tareas agrega Registrar inicio de reparación a la lista, el Técnico la toma.
- El Técnico completa el formulario de Registrar inicio de reparación, la Tarea termina.
- El el continúa, el Gestor de Tareas agrega Cerrar OT a la lista, el Técnico la toma.
- El Técnico completa el formulario de Cerrar OT, la Tarea termina.
Ejecución de Procesos - Funcionamiento
Normalmente, un flujo de trabajo está asociado un documentoo que va pasando por las distintas Tareas y va cambiando de estado. En el ejemplo, una Orden de Trabajo se va "transformando" a medida que avanza: por asignar, asignada, iniciada, terminada y cerrada.
Inscripción de Asignaturas (Ejecución de Procesos)
La Piscina Sistema de Inscripción de Asignaturas representa una aplicación de SW que tiene dos usuarios: Alumno y Tutor. Esta aplicación da soporte informático al Proceso de Negocio Inscripción de Asignaturas. Nótese que, a diferencia del ejemplo anterior, el receptor del servicio provisto —el Alumno— es también un usuario de la aplicación. El tercer Participante del Proceso de Negocio —el Profesor— no es usuario de la aplicación.
Al comienzo de cada período académico, el Gestor de Tareas agrega Inscribir asignaturas a la lista de pendientes de cada Alumno. Es decir, crea tantas Tareas como Alumnos —en condición de inscribir asignaturas— hay. Cada Tarea tiene un destinatario único. Compárese con el Sistema de Reparaciones, donde el Gestor de Tareas genera Revisar y aceptar OT y la coloca en la lista de pendientes de cada Técnico en terreno (los usuarios potenciales). Solo uno de ellos la toma y pasa a ser el "usuario real" de la Tarea, la que desaparece de las listas de pendientes de los demás Técnicos.
Al igual que el ejemplo anterior, el diagrama muestra una versión simplificada del flujo de trabajo. Una versión completa debería considerar —a lo menos— que el Alumno no inscribe asignaturas, que el Tutor no autoriza la inscripción, y que el Alumno rechaza los decidido por el Tutor.
Proceso con Tareas Usuario - Ejecución de Procesos (ii)
Tareas de Recepción y Envío de Mensaje
|
Una Tarea de Recepción espera la llegada de un Mensaje desde otro Participante. Una vez que ha recibido el Mensaje, la Tarea termina. Como toda Actividad, es un rectángulo de esquinas redondeadas y línea delgada. Tiene la figura de un sobre de carta en la esquina superior izquierda. |
|
|
Una Tarea de Envío entrega un Mensaje a otro Participante. Una vez que ha enviado el Mensaje, la Tarea termina. Como toda Actividad, es un rectángulo de esquinas redondeadas y línea delgada. Tiene la figura de un sobre de carta ennegrecido en la esquina superior izquierda. |
|
Normalmente, estas Tareas aparecen pareadas para crear una interacción: un Participante usa una Tarea de Envío para comunicarse con otro Participante. Más adelante en el Proceso, el primero espera, con una Tarea de Recepción, la respuesta del segundo. En el Proceso del segundo Participante habrá también dos Tareas pareadas, pero a la inversa: primero una Recepción y luego una de Envío.
Solicitud, Creación y Uso de Producto
El Proceso de Negocio muestra una interacción genérica entre dos Participantes: Cliente y Proveedor; donde el primero solicita, recibe y usa un cierto producto. Los detalles del Proveedor no se muestran.
En una Colaboración, los Participantes intercambian datos y bienes. En este caso, el Ciente le envía al Proveedor una solicitud (datos) y recibe un producto (bien). En BPMN, los Mensajes se usan para representar tanto datos como bienes (físicos e intangibles, es decir, productos y servicios).
Ejemplo
Nótese que el diagrama BPMN no muestra cómo se realiza la comunicación. Esta podría ser presencial: el Cliente va a las instalaciones del Proveedor, solicita el producto, lo recibe y se retira. También podría ser una compra telemática: pide el producto en el Portal Web del Proveedor y recibe el producto en su casa.
Consulta Médica
El Proceso de Negocio muestra una interacción entre dos Participantes: Paciente y Oficina Médica. Las Actividades dentro de la Oficina Médica las realizan dos Roles: Doctor y Recepcionista. (Esta es una variante del ejemplo: "An example of a Collaborative Process" [BPMN 2.0, p. 23]).
La Colaboración incluye tres interacciones:
- Entre el Paciente y la Recepcionista: la solicitud de hora de consulta.
- Entre el Paciente y el Doctor: la consulta en sí.
- Entre el Paciente y la Recepcionista: el despacho de la receta.
En este caso, las tres interacciones son iniciadas por el mismo Participante —el Paciente—. Esto no es siempre así, cualquiera de los Participantes puede iniciar una interacción.
Ejemplo
Medios para intercambiar Mensajes
El diagrama BPMN de Consulta Médica no muestra cómo se realiza la comunicación (al igual que en Solictud, Creación y Uso de Producto). En ambos casos se está usando BPMN para el Modelado de Procesos, donde la comunicación es realizada por personas. En un Proceso de Negocio concreto el o los medios de comunicación utilizados deben estar claramente documentados.
Por ejemplo, en una vesión "presencial" de Consulta Médica las interacciones serían las siguientes:
- La solicitud de hora de consulta se realiza mediante una comunicación telefónica.
- La consulta en sí se realiza cara a cara: el Paciente se presenta en persona en la Oficina Médica.
- El despacho de la receta se realiza cara a cara: el Paciente despacha la receta en la Oficina Médica una vez termina la interacción con el Doctor.
Ejemplo
Por otro lado, en una vesión "telemática" de Consulta Médica las interacciones serían las siguientes:
- La solicitud de hora de consulta la realiza el Paciente en una applicación en su dispositivo móvil. La Recepcionista utiliza un sistema de reservas en su computador de escritorio.
- La consulta en sí la realizan el Paciente y el Doctor por videoconferencia.
- El despacho de la receta lo realiza la Recepcionista mediante una empresa de transporte. El Paciente recibe la notificación del despacho en su dispositivo móvil.
Ejemplo
Funcionamiento de la Tarea de Recepción
El propósito de la Tarea de Recepción es incorporar al Proceso datos o bienes que se originan fuera de él. Los datos o bienes llegan por un Flujo de Mensaje y pasan al interior del Proceso por una Asociación dirigida a un Objeto de Datos. La estructura del Mensaje debe coincidir con la estructura del Objeto de Datos. La Tarea funciona de la siguiente manera:
- La Tarea Recibir datos o bienes recibe el control (el Flujo del Proceso llega a ella) y espera la llegada de un Mensaje.
- El Creador de Datos o Bienes envía un Mensaje cuyo contenido cumple con la estructura esperada por la Tarea.
- La Tarea recibe el Mensaje, toma su contenido y lo envía por la Asociación hacia el Objeto de Datos Salida. De esta manera, los datos o bienes originados en el exterior ingresan al Proceso.
- La Tarea termina y el Proceso continúa.
El Flujo de Mensaje entrante y la Asociación de Datos saliente siempre existen, pero no es obligatorio mostrarlos en el diagrama.
Funcionamiento de la Tarea de Recepción
Funcionamiento de la Tarea de Envío
El propósito de la Tarea de Envío es traspasar hacia el exterior del Proceso datos o bienes que existen dentro de él. Los datos o bienes llegan a la Tarea por una Asociación y pasan al exterior por un Flujo de Mensaje. La estructura de datos que ingresa a la Tarea es usada para crear el Mensaje de salida. La Tarea conoce al destinatario del Mensaje y qué (datos o bines) espera. La Tarea funciona de la siguiente manera:
- La Tarea Enviar datos o bienes recibe el control (el Flujo del Proceso llega a ella).
- La Tarea recibe datos o bienes a través de la Asociación conectada al Objeto de Datos Entrada.
- La Tarea crea un Mensaje con los datos o bienes recibidos, y lo envía al Receptor de Datos o Benes.
- La Tarea termina y el Proceso continúa.
El Flujo de Mensaje saliente y la Asociación de Datos entrante siempre existen, pero no es obligatorio mostrarlos en el diagrama.
Funcionamiento de la Tarea de Envío
Comunicación entre Piscinas y dentro de una Piscina
En BPMN un Proceso ocurre dentro de una Piscina. Una Colaboración es la interacción de varios Procesos, cada uno en su propia Piscina. Existe comunicación (intercambio de datos) tanto dentro de una Piscina como entre Piscinas. Dicho en otras palabras, existe comunicación tanto dentro de un Proceso como entre Procesos. BPMN define dos notaciones distintas para la comunicación en uno y otro caso:
- Dentro de un proceso se usan Objetos de Datos (y sus variantes), que son creados y consumidos por Actividades y Eventos.
- Entre Procesos se usan Mensajes, que son —principalmente— enviados y recibidos por Tareas (Recepción y Envío) y Eventos Mensaje (Captura y Lanzamiento).
El siguiente diagrama muestra una versión de Solictud, Creación y Uso de Producto que incluye, además del intercambio de Mensajes, la comunicación mediante Objetos de Datos (Solictud y Producto) dentro del Proceso del Cliente.
Ejemplo
En BPMN un Proceso de Negocio se representa mediante una Colaboración entre varios Participantes que se comunican y coordinan mediante Mensajes.
Cuando el detalle del Proceso de uno de los Participantes no es relevante, se puede usar una Piscina Caja-Negra para modelarlo, es decir, solo se dibuja el rectángulo sin Objetos de Flujo en su interior, como Proveedor en el diagrama anterior.
Incluso se puede eliminar del diagrama la Piscina de un Participante, pero éste sigue existiendo, aunque de manera implícita. En este caso, los Eventos y/o Actividades que se comunican con este Participante ya no están conectados por Flujos de Mensajes, pero siguen modelando la relación con él.
Para facilitar la lectura del diagrama, los Eventos y/o Actividades que interactúan con el Participante implícito deben reflejar en sus nombres esta relación. Por ejemplo, la Tarea Enviar solicitud ahora se llama Enviar solicitud al Proveedor.
Ejemplo
El siguiente Proceso de Negocio muestra una interacción genérica entre dos Participantes: Cliente y Organización; donde el primero solicita al segundo que estudie una cierta materia y recibe un informe con el resultado del estudio. Los detalles del Proceso del Cliente no se muestran.
En la Organización, el Supervisor recibe la solicitud, planifica y deriva el trabajo al Analista. Este realiza el estudio y escribe la primera versión del informe. Finalmente, el Supervidor revisa y corrige el informe, y lo entrega al Cliente.
El intercambio de Mensajes se realiza por medio de Eventos Mensaje (Inicial y Final). El Objeto de Datos Informe pasa por dos estados: preliminar y final.
Así como los Mensajes y Flujos de Mensaje entre Piscinas no describen el medio de comunicación utilizado, los Objetos de Datos y las Asociaciones no inidican cómo se realiza la comunicación. Por ejemplo, el Analista puede entregar en mano el informe al Supervisor, o adjuntarlo a un correo electrónico, o puede que sea un documento compartido en un sistema de gestión documental. En un Proceso de Negocio concreto el o los medios de comunicación utilizados deben estar claramente documentados.
Ejemplo
Un error común es creer que los Mensajes se pueden usar para comunicarse dentro de una Piscina. Por ejemplo, en el siguiente diagrama el modelador usa las Tareas de Envío y Recepción para indicar que "el Analista le envía el informe al Supervisor".
Nótese que el diagrama está sintácticamente correcto, es decir, cumple con las reglas del lenguaje BPMN, pero no representa lo que el modelar pretendía. De hecho, la interpretación correcta —para BPMN— es que Escribir informe envía "el informe a alguien fuera de la Piscina" y Escribir informe recibe "el informe desde alguien fuera de la Piscina".
Ejemplo
Otro error relacionado con el uso de Mensajes dentro de una Piscina consiste en utilizar un Evento Mnesaje de Lanzamiento para indicar que una Actividad le comunica algo a otra Actividad. Por ejemplo, en el siguiente diagrama el modelador usa el Evento Mensaje para indicar que "el Analista le envía el informe al Supervisor".
Al igual que en el caso anterior, el diagrama está sintácticamente correcto, es decir, cumple con las reglas del lenguaje BPMN, pero no representa lo que el modelar pretendía. De hecho, la interpretación correcta —para BPMN— es que después Escribir informe el Proceso envía "el informe a alguien fuera de la Piscina" y luego pasa a la Tarea Escribir informe.
Ejemplo
Tareas de Mensaje y Eventos de Mensaje
Texto.
Texto.
Ejemplo
Texto.
Texto.
Ejemplo
Texto.
Texto.
Ejemplo
Texto.
Texto.
Texto.
Tarea de Recepción iniciador de Proceso
|
Una Tarea XXXX texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. |
|
Texto.
Texto.
Tarea Servicio
|
Una Tarea XXXX texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. |
|
Texto.
Texto.
Ejemplo
Texto.
Texto.
Texto.
Funcionamiento Servicio
Texto.
Texto.
Tarea Regla de Negocio
|
Una Tarea XXXX texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. |
|
Texto.
Texto.
Ejemplo
Texto.
Texto.
Texto.
Texto.
Tarea Script
|
Una Tarea XXXX texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. |
|
Texto.
Texto.
Ejemplo
Texto.
Texto.
Texto.
Texto.
Tarea Global-Reutilizable
Texto.
Texto.
Texto.
Llamadas a Tareas Globales
| Tipo | Notación | Descripción |
|---|---|---|
| Abstracta |  |
Una Tarea Abstracta no tiene un tipo03 específico. |
| Manual |  |
YYY |
| Usuario |  |
YYY |
| Regla de Negocio |  |
YYY |
| Script |  |
YYY |
Texto.
Ejemplo
Texto.
Texto.
Texto.
Texto.
Marcadores
Las Tareas pueden tener marcadores en su parte inferior central.
Hay dos tipos de marcadores para la Tarea: Marcador de Iteración (con tres variantes) y Marcador de Compensación.
Una Tarea puede tener uno o dos de estos Marcadores, pero sólo una variante del Marcador de Iteración.
Tanto las Tareas como los Subprocesos pueden ser iterativos (estándar, paralelo o secuencial). En el caso de un Subproceso, la Actividad tiene las dos Marcas en la parte inferior.
Marcadores de Actividades
| Marcador | Icono | Tarea | Descripción | |
|---|---|---|---|---|
| Iteración | Estándar |
|
La Actividad se repite mientras se cumple una condición. | |
| Multiinstancia Paralela |
|
La Actividad se ejecuta varias veces de manera simultánea, normalmente para procesar una colección de datos. | ||
| Multiinstancia Secuencial |
|
La Actividad se ejecuta varias veces una después de otra, normalmente para procesar una colección de datos. | ||
| Compensation |
|
Texto. | ||
Iteraciones
¿Cuándo una Actividad es iterativa?
El responsable de una Actividad debe asegurar que todas las acciones son realizadas correctamente siguiendo las normas y estándares establecidos. Si es necesario, debe rehacer parte o todo el trabajo. Solo puede dar por terminada la Actividad cuando todos los artefactos e información creados o modificados cumplen con los estándares de calidad requeridos.
Visto así, toda Actividad sería iterativa: hacer algo, repetirlo –si es necesario–, hasta que se cumple una condición. Sin embargo, esto no es práctico, pues al ser “todo iterativo” el concepto mismo de iteración pierde sentido.
Debemos reservar las Marcas de Iteración para aquellas Actividades (como las de los ejemplos) que deben hacerse completas varias veces: varias reuniones, varias reparaciones, etc.
El Comité de Reclutamiento recibe los CV de los Postulantes y repite Revisar antecedentes para cada uno de ellos. La iteración es paralela, ya que la revisión puede ser simultánea.
Posteriormente, el Comité de Reclutamiento entrevista a los Postulantes. La iteración es secuencial, ya que las entrevistas se hacen una tras otra.
Ejemplo Reclutamiento
El Técnico repite Reparar conexión hasta que la señal alcanza un mínimo aceptable. Es decir, realiza todas las acciones de la Actividad y mide la señal. Si no se logra el mínimo aceptable, repite las acciones. Si se alcanza e mínimo, la Actividad termina y cierra la orden de trabajo.
Ejemplo Reparación
Documentación
Reglas de Negocio. Entradas y Salidas de Datos. Reglas de Transformación de datos recibidos. RACI.
Especificación BPMN
A Task is an atomic Activity within a Process flow. A Task is used when the work in the Process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the Task when it is executed.
A Task object shares the same shape as the Sub-Process, which is a rectangle that has rounded corners that MUST be drawn with a single thin line.
There are different types of Tasks identified within BPMN to separate the types of inherent behavior that Tasks might represent.
There are different types of Tasks identified within BPMN. The specific Task type depiction is obtained by placing a Task type maker in the upper left corner of the Task shape. A Task that is no further specified is called an Abstract Task.
In many business workflows, human involvement is needed to complete certain Tasks specified in the workflow model. BPMN specifies two different types of Tasks with human involvement, the Manual Task and the User Task.
Tasks (Abstract, Service, Send, Receive, User, Manual, Business Rule or Script) can also have Compensation and/or Loop Characteristic markers at the bottom center of the shape.
BPMN specifies two types of markers for Task: Iteration marker and Compensation marker. A Task MAY have one or two of these markers (see Figure 10.9).
