UNIVERSITÉ NATIONALE DE L'ALTIPLANO PUNO

FACULTÉ D'INGÉNIERIE MÉCANIQUE ÉLECTRIQUE, ÉLECTRONIQUE ET SYSTÈMES

ÉCOLE PROFESSIONNELLE D'INGÉNIERIE DES SYSTÈMES

ASIGNATURA: INGIENERIA DE PROCESOS

INGENIERO: JESUS WALTER CORDERO

TRABAJO:

MODÉLISATION DES PROCESSUS

PRÉSENTÉ PAR :

Coila Ticona Jehan carlos

PUNO–PÉROU
 PRESENTACIÓN

La notation des processus d'affaires est une matière qui fournit des connaissances sur les
fondements de la gestion des processus d'affaires, à travers un contexte historique pour comprendre
mieux l'évolution de l'ingénierie des processus. De plus, on considère les concepts de
mise en œuvre, pour connaître et comprendre les définitions qui facilitent la compréhension de la portée du BPM,
la deuxième partie intègre aux modèles de procédure le soutien technologique dans chacune des
couches du BPM et enfin la notation BPMN est présentée dans le but de l'appliquer à des cas de
[Link] résultat d'apprentissage:À la fin de la matière, l'étudiant sera capable de
élaborer des modèles de divers processus commerciaux, en utilisant les principes du Business
Gestion des processus (BPM) et éléments de notation du Business Process Model and Notation
(BPMN), basé sur une plateforme de conception, de simulation et d'automatisation des processus comme

représentation standard pour les besoins d'une organisation.

Le présent matériel se compose de quatre unités : Unité I : APPROCHE : PROCESSUS D'AFFAIRES

LA GESTION (BPM) présente des concepts, et des principes de base, l'organisation et la structure de
BPM. Unité II : ARCHITECTURE D'ENTREPRISE (AE) DANS LE CONTEXTE
LA GESTION DES PROCESSUS METIERS BPM présente des concepts et les relations entre les normes
existantes pour la gestion d'entreprise basée sur les processus. Unité III : PROCESSUS D'AFFAIRES
GESTION (BPM) ET LA MODÉLISATION BUSINESS PROCESS MODEL AND NOTATION (BPMN)
présente les éléments de notation de la notation des processus métier (BPMN). Unité IV :
AUTOMATISATION DES PROCESSUS AVEC LA GESTION DES PROCESSUS MÉTIERS (BPMN),
présente des outils de simulation et d'automatisation, développés à partir du texte BPM : Business
Gestion des Processus Fondamentaux et Concepts de Mise en Œuvre (HITPASS, Bernard, 2014).
Il est recommandé que l'étudiant développe une lecture d'étude permanente en plus de la
élaboration des modèles de processus, ainsi que la recherche dans d'autres textes et sur internet. Le
Le contenu du matériel sera complété par les leçons en présentiel et à distance qui se
développent dans la matière.
 UNITÉ I
INTRODUCTION ET DÉFINITION DU BPM

Thème n° 1 : Introduction au BPM

1.1 Antécédents du BPM

(HITPASS, 2013)
La mondialisation exige des exigences plus élevées, tant des entreprises privées que des
organisations publiques, dans leur capacité de réaction face aux changements exigés par le marché.
Ceux-ci peuvent être des changements dans le type de demande ou des changements de réglementations.

Il existe de nombreuses définitions du BPM. Bien qu'elles aient toutes quelque chose en commun, il en existe aussi.

différences, surtout en ce qui concerne la portée. Certains auteurs et experts, en particulier en Europe, restreignent

le BPM en tant que discipline de gestion sans inclure explicitement le soutien des TI. D'autres auteurs définissent

BPM comme le processus vers l'automatisation et l'opération des processus implicitement avec les TI.
Le concept de BPM est même plus large, mais cela dépendra de quels sont les objectifs que
nous poursuivons avec BPM, que généralement toutes les écoles partagent. En général les
les différences entre les écoles se trouvent dans le concept de la manière d'aborder le processus vers le
atteinte des objectifs et chaque concept commence par une définition, c'est pourquoi certaines définitions
se différencient des autres. La description des objectifs est claire et bien définie.

1.2 Histoire et Évolution

Évolution de l'Ingénierie des Processus vers le BPM Source :

(HITPASS, 2013)
1.2.1 L'ingénierie des processus naît avec Frederick Taylor

(HITPASS, 2013)
L'idée que les activités (le travail) peuvent être décrites comme un processus n'est pas nouvelle. À
au début du siècle dernier, Frederick Winslow Taylor (1911) a élaboré le concept de la
«Administration Scientifique» (Taylor a publié peu avant de mourir (1915) en 1911 son œuvre qui le fit
si fameux « Les Principes de la Gestion Scientifique ».) [TaylorFre08]. À Taylor, on attribue d'avoir
développé les principes de la spécialisation et de la normalisation des processus de production
industrielle les élevant à une science que nous pourrions appeler « ingénierie industrielle et amélioration de

processus», raison pour laquelle de nombreux auteurs l'appellent le père de l'ingénierie industrielle.
Taylor apporte des méthodes d'observation des bonnes pratiques, de mesure du travail et à partir de
ces connaissances sur la conception de processus industriels décomposés jusqu'au niveau d'activité
manuel (Taylor parlait de « gestion des tâches ») hautement spécialisés pour réussir
améliorations substantielles de la productivité.

Les principes de l'administration scientifique que décrit Taylor dans son œuvre peuvent se résumer selon
(Bravo, 2011) en les quatre étapes suivantes :
1.Développer l'étude scientifique du travail, une "science" selon Taylor
2. Sélectionner scientifiquement l'ouvrier le plus adapté à la tâche, selon ses capacités, et ensuite
l'instruire sur la façon de faire correctement la tâche, selon le point précédent.
3. Coopérer avec les ouvriers pour que tout le travail soit fait conformément aux principes
scientifiques qui s'appliquent. Il fait référence à une coopération entre les chercheurs et de
administrateurs. Harmonie est le mot principal utilisé par Taylor.
4. Distribuer équitablement le travail et la responsabilité entre la direction et les ouvriers.
Juan Bravo (Bravo, 2011) dans son livre indique ce qui suit sur Taylor :
Nous pouvons résumer que l'objectif poursuivi par Taylor en réunissant des faits et des mesures était

fournir une base scientifique pour concevoir et améliorer les processus. Avec ces fondements
Il avait l'intention de mettre fin à l'improvisation qui prédominait à cette époque. Au lieu de faire que
chaque travailleur faisait la tâche à sa manière, Taylor voulait trouver la façon optimale de le faire et
standardiser les bonnes pratiques en les rendant plus efficaces et atteindre des économies d'échelle. Ce
L'approche a été utilisée avec succès tout au long de l'époque de l'industrialisation (marché de l'offre)
durant le XIXe siècle et au début du XXe siècle, mais cette technique était restreinte aux processus
manuels et à la production industrielle et n'incluait pas le suivi des processus de gestion.
1.2.2 Le passage du marché de l'offre au marché de la demande

(HITPASS, 2013)
Plus tard, au début des années 80, des approches statistiques sont apparues dans le but d'améliorer
les processus de contrôle. Ainsi est né l'approche TQM (Gestion de la Qualité Totale) basée sur une
gestion du contrôle statistique, mais l'appliquer nécessite une discipline rigoureuse dans l'organisation
ce qu'est le Management) basé sur une gestion de contrôle statistique, mais l'appliquer nécessite un
une discipline rigoureuse dans l'organisation qui est difficile à atteindre.
Les entreprises japonaises, en particulier Toyota, ont reconnu au début des années 90 le changement vers le
marché de la demande et ont orienté la gestion vers les besoins de l'entreprise
(clients).
Remarque : Dans le « marché de la demande », l'offre est supérieure à la demande, ce qui signifie qu'en économie

il en ressort que le pouvoir d'achat est plus influent que le pouvoir qu'ils peuvent exercer
fournisseurs sur les marchés où ils opèrent.
Toyota a développé le concept de Toyota Production System (TPS)[ Liker06]. Celui-ci se caractérisait par
contar con una estructura organizacional muy plana, instalando equipos multidisciplinarios en
centres de production et chargés de résoudre de manière autonome des propositions d'amélioration
continue dans les processus de production. Ce système de travail a également été appelé Lean
Production, indiquant à enlever la graisse des structures organisationnelles bureaucratiques et lentes dans
ses processus de décision.
Lorsque dans les années 90 de nombreuses entreprises occidentales ont été frappées par la récession, en raison de

que les marchés avaient atteint une situation de surproduction (saturation, changement vers le
marché de la demande) et le début de la mondialisation, apparaît le Business Process
Réingénierie (BPR, Hammer et Champy, 1993) (Hammer, M. et Champy, J., 1993) comme mesure
de salut pour débureaucratiser les entreprises et être plus efficaces dans leurs processus commerciaux.
1.2.3 La réingénierie des processus comme précurseur de BPM

(HITPASS, 2013)
La réingénierie des processus métiers BPR tiene como finalidadrediseñar y hacer más eficientes
les processus, en attaquant les structures hiérarchiques fonctionnelles et en les alignant avec les objectifs de
affaire, cherchant à atteindre des résultats de performance spectaculaires à court terme. La réingénierie
de processus repose et s'appuie fortement sur l'incorporation des technologies de l'information,
comme élément clé pour la transformation attendue. Le BPR est la première approche de bout en bout.
introduire en tant que gestion les processus d'affaires transversaux aux organisations fonctionnelles,
centrés sur les besoins du client et non sur les processus de production, mais cela n'a pas été facile,
beaucoup de projets de BPR se sont terminés par des projets de rationalisation des ressources avec une

forte réduction de personnel. Perdre, souvent, la perspective d'ajout de valeur pour

le client. Le BPR n'a pas été la seule approche à apparaître dans ces décennies, au début des années 80
Six Sigma est apparu comme une option pour améliorer l'efficacité et l'efficience des processus de
affaires. Cette approche est née chez Motorola Inc. et le cas pratique d'application le plus connu était
General Electric en los ’[Link] TQM, Six Sigma se basa en principios estadísticos para mejorar
les processus de contrôle et d'amélioration. L'acronyme Six Sigma signifie "un défaut de sortie sur six standards"

les déviations d'une distribution de probabilité pour un résultat de processus particulier. Les techniques de Six Sigma se

emploient sur la base d'épisodes ou d'événements, qui devraient être au niveau de

exigence définie pour le processus (quantité de Sigmas), mais n'incorporent pas une pensée de
amélioration continue. De nombreuses entreprises combinent l'approche Six Sigma avec le TPS ou la production Lean.

On ne peut pas encore prédire comment Six Sigma va continuer à évoluer, mais malgré cela, on détecte
Les signes de fatigue sont encore très répandus dans les entreprises nord-américaines (Davenport, forward

BPM Jeston et Nelis, 2008) (John Jeston & Johan Nelis, 2008). Au milieu des années 90 apparaît la
les ERP (Enterprise Resource Planning). Les ERP ont été présentés comme la solution pour
tous les problèmes au sein de l'organisation, mais les ERP n'ont pas généré l'efficacité et l'efficience
attendue dans les processus commerciaux, ils étaient conçus pour améliorer l'efficacité administrative.
A fines de los años 90 y a principios del 2000 aparecieron los sistemas Customer Relation
Gestion (CRM) comme mesure pour améliorer les services aux clients, mais nous ne disposions pas encore
avec une intégration entre les processus du front office (CRM) et ceux du back office (ERP).
Thème n° 2 : Concepts de base du BPM

2.1 Définition du Processus

(HITPASS, 2013)
En principe, un processus correspond à la représentation d'un ensemble d'actions (activités)
que se font, sous certaines conditions (règles) et qui peuvent déclencher ou exécuter des choses (événements). En
de manière générique, on peut définir un processus comme :

«Une concatenation logique d'activités qui remplissent un objectif déterminé, à travers le temps et
lieu, poussées par des événements.» Cette définition contient les principaux éléments qui décrivent
un processus : Les événements sont des occurrences externes qui initient un processus, c'est-à-dire qu'un processus ne

il commence de lui-même, quelque chose doit se produire et le processus réagit à l'événement. Le processus doit
atteindre un but déterminé, dans les sciences économiques destinées à produire des biens et des services.
À la différence des événements, les activités dans un processus consomment du temps et des ressources. Une

L'activité peut être définie comme une «action sur un objet», c'est-à-dire le processus de transformation.
cela se produit à travers les activités dans un processus.

Les activités d'un processus sont enchaînées par une séquence logique qui détermine
Dans l'ensemble, les conditions de l'entreprise.
Ces éléments de base décrivent dans leur ensemble les processus et sont contenus dans la plupart
des notations pour les modéliser, ainsi que dans la norme BPMN. La définition est pure, elle ne dit pas
rien concernant les objectifs pour lesquels des processus sont établis et modélisés dans une organisation.

Exemple de processus : Processus d'inscription à l'université

(Source :[Link]
Ejemplo de proceso: Proceso de Elaboración de calzado artesanal
(Source :[Link]

Étape 1 : Sélection et acquisition du matériel.

Étape 2 : Sélection du modèle et coupe à réaliser.
Étape 3 : Assemblage de la pelle.

Étape 4 : Montage.
Étape 5 : Démontage.
Étape 6 : Terminé.
Étape 7 : Emballage et distribution.

2.2 Processus d'Affaires

(Hammer, M. et Champy, J., 1993) Introduisent dans leur ouvrage de Réingénierie des Processus en 93,
el concepto de proceso de negocio:
Un processus d'affaires est un ensemble d'activités qui prennent un ou plusieurs types d'entrées et créent
un résultat qui a de la valeur pour un client.
Les processus d'affaires sont ceux qui créent de la valeur pour un client, c'est-à-dire que la définition est liée

au concept de création de valeur pour le client. Suivant la définition proposée dans ce travail
d'un processus en forme générale, on définira un processus d'affaires comme :
Un processus d'affaires est un ensemble d'activités qui, déclenchées par des événements, sont exécutées.
dans une certaine séquence, ils créent de la valeur pour un client (interne ou externe).

Un processus d'affaires se reconnaît par le type d'événement qui le déclenche. L'un des principaux
les caractéristiques d'un processus métier sont qu'il est déclenché par le client et les résultats de la
l'exécution du processus doit revenir au client, compris dans le sens le plus large que le
Le client peut également être interne, par exemple un service de l'entreprise, ou externe, un fournisseur.
L'ingénierie industrielle est connue sous le nom de processus pull, le client tire le processus commercial.
différence entre le processus Push, où les objets sont « poussés » à travers le processus pour arriver au client.
Le concept de processus Pull et Push est lié à la manière dont ils sont planifiés, distribués
y reponen les produits en entrepôt (logistique). Il existe deux manières de couvrir ce cycle :
1. Dans le concept push, la demande est calculée sans connaître les commandes des clients (par exemple
Les représentations de voitures au Chili fonctionnent ainsi). Ils importent des voitures et puis les vendent.

[Link] le concept de pull, on ne planifie et ne produit des biens qu'en fonction de la demande réelle et est très

lié au concept de juste à temps, il s'agit de réduire au minimum les processus de stockage
intermédiaire. Dell, par exemple, est devenu célèbre dans les années 90 en appliquant ce concept à l'extrême.
Elle n'est produite que sur demande réelle (commande d'achat) du client. Il est normal de trouver dans de nombreuses

entreprises combinaisons des deux types de flux, en particulier pour répondre avec plus
opportunité aux exigences des clients. Le processus métier est transversal aux domaines et
traverse la chaîne de valeur de bout en bout (le terme anglo-saxon «end» est également beaucoup utilisé)
À la fin). Ce principe est indifférent qu'il s'agisse d'un client externe (client final) de l'entreprise ou
client interne.
On confond souvent les macroprocessus avec les processus d'affaires.
En général, les macroprocessus correspondent aux grandes zones d'activité d'une entreprise.
comme par exemple approvisionnement, production, entrepôt, vente, etc. Aucun client externe va à
déclencher un processus dans le domaine de l'approvisionnement et les processus dans ce domaine ne traversent pas non plus la

chaîne de valeur de l'entreprise.

Bien que ces domaines puissent être très vastes et très complexes, ils n'ont pas de relation directe avec le

concepto de proceso de negocio: gatillado por el cliente, de principio a fin y el resultado tiene que
être de la valeur pour le client.

Les processus d'affaires se situent en dessous des macroprocessus et les traversent. En cartographiant
Les processus d'une organisation commettent souvent de grandes erreurs à cet égard. Si
les macroprocessus sont décomposés en «haut vers le bas» et les processus internes des domaines vont être cartographiés

à différents degrés d'abstraction, et ce ne sont justement pas les processus d'affaires.

Comment peut-on alors identifier les processus d'affaires ?

À cette fin, il est recommandé de réaliser une analyse du contexte et de dresser une liste de tous les
événements initiés par le client. Voici quelques exemples de processus d'affaires :
Solicitudes de créditos, préstamos, devoluciones Solicitud de apertura de cuenta bancaria Compra
de passages Processus de réclamations Suivi de la résolution des problèmes dans le Service à
Clientes Gestión de Hipotecas, Multas,... Recepción y pago de factura Recepción y confirmación
de commande Élaboration d'offres

Les exemples suivants ne peuvent pas être classés comme des processus d'affaires.

Partie double comptable : • Il s'agit d'une fonction comptable qui suit un mouvement
comptable.
Reserva de pasajes: • Se trata de un subproceso del proceso de negocio «compra de pasajes».
Dans ce cas, le principe de finalité n'est pas respecté, qui serait l'achat du billet.
Intégration d'un nouvel employé dans le système des RH : • Activité manuelle du processus métier
«recrutement de personnel». Le client interne est le domaine d'activité, qui déclenche la demande de
embauche.
Enregistrement d'un bon de commande : • Activité manuelle du processus métier « achat d'un
produit ou service
Envoi d'email : • Activité technique sans signification commerciale
Émettre une police : • Émettre peut signifier imprimer, générer ou étendre une police d'assurance, mais
de toutes façons, le processus commercial serait «demande d'un contrat d'assurance»
 Vous devez faire attention à ne pas confondre le concept de « chaîne de valeur » proposé par Porter avec le
concept de «processus d'affaires» qui est lié au concept de valeur pour le client. La figure
montre la structuration typique d'une chaîne de valeur décomposée en processus de direction,
processus principaux et processus de soutien, les processus principaux étant les processus de la
«chaîne de valeur» parce qu'ils sont directement liés à la création de biens et de services
pour le client externe, mais la chaîne de valeur n'est pas la même que les services qu'ils demandent
clients.

Figure Structure de la Chaîne de Valeur selon Porter

SOURCE : (HITPASS, 2013)

La figure suivante montre la transversalité des processus d'affaires qui sont impulsés par
clients et dont les résultats doivent leur revenir.

Figure Structure des processus d'affaires

SOURCE : (HITPASS, 2013)

La chaîne de valeur montre les dépendances dans les étapes de production, tandis que les processus
les dépendances des politiques commerciales pour répondre aux demandes des
clients et les amener à un résultat satisfaisant qui a une expression de marché, c'est-à-dire le client
est prêt à payer (création de valeur).
2.3 Gestion des processus d'affaires ou par processus d'affaires ?

Actuellement, les deux termes sont très utilisés, à la fois Gestion par processus et Gestion de

processus, et il est important de savoir s'il existe une différence entre les deux termes :

(HITPASS, 2013)
Dans une organisation, il existe de nombreux processus métiers. Si nous faisons référence à la gestion d'un processus

en particulier, nous parlons de « gestion de processus ».

Généralement, le premier objectif dans les organisations est d'obtenir un meilleur contrôle et des performances.

sur les processus.

Le contrôle des maires signifie avoir une connaissance en temps réel de l'état de chaque
les processus instanciés.
Par exemple, connaître la charge de travail de chacun des utilisateurs et savoir quels processus
ils sont bloqués pour une raison quelconque.
Cette information permet au superviseur (gestionnaire du processus) de détecter les problèmes avant que

impactent sur les résultats. En ayant un meilleur contrôle sur ce qui se passe, nous pouvons
mejorar el desempeño de los procesos, por ejemplo acortar los tiempos de ciclo y en general mejorar
le degré de satisfaction du client.
En introduisant «gestion des processus» dans une organisation, nous avons la possibilité d'améliorer le degré
de conformité aux objectifs fonctionnels, mais ce n'est pas un instrument suffisant pour aligner la
gestion des processus avec la stratégie de l'organisation et ses objectifs commerciaux appropriés.
La gestion des processus se concentre sur la mesure et l'analyse de la performance des processus dans

opérations, mais n'inclut pas les concepts d'alignement avec d'autres couches de l'organisation, par
exemple l'intégration aux processus d'alignement avec la stratégie et la couche technologique.
La gestion par processus signifie inclure les processus de planification et d'alignement à la gestion de
processus.
Entre les universitaires et les professionnels du BPM, le principe selon lequel « les processus
ils doivent suivre la stratégie» et que «la technologie doit suivre les processus.
La gestion des processus n'inclut pas ces cycles de planification et d'alignement aux processus comme
la discipline de gestion BPM le demande, mais si nous élargissons le concept de gestion et intégrons les autres
disciplines d'entreprise à la gestion des processus, alors nous parlons de « gestion par processus »
et dans sa définition la plus large en anglais de la gestion des processus d'affaires (BPM).

Dans la gestion des processus, nous nous concentrons sur le résultat de chaque processus et les actions à réaliser.
(amélioration continue, réingénierie ou innovation).
Identificación de los procesos y planificación de los Objetivos a conseguir con cada proceso. (Fase
de Modélisation et Planification des Processus
Mesure des résultats des indicateurs dans l'exécution ou le fonctionnement des processus
(Phases d'automatisation et d'exécution des processus)
Control de la consecución de los indicadores al compararlos con los objetivos y definición de
actions correctrices (Phase de Surveillance)
Dans la gestion par processus, nous nous concentrons sur l'alignement de la gestion des processus avec la stratégie
entrepreneurial et avec le reste des gestions d'entreprise :
La gestion des processus afin que chaque processus produise le résultat attendu
La alineación de cada proceso con la Estrategia Empresarial, de esta forma sabremos qué aporta
chaque processus à chaque objectif stratégique, et défini un objectif stratégique à quels processus il affecte et
s'il est nécessaire de les optimiser
La culture d'entreprise sera cohérente avec un système de gestion des processus
La gestion et la direction du personnel seront réalisées avec un focus sur les processus
Les différentes gestions de l'entreprise s'aligneront avec la gestion par processus

Source[Link]
2.4 Gestion traditionnelle sans BPM

Pour conceptualiser et comprendre la différence entre la gestion de et par processus, il est important de réaliser
une rétrospective, et savoir comment fonctionnait une organisation sans BPM.

(HITPASS, 2013)
Pour répondre à cette question fondamentale, nous allons d'abord analyser comment fonctionne la gestion.
traditionnelle centrée sur la consolidation des plans d'affaires par domaine et non par processus d'affaires qui sont

transversales à l'organisation.
En général, la formulation de la stratégie d'une entreprise est large et définit les grandes étapes.
que doivent être atteints et surtout sur quoi il faut se concentrer pour remplir la mission de l'entreprise
et les objectifs commerciaux qui se formulent à travers le cycle budgétaire d'une année commerciale,
mais la stratégie est transversale aux domaines d'activité, tout comme les processus d'affaires. Ici
nous nous trouvons dans la gestion d'entreprise traditionnelle avec le premier fossé.

D'une certaine manière, les objectifs commerciaux sont transférés de la haute direction au niveau de
opérations et en même temps opérations formule, au moyen d'une spécification, les exigences
de changement de la couche technologique, mais ce processus n'est pas standardisé et encore moins intégré sous
une méthodologie commune. En l'absence de standardisation ou d'intégration, des frictions surviennent et donc

perte de valeur. Comme la stratégie est transversale et qu'il n'existe pas de poste responsable pour
le rendement du processus complet, c'est-à-dire de principe à fin, les processus d'alignement sont
lents et coûteux. Cela entraîne une perte de valeur dans trois grands domaines de la gestion
entreprise traditionnelle, à savoir :
[Link] concrétiser la stratégie dans l'organisation
[Link] faire en sorte que les processus soient mis en œuvre avec la technologie

[Link] de valeur dans la structuration même des processus

Voici les trois grandes raisons (opportunités) d'implémenter la gestion par BPM. La contribution
del concept de BPM en tant que discipline intégrée est de combler ces lacunes.
2.5 Gestion des processus d'affaires (BPM)

C'est une méthodologie d'entreprise et une discipline de gestion, dont l'objectif est d'améliorer la performance.

(efficacité et efficacité) et l'optimisation des processus commerciaux d'une organisation, à travers

de la gestion des processus qui doivent être conçus, modélisés, organisés, documentés et optimisés
de manière continue. Par conséquent, il peut être décrit comme un processus d'optimisation des processus.
Le modèle de gestion par processus fait référence au changement opérationnel de l'entreprise, à
migrer d'une opération fonctionnelle à une opération gérée par des processus.
Le BPM est la compréhension, la visibilité et le contrôle des processus d'affaires d'une organisation.
Un processus d'affaires représente une série discrète d'activités ou d'étapes de tâches qui peuvent
inclure des personnes, des applications, des événements d'affaires et des organisations.

BPM peut être lié à d'autres disciplines d'amélioration des processus telles que Six Sigma. Les processus
les processus métier devraient être documentés (mis à jour), pour aider à comprendre l'organisation
ce qu'ils font à travers leur entreprise.

Nous détaillons d'autres concepts de BPM :

(John Jeston & Johan Nelis, 2008) : « La gestion des processus métier (BPM) est l'atteinte des objectifs d'affaires à travers la

améliorer, la gestion et le contrôle des processus d'affaires.

Dans cette définition, il est explicitement abstrait que la technologie va résoudre les problèmes à la
organisations.

Paul Harmon (Harmon, 2007) définit également le BPM comme : « Une discipline de gestion axée sur
l'amélioration de la performance des entreprises par la gestion des processus d'affaires.

Enfin, Jeston et Nelis (John Jeston & Johan Nelis, 2008) concluent que la BPM est :
Plus que du logiciel, plus que simplement l'amélioration ou la réingénierie des processus, ce n'est pas seulement
une mode, est une partie intégrante du management, plus que simplement le levage et le modélisation de processus,

c'est aussi la mise en œuvre et l'exécution des processus, qui nécessitent d'être analysés et
améliorés.
Facteurs critiques de la BPM selon Jeston et Nelis :
L'atteinte de la stratégie organisationnelle
L'organisation est alignée avec les processus de bout en bout
Les objectifs sont alignés avec la stratégie organisationnelle
Les processus doivent améliorer leur efficacité et être efficaces. Gestion orientée vers les processus.
(Gestion)
Contrôler le cycle complet de BPM
Sélectionner les processus critiques, tous les processus ne contribuent pas à l'atteinte des objectifs
stratégiques

La mise en œuvre du BPM doit avoir un impact sur les bénéfices de l'entreprise Notre définition a un
portée large et englobe à la fois la discipline de gestion et l'incorporation des TI pour la
automatisation des processus.

Nous définissons de manière abrégée BPM comme : « Discipline de Gestion par Processus Métier et de
Amélioration Continue fortement soutenue par les Technologies de l'Information

Une définition plus large se trouve dans le guide de référence de l'Association Internationale.
de Professionnels de BPM (BPM Common Body of Knowledge, ABPMP (Association de BPM
Professionnels) (Tony Benedict, Nancy Bilodeau, Phil Vitkus, Emmett Powell, Dan Morris, Marc
Scarsig, Denis Lee, Gabrielle Field, Todd Lohr, Raju Saxena, Michael Fuller, Jose Furlan, 2013) :

La gestion des processus métier (BPM) est une approche systématique pour identifier, relever,
documenter, concevoir, exécuter, mesurer et contrôler à la fois les processus manuels et automatisés,
dans le but d'atteindre de manière cohérente les objectifs commerciaux à travers ses résultats
qui sont alignés avec la stratégie de l'organisation. BPM englobe le soutien croissant
de TI dans le but d'améliorer, d'innover et de gérer les processus de bout en bout, qui déterminent
Les résultats commerciaux créent de la valeur pour le client et permettent d'atteindre les objectifs commerciaux.
avec plus d'agilité.

Comme l'indique (HITPASS, 2013), la définition de l'ABPMP, BPM est une discipline intégratrice.
qui englobe des techniques et d'autres disciplines organisationnelles, qui couvre les couches de l'entreprise et

technologie, qui se comprend comme un tout intégré dans la gestion à travers les processus. Nous
nous penchons pour cette définition car elle fait la différence entre les processus manuels et automatisés, mais

intégrer les deux cas dans la discipline de BPM. Avec cette définition, nous visons à atteindre un

compréhension commune qui est nécessaire pour réussir à introduire le BPM dans une organisation. Pour
Pour atteindre les objectifs visés en BPM, il est nécessaire de synchroniser et d'intégrer les processus.
manuels avec les mises en œuvre avec le soutien des TI ou ceux qui vont être automatisés.
Thème n° 3 : Organisation et structure du BPM

3.1 Concepts de Gestion dans BPM

BPM attaque l'automatisation des processus dans toute l'entreprise, mais avec une totale adhésion à la
modifications commerciales qu'un marché de forte compétition exige. Il n'existe pas de combinaison
unique et exacte des processus, méthodologies et indicateurs, et dans de nombreux cas, ceux-ci existent

aisladamente.
Un outil de BPM doit prendre en charge les activités de base de la gestion, qui peuvent être
résumées en :
•Définir une stratégie pour conduire la performance;
• Traduire la stratégie en objectifs, indicateurs et cibles;
•Accompagner le progrès par rapport aux objectifs ;
Analyser les raisons en cas d'objectifs non atteints et
•Sélectionner et mettre en œuvre des actions correctives.
Les systèmes de BPM servent à aider l'entreprise à mieux contrôler ses propres processus, à
les reformer quand c'est nécessaire et à effectuer des tâches importantes avec plus d'efficacité. Ces systèmes
donne à l'utilisateur plus de contrôle sur l'automatisation des processus, ce qui allège le travail de la
informatique. Le BPM impose à l'entreprise un très grand défi, car il oblige l'utilisateur à deux
actions que, presque toujours, il n'aime pas faire : repenser aux tâches du quotidien et, au moins
dans la phase d'implémentation, travailler côte à côte avec le personnel informatique.

(HITPASS, 2013)
Le BPM en tant que discipline de gestion axée sur les processus couvre deux grands domaines de la gestion.

empresarial: BPM Governance y BPM Operacional.

3.1.1 Gouvernance BPM

(HITPASS, 2013)
La gouvernance BPM, également appelée gouvernance d'entreprise, comme un modèle de gestion

corporatif orienté vers les processus, mais intégré avec toutes les couches d'une organisation
(couche de direction, opérationnelle et technologique), les phases du cycle de gestion, la gestion du changement
de nouveaux besoins (en anglais : Change Management), la structure organisationnelle et tous les
instruments d'alignement de et entre les structures corporatives.
La gouvernance BPM englobe l'alignement avec tout le cycle de gestion organisationnelle depuis la
planification et gestion stratégique, la définition de plans d'affaires, le cycle budgétaire, le
définition des profils et des postes, la gestion des opérations, le soutien technologique jusqu'à l'alignement
avec le portefeuille de projets d'entreprise.
(Harmon, 2007) Dans la littérature, plusieurs définitions de la gouvernance BPM sont trouvées, (John Jeston
& Johan Nelis, 2008), la plupart d'entre elles très vastes mais toutes s'accordent à dire qu'il s'agit d'un
concept défini pour une organisation sur la façon dont la « Gestion par Processus » doit être appliquée et que

intègre des instruments et des disciplines existants autour des processus d'affaires.

Harmon (Harmon, 2007)] discrimine d'abord entre «gouvernance» et «management», expliquant que
«gouvernance» est l'organisation du «management». En résumé, selon lui quand
hablamos de governance nos referimos a un modelo específico de gestión, mientras que
«gestion» est une activité humaine.

Pour Jeston et (John Jeston & Johan Nelis, 2008)(p. 323-324) dans un modèle de gouvernance BPM
son la clé de la définition des rôles et des responsabilités, les processus d'alignement avec la stratégie
de l'entreprise, le contrôle de gestion orienté vers les processus et enfin la standardisation des
processus de gestion.

Source :
[Link]
bierno%20par%[Link]?keepThis=true&TB_iframe=true&height=450&width=650
3.1.2 BPM Opérationnel

(HITPASS, 2013) Le BPM Opérationnel englobe la gestion du cycle BPM par processus et non les
mecanismos de alineamiento con las otras capas de la organización que, es dominio de un modelo
que incorpore la gouvernance BPM.
Le cycle présenté est conçu pour être appliqué à chaque processus séparément ou sous forme
indépendant. Chaque processus peut se trouver dans un état différent du cycle. Le cycle commence
à partir de deux constellations possibles : Un processus actuel qui doit être levé et documenté et/
ou se redéfinir. Un nouveau processus, qui n'existe pas dans l'organisation, doit être introduit.

Dans la phase de « Levée du Processus », il faut d'abord collecter des informations sur comment

le flux de travail est organisé. Cela se fait avec l'aide de techniques de modération, d'ateliers,
entretiens, collecte de documents, etc. Pour cela, dans le processus à établir, il faut :
Délimiter clairement depuis les processus antérieurs ou postérieurs
Décrire les services qu'il produit pour les clients et quelle priorité cela a du point de vue
vue des objectifs commerciaux
Représenter à la fois le flux de travail et les rôles qui interviennent à chaque étape,
les ressources qui sont utilisées et les systèmes d'information qui les soutiennent
Dans l'étape de «Documentation du Processus», les connaissances acquises dans l'étape de
Le levée est documentée dans un modèle de processus qui reflète la situation actuelle. La
la documentation résultante comprend les diagrammes des flux, des fiches de description, des politiques de
affaires et procédures utilisées pour exécuter le travail.
Les faiblesses identifiées lors de la phase d'« Analyse d'amélioration » ou les écarts que montre le
«Surveillance du processus» est généralement le point de départ d'une refonte des processus.
Éventuellement, différentes variantes ou scénarios peuvent être évalués à l'aide de simulateurs.
Cela s'applique également si un nouveau processus est en cours de conception. Dans les deux cas, le résultat ou

L'entregable est un modèle de processus souhaité (À faire).

La phase de « Mise en œuvre du processus » comprend à la fois la mise en œuvre technique ainsi que
les adaptations organisationnelles nécessaires. La gestion du changement (en anglais : Change
La gestion et la stratégie de communication constituent des éléments fondamentaux à considérer.
pour le succès du projet. Le modèle technique peut être mis en œuvre par le biais d'une Suite de BPM
suite de gestion des processus métiers, BPMS) ou par le biais d'un développement classique de
logiciel. Le résultat final de l'implémentation technique du processus est la situation actuelle (As is)
automatisée et documentée, correspond au modèle de processus désiré (À être).

Les phases depuis le « Lancement du Processus » jusqu'à l' « Implémentation du Processus » se

administrent généralement par le biais de l'organisation d'un projet, tandis que le
«Surveillance du Processus» (anglais : Process Controlling) est conçu comme un processus continu et forme
partie de toutes les opérations. Les activités les plus importantes de « Surveillance du Processus » sont
le contrôle constant des opérations (techniquement, nous parlons du contrôle des instances de)
processus réels) et leur évaluation respective des indicateurs. Selon l'école de BPM, si
Des problèmes ponctuels sont détectés et devraient être corrigés immédiatement ou en ligne. S'il y a des ressources

disponibles il est possible de résoudre des problèmes structurels sans avoir besoin de formuler un projet,
mais si ses causes ne sont pas claires ou sont complexes, il devient nécessaire de planifier et d'implémenter un
projet d'amélioration et de redesign. La décision de savoir s'il est nécessaire de formuler un nouveau projet ou

instalar un equipo de trabajo en operaciones, debiera tomarla el responsable del proceso de común
accord avec les participants.

Le cycle BPM montre dans ses principales phases comment fonctionne le cercle vertueux de l'amélioration continue.
des processus. Pour l'appliquer, il est nécessaire :

Attribuer des responsabilités aux processus et à chacun de leurs étapes Utiliser des méthodes d'analyse
et la gestion à cet égard Compter sur le soutien de solutions informatiques adéquates

Réaliser une coordination fluide entre ces trois composants est une tâche de gestion par processus (BPM-
La gouvernance). La gestion par processus se trouve au-dessus de tout projet de modélisation et
a donc pour mission de soutenir la «Gestion des Processus», pour le respect des
objectifs stratégiques.
3.1.3 Gestion des Cas - Gestion des Cas

La gestion des cas est une façon de progresser et d'améliorer les soins intégrés, coordonnés et
continuée, centrée sur la responsabilité partagée de coordonner les soins, les ressources,
services et professionnels. Il nous dit :

(HITPASS, 2013)
Un cas, comme un processus d'affaires, consiste en un ensemble d'activités ou de tâches. Sans
embargo, à la différence d'un flux prédéterminé, le processus d'un cas depuis son début jusqu'à la
la finalisation n'est pas limitée à une séquence du processus comme nous le comprenons normalement, de
principio a fin, aunque con una lógica compleja de anidación y encadenamiento.
Quelles activités doivent être réalisées pour compléter le cas ? Cela dépend des détails de chaque cas.
En général, le responsable du cas, ou peut-être tous les participants à une tâche, prendront cela.
décision. Les "règles", pour ainsi dire, sont le savoir-faire des utilisateurs. Dans la littérature
on parle aussi de « gestion de cas adaptative (GCA) ou gestion de cas dynamique », où
on argumente que l'accent est mis davantage sur le traitement du cas que sur le processus lui-même
[Lamont12].
Par exemple, dans un hôpital, toute l'attention se concentre sur le patient et le cas est ce qui est
se produisant avec lui. Les processus cliniques soutiennent la prise en charge du cas, mais le médecin ou l'équipe

le médecin décide quels processus de diagnostic ou de soutien thérapeutique seront employés et quand
recourir à eux. Le cas spécifique détermine la séquence. Cependant, dans l'industrie de la santé
À mesure que les connaissances ont augmenté, des guides de pratique clinique ont été développés qui
orientent la prise de décision par l'équipe de santé, facilitant la standardisation des
processus cliniques. Dans certains traitements, aujourd'hui, il est normal de se retrouver avec un processus

connu de principe à fin. En tout cas, le même processus doit prendre en compte dans ses règles l'option
de ne pas continuer avec le flux standardisé.

La gestion des cas ne travaille généralement pas par le dossier de routage du cas vers la tâche suivante
de façon séquentielle sur la ligne. À la place, les avancées se font à travers des événements, tant externes
comme internes :

Los eventos externos afectan el caso. El contenido de ese mensaje se agrega a la carpeta del caso
et de nouvelles tâches ou processus peuvent être créés. Les événements internes incluent les attributions et
règles de l'entreprise. Les travailleurs de cas assignent des tâches et initient les processus qu'ils jugent nécessaires

nécessaires à votre travail sur le cas. Les règles de l'entreprise peuvent créer et attribuer des tâches ou mener
à terme pleinement les actions automatisées sur la base de l'un quelconque des événements externes,
la réalisation des tâches des autres cas, ou l'expiration des délais de travail.
Ainsi, à partir d'un flux déterminé, le modèle conceptuel d'un cas est une collection visible de tâches dans
conjunto con los documentos y carpetas de cada caso. El estado del caso en su conjunto está
déterminé par l'état combiné de toutes ses tâches et documents.
Les domaines typiques où nous rencontrons des processus de type « gestion de cas » sont :
Domaine de la santé

Travail social
Support
Éducation
Projets qui induisent le changement
Explorations minières

En général, toutes les entreprises qui nécessitent des connaissances expertes qui n'ont pas encore atteint un

niveau de standardisation Quelles sont les fonctionnalités spécifiques requises pour soutenir
techniquement la gestion de cas dans le contexte du BPM ? En tenant compte des
principales caractéristiques que possède la gestion des cas requise :
Délégation du cas à d'autres spécialistes
Décisions de groupe Gestion de contenu
Gestion des documents
Fonctionnalités de recherche et de filtres
Configuration des attributs
Attribution de ressources

Exemple de gestion de cas - Clinique

SOURCE[Link]
3.1.4 Gestion de cas contre BPM ?

(HITPASS, 2013)
Après avoir examiné les caractéristiques distinctives des deux approches, nous pouvons indiquer que, BPM
normalement, il se concentre sur des processus répétitifs avec des flux très stricts. L'abstraction nécessaire
il doit gérer des tâches plus complexes. Pour sa part, la gestion des cas offre une flexibilité beaucoup
maire, mais échoue lorsqu'il s'adresse à l'utilisateur commercial et complique le respect des normes
régulatrices. Elles peuvent se compléter et leur travail ensemble peut être utile. Cependant, les
les décisions récurrentes dans la gestion des cas permettent d'identifier des modèles concernant les
actions, but given the nature of case management, it should not be structured, but it is possible
générer des manuels ou des guides d'exécution.

La gestion des cas apporte de la flexibilité et des directives. Elle se concentre sur les informations relatives aux cas, et non pas sur les

processus déterminés. Un cas recueille toutes les informations nécessaires à sa gestion : les acteurs
(utilisateurs / rôles qui participent au cas), données / contenu, règles et, bien sûr, processus et
tâches. La gestion des cas habilite les travailleurs qualifiés en leur donnant la possibilité de prendre
décisions dans les contraintes des stratégies commerciales. La gestion des cas définit
entreprises et objectifs réalisables, et les communique de manière transparente tandis que les propres
les utilisateurs ajoutent des tâches pour atteindre ces objectifs. Cela conduit à un mode « design-by-doing » qui

permet aux utilisateurs de créer, modifier et analyser les processus en temps réel. Les processus
adaptables, malgré qu'ils n'aient pas une progression prévisible et répétitive, se déplacent d'un état
moins ordonné à un autre plus ordonné par l'action de l'utilisateur. Les décisions prises
par les utilisateurs sont partagées en étant stockées dans des modèles et sont disponibles pour d'autres
acteurs de la compagnie comme actions proposées. C'est le cas de ce que l'on appelle le dossier clinique
unique dans l'histoire d'un patient dans un hôpital qui peut toujours être repris et créé un
nouvelle instance de processus. Enfin, nous pouvons résumer que la gestion des cas est un cas
specially in the field of BPM, but it is also about managing a process, in this case
appelé «gestion d'un processus de cas».

Fuente: [Link]
3.2 L'automatisation des processus (BPA)

Implique l'utilisation de systèmes technologiques pour automatiser les activités et/ou services d'une
fonction ou unité commerciale déterminée. De cette manière, des processus commerciaux tels que ceux que
ils occupent les domaines des ventes, de l'administration, des opérations, de l'approvisionnement et de la distribution,

Les recouvrements, les ressources humaines ou l'informatique peuvent être automatisés grâce à l'utilisation de packages.

informaticiens spécialisés pour développer une telle fonction. En conséquence, le BPA permet de libérer le
personnel de travaux routiniers afin que, en contraste, ils se concentrent sur des activités qui
maximisez la valeur ajoutée de l'ensemble de l'opération.

(HITPASS, 2013)
Pour comprendre ce que peut englober l'automatisation, un processus simple va d'abord être décrit.
demande de crédit organisée manuellement et ensuite il sera décrit comment aujourd'hui on
ils automatisent (mettent en œuvre techniquement) ce type de processus.

Le processus commence lorsque une demande de crédit est soumise par courrier et est transférée à
un cadre commercial à la banque. Le cadre examine d'abord la demande de manière visuelle pour
ensuite saisir certaines données du demandeur dans un système d'analyse des risques. Si l'indice de risque
c'est positif ou acceptable, saisissez les données de la demande dans un système de crédit financier et ensuite
envoyez la demande évaluée à votre supérieur pour qu'il l'approuve. L'automatisation de ce processus
pourrait se présenter de la manière suivante : L'arrivée de la demande de crédit par courrier est numérisée et via
un programme OCR (Reconnaissance Optique de Caractères ou reconnaissance automatique de texte) se
on extrait certaines variables du formulaire et elles sont saisies dans un système d'évaluation de crédit. Ensuite

un document électronique est créé qui déclenche la création d'un ordre de travail dans le Process
Moteur (moteur de processus) et est déposée dans la boîte de réception des nouvelles activités du
exécutif correspondant. L'exécutif sélectionne dans la liste la demande correspondante et visualise
la demande de crédit dans le Process Engine, elle est examinée formellement puis le Process Engine par
au moyen d'un service web, invoque le système d'analyse de risque en lui envoyant (techniquement, cela se

traspasan les variables) les informations correspondantes. Si le résultat de l'analyse est positif, le
Le moteur de processus déclenche automatiquement la demande d'approbation à votre supérieur, en saisissant les
données dans le système de crédit financier par le biais d'un service web et les déposant dans la boîte de réception
de l'entrée de celui-ci pour son approbation adéquate. Nous pourrions discuter si ce processus pourrait être amélioré,

mais ce cas décrit la différence entre un processus manuel et un processus automatisé :

Le moteur de processus contrôle le processus, à travers lequel il dirige les utilisateurs qui participent aux
différentes activités et leurs résultats respectifs (Gestion du Flux de Travail Humain) et contrôle les
interfaces internes et externes avec les systèmes qui participent au processus (Orchestration de
services).
Les décisions concernant le type d'activités ou de services à invoquer sont prises par le Process
Moteur à travers la logique technique mise en œuvre (modèle de processus technique) et les points de
intervention des utilisateurs. Dit autrement, la logique du processus mise en œuvre n'est pas toujours
elle est obligatoire, dans certaines circonstances, elle peut être influencée par les participants au processus,

avec la réserve que tout doit être enregistré.

Automatisation d'un processus avec un moteur de processus

SOURCE : (HITPASS, 2013)

3.3 Les participants dans BPM

(HITPASS, 2013)
Si nous admettons que la BPM en tant que discipline de gestion intégrée englobe toutes les couches d'une

organisation depuis la haute direction jusqu'à la technologie qui s'occupe de mettre en œuvre et de donner

support aux processus métier, il est clair que pour les processus de gouvernance BPM
Pour gérer les cycles de BPM, de nombreux acteurs doivent participer à la gouvernance d'entreprise.
par processus.

Les rôles des participants décrits ci-dessous devraient être présents d'une manière ou d'une autre
en projets, gestion ou opérations de BPM. La figure 2.3 montre les principaux rôles que l'on assume
les participants dans les couches métier et IT.

Il a été constaté que les entreprises ayant des niveaux de maturité plus élevés en BPM
ils ont également des rôles bien définis et des structures orientées vers des processus. Au chapitre 9, il se
va décrire comment ces rôles s'insèrent dans des structures organisationnelles orientées vers les processus.
Propriétaire du Processus (Process Owner) : Le propriétaire du processus est un membre de la haute direction de la

entreprise et responsable d'une ligne de métier. Il est responsable de traduire la stratégie en

ses processus d'entreprise. Il approuve et met à disposition une partie ou une grande partie du budget pour un

proyecto de BPM. Él debiera tener el mayor interés de todos los participantes en promover BPM
comme un instrument de gestion.

Gestionnaire de Processus (Process Manager) : Le gestionnaire de processus est responsable des opérations.
rapporte directement au propriétaire du processus et c'est lui qui propose généralement les propositions de
amélioration. Il est responsable de maintenir la communication avec les clients et/ ou les fournisseurs.

Normalement, le gestionnaire de processus se trouve inséré dans un niveau de hiérarchie intermédiaire, comme
sous-directeur, sous-gérant, chef d'agence ou chef de groupe.

Utilisateur commercial ou cadre commercial (Participant au processus) : C'est celui qui travaille dans les opérations.

avec le processus, c'est-à-dire une partie intégrante de la chaîne qui crée de la valeur pour les clients. On peut

relater de manières très différentes avec le gestionnaire de processus. Dans la plupart des organisations
son utilisateurs d'un domaine fonctionnel, comme les ventes, les finances ou la logistique. Dans ces cas, il n'existe pas d'

gestionnaire de processus ou agit en tant que tel dans sa partie du processus et l'utilisateur rapporte directement au

responsable de la zone. Si l'entreprise est organisée de manière matricielle, ce qui est courant dans les entreprises mondiales

Il est assez courant que des conflits émergent entre le gestionnaire de processus et les responsables de zones.
Dans les structures matricielles, un modèle de prise de décision collaboratif est nécessaire pour éviter le

conflit d'intérêts qui surgit au point d'intersection.

Analyste de Processus : Les compétences attendues de l'analyste de processus

ses connaissances en BPM en général, connaissances de l'entreprise et technique de
modélisation des processus qui sera utilisée. L'analyste de processus soutient le gestionnaire de processus
comme conseiller interne ou externe à toutes les étapes du cycle de BPM. Il peut représenter comme
expert au gestionnaire de processus devant des consultants externes ou faire partie de l'équipe des projets de

BPM. L'analyste des processus peut être membre d'un domaine d'activité, d'un domaine de processus ou
Appartenir en tant qu'analyste au département informatique de l'entreprise. Dans très peu de cas
sera le responsable de la mise en œuvre des processus, bien qu'il possède de bonnes connaissances
ou une grande affinité avec les technologies de l'information. L'analyste de processus devrait avoir
une grande compétence dans les domaines du développement organisationnel et des techniques de communication. Mais sur

tout est, comme l'indique son rôle, un analyste. On s'attend à une grande maîtrise de la technique de modélisation
et en tant que coordinateur entre les personnes de l'entreprise et de l'informatique, c'est un rôle clé dans tout projet de BPM.

Selon les observations et les expériences de l'auteur, de nombreuses personnes occupant ce rôle ne
ils ont les compétences suffisantes pour atteindre cet objectif. Dans la plupart des cas
parce qu'ils manquent des compétences pour ce profil. La qualification la plus importante d'un analyste de
les processus n'est pas de communiquer mais de saisir ou d'écouter les participants. De bons analystes de
les entreprises ressentent le besoin de vouloir s'occuper de tout en détail. En même temps, elles possèdent de l'empathie,

comme pour pouvoir se mettre à la place du client et représenter ses préoccupations. Ils ne leur sont pas...
n'escapent aucun détail, mais en même temps possèdent un bon sens de l'abstraction et peuvent
réduire les modèles à leur essence. Le profil d'un chef de projet est différent, il est centré sur
atteindre les objectifs du projet et, en général, privilégier les objectifs techniques du projet, tels que les dates

de livraison et de maintenance du budget des coûts du projet, face aux aspects de qualité et
efficacité. Pour cette raison, il n'est pas conseillé de mélanger les deux rôles dans le sens où un chef de projet
agissez en tant qu'analyste ou vice versa.

Ingénieur de Processus : L'ingénieur de processus met en œuvre un modèle technique

à partir de la spécification et de la conception opérationnelle validées par lui et les analystes de processus. Le
la conception technique doit se réaliser dans le même environnement (moteur de processus ou BPMS) où se

ils mettront en œuvre les processus. L'ingénieur des processus est bien formé dans l'environnement de
mise en œuvre, configure et construit la solution de BPM dans la suite choisie. L'ingénieur de
Les processus peuvent également agir en tant que conseiller lors de la phase de modélisation de la logique opérationnelle.

Ingénieur de Développement et de Services (EAI Développeur) : Un programmeur peut assumer le rôle de

ingénieur de développement, si la solution nécessite des extensions ou des adaptations de développement par
moyen de programmation (Services web, Java, C# ou d'autres langages).

Architecte SOA : L'architecte SOA est responsable de concevoir une architecture de

logiciel qui répond aux exigences technico-fonctionnelles des processus et services que se
ils vont automatiser et orchestrer avec les systèmes d'information. La plupart des processus de
les affaires doivent s'intégrer aux systèmes d'information du back-office, développer des interfaces B2B
et intégrer le BPMS à un portail d'entreprise.
 Dans les entreprises et organisations de petite taille, beaucoup de ces participants devront assumer
plusieurs rôles à la fois. Les rôles suivants ensemble pourraient par exemple être assumés par les participants
en entreprises PME :
Propriétaire de Processus et Gestionnaire de Processus Analyste d'Affaires et Exécutif d'Affaires Analyste de

Affaires et Ingénieur de Processus Architecte SOA et Ingénieur de Développement

3.4 Outils pour le BPM

Si l'on envisage de concevoir ou de modéliser des processus, il s'agit d'un processus d'analyse.
Si l'on pense à la gouvernance BPM, il s'agit d'une méthodologie de gestion.
Si vous envisagez de réaliser un prototype, il s'agit de tester un environnement de mise en œuvre ou de
automatisation des processus.
Et si l'on envisage de raccourcir le cycle de durée d'un processus, il s'agit de techniques de
optimización y control a través de indicadores.

Tous ces objectifs se réfèrent à différents domaines d'application dans le BPM. Chaque domaine d'application
c'est une spécialité en BPM et elle s'appuie sur différents concepts. Donc il sera difficile de
trouver un outil universel qui couvre tous ces domaines ; au contraire ce serait une
aberration d'essayer de construire une suite universelle pour le BPM.

(HITPASS, 2013)
Comme comparaison, analysons un exemple pratique : Une Ferrari ou une Porsche ne nous sera pas utile.
il est impensable qu'un Jeep ou un Land Rover gagne une course de Formule 1.

Il en est de même dans le BPM, une suite de BPMS ne nous servira pas à représenter une carte stratégique.
et de les aligner avec les processus d'une entreprise. Cela ne nous aidera pas non plus à décrire les politiques

et règles d'affaires de manière indépendante des processus qui les utilisent.

Dans le premier cas, nous parlons d'une suite BPA (Analyse des processus métier) et dans le
deuxième cas des moteurs de règles appelés BRMS (Systèmes de Gestion des Règles Métier).

En général, on peut segmenter le marché des outils pour la BPM en :

Outils qui soutiennent les processus d'analyse et de gouvernance d'entreprise (BPM Governance)
appelées plateformes BPA (Analyse des Processus Métier) ou également EA (Architecture d'Entreprise)
Outils)
Outils qui soutiennent la mise en œuvre technique ou l'automatisation des processus
appels BPMS
 Outils qui soutiennent l'administration et l'exécution des règles de métier de manière
indépendant des systèmes qui les utilisent, appelés moteurs de règles ou BRMS (Systèmes de Gestion de Règles Métier)

Systèmes de gestion des règles

Outils permettant d'implémenter avec les processus les indicateurs de contrôle de

gestion en temps réel, appels BAM (Surveillance des Activités Comerciales)
Outils permettant l'orchestration de services entre les BPMS avec tout type de
systèmes, principalement ceux du back office, appelés SOA Suite Outils qui permettent
analizar los datos históricos de los procesos ejecutados para detectar desviaciones del
comportement souhaité ou découvrir de nouveaux motifs. Ces environnements analytiques sont
on appelle outils de Minérisation des Processus ou Process Mining Tools en anglais.
Les experts en BPM savent qu'en fonction des exigences ou de la complexité d'une
l'organisation peut nécessiter une décomposition encore plus fine, par exemple de
séparer la couche de présentation d'un BPMS ou décomposer une suite SOA en plusieurs
environnements spécialisés (ESB, SOA-Repository, etc.).
Tous ces outils peuvent être positionnés à trois niveaux ou couches d'un cadre de
Architecture d'entreprise moderne comme le montre la figure.

Plates-formes et outils pour la BPM

FUENTE: (HITPASS, 2013)

La couche métier englobe tout le cycle de planification, d'analyse, de gestion et de contrôle de la stratégie
et du modèle commercial. Outils qui soutiennent toutes les fonctionnalités pour planifier,
analyser, modéliser et contrôler les changements des exigences sous des modèles intégrés dans une
base de données commune, on les appelle en anglais EA (Enterprise Architecture) ou BPA (Business)
Analyse de processus) Outils.
Thème n° 8 : Évolution du Business Process Model and Notation (BPMN)

8.1 Histoire des techniques de modélisation des systèmes et des processus

(HITPASS, 2013)
À partir des années 60, des techniques de modélisation ont commencé à se développer, surtout orientées vers le
développement de systèmes et la plupart d'entre eux, axés sur la modélisation des données et des fonctions. Le

ce qui était recherché, c'était des vues de données normalisées qui devaient être gérées par la
fonctionnalité requise pour l'entreprise, raison pour laquelle ils dominaient les techniques centrées
en flux de données, comme cela a été le cas pour l'analyse structurée (en anglais : Structured Analysis). La méthode

de l'analyse structurée est devenue à son époque synonyme de l'analyse du flux de données. Se
ils ont développé des outils pour documenter et gérer les flux de données. Les outils étaient
essentiels pour documenter les systèmes existants et pour déterminer les exigences de
information par le biais de la méthode structurée.

Les analystes souhaitaient connaître les réponses à quatre questions spécifiques : Quelles fonctions
integran el sistema? ¿Qué datos necesita cada función? ¿Qué datos deben ser almacenados?
¿Qué datos ingresan y abandonan el sistema? De lo dicho anteriormente queda claro que se daba
grande importance aux données.

Objets du Diagramme d'Analyse Structurée selon Yourdon ou Gane et Sarson

Exemple de diagramme de contexte avec IDEF

Ejemplo de Descomposición del Diagrama de Contexto con IDEF

8.2Clasificación de las técnicas de modelamiento

(HITPASS, 2013)
Formellement, nous pouvons faire le premier grand partage en méthodologies basées sur des techniques de

langage structuré (script) et méthodologies basées sur des techniques de diagrammation.

Les méthodologies basées sur des techniques de diagrammation peuvent être classées en techniques
orientées vers le flux de données, le flux de contrôle et orientées vers l'objet.

Classification de certaines techniques de diagrammation pour le modélisation des processus

8.3 Autres Techniques de Modélisation

(HITPASS, 2013)
Avant l'apparition de BPMN, certaines techniques orientées objet ont été largement diffusées pour
modéliser des processus, notamment les diagrammes d'activité UML (diagrammes des processus au niveau descriptif)

Diagrammes UML Cas d'utilisation (Cas d'utilisation à un niveau plus détaillé décrivant le flux entre)
activités et unités organisationnelles).
Ejemplo de Use Case de UML

Exemple de Diagramme d'Activité UML

8.4 Modèle et notation des processus métiers (BPMN)

(HITPASS, 2013)
La première version de la Business Process Modeling Notation (BPMN) a été développée par le
institut Business Process Management Initiative (BPMI) principalement sous la tutelle de Stephan
A. White professionnel de l'IBM en 2004.
Dès le début, l'objectif principal était de rendre disponible une notation graphique, standardisée, qui
permettait d'automatiser les processus à partir du design graphique. En 2005, il a été transféré le
projet à l'Object Management Group (OMG), car le BPMI n'était pas un institut qui
administre des normes. Le OMG est très connu dans le monde de l'informatique car il administre,
entre autres, la norme du langage pour la conception de logiciels appelée Modélisation Unifiée
Langage (UML). À travers l'OMG, dont la plupart des fournisseurs sont membres
plus importants de TI, BPMN s'est rapidement répandu dans le monde entier et presque tous les
Les fournisseurs, qu'ils soient grands ou petits, académiques ou consultants, ont commencé à adopter ce

standard. La dernière version officielle 1.2 a été publiée en janvier 2009 [OMG09]. La version 2.0,
complètement nouvelle et élargie, elle a été terminée à la mi-2010 et à la fin de celle-ci, le
équipe de la OMG chargée de revoir et de finaliser la nouvelle version, appelée Tâche de Finalisation
Force (FTF) a recommandé au syndicat de décider d'officialiser la version 2.0. À partir de la
La version 2.0, l'acronyme BPMN change légèrement de nom pour : Business Process Model and Notation.
Paradoxalement, jusqu'à la version 1.2, il n'était pas possible de mapper les modèles directement dans un environnement.

technique, parce que les attributs techniques n'étaient pas encore définis. En raison de cette lacune, il y a eu
beaucoup de problèmes pour convertir (mapper) les modèles en langages d'exécution comme BPEL.
Tout récemment, avec la version 2.0, il existe un métamodèle qui permet d'exécuter directement les modèles de

BPMN. Ces deux faits importants de la nouvelle version, à savoir la normalisation et la capacité de
l'exécution directe entraîne les avantages suivants :
En 2011, il existe plus de 70 outils de modélisation BPMN (tendance à la hausse) et beaucoup
de elles peuvent être acquises gratuitement. La communication avec d'autres partenaires commerciaux qui ont

l'apprentissage de BPMN (clients, consultants, fournisseurs, etc.) sera plus rapide, fluide et expressif.
vous pouvez vous attendre à ce que le nouveau personnel apporte des connaissances en BPMN.

Les instituts de formation, les universités et les entreprises de conseil vont investir des ressources pour former
professionnels dans cette notation. Des entreprises privées vont développer des solutions basées sur cela
norme, et les fournisseurs de technologie sont en train de développer des outils pour exécuter
directement le code graphique de BPMN.

Source:[Link]
Thème n° 9 : Les éléments de base de BPMN

9.1 Modèles, instances, jeton et corrélations

Comme un diagramme peut contenir plusieurs pools, on comprend qu'un

Le diagramme peut contenir n processus.
Modèle de processus : Dans un diagramme, un ou plusieurs modèles de processus peuvent être représentés.

Chaque modèle constitue la description d'un processus.

Instance de processus : On entend par un processus concret dans la réalité, c'est-à-dire des cas réels comme

par exemple, la réclamation d'un client crée une instance du processus de réclamations. Certains
Les processus ne s'initialisent qu'un couple de fois par an et d'autres plus souvent.

Token (marca):Se utiliza para visualizar y probar el comportamiento de los procesos diseñados.
Las marcas recorren en forma de una animación la lógica por los flujos normales y los de excepción.
Corrélation : Vous avez probablement reçu de nombreuses fois de la correspondance d'institutions qui
contiennent un numéro de référence, numéro de procès-verbal, numéro de ticket, etc. Si vous répondez à la
l'institution doit indiquer cette référence pour pouvoir être identifiée. À cette affectation dans
La forme d'un identifiant s'appelle corrélation. Un cas doit toujours être bien corrélé.
pour éviter que des erreurs ou des pertes de données ne se produisent.

9.2 Catégories des éléments de BPMN

Les élémentsgraphes en BPMNsils sont classés en 4 catégories :

Source: [Link]
9.3 Activités

C'est tout travail effectué par l'organisation. Ils peuvent être atomiques ou composés.
Les activités qui transforment l'état d'un objet commercial afin que le processus puisse
arriver à produire de la valeur pour les clients.

Fuente: [Link]

9.3.1Tipos de Actividades

(HITPASS, 2014)
Jusqu'à la version BPMN 1.2, il n'existait pas de symboles réservés pour différencier les types de
activités. Cette lacune a été surmontée à partir de BPMN 2.0, donnant aux activités indéfinies une
simbologie dans sa représentation.

[Link]é Manuelle
Elle est exécutée par une personne, dont le contrôle n'est pas géré par un système de workflow ou un moteur de processus.

Exemples :
Le stockage d'un acte dans un fichier physique

Clarifier par téléphone une facture mal émise

La conversation d'un cadre avec son client

[Link]é Utilisateur
Elle est également exécutée par une personne (utilisateur), mais dans ce cas, le contrôle est exercé par le système.

de workflow ou moteur de processus.

Exemples :
Revisar una factura
Approuver une demande de congés
Gérer une demande de support
[Link]é Service
C'est une activité automatique qui est exécutée complètement par un logiciel. BPMN fait partie
normalement de la base, qu'il s'agit d'un service web, mais ce n'est pas obligatoire. Quoi qu'il en soit
il s'agit d'un composant d'intégration d'applications, ce qui nous donne par cette voie la
entrée au pont avec les architectures orientées services (SOA).

Exemple de services d'intégration :

Demande de classification de risque de crédit à un système interbancaire
Vérification des stocks d'entrepôt pour un bon de commande
Disponibilité de siège pour une réservation de billets

[Link]é Envoyer et Recevoir

La réception d'un message en BPMN peut être modélisée comme une activité bien qu'il existe un type
de l'événement pour ces fins.
S'il est souhaité qu'un processus soit instance par une activité de type réception et de cette façon
remplacer un événement de type message au début d'un processus, il faut utiliser le symbole de type de
carte avec un cercle.
Le même principe est valable pour les activités de type envoi.
Ce type d'activités est uniquement technique et est utilisé pour invoquer des interfaces asynchrones de
services web en files d'attente de

messagerie (en anglais : files de messages), etc., c'est pourquoi il n'est pas recommandé de les utiliser dans des modèles

d'affaires.

[Link]é Script
Un script est un petit programme qui peut interpréter et exécuter directement le système de
flux de travail. Le script doit être écrit dans un langage que l'environnement peut interpréter.
mise en œuvre.

[Link]é Règle de Gestion

Ce type d'activité est également nouveau depuis BPMN 2.0 et est interprété de telle sorte que seul
est destinée à exécuter une règle métier, soit en l'invoquant dans un système indépendant
(BRMS : Système de Gestion des Règles Métier) ou en exécutant un moteur de règles qui est inclus
dans le Process Engine.
9.3.2Propriétés des activités

Aux activités, nous pouvons les marquer avec certaines propriétés (étiquettes), telles que répétitives
(boucle), multiples (plus d'un)
instance), ou compensation. Ces marques peuvent être combinées avec les types d'activités,
devenant d'une certaine manière des activités complexes.

[Link]
Une activité avec la propriété de boucle se répétera autant de fois que nécessaire jusqu'à ce qu'elle soit remplie, ou

la condition spécifiée n'est pas remplie.

Nous pouvons également modéliser la condition répétitive à l'aide de passerelles, en combinaison avec
Passerelles ou sans elles.
[Link]é multiple
L'activité avec propriété multiple s'exécute simultanément autant de fois que
instances existent.

[Link]é de compensation
Cette propriété est utilisée exclusivement dans le contexte de l'événement intermédiaire de compensation et

se rapporte à l'événement par le flux d'association et jamais par le flux de séquence.

9.4Flux de Séquence

Les connecteurs relient deux objets dans un diagramme. Il existe trois types différents de connecteurs.
de BPMN :

[Link] de Séquence
Définissez l'ordre des objets de flux dans un processus (Activités, Événements et
Gateways).
[Link] de message
Définissez le flux de communication entre deux participants ou entités (par exemple, une

organisation et ses fournisseurs). L'objet de la communication est un message.

[Link]
Ils sont utilisés pour lier des objets (données et informations) avec d'autres objets.
diagramme, incluant des objets de flux (Activités, Événements et Passerelles).
9.5 Activités mondiales

À partir de la version BPMN 2.0, nous pouvons définir des activités globales, qui se distinguent de
les activités normales, dans lesquelles les premières peuvent être réutilisées. Les activités globales ne se
elles se différencient graphiquement des normales. Nous ne les reconnaissons qu'en voyant l'existence d'activités

invocables qui portent le même nom que les globales, mais ont une ligne de contour en plus
grasse, c'est-à-dire en gras.

9.6 Un processus simple en BPMN

9.7 Flux de Processus avec Gateway

(HITPASS, 2014)
Presque aucun processus n'a un flux uniforme. Dans la plupart des cas, les instances parcourent
différentes trajectoires, en fonction des conditions et des règles qui s'appliquent.
9.7.1 Passerelle exclusive de données (XOR)

La porte par laquelle nous devons prendre la décision en BPMN est appelée Gateway.
Ne confondez pas une passerelle avec une activité.

Le Gateway nécessite un fait (une variable). L'activité est chargée de produire cela.
fait et rendre la variable disponible pour la passerelle.

Comme cette décision a été prise en fonction des informations reçues et la vanne permet
parcourir uniquement une alternative.

La possibilité que nous avons d'utiliser le XOR-Gateway comme élément de bifurcation (XOR-Split)
L'union (XOR-Join) peut sembler déroutante pour le débutant.
La notation permet même d'utiliser la passerelle XOR comme une union d'entrée et un bifurcateur de
sortie avec un seul symbole.

9.7.2 Passerelle parallèle

Par exemple, nous indiquons le temps moyen que prend chaque activité. La somme des temps de
chaque activité nous donne le temps de cycle du processus complet. (analyse des indicateurs de
temps de cycle
Nous pourrions envisager de paralléliser la préparation des repas et ainsi accélérer le processus.
général.

Le parallélisme ne signifie pas que les activités doivent nécessairement être exécutées exactement.
en même temps, mais ils peuvent commencer lorsque la condition est remplie.
Avec l'instance du processus, le jeton est créé simultanément, qui est cloné comme dans le cas
antérieur dans le AND-Split. Dès que la salade est prête, le jeton se dirige vers l'activité manger
préparation et exécute la tâche, c'est-à-dire que la salade se consomme sans attendre les pâtes, comme se

montre sur la figure :

Un autre cas où l'instance «vit» le temps correspondant au temps de cycle du processus

(exemple 45 jours). Bien que le premier jeton soit consommé après 30 jours, le deuxième jeton est encore
est actif pendant 15 jours de plus dans l'activité 2.
9.7.3 Passerelle inclusive de données (OU)

Avec un OR-Gateway, nous pouvons formuler une situation qui répond aux questions «et/ou».
lequel pouvons-nous choisir : un, plusieurs ou simplement tous les flux de sortie (pour consommer des jetons
d'une ou plusieurs branches d'entrée (Fusion inclusive) ou pour propager des jetons à, au moins, une des
ramas de sortie (Décision Inclusive).

Nous pouvons continuer à compacter le modèle, avec les différentes options :

Voyons les options :

Nous ne mangeons que des pâtes.

Nous ne mangeons que des steaks.

Nous ne mangeons que des salades.

Nous mangeons des pâtes et une salade

Nous mangeons du steak et de la salade.

Nous mangeons des pâtes et des steaks.

Nous avons mangé des pâtes, des steaks et une salade.

Le flux par défaut

Nous protège contre des situations indésirables. D'abord, tous les flux sortants sont pris en compte avec
sens des affaires ; seulement si aucune des options précédentes n'est valide, on utilise le flux par
défaut.

9.7.4 Passerelle complexe

Il est utilisé lorsqu'un cas d'affaires ne peut être représenté par aucun autre passerelle.
Il y a un moment dans le processus où plusieurs chemins apparaissent et seul l'un d'eux est valide.
Cette décision est basée sur les informations enregistrées dans Metadata.
Dans l'exemple, au moment de prendre la décision, pour l'une ou l'autre des alternatives, nous demandons
la pizza et nous avons écarté l'autre option.

Supposons que nous allons exécuter quatre activités en même temps. La cinquième activité
doit être exécuté dès que le résultat de trois activités est disponible, indépendamment de l'ordre
correlatif. Ce type de comportement de synchronisation peut être représenté par une passerelle
complexe, en y ajoutant si la condition sous la forme d'un artefact du type commentaire.
9.8 Événements

Les tâches (activités) changent l'état d'un objet, sous certaines conditions (Passerelles).

Les événements sont des choses qui se produisent. Ils indiquent qu'au début, de manière intermédiaire ou à la fin du processus.

quelque chose de significatif est arrivé.

Eventos de inicio nos indican que tipo de ocurrencias suceden para que un proceso comience.
Eventos intermedios muestran un estado que el proceso ha alcanzado y que en el modelo por
une certaine raison nous voulons le retenir. Ils ne sont pas utilisés très souvent, mais ils peuvent être très utiles, pour

exemple si l'état représente un jalon et qu'on veut mesurer le temps écoulé jusqu'à atteindre le
hito.
Les événements finaux indiquent qu'une réussite a été atteinte à l'issue d'un parcours du processus.

Les événements de capture sont appelés en BPMN « événements de capture » et indiquent des occurrences qui
Ils viennent de l'extérieur et ceux à qui un processus doit réagir lorsque cela se produit, indépendamment si
ce type d'événements « déclenchent » (en anglais : trigger) le début d'un processus ou se produisent pendant un

processus.

L'important à comprendre est que ce type d'événements a un impact sur le processus et que
cela doit réagir.
Les événements de capture peuvent avoir l'impact suivant sur les processus :
Ils initient le processus, le processus ou le flux du processus se poursuit, une activité ou un sous-processus qui se

la recherche en cours est interrompue ou annulée, pendant l'exécution d'une activité ou d'un
sous-processus, lance le début d'une autre activité ou sous-processus

Les événements de type déclencheur sont appelés en BPMN «throwings events» et indiquent des événements
créés dans le processus. C'est-à-dire, contrairement aux événements de type capture auxquels le
le processus doit réagir, dans ce cas le même processus agit comme déclencheur de nouveaux événements.
Événements de type déclencheur : ils peuvent être créés pendant le processus, ou à la fin du processus (événements de

terme).

Pour qu'un processus en attente puisse continuer, il peut être nécessaire qu'un
événement intermédiaire, comme le montre la figure, Si l'activité 1 est terminée, elle doit d'abord se produire
l'événement 1, avant que l'activité 2 puisse commencer.

En BPMN, nous pouvons également représenter des cas où il existe un flux normal, mais un événement peut survenir.

événement inattendu qui interrompt une activité ou un sous-processus. À ces événements intermédiaires
on les appelle «surimposés» (en anglais : attached), car ils sont superposés sur un côté de la
activité.
Tout d'abord, avancez vers l'activité 1, qui commence.
Si l'événement 1 se produit, pendant l'exécution de l'activité 1, celle-ci est immédiatement interrompue et
le jeton suit son flux dans l'activité 3 (cas de nécessité). Si l'événement 1 ne se produit pas, l'activité
1 s'exécute normalement et le jeton suit son flux régulier et commence l'activité 2.
Si l'événement 1 se produit, après que l'activité 1 ait été exécutée, l'événement n'impacte pas le
processus.

En BPMN jusqu'à la version 1.2, les événements superposés (à l'exception des événements de type
compensation), ils annulent toujours l'activité en cours. Ce comportement ne reflète pas toujours
la réalité, c'est pourquoi dans la version 2.0 un nouveau symbole a été introduit : un événement intermédiaire

surimposé, mais du type « non interruption ».

Le jeton initie l'activité 1. Si l'événement 1 se produit, durant l'exécution de l'activité 1, le jeton
es clonado: L'activité 1 est toujours en cours, mais en même temps, le deuxième jeton avance (le
cloné) à l'activité 3, qui est également initiée et exécutée. Cet événement peut se produire même
en forme répétitive, et le jeton se clone à nouveau jusqu'à ce que l'activité 1 soit terminée.
Si l'événement 1 ne se produit pas, l'activité 1 s'exécute normalement et le jeton continue son flux régulier.
et commence l'activité 2.
Si l'événement 1 se produit, après que l'activité 1 ait été exécutée, l'événement n'impacte pas le
processus.

9.8.1 Événement de Message

Événements qui portent des informations (ne se limite pas à certains porteurs d'informations comme des lettres,

emails ou appels, mais à tout objet qui porte de l'information : bon de commande, guide de
despacho, boleta ou facture.)
Exemple :

Ou aussi :

Un autre exemple, le client nous appelle pour se plaindre que le site ne répond pas ou est en panne. Le
L'opérateur cherche le problème ou vérifie s'il existe une erreur. Il est possible que le client ait
érroné et le problème lui incombe, car à un moment donné, il a pu avoir
Internet est tombé. Il appelle à nouveau pour que nous ne nous inquiétions pas. Cet appel entre dans le processus.

comme un événement de message de type interruption, lorsque cela se produit, toutes les autres activités sont annulées

et le flux continue à l'activité assignée par l'événement d'interruption.

9.8.2 Événement de temps

Aussi appelé minuteur, il est utilisé lorsqu'une condition temporelle se produit.

Comme événement de début, il peut être utilisé pour : démarrer un processus à intervalles réguliers, démarrer un
traitement régulièrement à une date et une heure indiquées, démarrer un processus dans une relation temporelle avec
un autre événement et lancer un processus une seule fois à une date et une heure déterminées.

Comme événement intermédiaire, le minuterie peut arrêter le processus, jusqu'à ce qu'un temps défini
soit atteint, une période de temps soit écoulée, un temps ait été atteint, que se
trouvez en relation avec un autre événement.
Un événement temporel ne peut pas être déclenché par un processus, car sur le temps nous n'avons pas
influence, raison pour laquelle cet événement n'existe que sous la forme de «événement de capture».

Très souvent, le minuteur superposé est utilisé comme « timeout », temps maximum autorisé
pour l'exécution d'une activité.

Il est également possible d'utiliser des temporisateurs superposés qui n'interrompent pas l'activité.

9.8.3 Événement d'erreur

Si vous identifiez les points où des erreurs peuvent se produire, vous pouvez les intercepter en utilisant ce type
d'événements.
En BPMN, une erreur est considérée comme un événement exceptionnel, c'est pourquoi elle ne peut être que

modéliser comme un événement intermédiaire superposé et qui nécessite en outre un traitement exceptionnel.
En tant que type de déclencheur, il ne doit être utilisé que comme événement final, indiquant que le processus a été

annulé par erreur, ou bien l'événement est capturé par un sous-processus supérieur qui le mène à un
traitement spécial.
9.8.4 Événement Conditionnel

Un processus peut être initié ou continué sous « certaines conditions ». La condition doit se produire dans
forme indépendante du processus.
Cet événement est, avec l'événement de temps, le seul type qui existe uniquement sous forme d'événement de capture.

9.8.5 Événement de signal

Ils ressemblent un peu à ceux des messages, raison pour laquelle dans BPMN les règles de
Le modélisation pour les deux événements est identique.

La seule et grande différence est que les messages ont une destination définie, par exemple un e-mail.
indique une adresse à qui cela s'adresse et un numéro de téléphone indique un numéro d'identification,
tandis qu'un signal est un message à destination indéfinie. Une annonce dans le journal, une réclame
À la télévision, ou un appel d'urgence par radio sont des exemples de signaux.
Toute personne ou système qui capte le signal peut réagir s'il le souhaite.

L'exemple qui, en voyant une publicité à la télévision, nous a donné envie de goûter à la pizza après le
annonce. Alors nous appelons et passons la commande de la pizza (réaction au signal), mais seulement la
nous mangeons quand nous avons envie de l'essayer (événement de condition). Ensuite, nous évaluons si nous avons aimé

la pizza sur un site web de gourmets. C'est-à-dire que les convives envoient également un signal (destination

indéfini) en évaluant la pizza dans un lieu public.

9.8.6 Événement de fin

L'événement de terminaison, après avoir consommé tous les tokens actifs, se charge également de finaliser la
instance du processus. En conséquence, cet événement spécial ne doit être utilisé que comme événement final,
en raison de la terminaison de tous les jetons actifs du processus, indépendamment de leur emplacement.

9.8.7 Événement de connexion

Une connexion ou un lien (en anglais : link) est un événement technique, n'a aucune signification commerciale.
L'événement n'a pas d'autre but que de pouvoir diviser des diagrammes très grands, sans perdre le lien de
un flux de séquence.

9.8.8 Événement de compensation

Compenser en BPMN signifie revenir à l'état initial d'une activité.

En la práctica utilizamos el evento de compensación sólo en el contexto de transacciones que tienen
que ser reversées.
Un exemple de processus d'une personne qui souhaite organiser une sortie le vendredi après
de sa journée de travail.
La personne se met d'accord avec son partenaire après midi (13h00) d'organiser une
sortie au théâtre ou d'inviter des amis à sortir. Dans les deux cas, nous devons nous engager à
réserver les billets pour le théâtre ou d'appeler des amis pour les inviter. Au crépuscule ou en arrivant à la maison,
Il peut arriver que nous soyons très fatigués, que nous changions d'avis et que nous restions à la maison.
regarder la télévision. Alors nous devons annuler les billets ou appeler les amis pour
leur faire savoir qu'il n'y aura pas de sortie.

9.8.9 Événement Multiple

Con el evento múltiple podemos incluir la captura de varios eventos alternativos con un símbolo.
S'il est utilisé comme événement de capture, il initie ou continue le processus, simplement en se produisant.
ou le premier des événements possibles.
Comme événement de type déclencheur, il réagit comme un déclencheur multiple, c'est-à-dire qu'il impulse tous

les événements contenus.

9.8.10 Événement de passerelle exclusif basé sur des événements

En BPMN, nous avons une possibilité supplémentaire pour concevoir des comportements spéciaux, comme
c'est l'« événement de Gateway exclusif basé sur des événements (abrégé : Event-Gateway) ». Ce Gateway
ne réagit pas aux données mais aux événements, spécifiquement au premier événement qui se produit.
Quelles situations peuvent se présenter pour utiliser ce passerelle d'événements ? À cet effet
REVOIR :

1. Événement multiple parallèle

2. Événement d'Escalade
3. Événement d'annulation
4. Événement de passerelle parallèle basé sur des événements

9.9Voie

Nous n'avons pas encore vu qui sont les responsables de l'exécution des activités. BPMN
utilise des couloirs appelés « lanes » pour l'attribution des responsables.

Selon les règles de BPMN, un objet de flux (activité, événement, passerelle) ne peut être
positionner à l'intérieur d'une voie et non entre elles.

La solution pour ce scénario serait de créer l'activité autant de fois que de personnes participent.
9.10Artefacts

BPMN contient également une catégorie d'éléments qui servent à une meilleure explication ou
visualisation graphique, mais qui n'a en aucun cas d'influence sur la logique des processus,
ce qui fait que les « artefacts » ne sont pas interprétés par un moteur de workflow.

9.11 Participants et flux de messages

S'il est nécessaire d'établir une coordination entre les participants dans un processus d'affaires, la méthodologie

de BPMN oblige à séparer les pools et la communication entre eux s'effectue via des flux
de messages. Alors nous aurions dans l'exemple illustré par la figure 6.9 quatre dirigeants, chacun
avec leur propre mini-processus et leur propre flux de contrôle. Entre eux, ils ne peuvent rien faire d'autre que

échanger des informations via des flux de messages. Il se peut qu'un processus dépende d'un
message externe pour que je puisse continuer, mais cela est défini par le propre processus (pool) à l'intérieur de son

logique.

Figure 6.9 : Flux de quatre participants dans des pools propres Source : [FreRueHit11]

Il est possible que l'analyste ne se sente pas très à l'aise avec ce principe de modélisation parce que dans
d'autres techniques de modélisation ne s'interprètent pas ainsi. Dans de nombreux cas, ce n'est pas nécessaire.
séparer tous les participants pour représenter une certaine logique dans un processus, cela va
déprendre fondamentalement si le «dirigeant» a le contrôle sur eux. Si un groupe ou un dirigeant n
il a le contrôle sur un participant, alors il doit effectivement le séparer et le représenter
como un pool propio, por ejemplo clientes y proveedores.

Pourquoi BPMN a-t-il introduit ce principe de séparer les participants en pools propres pour représenter
la logique dans leurs diagrammes ? L'objectif principal que les auteurs du BPMN ont en tête est le
automatisation des processus à partir des diagrammes.

9.12Sous-processus

Un sous-processus décrit en son sein la logique en détail, mais dans le diagramme du processus supérieur
ne prend plus de place qu'une propre activité. Les deux éléments, l'activité et le sous-processus,
appartiennent à la classe des activités et se représentent sous forme de rectangle avec des coins.
arrondies. La seule caractéristique qui les distingue est un signe plus (+) dans l'activité du type
sous-processus, qui indique l'existence d'une logique à l'intérieur de celui-ci.

Le processus supérieur commence et un nouveau token naît.

Le jeton passe par l'activité et atteint le sous-processus. Cela entraîne la création du processus supérieur.
une instance du sous-processus.
Dans le sous-processus, un nouveau jeton est créé qui suit la logique du flux du sous-processus depuis le
evento de inicio hasta el evento que termina el subproceso. El token del evento superior espera el
arrivée du token du sous-processus.
Thème N° 10 : Différentes vues d'un processus

BPMN part de la base que dans un diagramme peuvent être représentés un ou plusieurs participants.

Il faut faire attention à ne pas confondre un participant avec un rôle, un département ou un utilisateur. Un

Le participant est, en premier lieu, un élément logique de BPMN, dont l'application obéit aux
règles suivantes :

En un proceso existe un sólo participante (Este principio confunde a menudo al lector)

Ce participant possède le contrôle absolu sur la logique du processus.
D'autres participants ne peuvent pas influencer ce processus, parfois ils ne savent même pas.
comment est organisé
Le participant est par définition responsable du processus.
Si plusieurs participants doivent interagir avec d'autres processus, ils doivent le faire par le biais du

échange d'information (flux de message), information qui soutient logiquement l'opération de

processus
En raison de ces principes, il arrive que chaque participant ait sa propre vision du processus.
général, c'est-à-dire différentes perspectives. Ce fait nous amène à déduire qu'un processus d'affaires
il peut et a généralement plusieurs modèles de processus, autant de processus que de participants
existan. El objeto que en BPMN representa un participante es un pool.
Thème n° 11 : Catégorie de Processus

(Blanc 20009)
D'après sa description, BPMN a cherché à soutenir trois catégories principales de processus :
Orchestration
Chorégraphie
Collaboration
Ces termes ont varié, généralement avec des significations conflictuelles dans les différents contextes de
affaires dans lesquelles ils sont appliqués.

11.1Orchestration

Les modèles d'orchestration tendent à impliquer une perspective unique de coordination.

exemple, représentent une vue spécifique de l'entreprise ou de l'organisation du processus.
En tant que tel, un processus d'orchestration décrit comment une seule entité commerciale prend...

à la fin les choses.

Cependant, un diagramme BPMN peut contenir plus d'une orchestration. Dans ce cas, chaque
l'orchestration apparaît dans son propre sous-ensemble appelé Pool.

11.2 Chorégraphie

Un modèle de processus de chorégraphie est une définition du comportement attendu (un

classe de contrat procédures ou protocole) entre les participants qui interagissent.
Ces participants peuvent être des rôles d'affaires généraux (par exemple, un expéditeur)
ou une entité commerciale spécifique (par exemple, FedEx en tant qu'entreprise de transport).

Une chorégraphie décrit les interactions des participants.

Incluez autant de chemins alternatifs et parallèles, ainsi que des sous-processus. De cette manière

era, les objets de flux (Activités, Événements et Passerelles) des modèles d'orchestration
s'applique également aux modèles de chorégraphie.
Les connecteurs entre les Pools sont le Flux de Messages.

11.3 Collaboration

Alors que la chorégraphie montre l'ensemble ordonné (protocole) des interactions entre
les participants.
Une collaboration peut également contenir une chorégraphie (lorsqu'elle est disponible en
BPMN) et une ou plusieurs orchestrations.

Une collaboration est tout diagramme BPMN contenant deux participants ou plus comme
il se montre avec les Pools. Les Pools ont un Flux de Messages entre eux. N'importe lequel de
Les Pools peuvent contenir une orchestration (un Processus), mais ce n'est pas requis.
 RÉFÉRENCES BIBLIOGRAPHIQUES

Básique

HITPASS, Bernard, BPM : Gestion des processus d'affaires Fondamentaux et

Conceptos de Implementación, Segunda Edición. Chile: Editorial BHH Ltda, 2013.

Complémentaire

BERND RUKER, Jakob. Manuel de Référence et Guide Pratique BPMN 2.0. Cuarte
Éducion, Chili : Éditeur Dimacofi, 2014. Joyanes Aguilar, Luis. Structure de
Données. 1ère éd. Espagne : McGraw-Hill ; 2000.

BPMN 2.0, Bizagi Suite[en ligne]. [Consulté : 20 juin 2015]. Disponible sur
Web: [Link]

Guide de spécification BPMN[en ligne], [Consulté : 03 juin 2015]. Disponible

sur le Web[Link]