Responsibility Management

Responsibility Management répond à une seule question pour les autres frameworks : qui est responsable de cet objet, en ce moment ?

1. SAP livre des catégories d'équipe, chacune représentant un processus métier comme Procurement, avec les fonctions de membre et les définitions de responsabilité qui lui appartiennent.
2. Les clients dérivent des types d'équipe pour les sous-processus, par exemple Operational Purchasing et Strategic Purchasing, et peuvent masquer les fonctions ou définitions dont ils n'ont pas besoin.
3. Les key users créent des équipes dans Manage Teams and Responsibilities, renseignent les valeurs des définitions de responsabilité, comme la division 1010 ou une société, et ajoutent des membres avec leurs fonctions.
4. Un consommateur, comme une étape de flexible workflow ou un type de situation, demande les agents d'une équipe ou d'une fonction pour l'objet concerné.
5. Responsibility Management compare les attributs de l'objet aux équipes et renvoie les utilisateurs.

Les règles de responsabilité permettent aussi de déterminer les agents sans équipes. Responsibility Management transforme ainsi la connaissance de l'organisation en données que les workflows et les alertes peuvent interroger.

Les définitions de responsabilité et les fonctions sont affectées à la catégorie d'équipe SAP et héritées par ses types d'équipe ; les clients peuvent ajouter des définitions de responsabilité personnalisées. Les équipes peuvent aussi être organisées en hiérarchies avec Manage Team Hierarchies. Une équipe dans Responsibility Management est donc délimitée par des attributs métier, et non par un organigramme.

• Flexible workflow : lorsque les key users définissent les destinataires d'une étape de workflow, des scénarios comme les ordres de maintenance proposent l'affectation par équipe, qui envoie la tâche aux membres de l'équipe, ou l'affectation par rôle, qui retient les membres ayant une fonction donnée. Dans les achats, la catégorie Procurement apporte des fonctions comme Strategic Purchasing et Operational Purchasing.
• SAP Business Workflow : le business workflow est un type de contexte de responsabilité, si bien que les modèles de workflow peuvent déterminer les agents via les règles de Responsibility Management.
• Situation Handling : chaque type de situation détermine ses destinataires via des équipes ou des règles de responsabilité.

Plusieurs domaines métier livrent leurs propres tiles Manage Teams and Responsibilities, par exemple pour les achats, la gestion des immobilisations ou la comptabilité contractuelle, qui ouvrent le même framework avec une catégorie d'équipe prédéfinie. Responsibility Management est la couche commune de détermination des destinataires sous ces frameworks.

• Destinataires fondés sur des attributs : les responsabilités suivent la division, la société ou d'autres définitions, si bien qu'une seule règle de workflow sert de nombreuses unités organisationnelles.
• Maintenance assurée par le métier : les key users et les responsables d'équipe modifient les membres dans une application SAP Fiori, sans développement et sans toucher aux définitions de workflow.
• Réutilisation entre frameworks : les mêmes équipes servent aux approbations et aux alertes de situation, si bien qu'une réorganisation n'est maintenue qu'une fois.
• Extensible : des définitions de responsabilité, fonctions et règles personnalisées étendent les contextes de SAP, et SAP documente le transport de ces extensions.
• Autosurveillance : un modèle SAP pour Situation Handling informe les responsables d'équipe lorsque des membres qui doivent approuver des tâches sont indisponibles.

Pour les approbations et alertes SAP S/4HANA, Responsibility Management est le moyen natif d'aligner les destinataires sur l'organisation métier.

• Au sein d'un seul système SAP S/4HANA. Les équipes résident dans le système qui les utilise. Les approbateurs d'autres applications ou les tâches d'autres systèmes nécessitent leur propre logique de destinataires.
• Les équipes doivent concorder dans tout le paysage. Lorsque des workflows qui désignent des équipes sont transportés, SAP exige que les équipes soient identiques dans chaque système, ce qui intègre la maintenance des équipes à la planification des releases. Un ID global d'équipe, figé une fois sauvegardé, identifie la même équipe d'un système à l'autre.
• Il décide qui, pas quoi. Responsibility Management renvoie des agents ; les étapes, délais et décisions appartiennent au workflow ou au type de situation consommateur.
• La qualité des données détermine le résultat. Des équipes vides, des membres obsolètes ou des valeurs de définition manquantes produisent des tâches sans agents.

Ces limites sont voulues : Responsibility Management maintient les données de responsabilité, tandis que la conception des processus se fait dans les frameworks qui les consomment.

1. Nommer des personnes dans les workflows au lieu d'équipes. Chaque réorganisation implique alors de modifier les workflows ; les équipes absorbent le changement.
2. Des équipes qui se chevauchent. Deux équipes couvrant la même division avec la même fonction brouillent la responsabilité d'une tâche ; vérifiez comment la règle d'agent du consommateur gère plusieurs équipes correspondantes.
3. Des trous dans la couverture. Une division sans équipe laisse des tâches sans agents. Confrontez chaque nouvelle division ou société à la liste des équipes.
4. Ignorer les absences. Activez la situation de membre d'équipe indisponible pour que les responsables d'équipe puissent remplacer les membres qui ne peuvent pas agir.
5. Oublier le paysage. Des équipes créées uniquement en développement font échouer les workflows transportés en production.

Lorsqu'une tâche ou une situation n'a pas de destinataire, vérifiez d'abord le périmètre et les fonctions de l'équipe, puis les paramètres de destinataires du consommateur. La plupart des problèmes de Responsibility Management sont des problèmes de maintenance des données qui se manifestent par des tâches absentes.