• Aucun résultat trouvé

Théorie et Pratique du Système d’Information Sixième Chapitre: Pilotage des Processus

N/A
N/A
Protected

Academic year: 2022

Partager "Théorie et Pratique du Système d’Information Sixième Chapitre: Pilotage des Processus"

Copied!
36
0
0

Texte intégral

(1)

Théorie et Pratique du Système d’Information Sixième Chapitre: Pilotage des Processus

Janvier-Mars 2009 Ecole Polytechnique

Yves Caseau

(2)

Plan du Cours – Architecture du Système d’Information

Première partie:

Introduction et Formalisation

Deuxième partie:

Modélisation

Troisième partie:

Pilotage

(3)

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

(4)

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

(5)

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

(6)

Une représentation UML

Première Partie: Formalisation

(7)

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

(8)

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

(9)

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

(10)

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

(11)

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

(12)

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

(13)

Deuxième partie

• Introduction et Formalisation

Modélisation par processus

• Pilotage des processus

(14)

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

(15)

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

(16)

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

(17)

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

(18)

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

(19)

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

(20)

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

(21)

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

(22)

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

(23)

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

(24)

Troisième Partie

• Introduction et Formalisation

• Modélisation par processus

Pilotage des processus

(25)

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

(26)

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

(27)

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

(28)

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

(29)

Processus Internes de la DSI

• CMMI

• ITIL (Chap.

• Cf. TD ☺ 8)

Troisième Partie: Pilotage

(30)

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

(31)

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

(32)

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

(33)

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

(34)

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

(35)

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

(36)

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

Références

Documents relatifs

Elle consiste tout d’abord à rendre compte du fonctionnement des activités d’un organisme à partir du concept de processus, ensemble d’activités corrélées ayant

Plus précisément, dans une première partie nous proposons une typologie du pilotage industriel, le concept de centre de pilotage, la structure locale du processus de pilotage et

Christine Baratte, Philippe Faverdin, Eric Ramat, Cyrille Rigolot.. To cite

De plus, nous ne voulons pas seulement être en mesure d’indiquer les services qui permettent de résoudre un problème fonctionnel, mais nous voulons aussi donner les va- leurs

[31] A. Friedmann, Stochastic di¤erential equations and applications, Vol. Funaki, A certain class of di¤usion processes associated with non linear parabolic

Comme nous allons le voir plus loin, cela signifie que les systèmes TYn sont très différents non seulement des logiques d’ordre supérieur de Richard Montague (et en particulier de

Cette topologie de recouvrement peut se composer `a la fois de connections point ` a point et de zones b´en´eficiant d’un routage multicast natif (par exemple dans chaque site)..

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of