✒️ABAP / Los Agentes y la Estructura Organizativa Por Jhon Cano Pineda

Lección 6:

1 Que es un agente:

Es la persona que ejecuta el trabajo a realizar en el WorkFlow.

Cada WorkItem (entendiendo por WorkItem a la instancia en tiempo de ejecución de un paso del WorkFlow) puede ser proceso por:

ü El sistema de WorkFlow, utilizando el usuario WF-BATCH.

ü un agente.

Las agentes son los encargados de ejecutar tareas que no pueden ejecutarse automáticamente.

Una de las tareas más interesante y normalmente, una de las que más tiempo consume en el momento de definir un Workflow es como el sistema ha de seleccionar a los agentes correctos para la ejecución de cada WorkItem.

Desde la perspectiva de negocio esto no es trivial, particularmente cuando es un nuevo proceso que no ha sido llevado a cabo por nadie anteriormente.

Audio tips: enviar los WorkItem a los agentes responsables, constituye en 50% de la labor de la determinación de responsables, tener una estrategia para mantener la asignación de responsables minimizando el impacto de las tareas organizacionales y la fluctuación del personal representa el otro 50%

2 Asignación de agentes.

El sistema de Workflow deberá trabajar con grupos de agentes para poder determinar los responsables finales de la ejecución de un WorkItem.

Cuando estamos diseñando, implementando y manteniendo un Workflow, debemos entender como el sistema de Workflow ve estos grupos de agentes.

Los grupos de agentes son:

Agentes posibles: son quienes están permitidos para ejecutar el trabajo, siempre se asigne en la tarea según la cual se basaran muchos WorkItem pero no un WorkItem específico en sí mismo.

Si una persona no está en el grupo de agentes posibles entonces nunca podrá ejecutar la tarea. Adicionalmente se puede marcar una tarea como general. En esta caso todos los usuarios serán posibles agentes de la tarea.

Agentes responsables: son aquellos que queremos que ejecuten un WorkItem en particular. Son comúnmente asignados al crear un paso en el Workflow builder.

También puede ser asignados a través de roles o papeles, a nivel de la tarea. Como los roles agentes responsables se asignan dinámicamente en tiempo de ejecución. Siempre son agentes posibles.

Agentes excluidos: son aquellos que no queremos que ejecuten un WorkItem en particular. Siempre se definen en el WorkFlow builder al crear un paso para una tarea.

Estos tres grupos pueden solaparse e Interseccionarse para poder determinar el agente responsable final.

3 Receptores:

Son aquellos que automáticamente reciben un WorkItem en su inbox cuando el WorkFlow crea el WorkItem. También son conocidos como agentes seleccionados.

Los receptores son:

ü los posibles agentes para una tarea

ü restringiros a las listas de agentes responsables para un WorkItem.

ü No son miembros de la lista de agentes excluidos.

Debemos tener en cuenta:

ü Si no hay agentes posibles NADIE recibirá el WorkItem.

ü Si no se define un agente responsable en el paso, el sistema buscara la regla por defecto de la tarea, si no hay reglas todos los posibles agentes recibirán el WorkItem (excluyendo a los agentes excluidos).

Un receptor podrá hacer un reenvió de un WorkItem a otro usuario. En esta caso existen varias posibilidades:

Ø Tarea general: (General Task): los WorkItem podrán ser reenviados a cualquier usuario.

Ø Transmisión general permitida (General Forwarding): los WorkItem podrán ser reenviados a cualquier (pero existe una lista de agentes posibles).

Ø Transmisión general no permitida (No general Forwarding): los WorkItem solo podrá ser reenviados a los agentes posibles.

Ø Prohibido transmitir: no está permitido reenviar WorkItem.

Las posibilidades de renvió las definiciones dentro de la tarea, cuando determinemos los agentes posibles.

4 Otros agentes:

Agente actual: es el que está procesando el WorkItem

Una vez completado el WorkItem, el agente actual será el que haya procesado el WorkItem en último lugar.

Asignación múltiple: puede darse el caso que se envié un mismo WorkItem a varios receptores.

Cuando uno de los agentes tome el WorkItem este desaparecerá del Inbox del resto y en caso que lo vuelva a dejar son tomar volverá a aparecer a todos los usuarios nuevamente.

Agentes para plazos: son aquellos que reciben los WorkItem que haya vencido.

Agentes de notificación: son aquellos que recibirán un correo electrónico informándoles que determinado WorkItem ha sido ejecutado satisfactoriamente.

5 Estructura Organizativa en la asignación de agentes

Cada agente en el sistema de Workflow debe tener un User ID de SAP.

Cada vez que se esté asignado un agente posible, responsable o exclusivo estaremos asignando de manera implícita un usuario SAP.

Mantener usuario por usuario todos los agentes es una tarea excesivamente tediosa dado que puede existir múltiples WorkFlow, múltiples usuarios, etc. A su vez no debemos olvidar que lo usuarios son personas y como tal van cambiando de puesto, se van de la empresa, entran nuevos Etc.

Siempre que sea posible debemos mantener la asignación de usuarios a WorkFlow a través de un plan organizacional o estructura organizativa.

6 El plan organizacional básico

El plan organizacional básico consiste en una serie de relaciones, representa como una estructura organizativa jerárquica entre diferentes elementos organizaciones tales como:

Ø Unidad Organizativa: cada unidad organizativa representa un grupo de personas como un equipo, un departamento, una sección, una área de trabajo, un laboratorio etc.

Ø Trabajos: un trabajo describe un rol funcional dentro de la organización

Ø Posiciones: cada posición representa un lugar a ocupar por una persona, es un escritorio físico o una vacante.

Ø Usuarios: es el usuario SAP que se asigna a la posición

La mayoría de los objetos organizativos tienen un código, una descripción y un periodo de validez. Por defecto el periodo de validez se asigna con la fecha del día l aceración del objeto y como fecha de vencimiento será 31 de diciembre 999. No obstante el periodo se puede cambiar.

Transacciones de gestión Organizativa: Los objetos organizativos y sus relaciones se mantienen a través de las transacciones de gestión organizativa PPOM, PPOMW y PPOCW

7 Mantenimiento del plan organizacional básico

Para crear un plan organizacional o estructura organizativa ingresamos a la transacción PPOCW y se selecciona fecha de validez.

Creación de la unidad Organizativa

Presionamos el botón crear, selecciona la unidad organizativa, código, descripción y periodo validez.

Creación de la función: tratar – crear funciones, ingresa código y descripción

Y ingresamos un código y una descripción

Creación de una posición: código, descripción, función y si la posición es o no el máximo responsable de una unidad organizativa, validez.

Asignar un usuario: sobre la posición y presiona asignar

Luego seleccionar titular, elegimos un usuario

Finalmente se cambia la descripción de la posición.

Audio Tips: cuando se crea por primera vez la estructura organizativa el sistema nos genera una orden de transporte, cuando se modifique la estructura cambiando de objetos existentes o cambiando nuevos también solicitara una orden de transporte, no obstante podemos transportar a otros ambientes toda la estructura organizativa o parte de ella utilizando una herramienta que posee el sistema para tal fin, esta corresponde a la transacción estándar RE_RHMOBE30