Procédure pas à pas de mise en œuvre de Corticon : référentiel de contenu de vente

Dans cette procédure pas à pas, nous allons vous montrer comment implémenter des règles qui fournissent aux vendeurs un contenu spécifique en fonction du contexte de l’application dans laquelle ils travaillent, des autorisations pour leur rôle et des règles de workflow du processus de vente.

Il existe trois catégories de règles :

Catégorie 1 : Règles de type de fichier

1. Seuls les fichiers de type .ppt ou .pptx doivent être visibles dans l’application Présentations

2. Seuls les fichiers marqués avec «Produit1» apparaître dans l’application Teams

3. Seuls les fichiers modifiés au cours de la semaine dernière apparaissent dans les éléments récemment consultés

Catégorie 2 : règles d’autorisation des rôles

1. Les employés de niveau directeur ayant le rôle d’analyste sont autorisés à utiliser l’outil de reporting ad hoc

2. Au sein du locataire A, les utilisateurs du groupe B peuvent uniquement télécharger des ressources sur des appareils mobiles

3. Au sein du locataire B, les utilisateurs du groupe C ne peuvent voir que les opportunités dans le district ouest dans le CRM

Catégorie 3 : règles de workflow

1. Chaque semaine, envoyez les rapports A et B à tous les rôles de niveau gestionnaire du locataire D, à l’exception de ceux de la région Ouest

2. Si l’indice de qualité des données (dqi) d’une opportunité tombe en dessous de 20 %, envoyez un avertissement par e-mail aux vice-présidents des ventes

3. Si une question qui apparaît dans plusieurs appels d’offres est mise à jour, mettez à jour rétroactivement tous les appels d’offres précédents dans lesquels la question apparaît dans

Modélisation des règles du groupe 1 (contenu)

1. Seuls les fichiers de type .ppt ou .pptx doivent être visibles dans l’application Présentations

2. Seuls les fichiers marqués avec «Produit1» apparaître dans l’application Teams

3. Seuls les fichiers modifiés au cours de la semaine dernière apparaissent dans les éléments récemment consultés

Vocabulaire

Feuille de règles

Optimisation de la logique des feuilles de règles : vérificateur d’ambiguïté (conflits)

Le vérificateur de conflits montre que, telle qu’elle est actuellement modélisée, l’action de la règle nous permet uniquement de choisir UNE application à laquelle accorder l’accès. À ce stade, nous devons revoir les règles et nous demander : « Quelle est l’intention réelle de ces règles ? »

La règle 1 signifie-t-elle :

• ppt et pptx sont accessibles UNIQUEMENT par présentation ?
• Seule Présentation peut accéder aux ppt et pptx ?
• La présentation peut UNIQUEMENT accéder aux ppt et pptx ?
• Autoriser tous les accès si le fichier est ppt et Product1 et SPP ?

En fonction de la manière dont nous souhaitons que la règle se comporte, nous devrons peut-être modifier la feuille de règles. Supposons que l’objectif des règles est de permettre l’accès à toutes les applications pour lesquelles le fichier répond aux règles spécifiées. Cela signifie que nous ne pouvons pas avoir un seul attribut pour le résultat, car une règle ultérieure remplacera le résultat d’une règle précédente.

Pour modéliser correctement cela, nous devons introduire un nouvel objet métier (le Application) et établissez une relation entre les fichiers et les applications autorisées à y accéder. Il s’agira d’une relation plusieurs-à-plusieurs :

La feuille de règles doit ensuite être modifiée comme indiqué ci-dessous. Dans la section de portée, nous définirons un alias, «app».

Lorsque les conditions sont remplies, une nouvelle instance de Application (étant donné l’alias dans cette feuille de règles, "application") sera créé en tant qu’entité enfant de Fichier.

Test de la feuille de règles

Maintenant, nous pouvons tester des scénarios spécifiques par rapport aux règles pour valider le comportement :

Modélisation des règles du groupe 2 (Autorisations)

1. Les employés de niveau directeur ayant le rôle d’analyste sont autorisés à utiliser l’outil de reporting ad hoc

2. Au sein du locataire A, les utilisateurs du groupe B peuvent uniquement télécharger des ressources sur des appareils mobiles

3. Au sein du locataire B, les utilisateurs du groupe C ne peuvent voir que les opportunités du district ouest dans le CRM.

Le groupe 2 est un peu plus complexe puisque nous devons modéliser les relations entre un utilisateur et :

p>a. La Groupes auxquels ils appartiennent

b. La Rôles’ autorisations respectives

c. La Locataires auxquels ils sont affectés

Vocabulaire

Dans ce modèle, nous supposons qu’un utilisateur peut avoir plusieurs rôles, locataires et groupes :

Leurs niveaux d’autorisation sont désormais définis dans une nouvelle feuille de règles :

Modélisation des règles du groupe 3 (Workflow)

1. Chaque semaine, envoyez les rapports A et B à tous les rôles de niveau gestionnaire du locataire D, à l’exception de ceux de la région Ouest

2. Si l’indice de qualité des données (dqi) d’une opportunité tombe en dessous de 20 %, envoyez un avertissement par e-mail aux vice-présidents des ventes

3. Si une question qui apparaît dans plusieurs appels d’offres est mise à jour, mettez à jour rétroactivement tous les appels d’offres précédents dans lesquels la question apparaît dans

Le groupe 3 pourrait être divisé en trois parties qui ne se chevauchent pas, mais pour l’instant, nous les conserverons ensemble dans ce document. vocabulaire :

Feuilles de règles

Étant donné que ces trois règles n’ont aucun rapport les unes avec les autres (sauf qu’elles ont quelque chose à voir avec le Workflow), il est plus logique de les modéliser dans des feuilles de règles distinctes. En fait, si nous les mettons toutes sur une seule feuille, vous pouvez voir à quel point elles sont indépendantes puisqu’aucune des règles ne partage aucun des attributs :

Divisons-les plutôt en trois feuilles avec leurs propres cas de test respectifs.

1. Chaque semaine, envoyez les rapports A et B à toutes les personnes ayant un rôle de gestionnaire dans le locataire D, à l’exception de la région Ouest.

2. Si l’indice de qualité des données (dqi) d’une opportunité tombe en dessous de 20 %, envoyez un avertissement par courrier électronique aux vice-présidents des ventes.

3. Si une question qui apparaît dans plusieurs appels d’offres est mise à jour, mettez à jour rétroactivement tous les appels d’offres précédents dans lesquels la question apparaît.

Ceci n’est qu’un avant-goût de la complexité des règles qui peuvent être créées et opérationnalisées sans code dans Corticon. Pour en savoir plus ou essayer une évaluation gratuite, visitez progress.com/corticon.

En savoir plus

Source link