Responsibility Management

Responsibility Management responde a una pregunta para otros frameworks: ¿quién es responsable de este objeto en este momento?

1. SAP entrega categorías de equipo, cada una de las cuales representa un proceso de negocio como Procurement, junto con las funciones de los miembros y las definiciones de responsabilidad que le corresponden.
2. Los clientes derivan tipos de equipo para subprocesos, por ejemplo Operational Purchasing y Strategic Purchasing, y pueden ocultar las funciones o definiciones que no necesitan.
3. Los key users crean equipos en Manage Teams and Responsibilities, establecen valores para las definiciones de responsabilidad, como el centro 1010 o una sociedad, y añaden miembros con sus funciones.
4. Un consumidor, como un paso de flexible workflow o un tipo de situación, solicita los agentes de un equipo o de una función para el objeto en cuestión.
5. Responsibility Management compara los atributos del objeto con los equipos y devuelve los usuarios.

Como alternativa, las reglas de responsabilidad determinan agentes sin equipos. Por tanto, Responsibility Management convierte el conocimiento organizativo en datos que los workflows y las alertas pueden consultar.

Las definiciones de responsabilidad y las funciones se asignan a la categoría de equipo de SAP y las heredan sus tipos de equipo; los clientes pueden añadir definiciones de responsabilidad personalizadas. Los equipos también pueden organizarse en jerarquías con Manage Team Hierarchies. Por tanto, un equipo en Responsibility Management se delimita por atributos de negocio, no por un organigrama.

• Flexible workflow: cuando los key users definen los destinatarios de un paso de workflow, escenarios como las órdenes de mantenimiento ofrecen la asignación por equipo, que envía la tarea a los miembros del equipo, o la asignación por rol, que selecciona a los miembros con una función determinada. En compras, la categoría Procurement aporta funciones como Strategic Purchasing y Operational Purchasing.
• SAP Business Workflow: el business workflow es un tipo de contexto de responsabilidad, de modo que las plantillas de workflow pueden determinar agentes mediante reglas de Responsibility Management.
• Situation Handling: cada tipo de situación determina los destinatarios mediante equipos o reglas de responsabilidad.

Varias líneas de negocio entregan sus propios tiles de Manage Teams and Responsibilities, por ejemplo para compras, gestión de activos o contabilidad de contratos, que abren el mismo framework con una categoría de equipo predefinida. Responsibility Management es la capa de destinatarios compartida bajo estos frameworks.

• Destinatarios basados en atributos: las responsabilidades siguen el centro, la sociedad u otras definiciones, de modo que una sola regla de workflow sirve a muchas unidades organizativas.
• Mantenimiento a cargo del negocio: los key users y los propietarios de equipos cambian los miembros en una aplicación SAP Fiori, sin desarrollo y sin tocar las definiciones de workflow.
• Reutilización entre frameworks: los mismos equipos sirven para aprobaciones y alertas de situación, de modo que una reorganización se mantiene una sola vez.
• Extensible: las definiciones de responsabilidad, funciones y reglas personalizadas amplían los contextos de SAP, y SAP documenta cómo transportar esas extensiones.
• Autosupervisión: una plantilla de SAP para Situation Handling informa a los propietarios de equipos cuando los miembros que deben aprobar tareas no están disponibles.

Para las aprobaciones y alertas de SAP S/4HANA, Responsibility Management es la forma nativa de mantener los destinatarios alineados con el negocio.

• Dentro de un único sistema SAP S/4HANA. Los equipos residen en el sistema que los usa. Los aprobadores en otras aplicaciones o las tareas en otros sistemas necesitan su propia lógica de destinatarios.
• Los equipos deben coincidir en todo el landscape. Cuando se transportan workflows que nombran equipos, SAP exige que los equipos sean idénticos en todos los sistemas, lo que convierte el mantenimiento de equipos en parte de la planificación de releases. Un ID global de equipo, fijo una vez guardado, identifica el mismo equipo en todos los sistemas.
• Decide quién, no qué. Responsibility Management devuelve agentes; los pasos, los plazos y las decisiones pertenecen al workflow o al tipo de situación consumidor.
• La calidad de los datos decide el resultado. Los equipos vacíos, los miembros desactualizados o los valores de definición que faltan producen tareas sin agentes.

Estos límites son intencionados: Responsibility Management mantiene los datos de responsabilidad, mientras que el diseño de procesos se realiza en los frameworks que los consumen.

1. Nombrar a personas en los workflows en lugar de equipos. Cada reorganización obliga entonces a editar workflows; los equipos absorben el cambio.
2. Equipos solapados. Dos equipos que cubren el mismo centro con la misma función difuminan quién es responsable de una tarea; compruebe cómo trata la regla de agentes del consumidor varios equipos coincidentes.
3. Huecos de cobertura. Un centro sin equipo deja tareas sin agentes. Compruebe cada nuevo centro o sociedad con la lista de equipos.
4. Ignorar las ausencias. Active la situación de miembro del equipo no disponible para que los propietarios de equipos puedan sustituir a los miembros que no pueden actuar.
5. Olvidar el landscape. Los equipos creados solo en desarrollo rompen los workflows transportados en producción.

Cuando una tarea o una situación no tiene destinatario, compruebe primero el ámbito y las funciones del equipo y después la configuración de destinatarios del consumidor. La mayoría de los problemas de Responsibility Management son problemas de mantenimiento de datos que aparecen como tareas que faltan.