Exemples de stratégie d'approbation

Exemple 1 : stratégie d'approbation de niveau application

Tout d'abord, prenons un exemple simple pour démontrer le fonctionnement des approbations à un niveau basique. Dans cet exemple, il existe une stratégie d'approbation au niveau de l'application. Elle spécifie qu'au moins deux personnes du groupe GL Govern doivent approuver toutes les modifications apportées au plan de comptes.

Le groupe GL Govern se compose de Barry, Julie et Jane. Tom est le propriétaire de l'application Fusion GL.

Workflow d'approbation :

1. Mark soumet une demande pour ajouter un compte et mettre à jour une description de centre de coûts.
2. Puisque la méthode d'approbation est Parallèle, la demande est envoyée aux trois membres du groupe GL Govern pour approbation.
3. Julie approuve la demande.
4. Barry approuve la demande.
5. Les critères de la stratégie sont remplis, et la demande est validée.

Exemple 2 : escalade pour cause de blocage

Prenons le même exemple, sauf que cette fois, Barry et Jane ont été exclus du groupe GL Govern.

Le groupe GL Govern se compose uniquement de Julie. Tom est le propriétaire de l'application Fusion GL.

Workflow d'approbation :

1. Mark soumet une demande pour ajouter un compte et mettre à jour une description de centre de coûts.
2. Une demande d'approbation est envoyée à Julie.
3. Julie approuve la demande.

   Bien que la stratégie exige deux approbateurs du groupe GL Govern, Julie est la seule personne dans ce groupe. Puisqu'il n'y a pas d'autre approbateur disponible pour remplir les critères de stratégie, la situation est bloquée. Par conséquent, la demande est remontée à des utilisateurs dotés de l'autorisation Gestionnaire de données pour l'application. Etant donné que Tom est le propriétaire de l'application, son autorisation Propriétaire inclut l'autorisation Gestionnaire de données.

4. La demande est remontée à Tom.
5. Tom approuve la demande.
6. Les critères de la stratégie sont remplis, et la demande est validée.

Exemple 3 : stratégie d'approbation en série de niveau dimension

Maintenant, intéressons-nous à une stratégie en série au niveau de la dimension. Dans cet exemple, Josh doit approuver la demande en premier, puis Frank, et enfin une personne du groupe Accounting.

Le groupe Accounting se compose de James et Heather.

Workflow d'approbation :

1. Mark soumet une demande pour déplacer trois comptes.
2. Une demande d'approbation est envoyée à Josh.
3. Josh approuve la demande.
4. Une demande d'approbation est envoyée à Frank.
5. Frank approuve la demande.
6. Des demandes d'approbation sont envoyées au groupe Accounting (James et Heather).
7. Heather approuve la demande.
8. Les critères de la stratégie sont remplis, et la demande est validée.

Exemple 4 : stratégie d'approbation de niveau ensemble de hiérarchies et type de noeud

Alors que les stratégies d'approbation de niveau application et dimension s'appliquent à toutes les actions de demande, les stratégies de niveau ensemble de hiérarchies et type de noeud s'appliquent uniquement à certaines actions de demande. Les stratégies de type de noeud s'appliquent uniquement aux demandes qui ajoutent ou suppriment des noeuds, ou qui mettent à jour des propriétés de noeud. Les stratégies d'ensemble de hiérarchies s'appliquent uniquement aux demandes qui insèrent, enlèvent, déplacent ou réorganisent des noeuds dans un ensemble de hiérarchies, ou qui mettent à jour des propriétés de relation entre des noeuds.

Pour illustrer ces principes, prenons l'exemple de deux demandes dont les stratégies concernent à la fois le type de noeud et l'ensemble de hiérarchies. La première demande met à jour une propriété de noeud. Par conséquent, seule la stratégie sur l'ensemble de noeuds est appliquée. La seconde demande ajoute des comptes, avec un impact à la fois sur le type de noeud et l'ensemble de hiérarchies. Les deux stratégies sont donc appliquées.

Quelques informations supplémentaires sur ces demandes :

• Le groupe Accounting se compose de James et Heather.
• Le groupe TaxUsers se compose de Brian, Jane et Rachel.
• Le groupe EssAdmins contient sept administrateurs (EssAdmin1 à EssAdmin7).

Tout d'abord, intéressons-nous à une demande de mise à jour des propriétés de noeud. Les mises à jour de propriétés de noeud sont régies uniquement par les stratégies de type de noeud.

Workflow d'approbation de la demande 1 :

1. Mark soumet une demande pour mettre à jour la description de trois comptes (mise à jour de propriétés de noeud).
2. Des demandes d'approbation sont envoyées aux groupes Accounting et TaxUsers.

   Remarque :

   Puisque la mise à jour des propriétés de noeud n'a aucun effet sur l'ensemble de hiérarchies, le groupe EssAdmins ne reçoit pas de demande d'approbation.
3. James approuve la demande pour le groupe Accounting.
4. Rachel approuve la demande pour le groupe TaxUsers.
5. Les critères de la stratégie sont remplis, et la demande est validée.

Maintenant, intéressons-nous à une seconde demande, qui consiste cette fois à ajouter des noeuds. Comme auparavant, la stratégie de type de noeud est appliquée car l'action de la demande consiste à ajouter des noeuds. Toutefois, la stratégie d'ensemble de hiérarchies s'applique également car les actions d'ajout créent des actions d'insertion dans les points de vue hiérarchiques.

Workflow d'approbation de la demande 2 :

1. Mark soumet une demande pour ajouter trois nouveau comptes.
2. Des demandes d'approbation sont envoyées aux groupes Accounting et TaxUsers.
3. Puisqu'une action d'ajout dans un point de vue hiérarchique crée également des actions d'insertion dans l'ensemble de hiérarchies, des demandes d'approbation sont aussi envoyées au groupe EssAdmins.
4. James approuve la demande pour le groupe Accounting.

   Remarque :

   Etant donné que James possède une autorisation Participant (Lecture) implicite sur le type de noeud mais pas sur l'ensemble de hiérarchies, il doit approuver la demande dans l'inspecteur de demande. Reportez-vous à Stratégies et autorisations.
5. Rachel approuve la demande pour le groupe TaxUsers.

   Remarque :

   Etant donné que Rachel possède une autorisation Participant (Lecture) implicite sur le type de noeud mais pas sur l'ensemble de hiérarchies, elle doit approuver la demande dans l'inspecteur de demande. Reportez-vous à la section Stratégies et autorisations.
6. Cinq administrateurs Essbase approuvent la demande.

   Remarque :

   Etant donné que le groupe EssAdmins possède une autorisation Participant (Lecture) implicite sur l'ensemble de hiérarchies, il reçoit également une autorisation Participant (Lecture) implicite sur le type de noeud. Il peut ouvrir une vue et parcourir l'ensemble de hiérarchies pour approuver la demande. Reportez-vous à la section Stratégies et autorisations.
7. Les critères de la stratégie sont remplis, et la demande est validée.

Exemple 5 : approbation avec enrichissement activé

Si l'enrichissement est activé pour une stratégie d'approbation, les approbateurs dotés de l'accès Participant (Ecriture) sur un objet de données de la vue correspondant à la demande peuvent modifier cette dernière avant approbation.

Dans cet exemple, une demande est effectuée dans une vue de maintenance avec des points de vue pour trois applications : General Ledger, Planning et Consolidation. Chaque application comporte une stratégie d'approbation de niveau application, et l'enrichissement est activé dans les stratégies GL et Planning.

Workflow d'approbation :

1. Mark soumet une demande pour ajouter un centre de coûts dans l'application General Ledger.
2. Une demande d'approbation est envoyée à Josh, l'administrateur de GL.
3. Josh enrichit la demande en ajoutant le centre de coûts à l'application Planning, puis approuve la demande pour l'application GL.
4. Josh ayant ajouté un noeud à l'application Planning, la stratégie d'approbation Planning est activée et une demande d'approbation est envoyée à Julie, l'administratrice de Planning.
5. Julie enrichit de nouveau la demande en ajoutant le centre de coûts à l'application Consolidation, puis approuve la demande pour l'application Planning.
6. La stratégie d'approbation Consolidation est activée et une demande d'approbation est envoyée au groupe Accounting.
7. Barry, membre du groupe Accounting, approuve la demande pour l'application Consolidation. L'enrichissement n'étant pas activé dans la stratégie Consolidation, Barry ne peut pas enrichir davantage la demande.
8. Une fois les critères de toutes les stratégies d'approbation remplis, la demande est validée et le centre de coûts ajouté aux trois applications.