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

Transcripción

1 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 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.

2 Nombre 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 Flujo por defecto Flujo condicional Define el orden de ejecución entre dos actividades Camino a seguir si no existe alguna condición que genere un camino alternativo. 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 Puerta Exclusiva Puerta basada en eventos Puerta paralela Indica cuando se llega a la compuerta el flujo solo toma una de los posibles caminos a partir de ese punto. Se activa dado un evento, usualmente es seguido de una actividad que atrape estos eventos. Determina el comienzo de dos flujos en paralelos dentro del proceso

3 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 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.

4 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.

5 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.

6 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 Actividad Interactiva Actividad <Tipo de Actividad y nombre> < de la actividad documentada> Rol <Rol responsable del cumplimiento de esta actividad> Tipo de Implementació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>

7 Entradas <Define las precondiciones del proceso> Salidas <Define las pos condiciones del proceso> Permisos <> Compuerta Compuerta <Tipo de Compuerta, y nombre> <Resumen de la razón de ser de la compuerta> Flujo de Secuencia Destino Condición < del flujo, de ser tomado> < del flujo, de ser tomado> <Referencia a la siguiente actividad> <Referencia a la siguiente actividad> < de la condición que debe ser cumplida para que el flujo tomado sea este> < 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 Tipo de Dato Trazabilidad Formato/T amaño Editable Requerido Comentarios <Nombre del atributo de la pagina> <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> 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. <Resumen de la razón de ser de este campo> De los botones se recomienda documentar la información que aparece en el siguiente formato.

8 Nombre Acción Validaciones <Etiqueta del botón> < del evento que se dispara al interactuar con este botón> <precondiciones que deben ser cumplidas para que la interacción con este botón sea válida>