Instructions: Système métier
Les systèmes métier représentent une fonctionnalité indépendante au sein d'une entreprise. Ces instructions expliquent comment les identifier et les modéliser.
Relations
Eléments connexes
Description principale

Introduction

Les systèmes métier représentent une fonctionnalité indépendante au sein d'une entreprise. Ils sont utilisés pour comprendre la structure d'une entreprise en le partitionnant en fragments gérables, de manière identique au partitionnement d'une organisation en unités indépendantes. Cependant, le rôle et l'objectif des différentes parties d'une organisation ne sont pas toujours clairs pour les autres parties qui la constituent, ce qui se traduit par des interactions loin d'être optimales lors de l'exécution d'un processus métier.

Les systèmes métier approfondissent le concept de partitionnement et d'interdépendance. Ils ne font pas que relier et contenir des rôles et des ressources (et éventuellement d'autres systèmes métier), mais ils définissent de manière explicite les interfaces, ou l'ensemble des services ou responsabilités qu'ils peuvent être amenés à fournir. Les organisations qui définissent des accords de niveau de service pour spécifier de manière formelle et gérer les interactions entre les services et les collaborateurs externes définissent en fait des systèmes métier. L'utilisation d'un système métier va souvent de paire avec l'utilisation de modèles métier à différents niveaux d'abstraction (voir Concept : Modélisation de grandes organisations).

Le terme "système métier" ne doit pas être confondu avec le système logiciel. Un système métier comprend des personnes, du matériel, et des logiciels et constitue donc un niveau plus élevé d'abstraction qu'un système logiciel.

Les systèmes métier activent une structure dynamique

Dans son livre Enterprise Modeling with UML, Chris Marshall met en évidence le fait que les structures organisationnelles traditionnelles relativement statiques ne suffisent plus dans le monde métier dynamique et radicalement décentralisé qui émerge. Il n'est plus envisageable qu'une partie de l'organisation puisse rester intacte sur de longues périodes de temps. Comme il le mentionne dans son livre, "La valeur est créée et fournie par le biais de chaînes de valeur qui se forment et se dispersent au cours du temps. En fait, le jour où une telle chaîne sera formée pour une simple transaction n'est peut-être pas si loin."

Les organisations sont organiques. Lorsque la pression de l'environnement métier s'accroît, elles doivent s'adapter pour rester compétitives. Considérée à l'extrême, une structure organisationnelle statique peut être paralysée dans un environnement métier hautement dynamique et impitoyable et les sociétés peuvent se trouver dans l'obligation de passer à une structure dynamique dans un mécanisme de survie.

Dans une structure organisationnelle statique traditionnelle, les frontières entre les services ne sont que conceptuelles. Alors que cela peut être le signe d'une organisation "ouverte" et "informelle", le résultat est que chaque personne et segment de l'organisation est entrelacé avec le reste de l'organisation. Il devient extrêmement difficile de changer et de gérer une partie de l'organisation de manière complètement indépendante des autres parties. Les systèmes métier mettent en place des partitions et des frontières en désactivant les interactions qui existent entre les systèmes métier, excepté par des interfaces prédéfinies. Ces interfaces (éventuellement des accords de niveau de service formalisés) deviennent les charnières qui prennent en charge l'organisation. L'avantage le plus significatif de ces interfaces entre les systèmes métier est le découplage des parties de l'organisation les unes par rapport aux autres. Les dépendances sont définies en termes de responsabilités et non pas en fonction de la manière dont ces responsabilités sont exercées.

Séparer la spécification des responsabilités de la réalisation des responsabilités et relier les utilisateurs du système métier aux services spécifiés à sa frontière plutôt que de relier à la réalisation d'éléments à l'intérieur de la frontière du système métier se traduit par une organisation agile capable de changer rapidement sa structure sans dégrader la performance de ses processus. Dans une telle organisation, une des ses fonctionnalités (définies par un système métier) peut être modifiée, améliorée, ou externalisée et l'effet global sur le reste de l'organisation est réduit au minimum. Aussi longtemps que la qualité et le service restent les mêmes après le changement, les opérations métier peuvent se poursuivre sans interruption. Le même travail peut être réalisé par un système logiciel, une personne ou un service entier, sur site ou à distance.

L'utilisation d'événements métier permettant de rendre les interactions plus abstraites peut réduire encore plus les dépendances directes entre les systèmes métier. Dans la mesure où les événements métier rendent le temps et l'espace transparent, les systèmes métier peuvent interagir de manière indirecte (voir Instructions : Evénement métier).

Remarque : instructions de modélisation UML pour l'encapsulation

Lors de la modélisation d'un système métier avec le langage UML, nous avons indiqué dans la description du Produit : Système métier que si l'encapsulation n'était pas considérée comme importante, alors la frontière du système métier était théorique - comme mentionnée ci-dessus pour l'organisation statique traditionnelle - et, à des fins d'interaction au moins - le système métier n'existait pas lors de l' opération métier. Il est possible d'indiquer cela en langage UML en disant que le système métier (qui est une sorte de composant du langage UML) n'est pas directement instanciable - il n'existe qu'à travers l'instanciation de ses parties. Au cours de la prochaine section, nous aborderons l'offre de services par les systèmes métier : dans ce cas nous sommes concernés par l'encapsulation, et nous pouvons indiquer que le système métier possède une frontière plus que théorique en le rendant directement instanciable. Cela vérifie le système métier au moment de l'analyse et de la conception en anticipant le fait que, en mode opératoire, la frontière sera d'une manière ou d'une autre rendue réelle.

Les systèmes métier ont des responsabilités bien définies

Les systèmes métier définissent de manière explicite les responsabilités (également appelées services) qu'ils peuvent être amenés à exercer. Cette spécification ou comportement est essentiel car il permet le découplage des dépendances mentionnées dans la section précédente. UN système métier ne définit pas ses services sans signification. Il n'existe aucun moyen qu'un autre système métier puisse savoir les services qu'il offre que de les déduire de son nom. Par exemple, on peut s'attendre à ce qu'un système métier lié aux ressources (en termes structurels, il serait appelé Gestion des ressources) fournisse des services permettant de demander des ressources, d'émettre des requêtes sur la disponibilité, les types ou les profiles des ressources.

Les responsabilités (ou services) définissent les moyens d'interaction avec le système métier et sont spécifiées en tant qu'opérations(s) de l'interface ou des interfaces. Ces interfaces sont des collections de services associés et en tant que telles, elles décrivent le rôle que le système métier peut jouer dans une interaction particulière. Dans l'exemple illustré en dessous du prochain paragraphe, nous voyons que chaque interface est une collection de services reliés de manière logique. Ces interfaces (grappes de responsabilité) sont affectées au système métier responsable de l'exercice de ces responsabilités. Lorsque quelque chose d'externe au système métier nécessite un des services fournis, un événement se produit au sein du système métier afin d'initier l'accomplissement du service requis. Cet événement qui est interne au système métier, peut être explicitement défini en tant qu'événement métier. Les rôles et ressources (travailleurs et entités métier) au sein du système métier collaborent ensuite les uns avec les autres (de manière interne) afin d'accomplir le service requis. Comme nous pouvons le constater, cela ressemble à la manière dont l'entreprise opère envers sa clientèle. En fait, nous pourrions même modéliser le système métier en tant que "métier," dans lequel les demandeurs de services seraient les acteurs métier du système métier.

L'exemple ci-dessous illustre les systèmes métier d'une institution de services financiers générique. Seules quelques dépendances entre les systèmes métier et les interfaces sont illustrées afin d'améliorer la compréhensibilité. Ce diagramme montre la manière dont les responsabilités peuvent être réaffectées en allouant une interface à un autre système métier. Cette réaffectation de responsabilité n'aurait en théorie aucun effet sur les systèmes métier qui utilisent ces services.

Diagramme illustrant les systèmes métier d'une institution de services financiers générique.

Remarque : instructions de modélisation UML pour les services

Nous avons noté ci-dessus que la modélisation d'un système métier en tant que composant directement instanciable montre clairement que la frontière du système métier n'est pas simplement théorique. Nous pouvons poursuivre ce thème en modélisant les responsabilités des systèmes métier par une application analogue au profile UML 2.0 pour les services logiciels. Bien que s'adressant aux services logiciels, les idées fondamentales de ce profile s'appliquent de manière identique aux systèmes métier. L'utilisation des ports UML 2.0 pour modéliser les services vérifie encore plus la frontière du système métier en définissant des points d'interaction clairs avec des interfaces bien définies, entre les utilisateurs et les systèmes métier. Ces points d'interaction isolent complètement l'implémentation des responsabilités du système métier de leur fourniture aux clients à l'extérieur du système métier. Cette méthode donne également à l'analyste du processus métier, puis au concepteur métier un moyen de modéliser en souplesse la composition et la chorégraphie des services (afin de délivrer des services à valeur ajoutée à la frontière du système métier).

Les systèmes métier contiennent des rôles et des ressources

Un système métier est une abstraction d'un ensemble de personnes, de matériels, et de logiciels qui concourent à l'exécution des responsabilités du système métier. Nous utilisons le mot "abstraction" car nous ne décrivons pas les collaborations au sein du système métier en tant que personnes, machines et logiciels mais en termes de rôles et de ressources. Un système métier comprend des travailleurs et des entités métier. Un travailleur métier est un rôle qui représente un système tel que nous l'avons défini dans le glossaire. En ce qui concerne la modélisation métier, il s'agit d'un système de 'noeud terminal', c'est-à-dire que sa décomposition n'ira pas plus loin dans l'effort de modélisation métier. Lors de notre étude de modélisation métier nous pouvons être amené à décider que :

  • une personne (ou des personnes) peut être liée à un rôle de travailleur métier particulier, auquel cas nous pouvons lui attribuer le stéréotype de <<travailleur>>
  • le rôle sera rempli par un logiciel (et associé au matériel de calcul), auquel cas nous pouvons lui attribuer le stéréotype de <<système IT>>,
  • le rôle doit être réalisé par un système plus complexe, qui lui-même peut utiliser des ressources humaines, matérielles et logicielles - mais qui, pour certaines raisons, n'est pas considéré comme étant un système métier. Par exemple, dans l'exemple de l'aéroport ci-dessous, il est possible de modéliser le système métier 'Vols' contenant les travailleurs métier transportant les passagers, c'est-à-dire les avions. Les avions constituent des systèmes complexes à part entière, mais le fait de les décomposer, qu'il s'agisse de leur comportement et de leur conception, nécessite un changement significatif de paradigme par rapport à la pensée métier. Par conséquent, dans ce contexte, nous pouvons les laisser sous forme d'abstractions (même si nous serions certainement très intéressés de spécifier leurs caractéristiques - capacité de charge, rayon d'action et consommation de carburant, entre autres) et leur attribuer le stéréotype <<système>>.

Une entité métier est un morceau d'information créé ou manipulé par les travailleurs métier. Ces travailleurs métier peuvent en fait être mappés à des ressources humaines ou à des systèmes matériels ou logiciels spécifiques. Cette abstraction permet de se focaliser sur le rôle et les interfaces du travailleur métier et de déterminer les responsabilités nécessaires sans avoir à considérer la situation réelle (souvent imparfaite) d'une personne ou d'un système spécifique.

Notez que certaines des ressources détenues par un système métier peuvent être virtuelles - par exemple, un système métier peut partager un ordinateur central de grande envergure avec d'autres systèmes métier, mais en ce qui concerne les systèmes métier, ils possèdent une machine virtuelle. Le mappage de ressources virtuelles peut intervenir au niveau qui possède la ressource réelle - dans de nombreux cas il s'agira du niveau de l'entreprise (le métier global).

Les cas d'utilisation métier surpassent les systèmes métier

Les cas d'utilisation métier ne doivent pas simplement être affectés à un système métier. Les cas d'utilisation métier représentent les processus orientés client qui nécessitent la collaboration d'un certain nombre de systèmes métier, de partenaires et de fournisseurs. Cela est souvent appelé chaîne de valeur. Les systèmes métier concourent à la réalisation de cas d'utilisation métier, comme indiqué dans la figure ci-dessous.

Diagramme illustrant la collaboration entre un client, un partenaire, un organisme réglementaire et un fournisseur.

Il existe une exception : lors de la création de modèles métier à différents niveaux d'abstraction (voir Concept : Modélisation de grandes organisations), les cas d'utilisation métier peuvent être affectés à un système métier. Par exemple, il est possible que vous désiriez modéliser le métier dans son ensemble ainsi qu'un des systèmes métier de ce métier. Dans ce cas, il y aurait un modèle de cas d'utilisation métier pour l'ensemble du métier, dans lequel les cas d'utilisation métier globaux surpasseraient les systèmes métier (comme illustré ci-dessus). A un niveau inférieur, les services requis par un système métier particulier pourraient être enregistrés en tant que cas d'utilisation métier dans le modèle de cas d'utilisation métier du système métier. L'instruction stipulant que les cas d'utilisation métier ne doivent pas être affectés à un système métier doit s'entendre ainsi : "Un cas d'utilisation métier à un niveau particulier ne doit pas être affecté dans sa globalité à un seul système métier à un niveau inférieur."

Cette nature interfonctionnelle des cas d'utilisation métier constitue l'une des raisons de l'intérêt porté à la modélisation métier et à la réingénierie, ainsi qu'à l'analyse du coût et des performances des processus métier (voir Concept : Etablissement des coûts basés sur l'activité). Il est plus intéressant de comprendre comment les coûts du cas d'utilisation métier global sont liés à la valeur ajoutée fournie au client plutôt que de savoir comment le budget annuel de l'un des services est lié au budget d'entreprise global.

Exemples

Magasin de meubles

La figure ci-dessous illustre les systèmes métier relatifs au magasin de meubles utilisé comme exemple dans les Instructions : Objectif métier et les Instructions : Modèle de cas d'utilisation métier. Ce magasin gère les produits stockés dans un entrepôt situé à proximité de la salle d'exposition. Cela permet aux clients de consulter les produits affichés dans la salle d'exposition et de récupérer les produits achetés au niveau de l'entrepôt. Les clients peuvent se faire livrer les articles de grande taille.

Diagramme illustrant les systèmes métier relatifs à un magasin de meubles.

Ce métier a été divisé en trois systèmes métier différents. Chaque système métier se caractérise par un objectif précis et fournit des services bien définis (non visibles dans le diagramme). La définition explicite de ces interdépendances et interactions permet d'optimiser le métier.

Aéroport

Un aéroport offre des services à des compagnies aériennes, à des passagers et à des visiteurs dans l'intérêt des compagnies aériennes. Dans la mesure où un aéroport constitue un métier très large et très complexe à modéliser, il est judicieux de le diviser en un certain nombre de systèmes métier indépendants. Chaque système métier peut ensuite être modélisé de manière indépendante comme un métier à part entière, comme illustré ci-dessous.

Diagramme illustrant les systèmes métier relatifs à un aéroport.

Dans l'exemple ci-dessus, nous voyons qu'une compagnie aérienne participe aux systèmes métier Passagers et Vols. Le trafic aérien est régulé par le contrôle du trafic aérien en fonction de lois et de réglementations. Les hangars fournissent des services aux équipages au sol de la compagnie aérienne. Les passagers et les vols utilisent des services offerts par l'acheminement des bagages pour les départs et les arrivées. Le système métier divertissement pourrait également être appelé installations aéroportuaires et comprend les magasins, les zones d'attente, les parcs de stationnement et les transports.