[A.MOUSSAFIR, A.CHAFII, J.MAS – FE13/FI13]

La notion de processus métier, apparue il y a une cinquantaine d’année, a jouée un rôle croissant dans l’étude des systèmes d’information. Aujourd’hui, la modélisation des processus métiers est souvent considérée comme un préalable indispensable pour la conception des systèmes d’information. Dans le monde de l’entreprise, il existe de nombreuses techniques ou méthodes qui permettent la modélisation de ces processus. Certaines d’entre elles sont ouvertes et gratuites, d’autres sont propriétaires et payantes, ont fait l’objet d’une normalisation ou non.

Devant ce large choix nous avons choisi d’en présenter trois, OSSAD, MERISE et IDEF0. Nous nous sommes intéressés à ces trois méthodes car elles sont issues de projets originaires de pays ou continents différents, respectivement, européen, français et américain. IDEF0 est une méthode normalisée alors qu’OSSAD et MERISE sont des projets publics. De plus, ces méthodes permettent d’étudier deux approches de modélisation différentes ; une structurée par l’intermédiaire d’IDEF0 et deux systémiques avec OSSAD et MERISE.

Le but de la présentation de ces méthodes sera de pouvoir les comparer afin d’en dégager les similitudes et différences, s’il en existe, que ce soit au niveau des concepts mais aussi de leurs domaines d’applications.

Avant de présenter et de comparer les méthodes, nous allons replacer le sujet dans son contexte en déterminant l’intérêt que portent les entreprises à modéliser les processus métiers. Mais tout de suite, nous allons définir ce que l’on appelle communément une méthode de modélisation.

u

Qu’est-ce qu’une méthode  de modélisation?

Une méthode est un ensemble comprenant un langage, souvent présenté sous forme d’un ensemble de modèles et diagrammes associés, ainsi que des préconisations sur la façon d’utiliser ces modèles.

Un langage de modélisation est un ensemble de concepts et de règles permettant de construire des modèles. Les éléments composants un langage de modélisation peuvent être représenté par un modèle, appelé métamodèle.

Un modèle est une représentation simplifiée de tout ou une partie d’un système d’information existant ou futur, mettant en évidence certains aspects essentiels. Pour élaborer un modèle, on s’appuie sur un métamodèle. On peut suivre des règles de construction, lorsqu’elles ont été énoncées.

Un diagramme correspond à la forme graphique d’un modèle. De même que le terme « modèle », le terme « diagramme » peut être employé à deux niveaux d’abstraction différents : c’est pourquoi on qualifie en général l’emploi du terme.

u

Pourquoi modélise-t-on les processus métiers ?

On modélise les processus métiers afin d’avoir une représentation de la structure et du fonctionnement du système et plus globalement de l’entreprise. Cette activité de modélisation permet de « mettre à plat » le système et d’en avoir une vision statique afin de formaliser les savoir-faire de l’entreprise et d’identifier ses forces et faiblesses dans le but d’établir un diagnostic. Cette étape de modélisation de « l’existant » correspond à une phase d’analyse. À partir du diagnostic réalisé, l’entreprise élaborera un plan d’actions qui aboutira sur la conception d’un nouveau système. Cette deuxième étape correspond à la phase de conception. Le plan d’actions à suivre dépend bien évidemment des objectifs qui ont été fixés soit initialement, soit à la suite du diagnostic. Ces objectifs peuvent être de différentes natures, comme l’amélioration du système à cause de dysfonctionnements, l’augmentation des performances du système, la réorganisation du système, l’intégration de nouveaux services, la fusion de plusieurs services, etc.

Le schéma suivi reprend de manière graphique ce qui vient d’être dit :

Les méthodes de modélisation sont donc utilisées pour, dans un premier temps, analyser les systèmes d’information existants et, dans un second temps, concevoir les futurs systèmes. Les méthodes qui existent proposent chacune leurs modèles d’analyse et de conception pour certaines. Il convient alors de bien choisir la méthode en fonction des objectifs que l’entreprise s’est fixés.

u

Présentation des méthodes

Pour chaque méthode sera décrit ses origines puis ses principaux concepts et modèles.

• OSSAD :

–  Les origines.

La méthode OSSAD (Office Support Systems Analysis and Design) est une méthode d’analyse d’organisation par les processus. Cette méthode résulte d’un projet du programme ESPRIT (European Strategic Programme for Research in Information Technology) réalisé de 1985 à 1990 par une équipe multinationale (allemands, anglais, finlandais, français, irlandais, italiens) et pluridisciplinaire, composée de conseils de chercheurs, d’universitaires et d’industriels.

OSSAD est conforme aux exigences de modélisation de la norme ISO 9000:2000 qui recommande une représentation des organisations en trois phases : les Processus, les Procédures et les Instructions de travail.

–  Les modèles.

La méthode OSSAD a une répartition en trois types de modèles.

Le modèle abstrait (MA) qui a comme objectif de formaliser les caractéristiques stables et durables du système ; le modèle descriptif (MD) qui décrit la façon pratique dont le travail est effectué ou sera effectué et le modèle prescriptif (MP) qui précise le détail de l’organisation et de la technique (OSSAD ne propose pas de représentation de ce modèle).

Dans le modèle abstrait, on trouve des concepts qui sont liés à l’activité, il s’agit des concepts de Fonction, Sous-fonction et Activité. La Fonction est le premier niveau de découpage de l’organisme fournissant un résultat ou regroupant plusieurs actions visant le même objectif ; les Sous-fonctions représentant des niveaux successifs de découpage et l’Activité étant le niveau le plus fin. Par ailleurs les fonctions ou sous-fonctions échangent des messages qui feront l’objet du concept de Paquet d’informations.

Le modèle descriptif propose les Rôles qui sont l’ensemble des Tâches/responsabilités effectuées par une personne : c’est la « fonction » professionnelle de l’individu. Les Acteurs qui sont des personnes remplissant un ou plusieurs Rôles et les Unités qui sont des regroupements de rôle sur la base de responsabilités identiques ou partagées, ou bien à des fins de coordination et de contrôle.

Les concepts liés au fonctionnement sont : la Tâche qui est une Activité ayant un Rôle ; c’est aussi un ensemble d’opérations. La Procédure qui est un regroupement de Tâches permettant de visualiser la totalité du travail d’une Activité et à l’opposé, l’Opération qui est un élément de la Tâche. Pour décrire les moyens, nous disposons du concept de Ressource qui est un ensemble d’informations groupées sous une forme concrète de stockage et de communication (c’est le pendant du Paquet) et de celui d’Outil qui est un moyen matériel ou logiciel permettant d’effectuer  le travail.

Niveau global

La « fonction » permet bien d’avoir une première description globale du processus dans la mesure où elle représente un premier niveau de découpage de l’activité basée sur l’objectif attendu. Cet objectif attendu peut être rapproché de ce que nous avons défini comme étant l’objectif du processus global.

Les itérations successives préconisées qui permettent la découverte progressive du processus peuvent être réalisées par le découpage des fonctions en « sous-fonctions ».

Le graphe de relations entre « fonctions » ou entre « sous-fonctions » permet de représenter le processus.

Niveau détaillé

Le processus détaillé sera représenté par une « sous-fonction », et les activités seront les « activités » d’OSSAD ou les « procédures » en fonction du niveau d’abstraction dans lequel ces processus seront décrits. La « tâche » décrite par OSSAD peut également décrire l’activité dans la mesure où le rôle lui est lié, et dans ce cas « l’opération » sera l’équivalent de la tâche.

Les concepts d’événement et de résultat seront représentés par les « paquets » d’information. La différentiation entre l’événement et le résultat se fait par le sens entrant ou sortant des flèches. Les événements temporels devront être considérés comme des paquets d’informations. La notion d’événement interne et externe n’est pas différenciée.

OSSAD détient un concept de « ressource » qui est le pendant descriptif du paquet et qui peut être utilisé au même titre que le concept de ressource des processus.

Les rôles et acteurs ont leur correspondance dans la méthode OSSAD qui ajoute aussi le concept « d’unité » organisationnelle.

u

• MERISE :

– Les origines.

MERISE (pour Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise) est une méthode d’analyse et de conception des systèmes d’information qui a vu le jour en 1974 suite à un projet commun entre la CETE d’Aix-en-Provence (Centre d’Etudes Techniques des Equipements, l’Université de Marseille et l’INRIA (Institut National de Recherche en Informatique et Automatique) liés par un contrat de recherche. En 1977, le ministère de l’industrie demande à ses instituts de créer une méthode de conception pour les projets de l’administration française, ce qui abouti en 1978 à la normalisation de la méthode sous le nom de MERISE. Plus tard en 1993, la méthode a été mise à jour afin de s’adapter aux évolutions techniques.

– Les modèles.

La méthode MERISE est basée sur un principe d’analyse des données d’un données d’un côté et des traitements de l’autre suivant trois niveaux d’abstraction (Conceptuel, Logique/Organisationnel, Physique/Opérationnel). L’analyse s’effectue alors par une approche abstraite pour aller vers une approche de plus en plus concrète.

MERISE propose plusieurs modèles en fonction du niveau d’abstraction. Chaque modèle est la représentation des données ou traitements résultant d’une question initialement posée. Le tableau suivant regroupe les différents modèles :

Modèle Conceptuel des Traitements (MCT).

Le MCT est la représentation des traitements à mettre en œuvre dans le système d’information en fonction des événements extérieurs sans s’intéresser à l’organisation qui régira ces traitements.

Pour formaliser le MCT, les éléments suivants sont utilisés :

Des processus : il s’agit de l’ensemble que compose les évènements, opérations, synchronisation et émissions.

Des évènements : il s’agit d’un déclencheur pour le lancement d’une opération ou le résultat d’une opération à destination du monde extérieur, ce dernier pouvant être le déclencheur pour le lancement d’une autre opération. Ils peuvent être internes ou externes au système d’information.

De synchronisations : il s’agit de la règle qui indiquant les événements et l’enchaînement de ces derniers nécessaires au lancement d’une opération. Il s’agit d’une expression logique composée essentiellement de OU et de ET.

D’actions : il s’agit des règles de gestion auxquelles doivent répondre les évènements.

D’opérations : il s’agit de la liste des actions à réaliser si la synchronisation associée est réalisée. L’ensemble des actions de l’opération s’exécute sans interruption ni attente d’événement.

D’émissions : il s’agit d’expression logique indiquant selon le résultat de l’opération quels événements internes au système d’information sont créés.

Exemple de représentation MCT :

Modèle Organisationnel des Traitements (MOT).

Le MOT est la représentation des processus du MCT auxquels on ajoute la dimension de l’organisation. On retrouve alors les ressources affectées à chaque traitement (humaines et matérielles) ainsi que les aspects saptio-temporels liés à chaque traitement.

Pour formaliser le MOT, les éléments suivants sont utilisés :

Des flux d’informations : équivalents aux évènements du MCT. Pour chaque flux d’information, on indique le type de support sur lequel il se trouve (papier, disque dur).

Des postes de travail : correspondent aux acteurs, intervenants ou lieux du système d’information. Ils peuvent être internes ou externes.

Des phases : équivalents aux actions du MCT. Pour chaque phase on indique son type. Le type peut être de trois sortes, manuel, interactif ou automatique.

Des tâches : correspondent à une description détaillée des phases.

Des procédures : équivalents aux opérations du MCT. Elles sont un regroupement de phases.

La représentation s’effectue sous forme de tableau dont les colonnes sont les postes de travail et les lignes apportent la notion de temps.

Exemple de représentation MOT :

u

u

u

u

u

• IDEF0 :

– Les origines.

IDEF0, Integrated Definition Language 0, fait partie d’une famille de méthodes appelée IDEF. A la base, IDEF était développée dans le cadre du projet ICAM (Integrated Computer Assisted Manifacturing) de l’US Force mené dans les années 1970 et qui visait à l’époque le développement des outils de production assistée par ordinateur. Le projet incluait l’élaboration de techniques de spécification. En effet, deux techniques ont été mises au point par la société SofTech de Douglas Taylor ROSS (D.T. Ross) : IDEF1 relative à la représentation de données et IDEF0 pour représenter des fonctions.  Ces deux techniques réunies ont été commercialisées par SofTech à partir de la fin des années 1970 sous le nom de SADT (Structural Analysis and Design Technical), méthode qui a connu une grande diffusion dans le milieu industriel et militaire.

En 1993, IDEF0 a été retenue par l’état américain comme standard fédéral pour la modélisation et le développement des systèmes d’information. Et depuis 1998, IDEF0 fait l’objet d’un standard IEEE.

Aujourd’hui, le noyau de la famille IDEF est représenté par 3 méthodes :

–  IDEF0 pour la représentation des fonctions

–  IDEF3 pour la représentation des processus

–  IDEF1X orientée données et informations

Nous avons choisi IDEF0 qui est plus souvent utilisée pour la modélisation des processus, et qui est normalisée IEEE.

–  Les concepts.

IDEF0 est présentée comme une méthode de modélisation permettant d’élaborer des représentations graphiques et structurés d’un système. Le concept principal est la décomposition du système de façon hiérarchique en faisant apparaître les fonctions de chaque niveau sous forme de boîtes et leurs interfaces. Le modèle décrit, ce que fait le système, ce qui le contrôle, sur quoi sur quoi il travaille, ce qu’il produit et les moyens mis en œuvre, à plusieurs niveaux de décomposition.

Un modèle IDEF0 se compose d’une arborescence de diagrammes, comprenant des fonctions, du texte et un glossaire. Un diagramme peut être décomposé en plusieurs diagrammes « enfants », chacun correspondant au détail d’une boîte – fonction. À l’exception du premier niveau, tout diagramme est rattaché à un diagramme « parent ». Chaque diagramme porte un numéro de nœud, un titre et un identifiant qui lui est propre. Le diagramme de premier niveau (nommé A-0) représente le système global ; il est appelé « diagramme de contexte ». Le texte qui l’accompagne décrit l’objectif du système.

Sur cet exemple, le diagramme contexte (A0) fait apparaître plusieurs sous fonctions au niveau inférieur. Seule la fonction 3 a fait l’objet d’une décomposition, comme l’indique le numéro du nœud au dessous de la boite (A3).

Il est recommandé de ne pas dépasser 6 niveaux de décomposition et d’avoir entre 3 et 6 fonctions à chaque niveau détaillé.

Chaque boîte à chaque niveau fait l’objet d’une numérotation précise : numéro de nœud (boîte parent), suivie d’un numéro de séquence dans le diagramme. Cette numérotation permet de dresser l’arbre des nœuds, c’est-à-dire le schéma complet de décomposition :

Arbre des nœuds

Le diagramme IDEF0.

Au niveau de la syntaxe, chaque diagramme est composé de boîtes et de flèches tout en respectant les règles suivantes :

–  Chaque fonction est représentée par un rectangle qui contient un verbe résumant l’objectif de la fonction

–  Toute flèche porte un nom ou une phrase nominale qui indique ce qu’elle représente. Elle est toujours rattachée à au moins une boîte par une de ses extrémités. Une flèche peut être horizontale, verticale ou coudée à 90°.

Les flèches dans un diagramme IDEF0 sont dites ICOM

u

Comparaison des méthodes

Pour comparer ces méthodes nous avons établi des critères qui passent en revue trois aspects :

• La représentation :

L’aspect représentation est associé à deux  critères.

– Le premier présente les principes sur lesquels se base les méthodes pour la construction de leurs modèles.

– Le deuxième présente la forme sous laquelle sont représentés ces modèles.

• La méthodologie :

L’aspect méthodologique est associé à sept critères.

– Le premier présente le type d’approche de la méthode.

– Le deuxième présente les différentes étapes que couvrent les méthodes.

– Le troisième présente le niveau de détail de ces étapes.

– Le quatrième présente le type de découpage qui est effectué pour appliquer la méthode.

– Le cinquième présente les points de vue abordés par la méthode.

– Le sixième présente la couverture ou non de l’aspect temporel de la méthode.

– La septième présente l’approche de développement de la méthode.

• L’adaptabilité :

L’aspect adaptabilité est associé à cinq critères.

– Le premier présente le type de système sur lequel peut être adaptée la méthode.

– Le deuxième présente la difficulté d’application de la méthode

– Le troisième présente la difficulté d’apprentissage de la méthode

– Le quatrième présente la réutilisabilité de la méthode.

– Le cinquième présente l’existence de support logiciel ou non.

Tableau de synthèse

À la vue de ce tableau, nous pouvons remarquer un grand nombre de similitudes entre les trois méthodes bien que leurs objectifs respectifs ne soient pas les mêmes.

Le concept de processus est présent partout. La description des flux de contrôle et des flux d’information est identique. En effet, elle repose sur des concepts communs :

– Des activités ou des opérations élémentaires qui doivent être effectuées et qui sont ordonnées de manière chronologique.

– Des swimlanes qui permettent de montrer quels acteurs ou quels rôles sont responsables de ces activités ou opérations.

– Des conditions et des opérations parallèles permettant de contrôler le déroulement ou la séquence de ces activités ou opérations.

– Des ressources en information et des outils qui sont liés aux activités ou opérations.

Cette correspondance directe entre les modèles n’est pas surprenant, dans la mesure où la représentation d’une séquence d’opérations ou d’activités est d’un faible niveau d’abstraction et doit coller à la réalité. À ce niveau, les trois méthodes peuvent être utilisées indifféremment pour modéliser un processus, le passage d’une technique à l’autre peut se faire facilement.

Comme nous venons de le mentionner OSSAD, MERISE et IDEF0 intègrent un certain nombre de concepts communs, même si la notation est parfois différente. Pour faciliter la mise en correspondance des ces concepts, nous les avons regroupé dans le tableau suivant :

Globalement, elles sont comparables mais se distingue sur certains points. Voici ce que nous pouvons retenir de chaque méthode :

–  OSSAD permet de couvrir tous les aspects de la modélisation de processus et ses différents niveaux de modèles sont fort bien articulés entre eux. Elle est la méthode qui assure le mieux la liaison entre les modèles structurels et le niveau abstrait grâce à la matrice activités-rôles. Elle reprend l’idée de processus, mais y ajoute le concept de paquet d’information et montre la circulation de paquets entre processus. Cette méthode intègre de plus l’idée de processus externe afin de représenter la circulation de l’information non seulement à l’intérieur d’une organisation, mais aussi entre cette dernière et son environnement. Elle permet de définir les rôles qui sont responsables d’activités données, et à une activité du niveau abstrait correspond une procédure définie au niveau opérationnel. Elle est destinée aux systèmes d’information, voit l’organisation uniquement comme un système ouvert finalisé. Son modèle abstrait (représentant ce qui doit être fait et pourquoi) nécessite un système stable et certain. Son modèle descriptif (représentant qui fait quoi et comment) apporte les solutions. OSSAD peut donc s’appliquer à un environnement semi-structuré. Au travers de ses diagrammes, OSSAD fournit des informations relatives à la pertinence et la qualité des données. Elles s’intéressent à l’analyse et à la spécification et laissent le choix à d’autres méthodes pour ce qui est de l’implémentation.

– MERISE considère l’organisation par ses échanges et ses actions par le MOT. Cette méthode préconise un découpage fonctionnel et est destinée aux systèmes structurés, stables et certains ce qui n’est pas le cas dans différents domaines d’application (ou entreprises). De plus, sa finalité orientée base de données relationnelles permet d’avoir une information qualitative et quantitative des données. Elle ne permet pas d’appréhender l’entreprise comme le fait OSSAD par exemple. De plus, elle est riche en concepts utilisés ce qui apporte de la difficulté au niveau de son apprentissage au contraire des deux autres méthodes. Mais sa principale limite se trouve être les environnements distribués, où de multiples applications externes à un domaine viennent interagir avec l’application à modéliser

– IDEF0 s’applique à l’analyse fonctionnelle de systèmes et donc aux systèmes cybernétiques. De par son analyse descendante, hiérarchique et structurée, elle ne peut s’appliquer qu’à des environnements stables, certains et structurés. Seul l’aspect qualitatif des données est pris en compte. Un aspect important de la méthode est qu’elle suggère une analyse prenant en compte le point de vue des différents intervenants humains. Cette méthode a fait ses preuves en tant que méthode d’analyse des systèmes complexes, mais elle ne prend pas en compte les aspects dynamiques du système. D’autre part, il y a une certaine confusion au niveau des flux représentés. La représentation utilisée par IDEF0 ne permet pas de distinguer les différents types de flux entrant et sortant d’une activité, ce qui peut amener une confusion dans l’interprétation du modèle. De plus, elle ne permet pas de représenter les interruptions de travail, ni les tâches parallèles Par contre, le formalisme graphique utilisé, composé de la boîte et des flèches fait de cette méthode un outil de communication puissant permettant de décomposer un système complexe, comme peut l’être un processus opératoire, en sous-système détaillés. Il arrive cependant que les utilisateurs de cette méthode tendent à interpréter les modèles comme une simple séquence d’activités linéaires, du fait de la représentation graphique généralement orientée diagonalement de gauche à droite et de la simplicité du formalisme utilisé. D’autre part, il y a une absence totale de la notion de temps et de synchronisation, contrairement à MERISE, ce qui peut paraître comme un manque à la méthode mais qui assure néanmoins de la concision au modèle. Ces modèles sont uniquement graphiques et ne peuvent être un support direct de simulation. IDEF0 est efficace pour l’analyse seulement et n’est pas une méthode permettant la ré-ingénierie de systèmes.

En définitive, nous pouvons dire que le choix de la méthode s’opère avant tout par le besoin que l’on recherche. Si l’on recherche une méthode qui permette de diagnostiquer un système déjà existant, les méthodes OSSAD et IDEF0 sont alors les méthodes les plus adaptées.  Ces deux méthodes ont été conçues pour la modélisation de processus et elles permettent de modéliser la structure et les objectifs d’une organisation. Cependant, IDEF0 est plus limitée ; OSSAD permet également d’optimiser les prises de décisions dans les organisations. De plus, bien qu’IDEF0 offre l’avantage de pouvoir analyser des systèmes complexes, elle est limitée au système structuré alors qu’OSSAD permet d’analyser n’importe quel système.

Si en revanche, l’on recherche une méthode qui permette de concevoir un nouveau système, MERISE sera alors plus adaptée.  C’est pourquoi OSSAD et MERISE ne sont pas vraiment en concurrence. Ce sont plutôt des approches complémentaires. OSSAD permettra de constater si le système est utile et performant par rapport aux objectifs fixés et MERISE viendra en aval poursuivre le travail effectué pour concevoir les objectifs fixés. MERISE est donc plus souvent utilisée pour les phases de réalisation que les phases d’analyse en amont.

u

Conclusion

L’objet de cette étude n’était pas de faire ressortir une méthode et de dire qu’elle est meilleure qu’une autre. Aucune méthode n’est complète et ne permet de modéliser tous les aspects d’un système, surtout lorsque le système est hautement interactif. Les méthodes n’apportent pas la solution à tous les problèmes, elles disposent de certaines qualités propres au traitement de problèmes spécifiques mais ont des lacunes au regard d’autres problèmes. Pour palier à ce problème, les méthodes sont souvent adaptées et viennent se compléter plutôt que de se concurrencer. Nous retrouvons, néanmoins, un point commun qui est visible pour toutes les méthodes. Elles recherchent à représenter dans un formalisme adapté les données issues de l’analyse du système.

Aujourd’hui, vu la multiplicité des méthodes il est difficile de connaître l’étendu et la réelle pratique de chaque méthode, surtout pour les méthodes issues de projets publiques comme MERISE ou OSSAD qui sont pour la plupart du temps utilisées que partiellement car chacun l’adapte et l’applique ensuite à sa manière. Nous pouvons tout de même supposer que les entreprises auront tendance à utiliser les méthodes issues de leur pays d’origine. En revanche, ce que nous savons c’est que MERISE qui était massivement utiliser avant les années 2000, est aujourd’hui, de moins en moins utiliser, notamment pour la conception des systèmes.

 

Sources :

http://univ-valenciennes.fr/LAMIH-intra/site/specifique/publications/666.pdf

http://www.ecole.ensicaen.fr/~elallam/mini_projet_html/livrable/livrable_methode_comparatif.pdf

http://agbo.insa-lyon.fr/ressources/fichiers/Mod%C3%A9lisation_des_pratiques.pdf

http://www.idheap.unil.ch/idheap.nsf/view/79DE76D92D88CE86C1256C71004401E5/$File/wp%2014-2002%20jlc.pdf