Responsibility Management

O Responsibility Management responde a uma pergunta para outros frameworks: quem é responsável por este objeto, neste momento?

1. A SAP entrega categorias de equipe (team categories), cada uma representando um processo de negócio, como Compras, junto com as funções de membros e as definições de responsabilidade que pertencem a ela.
2. Os clientes derivam tipos de equipe (team types) para subprocessos, por exemplo Compras Operacionais e Compras Estratégicas, e podem ocultar funções ou definições de que não precisam.
3. Os key users criam equipes no Manage Teams and Responsibilities, definem valores para as definições de responsabilidade, como o centro 1010 ou uma empresa, e adicionam membros com suas funções.
4. Um consumidor, como uma etapa de flexible workflow ou um tipo de situação, solicita os agentes de uma equipe ou de uma função para o objeto em questão.
5. O Responsibility Management compara os atributos do objeto com as equipes e retorna os usuários.

Como alternativa, regras de responsabilidade determinam agentes sem equipes. O Responsibility Management, portanto, transforma conhecimento organizacional em dados que workflows e alertas podem consultar.

As definições de responsabilidade e as funções são atribuídas à categoria de equipe da SAP e herdadas pelos seus tipos de equipe; os clientes podem adicionar definições de responsabilidade customizadas. As equipes também podem ser organizadas em hierarquias com o Manage Team Hierarchies. Uma equipe no Responsibility Management é, portanto, delimitada por atributos de negócio, não por um organograma.

• Flexible workflow: quando os key users definem os destinatários de uma etapa de workflow, cenários como ordens de manutenção oferecem atribuição por equipe, que envia a tarefa aos membros da equipe, ou atribuição por role, que seleciona os membros com uma determinada função. Em compras, a categoria Compras traz funções como Compras Estratégicas e Compras Operacionais.
• SAP Business Workflow: o business workflow é um tipo de contexto de responsabilidade, então os modelos de workflow podem determinar agentes por meio de regras do Responsibility Management.
• Situation Handling: cada tipo de situação determina destinatários por meio de equipes ou regras de responsabilidade.

Várias linhas de negócio fornecem seus próprios tiles do Manage Teams and Responsibilities, por exemplo para compras, gestão de ativos ou contabilidade de contratos, que abrem o mesmo framework com uma categoria de equipe predefinida. O Responsibility Management é a camada compartilhada de destinatários sob esses frameworks.

• Destinatários baseados em atributos: as responsabilidades seguem o centro, a empresa ou outras definições, de modo que uma única regra de workflow atende a muitas unidades organizacionais.
• Manutenção nas mãos do negócio: key users e responsáveis por equipes alteram membros em um app SAP Fiori, sem desenvolvimento e sem mexer nas definições de workflow.
• Reutilização entre frameworks: as mesmas equipes atendem aprovações e alertas de situação, então uma reorganização é mantida uma única vez.
• Extensível: definições de responsabilidade, funções e regras customizadas estendem os contextos da SAP, e a SAP documenta o transporte dessas extensões.
• Automonitoramento: um modelo da SAP para o Situation Handling informa os responsáveis por equipes quando membros que precisam aprovar tarefas estão indisponíveis.

Para aprovações e alertas do SAP S/4HANA, o Responsibility Management é a forma nativa de manter os destinatários alinhados ao negócio.

• Dentro de um único sistema SAP S/4HANA. As equipes vivem no sistema que as utiliza. Aprovadores em outras aplicações ou tarefas em outros sistemas precisam da sua própria lógica de destinatários.
• As equipes precisam coincidir em todo o landscape. Quando workflows que nomeiam equipes são transportados, a SAP exige que as equipes sejam idênticas em todos os sistemas, o que torna a manutenção de equipes parte do planejamento de releases. Um ID global de equipe, fixo depois de gravado, identifica a mesma equipe entre sistemas.
• Ele decide quem, não o quê. O Responsibility Management retorna agentes; as etapas, os prazos e as decisões pertencem ao workflow ou ao tipo de situação consumidor.
• A qualidade dos dados decide o resultado. Equipes vazias, membros desatualizados ou valores de definição ausentes geram tarefas sem agentes.

Esses limites são intencionais: o Responsibility Management mantém dados de responsabilidade, enquanto o desenho de processos acontece nos frameworks que os consomem.

1. Nomear pessoas nos workflows em vez de equipes. Cada reorganização passa a exigir a edição dos workflows; as equipes absorvem a mudança.
2. Equipes sobrepostas. Duas equipes que cobrem o mesmo centro com a mesma função tornam incerto quem é dono de uma tarefa; verifique como a regra de agentes do consumidor trata várias equipes correspondentes.
3. Lacunas de cobertura. Um centro sem equipe deixa tarefas sem agentes. Confira cada novo centro ou empresa com a lista de equipes.
4. Ignorar ausências. Ative a situação de membro de equipe indisponível para que os responsáveis por equipes possam substituir membros que não conseguem agir.
5. Esquecer o landscape. Equipes criadas apenas em desenvolvimento quebram workflows transportados em produção.

Quando uma tarefa ou situação não tem destinatário, verifique primeiro o escopo e as funções da equipe e, depois, as configurações de destinatário do consumidor. A maioria dos problemas de Responsibility Management são problemas de manutenção de dados que aparecem como tarefas ausentes.