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.
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.
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.
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.
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.
|