Flujo de Control gestionado por humanos vs por sistemas
En concordancia con el post anterior, si realizáramos un proyecto de automatización de procesos para la gestión de incidencias; tendríamos que identificar en primer lugar que partes del proceso podrían ser automatizadas dentro de un motor de procesos y que otras son actividades humanas.
En este escenario decidimos que el gestor de cuenta de un cliente no debe ser molestado con formularios web o listas de tareas, sólo debe enviar un correo electrónico si quiere informar o reportar un problema y recibir un correo electrónico cuando haya terminado el proceso de atención.
La misma idea se aplica para el proveedor de software: Se asumen que el agente de segundo nivel de soporte se encuentra en el mismo espacio físico que los desarrolladores. Tal vez es más eficiente si el agente de soporte sólo se acerca a los desarrolladores y conversa sobre el tema, en lugar de jugar un tiempo de ping-pong para la asignación de tareas. Por lo tanto, queremos mantener esta parte del proceso de gestión de incidencias de forma manual, así: no existirá un motor de procesos para la colaboración entre el segundo nivel de soporte y los desarrolladores de software.
Pero queremos que la asignación de tickets para el 1er y 2do nivel de soporte se realice mediante un sistema de gestión de tickets, que tomara el papel o rol del motor de procesos y por lo tanto es modelado en un pool.
Este sistema de gestión de tickets puede recibir y analizar correos electrónicos enviados por el gestor de cuentas y abrir un ticket para este. Si el agente de primer nivel de soporte decide que este es un caso de 2 º nivel, lo hace documentando su decisión y completando la tarea asignada "Documentar resultado de incidencia". El sistema de gestión de tickets posteriormente enruta la entrada al agente segundo nivel de soporte. Cuando el agente ha terminado, este puede establecer que el error se solucionara en el siguiente lanzamiento de software (software release).
A continuación, el sistema de "trouble ticket" invoca un servicio en el sistema de gestión de productos “product backlog system”, para adicionar una nueva característica, necesaria para corregir el error identificado.
La entrada no tendrá que ser insertada manualmente. Al final, el sistema de gestión de tickets enviará un correo electrónico al gestor de cuentas, que contiene los resultados de la gestión de incidentes, y cierra el ticket. El gestor de cuentas podrá explicar la solución al cliente basado en la información del ticket.
Por supuesto, esta manera de modelar los flujos de procesos dirigidos por acciones humanas o sistemas en un diagrama es sólo un ejemplo sobre el uso de modelos y enfoques basados en diagramas de colaboración.
Para finalizar, es importante entender que podemos modelar nuestros procesos con tareas manuales o automatizadas. Esto nos da la oportunidad de hablar con los analistas de negocio o gerente de TI sin sobrecargar los procesos con detalles técnicos; muchas veces demasiado complejos e imprecisos.
No hay comentarios:
Publicar un comentario