INS-45!1!01-01 Modelamiento de Procesos Con BPMN1

Modelamiento de Procesos con BPMN
INS-45-1-01-01
FECHA PUBLICACIÓN 18/01/2016
MACROPROCESO NIVEL 1 NIVEL 2 VERSIÓN
Efectividad Institucional Sistema de Calidad Institucional Gestión de Procesos 0
Tabla de Contenido
1. OBJETIVO ..................................................................................................................................... 3
2. ALCANCE ...................................................................................................................................... 3
3. INSTRUCCIONES .......................................................................................................................... 3
3.1. Reglas Generales para el Modelamiento de Procesos ...................................................... 3
3.1.1. Criterio de Proceso ........................................................................................................ 3
3.1.2. Nivel de uso de Notación BPMN ................................................................................... 3
3.1.3. Utilización de Pools, Lanes y Fases ................................................................................ 4
3.1.4. Orientación del Diagrama.............................................................................................. 5
3.1.5. Anotaciones y Grupos.................................................................................................... 6
3.2. Objetos de Conexión.......................................................................................................... 7
3.2.1. Línea de Secuencia ........................................................................................................ 7
3.2.2. Línea de Mensaje........................................................................................................... 7
3.2.3. Línea de Asociación ....................................................................................................... 8
3.3. Actividades ......................................................................................................................... 9
3.3.1. Actividad ‐ Usuario ........................................................................................................ 9
3.3.2. Actividad ‐ Manual....................................................................................................... 10
3.3.3. Actividad ‐ Script.......................................................................................................... 10
3.3.4. Actividad ‐ Servicio ...................................................................................................... 10
3.3.5. Actividad ‐ Envío .......................................................................................................... 10
3.3.6. Actividad ‐ Recepción .................................................................................................. 10
3.3.7. Actividad ‐ Regla de Negocio ....................................................................................... 10
3.4. Subprocesos ..................................................................................................................... 11
3.4.1. Embebido..................................................................................................................... 11
3.4.2. Reusable ...................................................................................................................... 12
3.5. Eventos ............................................................................................................................ 13
3.5.1. Eventos de inicio .......................................................................................................... 14
3.5.2. Eventos intermedios .................................................................................................... 15
3.5.3. Eventos de fin .............................................................................................................. 18
3.6. Compuertas...................................................................................................................... 19
Dirección de Planeación y Evaluación |1

INS-45-1-01-01
3.6.1. Compuerta Paralela .................................................................................................... 20

3.6.2. Compuerta Exclusiva Basada en Datos ...................................................................... 21
3.6.3. Compuerta Exclusiva Basada en Eventos ................................................................... 24
3.6.4. Compuerta Inclusiva ................................................................................................... 25
3.6.5. Compuerta Compleja .................................................................................................. 27
3.7. Modelaje de Datos ........................................................................................................... 27
3.7.1. Data Objects .............................................................................................................. 27
3.7.2. Data Stores ................................................................................................................. 29
3.8. Recomendaciones para la Automatización de Procesos ................................................. 29
3.8.1. Entidades ..................................................................................................................... 31
3.8.2. Reglas de Negocio ....................................................................................................... 32
4. DEFINICIONES ............................................................................................................................ 32
5. DOCUMENTOS DE REFERENCIA ................................................................................................ 34
6. CONTROL DE CAMBIOS ............................................................................................................. 34
7. APROBACION ............................................................................................................................. 34
8. ANEXOS ..................................................................................................................................... 34

INS-45-1-01-01
1. OBJETIVO
Establecer las reglas básicas de modelamiento de procesos utilizando notación BPMN, como punto
de partida para estandarizar el modelamiento de los procesos de la Universidad.
2. ALCANCE
Las instrucciones presentadas en este documento deben ser tenidas en cuenta en los siguientes
ámbitos:
 Documentación de procesos que hacen parte de la cadena de valor.

 Proyectos de análisis y mejoramiento de proceso.
 Proyectos de automatización de procesos.
 Unidades Académicas y Administrativas que tienen la necesidad o el interés de modelar
sus procesos.
3. INSTRUCCIONES
A continuación se presentan las instrucciones generales que se deben tener en cuenta para
modelar procesos siguiendo los lineamientos establecidos por la Dirección de Planeación y
Evaluación y el uso mediante BPMN.
3.1. Reglas Generales para el Modelamiento de Procesos

3.1.1. Criterio de Proceso
Un proceso debe cumplir con las siguientes características:
 Incluir mínimo 3 actores (como cargos o roles independientemente que en el diagrama
solo esté una unidad o dependencia).
 Contar con mínimo 6 actividades.
 Tener una secuencia de actividades lógicas que se repitan en el tiempo y que los
resultados son siempre los mismos.
 Cuando el diagrama de proceso contenga un número mayor a 35 actividades de debe
analizar la posibilidad de dividirlo, para facilitar su comprensión.
3.1.2. Nivel de uso de Notación BPMN

Dependiendo de la necesidad de documentación se van a utilizar distintos niveles de uso de la
notación BPMN.
 Descriptivo: El nivel descriptivo es utilizado para la documentación de los procesos de la

cadena de valor.
o Captura el proceso de forma general
o Contexto de Negocios – Alto Nivel
o Entendimiento generalizado
o Documentación básica del proceso

INS-45-1-01-01
o Puede omitir detalles como caminos de excepción y validaciones

 Analítico: El nivel analítico es utilizado en los proyectos donde el objetivo sea analizar y
mejorar los procesos.
o Detalle completo
o Analizar el proceso
o Situación actual (AS-IS) –Situación Propuesta (TO-BE)
o Todos los caminos deben estar diagramados
o Se debe incluir información sobre los recursos involucrados
 Ejecutable: El nivel ejecutable es utilizado en el modelamiento de procesos que van a ser
automatizados a través de cualquier herramienta BPMS (Business Process Management
System).
o Detalle de información para implementar el proceso en una herramienta de
automatización (BPMS) como: reglas de negocio, cargos o roles, asignación de
actividades, etc.
3.1.3. Utilización de Pools, Lanes y Fases

Pool
 Los procesos están contenidos dentro de un pool (contenedor), en consecuencia cada
proceso diagramado debe tener un pool. Un pool contiene un único proceso y su nombre
puede considerarse como el nombre del proceso.
 Los flujos de secuencia no pueden cruzar los límites del pool.
Lanes
 Los lanes (calles horizontales) se utilizan para representar a cada uno de los participantes
del proceso. Un lane puede representar un área funcional (Unidad Académica o
Administrativa), un cargo o un rol. Un área funcional puede ser responsable de muchas
actividades.
 Las áreas funcionales no determinan las asignaciones de las actividades, son una ayuda
para realizar las consultas graficas del proceso.
 En el proceso que se esté diagramando no pueden existir elementos que no estén
ubicadas en un lane o en un pool.

INS-45-1-01-01
Fases
 Las fases de un proceso se usan para delimitar etapas distintas de un proceso en donde se
puede identificar una salida intermedia entre una etapa y la siguiente. Por ejemplo:
En la imagen anterior, se puede ver un proceso de pago de factura que tiene una fase de
aprobación y una posterior de realización del pago.
3.1.4. Orientación del Diagrama

Los procesos serán modelados de izquierda a derecha, iniciando la diagramación en la esquina
superior derecha, de forma que se extienda hacia abajo y a la derecha.

INS-45-1-01-01
 Forma Incorrecta
 Forma correcta
3.1.5. Anotaciones y Grupos

 Las anotaciones se utilizan para proporcionar información adicional sobre el proceso o sus
actividades. Se pueden dar como una nota de una mejora, justificación, pregunta,
observación especificación técnica.
 Los grupos son utilizados para agrupar un conjunto de actividades para efectos de
compresión, visuales o mejor entendimiento. No afectan la secuencia del flujo.

INS-45-1-01-01
3.2. Objetos de Conexión

3.2.1. Línea de Secuencia
Las líneas de secuencia se representan por una flecha solida terminada en un triángulo relleno.
Representan el control y flujo y la secuencia de las actividades. Se debe tener en cuenta que:
 Se utiliza para representar la secuencia de los objetos de flujo, dentro de los cuales se
encuentran las actividades, las compuertas y los eventos.
 El avance del proceso se ve por el flujo de secuencia, que debe ser de izquierda a derecha,
de arriba hacia abajo o de abajo hacia arriba.
Patrón Básico de Control de Flujo – Secuencia

 Se requiere cuando hay una dependencia de dos tareas, de tal forma que una tarea no
pueda iniciarse antes de que la otra se haya terminado (actividades en serie).
3.2.2. Línea de Mensaje

Representan la interacción entre varias entidades o procesos, a través de las cuales se comunican
mensajes. No representan flujos de secuencia. Se debe tener en cuenta que:
 Representan Señales o Mensajes.  

 No representan flujos de control.  
 No todas las líneas de mensaje se cumplen para cada instancia del proceso y tampoco se
especifica un orden para los mensajes.  
Nota: Según el estándar establecido por la Dirección de Planeación y Evaluación, no se utilizará

este tipo de objeto de conexión, ya que sólo se usara un pool por proceso.

INS-45-1-01-01
 Forma Incorrecta
 Forma Correcta
3.2.3. Línea de Asociación

Su objetivo es crear relaciones entre los objetos de datos (ver sección 3.7) y los elementos del
diagrama de proceso, como se puede ver en la siguiente imagen.

INS-45-1-01-01
3.3. Actividades
Las actividades representan el trabajo realizado dentro de una organización. Se debe tener en
cuenta que:
 No representa un estado, función o evento.

 Cuando una actividad es completada la siguiente actividad inicia.
 Una actividad consume recursos de la organización.
Nota: Si no se logra organizar las calles y hay actores que comparten una actividad pero no se
pueden unir, entonces se deja la actividad en un sólo actor y se especifica en la descripción de
actividades.
Para cumplir el objetivo de modelar procesos ejecutables, se cuentan con tipos de actividades
especializadas.
Nota: Para la diagramación de procesos cuyo fin sea distinto a la automatización, solo se
utilizaran las tareas genéricas.
A continuación se presenta una descripción de los tipos de actividades más comúnmente usados.
3.3.1. Actividad ‐ Usuario

Una actividad de usuario es una actividad típica de flujo de trabajo (workflow), en donde una
persona realiza la tarea con la ayuda de una aplicación de software y está programada a través de
un gestor de listas de tareas de algún tipo.

INS-45-1-01-01
3.3.2. Actividad ‐ Manual

Una actividad manual es una actividad que se espera sea realizada sin la ayuda de algún motor de
ejecución de procesos de negocio o cualquier otra aplicación. Un ejemplo de esto podría ser un
técnico de telefonía que hace la instalación de un teléfono en la ubicación del cliente.
3.3.3. Actividad ‐ Script

Una actividad tipo Script es una actividad automática, solo que no la resuelve un sistema externo,
sino que la resuelve el mismo sistema que está automatizando un proceso. El usuario define
un script en un lenguaje que el motor de procesos pueda interpretar. Las actividades de reparto y
asignación de responsables, por lo general son actividades tipo script si se resuelven internamente
en el motor de proceso, así como el envío de un correo electrónico.
3.3.4. Actividad ‐ Servicio

Este tipo de actividad se utiliza para consumir servicios automáticos ofrecidos por un sistema de
información. Esta actividad se lleva a cabo por el sistema sin intervención humana.
3.3.5. Actividad ‐ Envío

Es un tipo de actividad simple que está diseñada para enviar un mensaje a un participante externo
(en relación con el proceso). Una vez que el mensaje ha sido enviado, se completa la tarea.
3.3.6. Actividad ‐ Recepción

Es un tipo de actividad simple que está diseñada para esperar a que llegue un mensaje de un
participante externo (en relación con el proceso). Una vez que el mensaje ha sido recibido, se
completa la tarea.
3.3.7. Actividad ‐ Regla de Negocio

Este tipo de actividad proporciona un mecanismo para que el proceso le de entradas a un motor
de reglas de negocio y para obtener las salidas que este motor le puede brindar.
Recomendaciones de uso de Actividades

 Las tareas que son realizadas por un mismo usuario en un mismo instante de tiempo y que
tienen un mismo objetivo se agrupan en una sola.
 No se diagraman las tareas de remitir información de un puesto de trabajo a otro. El
detalle del envío o recepción de información y el medio por el que se realizan, se deja en
la descripción de actividades de la ficha técnica.
 Para identificar las tareas, es recomendable:
o Identificar que va a hacer el usuario en dicha actividad.  
o Identificar si lo podría realizar en un mismo instante de tiempo
 Por ejemplo: Se tiene la actividad “Contactar cliente”, en la cual contiene
la tarea de llamar por teléfono y registrar el resultado de la llamada.
Dirección de Planeación y Evaluación | 10

INS-45-1-01-01
3.4. Subprocesos
Es una actividad compuesta que es incluida dentro de un proceso. Es compuesta dado que esta
figura incluye a su vez un conjunto de actividades y una secuencia lógica (proceso) que indica que
dicha actividad puede ser analizada a un nivel más fino.
La representación del subproceso puede ser:
Colapsado Extendido
Los procesos colapsados deben tener un evento de inicio y uno de finalización.
 Para cumplir el objetivo de modelar procesos ejecutables, se cuenta con tipos de

subprocesos especializados.
o Embebido
o Reusable
Nota: Para la diagramación de procesos cuyo fin sea distinto a la automatización, no habrá
distinción entre los subprocesos embebidos y los reusables.
3.4.1. Embebido
Un Sub-Proceso embebido es “parte del” proceso. Es decir, pertenece solo al Proceso padre y no
está disponible para ningún otro proceso.
 No puede contener pools, ni áreas funcionales

 Solo puede utilizar un evento de inicio sin especificar (simple)
 Los datos que puede utilizar el subproceso son los mismos datos que usa el proceso padre,
sin necesidad de mapeo.

INS-45-1-01-01
Proceso padre y subprocesos embebidos
3.4.2. Reusable
Es un proceso definido como un diagrama de procesos independiente y que no depende del
proceso padre.
 Son reutilizables, pues al no depender del proceso padre, pueden aparecer, sin cambios,
en varios diagramas.
 Pueden ser procesos de alto nivel y subprocesos.

INS-45-1-01-01
Proceso Padre
Subproceso Reusable
Recomendaciones de uso de Subprocesos

 Recomendaciones para identificar subprocesos:
o Identificando un conjunto de tareas que tienen un objetivo diferente al proceso
padre.  
o Necesidad de ser invocado de procesos diferentes. Es decir que son actividades
reusables por otros procesos.
o Conjunto de actividades con contexto diferente.  
o Diferente dueño.  
 El subproceso puede tener o no el mismo contexto del proceso que lo invoca.
3.5. Eventos
Un evento representa algo que ocurre o puede ocurrir durante el curso de un proceso. Tienen una
causa y un impacto.

INS-45-1-01-01
Existen tres tipos de eventos dependiendo de la forma en la que afecta el flujo:
 Eventos de inicio
 Eventos intermedios
 Eventos de fin
3.5.1. Eventos de inicio

Los eventos de inicio son los disparadores del proceso, todo proceso debe tener al menos un
evento de inicio, puede darse el caso de procesos que tengan varios eventos de inicio. El símbolo
al interior del evento de inicio, identifica el tipo de disparador del proceso.
Inicio Simple
Este evento indica que un proceso ha iniciado. No tiene flujos de secuencia que lo precedan. No
específica ningún comportamiento particular, generalmente es porque uno de los actores del
proceso lo dispara manualmente.
Inicio por Mensaje

Un sistema de información u otro proceso envían un mensaje específicamente a este proceso para
que inicie un proceso, cuando el mensaje es recibido, el proceso arranca.
 Inicio de un proceso que es activado cuando se recibe un mensaje.

 El mensaje puede ser recibido desde un evento intermedio de mensaje (envío) o un
evento de fin de mensaje.

INS-45-1-01-01
Al utilizarse sólo un pool por proceso, no se tendría el diagrama que aparece en la imagen
anterior. Sin embargo, la idea de la comunicación entre procesos se mantiene. Se identifica como
la salida del proceso de Solicitud de cargo, luego se convierte la entrada del de Selección de
candidatos.
Nota: Los únicos eventos por mensaje que se nombran, son los que se relacionan con un evento
de mensaje intermedio. Esto con el fin de tener claridad en que parte de los procesos se está
enviando los mensajes. Las parejas de mensajes se deben llamar igual.
Inicio por Condición de Tiempo

Se utiliza para indicar que el proceso se inicia periódicamente o en una fecha determinada.
 Ejemplo: cada 10 de diciembre se abren los plazos para la inscripción de materias en el

galpón.
 El temporizador debe indicar el parámetro en términos de tiempo.
Inicio por Señal

Este tipo de evento sirve para modelar la comunicación entre diferentes procesos, por lo que el
proceso inicia cuando se captura una señal lanzada desde otro proceso. Es importante tener en
cuenta que la señal es diferente al mensaje, pues el mensaje tiene un destinatario claro, en
cambio la señal no.
3.5.2. Eventos intermedios

Son eventos que ocurren en la mitad del proceso, es decir entre el inicio y el fin del mismo. Estos
eventos pueden utilizarse dentro del flujo de secuencia.
Los eventos intermedios se dividen en dos tipos, los de Esperar o recibir (catching) y los de Lanzar
(throwing) los cuales se diferencian por los iconos oscuros al interior.
 Cuando el evento es usado para recibir, el icono del circulo esta sin rellenar y cuando es
para lanzar se encuentra relleno. Los eventos intermedios se reconocen porque tienen
doble borde.
Nota: Si hay muchos eventos de envío (throw) que entren a la misma actividad, se coloca un solo
evento de recepción (catch) antes de esta.
Cuando un proceso llega a un evento intermedio de espera, se detiene en él y la única forma que
tiene de continuar es que el ocurra el evento que está esperando, bien sea que reciba un mensaje
para continuar, que se cumpla la condición de tiempo, que se cumpla o que suene la señal que
está esperando para poder continuar.
 Si el evento que está esperando no ocurre, el proceso nunca avanzará.

INS-45-1-01-01
 En ningún caso un evento intermedio de Lanzar detiene el proceso, solo realiza su tarea y
continúa la ejecución del proceso.
Evento Intermedio sin Especificar

Indica algo que ocurre o puede ocurrir dentro del proceso. Solo se pueden utilizar dentro de la
secuencia de flujo.
 Ejemplos:
o Cancelar una solicitud
o Recibir documentos del cliente
Evento Intermedio de Enlace

Este evento permite conectar dos secciones de un proceso. Generalmente se usan para que las
líneas de secuencia de flujo no se crucen.
 Envío (throw): Desde donde parte el flujo.

 Recepción (catch): Desde donde continúa el flujo.
Nota: Estos eventos deben ser enumerados de manera que cada evento de salida tenga un
evento de llegada.
Evento Intermedio de Mensaje

Este evento indica que un mensaje puede ser enviado o recibido. Si el evento de mensaje es de
recepción, indica que el proceso no continuará hasta que el mensaje sea recibido.
 Envío (throw): Lanza un mensaje y continúa el flujo del proceso.

 Recepción (catch): Recibe un mensaje.
o Espera el mensaje para continuar con el flujo del proceso
Nota: Se utiliza cuando se quieren enviar un mensaje de un proceso a otro. Estos se deben
enumerar y se coloca la actividad o acción del proceso del cual sale. Este mensaje tiene un único
destinatario y sólo puede ser enviado por otro proceso.
Evento Intermedio de Tiempo

Este evento indica una espera o demora dentro del proceso. Puede utilizarse dentro del flujo de
secuencia, indicando una espera entre las actividades antes de que se ejecuten.

INS-45-1-01-01
Evento Intermedio de Señal

Este evento se utiliza para enviar o recibir señales. Se puede utilizar dentro del flujo de secuencia
para enviar o recibir señales que activarán la siguiente actividad cuando la señal sea capturada.
 Envío (throw): Lanza una señal que continúa el flujo del proceso. Esta señal puede ser
“escuchada” por muchos procesos (los que estén preparados para escucharla).
 Recepción (catch): Espera una señal para continuar con el flujo del proceso.
A continuación se presenta un ejemplo del uso de este tipo de evento y del evento fin de señal.
Como se puede ver, el proceso de Gestión de Requerimientos espera a que el de Evaluación de

Sugerencias mande la señal que se reunión el comité para poder continuar con el proceso.

INS-45-1-01-01
Nota: Como la señal enviada desde un proceso puede ser “oída” por varios procesos, esta debe
ser nombrada de manera clara para evitar ambigüedades, y debe ser descrita en la Descripción de
Actividades de la Ficha Técnica.
3.5.3. Eventos de fin

Los eventos de fin son la marca que identifica el fin de un proceso. Todo proceso debe tener al
menos un evento de fin, pero es habitual que los procesos tengan varios eventos de fin para darle
claridad al tipo de terminación que tuvo el proceso.
 Ejemplo: No es lo mismo saber que el proceso terminó, que saber que el proceso terminó
aprobado o que el proceso terminó rechazado.
Evento Fin Simple

Indica que un camino del flujo de secuencia llego a su fin.
Evento Fin de Mensaje

Este evento es utilizado cuando se termina un flujo de secuencia y al llegar a este punto se desea
enviar un mensaje.
 Ejemplo: Se puede observar el diagrama del ejemplo de Evento Intermedio de Señal, en

donde se usó el Evento Fin de Mensaje, que a su vez puede ser la entrada de un proceso
de Desarrollo de soluciones. Este proceso iniciaría con un evento de inicio de mensaje,
Evento Fin de Señal

Este evento es utilizado cuando lanza una señal y finaliza el camino del proceso.
 Ejemplo: Se puede observar el diagrama del ejemplo de Evento Intermedio de Señal.
Evento Fin Terminal

Este evento indica que el proceso ha terminado, es decir cuando algún camino del flujo llega a este
fin el proceso termina, completamente, sin importar si existen más caminos del flujo pendientes
de llegar al fin.

INS-45-1-01-01
Nota: siempre que se tenga una compuerta paralela (ver 3.6.1) que no converja, se debe poner
eventos de fin terminal para asegurar que se terminen todas las instancias del proceso que siguen
activas.
Recomendaciones para uso de Eventos

 Todos los eventos deben tener una etiqueta que indique la naturaleza del evento.
o Ejemplo: Recepción de factura, mensual, Cada 5 días, etc.
 Los eventos que trabajan en pares (throw y catch) deben ser enumerados y se coloca la
actividad del proceso del cual sale.
 Cuando se tienen actores externos dentro del proceso se recomienda identificar:
o ¿Cómo se espera que el actor interactúe con el proceso?  
o ¿Se desea modelar dentro del proceso y que realice una actividad?  
 Por ejemplo en el envío y recepción de información o documentos por
parte de un actor externo, éste puede ser modelado a través de un
evento. Sin embargo, si se decide modelar dentro del proceso, debe haber
un lane con su nombre y una actividad a su cargo.
• Para los procesos ejecutables, si se modela un actor dentro del proceso, este debe tener
un usuario nombrado y por lo tanto una licencia.
3.6. Compuertas
Las compuertas son elementos utilizados para controlar los puntos de divergencia y de
convergencia del flujo.

INS-45-1-01-01
Divergente Convergente
Nota: Una compuerta no puede ser convergente y divergente al mismo tiempo.
Existen varios tipos de compuertas:
3.6.1. Compuerta Paralela

Una compuerta paralela es un punto de paralelismo en el proceso. Después de esta compuerta
todos los caminos habilitados se dispararán en paralelo.
 Divergencia: Se utiliza cuando varias actividades pueden realizarse concurrentemente o en

paralelo.
 Convergencia: Permite sincronizar varios caminos paralelos en uno solo. El flujo continúa
cuando todos los flujos de secuencia de entrada hayan llegado a la figura.
A continuación se muestra un ejemplo de uso de las compuertas.

INS-45-1-01-01
Recomendaciones de uso de Compuerta Paralela

 No se le coloca nombre a las compuertas paralelas.
 Cuando no se sincronizan los caminos, se debe terminar cada uno de los flujo con un
evento de fin terminal (ver sección 3.5.3).
3.6.2. Compuerta Exclusiva Basada en Datos

Una compuerta exclusiva es un punto de decisión que depende exclusivamente de los datos del
proceso, donde solo una de las rutas de salida de la compuerta será escogida, es decir al momento
de llegar a esta compuerta solo está permitido seguir por un solo camino y los demás quedan
descartados.
 Divergencia: Ocurre cuando en un punto del flujo basado en los datos del proceso se
escoge un camino de varios disponibles.
 Convergencia: Como punto de convergencia, es utilizada para sincronizar caminos
excluyentes.

INS-45-1-01-01
Recomendaciones de uso de Compuerta Exclusiva Basada en Datos

 A pesar que según BPMN estas compuertas pueden ser representadas con una “X”, el
estándar de la Dirección de Planeación y Evaluación indica que no debe ser así. Se dejan
sin el marcador de la X, mientras que la pregunta o condición que debe cumplirse va
abajo.
 Las compuertas exclusivas se identifican con una pregunta o una condición, la cual debe
ser lo más concreta posible, sin sacrificar el entendimiento del proceso.
o Por ejemplo: ¿Solicitud aprobada?
 Todas las flechas de salida de una compuerta exclusiva deben estar nombradas con una
etiqueta.
 Cuando se tienen decisiones se debe tener una tarea previa a la compuerta, en donde se
evalúe la decisión.  
 Para evitar que una compuerta sea convergente y divergente al mismo tiempo, se debe
utilizar una compuerta exclusiva convergente para sincronizar caminos que sean
excluyentes.
Nota: Aplica solo para el modelamiento de procesos ejecutables (de automatización). Para el
resto de los casos se omitirá la compuerta convergente, para procurar tener un diagrama más
liviano y de más fácil entendimiento para el cliente que no está acostumbrado a la notación.
 Relacionado con el punto anterior, No siempre es necesario utilizar una compuerta

convergente. En la siguiente imagen se aprecia que la compuerta no es necesaria ya que
no está previniendo que una compuerta divergente y convergente al mismo tiempo. Por lo
tanto, los dos diagramas son equivalentes. En estos casos no se diagrama la compuerta
para mantener liviano el diagrama.

INS-45-1-01-01
 Cuando se usan decisiones es porque el flujo de las actividades siguientes varía de acuerdo
a la decisión.  
 Las compuertas anidadas referentes a la misma pregunta, como la que se muestra en la

siguiente imagen, no se utilizarán. En su defecto se utilizará una sola compuerta donde la
pregunta tiene tres caminos de respuesta. Solo se usarán “Sí” y “No” como respuestas a
una compuerta cuando, efectivamente estas dos, sean las respuestas a la pregunta que se
ha realizado.
Incorrecto Correcto
o El uso de dos compuertas anidadas, para los casos en que cada compuerta evalúe
condiciones de negocio distinto, está permitido. Lo que no se debe hacer es usar

INS-45-1-01-01
compuertas anidadas para hacer la misma pregunta acerca de la misma condición

de negocio.
 No confundir las reglas que determinan cambios en el flujo, con condiciones que deben
ser cumplidas dentro de las actividades.
 Cuando en el proceso se requiere retornar para evaluar nuevas condiciones, se debe tener
en cuenta en donde son registradas las decisiones, para que el retorno se realice en el
punto adecuado.
3.6.3. Compuerta Exclusiva Basada en Eventos

Es una compuerta exclusiva pero la decisión de la ruta a tomar no depende de los datos del
proceso como en la exclusiva basada en datos, sino que depende de eventos que ocurren en el
proceso.
 Divergencia: Se utiliza para ejercer un control sobre la ejecución de ciertas actividades en

la medida que permite mantenerlas disponibles hasta que una de ellas es ejecutada. Por lo
tanto, sólo una puede ocurrir.

INS-45-1-01-01
Nota: No existe una compuerta convergente por la naturaleza de la compuerta. Una vez se active
una rama del proceso las otras ramas deben quedar deshabilitadas.
A continuación se muestra un ejemplo de uso de la compuerta.
En este ejemplo se muestra el caso que el cliente envíe o adjunte la documentación requerida,
ésta se cargará en el sistema y éste le enviará un mensaje de “Llegada” de documentos al proceso.
En este caso el proceso continuará por la ruta de verificar documentos y descartará la otra ruta
automáticamente. Si por el contrario el Tiempo de Espera de Documentos de 5 días se termina, el
proceso avanzará automáticamente hacia la actividad “Contactar Cliente” para mirar que ha
pasado con la documentación que no ha llegado. Nótese que ante las dos situaciones se está
respondiendo a eventos que pasan, esa es la naturaleza de esta compuerta, responder a eventos.
A esta compuerta no se le asigna ningún nombre y su comportamiento depende de los eventos

que sucedan.
Recomendaciones de uso de Compuerta Exclusiva Basada en Eventos

 No asignar nombre a la compuerta.
3.6.4. Compuerta Inclusiva

Una compuerta inclusiva se utiliza cuando en un punto se activan uno o varios caminos del flujo.
 Divergencia: Se utiliza cuando en un punto se activan uno o varios caminos (decisión

basada en datos del sistema).
 Convergencia: Es utilizada para sincronizar caminos activados previamente por una
compuerta inclusiva divergente.

INS-45-1-01-01
Recomendaciones de uso Compuerta Inclusiva

 Al igual que las compuertas paralelas trabajan en pareja con lo cual los caminos que
surgen de una compuerta inclusiva de deben cerrar con otra igual.
 La compuerta divergente será nombrada sólo cuando sea estrictamente necesario para el
entendimiento del proceso. La compuerta divergente no requiere ser nombrada.
 Todas las flechas que salen de la compuerta divergente deben estar nombradas, tal como
se hace con las compuertas exclusivas.
 Dos o más condiciones que salen de una compuerta, no deben llegar a la misma actividad,
sino que se incluyen en la etiqueta del flujo que llega a la mima actividad. En el ejemplo,
la etiqueta del flujo puede quedar “Requiere verificación o no es cliente del banco”.

INS-45-1-01-01
3.6.5. Compuerta Compleja

El uso de esta compuerta se limita a la necesidad de modelar reglas complejas de negocio, que no
pueden ser modeladas a través de las compuertas presentadas anteriormente.
 Divergente: Es utilizada para controlar puntos de decisión complejos.

 Convergente: Permite continuar al siguiente punto del proceso cuando una condición de
negocio se cumple.
En este ejemplo, la actividad de desembolso puede variar dependiendo de los tipos de

aprobaciones que hayan sido efectuadas en esas actividades. Este es un patrón de modelamiento
típico de mezcla de N/M casos.
3.7. Modelaje de Datos

Un requerimiento para el modelaje de procesos, es tener la posibilidad de modelar ítems (físicos o
de información) que son creados, manipulados y usados durante la ejecución de un proceso. Un
aspecto importante de esto es la capacidad de capturar la estructura de los datos, para consultar o
manipular esa estructura. Esto se logra mediante la utilización de varios elementos, algunos de los
cuales serán presentados a continuación.
3.7.1. Data Objects

Proporciona información acerca de cómo se utilizan y actualizan documentos, datos y otros
objetos durante el Proceso.

INS-45-1-01-01
 Los Data Objects deben estar contenidos dentro del proceso o subproceso.
 Los Data Objects se muestran visualmente en un diagrama de flujo.
Asociación de Datos
Asociaciones de datos son usadas para mover datos entre Data Objects, entradas y salidas de
actividades, procesos. A continuación se presenta un ejemplo de dos formas equivalentes de
mostrar la asociación de datos.
Nota: A pesar de ser formas equivalentes, el estándar manejado por la Dirección de Planeación y
Evaluación es el de la derecha, debido a que se considera más sencillo de entender visualmente.
Recomendaciones de uso de Data Objects

 Se debe tener en cuenta la dirección de la línea de asociación del Data Object y la
actividad. Por ejemplo, en la actividad registrar solicitud se hace una asociación con el
documento que se genera al realizar la actividad. Si la flecha va en sentido de la Actividad
al Objeto significa que la Actividad crea, genera produce el Objeto de Negocio, pero si la
flecha va en sentido del Objeto hacia la actividad, significa que la Actividad utiliza el
Objeto.
 El conector se coloca saliendo de la actividad (lado derecho centro) y se oculta con el

conector de flujo de secuencia.
 Cuando se tienen varios documentos que salen de una misma actividad, estos deben
nombrarse precedidos de un guion corto “-“, como se muestra a continuación.

INS-45-1-01-01
 Si es un insumo se conecta directamente a la actividad con un link con flecha. Hay que
tener en cuenta que un instructivo NO se debe colocar como insumo en el diagrama de
flujo, pero si en el momento de la modelación hay información relevante que se requiera
pero no se especifica en la entrada del proceso si se puede colocar. Por ejemplo, en el
proceso de adquisición de una tarjeta de crédito la información de la SIFIN.
3.7.2. Data Stores

Proporciona un mecanismo para que las actividades puedan recuperar o actualizar información
guardada previamente, de manera que esta exista más allá del alcance del proceso y esté
disponible para otros procesos.
 La forma de asociar los Data Stores al flujo es idéntica a la presentada con los Data
Objects.
3.8. Recomendaciones para la Automatización de Procesos

 Usar un “pool” para diferenciar cada proceso. Se debe tener en cuenta que los procesos se
comunican por medio de mensajes y en el caso que un diagrama contenga varios
procesos, estos deben ir en “pools” separados. De igual manera, identificar y documentar
los subprocesos que van a ser automatizados y los que no.
 Los “lanes” representan los roles funcionales que ejecutan el proceso y funcionan sólo en
el ámbito del mismo. Por lo tanto, no es recomendable usar nombres de áreas funcionales
o cargos, ya que no sería clara la responsabilidad de las personas de los actores del
proceso en las actividades en las que participan.
 Para los procesos que se quieren automatizar, las actividades y algunos eventos se
traducen en pantallas de formularios web que reciben y muestran información específica
dependiendo del rol que la ejecuta. Debido a esto, en el momento de diagramar y
describir una actividad, se debe pensar en la forma en que un usuario diligencia y recibe

INS-45-1-01-01
los datos que requiere guardar o consultar durante la ejecución del proceso. Por lo tanto,
se debe hacer la descripción funcional de la pantalla a nivel de todos los datos que va a
mostrar y recopilar (cuadros de texto, listas de valores, campos y criterios de búsqueda,
etc.). Para lograr el diseño del formulario esperado se pueden usar herramientas como:
Evolus Pencil o Cacoo.
 Se deben identificar las actividades automáticas o de integración con otros sistemas y

marcar como tipo de actividad de servicio (ver 3.3.4). Estas actividades describen la
necesidad de información desde y para los sistemas legados de la Universidad; es
importante enfocarse en los datos que se requieren (entidades y detalle de campos) y no
en el origen de los mismos, ya que en las etapas de diseño se evalúa la mejor fuente de
información según las necesidades de los usuarios. Adicionalmente, se debe describir la
frecuencia, la concurrencia, si se hace en línea o son periódicas estas comunicaciones.
o Ejemplo: En el caso de necesitar los datos de un empleado, enfocarse en la
información requerida y no en que se deben traer los datos de SAP, ya que según
los datos la fuente puede ser la bodega de datos, Academia, SAP ERP, etc.
 Se deben identificar las actividades del proceso que generan notificaciones y/o
documentos (.pdf, .doc, .xls, etc.). Estas actividades se deben marcar como tipo de
actividad script. En caso de la generación de documentos, se debe especificar el formato,
la plantilla o lineamientos para la construcción del mismo, los datos que va a contener, el
uso o no de firmas digitalizadas y firmas digitales, la frecuencia y uso de los mismos
durante la ejecución del proceso y después de haber finalizado. Asimismo se debe validar
si será un documento que requiere tener asociada una metadata, para su posterior
almacenamiento en un gestor documental. Para los casos de notificaciones de correo,
revisar si estas generan o no documentos, las plantillas o formatos a usar, los remitentes,
las copias, los destinatarios y la información dinámica que se enviará en el cuerpo del
mensaje.
 Hacer simulaciones manuales (pruebas de escritorio) del proceso con casos reales para
evaluar el alcance de las actividades, los casos de excepción y los flujos normales de
trabajo.
 Todos los procesos deben tener eventos de cancelación. Esta es una buena práctica en
caso que se quiera cancelar el flujo del proceso por motivos no contemplados o por casos
de excepción particulares.

INS-45-1-01-01
3.8.1. Entidades
 Es importante identificar la unidad básica del proceso (entidad central de información), ya
que todas las reglas de negocio estarán sujetas a esta unidad para mantener la
trazabilidad de la misma durante todo el proceso.
o Ejemplo: en el caso de las homologaciones, la entidad principal es el curso a
homologar más no la solicitud del estudiante.
 Todo proceso tiene una Entidad de Proceso principal. La entidad provee un punto de
acceso al resto de la información del proceso. Solamente existe UNA Entidad de Proceso
por proceso y siempre debe ser una entidad maestra.
 Para identificar entidades hay que definir los principales objetos que interesan al usuario.
Estos objetos serán las entidades. Una forma de identificar las entidades es examinar las
especificaciones de requisitos de usuario. En estas especificaciones se buscan los nombres
como número de empleado, nombre de empleado, número de inmueble, dirección del
inmueble, alquiler, número de habitaciones, etc. También se buscan objetos importantes
como personas, lugares o conceptos de interés, excluyendo aquellos nombres que sólo
son propiedades de otros objetos.
o Ejemplo: se pueden agrupar el número de empleado y el nombre de empleado en
una entidad denominada empleado, y agrupar número de inmueble, dirección del
inmueble, alquiler y número de habitaciones en otra entidad denominada
inmueble.
 Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí
mismos.

INS-45-1-01-01
o Ejemplo: empleado es una entidad porque los empleados existen, sepamos o no

sus nombres, direcciones y teléfonos.
3.8.2. Reglas de Negocio

 Los procesos de negocio se rigen por reglas que garantizan una adecuada ejecución de
acuerdo a las estrategias, objetivos y filosofía de la organización. Las reglas de negocio
establecen los procedimientos que deben ser ejecutados y las condiciones que deben ser
evaluadas y controladas en el flujo de Proceso.
 Se pueden definir reglas de negocio para:

o Direccionar flujos de Proceso: Controlar el flujo de secuencia para definir el
camino que debe seguir el Proceso de acuerdo a condiciones de negocio
específicas.
 Ejemplo: Si una solicitud de viaje fue aprobada se debe proceder a hacer
las reservas respectivas, de lo contrario, se debe notificar el rechazo.
o Realizar acciones en Actividades: Ejecutar los procedimientos necesarios al realizar
una tarea, tales como validaciones y cálculos.
 Ejemplo: Cuando un empleado reporta los gastos incurridos en un viaje, el
valor total de estos debe ser calculado automáticamente).
o Manipular interfaces de usuario: modificar los controles de una forma (visibles,
requeridos o de solo lectura) para evitar errores en la información ingresada en el
proceso.
 Ejemplo: Si una solicitud de viaje es rechazada, el control de comentarios
de rechazo debe mostrarse en la forma, de lo contrario, debe ocultarse.
o Asignar usuarios: Definir las condiciones que un usuario debe cumplir para poder
ser asignado a una tarea.
 Ejemplo: Si una queja se relaciona a facturación, debe ser atendida por un
agente de servicio al cliente especializado en quejas de facturación.
4. DEFINICIONES
 BPM: Business Process Management (BPM) por sus siglas en ingles. Es una metodología
corporativa y disciplina de gestión, cuyo objetivo es mejorar el desempeño (eficiencia y
eficacia) y la optimización de los procesos de negocio de una organización, a través de la
gestión de los procesos que se deben diseñar, modelar, organizar, documentar y optimizar
de forma continua.

INS-45-1-01-01
 BPD: Business Process Diagram (BDP) por sus siglas en ingles. Es un diagrama diseñado
para ser usado por los analistas de procesos, quienes diseñan, controlan y gestionan los
procesos.  Un BPD puede contener varios procesos.
 BPMN: Business Process Model and Notation (BPMN) por sus siglas en ingles. Es una
notación gráfica estandarizada que permite el modelado de procesos de negocio, en un
formato de flujo de trabajo. El principal objetivo de BPMN es proporcionar una notación
estándar que sea fácilmente legible y entendible por parte de todos los involucrados e
interesados del negocio (stakeholders). Entre estos interesados están los analistas de
negocio (quienes definen y redefinen los procesos), los desarrolladores técnicos
(responsables de implementar los procesos) y los gerentes y administradores del negocio
(quienes monitorizan y gestionan los procesos).
 BPMS: Business Process Management System (BPMS) por sus siglas en ingles. Es una
solución tecnológica que apoya la estrategia de BPM en la organización.
 Entidad: En bases de datos, una entidad es la representación de un objeto o concepto del

mundo real que se describe en una base de datos. Una entidad se describe en la
estructura de la base de datos empleando un modelo de datos. Por ejemplo, nombres de
entidades pueden ser: Alumno, Empleado, Artículo, etc. Cada entidad está constituida por
uno o más atributos. Por ejemplo, la entidad "Alumno" podría tener los atributos: nombre,
apellido, año de nacimiento, etc.1
 Metadata: Se puede definir Es data que describe otra data. Es información que describe el
contenido un archivo u objeto. Por ejemplo, una imagen digitalizada de una orden de
compra es la data. La descripción de este documento, como lo es el número de la orden de
compra, dirección física, nombre a quien va dirigido, fecha, etc.2
 Token: Es un objeto "teórico o abstracto” que se utiliza para simular el comportamiento

del proceso en ejecución.  Se debe tener en cuenta que:
o Se representa la secuencia del proceso mediante tokens que viajan o no viajan por
los flujos de secuencia, y a través de las actividades, las compuertas y los eventos.
o Cuando inicia un proceso se crea un token, y dependiendo de la naturaleza de los
objetos del flujo los tokens se ejecutan instantáneamente, se retrasan, se
multiplican o se unen (convergen en uno solo).
 Por ejemplo, cuando se llega a una compuerta paralela divergente, el
token se divide y se ejecutan distintos caminos del mismo proceso de
1 Tomado de http://www.alegsa.com.ar/Dic/entidad.php#sthash.VEkyfWsa.dpuf.
2 Tomado de http://www.digitalika.com/2010/07/metadata-definicin-de-hoy/.

INS-45-1-01-01
manera simultánea. De manera análoga, cuando los tokens llegan a un

compuerta paralela convergente, los tokens van a converger y formar uno
solo, que avanzara tan pronto como lleguen todas las instancias activadas.
o Los tokens no fluyen a través de asociaciones de datos, por lo tanto, estas
asociaciones no tienen efecto directo en el flujo del proceso. 
5. DOCUMENTOS DE REFERENCIA
INTERNOS (Cadena de Valor) EXTERNOS (Unidad académica, administrativa, entidad)
FOR-45-1-01-10 Descripción de Actividades de

BPMN V2.0
Automatización
6. CONTROL DE CAMBIOS
VERSIÓN ACTUALIZACIÓN FECHA

Elaboración 27/10/2015
0
Publicación 18/01/2016
7. APROBACION
NOMBRE CARGO FECHA
Coordinador de Procesos de
ELABORÓ Alberto Poveda Caputo 27/10/2015
Planeación y Efectividad
Manuela Peña Ingeniera de Procesos 30/10/2015
Lucrecia Ulloa Ingeniera de Procesos 04/11/2015

REVISÓ
Angélica Rodríguez Ingeniera de Procesos 05/11/2015
María Paula Sánchez Ingeniera de Procesos 09/11/2015

Jefe de Planeación y Efectividad
APROBÓ Carlos Castellanos 22/12/2015
Institucional
8. ANEXOS
No aplica.

INS-45!1!01-01 Modelamiento de Procesos Con BPMN1

Cargado por

Copyright:

Formatos disponibles

INS-45!1!01-01 Modelamiento de Procesos Con BPMN1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

INS-45!1!01-01 Modelamiento de Procesos Con BPMN1

Cargado por

Copyright:

Formatos disponibles

Modelamiento de Procesos con BPMN

Dirección de Planeación y Evaluación |1

3.6.1. Compuerta Paralela .................................................................................................... 20

Dirección de Planeación y Evaluación |2

 Documentación de procesos que hacen parte de la cadena de valor.

3.1. Reglas Generales para el Modelamiento de Procesos

3.1.2. Nivel de uso de Notación BPMN

 Descriptivo: El nivel descriptivo es utilizado para la documentación de los procesos de la

Dirección de Planeación y Evaluación |3

o Puede omitir detalles como caminos de excepción y validaciones

3.1.3. Utilización de Pools, Lanes y Fases

Dirección de Planeación y Evaluación |4

3.1.4. Orientación del Diagrama

Dirección de Planeación y Evaluación |5

3.1.5. Anotaciones y Grupos

Dirección de Planeación y Evaluación |6

3.2. Objetos de Conexión

Patrón Básico de Control de Flujo – Secuencia

3.2.2. Línea de Mensaje

 Representan Señales o Mensajes.

Nota: Según el estándar establecido por la Dirección de Planeación y Evaluación, no se utilizará

Dirección de Planeación y Evaluación |7

3.2.3. Línea de Asociación

Dirección de Planeación y Evaluación |8

 No representa un estado, función o evento.

3.3.1. Actividad ‐ Usuario

Dirección de Planeación y Evaluación |9

3.3.2. Actividad ‐ Manual

3.3.3. Actividad ‐ Script

3.3.4. Actividad ‐ Servicio

3.3.5. Actividad ‐ Envío

3.3.6. Actividad ‐ Recepción

3.3.7. Actividad ‐ Regla de Negocio

Recomendaciones de uso de Actividades

Dirección de Planeación y Evaluación | 10

La representación del subproceso puede ser:

Los procesos colapsados deben tener un evento de inicio y uno de finalización.

 Para cumplir el objetivo de modelar procesos ejecutables, se cuenta con tipos de

 No puede contener pools, ni áreas funcionales

Dirección de Planeación y Evaluación | 11

Proceso padre y subprocesos embebidos

Dirección de Planeación y Evaluación | 12

Recomendaciones de uso de Subprocesos

Dirección de Planeación y Evaluación | 13

Existen tres tipos de eventos dependiendo de la forma en la que afecta el flujo:

3.5.1. Eventos de inicio

Inicio por Mensaje

 Inicio de un proceso que es activado cuando se recibe un mensaje.

Dirección de Planeación y Evaluación | 14

Inicio por Condición de Tiempo

 Ejemplo: cada 10 de diciembre se abren los plazos para la inscripción de materias en el

Inicio por Señal

3.5.2. Eventos intermedios

 Si el evento que está esperando no ocurre, el proceso nunca avanzará.

Dirección de Planeación y Evaluación | 15

Evento Intermedio sin Especificar

Evento Intermedio de Enlace

 Envío (throw): Desde donde parte el flujo.

Evento Intermedio de Mensaje

 Envío (throw): Lanza un mensaje y continúa el flujo del proceso.

 Representan Señales o Mensajes.  