La gestion des processus métier (BPM) et l’API-led Connectivity sont des stratégies complémentaires qui partagent la même vision : une entreprise à la structure composite qui s’adapte sans cesse aux nouvelles exigences du marché et aux attentes des clients en constante évolution.
Pourquoi le BPM et l’API-led Connectivity vont-ils de pair ?
L’objectif du BPM est d’optimiser les processus métier de l’entreprise. À cette fin, les processus métier sont modélisés, automatisés et supervisés. Les systèmes BPM (BPMS) facilitent ces tâches en modélisant et en exécutant le contrôle et le flux de données des processus métier. Ils assurent également des capacités de gestion de tâches humaines (Workflow) et intègrent un moteur de règles métier qui permet d’appliquer la logique des règles métier dans divers processus métier.
Prenons un exemple dans le secteur du commerce en ligne. Dans la figure 1, notre exemple de processus métier est la gestion simplifiée d’une demande de retour d’un client, qui est modélisée selon la norme de notation pour la modélisation des processus métier (BPMN, Business Process Model Notation).
Dès que le client demande un retour, le processus déclenche l’historique des commandes du client. L’historique des commandes est une donnée essentielle pour l’étape suivante : la validation de la conformité à la politique de retour. Un moteur de règles métier est utilisé pour automatiser cette activité.
Si la validation automatique renvoie un résultat négatif, une tâche manuelle permet de trouver une solution alternative pour le client. Si la demande est rejetée, ce dernier en est informé. Dans le cas contraire, le client reçoit une étiquette d’expédition retour et une autorisation de retour de marchandise (RMA) est consignée.
Maintenant que vous avons modélisé un exemple de processus métier, nous pouvons passer à la phase suivante dans le cycle de vie du BPM : l’automatisation du processus métier. Nous devons tenir compte de l’implémentation technique pour chaque type d’activité.
Il existe trois options principales :
- Créer une tâche manuelle pour attribuer l’activité humaine correspondante.
- Utiliser un moteur de règles métier pour automatiser une activité de décision.
- Tirer parti d’une logique métier dans les applications externes au BPMS par le biais d’appels.
Dans notre exemple, nous avons une activité, « gérer la violation de la politique », qui est implémentée comme tâche manuelle. L’activité de décision « valider la conformité à la politique de retour » est implémentée par le biais d’un moteur de règles. Les cinq dernières activités ont besoin d’une intégration avec des systèmes back-end. Découvrons comment l’API-led Connectivity peut nous aider.
API-led Connectivity et Processus métier
l’API-led Connectivity instaure un système de couches avec une séparation claire des responsabilités : API Expérience, API Processus et API System. Dans quelle couche les processus métier se trouvent-ils ? Alors que les API Expérience adaptent les informations pour un canal digital, les API System contiennent principalement une logique de connectivité vers les systèmes de traitement. Les API Process se situent entre les API Experience et les API System. Elles sont extraites des canaux digitaux et des environnements système sous-jacents et ciblent les domaines métier. Ainsi, les API Process sont adaptées par nature à la capture de la logique des processus métier et de la logique des règles métier.
Examinons maintenant les API et les intégrations qui existent dans le domaine métier. La figure 2, qui illustre l’architecture API-led Connectivity, comprend deux canaux d’engagement : un système de boutique et une expérience mobile associée.
Nous avons donc une API « Boutique » et une API « Mobile » sur la couche Experience afin d’adapter les informations à ces canaux.
La couche Process comporte quatre API métier. Notez que l’API « historique des commandes » (Order History) et
l’API « expédition » (Shipping) appellent plusieurs API pour enrichir les informations. Dans la couche System, des API fournissent la logique de connectivité aux systèmes back-end.
Anypoint Exchange héberge des API documentées et publiées comme briques de construction (building blocks) réutilisables pour des projets ultérieurs. Un « Center for Enablement » (C4E) est mis en place pour favoriser la réutilisation et permettre aux autres équipes de profiter de la plateforme et de la méthodologie. Ainsi, un C4E est une base organisationnelle parfaitement adaptée dans le cas d’une initiative de BPM.
Pour automatiser un nouveau processus métier, nous pouvons tirer profit de notre investissement existant en matière d’API-led Connectivity. Au lieu de recréer des intégrations pour chaque activité de processus, nous réutiliserons des API existantes qui présentent des fonctionnalités correspondantes. Les nouvelles API sont développées et publiées pour les activités qui ne peuvent pas être implémentées par le biais d’une réutilisation.
L’intégration vers des systèmes back-end dans le but d’implémenter des activités métier est un défi majeur dans l’automatisation des processus métier. L’API-led Connectivity offre une solution qui favorise la vitesse d’exécution et l’efficacité. Le BPM permet de générer une valeur commerciale grâce au caractère composite découlant de l’API-led Connectivity. En bref, le BPM constitue un moyen de créer une valeur commerciale à partir de l’investissement réalisé dans l’API-led Connectivity.
Dans la figure 3, nous reprenons notre précédent exemple afin de démontrer les améliorations nécessaires à l’architecture fondée sur les API de la figure 2.
Le nouveau processus métier présente, documente et publie l’activité « gérer la demande de retour » (Handle Return Request) en tant qu’API. Il est appelé par l’API d’expérience « boutique » (Shop) lors de l’exécution de la demande de retour du client et renvoie des informations sur l’autorisation relative à cette demande. Le processus de retour devient réutilisable dans d’autres contextes grâce à la documentation et à la publication de l’API.
Le BPMS orchestre l’exécution de l’instance du processus. L’implémentation de la première activité « rechercher l’historique des commandes du client » est un appel à l’API « historique des commandes » (Order History). Cette réutilisation de l’API « historique des commandes » dans le contexte d’un processus métier automatisé vous permet de gagner du temps et de réduire vos efforts. Cette exécution tire parti de la logique d’intégration et de connectivité existante vers le CRM et le système de gestion des commandes (OMS).
Un moteur de règles implémente la deuxième activité dans le processus : « valider la conformité à la politique de retour ». Le BPMS traite également directement la tâche manuelle « gérer la violation de la politique ».
L’activité « créer une étiquette d’expédition retour » est de nouveau implémentée par le biais d’un appel à une API existante : l’API « expédition ». Dans notre exemple, il n’existe aucune API correspondante pour implémenter le reste des activités dans le processus. Par conséquent, de nouvelles API sont nécessaires : « notification » et « commerce ». Pour le prochain projet, ces nouvelles API seront disponibles comme assets réutilisables.
Conclusion
Nous avons montré que la connectivité fondée sur les API constitue une base parfaitement adaptée à l’implémentation des processus métier. Le fait de réutiliser des API pour implémenter des activités de processus réduit considérablement le temps de travail et les efforts fournis.
Bien que le BPM et l’API-led Connectivity constituent des stratégies indépendantes et génèrent de la valeur par elles-mêmes, elles se complètent parfaitement. Avec l’API-led Connectivity, nous investissons dans le caractère composite de notre entreprise. Avec le BPM, nous récoltons les fruits de cet investissement, car chaque processus métier automatisé est une composition spécifique qui crée de la valeur commerciale.