Introduction

Nous introduisons, ci-après, la notion de processus métier qui est l’un des concepts majeurs sur lequel nous appuyons notre démarche, même si ce n’est pas l’unique point d’entrée. Cette notion n’est pas nouvelle ; cependant, il est clair qu’elle prend une nouvelle dimension du fait de l’évolution actuelle des systèmes d’information qui se tournent vers un support plus fidèle du métier. En abordant l’expression du besoin métier par la dynamique, via les processus métier, nous introduisons une approche efficace pour identifier les composants métier (autre concept majeur que nous traitons dans un autre article) et ainsi, bâtir des systèmes d’information modulaires.

Définition
Le processus métier est un ensemble de tâches coordonnées, régulées, exécutées selon une certaine séquence, dans le but de créer une valeur (produit matériel ou intellectuel). Les processus peuvent être assimilés à des briques qui, toutes assemblées, constituent l’édifice métier. On parle d’ailleurs en anglais de « Core Business Processes ». Les processus caractérisent une expression des besoins liée au service ; ils identifient un ensemble d’actions pratiques réalisées par un ensemble d’acteurs avec le recours ou non à des systèmes automatisés et procurent ainsi une vision de bout en bout au regard de la demande de services. Les processus métier représentent le cœur, l’essence même du métier d’une entreprise indépendamment de son organisation. A présent, pour en exploiter toutes les dimensions, il est nécessaire, dans un premier temps, de les identifier et de les formaliser. Ce n’est que dans un deuxième temps que l’ambition de les faire évoluer (pour répondre à une évolution du marché, de la stratégie, de la réglementation…) voire les optimiser deviendra légitime.

Identification.
Au sein de l’entreprise, nous pouvons distinguer deux catégories de processus : Les processus explicites, les processus implicites.

Dans le premier cas, les processus sont bien connus, maîtrisés et, parfois, formalisés. Il s’agit généralement de processus internes élémentaires impliquant peu d’acteurs. Dans le deuxième cas, le processus n’est pas réellement connu de bout en bout. Il fonctionne de manière implicite parce que l’entreprise doit rendre un service par l’enchaînement d’activités élémentaires mais, en aucun cas, il n’est considéré comme un tout qui peut à la fois évoluer et être optimisé. Ces processus sont généralement transverses à toute l’organisation et concernent plusieurs métiers au sein de l’entreprise (marketing, service des achats, production, SAV…). Face à ces différentes situations, l’approche adoptée pour les identifier doit être pragmatique tout en invitant à une prise de recul sur l’organisation et le métier de l’entreprise. Cela étant, il ne s’agit pas de reconstruire l’ensemble des processus mais plutôt de s’appuyer sur le savoir-faire de l’entreprise, l’expertise de ses ressources en procédant par palier. En ce sens, inutile de se lancer dans un vaste projet de re-ingénierie des processus (BPR), partons des projets et des besoins courants. Au sein du projet, une approche « top-down » sera suivie (processus puis sous-processus…), au-delà de ses limites, il conviendra d’appliquer (par itération) une approche « bottom-up » (processus puis macro-processus). C’est en procédant ainsi que nous pourrons disposer d’une connaissance approfondie du métier et mettre progressivement en place une vision des processus à l’échelle de l’entreprise sans provoquer de révolution culturelle. Pour ce faire et pour mettre en évidence les processus, implicites en particulier, nous considérons les besoins des acteurs externes en termes de service, le service réel qui leur est rendu (la valeur) et la manière dont il est rendu (les moyens mis en œuvre, qu’ils soient humains ou non). Finalement, c’est la consolidation des processus implicites et explicites qui fournit une vision consolidée et cohérente des processus métier à l’échelle du projet.

Formalisation et consolidation

Pour représenter les processus métier, nous nous appuyons sur le formalisme UML (norme de l’OMG) et, plus particulièrement, sur la notion de cas d’utilisation, introduite par Ivar Jacobson. Ces cas d’utilisation sont stéréotypés « processus ». Sur cette base, nous réalisons des diagrammes de cas d’utilisation et exploitons les relations entre cas d’utilisation proposées par UML pour représenter les différents types de dépendance entre processus. Les processus métier génériques de l’entreprise, ceux qui concrétisent LE service rendu, pourront être appelés « macro-processus ». Il existe alors plusieurs façons de préciser ces macro-processus :

• Une possibilité consiste à décomposer un macro-processus en processus plus précis. Ces processus sont chacun une partie du macro-processus mais possèdent une certaine autonomie ; ils sont porteurs d’une valeur (ou livrable) intermédiaire. Le résultat du déclenchement de l’ensemble de ces processus doit correspondre à la réalisation du macro-processus. Ainsi, lorsque le macro-processus sera sollicité, il sollicitera -utilisera- à son tour les processus (partiels) auxquels il est relié. Les processus peuvent être décomposés, selon ce principe, sur plusieurs niveaux. Le niveau le plus haut concerne les « macro-processus », le deuxième les « processus » et les suivants les « sous-processus ». Les processus de dernier niveau sont parfois appelés « processus feuilles ». Toutefois, quel que soit le niveau, il n’est pas faux d’employer le terme de processus mais, dans ce cas, l’indication de niveau de détail n’apparaît pas. Si les processus sont représentés au moyen du langage UML, cette décomposition est traduite grâce à la relation « include » depuis le macro-processus vers le ou les processus (et ainsi de suite pour les niveaux inférieurs).

• Un processus peut également être précisé avec l’intention de décrire son comportement dans un contexte particulier, lorsqu’il est déclenché par un acteur particulier, utilisant un canal particulier… Le sous-processus possède alors les caractéristiques du processus père auxquelles s’ajoutent des particularités qui lui sont propres.De la même façon que pour la décomposition « include », cette décomposition peut s’effectuer sur plusieurs niveaux de précision (on parlera de typage ou spécialisation). En langage UML, il s’agit d’une spécialisation, basée sur le principe de l’héritage, puisque les processus fils « héritent » du comportement du processus père.

• Enfin, la dernière façon de décomposer un processus permet de préciser qu’une partie du processus est exécutée dans un cas particulier, lorsque certaines conditions sont remplies. Ainsi, le macro-processus déclenchera le processus dans certains cas seulement (ou le sous-processus si nous partons d’un processus).Cette décomposition est rarement employée, comparée aux deux premières, et il est peu probable que se présente le cas où le processus doive à nouveau être décomposé. Il ne représente qu’une faible activité en regard de celle du macro-processus (ou processus si nous travaillons à un niveau inférieur). Le formalisme UML utilise la relation « extend » pour exprimer le fait que le processus père est « étendu » du comportement du processus fils lorsque certaines conditions sont remplies.

Il est donc possible de décomposer un processus en plusieurs niveaux de détail pour en faciliter la compréhension. Toutefois, la lecture des diagrammes s’en trouve entachée de par la multiplication du nombre de cas d’utilisation. Il est alors possible de grouper les processus par niveau de granularité grâce au concept d’encapsulation proposé par les packages.

Nous réalisons ainsi une sorte de hiérarchie de diagrammes de cas d’utilisation. Ce regroupement est conceptuel et se traduit, en termes de diagrammes, par un diagramme pour chaque package.

Conclusion

La notion de processus métier est un concept important pour comprendre et formaliser le métier d’une entreprise. Détaché de l’organisation, il oblige à une prise de recul qui est essentielle pour appréhender les besoins réels et leurs apporter une réponse adaptée. Perçu par l’acteur externe, il met en évidence la notion de service de bout en bout. La déclinaison de ces processus ou services en activités métier conduira ensuite à l’identification de composants métier majeurs. L’on considèrera finalement qu’un processus est un ensemble d’interactions entre composants métier.