Modéliser les processus identifiés

La seconde étape (figure 37) consiste à modéliser les processus précédemment identifiés.

Figure 37 : Étape 2 – Modéliser les processus identifiés

II.1.MODELISER HIERARCHIQUEMENT LES PROCESSUS

Les processus précédemment identifiés sont modélisés de manière à assurer leur coordination hiérarchique. Pour cela, il faut exploiter les relations hiérarchiques identifiées aux étapes I.1 et/ou I.4.

II.2.CADRER LES PROCESSUS CONTRIBUANT AUX ETATS-EDV« INTERMEDIAIRES » Pour chaque processus associé à un état-EDV « intermédiaire » :

(1) sont identifiés le ou les événements dont l’occurrence marque le début de cet état-EDV « intermédiaire ». Il est alors recommandé d’identifier la ou les activités (au sein du processus « étudié ») déclenchées par l’occurrence de cet ou ces événements. Pour chacune de ces activités, sont identifiées :

 l’unité organisationnelle responsable de cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 l’unité organisationnelle exécutant cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

(2) sont également identifiés par rapport à chacun des événements dont l’occurrence marque le début de cet état-EDV « intermédiaire » :

II. Modéliser les processus identifiés

II.1. Cadrer les processus contribuant aux états-EDV « intermédiaires »

II.2. Modéliser les processus

163

 l’état-EDV « amont » qui a pris fin par l’occurrence de cet événement ;  le processus « amont » correspondant à cet état-EDV « amont »;

 l’unité organisationnelle responsable de cet état-EDV « amont » et de ce processus « amont », ainsi que la cellule organisationnelle à laquelle elle est intégrée ;

 l’activité (au sein du processus « amont ») générant cet événement ;

 l’unité organisationnelle responsable de cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 l’unité organisationnelle exécutant cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 les EDV qui sont à la fois en sortie de l’activité (au sein du processus « amont ») générant cet événement et en entrée de la ou des activités (au sein du processus « étudié ») déclenchées par l’événement.

(3) sont également identifiés le ou les événements dont les occurrences respectives sont susceptibles de marquer la fin de cet état-EDV. Il est également nécessaire d’identifier par rapport à chacun des événements :

 l’activité (au sein du processus « étudié ») générant cet événement ;

 l’unité organisationnelle responsable de cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 l’unité organisationnelle exécutant cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 le ou les états-EDV « aval » qui débutent par l’occurrence de cet événement ; Pour chacun des états-EDV « aval », sont identifiés :

o le processus « aval » correspondant à cet état-EDV « aval » ;

o l’unité organisationnelle responsable de cet état-EDV « aval » et de ce processus « aval », ainsi que la cellule organisationnelle à laquelle elle est intégrée ;

o la ou les activités (au sein du processus « aval ») déclenchées par cet événement ;

164

 l’unité organisationnelle responsable de cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 l’unité organisationnelle exécutant cette activité et la cellule organisationnelle à laquelle elle est intégrée ;

 les EDV qui sont à la fois en sortie de l’activité (au sein du processus « étudié ») générant cet événement et en entrée de l’activité (au sein du processus « aval ») déclenchée par l’événement.

Ainsi, chaque processus contribuant à un état-EDV « intermédiaire » est cadré. II.2.MODELISER LES PROCESSUS

Les relations hiérarchiques entre l’ensemble des processus ayant été établie et les processus contribuant aux états-EDV « intermédiaires » étant cadrés (pour chacun de ces processus sont maintenant connus le ou les processus « amont », « aval »), il est maintenant possible de modéliser les processus de manière à illustrer leur coordination. Pour cela, il est utile de distinguer :

 les processus confrontés à des interfaces organisationnelles et qui (ou plus exactement leurs activités) sont articulés par des interactions ;

 les processus qui ne sont pas confrontés à des interfaces organisationnelles et qui (ou plus exactement leurs activités) sont articulés par des branchements.

165

Précisons que…

La modélisation des processus s’appuie principalement sur la « vue fonction » du méta-modèle proposé. Cependant, cette vue n’est pas indépendante des autres vues de modélisation, il est donc nécessaire d’en tenir compte. Tout modèle de processus peut s’accompagner de modèles complémentaires associés aux autres vues de modélisation. Pour cela, il est possible de faire appel à de multiples diagrammes. À titre d’exemple, le tableau 4 ci-dessous identifie quelques diagrammes issus des langages de modélisation graphiques UML et BPMN. L’usage de certains diagrammes illustre cette dépendance entre vues : dans un diagramme de collaboration, bien que l’on cherche à modéliser un processus étendu (vue réticulaire), des cellules organisationnelles et des unités organisationnelles (vue organisation) sont respectivement représentées par des « pools » et des « lanes ».

Vue fonction ^{Diagramme de processus (BPMN)} Diagramme d’états-transitions (UML) Vue réticulaire ^{Diagramme de conversation (BPMN)} _{Diagramme de chorégraphie (BPMN)} Diagramme de collaboration (BPMN) Vue valeur ^{Diagramme de classes (UML)}

Diagramme d’objets (UML) Etc.

Tableau 4 : Exemples de diagrammes soutenant la modélisant d’une organisation étendue

La modélisation est en entreprise « l'art d'externaliser des connaissances » (Vernadat, 1999). Cette connaissance est élicitée durant l’instanciation du méta-modèle proposé. Par ailleurs, pour un même besoin de modélisation, il existe de multiples langages de modélisation graphique (par exemple, pour modéliser des processus, BPMN propose le diagramme de processus et UML propose le diagramme d’activités). De surcroit, de notre expérience au sein d’un cabinet de conseil puis en tant que client de cabinets de conseil, nous retenons que le travail de modélisation est essentiellement confié à des consultants qui souvent, en l’absence d’outil dédié à la modélisation, ont simplement recours à PowerPoint. Clients et consultants s’accordent alors sur une syntaxe et une sémantique communes et basées sur les différentes « formes » proposées par PowerPoint, s’inspirant parfois de BPMN, parfois d’UML, etc. C’est pourquoi, dans ce travail, nous laissons libre le choix des types de représentation graphique qui sembleront les plus « user friendly », à condition de se référer au méta-modèle proposé.

166