Cours chapitre6 2012


Published on

Cours sur le système d'information en 9 chapitres

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Suite d'actions conduisant à un but défini. Suite d'états ou de phases de l'organisation d'une opération ou d'une transformation
    (Informatique) Tâche en train de s’exécuter.
    (Gestion de la qualité) Système d'activités qui utilise des ressources (personnel, équipement, matériels, informations) pour transformer des éléments entrants en éléments de sortie dont le résultat final attendu est un produit ou un service.
  • From
    Schéma tiré de ISO 9001
    The concept of PDCA comes out of the Scientific Method, as developed from the work of Francis Bacon (Novum Organum, 1620). The scientific method can be written as "hypothesis" - "experiment" - "evaluation" or Plan, Do, and Check. Shewhartdescribed manufacture under "control" - under statistical control - as a three step process of specification, production, and inspection.[1] He also specifically related this to the Scientific Method of hypothesis, experiment and evaluation. Shewhart[2]says that the statistician "must help to change the demand [for goods] by to close up the tolerance range and to improve the quality of goods." Clearly, Shewhart intended the analyst to take action based on the conclusions of the evaluation. According to Deming[3] during his lectures in Japan in the early 1950's the Japanese participants shortened the steps to the now traditional Plan, Do, Check, Act. Deming preferred Plan, Do, Study, Act because 'Study' has connotations in English closer to Shewhart's intent than "Check."
    r. Deming's teachings and philosophy can be seen through the results they produced when they were adopted by the Japanese, as the following example shows: Ford Motor Company was simultaneously manufacturing a car model with transmissions made in Japan and the United States. Soon after the car model was on the market, Ford customers were requesting the model with Japanese transmission over the USA-made transmission, and they were willing to wait for the Japanese model. As both transmissions were made to the same specifications, Ford engineers could not understand the customer preference for the model with Japanese transmission. It delivered smoother performance with a lower defect rate. Finally, Ford engineers decided to take apart the two different transmissions. The American-made car parts were all within specified tolerance levels. On the other hand, the Japanese car parts had much closer tolerances than the USA-made parts - i.e. if a part was supposed to be one foot long, plus or minus 1/8 of an inch - then the Japanese parts were within 1/16 of an inch. This made the Japanese cars run more smoothly and customers experienced fewer problems. [3].
  • Envoie les noms des printers sur le canal spool : liste de disponible
  • Use case: enchainement pas clair
    Swim lane: trop d’acteurs
  • Source:
    Business Process Modeling Notation (BPMN) is a graphical representation for specifying business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is currently maintained by the Object Management Group since the two organizations merged in 2005. The current version of BPMN is 1.1, and a major revision process for BPMN 2.0 is in progress.
    Sequence Flow: A Sequence Flow is represented with a solid line and arrowhead and shows in which order the activities will be performed. A diagonal slash across the line close to the origin indicates a default choice of a decision.
    Message Flow: A Message Flow is represented with a dashed line and an open arrowhead. It tells us what messages flow between two process participants.
    Association: An Association is represented with a dotted line and a line arrowhead. It is used to associate an Artifact, data or text to a Flow Object.
  • WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.
    The origins of BPEL can be traced to WSFL and XLANG. It is serialized in XML and aims to enable programming in the large. The concepts of programming in the large andprogramming in the small distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes.
    Web Services Flow Language (WSFL) is an XML language proposed by IBM to describe the composition of Web services. WSFL has been superseded by BPEL.
    IBM and Microsoft had each defined their own, fairly similar, 'programming in the large' languages, WSFL and XLANG, respectively. With the popularity and advent of BPML, and the growing success of and the open BPMS movement led by JBoss and Intalio Inc., IBM and Microsoft decided to combine these languages into a new language, BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft, SAP and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web Services BPEL Technical Committee. Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL technical committee voted on 14 September 2004 to name their spec WS-BPEL 2.0. This change in name was done to align BPEL with other Web Service standard naming conventions which start with WS- and accounts for the significant enhancements between BPEL4WS 1.1 and WS-BPEL 2.0. If you are not discussing a specific version, the moniker BPEL is commonly used[citation needed].
    In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People and WS-HumanTask specifications, which describe how human interaction in BPEL processes can be implemented.
  • Attention au catalogue
  • Figure p. 182
    Cf. P. Haren – garbage in – garbage out
  • Burlton, R.T.,  Business Process Management. Sams, Indianapolis, 2001.
    Galbraith J.,  Designing Organizations. Jossey-Bass, Wiley, 1998.
  • Chaque point mérite un exposé à lui tout seul
    Il ne sert à rien de pousser l’approche processus si l’on ne comprend pas les bénéfices concrets
    Cette compréhension n’est ni simple ni intuitive
  • CMMI et ITIL
  • Cours chapitre6 2012

    1. 1. Théorie et Pratique du Système d’Information Sixième Chapitre: Pilotage des Processus Janvier-Mars 2012 Ecole Polytechnique Yves Caseau Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 1/29
    2. 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  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 2/29
    3. 3. Première Partie: Formalisation Processus: Modélisation  Modéliser un processus consiste à:      Identifier les tâches qui participent à un objectif commun Identifier les acteurs et les responsabilités Identifier les dépendances Identifier le mode opératoire Il existe des méthodes et des standards pour formaliser et décrire   UML : le formalisme le plus répandu pour décrire un système d’information BP__: une famille de normes  BPMN: notation  BPEL: exécution II.1 : Processus - Principes Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 3 3/29
    4. 4. Première Partie: Formalisation Processus : Exemple KO client Banque : Validation coordonnées bancaires Coordonnées Validées ? début CRM : Accueil Base client : enregistrement CRM : Retour négatif Provisioning Activation Cohérente ? CRM : Retour positif Facturation Base Client  Dataware house Traitement échec KO technique Un processus est un « enchaînement » de tâches liées à un objectif (client/ valeur) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 4 4/29
    5. 5. Première Partie: Formalisation Exemple Bouygues Telecom Déclarer Souscription d’offre Payer d’avance Enregistrer contact Traiter souscription Provisionnement Technique Créer client, FS et services com. Souscription dans Valorisation Souscription dans Facturation Commissionnement et logistique Informer Client Clôturer souscription Provisionnement Services 6esens Enregistrer CR Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 5/29
    6. 6. Première Partie: Formalisation Une représentation UML : SF Dialogue clients/instancie/FORFAIT : SF Gestion des reglements/instancie/FORFAIT *SF Dialogue clients/instancie/FORFAIT* *SF Gestion des reglements/instancie/FORFAIT* : SF Ventes aux clients SP/instancie/FORFAIT *SF Ventes aux clients SP/instancie/FORFAIT* : SF Configuration et activ ation des serv ices/instanci... *SF Configuration et activation des services/instancie/FORFAIT* : RF Clients SP *RF Clients SP* : SF Assistance clientele SP/instanc ie/FORFAIT *SF Assistance clientele SP/instancie/FORFAIT* : SF Valorisation SP/instancie /FORFAIT *SF Valorisation SP/instancie/FORFAIT* : SF Facturation SP/instancie/FORFAIT *SF Facturation SP/instancie/FORFAIT* : SF Ventes aux distributeurs/mutualise *SF Ventes aux distributeurs/mutualise* : SF Configuration et activ ation des serv ices/i... *SF Configuration et activation des services/instancie/6emeSENS* Souscription d'offre princ ou promot et évent d'offres sec demandée Déclarer sousc offres princ ou promot et sec F-GC02 Paiement avance CB non demandé[ NON ] Paiement avance CB demandé ? Paiement avance CB demandé[ OUI ] Payer l'avance CB F-GC02 Traiter sousc offres princ ou promot et sec F-GC02 Enregistrer contact sousc offres princ ou promot et sec validée F-GC02 Souscription offres princ ou promot et sec validée Exécuter provisionnement sur le réseau technique F-GC02 Créer client, formule souscrite et services commerciaux F-GC02 Prendre en compte souscription offres princ ou promot et sec par valorisation F-GC02 Prendre en compte souscription offres princ ou promot et sec par facturation F-GC02 <<business process>> Gestion au fil de l'eau du commissionnement, de la logistique et du SAV. T-CO24 Provisionner MMS F-GC02 Compte rendu du provisioning réseau Compte rendu de la valorisation Compte rendu de la facturation AND Compte rendu du provisionning MMS Clôturer sousc offres princ ou promot et sec F-GC02 Résultats consolidés Informer client F-GC02 Enregistrer compte rendu global F-GC02 Souscription d'offre princ ou promot et évent d'offres sec effectuée II.pes Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 6/29
    7. 7. 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 »   Actes de communication traçables Modèle sémantique global commun (ex: le « client ») Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 7/29
    8. 8. Première Partie: Formalisation Historique (Processus Métiers)  Adam Smith (« Pin factory »)   Frederic Taylor (« Scientific Management »)    Focus sur l’individu et sur le flux de documents Business Process Re-engineering(1990 – Michael Hammer)    Gestion de la qualité, Statistical Process Control Workflow (70s & 80s)   Focus sur le « workflow » (cf. H. Gantt) Job shops & queing systems W. Edwards Deming (PCDA wheel -1950+)   Division du travail : simplifier (tâche), spécialiser Formalisation et optimisation des processus Focus sur le client - Chaine de valeur (1985 – Michael Porter)  Analyse de la création de valeur Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 8/29
    9. 9. Première Partie: Formalisation Alignement Stratégique du SI  L’« alignement » est construit sur les processus à partir de la  chaîne de valeur et de la stratégie Stratégie Système d’information Ex :Balanced Scorecard Expérience client Chaîne(s) de valeur Organisation Pilotage Processus pilotage Processus métiers Processus support Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) Systèmes informatiques Contribution aux processus : •Support •Pilotage •Exécution 9/29
    10. 10. 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    Utilisé pour donner une sémantique à BPEL/ XLANG* Utilisé pour décrire des implémentations de BPMS (Biztalk) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 10/29
    11. 11. 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.  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 11/29
    12. 12. Deuxième partie Introduction et Formalisation  Modélisation par processus  Pilotage des processus  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 12/29
    13. 13. Deuxième Partie: Modélisation Processus et UML  Rappel: ce qui existe en UML     Avantages de la modélisation en UML     Diagramme de cas d’utilisation (Use case)  Vision claire des acteurs du processus Diagramme d’activité (swim lanes)  Enchaînements Diagramme de séquence  Orienté SI (messages) Se pratique avec la MOA Pas de formalisme nouveau à apprendre Permet différents niveaux de détails Limites    Rupture de formalisme  Processus complexes illisibles Lien avec l’exécution  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 13/29
    14. 14. Deuxième Partie: Modélisation BPMN : Business Process Modeling Notation  Objets:  événements, activités, portes  Connexions: séquence, message, association  Artefacts  Pool/lanes  Groupes  Données  Annotations Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 14/29
    15. 15. Deuxième Partie: Modélisation BPEL  BPEL : un dialecte XML  pour spécifier et exécuter  les processus  Évolution récente:  WS-BPEL 2.0   Origines: WFSL et  XLANG  3 composants:    Logique: BPEL Data types: XSD I/O: WSDL <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> Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 15/29
    16. 16. Deuxième Partie: Modélisation Processus et Matrices d’Intéractions  Dependency Structure Matrix (DSM)     Un outil pour décomposer    Produite à partir des  activités/fonctions/services  élémentaires Faire apparaitre les clusters Un outil pour ordonnancer    Développées à l’origine pour l’optimisation des processus Utilisées en génie logiciel pour le « refactoring » Feedback loops Cf. pivot de Gauss/  diagonalisation  Fait partie de la boite à outils des méthodologies  D J K L M N A B E F I H C P O G D D                               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 Controls F                 X  F  X  X          Air Controls I                   X  I  X          Sensors H                 X  X  X  H    X      Command Distribution C                         C  X      Actuators P                       X  X  P  X  X  Blower Controls O                           X  O    Blower Motor G                           X   G    Radiator ex: Lean Six Sigma Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 16/29
    17. 17. Deuxième Partie: Modélisation Récursivité et Granularité  Le concept de processus est un concept récursif     Les tâches/activités sont elles-mêmes des processus Les enchaînements sont souvent des processus techniques 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     Quelques macros processus (5 à 10) Quelques dizaines de processus métiers Quelques centaines de :  Sous-processus métiers (détaillés)  Processus « informatiques » (vue du SI) Encore plus de « processus techniques » Outil organisation (PPT) Le bon niveau pour le BPM Uniquement pour les procédures et les projets Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 17/29
    18. 18. Deuxième Partie: Modélisation Métier 1 Rôles Exécution Activité2 Activité1 Activité3 Responsable processus résultat UML formalisation MOA processus Métier 2 Système Informatique Projet métier applications Changement = projet informatique DSI Conception Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) Pilotage Vision patrimoniale: Applications services Métier 3 Catalogue Services 18/29
    19. 19. Deuxième Partie: Modélisation Gestion des demandes et sous-processus 1. Les processus ne sont pas indépendants   ⇒ Dépendances liées aux ressources partagées (objets) Dépendances métiers Il faut valider (exclusions): Événement externe Gestion des demandes Etat 1. Règles Il faut respecter la cohérence  ⇒ 1. Ensemble d’actions qui forment un tout Gestion de « transactions longues » Demande @ niveau N = processus @ N-1   urbanisation fractale   Différents niveaux de moteurs d’orchestration Gérer les demandes en paramètre (cf. pi-calcul) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 19/29
    20. 20. Deuxième Partie: Modélisation Accostage et Abstraction Modèle d’entreprise METIER Modèle du SI informatisé FONCTIONNEL 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... TECHNIQUE L’accostage n’est pas un isomorphisme • différents niveaux d’abstraction • différence de granularité PHYSIQUE Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 20/29
    21. 21. Deuxième Partie: Modélisation Résumé : Pourquoi une approche processus ?     Sortir la « business logic » des applications  Pour la modifier (rare)  Pour la tracer & la piloter (cf. plus loin)  Pour l’enrichir (fréquent) Pour gérer la complexité  Découplage temporel  Rôles fonctionnels  Paralléliser Pour faire émerger les événements & les services  extensibilité  Mutualisation Gérer une transaction longue : cohérence  Les exceptions  AMDEC  Rollback – cf. cours suivant Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 21/29
    22. 22. Troisième Partie    Introduction et Formalisation Modélisation par processus Pilotage des processus Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 22/29
    23. 23. Troisième Partie: Pilotage Orchestration de Processus Pour voir plus clair, il faut distinguer (Cummins): • Le processus • L’instance de processus Requester • La requête BPRMS (easy) Process A Definition CCS Process A instance Process Manager BPRMS (hard) Ressource Assignement Facilites Process B instance La gestion des demandes (Requester) joue un rôle clé: • vérifier la validité sémantique des paramètres (cf. QoD) • CCS • Lieu d’implémentation de règles (enrichissement) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 23/29
    24. 24. Troisième Partie: Pilotage Rôle des SI: Automatisation  Qu’est-ce que l’ « Orientation processus » ?    Enjeux -  La représentation des processus dans le SI est explicite et modifiable Le déroulement est automatisé/contrôlé Temps de réaction plus court Contre-mesure plus précise et plus efficace À long terme: optimisation continue (on-demand) Difficultés   Extirper la logique d’enchaînement des applications => refonte Besoin de méthodes et formations MOA pour exprimer des besoins « orienté-processus » Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 24/29
    25. 25. Troisième Partie: Pilotage Pourquoi le BPM  BPM:     Contexte:    Organisation de l’entreprise autour de ses processus Amélioration continue des performances Recherche de l’agilité dans l’adaptation continue des processus « hyper-compétition » => excellence (Burlton) « orientation client » => recherche qualité (Galbraith) Le SI comme levier stratégique:   Le pilotage du processus selon une stratégie = un système d’information La réactivité et l’agilité s’appuient sur l’automatisation III.1 : BPM – Principes Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 25/29
    26. 26. Troisième Partie: Pilotage Pourquoi une « approche processus » ? (5) (8) (3) (1) (7) Tâche 2 Tâche 1 Tâche 3 (2) (4) (1) (2) (3) (4) Alignement - Key performance indicators (KPI) Satisfaction client Réduction des exceptions/anomalies (ex: 6sigma) Optimiser les interfaces (6) (5) (6) (7) (8) Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) I : Contexte - Processus Métiers Allocation de ressources « Time to market » - réduction du « lead process time » (Lean) Analyse des modes de défaillance – continuité de fonctionnement Capitalisation / Apprentissage 26/29
    27. 27. Troisième Partie: Pilotage Application au pilotage DSI  Processus de « livrer un projet » -> CMMi Exprimer Besoin  Spécifier Développer Tester/ Intégrer Enjeux:    Qualifier Besoin Ne pas optimiser les maillons sans une mesure de bout-en-bout Pas de gains d’efficacité sans mesure de valeur (Mieux vs. Moins) Processus de « Qualité de Données » Bon usage  Filtrage Vérification Cohérence Echanges Audit Synchronisation Nettoyage Enjeux:   Un processus très complexe et très transverse qui n’existe pas dans l’organisation Impact majeur sur la qualité de service Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 27/29
    28. 28. Troisième Partie: Pilotage Processus Internes de la DSI CMMI  ITIL (Chap. 8)  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VI) 28/29
    29. 29. Exemple: Démarche CMMI pour la DCSI Indicateurs performance Plan Qualité Mesure Continue Implication CODCSI Suivi performance Formation Règles Sous-processus CMMI à améliorer •Pratiques •Vision DCSI Indicateur suivi Suivi Déploiement Analyse « Six-sigma » (déviation) Appréciation Performance (bonus) Mise à jour Règles Étape CMMI / Evaluation  Changement culturel profond : apprendre à aimer ses erreurs … IV: Plan d’action – 2012 - Cours Polytechnique (VI) Copyright © Yves Caseau 29/29