Théorie et Pratique du Système d’Information Sixième Chapitre: Pilotage des Processus
Janvier-Mars 2009 Ecole Polytechnique
Yves Caseau
Plan du Cours – Architecture du Système d’Information
• Première partie:
Introduction et Formalisation
• Deuxième partie:
Modélisation
• Troisième partie:
Pilotage
Processus : Exemple
CRM : Accueil
Banque : Validation coordonnées bancaires
Base client : enregistrement
CRM :
Retour négatif
Dataware house
CRM :
Retour positif Facturation
Provisioning
Base Client
Traitement échec début
Coordonnées Validées ?
KO client
KO technique Activation
Cohérente ?
Première Partie: Formalisation
Processus: Modélisation
• Modéliser un processus consiste à:
o Identifier les tâches qui participent à un objectif commun
o Identifier les acteurs et les responsabilités
o Identifier les dépendances
o Identifier le mode opératoire
• Il existe des méthodes et des standards pour formaliser et décrire
o UML : le formalisme le plus répandu pour décrire un système d’information
o BP__: une famille de normes
BPMN: notation
BPEL: exécution Première Partie: Formalisation
Exemple Bouygues Telecom
Payer d’avance Déclarer Sous- cription d’offre
Traiter souscription
Enregistrer contact
Provisionnement Technique
Créer client, FS et services com.
Clôturer souscription
Informer Client Enregistrer CR
Souscription dans Facturation Souscription dans
Valorisation
Commissionnement et logistique
Provisionnement Services 6esens
Première Partie: Formalisation
Une représentation UML
Première Partie: Formalisation
Le concept de processus
« Suite d’actions conduisant à un but défini »
• Décomposition temporelle/séquentielle
• Décomposition tâche/sous-tâche par rôle
• Décomposition par « événements »
o Actes de communication traçables
• Modèle sémantique global commun (ex: le « client »)
Première Partie: Formalisation
Historique (Processus Métiers)
• Adam Smith (« Pin factory »)
o Division du travail : simplifier (tâche), spécialiser
• Frederic Taylor (« Scientific Management »)
o Focus sur le « workflow » (cf. H. Gantt)
o Job shops & queing systems
• W. Edwards Deming (PCDA wheel -1950+)
o Gestion de la qualité, Statistical Process Control
• Workflow (70s & 80s)
o Focus sur l’individu et sur le flux de documents
• Business Process Re-engineering(1990 – Michael Hammer)
o Formalisation et optimisation des processus
o Focus sur le client -
• Chaine de valeur (1985 – Michael Porter)
o Analyse de la création de valeur Première Partie: Formalisation
Processus, Evénements et Services
• Evénements
o Les événements clients font partie du modèle métier
o EDO : Event-Driven Architecture
Couplage faible et distribution facile
o BRMS : réagir aux événements avec des règles (CEP)
Enrichissement du langage de description
• Logique d’enchainement « Business logic »
o Cf. cours #X, extraire la « logique métier » des applications augmente l’agilité
• Services
o La notion de service est liée à la mutualisation/réutilisation des tâches élémentaires
o Attention aux effets de perspective (encapsulation/ décapsulation)
Un processus défini comme un enchainement de services
L’exécution d’un service est un processus
o Le partage de service induit des couplages (cf. cours 7) Première Partie: Formalisation
Pi-calcul
• Le Pi-calcul (ou π-calcul) est un langage de programmation théorique inventé par Robin Milner. Ce langage occupe dans le domaine de
l'informatique parallèle et distribuée un rôle similaire à celui du λ- calcul dans l'informatique classique. (Wikipedia)
• Un terme représente un ensemble de processus communicants (issu de CSP) qui s’exécute de façon concurrente => support aux
implémentations parallèles et distribuées.
• Unification : un « nom » = un canal de communication = une information.
Permet de passer des canaux par paramètre, ou de créer des canaux, ce qui se prête au « mobile computing » - interaction dynamique entre processus
• Le pi-calcul est une base sémantique (calcul formel permettant de donner une sémantique) pour de nombreux types de « processus », allant des processus « systèmes » informatique aux processus métiers complexes
o Utilisé pour donner une sémantique à BPEL/ XLANG*
o Utilisé pour décrire des implémentations de BPMS (Biztalk)
Première Partie: Formalisation
Introduction au pi-calcul
• Syntaxe:
• le processus nil, noté 0. Ce terme ne fait rien – il s'agit d'un processus qui a terminé de s'exécuter.
• l'émission (asynchrone) d'un message: le processus a<b> émet sur le canal a l'information b.
• La réception d'un message se note a(x).P et se comporte de la manière suivante: si un processus de la forme est présent, il y a communication entre les processus.
• Si P et Q sont deux processus, P | Q est la composition parallèle de P et Q.
• La réplication: !P représente une réplication infinie de P
• le processus (νx)P (prononcer new x P) crée un nouveau canal, qui sera désigné sous le nom x dans P.
• Un processus peut tester l'égalité entre deux noms.
Première Partie: Formalisation
Pi-calcul et BPMS
• « Workflow is just a Pi process » H. Smith & P. Fingar
o Modèle adapté aux processus dynamiques
Ex: collaboration par email
Puissance du passage de canal par paramètre
o Adapté aux « processus mobile »
o Le modèle pour l’exécution distribuée de workflow
• « BPMS is more than a pi-process »
o Un processus métier (avec un client) vs. une collaboration de processus
o Ignore la problématique de distribution de données (cf. chap. 7)
Soit les données sont répliquées et la gestion est explicite
Soit on introduit une infrastructure centrale de données
o Ignore la problématique de contrôle/traçabilité (cf. chap. 8)
A réintroduire avec une infrastructure de contrôle…
… distribuée ou non Première Partie: Formalisation
Deuxième partie
• Introduction et Formalisation
• Modélisation par processus
• Pilotage des processus
Processus et UML
• Rappel: ce qui existe en UML
o Diagramme de cas d’utilisation (Use case)
Vision claire des acteurs du processus
o Diagramme d’activité (swim lanes)
Enchaînements
o Diagramme de séquence
Orienté SI (messages)
• Avantages de la modélisation en UML
o Se pratique avec la MOA
o Pas de formalisme nouveau à apprendre
o Permet différents niveaux de détails
• Limites
o Rupture de formalisme
o Processus complexes illisibles
o Lien avec l’exécution Deuxième Partie: Modélisation
BPMN : Business Process Modeling Notation
• Objets:
événements, activités, portes
• Connexions:
séquence, message, association
• Artefacts
o Pool/lanes
o Groupes
o Données
o Annotations Deuxième Partie: Modélisation
BPEL
• BPEL : un dialecte XML pour spécifier et
exécuter les processus
o Évolution récente:
WS-BPEL 2.0
o Origines: WFSL et XLANG
• 3 composants:
o Logique: BPEL
o Data types: XSD
o I/O: WSDL
• Cf. TD ☺
<process name="purchaseOrderProcess" ...>
<eventHandlers>
<onEvent partnerLink="purchasing"
operation="queryPurchaseOrderStatus" ...>
<correlations>
<correlation set="PurchaseOrder" initiate="no" />
</correlations>
<scope>...</scope>
</onEvent>
...
<sequence>
<receive partnerLink="purchasing"
operation="sendPurchaseOrder" ...
createInstance="yes">
</receive>
...
<reply partnerLink="purchasing"
operation="sendPurchaseOrder" ...>
<correlations>
<correlation set="PurchaseOrder" initiate="yes" />
</correlations>
</reply>
...
<!-- process the purchase order -->
...
</sequence>
Deuxième Partie: Modélisation
Processus, Échanges et Services
• Synergie:
o Processus = invocations de services liées par des échanges
o Même triangle causal que précédemment (données, services, processus)
o Objectifs de stabilité: données > échanges > services >
processus
• Importance XML
o Les schémas XML forment la grammaire des échanges
Importance de l’ingénierie XML
o Il y a de bonnes et moins bonnes représentations
Ex: compatibilité ascendante
• Importance SOA
o Un catalogue pour favoriser la réutilisation
o Une architecture de services pour favoriser la mutualisation Deuxième Partie: Modélisation
Processus et Matrices d’Intéractions
• Dependency Structure Matrix (DSM)
o Développées à l’origine pour l’optimisation des processus
o Utilisées en génie logiciel pour le « refactoring »
o http://www.dsmweb.org
• Un outil pour décomposer
o Produite à partir des
activités/fonctions/services élémentaires
o Faire apparaitre les clusters
• Un outil pour ordonnancer
o Feedback loops
o Cf. pivot de Gauss/
diagonalisation ☺
• Fait partie de la boite à outils des méthodologies
o ex: Lean Six Sigma
D J K L M N A B E F I H C P O G
Radiator DD
Engine fan J J
Heater Core K K
Heater Hoses L L
Condenser M M
Compressor N N
Evaporator Case A A X
Evaporator Core B X B X
Accumulator E X E X X
Refrigeration ControlsF X F X X
Air Controls I X I X
Sensors H X X X H X
Command DistributionC C X
Actuators P X X P X X
Blower Controls O X O
Blower Motor G X G
Deuxième Partie: Modélisation
Récursivité et Granularité
• Le concept de processus est un concept récursif
o Les tâches/activités sont elles-mêmes des processus
o Les enchaînements sont souvent des processus techniques
o La notion de processus métier (BP) est plus restrictive:
Client, objectif, mesures doivent être identifiés
• La notion de granularité est fondamentale pour communiquer
o Quelques macros processus (5 à 10)
o Quelques dizaines de processus métiers
o Quelques centaines de :
Sous-processus métiers (détaillés)
Processus « informatiques » (vue du SI)
o Encore plus de « processus techniques »
Outil organisation (PPT)
Le bon niveau pour le BPM
Deuxième Partie: Modélisation
Rôles
Activité1 Activité2 Activité3
Métier 1
Responsable processus
Métier 2
Changement = projet informatique
Vision patrimoniale:
Applications services
MOA
processus
résultat
Projet métier UML
formalisation Exécution
Système
Informatique applications
Métier 3
Deuxième Partie: Modélisation
Gestion des demandes et sous-processus
1. Les processus ne sont pas indépendants
o Dépendances liées aux ressources partagées (objets)
o Dépendances métiers
o Il faut valider (exclusions):
2. Il faut respecter la cohérence
o Ensemble d’actions qui forment un tout
o Gestion de « transactions longues »
3. Demande @ niveau N = processus @ N-1
o urbanisation fractale ☺
Différents niveaux de moteurs d’orchestration
o Gérer les demandes en paramètre (cf. pi-calcul)
Gestion des demandes Événement
externe
Etat Règles
Deuxième Partie: Modélisation
Accostage et Abstraction
On peut donc distinguer 4 types de processus
• les processus métier
• les processus fonctionnels
• les processus techniques/applicatifs
• les processus physiques/systèmes
Les liens entre les niveaux s'appellent
• les accostages Ils permettent de savoir
• ce qu'il advient si on arrête une machine
• l'impact de la croissance d'un processus métier...
L’accostage n’est pas un isomorphisme
• différents niveaux d’abstraction
• différence de granularité
Deuxième Partie: Modélisation
Résumé : Pourquoi une approche processus ?
• Sortir la « business logic » des applications
o Pour la modifier (rare)
o Pour la tracer & la piloter (cf. plus loin)
o Pour l’enrichir (fréquent)
• Pour gérer la complexité
o Découplage temporel
o Rôles fonctionnels
o Paralléliser
• Pour faire émerger les événements & les services
o extensibilité
o Mutualisation
• Gérer une transaction longue : cohérence
o Les exceptions
o AMDEC
o Rollback – cf. cours suivant
•
Deuxième Partie: Modélisation
Troisième Partie
• Introduction et Formalisation
• Modélisation par processus
• Pilotage des processus
Rôle des SI : Pilotage
• Enjeux:
o Pouvoir « tracer » de « bout-en-bout »
o pouvoir mesurer ce qui a du sens (métier)
• Leviers:
o modèle métier (sémantique uniforme) choisir
Cf. besoins du DWH
o architecture de données, collecter
Qui est propriétaire de quoi
Nettoyage et qualité des données
o agilité (tableaux de bord) assembler Troisième Partie: Pilotage
Rôle des SI: Automatisation
• Qu’est-ce que l’ « Orientation processus » ?
o La représentation des processus dans le SI est explicite et modifiable
o Le déroulement est automatisé/contrôlé
• Enjeux
o Temps de réaction plus court
o Contre-mesure plus précise et plus efficace
o À long terme: optimisation continue (on-demand)
• Difficultés
o Extirper la logique d’enchaînement des applications => refonte
o Besoin de méthodes et formations MOA pour exprimer des besoins « orienté-processus »
Troisième Partie: Pilotage
Processus et Urbanisation
Gestion des Processus
Gestion des Objets Métiers
Infrastructure
Systèmes Techniques
CRM Gestion Facturation DWH Provisioning
Processus Entreprise
P1
P2
Tâche
Tâche
Tâche
Tâche
Processus
Processus Techniques
Transport Annuaires
distribution
Troisième Partie: Pilotage
Processus et Projets
La transformation du SI nécessite un double accostage:
• Métier -> processus
• Processus -> SI
Le SI évolue par lots (les ST) avec une cohérence nécessaire entre les lots (intégration)
Principe du train
(extrait du « manuel DCSI » de Bouygues Telecom)
Version de ST
L’évolution d’un ST est véhiculée par un projet informatique
Version d’Intégration Système cohérente
Une version regroupe et pilote des projets intégrés entre eux
Projets clients
Les besoins des clients sont apportés par les Projets Clients
Gare =
ST (…) STn
Les besoins sont affectés à des systèmes techniques ST
Troisième Partie: Pilotage
Processus Internes de la DSI
• CMMI
• ITIL (Chap.
• Cf. TD ☺ 8)
Troisième Partie: Pilotage
Pourquoi le BPM
• BPM:
o Organisation de l’entreprise autour de ses processus
o Amélioration continue des performances
o Recherche de l’agilité dans l’adaptation continue des processus
• Contexte:
o « hyper-compétition » => excellence (Burlton)
o « orientation client » => recherche qualité (Galbraith)
• Le SI comme levier stratégique:
o Le pilotage du processus selon une stratégie = un système d’information
o La réactivité et l’agilité s’appuient sur l’automatisation Troisième Partie: Pilotage
Pourquoi une « approche processus » ?
1. Alignement - Key performance indicators (KPI)
2. Satisfaction client 3. Réduction des
exceptions/anomalies (ex: 6sigma) 4. Optimiser les interfaces
1. Allocation de ressources
2. « Time to market » - réduction du
« lead process time » (Lean) 3. Analyse des modes de
défaillance – continuité de fonctionnement
Tâche 1 Tâche 2 Tâche 3
(5)
(1)
(2) (6) (7)
(8)
(4) (3) Troisième Partie: Pilotage
Le processus du BPM et ses acteurs
• Au delà de « nous faisons tous des processus sans le savoir »
• Acteurs et interfaces
o Métier / contrôle de gestion : mesure / valeur
o Métier/ DSI : alignement processus métier et processus opérationnels
o Système d’information : produire les bons indicateurs
o Qualité/métier: culture TQM/6sigma
Analyse de la valeur
Analyse des
processus
Mesure des
processus
Analyse Amélioration Implémentation
Troisième Partie: Pilotage
Exemples Métiers
• Processus de Facturation
• Processus d’Activation de Services
• Processus de Commissionnement
Collecter Actes usage
Valoriser Facturer Mettre la Facture à disposition
Demande
client Qualifier
Besoin Provisionni
ng Suivre la
demande Retour client
Collecter Collecter Corrélation Appliquer Distribuer
• Macro-Processus
• Répartitions des rôles dans des directions différentes
Troisième Partie: Pilotage
Application au pilotage DSI
• Processus de « livrer un projet » -> CMMi
• Enjeux:
o Ne pas optimiser les maillons sans une mesure de bout-en-bout
o Pas de gains d’efficacité sans mesure de valeur (Mieux vs. Moins)
• Processus de « Qualité de Données »
o Enjeux:
Un processus très complexe et très transverse qui n’existe pas dans l’organisation
Impact majeur sur la qualité de service Exprimer
Besoin Qualifier
Besoin Spécifier Développer Tester/
Intégrer
Bon
usage Filtrage
Vérification Cohérence
Echanges Audit
Synchronisation Nettoyage
Troisième Partie: Pilotage
Echelle de maturité
• La démarche BPM est une « révolution tranquille » sur de
Analyse de la valeur
Analyse des
processus
Mesure des
processus
Analyse Amélioration Implémentation
Proportion de la valeur affectée à un processus
Degré de formalisation des processus
Industria- lisation de la mesure
Modélisation de la performance économique
Automatisation du
pilotage Informatisation des processus métiers
Réactivité du cycle
d’optimisation 100%
0%
100% Temps réel
Continu planifié Ad hoc
Soluble équations modèlisé
Ad hoc BPM dynamique
Processflow automatisé manuel
continu automatisé agile 0% lent
100%
0%
« orientation-processus du SI »
Troisième Partie: Pilotage
Illustration : Pilotage des flux urbains
• Fluidité
• Temps
moyen de transport
• Impact écologique
?
Analyse de la valeur
Analyse des
processus
Mesure des
processus
Analyse Amélioration Implémentation
• Feux
tricolores
• Réseaux
• Règles
• comptages
• Vitesse par caméra
Modèles Écoulement trafic
Modèles avec apprentissage Modèles Dynamiques (algorithmes)
Pilotage dynamique des feux
100%
0%
100%
0%
100%
0%
100%
0%
100%
0%
100%
0%
• Application à la gestion des feux tricolores dans une ville:
Troisième Partie: Pilotage