Bonnes pratiques fondamentales de Pega Express pour le Business Architect

Les résultats métier (Business outcomes) sont les objectifs métier clés et à forte valeur ajoutée, pour lesquels une application créée avec Pega Platform™ est conçue. Les résultats métier peuvent par exemple inclure : 

• un nouvel objectif de vente,
• un objectif de fidélisation client,
• un objectif d’efficacité.

L’identification et la définition de résultats métier stratégiques clés pour l’application Pega déterminent l’orientation de votre programme de transformation des processus métier et garantissent que tous les incréments contribuent à répondre aux besoins de l'organisation cliente et de ses clients finaux. 

La bonne pratique Valeur métier (Business value) consiste à s’assurer que l'organisation atteint ses résultats stratégiques grâce à la préparation minutieuse d’une justification métier et d’un cas pratique à l’appui. 

Pour vous, en tant que BA Pega, la connaissance du cas pratique revêt de nombreux objectifs :

• prioriser la portée (scope) pour s’assurer que la solution proposée permet de réaliser le résultat métier ;
• établir les indicateurs clés de performance (KPI) cibles que la solution Pega atteint ;
• calculer le retour sur investissement (ROI) à l’aide des modèles de référence et cible.

L’établissement de la valeur métier d’un projet vous donne, en tant que pont entre les services métier et IT, des points de référence pour les discussions sur la priorisation avec l’équipe métier tout au long du projet.

Application pratique des résultats métier et de la valeur métier pour le Business Architect Pega

En tant que Business Architect Pega, vous travaillez avec le Product Owner pour comprendre les principaux résultats métier stratégiques du projet, qui orientent la transformation des processus métier. Au fur et à mesure que vous avancez dans le projet, la compréhension du cas pratique du projet guide vos discussions avec les parties prenantes de l’équipe métier sur la hiérarchisation des fonctionnalités en fonction de la valeur métier apportée par chacune. 

Vérifiez vos connaissances avec l’interaction suivante :

Le concept de micro-parcours (Microjourney) est fondamental pour l’approche de delivery Pega Express et constitue notre façon de fractionner les parcours clients complexes les plus longs en parcours plus petits qui peuvent être livrés plus rapidement, accélérant ainsi la création de valeur grâce à la refonte de vos processus métier.

Pour identifier les micro-parcours, vous devez tenir compte de l’expérience de bout en bout des utilisateurs finaux d’une application. Cet exercice consiste à identifier dans le parcours global des fonctionnalités incrémentielles que vos équipes projet peuvent rapidement mettre en production, ajoutant ainsi une valeur immédiate pour l'organisation cliente et son client. 

Par exemple, l’image suivante illustre comment un parcours de service automobile (une demande d’assistance routière avec une société appelée GoGoRoad) pourrait être décomposé en un micro-parcours :

L’approche de delivery Pega Express préconise de regrouper les modifications apportées à l’application dans une version logicielle appelée Minimum Lovable Product (MLP). Une série d’une ou plusieurs versions MLP dans un projet forme ensuite la feuille de route de transformation pour la refonte de vos processus métier.    

Chaque MLP offre une solution qui, en plus d’être viable, est également voulue et appréciée par les utilisateurs finaux. Comme l’illustre l’image suivante, un MLP est conçu pour fournir rapidement des résultats métier de façon à satisfaire les clients et à leur faciliter la vie, ce qui accélère la valorisation pour l'organisation cliente :

Application pratique des mircro-parcours et du MLP pour le Business Architect Pega

En utilisant le concept de micro-parcours (Microjourney) et la structure MLP, en tant que Business Architect, vous fractionnez un processus de développement complexe en livraisons incrémentielles qui renforcent la certitude à la fois de parvenir à livrer l’application et d’obtenir la valeur associée. Ainsi, le processus de livraison devient plus simple à gérer et à modifier. Les parties prenantes des équipes métier et IT peuvent ensuite prendre en compte et appliquer les enseignements et les informations recueillis lors de l’implémentation de chaque MLP de la feuille de route.  

Vérifiez vos connaissances avec l’interaction suivante :

L’approche Directly Capture Objectives (DCO) est la discipline Pega de collaboration, d’itération et de validation continues sur toute la durée d’un projet Pega. Elle favorise l’alignement des différentes parties prenantes ainsi qu’un dialogue de grande qualité entre les équipes métier et IT. Comme l’illustre l’image suivante, l’approche DCO constitue une discipline qui repose sur la collaboration, l’itération et la validation en continu :

Les thèmes de l’approche DCO sont les suivants :

• conception et développement d’applications,
• obtention des résultats métier,
• conception centrée sur l’humain,
• itérations permettant d’obtenir plus rapidement une valeur métier.

Grâce aux outils de visualisation fournis par Pega, l’approche DCO aide les parties prenantes métier à comprendre l’application d’un point de vue pratique et expérientiel.

En tant que Business Architect, l’intégration de l'approche DCO dans votre projet est essentielle pour réduire les malentendus et limiter le risque de découvrir des lacunes métier ou fonctionnelles trop en aval du processus de développement d’applications. 

La réutilisation (Reuse) est la bonne pratique stratégique de conception et de configuration d’applications en tenant compte de la feuille de route, de l'échelle et des besoins à long terme de l’entreprise.  

La réutilisation permet d’implémenter des applications qui peuvent être rapidement étendues pour répondre à des besoins métier spécifiques tout en favorisant la cohérence de l’expérience utilisateur.

L’approche de Pega en matière de réutilisation, incarnée dans l’idée du Situational Layer Cake, se compose des couches (layers) suivantes, de la plus spécialisée à la moins spécialisée :

• Couche des applications d’innovation : contient des règles associées aux applications créées pour des business units spécifiques ou des régions géographiques localisées.
• Couche des applications métier : contient des règles associées aux business units distinctes d’une organisation
• Couche des applications modulaires : contient toutes les règles disponibles pour être réutilisées dans les applications métier et d’innovation
• Couche d’entreprise : contient des règles communes à toutes les applications de l’entreprise
• Couche Pega Platform : comprend tous les packages de règles de Pega Platform

Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur l’approche du Situational Layer Cake de Pega en matière de réutilisation :

Scrum est un élément fondamental de l’approche de delivery Pega Express. Scrum garantit que les parties prenantes des équipes métier et informatique travaillent ensemble de manière collaborative et transparente pour obtenir les bons résultats pour le client, écartant ainsi toute mauvaise surprise au moment du déploiement. 

Scrum est une forme de développement Agile qui définit des rôles, des responsabilités, des événements, des artefacts et des processus spécifiques à votre projet. Il comprend des rôles de leadership tels que Product Owner (PO), Project Delivery Lead (PDL) et Scrum Master, divise les projets en cycles de développement limités dans le temps appelés sprints et nécessite la maintenance d’un backlog projet divisé en user stories.

Sprints et événements Scrum 

Un sprint est un cycle de travail limité dans le temps, d’une durée maximale de quatre semaines, au cours duquel l’équipe développe un livrable. Les sprints sont d’une longueur constante tout au long du projet, et dès qu’un sprint se termine, le suivant commence, livrant un nouvel incrément. Plusieurs événements Scrum se produisent au cours de chaque sprint. Chacun de ces événements aide l’équipe à vérifier ce qui est développé et à s’y adapter. 

Exemples d’événements Scrum : 

• Affinement (refinement) et estimation des stories : donne le temps de passer en revue la taille et l’exhaustivité des user stories.
• Planification des sprints : permet au Product Owner, au Project Delivery Lead et au Scrum Master de prioriser les user stories dans le sprint en cours.
• Point Scrum quotidien (Daily Scrum) : le Scrum Master dirige cette réunion quotidienne afin que certains membres de l’équipe projet puissent se rencontrer et discuter de l’avancement du projet.
• Revue de sprint (Sprint review) : donne à certains membres de l’équipe projet l’occasion de revoir ce qui a été réalisé dans le sprint en cours.
• Rétrospective de sprint : donne à l’équipe projet l’occasion d’échanger sur les changements à apporter dans le prochain sprint, sur la base de ce qui s’est bien passé dans le sprint actuel ou de ce qui peut être amélioré.

En tant que Business Architect, vous participez activement à tous les événements Scrum, y compris, dans la mesure du possible, aux points Scrum quotidiens.

Affinement et estimation des user stories 

Des sessions d’affinement et d’estimation des stories sont organisées de manière régulière. Durant les réunions d’affinement et d’estimation des stories, l’équipe : 

• vérifie que l’équipe IT comprend les user stories qui sont prêtes pour l’estimation et que ces user stories répondent à la Definition of Ready (DoR), les critères qui déterminent si une story est complète ; 
• permet à l’équipe de développement d’évaluer les efforts requis pour configurer et tester la user story afin de répondre à la Definition of Done (DoD), les critères qui permettent de déterminer si une story est complète en termes de développement ; 
• dimensionne la story à l’aide de points (petite = 1, très grande = 13), afin que le Scrum Master puisse la prendre en compte à la prochaine session de planification des sprints. 

Application pratique de Scrum pour le Business Architect Pega

Travaillant à l’intersection entre les équipes métier et IT du projet, vous participez activement à de nombreux événements Scrum pendant toute la durée de votre projet. Les informations communiquées lors des événements Scrum vous permettent de soutenir, à différents moments, aussi bien l’équipe métier que l’équipe IT. Par exemple, vous participez activement aux événements Scrum d’affinement et d’estimation des stories pour finaliser les user stories que vous avez créées dans le cadre de vos sessions DCO. Une fois les user stories finalisées, vous les ajoutez au backlog du projet et les mettez ainsi à disposition pour le développement et les tests par l’équipe informatique lors des sprints à venir.  

Vérifiez vos connaissances avec l’interaction suivante :