✒️ABAP Los Agentes y la Estructura Organizativa
ABAP Los Agentes y la Estructura Organizativa
AGENTES Y ESTRUCTURA ORGANIZATIVA
1.- Què es un Agente:
Es la persona que ejecuta el trabajo a realizar en el workflow.
Cada workitem (se entiende por workitem a la instancia en tiempo de ejecuciòn de un paso del workflow) puede ser procesado por:
- El sistema de workflow, utilizando el usuario WF-BATCH
- Un agente.
Los agentes son los encargados de ejecutar tareas que no pueden ejecutarse automàticamente.
Una de las tareas màs interesantes y normalmente, una de las que màs tiempo consumen en el momento de definir un workflow es còmo 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.
Enviar los workitems a los agentes responsables correspondientes, constituyen en el 50% de la labor de la determinaciòn de responsables, tener una estrategia para asignar los responsables minimizando el impacto de los cambios organizacionales y las fluctuaciones del personal constituyen el otro 50%.
2.- Asignaciòn de agentes.
El sistema de workflows 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 asignan en la tarea segùn la cual se basaràn muchos workitems 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 este 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 pueden ser asignados atravès de "roles o papeles" a nivel de la tarea, Con los roles los 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 "e 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 e workflow crea el workitem.
Tambièn son conocidos como agentes "seleccionados".
Los receptores son:
- Los posibles agentes para una tarea.
- Restringidos a las listas de agentes responsables para un workitem.
- No son miembros de la lista de agentes excluidos.
Debemos tener en cuent que:
- Si no hay agentes posibles NADIE recibrà el workitem.
- Si no se define un agente responsable en el paso, el sistema buscarà la regla por defecto de la tarea, si no hay regla todos los posibles agentes recibiràn el workitem (excluyendo a los agentes excluidos).
Un receptor podrà hacer un reenvìo de un workitem a otro usuario. En est caso existe varias posibilidades:
- Tarea general (General Task): Los workitems podràn ser reenviados a cualquier usuario.
- Transmisiòn general permitida (general Forwarding): los workitems podràn ser reenviados a cualquier usuario (pero existe una lista de agentes posibles).
- Transmisiòn general no permitida (No general Forwarding): los workitems solo podràn ser reenviados a los agentes posibles.
- Prohibido transmitir: no està permitido reenviar workitems.
Las posibilidades de reenvìo las definimos dentro de la trea, cuando determinamos los agentes posibles.
4.- Otros Agentes:
- Agente actual: Mientras que un workitem se estè procesando el agente actual es aquel que este procesando el workitem (lo tiene tomado).
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 (y es muy comùn) que se envìe un ismo 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 sin tomar volverà a aparecer a todos los usuarios nuevamente.
- Agentes para plazos: son aquellos que recibiràn un workitem que haya vencido, es decir que se le fijò un plazo y el plazo se alcanzò.
- 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 asigne un agente posible, responsable o excluido estaremos asignando de manera implìcita u usuario SAP.
Mantener usuario por usuario todos los agentes es una tarea excesivamente tediosa dado que pùeden existir mùltiples workflows, mùltiples usuarios, etc. A su vez no debemos olvidar que los 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, representadas como una estructura organizativa jeràrquica entre diferentes elementos organizacionales tales como:
- Unidades Organizativas: cada unidad organizativa representa un grupo de persona como un equipo, un departamento, una secciòn, un àrea de trabajo, un laboratorio, etc.
- Trabajos: describe un rol funcional dentro de la organizaciòn.
- Posiciones: representa un lugar a ocupar por un a persona, es un escritorio fìsico o una vacante.
- Usuarios: es el usuario SAP que se asigna a a posiciòn.
La mayorìa de os objetos organizativo tienen un còdigo, una descripciòn y un perìodo de validez. Por defecto el perìodo de validez se asigna con la fecha del dìa de la creaciòn del objeto y como fecha de vencimiento serà 31 de diciembre de 9999 No obstante el perìodo se puede cambiar.
"Los objetos organizativos y sus relaciones se mantienen a travès de las transacciones de gestòn organizativa PPOM, PPOMW, PPOCW".
7.- Mantenimiento el plan organizacional Bàsico.
Para crear un Plan organizacional o Estructura organizativa: ingresamos a la transacciòn PPOCW y seleccionamos una fecha de validez.
Luego realizamos los siguientes pasos:
- Creaciòn de la unidad organizativa: para ello presionamos el botòn crear, selecconamos la unidad organizativa e indicamos un còdigo, una descripciòn y un perìodo de validez.
- Creaciòn de la funciòn: desde el menù seleccionamos "Tratar / crear fuciones". E ingresamos un còdigo y una descripciòn.
- Creaciòn de una posiciòn: colocamos el còdigo, la descripciòn, una funciòn y si la posiciòn es o nò el màximo responsable de la unidad organizativa. Tambièn podemos colocar la validez,
- Asignar usuario: nos ubicamos sobre la posiciòn y presionamos el botòn "Asignar".
Luego seleccionamos "titular" y elegimos un usuario.
Finalmente cambiamos la descripciòn de la posiciòn.
Cuando se crea por primera vez un estructura organizativa el sistema nos solicitarà una orden de transporte cuando se modifique la estructura cambiando objetos existentes, tambièn se nos va a solicitar una orden de transporte.
RE_RHMOVE30 (transacciòn)
Sobre el autor
Publicación académica de Miguel Angel Acosta Acosta, en su ámbito de estudios para la Carrera Consultor ABAP.
SAP Expert
Miguel Angel Acosta Acosta
Profesión: Ingeniero de Sistemas - Ecuador - Legajo: TF64C
✒️Autor de: 238 Publicaciones Académicas
🎓Egresado de los módulos:
- Carrera Consultor en SAP SD Nivel Avanzado
- Carrera Consultor en SAP SD Nivel Inicial
- Máster ABAP for HANA
- Carrera Consultor ABAP Nivel Avanzado
- Carrera Consultor ABAP Nivel Inicial
Disponibilidad Laboral: FullTime
Presentación:
Profesional de ingeniería de sistemas en computación e informática, con experiencia en la implantación y soporte de proyectos informáticos para empresas del sector industrial y financiero.
Certificación Académica de Miguel Acosta
