Guía Metodológica para el diseño de procesos de negocio

Guía Metodológica para el diseño de procesos de negocio
La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el
desarrollo BPM, principalmente en aquellas que soportan el desarrollo en un ambiente particular
(como lo son la metodología de IBM y Oracle para sus respectivas suites BPM), aunque también se
apoya en modelos de referencia para el diseño de procesos de negocio generales (SCM maturity
model, modelos de Bowersox, Metz y Cooper, modelo CPFR, SCOR).
Esta guía tiene como objetivo definir como realizar el diseño de procesos de negocio, entiéndase
por modelado de procesos de negocio, la captura de la secuencia ordenada de actividades de un
negocio particular, para BPM esta captura se realiza sobre el estándar BPMN.
Dentro del desarrollo de software apoyado en suites BPM se identifican los siguientes roles.
Rol
Analista de Procesos
Desarrollador de Procesos
Administrador de negocio
Dueño del proceso
Participante del proceso
Descripción
Es la persona encargada de crear el flujo de
proceso y documentar sus pasos, esto también
implica que es la persona responsable por la
identificación y definición de los KPI.
Es la persona que desarrolla los procesos
documentados por el analista de procesos.
Encargado del funcionamiento de la suite BPM,
en él recae la responsabilidad de asegurar la
disponibilidad de la infraestructura BPM, y
también del manejo de usuarios, grupos,
unidades organizacionales etc.
En tiempo de ejecución, son los responsables
de que las instancias del proceso sean
ejecutadas de acuerdo a las reglas de negocio.
Usuarios de la aplicación generada con las
suites BPM
La ejecución de esta guía metodológica será llevada a cabo por el(los) analista(s) de procesos
1. Introducción BPM
BPMN
Es necesario que la(s) persona(s) que se disponen a diseñar los procesos de negocio estén
familiarizados con la notación estándar para procesos de negocio BPMN. La siguiente es una
introducción a la notación la cual debería ser suficiente para la mayoría de los proyectos BPM, de
no ser así referirse al sitio oficial de BPMN [referencia al sitio].
Actividades
Describen una tarea específica dentro de un proceso de negocio.
Nombre
Descripción
Tarea
Indica una unidad de trabajo dentro de un proceso
Transacción
Una secuencia de tareas que lógicamente van en
conjunto.
Sub-Proceso por evento
Un subproceso que se activa según un evento
determinado, puede ser bloqueante o correr en
paralelo.
Llamado a actividad
El llamado a actividad es un subproceso global
definido de una forma específica para su
reutilización
Conectores
Son los que definen una secuencia entre actividades, dándole sentido y estructura al proceso que
se está modelando
Flujo de secuencia
Define el orden de ejecución
entre dos actividades
Flujo por defecto
Camino a seguir si no existe
alguna condición que genere
un camino alternativo.
Flujo condicional
Tiene una condición asociada
que determina si el camino es
activado o no.
Compuertas
Las compuertas permiten el manejo de una secuencia de eventos, hace posible que exista una
clara coordinación entre actividades.
Nombre
Descripción
Puerta Exclusiva
Indica cuando se llega a la compuerta el flujo solo
toma una de los posibles caminos a partir de ese
punto.
Puerta basada en eventos
Se activa dado un evento, usualmente es seguido de
una actividad que atrape estos eventos.
Puerta paralela
Determina el comienzo de dos flujos en paralelos
dentro del proceso
Puerta Inclusiva
Se activan varios flujos y todos deben finalizarse
antes de combinarse nuevamente
Datos
A continuación se describe la manera en la que se modela la información y los datos que fluyen
entre procesos y grupos de procesos.
Nombre
Descripción
Entrada
Entrada de información externa
Salida
Salida de información del proceso completo que
puede ser accedido al exterior de este
Datos
Representa flujo de información al interior del
proceso
Colección de Datos
Representa un conjunto de información, como por
ejemplo una lista.
Almacenamiento
Representa un lugar donde el proceso puede leer y
escribir información
Mensaje
Representa la comunicación entre dos participantes
Proceso de negocio
En el contexto de esta guía, un proceso de negocio se ve como una serie de actividades con salidas
bien definida, que se ciñen a reglas de negocio determinadas.
Instancia de proceso
Define el estado de un proceso de negocio en el tiempo.
Muestra de proceso
Define el punto de la ejecución en una instancia de proceso, la existencia de puertas en un proceso
de negocio causa la posibilidad de múltiples muestras de proceso en una misma instancia.
2. Determinar los requerimientos de negocio
El levantamiento de requerimientos en este caso inicia en una exploración juiciosa al modo en el
cual trabaja la compañía que pretende hacer uso del sistema BPM.
Del mismo modo que participa la ingeniería de requerimientos en el desarrollo tradicional de
soluciones, en un desarrollo BPM es necesario definir los requerimientos del negocio, esta
definición comprende:



Priorización.
Evaluación.
Especificación.
La prioridad en esta guía metodológica está en función del aporte de un proceso a la cadena de
valor de una compañía, es decir, la influencia de un proceso de negocio en cuanto a los ingresos,
primero se deben implementar aquellos procesos de negocio con mayor impacto a la cadena de
valor, de modo que se evidencie el beneficio que BPM aporta al funcionamiento de una compañía
desde el primer proceso desarrollado.
Tradicionalmente este proceso se ve soportado por los KPI de una empresa, un KPI (Key
Performance Indicator) es una medida que permite evaluar el progreso de un objetivo dentro de
una actividad particular, esta evaluación actuaría como soporte de la utilidad de un proceso
soportado por BPM contrastando el modo en el que se realizaban las actividades previo al
desarrollo de la solución.
Como en un desarrollo tradicional, los requerimientos definen el alcance del desarrollo de
software, la especificación y aceptación de los requerimientos de negocio, conforman el contrato
que debe cumplir el desarrollo de una solución BPM.
3. Modelado en BPMN
Después de seleccionar el proceso de negocio que se optó por desarrollar, se inicia su modelado
en BPMN.
3.1 Captura del estado actual del proceso
Implica la traducción de las actividades de un proceso de negocio, del modo en el que se
realizaban antes del desarrollo BPM, en una notación BPMN, en este punto el objetivo es definir el
flujo que existe de una actividad a otra, la naturaleza de dichas actividades es preocupación de
puntos posteriores en la guía metodológica.
3.2 Identificación de Roles
Es recomendable que toda actividad sea
responsabilidad de un rol, BPMN permite la
definición de roles se mediante Swimlanes, su
representación gráfica son divisiones del diagrama
sean horizontales o verticales, cada división
contiene las actividades en las cuales interviene un
rol.
3.3 Inicio y Fin de una instancia de proceso
Un proceso de negocio, puede tener múltiples puntos de partida así como múltiples puntos de
salida, los diferentes flujos de un punto de partida a un punto de salida definen los escenarios de
un proceso de negocio.
3.4 Actividades interactivas
En este punto es necesario identificar aquellas tareas que requieran de la intervención de un
usuario, estas son actividades interactivas, estas actividades pueden ser manejadas por la suite
BPM seleccionada para el desarrollo, como por ejemplo si es un formulario que debe llenarse por
el usuario, o pueden ser actividades manuales fuera del control de BPM como la impresión o firma
de un documento.
3.5 Actividades Automáticas
Estas actividades representan toda tarea dentro de un proceso de negocio que puede ser
automatizada por la suite BPM, por ejemplo, servicios tales como el envío de mensajes,
notificaciones, comunicación entre procesos de negocio, la validación del cumplimiento de reglas
de negocio, etc.
3.6 Flujo de actividades
Para definir el flujo de actividades en BPMN son utilizados los conectores en conjunto con las
compuertas.
3.7 Modelado del proceso de negocio como debería ser
Implica la identificación y modificación de aspectos a mejorar que presenta el diagrama del
proceso de negocio en su estado actual, este proceso se recomienda sea supervisado por un
experto en el negocio que valide las decisiones que se tomen con respecto al diseño.
4. Recomendaciones al modelar
Los procesos de negocio pueden llegar a ser muy complejos, dependiendo del flujo o de la
cantidad de actividades que se lo componen, las siguientes son algunas recomendaciones para
que la representación de un proceso en BPMN sea simple, en términos de cantidad de actividades
y el flujo entre ellas.
4.1 Uso de Subprocesos
Esta técnica consiste en agrupar actividades de un proceso de negocio, y reducirlas a una actividad
en un nivel más alto de abstracción.
El objetivo es llegar a un máximo de actividades por diagrama BPMN.
Para realizar este proceso se debe tener en cuenta lo siguiente.


Los diferentes flujos de entrada a las actividades pertenecientes a este conjunto, que
provengan de actividades al exterior de este, se definen como puntos de partida para el
nuevo subproceso.
Los diferentes flujos de salida de actividades pertenecientes a este conjunto, que tengan
como destino actividades al exterior de este, se definen como puntos de salida para el
nuevo subproceso
Aparte de una reducción considerable en el tamaño de los diagramas, si la suite BPM lo soporta, el
mayor atractivo del uso de subprocesos es la reutilización de estos.
Por último, la división de procesos en una etapa posterior de implementación, facilita la división
de la carga de trabajo en los desarrolladores.
4.2 Documentación de las actividades.
Es recomendable que cada actividad posea una documentación detallada que será insumo para el
proceso de implementación, de modo que cada desarrollador cada vez que necesite información
acerca de la actividad que se encuentra desarrollando, no tenga que filtrar la información
concerniente a su actividad en un panorama general cada vez que lo necesite.
Se recomienda el uso de formatos como los siguientes para la documentación de actividades y
compuertas de un diagrama BPMN.
4.2.1 Actividad Interactiva
Actividad
<Tipo de Actividad y nombre>
Descripción
<Descripción de la actividad documentada>
Rol
<Rol responsable del cumplimiento de esta actividad>
Tipo de Implementación
<Descripción del modo en el que se implementará una actividad>
Expiración
<En caso de existir restricciones de tiempo para completar una actividad, estas se definen aquí>
Notificaciones
<Define las notificaciones que deben ser enviadas, y sus destinatarios al ejecutarse esta actividad>
Entradas
<Define las precondiciones del proceso>
Salidas
<Define las pos condiciones del proceso>
Permisos
<>
4.2.2 Compuerta
Compuerta
<Tipo de Compuerta, y nombre>
Descripción
<Resumen de la razón de ser de la compuerta>
Flujo de Secuencia
Destino
<Descripción del flujo, de ser
<Referencia a la siguiente
tomado>
actividad>
<Descripción del flujo, de ser
tomado>
<Referencia a la siguiente
actividad>
Condición
<Descripción de la condición
que debe ser cumplida para
que el flujo tomado sea este>
<Descripción de la condición
que debe ser cumplida para
que el flujo tomado sea este>
5. Simulación y Validación de pantallas
Por último es conveniente la generación de pantallas que simulen la interacción de los
participantes del proceso, de este modo se obtiene el visto bueno del usuario en términos de
usabilidad de las actividades interactivas en el proceso BPM, el diseño gráfico de las pantallas es
indiferente para esta guía metodológica, en cambio la documentación de los atributos de las
páginas de un proceso de negocio, puede ser de gran ayuda en el proceso de implementación,
entiéndase por atributo cualquier campo que brinde información o permita inserción o
modificación del modelo de datos que soporte la solución.
Para la documentación de los atributos de una página se recomienda contar al menos con los
datos que se muestran en el siguiente formato.
<Nombre de la pantalla>
Atributo
<Nombre del
atributo de la
pagina>
Tipo de Dato
Trazabilidad
Formato/T
amaño
Editable
Requerido
Comentarios
<Tipo de dato>
<referencia al
atributo del
modelo de
datos al que
este atributo
está
vinculado>
<restriccion
es en
cuanto a
tamaño o
formato del
campo>
<sí o no se
puede editar
el campo>
<sí o no es requerido
el campo al diligenciar
el formulario>
<Resumen de la razón de ser
de este campo>
También es recomendable la documentación de los botones de las pantallas, dado que estos
disparan acciones que han de ser desarrolladas en la etapa posterior al diseño.
De los botones se recomienda documentar la información que aparece en el siguiente formato.
Nombre
<Etiqueta del botón>
Acción
<Descripción del evento que se
dispara al interactuar con este
botón>
Validaciones
<precondiciones que deben ser cumplidas para
que la interacción con este botón sea válida>