4. Des processus au SI Informations des messages et dictionnaire Modélisation des données La dynamique :diagrammes d’état La dynamique : modèles de WorkFlow Données, processus et stratégie d'organisation

Les Informations Identifier les INFORMATIONS des messages. Nature des informations identification des messages et des événements qu'ils concernent identification des origines, destinataires, événements amont description des événements en termes de temps, espace et forme avec la précision du système opérationnel Constituer le dictionnaire des informations Gestionnaire Transports Transporteur CR transport Ordre de transport N° CR_TRP N° RV Nom Transporteur N° Site Etc. Date Heure début Durée Référence produit Quantité +/- N° Site

Structurer les messages Les informations des messages se structurent en groupes hiérarchisés, répétitifs ou non: Modèle du message - CR transport Corps du CR Infos du groupe N° CR_TRP Nom Transporteur Rendez-vous (infos sur la réalisation des RV) Produits manipulés lors du RV Infos du groupe Référence produit Quantité +/- Infos du groupe N° RV Date Heure début Durée N° Site

Dictionnaire d’informations (1) Dans le contexte de chaque message la signification de chaque information est (en général) claire Pour l’émetteur Pour le destinataire Cependant il se peut que l’émetteur et le destinataire ne désignent pas de la même façon ces informations Il se peut que certaines désignations d’informations soient employées par divers acteurs pour des informations différentes Le dictionnaire d’informations est destiné à doter l’organisme d’un vocabulaire de référence, éliminant : Les polysémies exactes (même désignation pour deux informations) Les polysémies approchées (désignations voisines pour deux informations) Les synonymies (deux désignations pour la même information) non repérées

Dictionnaire d’informations (2) Toutes les polysémies doivent être éliminées Les synonymies sont tolérables si elles sont signalées Les polysémies exactes peuvent se repérer automatiquement On introduit dans le dictionnaire les informations acteur par acteur et message reçu ou émis par message reçu ou émis On accompagne chaque information de sa définition par l’acteur Au moment où l’on tente d’entrer une information dont la désignation est déjà présente, on constate une polysémie exacte si le sens est différent

Dictionnaire d’informations (3) Les synonymies et les polysémies approchées peuvent être traquées grâce à un système de mots-clés On dresse une liste officielle d’une centaine de « mots clés », représentant le vocabulaire de base de l’organisme (Ex : client, fournisseur, commande, …) Au moment de son introduction, chaque information est accompagnée d’une indication de sa « classe » (Ex : alphanumérique, numérique, date, heure …), ainsi que d’une liste de mots-clés, tirés de la liste officielle A une « classe » d’information et à un mot-clé correspond alors une liste d’informations assez courte pour que la comparaison des définitions permette de diagnostiquer des synonymies ou des polysémies approchées Exemple : « date livraison », « date livr » et « date de livraison » sont des dates ayant « livraison » comme mot-clé : selon que le sens est le même ou non, il y a synonymie ou polysémie approchée

Cas des informations calculées Quantité livrée Prix tarif Taux de remise... Informations en entrée REGLE DE CALCUL DU MONTANT HT DE LA LIGNE DE FACTURE Montant HT de la ligne de facture Information en sortie Les règles de calcul servent parfois à la définition de certaines informations

Le Modèle de données Elaborer une représentation structurée des données que le système devra garder en mémoire. Un langage de description de données : le formalisme Classe / Association.

Le Modèle de données Mémoriser : les commandes, les produits proposés à la clientèle, les clients, les rendez-vous, ... Client Livraison Agence Transporteur Gestionnaire Stocks Gestionnaire Transports Magasinier Commande acceptée Problème de dispo Ordre de Fabrication Demande de transfert Transport RV enlèvement RV Livraison Enlèvement Dde Achat Négoce agence AR Commande

Le Modèle de données Une métaphore provisoire : des fiches dans des tiroirs Une classe représente une catégorie particulière d'objets, dont tous les exemplaires (instances) peuvent être décrits de la même manière. Commande Client Transporteur Site

Le Modèle de données Une autre métaphore : des liens entre les fiches Les associations représentent les types de liens qui doivent être mémorisés entre les instances des classes .

Construction du Modèle de données Candidats à devenir des classes : les acteurs internes ou externes (client, transporteur, ...), les flux ou messages (commande, Rendez-vous, CR de transport, ...), les objets mentionnés dans les messages (produit, site, ...). Candidats à devenir des associations : les liens d'émission et de réception (client-commande), les liens de tranformation (commande-ordre de trf), l'expression des flux en termes d'autres flux ou objets. Remarques : certains partenaires ne donneront pas de classe ("instance" unique), les flux qui créent des partenaires ou des objets donnent la même classe que ces partenaires ou objets, plusieurs flux peuvent donner la même classe ...

Ebauche du Modèle de données

Finition du Modèle de données

Le Modèle de données Les classes peuvent être décrites par des informations : leurs attributs. Pour doter une association d'attributs, on lui adjoint une "classe d'association".

Le Modèle de données A combien d’ordres de transport correspond une étape ? au moins, au plus ? Multiplicités minimum et maximum : nombres max et min d'instances de la classe auxquelles est reliée une unstance de l'autre classe Combinaisons usuelles : 0..1 ; 1..* ; 1..1 (ou 1 en abrégé) et 0,* (ou *)

Le Modèle de données Une classe peut se spécialiser en sous-classes Les classes spécialisées "héritent" de ses attributs et associations mais peuvent être dotées d'attributs ou d'associations propres Des associations peuvent servir à relier des instances d'une même classe

Correspondances avec d’autres formalismes Relationnel : Client [Id_Client], Commande [Id_Commande, A livrer le, Moment Commande, Id_Client], Produit [Id_Produit, Nom Produit, Code Produit], Concerne [Id_Commande, Id_Produit, Quantité commandée

La dynamique : "opérations" des classes (que font les objets ?) Les objets (instances) d'une classe sont capables d'un comportement conforme aux "opérations" de la classe, décrites par ses "méthodes" Les spécialisations héritent aussi des opérations Il s'agit ici d'opérations du niveau "logiciel" et non plus "conceptuel" ou "organisationnel" Commande Moment Commande A livrer le Annulation commande() Lancement commande() Création commande() Affectation commande()

La dynamique : "diagrammes d'état" (que deviennent les objets ?) Le diagramme d'état montre les différents états possibles des instances d'une classe avec les transitions d'un état à l'autre et ce qui les cause

La dynamique : modèles de WorkFlow (1) Un "WorkFlow de production" confie des tâches (WorkItems) aux membres de l'organisation Pour cela, un "moteur" exploite des "définitions de process" : La définition des étapes, et en particulier de leur degré de finesse, doit privilégier le point de vue des ressources humaines (éviter l’éclatement en tâches élémentaires)

La dynamique : modèles de WorkFlow (2) Chaque étape d’une "Définition de processus" doit être munie d’une description et disposer d’une règle d’affectation Certaines étapes de modèles de WorkFlow peuvent consister à lancer l’exécution d’une autre "Définition de processus" Asynchronous Lancer_réappro_CdA AD Desc Lancer réappro Réappro WF_Assign. Rule AR_Lancer_réappro_CdA Lancer_réappro_Inventaire Lancer_réappro_PV AR_Lancer_réappro_Inv AR_Lancer_réappro_PV Remarques : La description d’étape « desc Lancer réappro » est partagée par des étapes de appartenant à 3 « définitions de processus » différentes Les règles d’affectation sont propres au contexte et définies de façon séparée pour les 3 étapes, dans le contexte de leurs « définitions de processus » respectives

Des procédures aux modèles de WorkFlow (1) Ce qu’est une exécution d’un modèle de WorkFlow doit être une notion claire (il en est de même pour les exécutions de chaque étape d’un modèle) Cela peut conduire à instrumenter une même procédure par plusieurs modèles de WorkFlow ("définitions de process") Procédure Cde- Liv agence Cde-livraison agence Plan de transport du jour

Des procédures aux modèles de WorkFlow (2) A son tour, un même modèle de WorkFlow peut instrumenter des parties de plusieurs procédures (éventuellement issues de plusieurs processus), par exemple : Commande- Livraison Appel Procédure Cde-Liv agence Appels Ordres transfert (C tél NU) Plan de transport du jour Commandes tél non urgentes Cde-livraison Fabrication Fabrication_1 Fabrication_1 & O transfert PF

Des processus et procédures aux applicatifs et aux modèles de WorkFlow (Process Definitions) Les processus se placent au niveau conceptuel : ils fournissent à la fois le contenu fonctionnel du travail avec ses objets de gestion (Business Objects), leurs états munis de leurs enchaînements, et les étapes théoriques du travail Les procédures montrent les variantes d’affectation des étapes théoriques aux acteurs et leur regroupement en étapes pratiques, dont le contenu est défini plus haut ; elles déterminent la couche de présentation Les modèles de WorkFlow instrumentent les procédures et assurent le contrôle et le suivi de leur déroulement : ils donnent la main aux personnes en mettant à leur disposition les modules logiciels et les données dont elles ont besoin.

Données, processus et stratégie d'organisation La définition des processus est un préalable à celle des indicateurs de performance ces indicateurs sont toujours fondés sur des informations décrivant les flux d'entrée et de sortie des processus ils font partie du système des informations stratégiques La modélisation (description) des processus est un préalable à la conception du SI c'est elle qui permet de définir les "classes" d'objets et leurs associations, base du système de données c'est elle qui permet de définir la dynamique (locale) des classes à partir de la dynamique globale

Métamodèle des composants montrés dans les cartographies

Commentaires sur le métamodèle Une opération peut appartenir à plusieurs processus, une tâche à plusieurs procédures Par décomposition ou spécialisation, on peut les affiner en vue d ’exiger une multiplicité max de 1 Une activité intervient dans plusieurs processus, ce qui comporte des écueils De même pour les acteurs et les procédures Pourtant, ces diagrammes de flux sont le meilleur support pour imaginer des réingénieries Au niveau conceptuel les étapes définissent le contenu professionnel ; aux niveaux inférieurs, ce contenu n’est connu que par référence Le choc des deux mondes (celui des objets et celui des événements) a lieu dans les logiciels de WorkFlow. A chaque ProcessDefinition, et à chacune de ses ProcessActivities est attachée une classe et, en "Run Time", pour chaque exécution d'un ProcessDefinition et pour chaque exécution d'une de ses ProcessActivities va être créée un instance de la classe correspondante, laquelle instance va posséder un cycle de vie, avec par exemple les états suivants : créée, prête, active, terminée ou avortée. Cette exigence n'est pas souvent à l'esprit des concepteurs de processus et autres procédures des niveaux "supérieurs"... Par exemple, qu'est-ce qu'UNE occurrence du processus Commande-livraison, si une livraison "regroupe" des "morceaux de commande" ? C'est une raison pour laquelle, quoi qu'en disent certains éditeurs, les ProcessDefinitions sont bien du "niveau logiciel" et non pas "organisationnel". Et il y a de la valeur ajoutée dans le passage...