Les systèmes informatiques de nos entreprises sont le résultat d’une démarche visant à outiller les métiers. Cette démarche s’appuie sur plusieurs objectifs : réduction des coûts de traitement, réduction des anomalies et de la non-qualité (liée à des traitements manuels), amélioration de la productivité, optimisation des procédés de fabrication, aide à la décision ou plus récemment dématérialisation des documents (voie royale de l’informatique « verte »).

Le fossé entre informaticiens et utilisateurs subsiste dans les applications

Force est de constater que beaucoup d’énergie est dépensée dans la mise en œuvre et la maintenance de ces systèmes informatiques. Les années passant et, évolution technologique après évolution technologique, les mêmes problèmes de déploiement et d’utilisabilité des applications subsistent. La règle de base des logiciels informatiques bien connue dite « règle des 3 U » (une application utile, utilisable et utilisée), n’est malheureusement pas toujours respectée. Les systèmes d’informations regorgent d’applications stratégiques qui ne couvrent que 20 % à 40 % de leur périmètre initial. Cela s’explique par des dérives de charge liées à des aspects techniques, fonctionnels ou de gestion de projet. Les problèmes fonctionnels proviennent souvent de besoins insuffisamment décrits, ou mouvants. Ce n’est pourtant pas faute de disposer de méthodes de recueil des besoins : gestion des exigences, démarches par Use Case, inventaires de fonctionnalités attendues, entre autres. Chaque entreprise cherche à satisfaire ses besoins avec un patchwork de ces approches pour obtenir une démarche maison qui se doit d’être pérenne dans le temps. Une profusion de méthodes, d’approches et autres dogmes sont disponibles pour tenter de parvenir à capter les besoins du client dans sa totalité.

La solution la plus efficace consiste à vivre ce que les futurs utilisateurs vivent au quotidien. Une immersion totale permet de comprendre les tenants et les aboutissants du métier que les équipes de développement doivent implémenter. Quelques entreprises ont déjà pris ce parti : faire participer le consultant, le chef de projet, à la vie réelle de ses clients ; dans le magasin pour le monde la distribution, dans l’usine pour le monde de l’industrie, etc. L’objectif peut être atteint dans une bonne majorité des cas. Malheureusement, ces approches coûtent cher, sont consommatrices de ressources et pas toujours simples à mettre en place.

Néanmoins, une alternative existe : le développement de l’application basé sur les processus. 

Première approche de la démarche

Le recueil des besoins d’une application se décrit généralement de manière textuelle : « l’outil doit gérer la relation client, c'est-à-dire être en mesure de créer une fiche client, la modifier… La fiche client contient les informations suivantes : … ».

Au final, 80% des besoins décrits se résument par une gestion du CRUDS (Create, Read, Update, Delete, Search) des objets métiers de l’application. L’expression qui en découle ressemble alors fortement à la description de l’enchainement des écrans attendus par le client. C’est le cas d’une majorité des outils de gestion. De ce fait, on a tendance à oublier que les règles de gestion implémentées dans nos outils servent à supporter des processus métiers riches et complexes.

L’inconvénient de la description textuelle est qu’elle est soumise à l’interprétation de celui qui la lit et qu’elle peut être ambigüe. L’avantage du processus est qu’il peut être représenté sous forme graphique régi par une notation et un langage précis (cf. visuels 1 et 2). En somme, 30 % de l’expression des règles de gestion peut s’effectuer via l’enchaînement des tâches et leurs parcours. 20 % sont liés à la circulation des informations, et 10 % aux acteurs qui manipulent cette information. En approfondissant encore, il est possible de représenter les informations manipulées dans chaque tâche. Et pourquoi ne pas associer à chaque tâche une ou plusieurs règles de gestion ? Ce niveau de détail pouvant être exploité directement du point de vue de l’implémentation.

Même si l’approche semble idéaliste, ce n’est pas dans l’art de la définition du processus que cette démarche prend tout son sens, mais plutôt dans la capacité du « modéliseur » ou de « l’accoucheur » à parcourir l’exhaustivité des cas possibles au sein du processus. Dans une expérience récente, il m’est arrivé de commencer par un processus simple regroupant quelques sous processus, pour finir avec une complexité beaucoup plus importante. En effet, des sous-processus complémentaires n’avaient pas été identifiés. Là où l’expression traditionnelle était réductrice, l’approche par les processus permettait de réduire les risques liés à une expression incomplète du besoin.

Cette approche est d’autant plus évidente dans le cadre des problématiques d’intégration des systèmes informatiques. Malgré une appropriation de la notion de processus plus marquée de la part des techniciens depuis l’avènement du BPEL (Business Process Execution Language) comme langage d’exécution des processus, l’intérêt même du processus a été rejeté dans les bas fond de la documentation projets. Pourtant le processus métier est le cœur même des problématiques d’intégration. Qui, hormis le processus métier, est le plus susceptible de mettre en évidence les problématiques d’intégration des systèmes d’informations.

Le processus permet de définir la succession des activités (ou des tâches, opérations, actions, etc.) nécessaires à la réalisation d’un produit (matière première, produit fini, service, etc.).

Le processus peut viser plusieurs finalités :

• L’identification des fonctionnalités à implémenter dans les applications,
• L’identification des besoins de compensation, de manques logiciels lors de l’intégration de progiciels dans un système informatique,
• L’identification de processus ou de sous-processus non identifiés en phase de cadrage du besoin,
• L’identification des processus cibles, donc de recette utilisateur,
• L’identification des entrants de la conception détaillée :
  - les fonctionnalités attendues par le logiciel,
  - les règles de gestion,
  - les objets métiers, création, manipulation, accès concurrents, destruction ou expiration,
  - les flux de données entre les applications,
  - les interfaces d’échange,
  - les batchs (séquence de tâches automatisées),
  - les besoins en IHM,
  - profils d’utilisateurs, exclusions, délégations, escalades,
• L’identification de modifications de fonctionnements organisationnels jusque-là négligées,
• L’identification des sondes/points de mesures permettant de calculer les KPI (Key Performance Indicator).

Une fois le processus décrit, les domaines fonctionnels auxquels le système cible se rapporte sont identifiés.