Dans un contexte de complexité grandissante des métiers et des technologies, où il faut déployer des solutions collaboratives sur mesure en un temps record, l’adoption des standards offre une aide considérable. Cependant, les bonnes pratiques restent indispensables pour réussir son projet de BPM (Business Process Management). En tant qu’éditeur de solutions d’automatisation des processus métier, W4 le constate sur le terrain et vous propose un retour d’expérience.

BPMN2.0, une norme arrivée à maturité

Les modèles tiennent une place prépondérante en informatique et l’adoption d’une notation communément admise est un atout majeur pour réussir un projet. Pour les processus métier, le standard BPMN de l’OMG a gagné en maturité. Sa version 2.0 (2011) est issue d’un long travail collectif de normalisation, rassemblant des experts chevronnés du métier, des consultants et des éditeurs… BPMN2.0 s’est imposée grâce à un éventail complet d’éléments destinés à modéliser les activités intervenant dans un processus, du plus simple au plus complexe. Devenue incontournable en phase d’analyse (BPA), elle s’impose aussi de plus en plus à l’exécution. Cet aspect a de quoi séduire les éditeurs de suites BPM (BPMS) et les incite aussi à apporter leur pierre à l’effort de standardisation pour clarifier certains points ambigus, notamment concernant le comportement à adopter à l’exécution.

L’utilisation de modèles BPMN2.0, agnostiques en termes d’outillage, facilite d’abord la communication entre gens du métier, ayant la connaissance fonctionnelle des services à fournir, et équipes informatiques, en charge de produire les logiciels. Les résultats livrés sont ainsi plus conformes aux attentes. Cette banalisation de BPMN rend aussi les compétences plus faciles à trouver sur les projets. Cerise sur le gâteau, à défaut d’être encore réellement interopérables (capables de communiquer à l’exécution), les modèles deviennent inter-échangeables (compatibles d’un outil de conception à l’autre), ce qui accroît le potentiel de réutilisation et de collaboration [1].

Sur le terrain, les DSI aussi évoluent : elles ne limitent plus BPMN à un outil de représentation de flux séquentiels. Elles comprennent sa complétude pour rendre les procédures conformes et son apport pour implémenter des processus ad-hoc, où les activités peuvent s’exécuter de façon non séquentielle, voire complètement désordonnée. Les chorégraphies (diagrammes BPMN de collaboration) séduisent par leur capacité à décrire comment les intervenants s’échangent l’information pour mieux collaborer. La richesse de la norme en termes d’événements et de messages ouvre des portes pour le traitement d’événements complexes (CEP), permettant de déployer des solutions plus modulaires grâce à des processus capables de s’invoquer mutuellement de manière normée, par envoi de messages.

Les standards ne suffisent pas

Il y a cependant danger à tout attendre de l’adoption de BPMN2.0, d’abord parce que son périmètre est restreint aux activités du processus. Or, l’automatisation des processus dans le monde réel reste indissociable d’autres aspects.

Par exemple, des extensions sont indispensables pour associer des rôles aux participants associés aux activités : si les pools et swim lanes BPMN constituent un embryon de solution pour décrire les aspects organisationnels, les mécanismes prévus dans la norme à cet effet restent limités. Les éditeurs de BPMS doivent donc proposer des possibilités de décrire les organisations dont sont issus ces acteurs (utilisateurs, groupes d’utilisateurs, hiérarchies…) et des fonctionnalités pragmatiques répondant aux scénarios à couvrir. De même, si la traçabilité et le pilotage des processus sont inhérents au BPM, rien dans la norme ne s’y rapporte. Ces aspects, indispensables à la qualité, doivent être couverts par les outils choisis.

Autre exemple : la modélisation (partielle du moins) du système d’information où résident les données manipulées dans les processus est un passage obligé, synonyme d’intégration de bases de données, fichiers Excel, annuaires LDAP, services web, systèmes de GEDs... Cet aspect sort du périmètre de BPMN et l’on retombe alors souvent sur des solutions propriétaires. Pour conserver les avantages de l’adoption des normes, il faut pourtant privilégier les extensions vers d’autres standards. Ainsi, pour les data objects et data stores de BPMN, mieux vaut s’appuyer sur UML (de l’OMG), qui permet en outre de couvrir les use-cases.

L’utilisation d’UML en renfort de BPMN semble naturelle et les éditeurs commencent à proposer des solutions combinant les deux normes. Pour la gestion de documents, indispensable dans une démarche de dématérialisation, le support de CMIS [2] est une option intéressante.

Pour d’autres aspects cependant, aucune norme ne s’impose : description des organisations, mais aussi règles métier (les gateways BPMN n’en couvrent qu’un petit ensemble), indicateurs métier, interfaces utilisateur... Le pragmatisme reste alors de rigueur pour choisir l’outil le plus adapté à son besoin.

Les bonnes pratiques indispensables à l’agilité

L’expérience de W4 montre clairement que si l’on n’adopte pas d’emblée un certain nombre de bonnes pratiques, le choix des standards, s’il est un facteur favorable, ne suffit pas à garantir le succès d’un projet de BPM. Fini le temps des applications « built to last », nous sommes dans l’ère du « built for change ». Or, l’agilité ne se décrète pas, elle s’anticipe et se conçoit. Et le respect de certaines bonnes pratiques permet de l’accroître considérablement.

Le développement piloté par les modèles (MDD) est par exemple une approche reconnue comme efficace pour rendre les solutions plus agiles. Elle est du reste assez naturelle pour donner tout son sens aux représentations visuelles BPMN et UML.

En amont, pour modéliser le changement [3], la définition des besoins avec les parties prenantes du projet doit en priorité identifier ce qui sera amené à faire varier les processus, de manière spécifique au domaine fonctionnel. C’est un travail indispensable pour éviter la rigidité des processus, favoriser leur flexibilité et leur adaptabilité dans le temps. Il est donc essentiel, en avance de phase, de se focaliser sur les éléments du modèle susceptibles d’être les vecteurs du changement.

Le paramétrage des règles métier par les éléments variables du modèle est une autre pratique permettant d’obtenir des workflows adaptables dans le temps, permettant la prise en compte de valeurs ou de seuils conditionnels, d’autres politiques d’assignation, de nouvelles unités, des mécanismes de notifications différents, etc.

Enfin, pour simplifier les choses et faciliter la maintenance, le souci permanent du découpage des problèmes en fonction du domaine auxquels ils appartiennent est vital. C’est ce que les anglo-saxons appellent the separation of concerns : la distinction claire de couches logicielles dédiées (présentation, logique métier, accès aux données, persistance…) est essentielle. Un couplage lâche entre ces couches favorise l’ouverture, l’adaptabilité et la portabilité des composants. Cette pratique de répartition du travail s’applique aussi à un autre niveau : alors que les experts fonctionnels modélisent le monde métier, il incombe aux éditeurs de fournir les outils pour automatiser les processus (moteurs d’orchestration, suivis graphiques, tableaux de bord, consoles de pilotage…) et offrir intrinsèquement le support de ces bonnes pratiques.

Conclusion

La norme BPMN2.0 est suffisamment complète pour inciter les parties prenantes des projets de BPM, côtés métier et informatique, à l’adopter. Cependant, son périmètre ne suffit pas à produire des applications basées sur des processus métier. L’adoption des standards est un facteur favorable, mais ne peut garantir à elle seule le résultat si l’on ne respecte pas aussi les bonnes pratiques, en particulier celles se focalisant sur l’agilité. Pour pallier ces manques et s’appuyer sur les pratiques gagnantes, il faut s’orienter vers la technologie offrant le meilleur compromis. Le support scrupuleux de BPMN2.0, l’ouverture (notamment vers d’autres normes comme UML et CMIS), la richesse des extensions fonctionnelles pour couvrir les autres aspects (structures organisationnelles, données métier, interfaces utilisateurs, règles…) et le respect des bonnes pratiques doivent orienter ce choix.

[1] Voir les travaux du MIWG de l’OMG sur ce sujet
[2] Content Management Interoperability Standards du consortium OASIS
[3] Réf. What the Business Process Director Needs to Know About BPMN 2.0, Mars 2013, Nicholas Gall, Gartner