Conception de dossier

La première étape de l’activité de conception de dossier (case design) durant la phase de préparation consiste à examiner le backlog du type de dossier (case type) et à créer le type de dossier pour chaque Microjourney^™ ayant été priorisé pour le MLP (Minimum Lovable Product). Vous devez vous assurer du bien-fondé des développements (build) que vous planifiez.

L’activité de conception de dossier a pour but de :

• Créer les types de dossiers de base ainsi que les liens entre eux en vue de préparer la phase Build
• Valider la portée (scope) fonctionnelle du Microjourney avec le product owner
• Garantir que la conception de dossier applique les bonnes pratiques dès le début.

L'approche Directly Capture Objectives (DCO) permet au business architect, au system architect et au product owner de travailler ensemble à la modélisation du type de dossier (case type) en phases (stages) et en étapes (steps). Le type de dossier est ainsi fractionné en ses composants.

Une fois les étapes et les phases validées avec le product owner, des discussions ultérieures permettent de définir les personas impliqués dans le type de dossier ainsi que les data objects nécessaires pour effectuer le traitement. À l’issue des sessions de DCO, vous disposerez d’une représentation visuelle du type de dossier à faire valider par le product owner.

Pour s’assurer que les bonnes pratiques en matière de conception de dossier ont été adoptées dès le début, le system architect dirige les aspects techniques du type de dossier au sein de la session de DCO.

Le system architect vérifie que la conception de dossier prend en compte les éléments suivants :

• Workflow
• Personas et canaux (channels)
• Données
• Réutilisation
• Echelle (scale)

Dans l’image suivante, cliquez sur + pour en savoir plus sur les phases (stages) et les étapes (steps) de la conception de dossier (case design).

L’association des phases et des étapes détermine le workflow du dossier. Dans la plupart des entreprises, il existe différentes combinaisons de tâches :

• Certaines tâches peuvent être exécutées de manière séquentielle.
• D’autres peuvent être exécutées en parallèle.
• D’autres encore peuvent être facultatives, applicables uniquement sous certaines conditions.  

Au début du projet, les différents types de tâches influent sur la conception de votre dossier. Sur la base des résultats des ateliers (workshops) menés avec le product owner, le lead system architect réfléchit à la bonne pratique technique. Le cas échéant, il peut décider de créer des types de dossier supplémentaires (pour rendre possible l’exécution de tâches en parallèle au moyen de dossiers enfant, par exemple).

Lors de la conception de dossier, il est également nécessaire d’envisager l’affectation des tâches. Cet aspect est débattu et convenu entre les parties prenantes au début du projet. L’affectation des tâches définit la manière dont les tâches sont attribuées aux personas associés au type de dossier. Pour définir le modèle d’affectation des tâches, il est nécessaire de comprendre le modèle opérationnel de l’entreprise.

Il existe deux modèles d’affectation des tâches :

• Le modèle « push » : dans ce type de modèle, le système ou un chef d’équipe attribue les tâches à l’utilisateur concerné.
• Le modèle « pull » : dans ce type de modèle, l’attribution d’une tâche à un utilisateur s’effectue automatiquement en fonction d’un ensemble de règles métier (business rules).

Grâce à l’approche Pega Express^™, les personas sont associés avec les phases (stage) d’un type de dossier (case type) de manière à représenter les interactions de ce persona durant le cycle de vie du dossier. Les personas sont également associés à des canaux (channels) pour indiquer comment ils accèdent à l’application (ex. : par e-mail ou par le biais d’une page Web en libre-service). 

Avec la possibilité d’associer un persona à un canal, Pega Platform peut tenir compte d'une interface utilisateur et de processus spécifiques à ce canal pour créer une expérience utilisateur adaptée à cet environnement.

Lors des sessions de DCO organisées lors de la phase de préparation, le product owner et le business architect associent les personas aux phases pour s’assurer que les scénarios métier sont traités dans le périmètre du type de dossier. Dans le cadre de ces discussions, il est important de comprendre le type d’interactions susceptibles d’être générées par le persona au sein d’un canal spécifique. Par exemple, il peut être possible de créer une réclamation via un canal en libre-service, mais pas par e-mail. 

Sécurité par persona et par canal

Les droits d’accès aux données et aux processus sont également définis pour le type de dossier (case type). Ces droits d’accès peuvent influer sur la conception du type de dossier de différentes manières, avec par exemple :

• L’exclusion des tâches/données de certains canaux
• La répartition des tâches dans les différentes phases du type de dossier
• La création d’un type de dossier entièrement nouveau  

En se basant sur les exigences de sécurité, les system architects doivent prendre des décisions relatives à la conception du type de dossier afin de répondre aux besoins en matière de sécurité.

Au début du projet, vous devez avoir une très bonne compréhension des data objects associés au type de dossier afin de vous assurer que la conception de celui-ci est bien adaptée aux besoins en termes de données. 

Pour chaque data object, le system architect doit connaître les points suivants :

• Disponibilité et délai d’accès
• Conservation et archivage des données 

La disponibilité des données fait référence à la source de ces données. Certaines données peuvent être disponibles sur des systèmes externes. Les utilisateurs peuvent saisir directement d’autres données, et certaines peuvent être indisponibles. Il faut donc les créer au cours de l’avancement du dossier. Le délai d’accès aux données fait référence à la rapidité avec laquelle celles-ci peuvent être extraites d’autres systèmes et à la fréquence à laquelle elles évoluent.

En raison de l’attention toujours plus grande portée aux exigences en matière de confidentialité, les règles de conservation des données client influent directement sur l’activité de modélisation des données associée à la conception de dossier. L'identification de ces règles dès le début oblige le system architect à concevoir le dossier de manière à optimiser la gestion des données au sein de celui-ci. 

Exemple : un workflow bancaire doit capturer les coordonnées bancaires le plus tard possible dans le dossier de manière à éviter la détention d’informations bancaires tant que ce n’est pas nécessaire. En outre, il est possible que le workflow doive comporter une étape automatique de suppression des coordonnées bancaires une fois que la conservation des données n’est plus justifiée par des motifs commerciaux légitimes.

Au début du projet, identifiez les domaines clés du type de dossier susceptibles d’êtres utiles à d’autres types de dossier ou à des MLP ultérieurs. Le system architect disposera ainsi des informations permettant de guider la conception du dossier lors de la phase de préparation, de manière à prendre en charge la réutilisation du type de dossier, en totalité ou en partie (p. ex. : processus ou données spécifiques, interface utilisateur). La bonne pratique consiste à identifier les points communs aux niveaux métier et technique. Spécifiez ensuite ces points communs et concevez-les sous forme de règles ou de composants à utiliser dans plusieurs types de dossier.

Lors de la conception de type de dossier à mettre à l'échelle (scale), vous devez envisager la fréquence et le volume des dossiers concernés. L'échelle doit également prendre en compte l’interaction des personas avec le type de dossier. 

Différents membres de l’équipe utilisent l''échelle pour concevoir le type de dossier :

• Le product owner et le business architect analysent le workflow pour déterminer les niveaux d’automatisation à implémenter dans le type de dossier.  
• Le system architect étudie les mécanismes d’accès aux données et de stockage de celles-ci au sein du type de dossier.

Lorsque les dossiers sont fréquents et volumineux, concentrez vos efforts sur leur conception afin d’optimiser les traitements STP et d’obtenir ainsi le meilleur rendement possible en un minimum de temps.   

Avec la prise en compte du volume du dossier, vous orientez les discussions initiales sur la conception de celui-ci de manière à envisager les besoins en données associés aux types de dossier. Cette prise en compte permet de mettre en relief les changements à apporter à la modélisation initiale des dossiers afin de garantir l’efficacité et l’optimisation de l’accès aux données, en évitant des contraintes injustifiées sur les interfaces et les temps de réponse. 

Lors de la phase de préparation, consignez ces éléments en tant que User Stories et ajoutez-les au backlog pour les approfondir ultérieurement au cours du projet. 

Vérifiez vos connaissances avec l’interaction suivante.