Configurer les modèles de plan d’objectifs de développement à l’aide de XML

Le XML du plan de développement vous offre un contrôle total de la configuration, tandis que Gérer les modèles dans le Centre d’administration vous offre des options limitées. Par exemple, voulez-vous ajouter les champs Métrique/Mesure de réussite ou Jalons ? Cela ne peut être configuré que via le fichier XML. Tous les éléments du Centre d’administration sont également configurables dans le fichier XML. Par exemple, la date de début planifiée utilise l'élément XML <obj-plan-start>. Certains éléments sont faciles à corréler tandis que d'autres peuvent être difficiles.

La plupart des attributs Paramètres généraux ne peuvent pas être modifiés dans le Centre d’administration et doivent être modifiés via XML. Cette section passe en revue certains des attributs Options générales qui doivent être modifiés via XML.

Pour modifier le modèle de plan d’objectifs de développement au format XML, le modèle doit d’abord être exporté. Cette opération peut être effectuée à partir de Gérer les modèles à l'aide de la flèche Télécharger. Une fois le modèle exporté, il peut être ouvert dans un éditeur XML pour apporter des modifications. Une fois les modifications sauvegardées, le modèle est chargé à nouveau dans l'instance à l'aide de la flèche Mettre à jour dans Gérer les modèles.

Pour savoir comment modifier des modèles de fichiers XML, regardez cette vidéo :

Les options générales vous permettent d'activer différentes fonctionnalités dans votre modèle de plan de développement. L'une de ces fonctionnalités est de définir l'objectif comme privé (seul l'utilisateur peut voir l'objectif) ou public (les utilisateurs disposant des autorisations appropriées peuvent voir l'objectif). La visibilité des objectifs est contrôlée par les attributs new-obj-share-status-public et use-text-for-privacy.

• Les autorisations d'accès privé et d'action de partage auront également un impact sur le fait que la zone Visibilité peut être modifiée ou est en lecture seule.

La figure illustre la vue pour les écrans XML et Créer un objectif de développement après avoir défini par défaut un objectif sur Privé et activé la zone Visibilité.

Remplacement de texte vous permet de remplacer le texte standard de l'attribut "Instructions" par du texte personnalisé dans le fichier XML (notez que le "I" au début de l'attribut est en majuscules). Si les instructions ne s’affichent pas, sélectionnez le texte « Introduction » dans l’écran Plan d’objectifs de développement pour activer et désactiver le texte.

Ne confondez pas cela avec l’outil Remplacement de texte dans le Centre d’administration. Toutes les options de remplacement de texte se trouvent dans la DTD objective-template_4_0.dtd et sont ajoutées via l'élément text-replace. Vous pouvez rechercher dans la DTD le terme "Remplacements de texte" et vous trouverez la liste des options.

La figure ci-dessous illustre le code XML et la vue Plan de développement présentant des exemples de remplacement de texte XML.

Les catégories sont utilisées pour organiser les objectifs de développement et sont configurées à l’aide de l’élément catégorie. Dans l'élément de catégorie, il doit y avoir un ID de catégorie et un nom de catégorie.

L'ID de catégorie apparaît dans les rapports et peut uniquement être configuré dans le fichier XML. Le nom de la catégorie est ce qui apparaît dans l'instance.

Il est recommandé de rendre l'ID de catégorie et le nom de la catégorie aussi similaires que possible. En outre, les caractères spéciaux ne doivent pas être utilisés dans les ID de catégorie. Lorsqu'une catégorie est ajoutée à partir du Centre d'administration, le système affecte un ID avec le nom "categoryX", où X est une valeur numérique. Cet ID doit être modifié dans le fichier XML pour correspondre au nom de la catégorie.

Le <default-category> prend en compte les éléments suivants : 

• Il n'existe qu'un seul <default-category> pouvant être configuré en tant que tel dans le modèle XML.
• La <default-category> est toujours postérieure à la dernière </category> définie dans le modèle XML. Cet ordre est appliqué par le DTD objective-template_4_0.dtd. Après avoir créé de nouvelles catégories, vous pouvez supprimer l'élément <default-category> pour contrôler l'ordre.
• Le <default-category> est facultatif et plus fréquemment utilisé dans les plans d'objectifs que dans les plans de développement. 

Voici un exemple du fichier XML <default-category> :

1234567891011

<category id="Goals">
<category-name>Current Goals</category-name>
</category>
<category id="ArchivedGoals">
<category-name>Archived Goals</category-name>
</category>
<default-category id="Default">
<category-name>Select Current or Archived Goals Category</category-name>
</default-category>

Comme indiqué dans les sections précédentes, les zones standard et personnalisées peuvent être ajoutées à un plan de développement. Bien que l’ajout de champs soit généralement terminé dans le Centre d’administration, les champs Standard et Personnalisé peuvent être ajoutés via XML.

L’ajout de nouveaux champs via Provisioning au format XML suit un processus en deux étapes, car les étapes qui ont été exécutées automatiquement pour vous dans le Centre d’administration doivent maintenant être effectuées manuellement dans XML :

1. Définissez la zone.

   L’élément <field-definition> est utilisé pour définir chaque champ d’objectif de développement. Vous devez définir toutes les zones qui doivent être utilisées dans le plan.

   Tous les modèles de plan d’objectifs de développement sont préremplis avec plusieurs champs d’objectifs de développement configurés.

   Vous pouvez ajouter, supprimer ou modifier ces zones en fonction des besoins du client. Vous pouvez ajouter de nombreux champs au plan d’objectifs de développement.

2. Autorisez le champ.

   La section <field-permission> détermine qui peut lire (afficher) et écrire (modifier) des zones spécifiques.

   Les champs ajoutés via Gérer les modèles sont également automatiquement ajoutés à la présentation du plan, mais celle-ci n’est plus utilisée avec la dernière version du module Gestion des objectifs. Si un <field-definition> est supprimé dans le fichier XML, assurez-vous qu'il est supprimé des autorisations et planifiez la mise en forme pour valider le fichier XML.

Le fichier XML d'un champ standard suit un modèle répétable. Voici un exemple de champ de nom que nous pouvons décomposer pour voir les différents attributs :

1234
<field-definition id="name" type="textarea" required="true" detail="false" viewdefault="on" showlabel="false" default-calc-type="step" field-show-coaching-advisor="true" cascade-update="push-down">
<field-label>Goal</field-label>
<field-description>Goal</field-description>
</field-definition>

Les champs du plan d’objectifs sont contrôlés par <field-definition> éléments au format XML. Chaque zone a sa propre définition de zone unique qui, à son tour, peut avoir les sous-éléments et attributs suivants.

L'interaction de configuration Zone d'objectif fournit des détails supplémentaires sur chaque étape de l'ajout d'une nouvelle zone via XML.

Cliquez sur les boutons pour en savoir plus sur les éléments de définition de champ.

Certains attributs sont requis pour toute définition de zone. Par exemple, l'attribut id et l'attribut type doivent être définis ou la validation du fichier par rapport à la DTD échouera. Certains attributs ne sont pas requis, par exemple detail ou showlabel.

Il existe également un élément enfant requis : field-label . Tous les autres éléments subordonnés sont facultatifs.

En outre, la table Champs standard répertorie les détails des champs standard du plan d'évolution couramment utilisés. Ils peuvent tous être ajoutés via le Centre d’administration.

La table Types de zones affiche une liste des types de zones disponibles. Il est important de garder à l'esprit que les zones standard sont limitées à un ensemble prédéterminé de types de zones. Les champs personnalisés utilisent généralement du texte, une zone de texte, une énumération, une date ou un pourcentage.

Bien que tous ces types de champs soient disponibles en XML, ils ne sont pas tous disponibles lors de l’ajout de champs via Gérer les modèles dans le Centre d’administration.

Comme pour la gestion des objectifs, d’autres champs standard peuvent être configurés dans le plan de développement. Il s’agit de champs standard qui ne peuvent pas être ajoutés via Gérer les modèles dans le Centre d’administration ; ils doivent être ajoutés au format XML. Par exemple, si le client souhaite que l'utilisateur ajoute des jalons à chacun de ses objectifs. Le champ des jalons n’est pas un champ standard du Centre d’administration.

Voici d'autres zones standard :

Pour apporter des modifications aux attributs qui ne sont pas disponibles dans le Centre d’administration, localisez l’élément souhaité et apportez la modification. Par exemple, si vous voulez que le champ soit un champ obligatoire, modifiez le code required. Les champs obligatoires sont signalés par un astérisque (*).

La table décrit des attributs <field-definition> supplémentaires et peut être sauvegardée pour référence.

Pour plus de clarté, évitez d'utiliser des attributs définis par DTD tels que "type" ou "id" comme valeurs littérales entre guillemets. Cela pourrait semer la confusion parmi les développeurs et les administrateurs.

Des options de zone supplémentaires sont disponibles dans le Guide d'implémentation de la planification du développement de carrière : Éléments et attributs du modèle de plan d'objectifs.

Nous avons déjà vu que des champs personnalisés pouvaient être ajoutés via le Centre d’administration. Ils peuvent également être ajoutés via XML. Pour les zones personnalisées, l' ID de zone et le type de zone sont déterminés par le client. Il est important de décider si les champs personnalisés doivent être utilisables dans les rapports (seuls les champs personnalisés ont besoin de cet attribut). Tous les champs standard peuvent faire l’objet de rapports par défaut).

La figure ci-dessous montre le champ personnalisé ajouté : done (% complete).

Outre la configuration des zones du plan d'évolution, le client doit décider quels rôles utilisateur peuvent utiliser les objectifs et les zones. Les autorisations du plan de développement sont différentes des autorisations basées sur les rôles, mais les deux sont utilisées pour accorder l’accès aux utilisateurs.

Les autorisations basées sur les rôles permettent d’accéder au plan d’objectifs de développement. Une fois que les utilisateurs ont accès au plan d’objectifs, toutes les autres autorisations sont régies par les autorisations de plan XML.

Lorsque des champs sont ajoutés dans le Centre d’administration, les autorisations de ce champ sont automatiquement ajoutées à tous les blocs d’autorisation existants. Il se peut que ce ne soit pas le comportement souhaité, les autorisations doivent donc être modifiées ultérieurement via XML.

Lorsque des champs sont supprimés du Centre d’administration, le champ et ses autorisations sont supprimés.

Lorsque des champs sont ajoutés via XML, les autorisations doivent être ajoutées manuellement à tous les blocs d'autorisation existants. Il en va de même lorsque les zones sont supprimées via XML.

Les sections suivantes abordent le processus de modification de deux types d’autorisations de plan de développement : les autorisations d’action et les autorisations de champ.

Les autorisations d'action définissent les rôles qui ont la possibilité d'effectuer des actions spécifiques sur un plan d'objectifs, telles que la création d'objectifs ou l'affichage d'objectifs privés.

La figure ci-dessus illustre un exemple de XML avant la modification des autorisations, c’est-à-dire qu’aucun représentant RH, et une fois les autorisations modifiées, c’est-à-dire que le représentant RH est inclus. Dans l'exemple suivant, l'autorisation Rep. RH est représentée par le rôle GE qui est mis en surbrillance en jaune.

La table Toutes les autorisations affiche une liste des autorisations d'action possibles.

L’élément <field-permission> définit qui voit et modifie les champs dans le plan d’objectifs. Les autorisations sont basées sur la relation entre les employés de l'organisation. Les autorisations de champ ne peuvent être configurées que dans le modèle XML et non dans Gérer les modèles.

Les autorisations de zone possibles sont les suivantes :

• Lecture : l'utilisateur disposant de l'autorisation Lire peut voir le champ, mais pas le modifier. 
• Écriture : l'utilisateur disposant de l'autorisation Écriture peut voir et modifier le champ. L'autorisation d'écriture implique l'autorisation Lecture, de sorte qu'elles n'ont pas besoin d'être configurées toutes les deux.
• Aucun : l'utilisateur ne peut pas du tout voir (ou modifier) le champ.

Les autorisations de champ existent dans des blocs qui sont lus par le système de haut en bas, de sorte qu'un bloc d'autorisation Lecture inférieur peut potentiellement remplacer un bloc d'autorisation en écriture supérieur. La meilleure pratique consiste à placer les autorisations de lecture au-dessus des autorisations en écriture dans la liste de codes.

L'élément <field-permission> se compose des balises suivantes :

La figure ci-dessus montre l'avant et l'après XML lorsqu'une autorisation de champ est modifiée. L'exemple ci-dessus montre deux blocs d'autorisation (surlignés en jaune). Dans cet exemple, personne ne peut lire ou modifier le champ "métrique" car il n'y a pas d'autorisation pour le champ "métrique". L'exemple suivant montre trois blocs d'autorisation (mis en surbrillance en jaune). Dans cet exemple, tout le monde peut lire la zone "métrique", les rôles E et EM peuvent modifier "métrique", et les rôles EM+ et EH peuvent modifier les "commentaires".

Les rôles pour les autorisations XML du plan de développement sont les mêmes que dans Gestion des objectifs et le modèle de données non basé sur les rôles, avec l’ajout du rôle MT.

Pour obtenir une liste complète des rôles, voir l'article de la base de connaissances suivant : https://launchpad.support.sap.com/#/notes/2087940

La configuration des plans de développement dans le Centre d’administration ou XML présente des avantages et des inconvénients. Par exemple, la configuration d'éléments dans le Centre d'administration empêche les consultants d'effectuer des erreurs de syntaxe. D'autre part, certains postes ne peuvent être ajoutés qu'à l'aide de XML. En fonction des éléments que vous configurez, sélectionnez la méthode de configuration la plus appropriée.

Une stratégie consiste à ajouter autant que possible via le Centre d’administration, puis à terminer la configuration au format XML.

Le tableau ci-dessous répertorie quelques exemples d'avantages et d'inconvénients des deux méthodes de configuration.

Le champ de commentaire standard est utilisé pour stocker les commentaires publics pour les objectifs. Ce champ inclura toujours le nom de l'auteur et l'horodatage lorsqu'un commentaire est saisi.

Il n’est pas possible d’ajouter ce champ au modèle de plan de développement à partir de Gérer les modèles. La configuration est effectuée dans le fichier XML. L'ID de zone comments est au pluriel, tandis que le type de zone comment est au singulier :

12345678910
<field-definition id="comments" type="comment" required="false" detail="false" viewdefault="on" showlabel="true" field-show-coaching-advisor="false" cascade-update="push-down">
   <field-label>Comments</field-label>
   <field-label lang="en_US">Comments</field-label>
   <field-label lang="fr_FR">Commentaires</field-label>
   <field-description>Comments</field-description>
   <field-description lang="en_US">Comments</field-description>
   <field-description lang="fr_FR">Commentaires</field-description>
  </field-definition>

Comme tout autre champ, le champ de commentaire standard doit être ajouté à l’autorisation de champ dans le fichier XML du modèle de plan d’objectifs de développement. Les commentaires peuvent être ajoutés, modifiés ou supprimés après l'ajout de l'objectif à l'aide de l'écran Détails de l'objectif.

Le type de champ "competencies" relie les objectifs de développement à un ou plusieurs attributs (aptitudes ou compétences) que l’employé tente de développer.

1234
<field-definition id="competency" type="competencies" required="false"  detail="false"  viewdefault="on"  showlabel="false" field-show-coaching-advisor="false">
    <field-label>Attributes</field-label>
    <field-description>Competencies</field-description>
    <field-format>use-competencies</field-format>

Vous ne pouvez avoir qu’un seul champ "competencies" par plan de développement, mais vous pouvez avoir plusieurs qualifications ou compétences ajoutées à un objectif à l’aide de ce champ unique. Et ce champ "competencies" peut avoir une étiquette « Attributs », car les compétences et les aptitudes peuvent être ajoutées à un objectif.

Pour utiliser des comportements dans le champ Compétences au lieu de compétences, définissez la balise de format de champ (dans le bloc field-definition) comme suit : <Field-format>use-behaviors</ field-format>.

Le champ Compétences répertorie ensuite les comportements dans leurs compétences parentes.

Seules les compétences qui ont des comportements sont affichées et les aptitudes ne sont plus affichées. Vous pouvez sélectionner des comportements sous la compétence parent lors de la création d’un objectif de développement. Le champ Compétences répertorie ensuite les comportements sélectionnés.

Si vous aviez des compétences et des aptitudes dans un objectif et que vous modifiez le code XML pour utiliser des comportements, toutes les qualifications et compétences précédentes seront supprimées du champ Compétences/Attributs.

Le modèle de plan de développement utilise un ensemble de compétences spécifiques en ajoutant des filtres dans le modèle XML. Pour inclure des compétences de l’un des éléments suivants, vous pouvez ajouter une balise <competency-filters> qui définit les sources des compétences que le plan de développement utilisera. Il s'agit des éléments suivants :

• Formulaires
• Rôles
• Catégories
• Bibliothèques
• Exclure les compétences masquées
• Exclure les qualifications et les questions

Voici quelques exemples de la balise <competency-filters> :

123456
...
</default-category>
<competency-filters>
<exclude type="roles"/>
</competency-filters>
<field-definition ...

123456
...
</default-category>
<competency-filters>
<exclude type="forms"/>
</competency-filters>
<field-definition ...

1234567
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="hidden"/>
</competency-filters>
<field-definition ...

12345678
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<include type="category" match="category name"/>
</competency-filters>
<field-definition ...

12345678
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<include type="library" match="library name"/>
</competency-filters>
<field-definition ...

123456789
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<include type="category" match="category name A"/>
<include type="category" match="category name B"/>
</competency-filters>
<field-definition ...

123456789
...
</default-category>
<competency-filters>
<exclude type="forms"/>
<exclude type="roles"/>
<exclude type="hidden"/>
<include type="category" match="category name" library="library name"/>
</competency-filters>
<field-definition ...