MÉMOIRE - theses.univ-oran1.dztheses.univ-oran1.dz/document/TH4211.pdf · essentielles dans la gestion dune entreprise industrielle. Elle permet aussi de donner ... Notre objectif

MÉMOIRE

Présenté pour l’obtention du Diplôme de Magister

Spécialité : Informatique

Option : Ingénierie des Données et des Connaissances

Par : Mr. MENAD Si Mohamed Bekkai

Titre

CONCEPTION D’UN PROCESSUS DE

DEVELOPPEMENT PAR UML – WORKFLOW:

ACTIVITÉS BUDGETAIRES (AVAL/Sonatrach)

Soutenu le ……..… / ……..… / …………… devant la commission de jury :

Mr. RAHMOUNI Mustapha Kamel, Professeur à l’Université d’Oran Président

Mr. Abdi Mustapha Kamel, Maître de Conférences à l’Université d’Oran Examinateur

Mr. Atmani Baghdad, Maître de Conférences à l’Université d’Oran Examinateur

Mme Nait Bahloul Safia, Maître de Conférences à l’Université d’Oran Encadreur

Mr. Draou Abbes, Chef de Département-Etude et Développement–AVAL/Sonatrach- Invité

ةـــــة الشعبيــــــة الديمقراطيــــالجزائري الجمهـــــوريةRépublique Algérienne Démocratique et Populaire

يـــــــــــــــــث العلمــي والبحـــــــالــــــــــم العـــــــوزارة التعليMinistère de l’Enseignement Supérieur et de la Recherche Scientifique

الدقيقة والتطبيقية موـــــة العــــلــــــــكليFaculté des Sciences Exactes et Appliquées

لــم اإلعــقسآ يـــــــــالم ال

Département Informatique

11 03 2014

Remerciements

Je tiens tout d’abord à remercier Madame Nait Bahloul Safia, maître de

conférence (MCA) à l'université d’Oran, de m'avoir guidé, soutenu, aidé, conseillé et encouragé au cours de ce projet. Qu'elle trouve ici, l'expression de ma sincère

reconnaissance et considération.

Je tiens aussi à remercier :

- Monsieur Rahmouni Mustapha Kamel, Professeur à l'université d’Oran de m’avoir

fait l’honneur d’accepter de présider le jury de ma soutenance.

- Messieurs Atmani Baghdad et Abdi Mustapha Kamel, maîtres de conférence à

l'université d’Oran pour l’honneur qu’ils m’ont fait de juger ce travail.

- Monsieur Draou Abbes, chef de département études développement et intégration au niveau de l’activité AVAL/Sonatrach – oran, d’avoir accepté de faire partie de ce jury en tant qu’invité.

Je remercie également tout le personnel d’encadrement pédagogique et

administratif de département informatique de la faculté des sciences de l’université d’Oran, et en particulier le chef de département Mr. le docteur Bouamrane K., Mme Meziane Hassina. Maître de conférence à l’université d’Oran, Mlle. Benabbou Amel Maître assistant à l’université de Mostaganem, Mr. Benaribi Fethi Imad, maître assistant à l’université de Ain Témouchent et Mme. Benouadah Mokhtaria pour

leurs aides, conseils et encouragements.

Je remercie aussi tout le personnel du service des traitements au niveau de la

direction de l’éducation de Mostaganem, et en particulier le chef de service Mr. Si Afif Med Benali pour le soutien qui m’a accordé au long de ce projet, le chef de bureau Mr.Saadoun Habib pour son aide et mes collègues de bureau des professeurs d’enseignement secondaire.

Je n'omettrais pas de remercier vivement tout le personnel de département

études développement et intégration au niveau de l’activité AVAL/Sonatrach – Oran,

avec lesquels j'ai pu échanger des idées, discuter, partager et vivre des moments agréables parmi eux.

Enfin, un grand et chaleureux merci à ma femme pour sa patience et son

soutien moral pendant toutes ces années de travail.

Je dédie ce modeste travail à :

Mes défunts parents,

Ma femme et ma petite étoile Amira-Dehiba,

Mes beaux parents,

Mes défunts frères et sœurs,

Mes frères et mes sœurs,

Mes familles Menad, Bernou, Djordem, Mortet et Tekkouk ,

Mes neveux et surtout Touati et Abdellah Benkhatab.

Résumé

i

Résumé : Le budget est un processus lourd et complexe à mettre en œuvre. Le

premier rôle du budget est de donner un cadre pour l’exercice à venir. La gestion

budgétaire est un mode de gestion qui englobe tous les aspects de l'activité de

l'organisation qui comprend une période de budgétisation (construction de l'ensemble

cohérents de prévisions chiffrées) puis une période de contrôle budgétaire. Les

prévisions budgétaires et leur planification au cours de toute l’année est une des parties

essentielles dans la gestion d’une entreprise industrielle. Elle permet aussi de donner

des délais courts aux demandes/commandes des clients et des agents de l’entreprise.

La gestion et le contrôle budgétaire au niveau de l’activité Sonatrach/AVAL n’adopte

pas de technique et de méthode automatique suffisante à la solution du processus

budgétaire. Les difficultés à ce niveau peuvent être vues classées en deux catégories :

des problèmes de gestion et des problèmes de contrôle. Le projet de l’automatisation de

la gestion et du contrôle budgétaire devient donc une nécessité prioritaire.

Notre objectif dans ce projet est la mise en place d'une solution informatique au

problème de la gestion et de contrôle des budgets au niveau de l'activité

Sonatrach/AVAL. Notre objectif final dans ce projet est l'adoption d'une approche

organisationnelle et méthodologique qui vise une automatisation de la gestion et du

contrôle des processus budgétaires et la mise en œuvre d'une solution généralisée pour

l'optimisation de la solution au niveau de l'activité AVAL. Une bonne prévision

budgétaire annuelle permet d’honorer les meilleures dépenses des clients et agents de

l’entreprise Sonatrach/AVAL. Les méthodes de prise en charge des flux utilisées seront

UML et Workflow, les outils de validation des modèles de conception seront

l’utilisation du Logiciel MagicDraw pour la génération des fichiers BPEL.

Mots-clés : Modèle, Système d’information, UML, Workflow, Processus métier, BPEL, Modélisation,

Validation, Représentation relationnelle, Activité budgétaire, Sonatrach/AVAL

Sommaire

ii

Problématique et introduction générale …………..………………………….…………………….………..………..……01

Chapitre I : Modélisation d’un Système

1. Introduction ………………..…………………………….…………………………………….……………….………….….……………….…05

2. L’approche orientée objet ………………..…………………………….…………………….……………………………...….…05 2.1. Introduction …………………………………………………..……………………….…………………………..…….……….…...…05 2.2. Concepts importants ……………………………………………………………………………………………………..………06

a. Classe et Objet …………………………………………………………..………………………..………………………………...……06

b. Association …………………………………………………………..………………………………..………………………………....…06

c. Agrégation …………………………………………..………………..………………………………..……………………………………07

d. Composition ………………………………………………………..…………………………………..…………………………….……07

e. Héritage, Spécialisation, Généralisation et Polymorphisme ………….………………….……07

3. Le Langage UML ………………..…………………………………………………………………………………………………..….……08

3.1. Introduction …………..…………………………………..…………………………………………………………….…..….….…08 3.2. Les diagrammes UML ………………………………………………………………………………….….……..…..….…08 3.3. Diagrammes de classes ……………………………………………………………………………….……………..…..…09 3.4. Diagrammes d’objets …………………………………………………....……………………………….….…………......10 3.5. Diagrammes de composants …………………………………………………………………….……..…….………11 3.6. Diagrammes de structures composites ………………………………………………………..…..………11 3.7. Diagrammes de déploiement ………………………………………………………..…………………….…………11 3.8. Diagrammes de package ………………………………………………..…………………………….…………….……12 3.9. Diagrammes de cas d’utilisation …………………………………………………………..…………….….……12 3.10. Diagrammes d’activités ……………………………………………………………………………….……….…….….…14 3.11. Diagrammes d’états-transitions ………………………………………..………………………..……..…..….…15 3.12. Diagrammes de séquence …………………………………………….…………………………….………………...…16 3.13. Diagrammes de communication ……………………………………………………………………….……...…18

4. Conclusion ………………..……………………..……………………………………………………………….………………..………...….…19

Chapitre II : La technologie des WorkFlows

1. Historique ………………..…………………………….…….…………………………………….……………….……………….…….….……20

2. Introduction ………………..…………………………….……..……………………………………………….………………….….…...……20

3. Concepts clés ………………..………………………….……………………………………………………..……………….…….…….……21 3.1. Processus métier …………..…………………………..………………………………………………….…………………..………21 3.2. Modèle de processus ………………………………………………………………………………………….……………..……21 3.3. Tâche ……….………………………………………………………………………………………………………………….…………….……21

3.4. Nœud…………………………………………………………………………......………………………..…….……………………..….….…22 3.5. Types de nœuds ……………………………………………………………..…………………..……………….………….….……22

Sommaire

iii

3.6. Transitions ……….………………………………………………………………………………………….….………………………..….22 3.7. Evènement …………………………………………………………………………………………………..…….…………..…….…...…22

4. Workflow et processus métier …………………………………………………………………….………………..…………22

5. Aperçu sur les Workflow ………………………………………………………………………..………………………….………23

5.1. Modèle de référence …………..…………………..………………………………………………….……………………………24 5.2. Système de gestion des Workflow ……………………………………………………………………………..……25 5.3. Workflow et business objects …………………………………………………………………….………………….……26

6. Application d’UML sur les Workflow …………………………..……………………………………………………27

7. Langages de spécification de Workflow …………………..…………………………………………….…….…..30

8. Conclusion …………..…………………………………………………………………………………………………….…..………………....…30

Chapitre III : Langage d’Exécution des processus métiers (BPEL)

1. Introduction ………………..…………………………….……..……………………………………………….……………….………….……31 2. Processus métier et fichier BPEL………………..……….………….…………….……………….…………….……..……31

3. Concepts fondamentaux et syntaxe de BPEL ………………..…………..……….………………….….….…31

3.1. Syntaxe des éléments de base …………..……………………………………………….…………………………….…32 3.2. Syntaxe des éléments basés sur les messages …………....……………………………………….………33 3.3. Syntaxe des éléments de contrôles structurés …………..……………………………………..…..……33 3.4. Syntaxe des éléments de contrôles évolués …………..………………………….………………………..34

Chapitre IV : Modélisation d’un processus métier par UML-Workflow

1. Définition ………………..…………………………….……..…………………………………………………….……………….………...……37

2. Aspects à modéliser………………..……….……………………………………………………….…………..……..……………..……37

2.1. Aspect fonctionnel…………..………………………………………………………..………………….………...…………………37 2.2. Aspect comportemental …………..…………………………………………….……………….……………………….……37 2.3. Aspect informationnel …………..………………………………………………………………….………………………..…38 2.4. Aspect organisationnel …………..……………………………………………….……………….……………….…….….…38

3. Présentation du système à modéliser ………………..……….…………………………….…………….....……..…39

3.1. Les objectifs stratégiques de la société SONATRACH ……….……………………….….……38 3.2. Les différentes structures de SONATRACH …………….……………….…………………………...…39

3.2.1. L’activité AVAL …………..………………………………………………..………………..….…………………….………39 3.2.2. La Direction d’Informatique et de Systèmes d’Information ……….……..….………40 3.2.3. Le Département Systèmes Informatique …………….…………………………………....……………41

3.3. Présentation du cahier de charges …………….…………………………………….…………………………...…41 3.3.1. Description de la procédure de l’élaboration du budget PA et PMT de

département ‘Production’ …………..……………………..……..………………..….……………………..………41

Sommaire

iv

3.3.2. Description de la procédure de l’élaboration du budget PA et PMT de département ‘Finances’ …………..……………………..……..……………………..….…………………….….……42

3.3.3. Description de la procédure de validation des prévisions de consommations quantitatives pour les articles non gérés en stocks (M) du plan annuel (PA) et PMT ……..……..……………………..……..………………………..…….….………45

4. Modélisation par UML ………………………………..………………………….……..……………………………………….……46

4.1. Modélisation statique ……….……………………………………………………………………………………......….………46 4.1.1. Diagramme de classes …………..………………………..………….………….……………………………….………47

4.2. Modélisation dynamique ……….………………………………………………………………………………………….…48 4.2.1. Diagramme d’activités de la fonction Production (P) …….…………..…………..…………49 4.2.2. Diagramme d’activités de la fonction Finances (F) …………..……..…….………….….……51 4.2.3. Diagramme d’activités de la fonction Validation des prévisions de

consommations non gérées en stock (M) ………………………………..……………….……….....…52

5. Modélisation par Workflow ………………………………….……..……….…………………………………………….……54

5.1. Eléments de diagrammes de processus Workflow ……….….……………………….……...……54 5.2. Modélisation des diagrammes de processus Workflow ….…….…………….………….……55

5.2.1. Diagramme de processus métier de la fonction production (P)…………..….....…56 5.2.2. Diagramme de processus métier de la fonction finance(F) …………………..........…57 5.2.3. Diagramme de processus métier de la fonction validation des

prévisions des consommations des articles non gérés en stock (M) ….....…...58

5.2.4. Diagramme de processus métier de la fonction Approvisionnement (A)…………………………………..………………………………………………………………………...…………………...…….59

5.2.5. Diagramme de processus métier de la fonction Système d’information et de Gestion (SIG)……………………….….………..…………….…….………………..…………………….….......60

5.2.6. Diagramme de processus métier de la fonction Administration et Social (S)……….…………………………………………………….………………………………….…………………………….…….......61

5.2.7. Diagramme de processus métier de la fonction Service Relation de Travail (RT)…….………………………………………………………………….…………………….……….….…........62

5.2.8. Diagramme de processus métier de la fonction Moyens Généraux (M)……….……………………………………………….…………………………………….……………………………….….......63

5.2.9. Diagramme de processus métier de la fonction Ressources Humaines (R)……….…………………………………………………….………………………………….….………………………………......65

5.2.10. Diagramme de processus métier de la fonction Passation des Marchés (PM)……….……………………………………………….….…………………………….………………………….…………......66

5.2.11. Diagramme de processus métier de la fonction Assistant Sûreté Interne (ASI)…….………………………………………………….………………………………….…………………………….………....67

5.2.12. Diagramme de processus métier de la fonction conseil syndical …..….....…68 5.2.13. Diagramme de processus métier de la fonction maintenance(G) ….........…69 5.2.14. Diagramme de processus métier de la direction de l’unité, D*E et D*S…...70 5.2.15. Diagramme de processus métier de la fonction technique(T) ….................…71 5.2.16. Diagramme de processus métier de la fonction sécurité industrielle(I)...72

Sommaire

v

5.2.17. Diagramme de processus métier de la fonction travaux neufs(W) …......…73 5.2.18. Diagramme de processus métier de la fonction validation des

prévisions des stocks, d’achats et de consommations des articles gérés en stock (A) ………………………………………………………………………..….....…...74

5.2.19. Diagramme de processus métier de la fonction validation des prévisions des stocks, d’achats et de consommations des articles non gérés en stock (A) ….....…………………………………………………………………………………………....76

5.2.20. Diagramme de processus métier de la fonction validation des prévisions consolidées d’achats et consommations articles non gérés en stock (M) ….....………………………………………………………………………………………………….....77

Chapitre V : Validation des diagrammes de processus Workflow

5.1 Introduction…...……………………….……………………………………………………………………………………...…….…..….79 5.2 Génération des fichier de validation BPEL ………………………………………………...……….…..….79

5.2.1 Fichier BPEL du diagramme de processus métier de la fonction (P) …..….....82 5.2.2 Fichier BPEL du diagramme de processus métier de la fonction (F)……........85 5.2.3 Fichier BPEL du diagramme de processus métier de la fonction

validation des prévisions de consommations non gérées en stock (M)…....86

Chapitre VI : Architecture des processus métiers du système étudié et Représentation relationnelle du système étudié

1. Introduction ………………..……….……………………………………………………..……………………….……………….………...……88 2. Architecture des processus métiers ………………..……….…………………………….……………….………...……88

2.1. Architecture du processus métier de département Production ………..…….………..88 2.2. Architecture du processus métier de département Approvisionnement…....90 2.3. Architecture du processus métier de département Maintenance………….………...91 2.4. Architecture du processus métier de département Sécurité industrielle …....92 2.5. Architecture du processus métier de département Moyens généraux ……......93 2.6. Architecture du processus métier de département Technique……………..……..…...94 2.7. Architecture du processus métier de département Travaux neufs………...….....95

3. Représentation relationnelle du modèle statique ……………………………….……………….…..……96 3.1. Règles de passage du modèle conceptuel au modèle relationnel……….…….……..96 3.2. Schéma du modèle relationnel relatif au modèle statique conçu………….…..……..96

Conclusion générale ……………………………………………………..……………………………………………………………...….….....98

Annexe 01 : Complément de diagrammes d’activités du système étudié ……………...100

Annexe 02 : Présentation intégrale du cahier de charges du système étudié ….…...117

Bibliographie : ………………………………………………………………………………………………………….…………………………......138

PPrroobblléémmaattiiqquuee

&&

IInnttrroodduuccttiioonn ggéénnéérraallee

Problématique et Introduction Générale

Conception d’un Processus de Développement par UML-WorkFlow

1

Problématique et introduction générale

Le budget est un processus lourd et complexe à mettre en œuvre. Les entreprises

n’ont pas encore trouvé d’autres alternatives pour encadrer à la fois leurs investissements,

leurs dépenses, allouer les ressources nécessaires et donner des objectifs aux actions à venir.

Le premier rôle du budget est de donner un cadre pour l’exercice à venir. Le budget décline

insuffisamment la stratégie de l’entreprise au niveau opérationnel.

En somme, le budget est décrit comme mobilisant des ressources considérables

pour une utilité discutée. Pour être plus dynamique et en adéquation avec les orientations

stratégiques, il devrait être réactualisé plus fréquemment.

Les entreprises doivent constamment faire preuve de capacité d’adaptation et procèdent à

des révisions tarifaires fréquentes. Les mutations fréquentes au sein de l’entreprise

impactent le processus budgétaire. A cet égard, l’entreprise doit être dotée d’un processus

budgétaire évolutif et capable d’appréhender les modifications de structure. Les données

saisies doivent pouvoir être manipulées en cours d’exercice afin de prendre en compte ces

changements parfois considérables (fusion/ désinvestissement).

La construction du budget au sein des structures AVAL/Sonatrach est très majoritairement

réalisée par tableur où la consolidation des données devient très complexe.

Les outils utilisés manquent de flexibilité pour appréhender les évolutions de l’entreprise et

de capacité à suivre l’intégralité des flux d’informations. Les outils limités dans leur

fonctionnalité favorisent les dysfonctionnements.

Le contrôle de gestion est un processus transversal destiné à aider les responsables

de service à piloter leurs activités et à agir dans le sens de la stratégie, il a un rôle d'interface

entre le plan stratégique et opérationnel. Il permet d'obtenir l'assurance que les ressources

sont obtenues et utilisées de manière efficace (atteindre les objectifs) et efficiente (utilisation

des ressources). Le budget est un outil classique et en général un outil central du contrôle de

gestion, puisque c’est à travers de son élaboration que sont précisés les objectifs de

l’entreprise et que sont définis les objectifs de chaque manager et les moyens qui seront mis

à sa disposition sur l’exercice considéré.

La gestion budgétaire est un mode de gestion qui englobe tous les aspects de l'activité de

l'organisation qui comprend une période de budgétisation (construction de l'ensemble

cohérents de prévisions chiffrées) puis une période de contrôle budgétaire.

La gestion et le contrôle budgétaire au niveau de l’activité AVAL/Sonatrach n’adopte pas de

technique et de méthode automatique suffisante à la solution du processus budgétaire sus



2

mentionnée. Les difficultés à ce niveau peuvent être vues classées en deux catégories : des

problèmes de gestion et des problèmes de contrôle.

D’autre part, la circulation des supports budgétaires se fait d’une manière manuelle et ainsi

les flux de communication deviennent moins contrôlables.

En contre partie, les problèmes liés au contrôle budgétaire concernent notamment la mise à

jour des fichiers Excel utilisés aux différents niveaux. Ces mises à jour sont achevées d’une

manière rudimentaire et aléatoire et le manque d’un mécanisme automatique pour ce

traitement (mise à jour des fichiers Excel) induit à une absence de traçabilité des historiques

des différents accès et opérations appliqués. En somme, toutes les transactions et les accès

effectués sur les fichiers à chaque niveau (service de validation) pour les différentes

structures ne sont pas pris en charge et l’unité budgétaire ne conçoit qu’une version finale

qui n’indique aucune trace des modifications antérieures.

Le problème lié au flux d’information de l’unité budgétaire a aussi un aspect sécurité :

identification des accès, gestion des authentifications et autorisation pendant les échanges

d’information au sein de l’unité de production, des divisions et direction.

Le projet de l’automatisation de la gestion et du contrôle budgétaire devient donc

une nécessité prioritaire.

Afin de permettre aux responsables de l’activité AVAL de la société nationale

SONATRACH de réaliser ce projet, nous allons concevoir un système d’information relatif à

l’élaboration des prévisions budgétaires des différentes structures de l’activité AVAL.

Mais tout d’abord quelle démarche pouvons nous suivre pour aboutir à notre

objectif ?

Selon [01], vu la complexité croissante des systèmes d’information, de nouvelles méthodes et outils ont été créées. La principale avancée réside dans la programmation orientée objet (P.O.O.). Ce nouveau mode de programmation a rapidement montré les limites des méthodes de modélisation classique (telle MERISE). La prise de conscience de l'importance d'une méthode spécifiquement objet ("Comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 méthodes objet sont apparues durant le milieu des années 90 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...). Aucune ne s'est réellement imposée.

Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception « orientée objet », l’OMG1 a eu comme objectif de définir une notation standard utilisable dans les développements informatiques basés sur l’objet. C’est ainsi qu’est apparu UML (Unified

1 L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont l’objectif est

de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA [20].



3

Modified Language), qui est issu de la fusion des méthodes Booch, OMT (Object Modelling Technique) et OOSE (Object Oriented Software Engineering). Issu du terrain et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à son développement.

En l'espace d'une poignée d'années seulement, UML est devenu un standard incontournable pour élaborer des modèles objet indépendamment de tout langage de programmation. Il permet tout à fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de décrire le rôle des acteurs du processus, la structure des éléments manipulés et produits, etc…

Devant la diversité des langages de programmation orientée objet, UML apparaît comme une espèce de standardisation graphique de ces langages, reprenant tous les mécanismes de base de l’orienté objet, même si leur traduction dans ces langages diffère. Cela permet aux personnes impliquées dans le développement logiciel de restreindre de plus en plus leur apport à la seule conceptualisation et analyse, en se libérant des contraintes syntaxiques propres aux langages et en différant de plus en plus les détails techniques liés à l’implémentation [ 11]. Grâce à UML, les objets s’envolent. Concrètement, un programmeur C++ et un programmeur Java, C#, Python ou PHP, pourront travailler, pour l’essentiel, dans un langage graphique commun, et automatiser, autant que faire se peut, la traduction des diagrammes dans les différents langages [11].

L’utilisation des workflow dans les entreprises permet l’automatisation des

différents processus de l’entreprise. Ceci conduit le concept de processus à occuper

aujourd’hui une place majeure dans le domaine des systèmes d’information [02].

Les entreprises se trouvant actuellement sur le marché ont bien compris les avantages que l’utilisation des systèmes de gestion de workflow pouvait leur apporter : gains de productivité, allocation plus efficace des ressources, maîtrise de la complexité inhérentes à de grands projets [03].

Comme le définit [04], UML est un « langage graphique destiné à la modélisation

de systèmes et de processus et il consiste en une série de symboles et de connecteurs qui

peuvent être utilisés pour créer des diagrammes de processus». D’autre part, Les

diagrammes de processus métiers de workflow sont très comparables aux diagrammes

d’activité UML, de par leur fonctionnement et leur représentation.

Finalement, ces points forts spécifiques à UML nous ont encouragés de procéder à

une démarche basée sur la modélisation UML-Workflow afin de concevoir notre futur

système d’information.

Outre l’introduction générale et la conclusion générale, ce mémoire est composé

de six chapitres. Dans le premier chapitre, nous allons parler de l’approche orientée objet et

du langage UML. Le deuxième chapitre sera consacré pour la technologie workflow. Une

présentation du langage BPEL (Business Process Execution Language) « langage

d’exécution des processus métiers » sera donnée dans le troisième chapitre. Notre



4

contribution sur la modélisation statique UML (Diagramme de classes) , la modélisation

dynamique UML-Workflow basée sur le principe des diagrammes d’activités sera présentée

dans le quatrième chapitre. Dans le chapitre cinq nous allons procéder à la validation de ces

derniers diagrammes en utilisant le logiciel MagicDraw pour les implémenter et les

transformer en fichiers BPEL sous format XML. En fin, nous allons présenter notre

contribution sur la conception des architectures des différents processus métiers relatifs à

l’élaboration des prévisions budgétaires, suivie de la représentation relationnelle de notre

modèle statique conçu.

CChhaappiittrree 11

MMooddéélliissaattiioonn dd’’uunn SSyyssttèèmmee

Chapitre I – Modélisation d’un système

5


1. Introduction

Selon [05], un modèle est une représentation abstraite et simplifiée (i.e. qui exclut

certains détails), d’une entité (phénomène, processus, système, etc.) du monde réel en vue de

le décrire, de l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une

connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.

Concrètement, un modèle reflète ce que le concepteur croit important pour la

compréhension et la prédiction du phénomène modélisé, les limites du phénomène modélisé

dépendant des objectifs du modèle.

Modéliser un système avant sa réalisation permet de mieux comprendre le

fonctionnement du système.

C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence. Un

modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il

est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est

essentielle pour aboutir à une compréhension commune aux différentes parties prenantes

(notamment entre la maîtrise d’ouvrage et maîtrise d’œuvre informatique) et précise d’un

problème donné.

Un modèle définit une frontière entre la réalité et la vision du concepteur. Ce n’est pas la

réalité, mais une vue très subjective de la réalité[03].

Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes

non triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les

modèles employés, la démarche de modélisation n’est pas la même.

2. L’approche orientée objet

2.1 Introduction

Dans l’approche orientée objet, tout système est vu comme un ensemble d’objets

dissociés, identifiés et définis par des propriétés. Une propriété est soit un attribut (i.e. une

donnée caractérisant l’état de l’objet), ou entité élémentaire comportementale de l’objet. La

fonctionnalité du système émerge alors de l’interaction entre les différents objets qui le

constituent. L’une des particularités de cette approche est qu’elle rapproche les données et

leurs traitements associés au sein d’un unique objet [05].

Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :

L’identité : L’objet possède une identité, qui permet de le distinguer des autres objets,

indépendamment de son état. On construit généralement cette identité grâce à un identifiant

découlant naturellement du problème (par exemple un produit pourra être repéré par un

code, une voiture par un numéro de série, etc.) [05].

Les attributs (Propriétés) : Ils représentent des variables stockant des informations sur l’état

de l’objet.


6


Les méthodes : L’ensemble des actions (opérations) que l’objet va réaliser est déterminé par

ses méthodes. Ces opérations permettent de faire réagir l’objet aux sollicitations extérieures

(ou d’agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs,

car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.

La difficulté de cette modélisation consiste à créer une représentation abstraite,

sous forme d’objets, d’entités ayant une existence matérielle (voiture, ampoule, personne,...)

ou bien virtuelle (client, temps,...).

2.2 Concepts importants

Nous avons vu que l’approche objet rapproche les données et leurs traitements.

Cette approche manipule un ensemble de concepts importants [ 12]:

a. Classe et Objet : Une classe est la description formelle d’un ensemble d’objets ayant

une sémantique et des propriétés communes. Elle représente des éléments concrets

(ex. des départements), des éléments abstraits (ex. des formations) ou des

composants d’une application (ex. les boutons des boites de dialogue).

Un objet est une instance d’une classe. Il représente une entité du

monde réel. Par exemple, Finances est une instance de la classe département.

Notation graphique

Figure 1.1- Représentation graphique d’une classe d’objets

b. Association : L’association décrit le lien statique entre plusieurs classes.

Notation graphique

Figure 1.2- Représentation graphique d’une association

Une association est dite réflexive si elle représente un lien entre des objets de la même classe.

Figure 1.3- Exemple d’association réflexive

Nom de la classe

- attribut_1 : Int … - attribut_n : String + opération_1() : void … + opération_m() : void

Nom d’association Classe1 Classe2

Personne

Est père de


7


c. Agrégation : C’est une forme particulière d’association où un tout est relié à ses parties. Le tout (la classe du côté du losange) est appelé agrégat et la classe en opposé est appelé agrégé (c.f : figure 1.4).

Figure 1.4- Exemple de relation d’agrégation

d. Composition : Lorsque que la suppression de l’objet agrégat mène à la suppression des objets agrégés, on dit que l’agrégation est forte, il s’agit donc d’une composition. Graphiquement, on ajoute un losange plein (◆) du côté de l’agrégat (cf. figure 1.5).

Figure 1.5- Exemple de relation de composition

e. Héritage, Spécialisation, Généralisation et polymorphisme : L’héritage est un

mécanisme de transmission des propriétés (attributs et méthodes) d’une classe (classe mère ou super classe) vers une sous-classe (classe fille). Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques communes d’un ensemble de classes. Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la réutilisation. Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des

objets de classes différentes.

Notation graphique

Figure 1.6- Représentation graphique d’héritage entre la classe mère « Employé »

et ses deux classes filles « Etudiant » et « Personne ».

Produit Commande

Commande Ligne Commande

Personne

Matricule

Nom

Prénom

Date de naissance

Vaccances(…)

DossierMédical(…)

Employé

Date de recrutement

Grade de l’employé

Calculer le salaire(…)

Etudiant

Date d’inscription

Niveau d’inscription

Spécialité d’étude

Calculer la moyenne annuelle(…)


8


3. UML

3.1 Introduction Selon [05], les méthodes utilisées dans les années 1980 pour organiser la

programmation impérative (notamment Merise) étaient fondées sur la modélisation séparée

des données et des traitements. Lorsque la programmation par objets prend de l’importance

au début des années 1990, la nécessité d’une méthode qui lui soit adaptée devient évidente.

UML (Unified Modeling Language en anglais, soit langage de modélisation objet unifié) est né de la fusion des trois méthodes qui s’imposaient dans le domaine de la modélisation objet au milieu des années 1990 : OMT, Booch et OOSE. D’important acteurs industriels (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) s’associent alors à l’effort et proposent UML 1.0 à l’OMG (Object Management Group) qui l’adopte en novembre 1997 dans sa version 1.1 comme langage de modélisation des systèmes d’information à objets. La version d’UML en cours à la fin de 2006 est UML 2.0 qui s’impose plus que jamais en tant que langage de modélisation standardisé pour la modélisation des systèmes, utilisé sur des centaines de projets dans le monde ; en conséquence, la connaissance d’UML est désormais une des compétences qui sont exigées quasi systématiquement lors d’un recrutement.

3.2 Les diagrammes UML

Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle [06]. C'est une perspective du modèle et non pas "le modèle".

UML 2.0 propose treize types de diagrammes pour décrire les concepts particuliers

d’un système. Ils se répartissent en deux grandes catégories [12] :

A. Diagrammes structurels ou diagrammes statiques (UML Structure)

– diagramme de classes (Class diagram)

– diagramme d’objets (Object diagram)

– diagramme de composants (Component diagram)

– diagramme de structures composites (Composite structure diagram)

– diagramme de déploiement (Deployment diagram)

– diagramme de paquetages (Package diagram)

B. Diagrammes comportementaux ou dynamiques (UML Behavior)

– diagramme de cas d’utilisation (Use case diagram)

– diagramme d’activités (Activity diagram)

– diagramme d’états-transitions (State machine diagram)

– Diagrammes d’interaction (Interaction diagram)

– Diagramme de séquence (Sequence diagram)

– diagramme de communication (Communication diagram)

– diagramme global d’interaction (Interaction overview diagram)


9


– diagramme de temps (Timing diagram)

Nous allons présenter les principaux diagrammes UML.

3.3 Diagramme de classes (Class Diagram)

3.3.1 Définition

Le diagramme de classes est considéré comme le plus important de la modélisation

orientée objet, il est le seul obligatoire lors d’une telle modélisation. Il permet de fournir une

représentation abstraite des objets du système et les différents types de relations statiques

qui existent entre eux.

3.3.2 Propriétés de classe

Une classe décrit un ensemble d’objets dotés de propriétés (attributs). Les

propriétés d’un objet permettent de spécifier son état et son comportement.

La syntaxe d’une propriété est la suivante : <visibilité> [ / ] <nom_attribut>:

<Type> [ ’[’ <multiplicité> ’]’ [ ’{’ <contrainte> ’}’ ] ] [ = <valeur_par_défaut> ]

Visibilité : Elle indique si l’attribut est public (+) ou privé (-) Type : Il peut être un nom de classe, un nom d’interface ou un type de donné

prédéfinie

Multiplicité : Elle indique le nombre de valeurs possibles de l’attribut.

Contrainte : pour préciser si les valeurs sont ordonnées ({ordered}).

3.3.3 Méthodes de classe

Une opération (même nom et même types de paramètres) doit être unique. La

déclaration d’une opération contient les types des paramètres et le type de la valeur de

retour, sa syntaxe est la suivante : <visibilité> <nom_méthode> ([ <paramètre> [, <paramètre> [, <paramètre> ...] ] ]) :

[<valeur_renvoyé>] [ { <propriétés> } ]

La syntaxe de définition d’un paramètre (<paramètre>) est la suivante :

[<direction>] <nom_paramètre>:<Type> [’[’<multiplicité>’]’] [=<valeur_par_défaut>]

La direction (<direction >) peut prendre l’une des valeurs suivante :

in : Paramètre d’entrée passé par valeur. Les modifications du paramètre ne sont pas

disponibles pour l’appelant. C’est le comportement par défaut.

out : Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la valeur finale est

disponible pour l’appelant.

inout : Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appelant.

Le type du paramètre (<Type>) peut être un nom de classe, un nom d’interface ou un type de

donné prédéfini.


10


Les propriétés (<propriétés>) correspondent à des contraintes ou à des informations

complémentaires comme les exceptions, les pré-conditions, les post-conditions ou encore

l’indication qu’une méthode est abstraite (mot-clef abstract), etc.

3.3.4 Association entre classes

Une association est une relation entre deux classes(association binaire cf. figure 1.7)

ou plus (association n-aire cf. figure 1.8), qui décrit les connexions structurelle entre leurs

instances. Elle est représentée par une ligne pleine et peut être ornée d’un nom, avec une

précision du sens de lecture (► ou ◄).

Figure 1.7– Association binaire

Figure 1.8– Association n-aire

3.3.5 Cardinalité

Elle indique le nombre d’objets d’une classe qui peuvent participer à l’association.

Elle est généralement définie avec une borne inférieure et une borne supérieure. Si les deux

bornes sont égales on utilise un seul nombre, dont ‘1..1’ est représentée par ‘1’, et ‘0..*’ par ‘*’

(infinie)

3.3.6 Classe d’association (associative)

Lorsqu’une association possède des propriétés caractérisant le lien entre les classes

associées, celle-ci est remplacée par une classe appelée classe associative et les propriétés du

lien deviennent attributs de cette classe.

Une classe-association est caractérisée par un trait discontinu entre la classe et

l’association qu’elle représente (Figure 1.9).

Figure 1.9 – Exemple de classe d’association

3.4 Diagramme d’objets (object Diagram)

Le diagramme d’objets représente un instantané des objets d’un système à un

moment donné [06]. Il est souvent appelé diagramme d’instance, car il représente des

instanciations de classes et non pas des classes (cf. figure 1.10).

1..* Travaille ► 1 Employé Organisme 1..*

1..* 1..1

Module Enseignant

Etudiant

Enseignant Module

Enseigner

Nombre d’heures


11


Figure 1.10 – Exemple de diagramme de classes et de diagramme d’objets associé (à droite).

3.5 Diagrammes de composants

Les diagrammes de composants permettent de décrire l’architecture physique et

statique des applications d’un système donné en termes de modules (fichiers, sources,

librairies, …) [12].

Figure 1.11 – Représentation graphique d’un composant

Généralement le concept composant est également très utilisé dans la conception des interfaces graphiques ( Un bouton, une zone de saisie… sont des composants [06].

3.6 Diagrammes de structure composite

Ces diagrammes font partie des nouveautés ramenées par UML 2.0. Ils permettent

de décomposer hiérarchiquement une classe en une structure interne [06].

Figure 1.12 – Un diagramme de structure composite décrivant une commande

3.7 Diagramme de déploiement (Deployment diagram) Les diagrammes de déploiement représentent l’agencement physique d’un

système montrant sur quels composants matériels les différents composants logiciels s’exécutent (cf. figure 1.13) [06]. Les principaux éléments sont des nœuds connectés par des voies de communication. Un nœud représentera une unité qui va héberger un logiciel, un équipement matériel ou ordinateur, un environnement d’exécution, un système d’exploitation, … etc.

Commande

Ligne de commande

Nom du composant

1..*

est affecté à

1..*

Enseignant

Département

nom : String

E2 : Enseignant E3 : Enseignant E1 :Enseignant

est affecté à est affecté à est affecté à

D:Département

nom : String= ’’Informatique’’


12


Figure 1.13 – Un diagramme de déploiement

3.8 Diagramme de package (Package diagram)

Les diagrammes de package permettent de grouper les éléments UML dans des

unités de plus haut niveau selon leurs types, leurs fonctionnalités ou leurs architectures. Ils

sont plus souvent utilisés pour grouper des classes.(cf. figure 1.14) [06].

Figure 1.14 – Exemple d’un diagramme de package

3.9 Diagramme de cas d’utilisation (Use Case Diagram)

Les diagrammes de cas d’utilisation décrivent le comportement d’un système, tel

qu’un utilisateur le voit. Ils permettent donc d’exprimer le besoin des utilisateurs d’un

système.

3.9.1 Éléments des diagrammes de cas d’utilisation

a) Acteur : Selon [08], un acteur est une entité du modèle organisationnel participant à l’accomplissement d’une procédure. il est chargé de réaliser les activités qui lui sont attribuées via le(s) rôle(s) qui lui sont définis dans le modèle organisationnel. Il se représente par un petit bonhomme (Figure 1.15) avec son nom (son rôle).

b) Cas d’utilisation : Un cas d’utilisation modélise un service rendu par le système en réponse à un besoin d’un acteur. Il doit produire un résultat observable pour un ou plusieurs acteurs du système [12] . Il se représente par une ellipse (Figure 1.15) contenant le nom du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.

Ecriture comptable

Comptabilité

Plan comptable national

Client Facture

Facturation

Produit

Serveur BD

BD

Utilisateur Département

administration

BD Employé

BD Finance Département formation et information

BD Client


13


Un cas d’utilisation non relié directement à un acteur, est appelé cas d’utilisation interne.

c) Relation : Elle exprime l’interaction existant entre un acteur et un cas d’utilisation. On distingue principalement deux types de relations : - Les dépendances stéréotypées représentées par une flèche avec un trait

pointillé.(les plus utilisés sont l’inclusion et l’extension). - La généralisation / spécialisation représentée par une flèche avec un trait

plein dont la pointe est un triangle fermé désignant le cas le plus général.

C.1) Relation d’inclusion : Elle indique que le cas d’utilisation source contient le comportement décrit dans le cas d’utilisation destination. Cette dépendance est symbolisée par le stéréotype « include » (figure 1.15 tirée de [05]).

C.2) Relation d’extension : Cette relation indique que le cas d’utilisation source précise le cas d’utilisation destination. Elle permet de modéliser les variantes d’un cas d’utilisation. Le stéréotype utilise est « extend ».

C.3) Relation de généralisation : Un cas A est une généralisation d’un cas B si B est un cas particulier de A [05].

La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai [05].

Figure. 1.15 - Exemple de diagramme de cas d’utilisation

Client

Condition :{si montant >100} Point d’extension : vérification_solde

Borne interactive d’une banque

<< include >>

Effectuer un virement

Extension Points : Vérification_solde (après : S’authentifier

avoir demandé le montant) << include >>

<< extend >>

Vérifier le solde << include >>

Consulter comptes

Consulter depuis internet

Retirer de

l’argent


14


3.10 Diagramme d’activités (Activity diagram)

Comme les définit [05], les diagrammes d’activités décrivent le comportement

d’une méthode, le déroulement d’un cas d’utilisation et les cheminements d’activités. Ils

permettent de mettre l’accent sur les traitements. Ils sont donc particulièrement adaptés à la

modélisation du cheminement de flots de contrôle et de flots de données.

3.10.1 Eléments de diagramme d’activités

a) Activité : Une activité désigne une suite d’actions et représentée par un

rectangle aux coins arrondis.

b) Nœuds : Un nœud est un type d’élément abstrait permettant de représenter les

étapes le long du flot d’une activité [05]. On distingue deux types de nœuds :

nœud d’exécution (d’action) et nœuds de contrôle. Les nœuds de contrôle

sont : nœud initial, nœud de fin, nœud de décision, nœud de fusion, nœud de

bifurcation et nœud d’union.

c) Transition : Les transitions sont utilisées pour connecter les activités entre

elles, elles sont représentées par des flèches en traits pleins. Elles sont

déclenchées dès que l’activité source est terminée et provoquent

automatiquement et immédiatement le début de la prochaine activité à

déclencher (l’activité cible). Contrairement aux activités, les transitions sont

franchies de manière atomique, en principe sans durée perceptible [05].

d) Couloirs d’activités : Les couloirs d’activités servent à organiser le diagramme

d’activités selon les acteurs participants à l’exécution des taches représentées.

Il est possible de citer les objets principaux manipulés d’activités en activités.

3.10.2 Décision / Fusion

Le comportement conditionnel est décrit par des décision/fusion (figure 1.16)

Une décision (ou branchement) permet de représenter des transitions

conditionnelles en utilisant des gardes (expressions booléennes).

Une fusion marque la fin d’un comportement conditionnel.

3.10.3 Débranchement et jonction (Synchronisation)

Il est possible de synchroniser les transitions à l’aide des barres de synchronisation.

Ces dernières permettent d’ouvrir (débranchement) ou de fermer (jonction) des branches

parallèles au sein d’un flot d’exécution.

Les transitions partant d’un débranchement ont lieu en même temps. Une jonction n’est franchie qu’après réalisation de toutes les transitions qui s’y rattachent.


15


3.10.4 Exemple de diagramme d’activités tiré de [05]

3.11 Diagrammes d’états-transitions (machine d’états) 3.11.1 Introduction

Le diagramme d’états-transitions UML décrit le comportement d’un objet durant

son cycle de vie. Il permet plus précisément de décrire les changements d’état d’un objet, en

réponse aux interactions avec d’autres objets ou acteurs [05].

3.11.2 Eléments de diagramme d’états-transitions

a) Etat : Un état représente une période dans la vie d’un objet pendant laquelle ce

dernier attend un évènement ou accomplit une activité.

Dans un diagramme d’états-transitions, Un état simple (élémentaire) est

représenté par un rectangle aux coins arrondis (Cf. figure 1.17)

Figure 1.17 - Exemple d’état simple

Les états qui contiennent des sous-états sont appelés composites.

Arrêt

Figure 1.16 – Un diagramme d’activité décrivant la prise en compte d’une commande


16


L’état initial est un pseudo état qui indique l’état de départ, l’état final est un pseudo état qui indique que le diagramme d’états-transitions, ou l’état enveloppant, est terminé.

b) Transition : une transition représente le passage instantané d’un état vers un

autre [06]. Elle est automatique dans l’absence d’étiquette.

c) Etiquette : une transition peut être déclenchée par un évènement, conditionné à

l’aide de ’gardes’, et /ou être associée à une activité [06].

La syntaxe d’une transition est la suivante [05]:

[ <évènement> ][ ’[’ <garde> ’]’ ] [ ’/’ <activité> ]

Dont : - évènement est un déclencheur d’un changement d’état.

- garde est une condition booléenne exprimée en langage naturel.

- activité est un comportement exécuté pendant la transition.

3.11.3 Exemple de diagramme d’états-transitions tiré de [06]

3.12 Diagramme de séquence (Sequence diagram)

3.12.1 Définition

Les diagrammes de séquence ont pour objectif la représentation des interactions

entre objets selon un point de vue temporel. L’accent est mis sur la chronologie des

échanges[12].

Notation graphique

Figure 1.19 – Représentation graphique de diagramme de séquence

Objet 1 Objet 2 Objet 3

Ligne de

vie d’un

objet Envoi de

message

Produit disponible Confirmation /livrer Annulation Annulation Facture payée

Figure 1.18 - Diagramme d’états-transitions décrivant une commande

Commande passée

Commande en cours

Commande livrée

Commande rejetée

Commande clôturée


17


L’ordre d’envoi de message est déterminé par sa position sur l’axe vertical du diagramme ; le temps s’écoule de haut en bas de cet axe. La disposition des objets sur l’axe horizontal n’a pas de conséquence pour la

sémantique du diagramme [06].

3.12.2 Barre d’activation

Il est possible de représenter de manière explicite les différentes périodes d’activité

d’un objet en utilisant une bande rectangulaire superposée à la ligne de vie de l’objet [06].

Un dédoublement de la barre indique un message récursif [06].

3.12.3 Appels synchrones et asynchrones

Un message définit une communication particulière entre des lignes de vie. Dans

un message synchrone, l’appelant attend la réponse afin de poursuivre son traitement, alors

que dans un message asynchrone, il continue son traitement sans attendre de réponse.

Le message synchrone est représenté par un trait plein orienté par une flèche

pleine, tandis que le message asynchrone est représenté par un trait plein orienté par une

flèche vide.

3.12.4 Instructions itératives et conditionnelles

Il est possible de représenter une exécution conditionnelle, itérative ou parallèle

d’un message en utilisant des cadres d’interactions et en précisant la clause alt, loop et par,

pour respectivement alternative, itération et parallèle.

3.12.5 Création et suppression de participants

La création d’un participant se fait en traçant une flèche de message allant

directement vers la boite du participant.

La suppression d’un participant est indiquée par un grand X.

Une flèche de message entrant dans X signifie qu’un participant supprime un autre. Un X mis à la fin d’une ligne de vie montre qu’un participant se détruit lui-même (autodestruction) [06].

3.12.6 Exemple de diagramme de séquence tiré de [06]


18


Figure 1.20 - Exemple de diagramme de séquence

3.13 Diagrammes de communication (Communication diagram)

3.13.1 Définition

Un diagramme de communication (diagramme de collaboration dans UML.1.x) est

souvent utilisé pour illustrer un cas d’utilisation ou pour décrire une opération. Il décrit

l’interaction en mettant l’accent sur les liaisons des données entre objets participant à

l’interaction.

3.13.2 Synchronisation des messages

Dans un diagramme de communication, nous pouvant préciser l’ordre et les

conditions d’envoi des messages, en indiquant pour chaque message :

- Les clauses qui conditionnent son envoi,

- Son rang (son numéro d’ordre par rapport aux autres messages),

- Ses arguments ou paramètres (optionnels),

- Le nom du message.

La numérotation des messages est faite par des chiffres séparés par des points. Ainsi il

est possible de représenter le niveau d’emboîtement des messages et leur précédence [06].

Loop

Calculer montant

: Commande : Ligne de

commande : Produit

[Pour chaque ligne] Avoir quantité

Avoir produit

Avoir tarification

Calculer somme


19


3.13.3 Exemple

Dans la figure 1.21 ci-dessous tirée de [06], l’envoi du message 1.2 suit

immédiatement celui du message 1.1 et ces deux messages font partie du flot des messages 1.

Figure 1.21 - Exemple de diagramme de communication

4. Conclusion Comme nous l’avons déjà dit, UML n’est qu’un langage de modélisation. En effet,

UML ne propose pas une démarche de modélisation explicitant et encadrant toutes les

étapes d’un projet, de la compréhension des besoins à la production du code de

l’application.

Bien qu’UML ne soit pas une méthode, ses auteurs selon [05], précisent néanmoins pour la

modélisation d’un système, qu’une méthode basée sur l’utilisation UML doit être itérative et

incrémentale, pilotée par les cas d’utilisation et en fin centrée sur une architecture conçue

principalement pour satisfaire les besoins exprimés dans les cas d’utilisation et prendre en

compte les évolutions futures et les contraintes de réalisation.

1 Calculer montant()

1.5.1 Avoir réduction()

1.5 Calculer

réduction 1.1 Avoir quantité 1.3 Avoir tarification()

1.2 Avoir produit

Client

Ligne de commande

Produit

Commande

CChhaappiittrree 22

LLaa TTeecchhnnoollooggiieess ddeess WWoorrkkFFlloowwss

Chapitre II - La Technologie des Workfolw

20


1. Historique

D’après [09], l'industrie de l'imagerie électronique et de la gestion de la production

assistée par ordinateur a été la première à réclamer une technologie qui permette

l’automatisation des procédures de travail, jusqu’alors réalisées à la main.

À partir de l’année 1975 et jusqu’à 1985, la nouvelle technologie dite de WorkFlow a connu

un essor important par la mise en place d'un système capable d’automatiser au mieux les

flux de travail. Ainsi des systèmes de WorkFlow statique ont vu le jour : Officetalk-P,

Backtalk, Poise, Xerox InConcert, etc.

De nombreuses entreprises ayant développé des produits similaires n’ont pu passer le cap

du millénaire, car les outils réalisés étaient grevés par un prix élevé et une complexité

importante. L’échec du WorkFlow statique est principalement dû au fait qu’il était très

difficile d’intégrer et de modifier les procédures de travail dans les systèmes WorkFlow. Les

traitements et les données faisaient partie intégrante du système et rendaient la tâche ardue.

Le regain d’intérêt pour le génie logiciel au début des années 1990 a permis de relancer les

recherches concernant les systèmes WorkFlow afin de mettre en place des systèmes plus

simples à utiliser. Il s’en est suivi une véritable explosion quant aux systèmes élaborés, dont

Oval, Apricot, MelMac, WAMO, FreeFlow, etc. Ces systèmes, connus sous le nom de

WorkFlow générique, proposaient une nouvelle approche du WorkFlow. L’idée était de

séparer traitement et données relatives aux procédures de travail et d'offrir de la sorte une

plus grande facilité quant à la création, la modification ou la suppression des procédures de

travail.

2. Introduction

La technologie des WorkFlows (WFs) s’impose actuellement dans le domaine de la

réalisation et la gestion des activités des organisations. Lorsque l’exécution des opérations

d’un WF se fait de manière automatique, des composantes spécialisées, appelées Business

Objects (BOs), sont introduites pour prendre en charge ces opérations et assurer leurs

réalisations.

Le WorkFlow Management Coalition (WFMC) définit un WF comme une

automatisation totale ou partielle d’un processus métier, durant lequel des documents, des

informations ou des tâches, sont transférés d’un participant à un autre pour des besoins et

fins spécifiques [16]. Ce transfert se base sur un ensemble de règles préétablies [17].

L’interaction d’un WF avec ses divers participants se fait par des WorkLists (WL). Le WFMC

définit un WL comme étant une liste d’activités à exécuter par un participant spécifique (ou

parfois par un groupe de participants).

L’Object Management Group (OMG) définit un BO comme étant une

représentation d’un élément actif dans le domaine des affaires. Un BO est décrit par ses

http://fr.wikipedia.org/w/index.php?title=Production_assist%C3%A9e_par_ordinateur&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=Production_assist%C3%A9e_par_ordinateur&action=edit&redlink=1

http://fr.wikipedia.org/wiki/1975

http://fr.wikipedia.org/wiki/1985

http://fr.wikipedia.org/wiki/G%C3%A9nie_logiciel


21


attributs d’affaires, son comportement, ses relations avec l’environnement intérieur et

extérieur et ses contraintes.

L’approche WF est l’une des nouvelles technologies de modélisation des systèmes

mises à la dispositions des concepteurs. Cette approche a pour objectif la coordination et le

suivi des processus métiers dans une organisation et par conséquent, d’identifier qui est

responsable de quoi[18].

3. Concepts clés

3.1 Processus métier

Un processus métier est un ensemble de procédures et d'activités plus au moins

liées qui réalisent collectivement un objectif métier [17 et 18], en général au sein d'une

structure organisationnelle définissant des rôles et des relations fonctionnelles. Un processus

métier peut être entièrement inclus dans une organisation simple ou peut s'étendre sur

plusieurs organisations.

Un processus métier peut combiner des activités automatiques et des activités manuelles

(WfMC).

3.2 Modèle de processus

C’est la représentation d'un processus métier dans une forme qui supporte des

manipulations automatiques comme la modélisation ou l'exécution par un système de

gestion de workflow. Une telle définition consiste en un réseau d'activités, en des critères

pour indiquer le démarrage et la terminaison du processus, ainsi que des informations sur

les activités comme les participants, les applications et les données permettant la mise en

œuvre des processus.

3.3 Tâche

Un processus métier est constitué d’un ensemble de tâches liées par des

transitions[10]. Une tâche peut être manuelle ou automatique. Pour s'exécuter, elle utilise

des ressources humaines et/ou machines. Quand une ressource est requise, la réalisation de

l'activité est attribuée à un participant.

a. Tâche automatique : une activité qui s'exécute sur un ordinateur et qui est

entièrement contrôlée par le système de gestion de processus

b. Tâche manuelle : une activité non automatisée qui reste en dehors du contrôle du

système de gestion de processus.

Ces activités peuvent cependant être inclues dans la définition d'un processus à des

fins de modélisation.


22


3.4 Nœud : Action interne à l'application mais n'ayant pas d'interaction ni avec

l'utilisateur ni avec un élément externe.

3.5 Types de Nœuds

Un (unique) startNode : étape à l'origine de la création de l’instance

du workflow

TaskNode : étape en attente d'une interaction avec l'utilisateur

State : étape en attente d'une action extérieure (webservices, attente de

réponse d'un composant externe à l'application)

Un ou plusieurs endNode : Archivage de l'instance du workflow et libération

des ressources

Les nœuds task et state ont un état wait

Fork : Séparation du workflow en N branches devant se réunir via un nœud

de type Join

DecisionNode : Condition sur une variable de l'instance de workflow

(utilisation d'un langage simple ou délégation à une classe java)

3.6 Transitions : Elles sont utilisées pour relier tout ces nœuds, représentant le

changement d'un nœud à un autre au sein de l'instance.

Une transition est un point dans l'exécution d'une instance de processus où une

activité se termine et une autre démarre.

Une transition peut être inconditionnelle (la terminaison de l'activité précédente

déclenche le démarrage de l'activité (ou des activités) suivante(s)) ou

conditionnelle (ce déclenchement est gardé par une condition logique).

3.7 Evènement : Chaque nœud possède trois évènements déclencheurs.

onNodeEnter : déclenchée à l'entrée du nœud

onNodeLeave : déclenchée à la sortie du nœud courant

onTransition : déclenchée lors de la transition du nœud suivant un événement

n'est pas lié qu’à une action, mais peut déclencher plusieurs

actions.

Un nœud n'a pas à connaître l'existence des autres nœuds, il manipule un

ensemble de données dans un contexte d'exécution.

4. Workflow et processus métier

Pour [15], un Workflow est une représentation d’un processus métier dans un

format interprétable et compréhensible par la machine.


23


Pour illustrer la relation entre les termes ‘‘Workflow’’ et ‘‘processus métier’’, nous

pouvons dire que le premier s’intéresse à l’organisation d’un travail (métier ou autre)

représenté par la coordination automatisée des tâches. Il correspond à la représentation

schématique ou à la modélisation d’un processus métier, alors que le deuxième (processus

métier) représente le métier proprement dit de l’entreprise en termes d’activités, de rôles et

de règles métiers.

Donc, et selon [07], un processus Workflow est explicitement défini comme étant

un ensemble d’étapes. Chaque étape peut-être une activité, une tâche (activité atomique) ou

peut faire référence à un sous-processus. Les activités sont exécutées via les conditions de

transition. Une activité peut être manuelle ou automatisée. Elle est réalisée par un rôle qui

décrit les compétences et le savoir faire qu’un acteur (utilisateur du Workflow ou

participant) doit avoir au sein d’une organisation. L'exécution de ces activités demande

l’invocation de ressources (applications externes, outils informatiques, etc.), la manipulation

de données, ainsi que l’accès aux artefacts tels que documents, formulaires électroniques ou

feuilles de styles.

5. Aperçu sur les WFs

D’après [17], deux étapes sont nécessaires pour la mise en place d’un WF, à savoir:

Création des processus et gestion des processus. Dans la première étape, une description des

processus est élaborée en termes de composants et de moyens de support. Tant dis que La

gestion assure le suivi et le contrôle des instances de processus actifs dans le système.

Pour que les WFs puissent être utilisés de manière efficace, il est important qu’ils intègrent

les capacités suivantes [21]: supporter les changements des modèles de processus; permettre

la surveillance de l’exécution des processus; permettre la distribution des processus à travers

des domaines d’affaires; et supporter l’assignation des ressources et étapes des processus.

Selon [16], l’utilisation des WFs peut intervenir à plusieurs niveaux dans une organisation.

Ainsi, un WF destiné-image permettrait d’automatiser le flot de documents papiers qui

circulent dans l’organisation. Pour cela, les documents sont transférés en images digitales.

Un WF destiné-formulaire permettrait de router de manière intelligente les formulaires dans

l’organisation. Ces formulaires, différents des images digitales, contiennent des champs

d’édition dont les valeurs sont exploitées dans les opérations de routage. De plus, ce type de

WF peut notifier ou rappeler ses usagers de certaines actions spécifiques à prendre en

compte. Enfin, un WF destiné-coordination permettrait de faciliter l’accomplissement des

opérations nécessitant l’intervention de plusieurs personnes. Pour cela, un cadre de

collaboration basé sur les engagements pris par ces personnes est nécessaire.


24


5.1 Modèle de Référence

Le standard prédominant dans la structuration d’un WF est le modèle de référence

du WFMC. Ce modèle présente une perspective orientée-WFs distribués [19]. La Figure 2.1

tirée de [16] illustre un environnement où plusieurs WFs cohabitent avec d’autres éléments :

services réseau et clients des WFs (clients pouvant être déconnectés du réseau de

communication).

Figure 2.1 - Environnement de WFs distribués

Selon [16], les WFs distribués sont des applications basées sur des processus qui

s’exécutent sur une infrastructure réseau à grande échelle (tel que l’Internet) et hétérogène.

Pour assurer le fonctionnement d’une telle infrastructure, certaines exigences doivent être

satisfaites [19] : hétérogénéité des composants faisant partie du WF, participation évolutive

et flexible au WF, support «Plug and Play» aux applications et BOs, discontinuité des

opérations et enfin, décomposition récursive et dynamique des WFs.

La figure 2.2 présente les composants de base du modèle de référence d’un WF ainsi que les

interfaces entre ces composants [19].

Figure 2.2 - Modèle de référence d'un WF

Service réseau

(imprimante)

Serveur WF

Serveur WF Client WF (mobile)

Réseau WAN

(Internet)


25


Le modèle de référence d’un WF définit cinq composants, selon [16]:

1. Outils de construction/définition des processus : outils utilisés pour spécifier dans une

notation abstraite la logique de fonctionnement des processus.

2. Serveur WF : centre nerveux du système WF, en étant responsable de la gestion des

processus et des WLs, des services de répertoire des participants et des invocations

d’applications externes.

3. Application client : application graphique destinée à la gestion des WLs d’un usager sur le

serveur WF.

4. Applications externes : ressources utilisées par le serveur WF pour compléter les activités

des processus.

5. Outils d’administration et de surveillance : outils utilisés pour suivre l’exécution des

processus.

Le modèle de référence d’un WF dispose de cinq interfaces entre ses composants :

Interface 1 - serveur-concepteur: définit un format commun pour l’échange des

spécifications des processus statiques entre l’outil de définition des processus et le

serveur WF.

Interface 2 - client-serveur : supporte les interactions entre l’application client du WF et le

serveur WF. Ces interactions incluent les WLs, la demande d’informations et de contrôle

des processus WFs et de leurs activités et enfin, les fonctions administratives. Cette

interface permet également à une application client d’un vendeur d’interagir avec le

serveur WF d’un autre vendeur (interopérabilité WF/Application Usager).

Interface 3 - invocation d’applications : n’est pas disponible pour le moment mais elle

devrait décrire comment des ressources externes sont invoquées par le serveur WF.

Interface 4 - serveur-serveur : (interopérabilité WF/WF) décrit les interactions entre les

serveurs WFs. Ces interactions incluent l’initiation, la demande d’informations et de

contrôle des processus WFs et de leurs activités et les fonctions administratives.

Interface 5 - surveillant-serveur : définit les fonctions d’administration et de surveillance

du serveur WF.

5.2 Système de Gestion des WFs

Le Système de Gestion d’un WF (SGWF) joue le même rôle qu’ un système de

gestion de base de données, il représente l’infrastructure de support d’un WF et de ses

processus métiers.

Selon [16], au moment de la conception d’un SGWF, le défit est de concevoir un

environnement dans lequel diverses technologies, allant des bases de données au traitement

distribué, doivent être intégrées de manière simple et flexible. En fait, chaque technologie

impliquée dans le fonctionnement d’un WF a ses caractéristiques fonctionnelles et


26


structurelles. Par conséquent, les questions d’interopérabilités de systèmes surgissent de

nouveau.

Un SGWF supporte les fonctionnalités des WFs par le biais de deux modules : modélisation et

exécution. Le module de support à la modélisation fournit les primitives nécessaires à la

définition des composants suivants : activités, entités responsables de l’exécution des

activités, données et flux de contrôle entre les activités et enfin, les conditions de début (pré)

et de fin (pro) d’exécution des activités. L’imbrication de WFs fait également partie de ce

module [16].

Comme [16] l’a définie, l’entité responsable de l’accomplissement d’une activité peut être un

programme ou une personne. Lorsqu’il s’agit d’une personne, cette information est définie

dans une Base de Données (BD) orientée-personnes («staff»). Les définitions d’un WF sont

également stockées dans une BD orientée-activités. Il est à noter que les deux BDs sont

généralement gérées par un SGBD sous-jacent au WF en question et peuvent être mises à

jour à tout moment. Les activités d’un processus de WF présentent plusieurs caractéristiques

énumérées comme suit :

Dépendance entre activités : séquentiel, parallèle, alternatif ou conditionnel.

Compensation des résultats des activités.

Comportement «roll-back» pour des activités.

5.3 WFs et BOs

Selon [16], un BO est une entité capable d’exécuter des opérations nécessaires à la

satisfaction des besoins de ses utilisateurs. Parmi ceux-ci, les WFs qui font souvent appel aux

BOs afin de supporter leurs processus métiers.

Dans l’objectif de structurer un BO de manière flexible et de lui assigner des responsabilités

bien spécifiques, une architecture à cinq niveaux est proposée dans [22]. Ces niveaux sont :

présentation, Processus métiers, entités d’affaires, accès aux données et stockage des données.

La couche présentation assure l’interaction entre les usagers et les entités d’affaires. Les

interactions se résument à un échange d’informations. Une entité d’affaires caractérise les

services qui sont communs à différentes opérations. Ces services sont représentés par des

règles d’affaires.

À titre d’exemple tiré de [16], une application de gestion de comptes bancaires intègre le

service «déduire un montant d’une balance». Un processus métier est une séquence de

traitement qui requiert les services de plusieurs entités d’affaires. La responsabilité d’une

entité d’affaires est de fournir les services reliés au domaine d’application. Cette entité ne

doit pas être concernée par le stockage et la récupération des caractéristiques de ce domaine.

Par conséquent, cette fonctionnalité est associée à la couche de stockage des données. La

couche de stockage des données intègre les fonctionnalités d’accès à une base de données

spécifique. Les entités d’affaires interagissent avec la couche de stockage de données grâce à

la couche d’accès aux données. La couche d’accès fournit les services aux entités d’affaires au


27


niveau de la création de nouvelles entités, la récupération d’une entité d’affaires déjà

existante dans la base de données et la mise à jour et récupération des entités. Finalement, la

couche processus métier demande les services de la couche d’accès aux données pour

débuter ou terminer une transaction [16].

6. Application d’UML sur les WFs

Comme nous avons vu, UML est le fruit de l’effort de standardisation de divers

formalismes de méthodes de conception orientés-objet disponibles sur le marché. Dans

l’objectif de créer un environnement homogène entre les usagers, consultants et

développeurs, UML est suggéré dans la description des systèmes.

Un système à modéliser est constitué d’un ensemble de processus et de structures statiques. Le

modèle d’un processus est représenté par une séquence d’activités, exécutées pour atteindre

un but défini. Par conséquent, les diagrammes de séquence et d'activités d’UML sont

appropriées pour une spécification des processus métiers de manière conviviale aux usagers.

Pour les structures statiques d’un système, les diagrammes de structures statiques d’UML

peuvent être utilisées sans la nécessité d’introduire des détails d’implantation [16].

La figure 2.3 tirée de [16] montre des exemples de représentation de processus métier, des

objets d’affaires et de rôles dans des équipes dans UML [23]. Les objets d’affaires sont

représentés par des objets et classes d’UML. Les classes représentent des objets d’affaires

sans identité, tel que Facture. Les objets représentent des objets d’affaires qui ont une

identité, tels que Facture numéro 2/98. Les processus métiers sont représentés par des Use-

Cases et des instances de Use-Cases d’UML.

Selon [16], les WFs sont des processus métiers automatisés (pouvant aussi être partiellement

automatisés). Ils sont représentés comme des Use-Cases ou des instances de Use-Cases avec

le stéréotype «WorkFlow». Les rôles dans des équipes sont représentés par des objets et

classes d’UML. Les classes représentent des types de rôles, alors que les objets représentent

des personnes associées à des rôles spécifiques. Tous les symboles peuvent être ornés par un

stéréotype approprié, comme «BO», «Processus métier » et «Rôle dans Équipe».


28


La figure 2.4 tirée de [16] est un diagramme de structure statique d’UML. Il montre une

structure d’équipe[23]. Les rôles dans l’équipe sont représentés comme des instances

d’objets, ce qui permet de spécifier le nombre de personnes dans chaque rôle. Dans

l’exemple de la figure 2.5, l’équipe de satisfaction des besoins des clients comporte trois

développeurs, deux testeurs et un gestionnaire de produits. Le regroupement des rôles est

représenté par le symbole d’un «package».

La figure 2.5 tirée de [16] montre un diagramme de séquence d’UML, qui est utilisé pour

représenter une instance d’un processus métier. L’acteur client passe une commande à un

employé non spécifié du département des ventes. Cet employé procède à la validation de la

commande. Si celle-ci est valide, cet employé invoque une instance du processus métier,

appelé «la compagnie délivre l’article». Ce type de diagramme n’est pas explicitement

mentionné dans le guide de Notation d’UML. Par contre, il reste conforme au méta-modèle

d’UML. Les symboles au-dessus des lignes verticales représentent des rôles de classification.

Ces rôles sont acteur, objet et UseCase.

Figure 2.3 - Représentation d'un BO, d'un processus métier et d'un rôle dans une équipe dans UML

Figure 2.4 - Structure d'équipe par un diagramme de structure statique d’UML


29


Figure 2.5 - Instance d'un processus métier par un diagramme de séquence d’UML

Dans la figure suivante tirée de [16] , le diagramme de Use-Cases d’UML représente les

relations statiques entre les processus métiers. Un processus métier décrit les collaborations

qui existent entre l’organisation et les clients.

La figure 2.7 tirée de [16] représente le diagramme d’activités d’UML, qui est utilisé dans la

définition d’un package de Use-Cases destiné à la gestion des factures.

Figure 2.7 - Chronologie des processus métiers par un diagramme d'activités UML

Figure 2.6- Relations statiques entre processus métiers par un diagramme de Use-Cases d’UML


30


7. Langages de spécification de workflow

Beaucoup de langages de spécification de processus métiers sont apparus ces

dernières années. Chacun adopte sa terminologie particulière et définit ses concepts

spécifiques en fonction des objectifs visés par le méta-modèle2 de Workflow, du domaine

d’intérêt ou du choix de représentation. Ces spécifications sont techniques et sont basées sur

le langage XML.

Parmi ceux-ci, nous pouvons citer :

– WSFL : le langage Web Services Flow Language développé par IBM

– BPML : le langage Business Process Modeling Language développé par l’organisation

BPMI.org (Business Process Management Initiative).

– XLANG : le langage XLANG [13] a été développé par Microsoft en 2001, pour les besoins

de sa plateforme de gestion de processus BizTalk. Ce langage permet de représenter les

éléments clés, d’un point de vue algorithmique, des processus métier et se classe ainsi

dans les langages de description comportementale.

– BPEL4WS : le langage BPEL4WS [13] est développé en 2003, par un regroupement

d’industriels, parmi ceux-ci, on retrouve IBM et Microsoft. Ce langage est une fusion des

langages, dit de première génération : XLANG et WSFL. Il reprend donc les avantages de

ces deux langages en tirant parti de l’apprentissage lié à leur mises en place. Il se focalise

sur la représentation du processus métier en se rapprochant des structures

algorithmiques.

Dans le chapitre suivant, nous allons présenter le langage BPEL, car il représente l’évolution,

dans le temps, des premiers langages de ce type, et plus particulièrement la fusion de WSFL

et XLANG. De plus il s’avère être le langage le plus utilisé par les industriels, devenant ainsi

un standard de fait, en plus d’être en phase de devenir un standard Oasis.

8. Conclusion

Dans ce chapitre, nous avons présenté de manière générale la technologie des WFs

et son importance dans la modélisation des processus métiers. Selon [16], un léger consensus

existe sur la définition d’un WF et de ses caractéristiques. Sous le terme de WF, les personnes

peuvent faire référence à un processus métier, à la spécification d’un processus, à un logiciel

qui implante et automatise un processus ou à un logiciel qui supporte simplement la

coordination et la collaboration de personnes implantant le même processus.

2 Selon MOF(Meta Object Facility), un méta-modèle définit la structure que doit avoir tout modèle conforme à ce méta-modèle. Tout modèle doit

respecter la structure définie par son méta-modèle.

CChhaappiittrree 33

LLee LLaannggaaggee BBPPEELL

Chapitre III - Langage d’exécution des processus métiers (BPEL)

31


1. Introduction

Selon [13], après une période très riche en création de nouveaux langages de

description comportementale, les acteurs majeurs tel que Sun, IBM, ou encore Microsoft se

sont associés pour écrire un nouveau langage, héritant des avantages des précédents. Ainsi,

la fusion des langages XLANG et WSFL a donné naissance à BPEL4WS connu sous le nom

de BPEL (Business Process Execution Language).

Avec BPEL nous pouvons définir des processus simples ou complexes. BPEL est similaire,

dans une certaine mesure, à des langages de programmation traditionnels. Il propose des

éléments de construction tels que boucles, branchements, variables, assignations, etc. ce qui

lui permet de définir les processus métiers de façon algorithmique. BPEL est un langage

spécialisé qui se concentre sur la définition et le développement de ces processus. Par

conséquent il offre d’un côté des éléments qui rendent cette définition relativement simple et

d’un autre côté, il est moins complexe que les langages de programmation traditionnels[14].

2. Processus métier et fichier BPEL

Nous avons vu qu’un processus métier décrit des interactions entre des agents

(personnes, services, organisations) et des systèmes d’information (logiciels, sous-systèmes).

Les différentes entités qui interagissent dans un processus donné sont les participants de ce

processus. Le processus métier est déterminé par un objectif précis : produire une facture

d’achat de fournitures, éditer un catalogue électronique, etc. Il est à la fois collaboratif et

transactionnel, et peut être composé d’activités automatisées aussi bien que manuelles. BPEL

utilise un vocabulaire XML permettant de spécifier et de décrire des processus métier [04].

Le fichier BPEL définit le processus, ou l’enchaînement et la logique des actions qui

seront exécutées par le moteur d’orchestration. La structure du fichier BPEL est la même que

celle du processus. Ce fichier est véritablement le code source de l’application que constitue

le processus, le moteur d’orchestration agissant comme une machine virtuelle capable

d’exécuter le code BPEL.

3. Concepts fondamentaux et syntaxe de BPEL

La description BPEL d’un processus métier est composée de quatre parties [13] :

– Une première partie permet de déclarer des variables, utilisant les types importés

de descriptions WSDL associées à la description BPEL. Ces variables seront

utilisées dans la partie description comportementale du processus métier pour

maintenir un état au niveau du service, et ainsi assurer des liaisons de données

entre deux opérations.

– Une deuxième partie permet la déclaration des partnerlinks : ces partnerlinks

définissent une liaison entre les ensembles d’opérations des services invoqués par


32


le service web BPEL et un nom de liaison bien précis du service BPEL. Ces liaisons

sont appelées partner et permettent ainsi d’identifier facilement les différents

services web utilisés.

– Une troisième partie permet la déclaration des fauthandlers : ce sont des processus à

déclencher en cas d’exception déclenchée pendant l’exécution du processus et non

interceptée avant.

– Enfin, la quatrième partie décrit le comportement du processus métier lui-même en

utilisant différents opérateurs dit de programmation.

3.1 Syntaxe des éléments de base tirée de [13]

L’élément vide : c’est l’élément de base le plus simple : il permet d’insérer une

opération vide dans un processus. Ceci signifie que le processus ne fait rien, mais

ne se termine pas complètement l’instruction suivante sera exécutée. Ce processus

est très utilisé dans le cadre de la synchronisation des activités parallèles : il

supporte la gestion des links.

<empty standard-attributes> standard-elements

</empty>

L’élément de terminaison : cet élément force le processus métier à se terminer

immédiatement.

<terminate standard-attributes> standard-elements

</terminate>

L’élément d’affectation : cet élément permet d’affecter un nouveau contenu à une

variable.

< from variable="ncname" part="ncname"? query="queryString"?/> <to variable="ncname" part="ncname"? query="queryString"?/>

L’élément déclenchant une exception : cet élément permet de lever une exception

qui pourra être interceptée à différents niveaux.

<throw faultName="qname" faultVariable="ncname"? standard-attributes> standard-elements

</throw>

L’élément de délai : Il permet d’attendre un temps donné (for) ou jusqu’à une

certaine heure (until).

<wait (for="duration-expr" | until="deadline-expr") standard-attributes> standard-elements

</wait>


33


3.2 Syntaxe des éléments basés sur les messages

L’élément de réception : cet élément permet à un processus métier de se mettre en

attente (synchrone) d’un message : typiquement, la première opération d’un

serveur consiste à l’attente d’une demande de traitement envoyée par un client.

Cet élément est lié aux informations partnerLink et portType de la description WSDL

pour l’opération indiquée par l’attribut XML opération. Le contenu reçu peut être

affecté à la variable indiquée par l’attribut variable.

<receive partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"? createInstance="yes|no"? standard-attributes>

standard-elements </receive>

L’élément de réponse : Il permet à un processus métier de répondre à un message

qu’il aurait reçu par un receive. La combinaison d’un receive et d’un reply permet

de réaliser une opération de question/réponse tel que le définit WSDL, en mode

synchrone. Comme l’élément de réception, il est lié aux informations partnerLink

et portType de la description WSDL pour l’opération indiquée par l’attribut XML

opération. Le contenu envoyé peut provenir de la variable indiquée par l’attribut

variable.

<receive partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"? createInstance="yes|no"? standard-attributes>

standard-elements </receive> <reply partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?

faultName="qname"? standard-attributes> standard-elements

</reply>

3.3 Syntaxe des éléments de contrôles structurés

Comme dans le langage XLANG, les contrôles structurés sont similaires à ceux

que l’on connaît des langages de programmation structurée. Leur corps est constitué

d’autres éléments de contrôle séquentiel ou des éléments de base ou d’échanges de

messages vu précédemment.

L’élément de séquence : c’est l’élément permet d’exécuter de façon séquentielle

(dans l’ordre de lecture de la séquence) une ou plusieurs instructions BPEL (mot

clé activity). La séquence se termine elle-même lorsque le dernier processus la

constituant se termine.

<sequence standard-attributes> standard-elements activity+

</sequence>


34


L’élément de choix: cet élément permet, comme en programmation structurée,

d’effectuer un branchement conditionnel : suivant l’évaluation d’une condition ou

d’un critère (attribut XML condition), le processus de la première branche (nœud

XML case) répondant à ce critère sera exécuté. Dans le cas où aucune condition ne

serait vraie, il est possible de définir une branche par défaut (nœud XML otherwise)

qui sera alors exécutée.

<switch standard-attributes> standard-elements <case condition="bool-expr">+

activity </case> <otherwise>?

activity </otherwise>

</switch>

L’élément de boucle : Il permet de réaliser une boucle while traditionnelle : la

boucle (composée des instructions représentées par le mot clé activity) est exécutée

tant que la condition (attribut XML condition) est évaluée à vrai.

<while condition="bool-expr" standard-attributes> standard-elements activity

</while>

3.4 Syntaxe des éléments des contrôles évolués

En plus des éléments de base et structurés vus précédemment, BPEL, comme le

langage XLANG, présente des outils allant du parallélisme d’actions à l’exécution

gardée (gestion des exceptions, évènements et aspect temporel).

L’élément de parallélisme : c’est l’élément permet d’exécuter en parallèle plusieurs

processus (mot clé activity). Ces différents processus peuvent être indépendants, et

alors, le processus englobant l’exécution parallèle se termine lorsque tous ses

processus sont terminés. Ou alors, les processus peuvent être dépendants les uns

des autres, et l’utilisation de liens (links) permet de synchroniser où d’ajouter des

dépendances temporelles entre les différents processus. Ainsi, l’ensemble des liens

est annoncé dans la déclaration du processus parallèle et ensuite, chaque élément

des sous-processus peut utiliser les sources et les cibles (target) : une cible n’est

franchissable que si une source ayant le même nom a déjà été franchie (ou plus

exactement l’exécution du processus déclarant cette source est terminée).


35


L’élément Pick : Il regroupe différents processus dont l’exécution est gardée par :

- des évènements (nœud XML onMessage) : à l’arrivée d’un message, le processus

de la branche associée à ce message sera exécuté.

- un temps d’attente (nœud XML onAlarm) : au bout d’un temps d’attente donné,

le processus de la branche est exécuté.

Seule une branche est exécuté : le processus de la première branche dont la

garde est évaluée à vrai s’exécute.

Cet élément permet de gérer des évènements extérieurs au déroulement

normal de l’exécution. Par contre, l’espace temps possible, permettant l’arrivée de

ces évènements, est limitée par une garde temporelle. De plus, cette instruction a

une portée limitée entre deux autres instructions.

<pick createInstance="yes|no"? standard-attributes>

standard-elements <onMessage partnerLink="ncname" portType="qname" operation="ncname"

variable="ncname"?>+ <correlations>?

<correlation set="ncname" initiate="yes|no"?>+ </correlations> activity

</onMessage> <onAlarm (for="duration-expr" | until="deadline-expr")>*

activity </onAlarm>

</pick

L’élément scope : c’est un élément très similaire à l’élément pick, et appelé context

dans le langage XLANG. Il permet d’exécuter un processus de façon gardée. C’est-

à-dire qu’il permet de parer à l’éventualité :

– d’une exécution du processus principal trop longue (nœud XML

eventHandlers) : une alarme est alors déclenchée et un processus associé à cette

alarme est exécuté.

– d’une exécution du processus principal déclenchant une exception (nœud

XML faultHandlers) : un traitement associé à cette exception est alors exécuté.

<flow standard-attributes> standard-elements <links>?

<link name="ncname">+ </links> activity+

</flow>


36


– de la survenue non prévue d’un message dans l’exécution du processus

principal (évènement extérieur) (nœud XML eventHandlers) : encore dans ce

cas, un processus associé à ce message est exécuté.

Cet élément représente les instructions traditionnelles trigger ou les blocs

try/catch. Contrairement à l’élément pick, sa portée n’est pas limitée entre deux

instructions, mais sur un bloc d’instructions (mot clé activity. Il définit également

un bloc compensationHandler permettant d’annuler les instructions réellement

effectuées en cas de mécanisme d’annulation de transactions.

<scope variableAccessSerializable="yes|no" standard-attributes> standard-elements <variables>?

... </variables>

<faultHandlers>? ...

</faultHandlers> <compensationHandler>?

... </compensationHandler> <eventHandlers>?

... </eventHandlers> activity

</scope

CChhaappiittrree 44

CCoonnttrriibbuuttiioonn àà llaa MMooddéélliissaattiioonn

dd’’uunn pprroocceessssuuss mmééttiieerr ddee ll’’aaccttiivviittéé

bbuuddggééttaaiirree ppaarr UUMMLL--WWoorrkkFFllooww

Chapitre IV - Modélisation d’un processus métier par UML-Workflow

37


Dans ce présent chapitre nous allons proposer une démarche progressive fondée

sur l’utilisation d’UML-Workflow pour la modélisation d’un Système relatif à l’élaboration

des prévisions budgétaires du plan annuel (PA) et plan à moyen terme (PMT).

Après avoir étudié le cahier de charge présenté par l’équipe AVAL en exploitant

toute information considérée utile nous avons pu déterminer les acteurs impliqués dans

l’élaboration des prévisions budgétaires, l’ensemble de données pertinentes ainsi que les

différentes actions nécessaires pour l’exécution de ce processus important, en tenant compte

les objectifs fixés par les responsables.

Une bref définition de la modélisation est donnée en premier point, suivie d’une

description des différents aspects à modéliser en deuxième point, puis nous allons présenter

le système à modéliser en troisième point, en suite vient la modélisation statique par UML

et en fin ; nous aborderons la modélisation par workflow des diagrammes des processus de

l’élaborations des différentes prévisions budgétaires et de validations. Ces diagrammes sont

basés sur le principes des diagrammes d’activités UML.

1. Définition

La modélisation est une activité qui précède toute décision ou formulation, elle

permet de représenter la description du système réel. Cette description comporte un certain

nombre d’aspects à modéliser que nous allons présenter ci-dessous.

2. Aspects à modéliser

2.1. Aspect fonctionnel

L’aspect fonctionnel concerne l’identification des activités des processus que l’on

souhaite modéliser. Il est important de comprendre qu’il ne s’agit pas uniquement

d’identifier les fonctions des différents départements d’une organisation mais bien de

distinguer les activités composant un processus. La modélisation fonctionnelle doit

également permettre d’établir la hiérarchie des activités, c’est-à-dire d’exprimer de possibles

décompositions en termes de sous-processus. Enfin, le modèle fonctionnel doit aussi

représenter le flux de données associées aux activités et les interdépendances de données

entre les activités.

2.2. Aspect comportemental

L’aspect comportemental est un aspect primordial du Workflow puisqu’il

correspond à la dynamique du processus [07]. Le comportement s’exprime par la


38


modélisation d’un contrôle de flux entre les activités. Ce dernier permet d’indiquer la

chronologie de l’exécution des activités, leur flux (séquentiel ou parallèle), les points de

synchronisation entre activités ou au contraire, les points de disjonction.

De plus, le modèle comportemental doit représenter les évènements qui permettent de

déclencher les activités. L’aspect comportemental est également appelé aspect de

coordination.

2.3. Aspect informationnel (données)

Cet aspect concerne l’ensemble des informations et des données qui sont associées

aux activités. Le modèle informationnel, souvent négligé lors de l’implémentation d’un

Workflow, décrit en détail les relations qui existent entre les données, leur type et leur

structure [08].

2.4. Aspect organisationnel

Comme son nom l’indique, la partie organisationnelle concerne la description de

l’organisation des acteurs de l’entreprise. Le modèle organisationnel peut refléter fidèlement

l’organigramme de l’entreprise, c’est-à-dire la décomposition hiérarchique de celle-ci en

départements et services ou bien décrire des unités organisationnelles dans lesquelles on

identifie des acteurs. Selon la méthode choisie, la description est plus ou moins détaillée et

permet d’établir des liens hiérarchiques entre les acteurs ainsi que des relations entre unités

organisationnelles ou départements. Toutefois, quelle que soit la méthode retenue, la

description des rôles associés aux différentes activités reste invariante. Les rôles créent

l’interface entre le modèle organisationnel et les modèles représentant les activités.

3. Présentation du système à modéliser

SONATRACH (Société Nationale de Transport et de Commercialisation des

Hydrocarbures) est une société nationale pétrolière créée en date du 31 décembre 1963 par le

décret n° 63-491, elle se trouve actuellement en position de jouer un rôle de premier plan et

de consolider sa position internationale grâce à :

L’importance de ses réserves énergiques dont 70% est en gaz naturel.

Ses capacités de production des hydrocarbures liquides et gazeuses.

Ses capacités technologiques et managériales.

SONATRACH est classée parmi les douze grandes compagnies pétrolières

mondiales. Ses principales actions sont :

La recherche et l’exploration

Le développement et l’exploitation des gisements


39


Le transport des hydrocarbures

La liquéfaction du gaz naturel et la transformation des hydrocarbures.

Les opérations, l’association et le partenariat en amont et en aval de ses métiers.

SONATRACH est la première entreprise du continent africain. Elle est classée 11ème

parmi les compagnies pétrolières mondiales, 2ème de GNL et de GPL et 3ème exportateur du

gaz naturel.

3.1. Les objectifs stratégiques de la société SONATRACH

Les objectifs stratégiques de la société SONATRACH reposent sur :

La maîtrise continue de ses métiers de base

Le renforcement de ses capacités technologiques et managériales

Le développement international et le partenariat

La diversification de ses activités

3.2. Les différentes structures de SONATRACH

La SONATRACH est structurée en plusieurs structures appelées activités qui sont:

activité amont, activité aval, activité de transport et activité commerciale (Figure 4.1).

Figure 4.1 – Organigramme des différentes structures de SONATRACH

3.2.1. L’activité AVAL

L’Activité AVAL a été créée pour la prise en charge de l’élaboration et la mise en

œuvre des politiques et stratégies de développement et d’exploitation de l’aval pétrolier et

gazier, et de leur mise en œuvre une fois approuvées.

L’activité Aval qui englobe les branches de raffinage pétrochimique (RPS) et de liquéfaction

et transformation des hydrocarbures a pour missions essentielles :

Directions Régionales

PDG

AMONT AVAL TRC COM

DGA


40


D’exploiter les installations existantes de liquéfaction de gaz naturel et de séparation

des GPL.

De mettre en œuvre, en partenariat le plan de développement de l’aval pétrolier et

gazier

De suivre la gestion du portefeuille des filiales et participation confiée au holding

RCH.

Actuellement l’activité aval de SONATRACH est constitué de :

1. Quatre complexes de liquéfaction de gaz naturel GNL

2. Deux complexes de séparation des GPL

3. Trois filiales de production industrielle NAFTEC (raffinage), ENIP (Pétrochimie) et

HELIOS (Hélium)

4. Trois filiales de services : SOMIZ (Maintenance), SOMIK (Maintenance Skikda) et

SOTRAZ (Transport)

5. Deux autres filiales de services spécialisées en gestion de zone industrielle : EGZIA

(Arzew) et EGZIK (Skikda).

3.2.2. La Direction d’Informatique et de Systèmes d’Information

La Direction d’Informatique et de Systèmes d’Information a pour missions

essentielles :

La contribution à l’élaboration des stratégies et politiques de l’entreprise en matière

d’informatique, de systèmes d’information, de télécommunication et de

documentation

L’élaboration et la mise en œuvre du schéma directeur informatique de l’activité

AVAL.

L’élaboration et la mise en œuvre des plans de développement des

télécommunications de l’activité AVAL

L’appui aux projets de l’activité AVAL

L’information et le reporting de l’activité AVAL.

La Direction d’Informatique et de Systèmes d’Information est organisée comme

suit :

Le Département Systèmes Informatique (DSI)

Le Département de Développement des Bases de Données (DDBD)

LE Département de Gestion de l’Information et de la Communication (DGIC)

Le Service de Télécommunications.


41


3.2.3. Le Département Systèmes Informatique

Ce département a pour rôle la conception, le développement, la mise en œuvre et

la maintenance des bases de données et des applications informatiques.

La conception et la réalisation de l’intégration du système d’Information (Data WareHouse ).

3.3. Présentation du cahier de charges

Nous nous limiterons à la présentation des trois procédures, deux relatives à

l’élaboration des prévisions budgétaires PA et PMT des deux départements de production

(P) et de Finances (F), l’autre correspond à la procédure de validation des prévisions de

consommations quantitatives pour les articles non gérées en stocks du département des

moyens généraux (M) du plan annuel et PMT.

L’intégralité du cahier de charge est donnée en annexe 02.

3.3.1 Description de la procédure de l’élaboration du budget PA et PMT de

département ‘Production’.

Objectif : Ce budget exprime les consommations en matières premières nécessaires à

l’atteinte des objectifs de production arrêtés et les moyens de

fonctionnement internes à la structure.

a) Budget PA et PMT de la fonction production:

- Acteurs impliqués : Direction Exploitation LQS, D*E, P, G et A unité.

- Informations exploitées (input) :

Plans : plan de production

Paramètres de consommations en volume :

produits chimiques (tamis moléculaires, inhibiteur de

corrosion…)

énergies (électricité, utilités, eau, gaz naturel

autoconsommé, gaz industriels)

lubrifiants

carburants

- Prévisions de prestations de services : redevances d’occupations terre plein et

plan d’eau « STH »


42


b) Budget PA et PMT de fonctionnements de la structure P :

- Fournitures consommées (non régies par une norme) : Produits sociaux,

outillages, consommation de fournitures diverses et produits de

fonctionnement, fournitures de bureaux spécifiques, consommables

informatiques…

- Prestations de services : Nombre des missions par destinations.

Tableau descriptif

3.3.2 Description de la procédure de l’élaboration du budget PA et PMT de département ‘Finances’

Objectif : Ce budget a pour objectif de déterminer pour l’ensemble de l’Unité,

essentiellement, les prévisions des:

Impôts et taxes,

Assurances,

Dotations aux amortissements,

Acteur / Intervenant

Action/ Description Destinataire Observation / support

EXP et dép. P Projet de Plan de production Plan de production

Dép. P

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) de consommation de :

Matières et fournitures gérées en stock liées à la production (quantitatifs selon paramétrages)

Matières et fournitures pour

fonctionnements non régies par une norme, non gérées en stock et liées à la production (prévisions quantitatives)

Matières et fournitures pour

fonctionnements non régies par une norme, non gérées en stock et non liées à la production (prévisions quantitatives)

Energies (prévisions valorisées)

Elaboration et transmission des prévisions quantitatives de missions pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5). Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Dép. A Dép. A Dép. M Dép. F Dép. M Dép. F

Pour prise en compte dans le budget achat A Pour compléter budget achat A Pour compléter budget achat M Pour intégration dans le budget trésorerie Etat des missions détaillé (annexe) Pour intégration dans le budget trésorerie


43


Frais bancaires

Prestations de services prévues par Finances.

a) Budget PA et PMT élaboré par finances:

- Acteurs impliqués : Toutes les structures de l’Unité et autres structures

AVAL (DAG, FIN, DRIZ………….)


Fichier investissement et le plan d’investissement Unité (pour le

calcul des amortissements)

Plan de production (taxe GN auto consommé, ..)

Patrimoine à assurer (contrats d’assurances, plan

d’investissement et valeurs des stocks)

Plan d’approvisionnement

Le nombre de contrats et montants prévisionnels à régler aux

fournisseurs de biens et services locaux et étrangers pour

déterminer les services bancaires en rapport avec les modes de

paiements.

Listing des véhicules légers et utilitaires réel

Prestations inter unité (frais de siège DG et AVAL, participation

financière, …….)

Paiements pour compte (redevances téléphoniques, salaires des

cadres supérieurs, contrats groupés Aval,…)

Plan des consommations valorisés (A et M)

Prestations de services valorisées de toutes les structures

Prix GN autoconsommé retenu comme norme

Soldes des comptes comptables de dettes et créances par natures

de dépenses.

- Informations (output) :

Prévisions d’impôt et taxes

Prévisions d’assurances

Prévisions dotations aux amortissements

Prévisions des frais bancaires (commissions,……

Prévisions des prestations inter-unités

Valorisations des prévisions de GN autoconsommé

- Prévisions de prestations de services : honoraires avocats, commissaires-

priseurs, notaires.


44


b) Budget PA et PMT de fonctionnements de la structure F :

Fournitures consommées (non régie par une norme) : produits sociaux,

fournitures diverses et fournitures de bureaux.

Prestations de services : Nombre des missions par destinations.

Tableau descriptif

Acteur / Intervenant Action / Description Destinataire Observation /

support

Toutes les structures de l’unité et autres structures AVAL

Voir les informations exploitées (input) Dép. F

Dép. F

Dép. F

Dép. F

Dép. F

Dép. F

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) de consommation de fournitures non régies par une norme, non gérées en stock (prévisions quantitatives)

Elaboration et transmission des prévisions quantitatives de missions pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration des prévisions valorisées de prestations de services prévues par Dép. F pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Elaboration des prévisions valorisées PA (par mois pour N et N+1) et PMT (de N+2 à N+5) :

Dotation aux amortissements Prévisions prestation inter-unité Impôts et taxes Assurances Frais bancaires Valorisations des prévisions de GN

autoconsommé

Consolidations des prévisions valorisées des charges (Unité) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Consolidations des prévisions valorisées des produits (Unité) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Elaboration des prévisions de trésorerie (Unité) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Dép. M Dép. M

Pour compléter budget achat M Etat des missions détaillé Pour intégration dans le budget de trésorerie Annexe


45


3.3.3 Description de la procédure de validation des prévisions de consommations quantitatives pour les articles non gérées en stocks (M) du plan annuel et PMT

1ère validation

- les prévisions sont saisies par les chefs de services, successivement et enregistrées

par centres de coûts jusqu’à leurs 1er validation.

- Affichage sur le tableau, seulement, des articles qui ont été quantifiés

(mouvementés).

- Les services valideront les prévisions enregistrées.

- La modification ou la suppression d’une prévision validée par le chef de service

nécessite le déverrouillage par le chef de département de rattachement.

2ème validation

Après 1ère validation des chefs de services, les prévisions validées des services seront

affichées par tableau (un tableau par service) au niveau du chef de département de

rattachement.

Apres la validation par tableau des prévisions de consommations quantitatives par

les chefs de structures (non rattache à D*E ou D*S) les prévisions seront exploitées

par le département M et peuvent être consultées par F.

La modification ou la suppression des prévisions validées par les chefs de

structure nécessite le déverrouillage par le chef de département M.

3ème validation (pour les départements rattachés à D*E ou D*S)

Apres 2eme validation, les prévisions annuelles seront affichées par tableau (un

tableau par département) au niveau du D*E ou D*S.

Apres la validation par tableau des prévisions de consommations quantitatives par

D*E ou D*S les prévisions seront exploitées par le département M et peuvent être

consultées par F.

Toutes modifications ou suppressions suivant le niveau de validation suit la même démarche d’approbation.


46


4. Modélisation par UML

Comme nous l’avons vu au chapitre 1, une modélisation UML repose sur une

consolidation mutuelle de deux points de vue complémentaires : dynamique et statique. Les

aspects dynamiques sont représentés par des diagrammes d’activités. Tant dis que les

aspects statiques sont exprimés sous la forme de cas généraux dans le diagramme de classes.

4.1. Modélisation statique

En appliquant ce que nous avons vu dans le chapitre 1, nous allons représenter

dans la figure 4.2 les différentes classes et associations relatives à la modélisation statique du

système étudié.


47


Figure 4.2 - Diagramme des Classes correspondant au système étudié


48


4.2. Modélisation dynamique

Les diagrammes de flux et de données réalisés sont en nombre de vingt, parmi eux

seize sont relatifs aux processus de l’élaboration des prévisions budgétaires effectués par les

différents départements et directions et les autres quatre diagrammes décrivent les différents

processus de validation.

Nous allons présenter trois diagrammes d’activités correspondant aux procédures

d’élaborations des prévisions budgétaires PA et PMT des départements ‘Production’ et

‘Finance’, et celle de la validation des prévisions de consommations quantitatives pour les

articles non gérés en stocks (M) du plan annuel et PMT. Le reste des diagrammes se trouve

en annexe 01.


49


4.2.1 Diagramme d’activités du budget PA et PMT élaborées par le département Production (P)

Description du processus (P) :

Dès la réception du plan de production et la note accompagnée de la directive cadre, le département Production (P) commence à élaborer en parallèle les prévisions PA et PMT de consommations des matières et fournitures tout en respectant les paramètres et normes en vigueur, les prévisions quantitatives PA et PMT de missions et les prévisions valorisées PA et PMT de prestation de services.

Une fois l’élaboration des prévisions est terminée :


50


- l’acteur (P) transmettant à l’acteur département Finance (F) ses besoin en matière de prestation de services pour prise en charge dans le budget de trésorerie.

- Il transmet aussi ses prévisions de missions à l’acteur département Moyens Généraux (M). pour établir un état de missions détaillé.

- Si le consommable est de prévisions des énergies l’acteur (P) envoie ses prévisions à l’acteur (F) pour qu’elles soient intégrées dans son budget de trésorerie.

- Si non, deux cas de figures peuvent se présenter : - Si il s’agit de prévisions de consommation non liée à la fonction production, il transmet ses

prévisions à l’acteur (M) afin de lui permettre de compléter son budget d’achat (M). - Si non, il transmet les prévision à l’acteur chef de service (CS). Ce dernier a pour rôle la

saisie et l’enregistrement des prévisions. - Si l’acteur (CS) constate des anomalies il les communique à l’acteur (P) pour correction et

actualisation. - Si non, exécution de la tâche de validation des prévisions par l’acteur ‘CS’. - L’acteur ‘CS’ communique les prévisions validées à l’acteur ‘chef de département (CD)’

pour consultation. - Si l’acteur (CD) constate des anomalies effectue un déverrouillage pour permettre à l’acteur

(CS) de faire les modifications ou suppression dans les prévisions validées. - Si non, affichage des prévisions puis exécution de la tâche de validation des prévisions par

l’acteur ‘CD’.

- Si cet acteur est un chef de département non rattaché à D*E (Sous direction d’exploitation), il communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur département Approvisionnement (A) pour prise en compte dans son budget achat A et pour exploitation.

- Si non, il communique les prévisions validées à l’acteur (D*E) qui va procéder à une troisième validation par tableau de consommations quantitatives.

- Si l’acteur (D*E) constate des anomalies il les communique à l’acteur ‘chef département A’ (CDA). - l’acteur (CDA) effectue un déverrouillage et avise l’acteur ‘CS’ pour consulter, saisir et

enregistrer à nouveau les prévisions.

- Si non, l’acteur (D*E) transmet les prévisions validées à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation.

- L’acteur ‘Service AG’ (SAG) et après la validation des prévisions effectuée au niveau de

l’acteur ‘chef de département’ et celle effectuée au niveau de l’acteur (D*E), affiche les prévisions puis il procède à la validation des entrées quantitatives, en suite il affiche des articles quantifiés sur le tableau.

- Si l’acteur (SAG) constate des anomalies et après avoir obtenu le déverrouillage auprès de l’acteur ‘Service AA’ (SAA), il effectue les modifications ou suppressions dans les prévisions validées.

- Si non, l’acteur (SAG) communique les prévisions à l’acteur (SAA) qui va procéder à la valorisation et au calcul des prévisions consolidées d’achat et de consommation, puis à l’affichage et la vérification des entrées établies. En fin la procédure d’approbation du budget est entamée.


51


4.2.2 Diagramme d'activités du Budget PA et PMT élaboré par le département Finances (F)

Description du processus (F) :

- L’acteur (F) élabore puis transmet ses prévisions PA et PMT quantitatives de missions à l’acteur (M). Ce dernier établie l’état des missions détaillé.

- L’acteur ( F) élabore aussi les prévisions quantitatives PA et PMT de consommation de fournitures, en suite ; il les transmet à l’acteur (M) afin de compléter le budget achat M.

- L’acteur (F) élabore ses prévisions valorisées PA et PMT de prestations de services. - Après la réception des prévisions valorisées de toutes les structures de l’unité, en se

basant sur le plan de production et consultant les soldes des comptes comptables de dettes et créances par nature de dépenses , l’acteur (F) exécute la tâche de consolidation des prévisions valorisées PA et PMT des produits pour élaborer les prévisions de trésorerie de l’unité.

- Dès la réception des prestations inter-unités et des plans d’investissement, d’approvisionnement et de consommations valorisées (A) et (M), l’acteur (F) élabore les prévisions valorisées PA et PMT relatives aux Prévisions prestation inter-unité, aux


52


impôts et taxes, aux assurances, frais bancaires et aux valorisations des prévisions de GN autoconsommé et à la dotation aux amortissements en se basant sur le listing des véhicules légers et utilitaires réel, sur la Patrimoine à assurer et sur le prix GN autoconsommé retenu comme norme.

Une tâche de consolidation des prévisions valorisées des charges et des produits est exécutée par l’acteur (F) à l’issu de cette dernière.

4.2.3 Diagramme d'activités du processus de procédure de validation des prévisions de consommations quantitatives pour les articles non gérées en stocks (M) du plan annuel et PMT


53


Description du processus de validation des prévisions des articles non gérés en stock M:

- Dès la réception des prévisions, l’acteur ‘Chefs de services’ entame la procédure de

saisie des prévisions et des réalisations de consommations des articles non gérés en

stock M.

- Après affichage sur tableau des articles quantifiés (mouvementés), vient la première

validation des prévisions enregistrées.

- En cas d’anomalies, un déverrouillage par l’acteur ‘chef de département de

rattachement ‘ est indispensable pour modifier ou supprimer une prévision validée.

- Après la 1ère validation, les prévisions validées sont affichées par service dans un

tableau au niveau de l’acteur ‘chef de département de rattachement’.

- Ce dernier effectue une deuxième validation par tableau des prévisions de

consommations quantitatives.

- A l’issu de cette validation, les prévisions seront exploitées par l’acteur ‘M’,

consultées par l’acteur ‘F’ et affichées au niveau de l’acteur ‘D*S/D*E’.

- En fin, l’acteur ‘D*S/D*E’ procède à la validation des prévisions par tableau. Ces prévisions validées seront exploitées par l’acteur ‘M’ et consultées par ‘F’.


54


5. Modélisation par Workflow

5.1 Eléments de diagrammes de processus Workflow

Un business process diagram contient différents éléments, lesquels représentent

différentes étapes du processus comme définit ci-après :

Forme Rappel sur la description

Les événements sont représentés par des cercles et décrivent quelque chose qui se passe. Les événements indispensables au bon fonctionnement du diagramme sont l’événement de départ et l’événement final.

Les activités (task) sont représentées par un rectangle aux coins arrondis et indiquent la tâche qui doit être effectuée.

Les passerelles, représentées par des losanges, indiquent un point de décision. Elles doivent être ouvertes avant une décision et refermées sitôt que les différents chemins se rejoignent. Les passerelles (gateway) sont utilisées lorsque deux directions différentes peuvent être prises à choix. Au contraire, la passerelle (fork/join) est utilisée lorsque deux processus différents sont effectués en même temps.

Ces différents éléments sont tous reliés entre eux grâce à trois différents types d’objets de connexion. Les flux de séquence (sequence

flow) sont représentés par une flèche pleine et une ligne solide. Ils indiquent les suites d’événements ou d’activités.

Les flux de message (message flow) quand à eux sont représentés avec une flèche vide et une ligne traitillée. Ils indiquent quel message circule entre deux participants.

Les associations consistent uniquement en une ligne traitillée utilisée pour associer un fichier ou un texte à un objet.

Les swimlanes permettent d’organiser les tâches à l’intérieur de différentes colonnes représentant chacune un acteur

Data

Les artefacts (artifacts) permettent au développeur du diagramme d’apporter des informations complémentaires afin de le rendre plus compréhensible. Les objets de données (data object) sont utilisés afin d’indiquer au lecteur quel donnée est nécessaire ou est produite dans une activité.

Pool

Task


55


5.2 Modélisation des diagrammes de processus Workflow

Suite aux concepts cités dans le chapitre 2, nous allons modéliser vingt processus

workflow. Parmi eux seize sont relatifs aux processus de l’élaboration des prévisions

budgétaires effectués par les différents départements et directions et les autres quatre

diagrammes concernent les différents processus de validation.

Pour cela nous utiliserons les business process diagram (diagrammes des

processus métiers) qui sont très comparables aux diagrammes d’activités UML

(fonctionnement et représentation).

Pour ne pas rendre nos business process diagrams complexes, nous allons

utiliser pour chaque acteur un nœud de fin de processus. Mais dans la validation nous devons utiliser un et un seul nœud.


56


5.2.1 Diagramme de processus métier des prévisions budgétaires PA et PMT élaborées par le département Production (P)

Description du processus (P) : Voir la description donnée en section 4.2.1.


57


5.2.2 Diagramme de processus métier des prévisions budgétaires PA et PMT élaborées par le département Finances (F)

Description du processus (F) : Voir la description présentée dans la section 4.2.2.


58


5.2.3 Diagramme de processus métier relatif à la validation des prévisions de consommations quantitatives PA et PMT des articles non gérés en stock de département des moyens généraux (M)

Description du processus de validation des prévisions des articles non gérés en stock M:

- Dès la réception des prévisions, l’acteur ‘Chefs de services’ entame la procédure de

saisie des prévisions et des réalisations de consommations des articles non gérés en

stock M.

- Après affichage sur tableau des articles quantifiés (mouvementés), vient la première

validation des prévisions enregistrées.

- En cas d’anomalies, un déverrouillage par l’acteur ‘chef de département de

rattachement ‘ est indispensable pour modifier ou supprimer une prévision validée.


59


- Après la 1ère validation, les prévisions validées sont affichées par service dans un

tableau au niveau de l’acteur ‘chef de département de rattachement’.

- Ce dernier effectue une deuxième validation par tableau des prévisions de

consommations quantitatives.

- A l’issu de cette validation, les prévisions seront exploitées par l’acteur ‘M’,

consultées par l’acteur ‘F’ et affichées au niveau de l’acteur ‘D*S/D*E’.

- En fin, l’acteur ‘D*S/D*E’ procède à la validation des prévisions par tableau. Ces prévisions validées seront exploitées par l’acteur ‘M’ et consultées par ‘F’.

5.2.4 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Approvisionnement (A).


60


Description du processus (A) :

- L’acteur département Approvisionnement (A) et après réception des prévisions de

consommation relatives aux départements P,G,T et I, élabore les prévisions de

fonctionnement et les prévisions de prestations de service(missions). Il les transmet

à l’acteur département Moyens Généraux (M).

- Ce dernier complète le budget achat M et établie l’état des missions détaillé.

- Suivant la politique de réapprovisionnement et selon le stock existant, l’acteur (A)

élabore les prévisions valorisées en exploitant la table des prix.

- Dès réception des prévisions valorisées de l’acteur (A), l’acteur (F) les prend en

compte dans la consolidation des charges si il s’agit des dotations aux provisions

pour dépréciation des stocks gérés par A. Si non , il les prend en compte dans la

consolidation des charges et dans le budget trésorerie.

5.2.5 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Système d’information et de Gestion (SIG).


61


Description du processus (SIG) :

- Dès réception des prévisions quantitatives des consommations de fournitures et

consommables informatiques, l’acteur département Système d’Information et de

Gestion (SIS) élabore :

- les prévisions consolidées de consommations et consommables informatiques.

- les prévisions de missions qui vont être transmises à l’acteur (M) pour établir l’état

des missions professionnelles détaillé.

- les prévisions valorisées de prestations de services. Il les transmet à l’acteur (F)

pour les prendre en compte dans le budget de trésorerie.

- les prévisions de consommation de matières et fourniture.

- L’acteur (M) et après réception de l’acteur (SIG) des prévisions de consommations

consolidées gérées en stock exécute la tâche de la valorisation. Dans le cas de

prévisions de consommation consolidées non gérées en stock ou de prévisions de

consommations pour fonctionnement, il complète le budget achat M.

5.2.6 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Administration et Social (S).


62


Description du processus (S) :

- Dès réception du plan des effectifs et des besoins organigrammes, l’acteur

département Administration et Social (S) commence à :

- Elaborer les prévisions quantitatives des fournitures non gérées en stock et non

régies par une norme. Ces prévisions vont être transmises à l’acteur (M) afin de

compléter son budget achat.

- Valoriser les prévisions des salaires, charges patronales, AFC, STC et gratification

en appliquant la norme de la masse salariale RHU/AVAL.

- Valorise les prévisions de prestations de service, outillage médical et produits

pharmaceutiques.

- Il transmet les prévisions valorisées des salaires et charges et les prévisions

médicales valorisées à l’acteur (F) pour les prendre en compte respectivement dans

le budget trésorerie et le budget des charges.

- Comme il transmet à l’acteur (M) les prévisions relatives aux missions

professionnelles afin d’établir l’état détaillé des missions professionnelles.

- En parallèle, il envoie à l’acteur (M) les prévisions quantitatives de transport scolaire

et universitaire et celles des loyers et charges locatives sous forme de listes

nominatives.

5.2.7 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires réalisées par le Service Relations du Travail (RT).


63


Description du processus (RT) :

- Dès réception de la directive cadre, l’acteur service Relation de Travail (RT) élabore

puis transmet à l’acteur (M) :

- les prévisions quantitatives de consommation de fournitures non gérées en stock et

non régies par une norme afin de compléter le budget achat M.

- les prévisions de missions par destinations pour établir l’état détaillé des missions.

5.2.8 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Moyens Généraux (M).


64


Description du processus (M) :

- Dès réception de la note et de la directive cadre, l’acteur (M) élabore et valorise ses

propres prévisions.

- Après réception des prévisions quantitatives de consommation de toutes les

structures, l’acteur (M) exécute la tâche de valorisation des ces prévisions en

appliquant les normes de consommation en quantité et en exploitant le tableau des

prix.

- En respectant les normes afférents aux prestations de services il élabore :

- les prévisions consolidées de missions des structures, puis il les transmet à l’acteur

(F) pour l’établissement d’un état détaillé de missions et de formations.

- Elaborer les prévisions de prestations de services et de dotations aux provisions

pour dépréciation des stock. Ces prévisions seront transmises à l’acteur (F) afin de

les prendre en compte dans la consolidation des charges et prestations

contractuelles.

- L’achèvement des deux premières tâches déclenche la tâche de la consolidation des

prévisions par l’acteur (M) en se basant sur la politique de gestion des stocks. Ces

prévisions seront transmises à l’acteur (F) pour les prendre en compte dans la

consolidation des charges et dans le budget trésorerie.

- Sous forme de listes du nombre prévisionnel d’agents, l’acteur (M) transmet à

l’acteur ‘DAG/MOG’ les prévisions quantitatives des loyers et charges locatives et

de transport scolaire et universitaire.

- En exploitant le tableau des prix, l’acteur ‘DAG/MOG’ valorise puis transmet ces

prévisions reçues à l’acteur ‘DAG/FG’ qui va les transmettre à son tour à l’acteur

‘F.UNITES’.


65


5.2.9 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Ressources Humaines (R).

Description du processus (R) :

- Dès réception de la note et de la directive cadre, des besoins organigrammes et du

plan des départs en retraite, l’acteur (R) élabore les prévisions quantitatives de

formation selon le plan de formation. Il les transmet à l’acteur (M) pour compléter

son budget achat.

- En exploitant le tableau des prix unitaires de formations et séminaires, l’acteur (R)

valorise les prévisions de prestations de formation et des taxes. Ces prévisions

valorisées sont transmises à l’acteur (F) afin de les prendre en compte dans le budget

trésorerie et/ou charges inter-unité.

- l’acteur (R) élabore les prévisions de prestations de services. Il transmet les

prévisions de missions professionnelles et les prévisions de missions pour formation

à l’acteur (M). Ce dernier et selon le cas, il établie un état détaillé de missions.


66


5.2.10 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Passation des Marchés (PM).

Description du processus (PM) :

- Dès réception de la note et de la directive cadre et du plan de passation des marchés

par structure, l’acteur (PM) élabore :

- les prévisions quantitatives de consommation de fournitures. Il les transmet à

l’acteur (M) pour compléter son budget achat.

- les prévisions valorisées de prestations de services. formation et des taxes. Ces

prévisions valorisées sont transmises à l’acteur (F) afin de les prendre en compte

dans le budget trésorerie.

- les prévisions de missions qui seront transmises par la suite à l’acteur (M). Ce

dernier établie un état détaillé de missions.


67


- les prévisions consolidées de recettes liées aux retraits des cahiers de charges. Puis

il les transmet à l’acteur (F) pour les prendre en compte dans les prévisions de

produits d'exploitation.

5.2.11 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires réalisées par l’Assistant Sûreté Interne (ASI).

Description du processus (ASI) : idem que la description précédente du processus (PM) sauf que et en plus de la note et la directive cadre, l’évènement déclencheur cette fois ci est la réception des prévisions relatives au nombre de personnel ouvrant droit à l’accès aux différentes zones.


68


5.2.12 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires réalisées par le Conseil Syndical.

Description du processus (Conseil Syndical) :

- Dès réception de la directive cadre, l’acteur Conseil Syndical élabore puis transmet à

l’acteur (M) :

- les prévisions quantitatives de consommation de fournitures non gérées en stock et

non régies par une norme afin de compléter le budget achat M et de valoriser les

consommations.

- les prévisions de missions par destinations pour établir l’état détaillé des missions.


69


5.2.13 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Maintenance (G).

Description du processus (G) :

Dès la réception d’une note accompagnée de la directive cadre, du plan de maintenance et du plan d’investissement, le département Maintenance (G) commence à élaborer en parallèle les prévisions PA et PMT de consommations des matières et fournitures tout en respectant les paramètres et normes en vigueur, les prévisions quantitatives PA et PMT de missions et les prévisions valorisées PA et PMT de prestation de services.

Une fois l’élaboration des prévisions est terminée, cet acteur (G) transmet à l’acteur département de Finance (F) ses besoin en matière de prestation de services pour que ce dernier les prenne en charge dans l’élaboration du budget de trésorerie. Il transmet aussi ses


70


prévisions de missions à l’acteur département Moyens Généraux (M) qui va à son tour établir un état des missions détaillé en tenant en compte les prévisions reçues.

Si il s’agit de prévisions de consommation non liée à la fonction maintenance, l’acteur (G) transmet ses prévisions à l’acteur (M) afin de lui permettre de compléter son budget d’achat M, si non il transmet les prévision au chef de service. Ce dernier a pour rôle la saisie et l’enregistrement des prévisions. Un test est effectué à son niveau, dans le cas d’anomalies il les communique à l’acteur (G) pour correction et actualisation. Une fois la correction est faite et dans l’absence d’anomalies, une tâche de validation des prévisions est exécutée par l’acteur ‘Chef de Service’. Dès que cette première validation est terminée, les prévisions validées sont affichées au niveau de l’acteur ‘chef de département’. Ce dernier effectue une deuxième validation. Si cet acteur est un chef de département non rattaché à

D*E, il communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation. Si non (c à d. chef

département rattaché à D*E), il communique les prévisions validées à l’acteur ‘D*E’ qui va procéder à une troisième validation par tableau de consommations quantitatives. Si il constate des anomalies il les communique à l’acteur ‘chef de service’ pour consulter, saisir et enregistrer à nouveau les prévisions. Si non (c à d pas d’anomalies constatées par l’acteur

‘D*E’), les prévisions validées vont être transmises à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation.

5.2.14 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires réalisées par la Direction de l’unité, D*E et D*S.

Description du processus (D*E et D*S) : Ce processus est le même que le processus (RT)

avec l’acteur (D*E et D*S) à la place de (RT).


71


5.2.15 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Technique (T).

Description du processus (T) :

Dès la réception d’une note accompagnée de la directive cadre et le planning des visites, le département Technique (T) commence à élaborer en parallèle les prévisions

quantitatives PA et PMT, les prévisions de prestation de services tout en respectant les normes réglementaires et les prévisions de missions.

Une fois l’élaboration des prévisions est terminée, l’ acteur (T) transmet à l’acteur (F) ses besoin en matière de prestation de services pour que ce dernier les intègre dans le budget de trésorerie. Il transmet aussi ses prévisions de missions à l’acteur (M) qui va établir un état détaillé des missions professionnelles en tenant en compte les prévisions reçues. Si il s’agit de prévisions de consommation pour le fonctionnement, l’acteur (T) transmet ses prévisions régies par norme et gérées en stock à l’acteur (M) afin de lui permettre de compléter son budget achat M, si non il transmet les prévision de matières et fournitures gérées et non gérées en stock au chef de service. Ce dernier a pour rôle la saisie et


72


l’enregistrement des prévisions. Un test est effectué à son niveau, dans le cas d’anomalies il les communique à l’acteur (T) pour correction et actualisation. Une fois la correction est faite et dans l’absence d’anomalies, une tâche de validation des prévisions est exécutée par l’acteur ‘Chef de Service’. Dès que cette première validation est terminée, les prévisions validées sont affichées au niveau de l’acteur ‘chef de département’. Ce dernier effectue une

deuxième validation. Si cet acteur est un chef de département non rattaché à D*E, il communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation. Si non, il communique les

prévisions validées à l’acteur ‘D*E’ qui va procéder à une troisième validation par tableau de consommations quantitatives. Si il constate des anomalies il les communique à l’acteur ‘chef de service’ pour consulter, saisir et enregistrer à nouveau les prévisions. Si non, les prévisions validées vont être transmises à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation.

5.2.16 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Sécurité Industrielle (I).


73


Description du processus (I) :

Ce processus est similaire que le processus (T) sauf que: - l’évènement déclencheur est composé de la note accompagnée de le directive cadre et

du plan HSE. - l’acteur principal est le département Sécurité industrielle (I) au lieu de l’acteur (T).

5.2.17 Diagramme de processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT réalisées par le département Travaux Neufs (W).

Description du processus (W) :

Ce processus est similaire que le processus (T) sauf que: - l’évènement déclencheur est composé de la note accompagnée de le directive cadre et

des programmes d’investissements. - l’acteur principal est le département Travaux neufs (I) au lieu de l’acteur (T). - les documents exploités pour l’élaboration des prévisions quantitatives et des

prévisions de prestations de services sont Planning des arrêts de maintenance , listing des investissements et les conventions.


74


5.2.18 Diagramme de processus métier relatif à la validation des prévisions des stocks, d’achats et consommations des articles gérés en stock (A) du plan annuel et PMT.

Description du processus de validation des prévisions des articles gérés en stock A:

- Dès la réception des prévisions, l’acteur ‘Chef de service (A)’ entame la procédure de

consultation, de saisie et d’enregistrement des prévisions.

- En cas d’anomalies, l’acteur ‘Chef de service (A)’ avise l’acteur (A) pour une éventuelle

correction et actualisation. Une fois cette correction est faite et dans l’absence

d’anomalies, l’acteur ‘Chef de service (A)’ exécute la tâche de validation.


75


- L’acteur ‘chef de département de rattachement’ consulte les prévisions validées. S’il

constate des anomalies il effectue un déverrouillage afin de permettre à l’acteur ‘chef de

service’ de procéder à la modification ou la suppression dans les prévisions validées.

Dans l’absence d’anomalies et après affichage des prévisions validées, l’acteur ‘chef de

département de rattachement’ valide les prévisions.

- Si cet acteur est un chef de département non rattaché à D*E, il communique les prévisions validées à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation. Si non, il communique les prévisions validées à

l’acteur ‘D*E’ qui va procéder à une troisième validation par tableau de consommations quantitatives. Si il constate des anomalies il avise l’acteur ‘chef de département (A)’ pour effectuer le déverrouillage afin de permettre à l’acteur ‘chef de service’ de consulter, saisir et enregistrer à nouveau les prévisions. Si non, les prévisions validées vont être transmises à l’acteur (F) pour consultation et à l’acteur (A) pour prise en compte dans son budget achat A et pour exploitation.

- Après la deuxième validation des prévisions et la troisième validation par tableau de

consommations quantitatives effectuées respectivement par les acteurs ‘chef de

département de rattachement’ et ‘D*E’, un affichage des prévisions de consommations

gérées en stock et du tableau des prévisions de consommations quantitatives est effectué

au niveau de l’acteur ‘Service AG’ qui va procéder à la validation des entrées

quantitatives, puis à l’affichage des articles quantifiés sur le tableau et en fin à une

modification ou suppression dans les prévisions validées après exécution de

déverrouillage par l’acteur ‘Service AA’.

- Ce dernier et après avoir reçu les prévisions quantitatives validées et actualisées de l’acteur ‘Service AG’ passe à la valorisation et au calcul des prévisions consolidées. Après affichage des entrées établies, un test de vérification est effectué par cet acteur. Si ces entrées ne sont pas approuvées, il les communique à l’arteur (A) pour révision. Ce dernier transmet les entrées révisées à l’acteur ‘structure concernée’. Cet acteur modifie les prévisions de consommation puis envoie les prévisions modifiées à l’acteur ‘chef département (A)’. Ce dernier et après déverrouillage des tableaux de consommations quantitatives, puis affichage des articles valorisés transmet ces prévisions modifiées à l’acteur ‘Service AA’. Une validation des prévisions enregistrées modifiées/approuvées est effectuée par cet acteur. Qui va en suite communiquer les prévisions validées à l’acteur ‘chef département (A)’ pour une autre validation. L’acteur ‘chef département (A)’ et dans le cas d’anomalies opère une modification ou suppression dans les prévisions

validées après déverrouillage effectué par l’acteur ‘D*S’. Dans l’absence d’anomalies,

l’acteur (A) envoie les prévisions validées à l’acteur ‘D*S’ pour validation des tableaux

quantitatifs et valorisés. En fin, l’acteur ‘D*S’ communique ces tableaux à l’acteur (F) qui va les exploiter.


76


5.2.19 Diagramme de processus métier relatif à la validation des prévisions des stocks, d’achats et consommations des articles non gérés en stock (A) du plan annuel et PMT.

Description du processus de validation des prévisions des articles non gérés en stock A :

Idem que le processus précédent, sauf que l’acteur ‘Service AG’ n’intervient pas cette fois, et que l’acteur ‘Service AA’ a des tâches en plus, telle que l’affichage des prévisions des consommations non gérées en stock A, la validation des prévisions quantitatives et consolidées d'achat des articles non gérés en stock A et la modification/suppression dans les prévisions validées.


77


5.2.20 Diagramme de processus métier relatif à la validation des prévisions consolidées d’achats et consommations pour les articles non gérés en stock (M) du plan annuel et PMT.

Description du processus de validation des prévisions consolidées de consommations

des articles non gérés en stock M:

- Dès la réception des prévisions de consommations des structures, l’acteur (M)

entame la procédure de valorisation des prévisions quantitatives et d'achets consolidées

en exploitant la table des prix. Puis il exécute une tâche de vérification des prévisions


78


établies. Dans le cas de non approbation des prévisions, il les transmet à l’acteur

‘structure concernée’.

- Après une modification des prévisions et acceptation des modification par

l’acteur ‘structure concernée’, un déverrouillage des tableaux de consommations

quantitatives M et des tableaux des départements concernés, puis un affichage des

entrées non approuvées des articles valorisés sont effectués par l’acteur ‘chef de

département (M)’.

- L’acteur ‘chef de service (M) et après approbations des prévisions établies ou

affichage des entrées non approuvées des articles valorisés valide les prévisions

enregistrées. Dans le cas d’anomalies il procède à une modification ou suppression dans

les prévisions validées après un déverrouillage effectué par l’acteur ‘chef de département

(M)’. Dans l’absence d’anomalies ou après modification, une validation des prévisions est

effectué par l’acteur ‘chef de département (M)’. Ce dernier et en cas d’anomalies , effectue

lui-même une modification ou suppression dans les prévisions validées après un

déverrouillage effectué par l’acteur après un déverrouillage effectué par l’acteur ‘D*S’.

- L’acteur D*E et après le résultat du test effectué par l’acteur ‘chef de

département (M)’ exécute une tâche de validation des tableaux des prévisions

consolidées d’achats et consommations pour les articles non gérés en stock (M), en suite

il communique les tableaux des prévisions validés à l’acteur ‘structure concernée’ pour

prise en charge dans le budget d’achat et à l’acteur (F) pour exploitation du tableau des

prévisions consolidées d’achats et consommations pour les articles non gérés en stock

(M).

CChhaappiittrree 55

VVaalliiddaattiioonn ddeess ddiiaaggrraammmmeess ddee

pprroocceessssuuss WWoorrkkFFllooww mmooddéélliissééss

Chapitre V – Validation des diagrammes de processus Workflow

79


5.1 Introduction

Cette étape consiste à l’élaboration des fichiers BPEL correspondant aux

diagrammes des processus métiers modélisés.

Pour cela nous avons utilisé le logiciel MagicDraw, qui rend possible l’exportation

de diagrammes des processus métiers vers du BPEL, il suffit d’utiliser la fonction « exporter

» puis « BPEL » dans l’onglet fichier pour qu’un fichier BPEL soit créé. Bien sûr cela n’est

effectuable uniquement si le diagramme ne contient aucune erreur. Dans le cas contraire

l’exportation n’est pas possible et le programme indiquera le type d’erreur soulevée.

Le fichier BPEL ainsi créé se présente sous la forme d’un fichier XML comme nous

l’avons vue dans le chapitre 3:

5.2 Génération des fichiers BPEL de validation

Nous allons tout d’abord présenter à titre d’exemple quelques figures illustrant les différentes étapes à suivre pour modéliser un processus workflow sous l’éditeur MagicDraw.

Figure 5.1- Création d’un nouveau projet nommé BPD_Finances à partir de la page d’accueil MagicDraw


80


Figure 5.2- Sélection d’un Star Event du menu principal du logiciel MagicDraw

Figure 5.3- Création d’un star Event avec un nœud fork/join et des nœuds d’activités


81


Après avoir crée le modèle de processus métier sous l’éditeur MagicDraw, nous

passons à l’étape de sa validation en exécutant comme nous avons vu dans la section 5.1 la

fonction « exporter » puis « BPEL » dans l’onglet fichier et en fin nous obtiendrons les fichier

BPEL correspondants aux différents processus métiers que nous allons présenter ci dessous.

Figure 5.4- Création d’un processus métier relatif à l’élaboration des prévisions budgétaires des finances


82


5.2.1 Fichier BPEL du diagramme de processus métier des prévisions budgétaires élaborées par le département Production (P)

<xml version='1.0' encoding='UTF-8'?>

<process xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

<partnerLinks>

<partnerLink myRole="dfltMyRole" name="dfltName" partnerLinkType="dfltPartnerLinkType"

partnerRole="dfltPartnerRole"></partnerLink></partnerLinks>

<partners>

<partner name="dfltName"></partner>

<partnerLink name="dfltName"></partnerLink></partners>

<variables>

<variable messageType="dfltMessageType" name="dfltName"></variable></variables>

<sequence>

<receive createInstance="yes" name="plan de production" operation="dfltOperation" partner=""

partnerLink="dfltPartnerLink" portType="dfltPortType" variable=""></receive>

<Flow name="">

<sequence>

<empty name="Elaboration des prévisions de prestations de services PA et PMT "></empty>

<empty name="Transmission des prévisions de prestation de services "></empty>

<empty name="Intégration dans le budget trésorerie"></empty>

</sequence>

<sequence>

<empty name="Elaboration des prévisions de missions PA et PMT "></empty>

<empty name="Transmission des prévisions des missions "></empty>

<empty name="Etablissement d'état de missions professionnelles détaillé "></empty>

</sequence>

<sequence>

<empty name="Elaboration des prévisions de consommation PA et PMT "></empty>

<switch name="">

<case condition="Non quantitative">

<empty name="Transmission des prévisions des énergies "></empty>

<empty name="Intégration dans le budget trésorerie"></empty>

</case>

<otherwise>

<switch name="">

<case condition="Non lié à la production">

<empty name="Transmission des prévisions"></empty>

<empty name="Compléter le budget Achat M "></empty>

</case>

<otherwise>

<empty name="Transmission des prévisions de consommable production gérées et

non gérées en stock "> </empty>

<empty name="Consultation, saisie et enregistrement des prévisions "></empty>

<switch name="">

<case condition="Cas d’anomalies">

<empty name="Correction et Actualisation "></empty>

</case>


83


</switch>

<empty name="Validation des prévisions "></empty>

<empty name="Consultation des prévisions "></empty>

<switch name="">


<empty name="Déverrouillage"></empty>

<empty name="Modification ou suppression dans les prévisions validées">

</empty>

</case>

</switch>

<empty name="Affichage des prévisions validées"></empty>

<empty name="Validation des prévisions "></empty>

<sequence>

<switch name="">

<case condition="Chef de département rattaché à D*E">

<empty name="Affichage des prévisions validées"></empty>

<empty name="Validation par tableau de consommations quantitatives">

</empty>

<sequence>

<empty name="Affichage des prévisions des consommations gérées en

stock et du tableau des prévisions de consommations

quantitatives"></empty>

<empty name="Validation des entrées quantitatives"></empty>

<empty name="Affichage des articles quantifiés sur le tableau"></empty>

<switch name="">


<empty name="Déverrouillage"></empty>

<empty name="Modification ou suppression dans les prévisions

validées">

</empty>

</case>

</switch>

<empty name="valorisation et calcul des prévisions consolidées d'achat et

de consommation ">

</empty>

<empty name="Affichage et vérification des entrées établies "></empty>

</sequence>

<sequence>

<switch name="">

<case condition=" Cas d’anomalies ">

<empty name=" Déverrouillage "></empty>

<empty name=" Consultation, saisie et enregistrement des

prévisions ">

</empty>

</case>

<otherwise>

<switch name="">

<case condition="Pour finance">

<empty name="Consultation des prévisions validées">

</empty>

</case>


84


<otherwise>

<empty name="Prise en compte dans le budget Achat A et

exploitation des prévisions validées ">

</empty>

</otherwise>

</switch>

</otherwise>

</switch>

</sequence>

</case>

<otherwise>

<switch name="">

<case condition="Pour finance">

<empty name="Consultation des prévisions validées"></empty>

</case>

<otherwise>

<empty name="Prise en compte dans le budget Achat A et exploitation

des prévisions validées ">

</empty>

</otherwise>

</switch>

</otherwise>

</switch>

</sequence>

<sequence>

<empty name="Affichage des prévisions des consommations gérées en stock et du

tableau des prévisions de consommations quantitatives">

</empty>

<empty name="Validation des entrées quantitatives"></empty>

<empty name="Affichage des articles quantifié s sur le tableau "></empty>

<switch name="">


<empty name=" Déverrouillage "></empty>

<empty name="Modification ou suppression dans les prévisions validées">

</empty>

</case>

</switch>

<empty name="valorisation et calcul des prévisions consolidées d'achat et de

consommation "></empty>

<empty name="Affichage et vérification des entrées établies "></empty>

</sequence>

</otherwise>

</switch>

</otherwise>

</switch>

</sequence>

</flow>

</process>


85


5.2.2 Fichier BPEL du diagramme de processus métier des prévisions budgétaires élaborées par le département Finance (F)



<partnerLinks>



<partners>



<variables>


<sequence>

<receive>

<receive createInstance="yes" name="Fichier et Plan d’investissement" operation="dfltOperation"

partner="" partnerLink="dfltPartnerLink" portType="dfltPortType" variable=""></receive>

<receive createInstance="yes" name="Plan de production" operation="dfltOperation" partner=""


<receive createInstance="yes" name="Plan d’approvisionnement" operation="dfltOperation" partner=""


<receive createInstance="yes" name="Plan de consommations valorisées (A & M)"

operation="dfltOperation" partner="" partnerLink="dfltPartnerLink" portType="dfltPortType"

variable=""></receive>

<receive createInstance="yes" name="Prestations inter-unité" operation="dfltOperation" partner=""


<receive createInstance="yes" name="Prévisions valorisées de toutes les structures"



<receive createInstance="yes" name="Soldes des comptes comptables de dettes et créances par nature

de dépenses" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink"

portType="dfltPortType" variable=""></receive>

<receive createInstance="yes" name="Patrimoine à assurer" operation="dfltOperation" partner=""


<receive createInstance="yes" name="Listing des vehicules légers et utilitaires réels"



<receive createInstance="yes" name="Paiement pour compte" operation="dfltOperation" partner=""


<receive createInstance="yes" name="Prix GN autoconsommé retenu comme norme"



</receive>

<Flow name= "">

<sequence>

<empty name="eElaboration des prévisions quantitatives de missions PA et PMT"></empty>

<empty name="Transmission des prévisions des missions"></empty>

<empty name="Etablissement de l’état de missions détaillé"></empty>

</sequence>

<sequence>


86


<empty name="Elaboration des prévisions quantitatives PA et PMT de consommation de fournitures

"> </empty>

<empty name="Transmission des prévisions de consommation de fournitures "></empty>

<empty name=" Compléter le budget achat M"></empty>

</sequence>

<sequence>

<empty name="Elaboration des prévisions valorisées PA et PMT de prestations de services pour

(F)">

</empty>

<empty name="Elaboration des prévisions de trésorerie PA et PMT"></empty>

</sequence>

<sequence>

<empty name="Consolidation des prévisions valorisées des produits (Unité) PA et PMT"></empty>

<empty name="Elaboration des prévisions de trésorerie (Unité) PA et PMT"></empty>

</sequence>

<sequence>

<empty name="Elaboration des prévisions valorisées PA et PMT de dotation aux

amortissements">

</empty>

<empty name="Elaboration des prévisions valorisées PA et PMT de prestations inter-unité ">

</empty>

<empty name="Elaboration des prévisions valorisées PA et PMT des Impôts et taxes, Assurances,

frais bancaires">

</empty>

<empty name="Valorisations des prévisions de GN autoconsommé"></empty>

<empty name="Consolidation des prévisions valorisées avec les prévisions valorisées des charges

(Unité) PA et PMT">

</empty>

</sequence>

</Flow name>

</sequence>

</process>

5.2.3 Fichier BPEL du diagramme de processus métier relatif à la validation des prévisions de consommations quantitatives des articles non gérés en stock de département des moyens généraux (M)



<partnerLinks>



<partners>



<variables>


<sequence>

<receive createInstance="yes" name="Reception des prévisions et des réalisations de consommations

des articles non gérés en stock M" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink"

portType="dfltPortType" variable=""></receive>


87


<Flow name="">

<empty name=" Saisie des prévisions et des réalisations de consommations des articles non gérés

en stock M">

</empty>

<empty name="Affichage des articles quantifiés "></empty>

<empty name="Validation des prévisions enregistrées"></empty>

<switch name="">


<empty name="Dévrrrouillage "></empty>

<empty name="Modification /suppression dans les prévisions validées"></empty>

</case>

</switch>

<empty name="Affichage par tableau des prévisions validées "></empty>

<empty name="Validation par tableau de consommations quantitatives"></empty>

switch name="">


<empty name="Dévrrrouillage "></empty>

<empty name="Modification /suppression dans les prévisions validées"></empty>

</case>

</switch>

switch name="">

<case condition=" Département M ">

<empty name="Exploitation des prévisions"></empty>

</case>

<otherwise>

<switch name="">

<case condition="Département F">

<empty name="Consultation des prévisions"></empty>

</case>

<otherwise>

<empty name="Affichage des prévisions annuelles par tableau "></empty>

<empty name="Validation par tableau des prévisions de consommations

quantitatives">

</empty>

<sequence>

<empty name="Consultation des prévisions"></empty>

</Sequence>

<sequence>

<empty name=" Exploitation des prévisions "></empty>

</Sequence>

</otherwise>

</switch>

</otherwise>

</switch>

</Flow>

</Sequence>

</process>

CChhaappiittrree 66

AArrcchhiitteeccttuurree ddeess pprroocceessssuuss mmééttiieerrss

eett rreepprréésseennttaattiioonn rreellaattiioonnnneellllee dduu

mmooddèèllee ssttaattiiqquuee

Chapitre VI - Architecture des processus métiers et représentation relationnelle

88


1. Introduction

Dans ce chapitre nous allons présenter les vues partielles des architectures métiers

du système étudié enrichies d’une description textuelle de chaque architecture. En suite,

nous allons entamer la procédure de la représentation relationnelle du modèle statique que

nous avons conçu dans le chapitre IV.

2. Architecture des processus métiers

2.1. Architecture du processus métier de département Production (P)


89


- Description de l’architecture (P):

Cette architecture représente le processus métier relatif à l’élaboration des

prévisions budgétaires PA et PMT de département (P). Ce processus est composé de six objets qui représentent soit des processus métiers

eux même composés (Gestion Prévisions Production (P), Gestion Prévisions Maintenance (M), Gestion Prévisions Approvisionnement (A), Gestion des Ressources (Bases de données)) soit des acteurs externes (Département Finance (F), DAG/MOG).

En se basant sur le plan de production, l’objet (P) invoque la base des articles pour élaborer les prévisions PA et PMT des matières et fournitures liées à la production (articles gérés en stock et ceux non gérés en stock), de fonctionnement (Matières et fournitures non liées à la production, et missions) et de prestation de services et énergie (Prévisions valorisées).

Dès que le processus d’élaborations des différentes prévisions est terminé, un processus de validation des prévisions est exécuté afin de les corriger et les finaliser. L’objet (A) communique ses besoins validés aux autres objets collaborateurs de la façon suivante :

Les prévisions de fonctionnement composées de prévisions de missions et de prévisions de consommation des matières et fournitures non gérées en stock et non liée à la production sont communiquées à l’objet (M) via le flux (P’’’

1). Les prévisions valorisées (prestation des services et énergies) sont transmises à l’objet (F) via le flux (P’’). L’objet (P) envoie à l’objet (A) les prévisions en matière d’articles gérés en stock via le flux (P1), et les prévisions en matière d’articles non gérés en stock via le flux (P’

1). Lui-même, l’objet (A) lance le processus d’élaboration des prévisions relatives à

son propre fonctionnement (Matières et fournitures non régies par une norme, Missions) et des prévisions de dotation. Après réception des prévisions d’achat pour les articles gérés ou non gérés en stock des différents centres de coût et en interrogeant les bases BSS/BRS et BSD, l’objet (A) arrête les prévisions de consommations de ces articles et passe en suite à l’exécution du processus de valorisation en utilisant la table des prix des produits. Un processus de validation interne est bien sûr exécuté pour objectif de finaliser les prévisions. L’objet (A) communique à l’objet (F) ses prévisions de dotation, de consommation des articles gérés en stock et de ceux non gérés en stock via respectivement les trois flux (A’), (P2) et (P’

2[A]). À l’objet (M) seront transmises les prévisions quantitatives de fonctionnement de

l’objet (A) via le flux (A1). À son tour, l’objet (M) élabore ses différentes prévisions relatives aux achats et

consommations pour les articles gérés en stock, au fonctionnement (Matières et fournitures non gérées en stock et de missions), aux achats pour articles non gérés en stock, aux dotations, aux charges locatives et aux transports scolaire et universitaire en interrogeant l’objet Base Personnel. Après avoir reçu les prévisions quantitatives des différents objets collaborateurs, un processus de validation est exécuté. En se basant sur les réponses de l’objet Table Produit/Prix, le processus de valorisation est exécuté pour les diverses prévisions quantitatives. L’objet (M) transmet à l’objet (DAG/MOG) les prévisions de transports scolaire et universitaire et celles des charges locatives, et à l’objet (F) les prévisions de fonctionnement, les prévisions d’achat des articles non GS, les prévisions valorisées de l’objet (A) et les prévisions valorisées de l’objet (P) respectivement via les flux (Mg1), (Mg2), (Mg3), (A2[M]) et (P’’’

2[M]).


90


2.2. Architecture du processus métier de département Approvisionnement (A)

- Description de l’architecture du processus (A):

Cette architecture représente le processus métier relatif à l’élaboration des prévisions budgétaires PA et PMT de département (A).

l’objet (A) lance le processus d’élaboration des prévisions de fonctionnement (Matières et fournitures non régies par une norme, Missions) et des prévisions de dotation.

Après avoir reçu les prévisions de consommations des objets collaborateurs P,G,T,I et W , il arrête les prévisions de consommations de ces articles et passe en suite à l’exécution du processus de valorisation en utilisant la table des prix des produits. Un processus de validation interne est bien sûr exécuté pour objectif de finaliser les prévisions. L’objet (A) communique à l’objet (M) ses prévisions quantitatives de fonctionnement via le flux (A1) et


91


à l’objet (F) ses prévisions valorisées de dotation, de consommation des articles non gérés en stock et de ceux gérés en stock via respectivement les trois flux (A’), (CC2) et (CC’

2). Concernant l’objet (M), les mêmes processus que dans la section 2.1.

2.3. Architecture du processus métier de département Maintenance (G)

Description de l’architecture du processus (G): cette architecture est la même que celle du processus (P) sauf que l’objet (G) n’a pas de prévisions d’énergie à élaborer et les prévisions des matières et fournitures sont liées à la fonction maintenance..


92


2.4. Architecture du processus métier de département Sécurité Industrielle

Description de l’architecture du processus (I): Cette architecture est la même que celle du processus (G).


93


2.5. Architecture du processus métier de département Moyens Généraux (M)

Description de l’architecture du processus (M): En consultant l’état du stock, l’objet (M) élabore ses différentes prévisions relatives aux achats et consommations pour les articles gérés en stock, au fonctionnement (Matières et fournitures non gérées en stock et de missions), aux achats pour articles non gérés en stock, aux dotations, aux charges locatives et aux transports scolaire et universitaire en interrogeant l’objet Base Personnel. Après avoir reçu les prévisions quantitatives des différents objets collaborateurs, un processus de validation est exécuté. En se basant sur les réponses de l’objet Table Produit/Prix, le processus de valorisation est exécuté pour les diverses prévisions quantitatives. L’objet (M) transmet à l’objet (DAG/MOG) les prévisions de transports scolaire et universitaire et de charges locatives, et à l’objet (F) les prévisions de fonctionnement, les prévisions d’achat des articles non GS, les prévisions valorisées de tout les objets collaborateurs.


94


2.6. Architecture du processus métier de département Technique (T)

Description de l’architecture du processus (T): cette architecture est la même que

celle du processus (G).


95


2.7. Architecture du processus métier de département Travaux Neufs (W)

Description de l’architecture du processus (W): Cette architecture est la même que

celle du processus (G) sauf que l’objet (w) n’a de prévisions des matières et fournitures que pour le fonctionnement.


96


3. Représentation relationnelle du modèle statique

Le passage vers le modèle relationnel est soumis à un ensemble de règles. Ce

passage donne lieu au modèle logique de données (MLD) que nous allons décrire sous la

forme relationnelle par le schéma relationnel de la base de données.

3.1. Règle de passage du modèle conceptuel au modèle relationnel

Toute classe mère du diagramme de classes devient une table de la base de données

avec comme clé primaire l’identifiant de la classe.

Toute classe fille du diagramme de classes devient une table avec comme clé

primaire composée de la concaténation de son identifiant et ce lui de la classe mère

correspondante.

Toute classe associative devient une table avec comme clé primaire composée de la

concaténation de son identifiant et ceux des classes participant à l’association.

3.2. Schéma du modèle relationnel relatif au modèle statique conçu

1) Département(Code département, désignation département) 2) Article(Code article, désignation article, unité mesure, n°compte comptable) 3) Matières_Fournitures(Code article, désignation article, unité mesure, n°compte

comptable, type mat_four, nature mat_four) 4) Paramètre(Code article ,Numéro paramètre, valeur paramètre) 5) Destination(Code destination, désignation destination, type destination) 6) Manifestation(Code manifestation, Code destination, désignation, n°compte

comptable) 7) Prestation de services(Code prestation, désignation prestation, type prestation,

n°compte comptable) 8) Recettes(Code recette, désignation recette, nature recette, n°compte comptable) 9) Missions(Code manifestation, Code destination, désignation, n°compte comptable,

motif mission) 10) Formations(Code manifestation, Code destination, désignation, n°compte

comptable, type formation) 11) Charges diverses(Code charges diverses, désignation charges diverses, n°compte

comptable) 12) Energie(Code article, désignation article, unité mesure, n°compte comptable) 13) Rubrique(Code rubrique, libellé rubrique, n°compte comptable) 14) Fonction personnel(Code fonction, libellé fonction, n°compte comptable) 15) Employés(Matricule, code fonction) 16) Prévisions article(Code département, Code article, Numéro prévision, exercice,

mois, quantité, montant prévision DA, montant prévision devises) 17) Prévisions prestations(Code département, Code prestation, Numéro prévision,

exercice, mois, montant prestation DA, montant prestation devises)


97


18) Prévisions recettes(Code département, Code recette, Numéro prévision, exercice, mois, montant recettes DA, montant recettes devises)

19) Prévisions manifestation(Code département, Code manifestation, Numéro prévision, exercice, mois, nombre de personnes, date début, date fin, coût manifestation)

20) Prévisions charges diverses(Code département, Code charges diverses, Numéro prévision, exercice, mois, nombre de personnes, montant prévision)

21) Prévisions salaire(Code département, Code fonction, Numéro prévision, exercice, mois, effectif, type effectif, montant)

22) Prévisions rubrique(Code département, Code fonction, Code rubrique, Numéro prévision, exercice, mois, nombre effectif, type effectif, montant).

La clé est indiquée par l’attribut(s) souligné(s).

CCoonncclluussiioonn ggéénnéérraallee

Conclusion Générale

98


Conclusion générale Ce travail nous a permis en premier lieu de se familiariser avec l'environnement

UML et workflow.

Nous avons parlé dans le premier chapitre du langage UML en présentant ses

principaux diagrammes utilisés dans la modélisation des systèmes. Dans le deuxième

chapitre, nous avons abordé la technologie des workflows qui a pris une position importante

dans la gestion des processus des organisations.

Le troisième chapitre est consacré pour la présentation du langage d’exécution des

processus métiers (Business Process Execution Language). Ce langage ‘BPEL’ va être utilisé

dans la validation de notre modélisation workflow dans le chapitre cinq.

Après avoir étudié le cahier charge présenté par l’équipe de l’organisme d’accueil

AVAL/SONATRACH, et suite aux explications et éclaircissements retenues lors des

différentes séances de travail tenues avec l’équipe AVAL/SONATRACH et notamment les

responsables de département informatique et ceux des finances, nous avons pu concevoir le

système d’information relatif au processus activité budgétaire réalisé aux niveaux des

différentes structures de l’activité AVAL/SONATRACH.

Dans notre démarche de conception, nous avons présenté une modélisation

statique décrite par le diagramme des classes vu dans la section 4.1 du chapitre IV, puis nous

avons entamé une modélisation dynamique en élaborant vingt (20) diagrammes d’activités,

dont certains sont cités dans la section 4.2 du chapitre IV, et d’autres dans l’annexe 1. Par la

suite et dans la section 5.2, nous avons appliqué le workflow à ces derniers diagrammes

pour réaliser notre modélisation workflow des différents processus métiers composant le

système de l’activité budgétaire. Cette modélisation est enrichie d’une description textuelle

de chaque processus.

Dans le cinquième chapitre nous avons réalisé la validation des diagrammes

workflows conçus, pour cela, nous avons choisi le langage BPEL présenté dans le chapitre

III. Afin de réaliser cette validation nous avons implémenté quelques diagrammes en

Conclusion Générale

99


utilisant l’éditeur du logiciel MagicDraw . En exécutant la fonction ‘Exporter vers BPEL’, et

dans le cas d’absence d’erreur, un fichier BPEL sous format XML est généré.

Dans le chapitre VI, nous avons aussi conçu sept (7) architectures métiers pour

préparer l’étape de l’implémentation du système de l’activité budgétaire AVAL et qui n’est

pas notre objectif dans ce travail.

En fin, nous avons représenté la structure relationnelle de la modélisation statique

UML vue dans la section 4.1 du chapitre IV. Cette représentation permettra dans le futur de

concevoir la base de données relative au processus activité budgétaire AVAL.

La continuité de ce travail est de réaliser un logiciel intégrant cette modélisation

traitant les prévisions budgétaires au sein de toutes les structures de Aval/Sonatrach.

AAnnnneexxee 0011

La suite de la contribution :

Modélisation des diagrammes

d’activités UML

Annexe 01 – Compléments des diagrammes d’activités modélisés

100


A01.1. Diagramme d'activités du Budget PA et PMT élaboré par le département Maintenance (G)


101


A01.2. Diagramme d'activités du Budget PA et PMT élaboré par le département Technique (T)


102


A01.3. Diagramme d'activités du Budget PA et PMT élaboré par le département Sécurité Industrielle (I)


103


A01.4. Diagramme d'activités du Budget PA et PMT élaboré par le département Travaux Neufs (W)


104


A01.5. Diagramme d'activités du Budget PA et PMT élaboré par la Direction de l’unité, D*E et D*S


105


A01.6. Diagramme d'activités du Budget PA et PMT élaboré par le Service Relations du Travail (RT)


106


A01.7. Diagramme d'activités du Budget PA et PMT élaboré par le Conseil Syndical


107


A01.8. Diagramme d'activité du processus de validation des prévisions des stocks, d’achats et consommations des articles gérés en stock (A) du plan annuel et PMT


108


A01.9. Diagramme d'activité du processus de validation des prévisions d’achats et consommations pour les articles non gérés en stock (A) du plan annuel et PMT


109


A01.10. Diagramme d'activité du processus de validation des prévisions

consolidées d’achats et consommations pour les articles non gérés en stock (M) du plan annuel et PMT


110

A01.11. Diagramme d'activités du Budget PA et PMT élaboré par le département Passation des Marchés (PM)


111

A01.12. Diagramme d'activités du Budget PA et PMT élaboré par le département Approvisionnement (A)


112

A01.13. Diagramme d'activités du Budget PA et PMT élaboré par le département Moyens Généraux (M)


113

A01.14. Diagramme d'activités du Budget PA et PMT élaboré par le département Ressources Humaines (R)


114

A01.15. Diagramme d'activités du Budget PA et PMT élaboré par le département Administration et Social (S)


115

A01.16. Diagramme d'activités du Budget PA et PMT élaboré par le département Système d’information et de Gestion (SIG)


116

A01.17. Diagramme d'activités du Budget PA et PMT élaboré par l’Assistant Sûreté Interne (ASI)

AAnnnneexxee 0022

La suite de cahier de charges

Annexe 02 – Cahier de charges du projet d'informatisation du processus budgétaire au sein de l'Activité Aval - Oran

117


Sonatrach/Activité Aval

Direction Finances

Département Budget et Contrôle de Gestion

Projet de formalisation et

d’informatisation des processus

de gestion budgétaire et

reporting au sein de l’Activité

Aval/Sonatrach

Volets Exploitation et

Financement

Version 1.0


118


Sommaire

Eléments de cadrage du projet I) Etat des lieux par processus

1) Description du déroulement de la campagne budgétaire 1- Le lancement de la campagne budgétaire

2- L’élaboration des prévisions budgétaires : 3- Le Pré-arbitrage du projet de PA et PMT Unité

4- Le Pré-arbitrage du projet de PA et PMT Division

5- Arbitrage du projet de PA et PMT Activité Aval 6- Contrôle et consolidation du projet de PA et PMT et transmission à la DCGF/SH

7- Notification du Plan Annuel N+1 2) Supports de collecte de l’information concernant le plan annuel et PMT

2.1 Support interne à l’Unité

2.2 Canevas du Plan Annuel et PMT SONATRACH II) Objectifs généraux du projet par processus

1) Elaboration du budget et PMT afférents aux volets exploitation et financement 2) Elaboration des documents de Reporting afférents aux volets exploitation et

financement 3) Contrôle budgétaire

III) Procédure d’élaboration du plan annuel et PMT volet exploitation et financement 1- Processus d’élaboration du budget et PMT afférents aux volets exploitation:

1.1- Différents plans (plan annuel et PMT): 1.2- Types de budgets et PMT par structure et par fonction

1.3- Hiérarchisation des budgets et PMT

Eléments de cadrage du projet

1. Le projet concerne les volets Exploitation et financement, conformément aux missions dévolues à la Direction Finances en tant que structure consolidante de ces volets dans le cadre de l’élaboration du Plan Annuel et PMT, en respect de l’organisation en place,

2. Le projet devra tenir compte des interfaces à établir avec les autres volets à considérer dans d’élaboration du Plan Annuel et PMT afférents aux volets Flux et Investissements, relevant d’autres Structures de l’Activité Aval (EXP, MNT, TEC, PLS, RHU) pour des impératifs de cohérences,

3. Le projet touchera les processus suivants :

Elaboration du budget annuel pour les périodes clôture N, N+1 et les périodes du PMT (N+2, N+3, N+4 et N+5), conformément aux procédures en vigueur de Sonatrach,

Elaboration du reporting périodique sur le suivi d’exécution des budgets notifiés,

Contrôle budgétaire à priori. 4. Le périmètre d’intervention du projet concerne les unités opérationnelles et les structures

fonctionnelles de l’Activité Aval.


119


I) Etat des lieux par processus

1) Description du déroulement de la campagne budgétaire

Le processus d'élaboration du Plan Annuel et PMT, s’étend d’avril de l’année N à janvier de l’année N+1. Ce processus est constitué de sept grandes étapes (cf. schéma n°1) :

1. Le lancement de la campagne budgétaire 2. L’élaboration des prévisions budgétaires Le Pré-arbitrage du projet de PA et PMT Unité 3. Le Pré-Arbitrage du projet de PA et PMT Division 4. L’arbitrage du projet de PA et PMT Activité Aval 5. Contrôle et consolidation du projet de PA et PMT et transmission à la DCGF/SH 6. Notification du budget N+1

1-Le lancement de la campagne budgétaire

Le lancement officiel de la campagne budgétaire s’effectue généralement le mois d’Avril de l’année N, après l’achèvement des travaux de bilan N-1. A l’initiative du Département finances, une note signée par le Directeur est envoyée aux différentes structures de l’Unité pour leur signifier le début des travaux ainsi que l’échéance retenue pour la transmission des supports de collectes dûment renseignés par leurs soins. Cette note est accompagnée d’une synthèse de la directive cadre du précèdent plan annuel et du planning des réunions de préparation et validation internes à l’Unité, en attendant la diffusion par l’Activité Aval de la Directive cadre du nouveau Plan Annuel et PMT. La note définit les différents axes et orientations pour l’élaboration des prévisions dans le respect des directives et politiques en vigueur au sein de l’Activité dans les différents domaines. La note transmise aux différentes structures est également accompagnée de supports de collecte de prévisions confectionnés par les services de l’Unité. Il est à signaler que la Directive cadre diffusée par l’Activité Aval, en attendant la note d’orientation générale vulgarisée par la Direction Générale de Sonatrach est accompagnée des hypothèses d’entrée et normes afférentes, principalement à :

La parité des principales Devises par rapport au Dinar à considérer pour les opérations libellées en Devises,

Le taux d’inflation,

2- L’élaboration des prévisions budgétaires :

Chaque structure élabore et transmets ses prévisions, en tenant compte des principes suivants :

Adéquation entre les prévisions et les objectifs ciblés,

Analyse quantitative et qualitative des prévisions,

Justification de l’opportunité de chaque opération,

Maturation de chaque opération, par rapport au processus de passation de marchés (existence de cahier des charges), Chaque poste budgétaire inscrit sur le support des charges de la structure est expliqué avec

le maximum de détails, pour permettre aux services financiers de l’Unité de fournir les explications nécessaires lors des présentations des projets de PA et PMT pour pré-arbitrage. Une fois toutes les prévisions de toutes les structures transmises au département finances et avant l’entame de l’opération de consolidation par ce dernier,des réunions sont tenues avec les structures concernées,afin de corriger les éventuelles erreurs ou incohérences.


120


3- Le Pré-arbitrage du projet de PA et PMT Unité

Après les réunions avec les différentes structures, le pré-arbitrage en interne à l’Unité est présidé par le Directeur, en présence de tous les responsables des départements, y compris le chef département Finances, secondé par le service informations de gestion qui aura à charge de noter toutes les orientations du Directeur et veiller à ce qu’elles soient portées sur le PV de réunion. Lors de cette séance de pré arbitrage, les prévisions budgétaires consolidées de l’Unité concernant le volet exploitation sont soumises à l’examen et la validation de la Direction, compte tenu des différents plans d’actions, parmi lesquels :

Plan de production,

Plan de maintenance,

Plan d’investissement,

Plan formation, effectifs, salaires,

Prévision des charges, A l’issu de ce pré-arbitrage, des corrections et actualisations sont portées sur le projet du plan annuel et PMT exploitation de l’Unité. Sur la base du plan annuel et PMT exploitation, ainsi validé par le Directeur de l’Unité, une synthèse est élaborée pour les besoins de l’opération de pré-arbitrage par le niveau hiérarchique supérieur.

4- Le Pré-arbitrage du projet de PA et PMT Division

Le plan annuel et PMT validé par le Directeur de l’Unité est présenté par ce dernier au Directeur de la Division, en présence des directeurs centraux TEC, MNT, EXP, PLS, FIN, RHU, ISI. Ce pré-arbitrage concerne toutes les unités relevant de la Division et se fait suivant un planning arrêté. Les volets examinés lors de ces séances de pré -arbitrage sont synthétisés comme suit :

Plan de production,

Plan de maintenance,

Plan d’investissement,

Prévisions des charges d’exploitation,

Prévisions de coût de process, de coût de maintenance, de coût de sécurité,

Evolution prévisionnelle des stocks de matières et fournitures. Les décisions prises et orientations données lors de ces réunions sont consignées sur un Procès Verbal et donneront lieu à des corrections et actualisations que l’Unité portera sur son plan annuel et PMT, avant de le remettre aux directions centrales concernées qui procèderont aux consolidations requises par volets, aux fins de présentation à l’arbitrage par Monsieur le Vice-Président en CCA (Comité de Coordination de l’Activité).

5-Arbitrage du projet de PA et PMT Activité Aval

L’arbitrage du Plan Annuel et PMT de l’Activité Aval se fait en CCA par Monsieur le Vice-président, en présence de tous les responsables de Structures qui présentent les grands objectifs retenus, aussi bien en matière d’exploitation que d’investissement pour l’exercice budgétaire suivant et sur le Plan à Moyen Terme. Lors de cet arbitrage, d’ultimes orientations et directives sont données par Monsieur le Vice-président, notamment pour les opérations dont l’importance requiert sa décision. Lesdites orientations et directives sont consignées dans un Procès Verbal et donneront lieu aux derniers ajustements et actualisations par les unités, avant que les Structures Centrales ne procèdent à la consolidation finale du Plan Annuel et PMT, chacune pour le volet dont elle est chargée. A cette étape, la Direction Finances/Aval se charge de la consolidation du volet Exploitation et financement.


121


6-Contrôle et consolidation du projet de PA et PMT et transmission à la DCGF/SH

Après l’arbitrage et l’adoption du Plan Annuel et PMT de l’Activité en CCA, toutes les Unités procèdent à la saisie des dernières corrections et actualisations sur les canevas du volet Exploitation et financement, avant de les transmettre aux services concernés de la Direction Finances/Aval. Ces derniers, après vérification de cohérences et contrôle de l’état de saisie des informations sur les canevas appropriés, procèdent à la consolidation et la transmission des documents des Unités, par courrier électronique, aux services concernés de la Direction Générale Sonatrach (DCGF/SH). Les travaux de consolidation portent, entre autres, sur:

Vérification des saisies,

Vérification de l’application des décisions prises lors du pré-arbitrage Division et arbitrage CCA,

Contrôle de cohérences avec les autres volets,

Rapprochement des opérations inter unités,

Rapprochement des paiements pour compte dans le budget de financement d’exploitation.

7-Notification du Plan Annuel N+1

En début janvier de l'année N+1, la DCG FIN procède à l’élaboration des décisions d’exécution du Plan Annuel de l’année N+1 pour les volets Budget d’Exploitation et Plan de Financement dans le respect du Plan consolidé approuvé par les Organes Sociaux de Sonatrach SPA et les soumettent à la signature du président Directeur Général. La notification est transmise, généralement, en janvier de l’année n+1. Elle a valeur d’autorisation budgétaire et marque le début d'exécution du Plan Annuel au sein des unités opérationnelles. Les sept étapes sont synthétisées dans le schéma ci-dessous :

Schéma 1 : Les grandes étapes du processus d’élaboration du PA et PMT.

Directive cadre d’élaboration du PA et PMT et Lancement de la campagne budgétaire

Pré arbitrage du PA et PMT au niveau des Divisions

Notification du Plan Annuel N+1

Avril N

Juin à Juillet

N

Janvier N+1

Principales étapes

Elaboration du PA et PMT

Validation au niveau Unité

Arbitrage du PA et PMT au niveau du CCA

Transmission du PA et PMT consolidé AVAL à la DCGF/SH

Septembre N

Octobre N


122


2) Supports de collecte de l’information concernant le plan annuel et PMT Ces supports sont à classer en deux (02) grandes catégories :

Supports de collecte des prévisions internes à l’Unité,

Canevas du Plan Annuel et PMT Sonatrach. 2.1 Support interne à l’Unité Il s’agit de tableaux Excel transmis par messagerie par le Département Finances à toutes les autres Structures de l’Unité, afin d’y renseigner leurs besoins prévisionnels en matière de budget de fonctionnement pour les exercices à venir en fonction des objectifs opérationnels inscrits sur le PMT. A titre d’exemple, le canevas utilisé au niveau du complexe GL2Z est donné en annexe n°1. 2.2 Canevas du Plan Annuel et PMT SONATRACH Le canevas du Plan Annuel et PMT, se présentant sous forme de tableaux Excel, est celui arrêté par les services de la Direction Générale Sonatrach (DCGF) et que chaque Unité se doit de respecter pour communiquer ses prévisions budgétaires dans le but de les consolider et de les notifier. Il existe deux types de canevas de saisie destinés aux services de la DCGF/Sonatrach, selon le volet concerné : canevas du volet Exploitation et canevas du volet Financement des Investissements. 2.2.1 Canevas du volet Exploitation Le canevas se présente sous forme de tableaux Excel, indiquant pour la plus part :

1. Les montants réalisés de l’exercice N-1, 2. Les prévisions de clôture N, 3. Les prévisions de l’exercice budgétaire N+1 (à notifier), 4. Les prévisions sur le PMT.

Selon leur contenu, ces tableaux sont classés comme suit : 1. Tableaux des Comptes de Résultats prévisionnels, 2. Tableaux des prévisions de charges d’exploitation, 3. Tableaux des prévisions de produits d’exploitation, 4. Tableaux des prévisions de coûts de maintenance, 5. Tableaux des prévisions de coûts de sécurité industrielle, 6. Tableaux des prévisions de coûts de sûreté interne, 7. Tableaux des prévisions de charges investies, 8. Tableaux des prévisions de coûts de processing ou de production, 9. Tableaux des prévisions de stocks de matières et fournitures, 10. Tableaux des prévisions de financement d’exploitation

2.2.2 Canevas du volet Financement des Investissements Sous forme d’une macro Excel, ce fichier permet la saisie, pour chaque opération d’investissement :

a) Les prévisions physiques valorisées, étalées sur les périodes du Plan Annuel et PMT, mettant en exergue :

La source de financement (interne et/ou externe),

La partie en biens et la partie en services de la prévision

Les parties en Dinars et en Devises de la prévision, b) La prévision d’autofinancement pour l’exercice N+1 à notifier et mettant en exergue :

La partie en biens et la partie en services de la prévision

La partie en Dinars et en Devises de la prévision, La somme de toutes les prévisions d’autofinancement de l’exercice N+1 constitue le budget de décaissement des Investissements de l’Unité, à notifier, pour cet exercice. II)Objectifs généraux du projet par processus 1) Elaboration du budget et PMT afférents aux volets exploitation et financement

1. Formalisation et uniformisation d’une procédure. 2. Automatisation de la collecte des prévisions, des mises à jour et consolidation au niveau Unité. 3. Automatisation des mises à jour et consolidation au niveau central.


123


4. Etablissement des prévisions par centre de coût et/ou par centre de responsabilité budgétaire, par nature et par mois pour les périodes N et N+1.

5. Amélioration de la fiabilité des prévisions budgétaires par la mise en place de paramétrages entre objectifs opérationnels et prévisions de consommation de biens et de services.

6. Instauration d’un système de validation des prévisions budgétaires (CC, CRB, Unité, Division, Activité).

7. Etablissement des coûts d’exploitation prévisionnels par fonction (voir résultats projet CAE pour intégration).

8. Etablissement d’une hiérarchisation et interdépendance des budgets (production, investissement, charges par fonction, achats…).

9. Traitement et rapprochements automatisés des opérations inter-unités (prestations, PPC). 10. Modèle de présentation uniforme pour arbitrages.

2) Elaboration des documents de Reporting afférents aux volets exploitation et financement

1. Formalisation et uniformisation d’une procédure. 2. Automatisation du report des réalisations périodiques sur les canevas à partir des bases de

données existantes (CAE, CPT Gle, trésorerie). 3. Identification et explication des écarts par centre de coût. 4. Automatisation de la consolidation au niveau central (Direction Finances). 5. Mise en place de tableaux de bord pour suivi d’indicateurs clés de performance à identifier

3) Contrôle budgétaire

- Formalisation et uniformisation d’une procédure de contrôle et de suivi d’exécution des budgets, par CC et/ou CRB. Ce contrôle à priori concerne, notamment :

Le budget d’approvisionnements, c’est-à-dire les sommes prévues d’être payées aux fournisseurs de biens,

Le budget des services, c’est-à-dire les sommes prévues d’être payées aux fournisseurs de services,

Le budget des investissements, c’est-à-dire les sommes prévues d’être payées aux fournisseurs d’investissements,

- Formalisation et uniformisation d’une procédure.

III) Procédure d’élaboration du plan annuel et PMT volet exploitation et financement La procédure est basée sur la notion du « qui fait quoi », compte tenu :

Des différents Plans existant et qui sont déterminants dans le processus d’élaboration des prévisions budgétaires et PMT,

De l’Organisation en place, aussi bien au niveau opérationnel que fonctionnel. 1-Processus d’élaboration du budget et PMT afférents aux volets exploitation:

1.1- Différents plans (plan annuel et PMT): Il s’agit des plans préalablement élaborés reflétant les différents objectifs opérationnels inscrits sur les PMT(s). Parmi ces plans, il est cité :

Plan de production,

Plan de maintenance

Plan de formation

Plan de recrutement

Plan HSE

Plan d’investissements

Plan d’approvisionnements

Plan de passation de marchés


124


Plan de ventes des biens et services

Plan de mission 1.2- Types de budgets et PMT par structure et par fonction Les types de budgets sont calqués sur l’organisation en place au niveau opérationnel et fonctionnel, en respect des missions dévolues aux différents acteurs intervenants dans le processus d’élaboration des prévisions dans le cadre de la campagne budgétaire. A titre d’exemple, l’organisation commune en place au sein d’une Unité opérationnelle de la Division LQS se décline comme suit :

Département production

Département maintenance

Département approvisionnements

Département Administration et sociale

Département DRH

Département moyens généraux

Département technique

Département travaux neufs

Département sécurité industrielle

Département finances

sûreté interne (assistant)

Département système d’information et de gestion

relations du travail (service)

Département passation des marchés

sous direction exploitation D*E

sous direction personnel D*S

conseil syndical

Il est à relever que les Structures fonctionnelles de l’Activité Aval élaborent également leurs prévisions budgétaires qui sont consolidées au niveau de la Direction Administration Générale/Aval en tant qu’Unité comptable et budgétaire du Siège/Aval. Ces Structures fonctionnelles sont également impliquées dans le processus d’élaboration du Plan Annuel et PMT des Unités opérationnelles dans son volet Exploitation en tant que Structures consolidantes, chacune dans son domaine.


125


1.3- Hiérarchisation des budgets et PMT Les différents budgets élaborés par les structures de l’Unité, conformément à l’organisation en place, se déclinent ci-dessous avec identification du « qui fait quoi » en fonction des missions dévolues à chacune d’elles. 1) Budget élaboré par le Département Production (P)

Objectif : budget exprimant les consommations en matières premières nécessaires à l’atteinte des objectifs de production arrêtés et les moyens de fonctionnement internes à la structure.

a) Budget et PMT de la fonction production: - Acteurs impliqués : Direction Exploitation LQS, D*E, P, G et A unité. - Informations exploitées (input) :

Plans : plan de production

Paramètres de consommations en volume : produits chimiques (tamis moléculaires, inhibiteur de corrosion…) énergies (électricité, utilités, eau, gaz naturel autoconsommé, gaz

industriels) lubrifiants carburants

- Prévisions de prestations de services : redevances d’occupations terre plein et plan d’eau « STH »

c) Budget et PMT de fonctionnements de la structure P : - Fournitures consommées (non régies par une norme) : Produits sociaux, outillages,

consommation de fournitures diverses et produits de fonctionnement, fournitures de bureaux spécifiques, consommables informatiques…



Action/ Description Destinataire Observation / support

EXP et dép. P

Projet de Plan de production Plan de production

(annexe)

Dép. P

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) de consommation de : Matières et fournitures gérées en stock liées à la

production (quantitatifs selon paramétrages) Matières et fournitures pour fonctionnements non

régies par une norme, non gérées en stock et liées à la production (prévisions quantitatives)

Matières et fournitures pour fonctionnements non régies par une norme, non gérées en stock et non liées à la production (prévisions quantitatives)

Energies (prévisions valorisées) Elaboration et transmission des prévisions quantitatives de missions pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Dép. A Dép. A Dép. M Dép. F Dép. M Dép. F

Pour prise en compte dans le budget achat A (annexe) Pour compléter budget achat A (annexe) Pour compléter budget achat M (annexe) Pour intégration dans le budget trésorerie Annexe Etat des missions détaillé (annexe) - Pour intégration dans le budget trésorerie


126


2) Budget élaboré par le Département de la Maintenance (G) Objectif : budget exprimant les consommations en matières et fournitures (PDR et consommables) et

services nécessaires à la réalisation du plan de maintenance de l’Unité et les moyens de fonctionnement internes à la structure.

a) Budget et PMT de la fonction maintenance : - Acteurs impliqués : MNT et EXP/LQS, D*E, G, P, A, M et T unité. - Informations exploitées (input) :

Plans : plan de maintenance (planning des arrêts), plan d’investissement IMFS

Paramètres de consommations en volume : - PDR pour matériels, fournitures électriques, petit outillage, matériaux de

construction… - produits chimiques - gaz industriels - lubrifiants

- Prévisions de prestations de services : contrats de prestations (diverses prestations de maintenance, réparations…)

- Description des opérations par contrat, convention et par nature (peinture des installations et bâtiments, re-bobinages, location de matériels et engins, …)

b) Budget de fonctionnements de la structure G : - Fournitures consommées (non régies par une norme) : Produits sociaux, outillages,

consommation de fournitures diverses et produits de fonctionnement, fournitures de bureaux, consommables informatiques…



Action / Description Destinataire Observation / support

Dép. G, Dép. P Dép. T, Dép. A,

MNT et EXP Projet de Plan de maintenance

Plan de maintenance (annexe)

Dép. G

Elaboration et transmission des prévisions quantitatives de consommation de fournitures PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

PDR et Matières et fournitures gérées en stock liées à la maintenance préventive (quantitatifs selon paramétrages)

PDR et Matières et fournitures non gérées en stock liées à la maintenance préventive

Matières et fournitures pour fonctionnement non régies par une norme non gérées en stock et non liées à la production

Elaboration et transmission des prévisions quantitatives de missions pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration et transmission des prévisions valorisées de prestation de services PA (par mois pour N et N+1) et PMT (de N+2 à N+5) liées a la maintenance

Dép. A Dép. A Dép. M Dép. M Dép. F

Pour prise en compte dans le budget achat A. Pour compléter budget achat A (annexe) Pour compléter budget achat M (annexe) Etat des missions détaillé (annexe) -Prestations contractuelles (annexe) -Pour prise en compte dans le budget trésorerie


127


3) Budget élaboré par le Département des Approvisionnements (A)

Objectif : Le budget des approvisionnements a pour objectif d’arrêter pour les structures, de l’Unité les niveaux des matières et fournitures à acquérir, compte tenu de leurs consommations prévisionnelles, du stock existant et du niveau du stock de sécurité, par article.

Le Département A prévoit également ses besoins dans le cadre de son fonctionnement. a) Budget et PMT de la fonction approvisionnements :

- Acteurs impliqués : P, G, T, I et W - Informations exploitées (input) :

Prévisions de consommations des structures P, G, T, I et W en matières et fournitures gérées en stock en quantités.

Politique de réapprovisionnement (stocks de sécurité en quantités).

Stocks existants en quantités.

Table des prix : coûts unitaires d’achat (décomposés en prix d’achat et frais d’approche) et les coûts unitaires moyens pondérés (CUMP)

- Prévisions de dotations aux provisions pour dépréciation des stocks b) Budget de fonctionnements de la structure A :

- Fournitures consommées (non régies par une norme) : Produits sociaux, articles consommables (PDR matériels roulants et de levages, fournitures électriques, outillages,….), fournitures de bureaux, …




Dép. P Dép. G Dép. T Dép. I Dép. W

Plan des prévisions des consommations des articles gérés et non gérés en stock en quantités.

Dép. A

Annexe pour Dép. P et Dép. G Dép. T Dép. I Dép. W

Dép. A

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) :

Prévisions consolidées d’achats (entrées stock) en Dinars et Devises et consommations (sorties stock) pour les articles gérés en stock (A) (prévisions valorisées)

Prévisions consolidées (Unité) des achats en Dinars et Devises pour les articles non gérés en stock (A) : consommations directes (prévisions valorisées)

Matières et fournitures pour fonctionnement A non régies par une norme (prévisions quantitatives)

Dotations aux provisions pour dépréciation des stocks gérés par A (prévisions valorisées)

Elaboration et transmission des prévisions quantitatives de prestation de services (missions) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Dép. F Dép. F Dép. M Dép. F Dép. M

Pour prise en compte dans la consolidation des charges et dans le budget trésorerie (Annexe). Pour prise en compte dans la consolidation des charges et dans le budget trésorerie . Pour compléter budget achat M (annexe). Pour prise en compte dans la consolidation des charges. Etat des missions détaillé (annexe) .


128


4) Budget élaboré par le Département des moyens généraux (M) Objectif : le budget des moyens généraux a pour objectif de mettre à la disposition de l’unité et de

ses structures les matières, fournitures et services nécessaires à leur fonctionnement. a) Budget et PMT de la fonction moyens généraux :

- Acteurs impliqués : toutes les structures - Informations exploitées (input) :

Les normes de consommations en quantités, par structure, concernant les matières et fournitures gérées en stock.

Les normes afférentes aux prestations de services (liées au paramètre effectif ou autres normes).

Manuel EIP.

Politique de gestion des stocks.

Table des prix : coûts unitaires d’achat et les coûts unitaires moyens pondérés (CUMP)

Liste du nombre prévisionnel d’enfants des bases de SONATRACH concernés par le transport scolaire et universitaire.

Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives. - Informations (output)

Budget des consommations consolidés Unité et des achats valorisés pour les matières et fournitures.

Budget des prestations de services valorisé consolidé Unité (transport du personnel, restauration, hygiène, désherbage, entretien espaces verts, maintenance des véhicules, maintenances des appareils, contrôle technique, …)

Liste du nombre prévisionnel d’enfants des bases de SONATRACH concernés par le transport scolaire et universitaire à transmettre à DAG/MOG.

Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives à transmettre à DAG/HR.

- Prévisions de dotations aux provisions pour dépréciation des stocks - Prévisions taxes liées au parc roulant (vignettes et divers timbres)

b) Budget de fonctionnements de la structure M : - Fournitures consommées (non régies par une norme) : Produits sociaux, articles

consommables, fournitures électriques, outillages,…. - Prestations de services : Nombre des missions par destinations.


Action / Description Destinataire Observation / projection / support

Toutes les structures

Plan de prévisions quantitatives des consommations des articles non gérés en stock et non régie par une norme (par mois pour N et N+1) et PMT (de N+2 à N+5) pour valorisation par M

Dép. M

Dép. M

-Elaboration et transmission des prévisions valorisées et consolidées PA (par mois pour N et N+1) et PMT (de N+2 à N+5) :

Prévisions consolidées d’achats (entrées stock) et consommations (sorties stock) pour les articles régies par une norme et gérées en stock (M)

Prévisions consolidées (Unité) d’achats des matières et fournitures non régies par une norme et non gérées en stock (prévisions valorisées)

Prévisions consolidées (Unité) de missions des structures de l’Unité et les missions de formations

Prestations de services

Taxes parc automobile

Dép. F Dép. F Dép. F

Dép. F

Pour prise en compte dans la consolidation des charges et dans le budget trésorerie Pour prise en compte dans la consolidation des charges et dans le budget trésorerie Etat des missions et de formations détaillé par structure (annexe)

Pour prise en compte dans la


129


5) Budget du département ressources humaines (R)

Objectif: le budget du département ressources humaines a pour objectif de valoriser les prévisions de formation et les taxes y afférentes (formation et apprentissage), retenues dans le plan emploi, salaires et formation de l’Unité. Par ailleurs, le département R élabore le plan des effectifs (départ/recrutement) de l’Unité par corps de métiers.

a) Budget et PMT de la fonction R - Acteurs impliqués : R, RHU/Aval - Informations exploitées (input) :

Plan de formation

Prix unitaires des formations et séminaires

Besoins organigramme de l’Unité

Plan des départs en retraite. - Informations (output)

Budget et PMT de prestations de formation externe et inter/unité SH valorisé.

Budget des taxes de formation.

Plan des effectifs (départs/recrutements). - Fournitures consommées en quantités liées à la formation sur site (non régies par une

norme) : Produits sociaux, articles consommables, fournitures de bureaux. - Prestations de services : Nombre des missions pour formations par destinations

consolidé. b) Budget de fonctionnements de la structure R :

- Prestations de services : Nombre des missions par destinations. Acteur /

Intervenant Action / Description Destinataire Observation / support

RHU/Aval et Dép. R

Plan de Formation arbitré

Dép. R

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) :

Budget et PMT de prestations de formation externe et inter/unité SH valorisé.

Budget des taxes de formation valorisé Fournitures consommées en quantités

liées à la formation sur site (non régie par une norme)

Nombre des missions pour formations par destinations consolidées

Nombre des missions de R par destinations

Dép. F Dép. F Dép. M Dép. M Dép. M

Pour prise en compte dans le budget trésorerie et /ou charges inter/unité Pour prise en compte dans le budget trésorerie Pour compléter budget achat M (annexe x) Etat des missions de formations détaillé (annexe x) Etat des missions détaillé (annexe)

6) Budget du département administration et social (S)

Objectif: le budget du département administration et social a pour objectif d’élaborer les prévisions de la masse salariale sur le plan annuel et PMT de l’Unité décliné par structures et par rubriques.

a) Budget et PMT de la fonction S : - Acteurs impliqués : R, S et RHU/Aval

Dotations aux provisions pour dépréciation des stocks gérés par M (prévisions valorisées)

-Transmission de la liste du nombre prévisionnel d’enfants des bases de SONATRACH concernés par le transport scolaire et universitaire - Transmission de la liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives.

Dép. F Dép. F DAG/MOG DAG/MOG

consolidation des charges Prestations contractuelles (annexe) Annexe Pour valorisation et transmission a DAG/FJ qui transmettra aux F Unités Pour valorisation et transmission a DAG/FJ qui transmettra aux F Unités


130



Plan des effectifs (Départs/Recrutements)

Besoins organigramme de l’Unité

Norme de la masse salariale RHU/Aval. - Informations (output)

Prévisions de salaires et charges patronales valorisées.

Prévisions AFC, STC et gratification médailles.

Liste du nombre prévisionnel d’enfants des bases de SONATRACH concernés par le transport scolaire et universitaire.

Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives. - Fournitures consommées : (non régies par une norme) : Produits sociaux (articles de

literie, ….), outillage médical et produits pharmaceutiques (inter- unités OSL). - Prestations de services :

consultations médicales spécialisées (inter- unités OSL). b) Budget de fonctionnements de la structure S :

- Prestations de services :

Entretiens et réparations matériels centre médical (inter- unités OSL).

Nombre des missions par destinations.



RHU/Aval, Dép.R et Dép.S

Plan des effectifs (départs/recrutements)

Dép. S

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) : Salaires, charges patronales, AFC, STC et

gratification médailles valorisées. Fournitures consommées en quantités, non

gérée en stock et non régie par une norme Outillage médical et produits

pharmaceutiques valorisés Prestations services valorisées

(Entretiens et réparations matériels et consultations médicales spécialisées)

Nombre des missions de S par destinations. Liste du nombre prévisionnel d’enfants des

bases de SONATRACH concernés par le transport scolaire et universitaire.

Liste du nombre prévisionnel d’agents concernés par les loyers et charges locatives

Dép. F Dép. M Dép. F

Dép. F Dép. M Dép. M Dép. M

Pour prise en compte dans le budget trésorerie . Pour compléter budget achat M (annexe).

Pour prise en compte dans le budget des charges (inter- unités OSL). Pour prise en compte dans le budget des charges (inter- unités OSL). Etat des missions détaillé (annexe). Liste nominative . Liste nominative.

7) Budget élaboré par le Département du département technique (T) Objectif : Le budget du département technique a pour objectif d’élaborer les prévisions de

consommations des matières et fournitures et de prestations de services nécessaires dans le cadre du respect des normes réglementaires pour la bonne exploitation de l’appareil de production.

a) Budget et PMT de la fonction technique:

- Acteurs impliqués : T, G, P, A et M unité. - Informations exploitées (input):

Normes réglementaires

Planning des visites réglementées - Prévisions de consommation des matières et fournitures:

Produits chimiques


131


Gaz industriels

Consommables (pour système DCS, laboratoire)

Petits outillages - Prévisions de prestations de services :

Contrôle technique réglementaire

Contrôle destructif et non destructif (test ultrason, radiographie, ressayage, ….)

Expertise pour les dérogations APV/APG

Etudes diverses

Mise à jour du système DCS (logiciels, formations, ….) b) Budget et PMT de fonctionnement de la structure T :

- Fournitures consommées (non régies par une norme) : produits sociaux, outillages de laboratoire et inspection

- Prestations de services : - Nombre des missions par destinations.

8) Budget élaboré par le Département de sécurité industrielle I Objectif : Le budget du département sécurité industrielle a pour objectif d’élaborer les prévisions

de consommations des matières et fournitures et de prestations de services nécessaires à la sécurisation de l’Unité et de minimiser les risques liés à l’utilisation des moyens matériels (outillages, installations technique et matériels roulants).

a) Budget et PMT de la fonction: - Acteurs impliqués : I et toutes les structures de l’Unité. - Informations exploitées (input) :

Plan HSE

Manuel EPI (Equipement de Protection Individuelle)

Recommandations issues des audits - Prévisions de consommation des matières et fournitures:

produits chimiques

gaz industriels

PDR (pour matériels de sécurité)

Outillages de sécurité

EPI spécifiques à la sécurité industriel non régis par le manuel. - Prévisions de prestations de services :

Gestion des déchets

Redevance ARPT,

Réparation des radios.

Cadastre des sites et sols pollués

Etalonnage/calibrage b) Budget et PMT de fonctionnements de la structure :



Dép. T

Elaboration et transmission des prévisions quantitatives PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Matières et fournitures gérées et non gérées en stock

Matières et fournitures pour fonctionnements non régies par une norme, non gérées en stock

Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Nombre des missions de T par destinations

Dép. A Dép. M Dép. F Dép. M

Pour prise en compte dans le budget achat A (annexe) Pour compléter budget achat M (annexe) Pour intégration dans le budget trésorerie (annexe) Etat des missions détaillé (annexe)


132


- Fournitures consommées (non régies par une norme) : Produits sociaux, consommations de fournitures.


Nombre des missions par destinations.

Acteur / Intervenant Action / Description Destinataire Observation / support I, HSE/AVL, toutes les structures

Plan HSE et Recommandations issues des audits

Dép. I

Elaboration et transmission des prévisions quantitatives PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Matières et fournitures gérées et non gérées en stock

Matières et fournitures pour fonctionnements non régies par une norme, non gérées en stock

Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Nombre des missions de I par destinations

Dép. A Dép. M Dép. F Dép. M

Pour prise en compte dans le budget achat A (annexe) Pour compléter budget achat M (annexe) Pour intégration dans le budget trésorerie (Annexe)

Etat des missions détaillé (annexe )

9) Budget élaboré par le Département Travaux Neufs W

Objectif : budget exprimant les prévisions de prestations de services et consommations de fournitures nécessaires pour la prise en charge des programmes d’investissements qu’ils soient liés ou non liés à la production (ILP ou INLP).

a) Budget et PMT de la fonction travaux neufs : - Acteurs impliqués : W et toutes les structures de l’Unité. - Informations exploitées (input) :

Listing des investissements inscrit au Plan annuel et PMTE impliquant W.

Planning des arrêts de maintenance

Conventions (barème des prix, objet de la/les conventions) - Prévisions de prestations de services :

Mise à disposition de personnel dans le cadre des conventions

Expertise et contrôle en génie civil dans le cadre des conventions et contrats

Locations (moyens de transport, de levage et de manutention)

Etudes de génie civil. b) Budget et PMT de fonctionnements de la structure W :

- Fournitures consommées (non régies par une norme) : Produits sociaux, consommations de fournitures (outillages, appareils de mesure et consommables spécifiques).


Nombre des missions par destinations. Acteur /

Intervenant Action/ Description Destinataire Observation/support

Toutes les structures de l’Unité

Listing des investissements inscrit au Plan annuel et PMTE impliquant W

Dép. W

- Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) des consommations de matières et fournitures pour fonctionnement non régies par une norme et non gérées en stock (prévisions quantitatives)

- Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

- Nombre des missions de W par destinations

Dép. M et/ou Dép. A Dép. F Dép. M

Pour compléter budget achat M et/ou A (annexe ) Pour intégration dans le budget de trésorerie Etat des missions

détaillé (annexe)


133


10) Budget élaboré par le Département Système d’Information et de Gestion (SIG)

Objectif : le budget du département système d’information et de gestion a pour objectif de déterminer les prévisions en matières et fournitures et prestations permettant à la structure de réaliser ses missions (INF-ORG-QHSE).

a) Budget et PMT liés aux fonctions

- Acteurs impliqués : SIG et toutes les structures de l’Unité. - Informations exploitées (input) :

Prévisions quantitatives des consommations de fournitures et consommables informatiques des structures de l’Unité non régies par une norme

Les normes de consommations quantitatives en fournitures et consommables informatiques

QHSE (certification, ….) - Prévisions quantitatives consolidées des consommations de fournitures et consommables

informatiques régies et non régies par une norme et gérées en stock. - Prévisions quantitatives consolidées des consommations de fournitures et consommables

informatiques non régies par une norme et non gérées en stock. - Expression des besoins de prestations services à transmettre à la direction ISI (mises à

jour,…….). - Prévisions de prestations de services :

Les frais de télécommunications

Réparations et maintenances des matériels et équipements informatiques et télécommunications.

Documentations (Papiers ou électroniques) b) Budget et PMT de fonctionnement de la structure:

- Fournitures consommées (non régie par une norme): petit outillages, produits sociaux,…………

- Prestations de services : - Nombre des missions par destinations.

Acteur /

Intervenant Action/ Description Destinataire Observation / support


Prévisions quantitatives des consommations de fournitures et consommables informatiques non régies par une norme

SIG

SIG

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Prévisions consolidées Unité consommations de fournitures et consommables informatiques régies et non régies par une norme gérées en stock (prévisions quantitatives)

Prévisions consolidées Unité consommations de fournitures et consommables informatiques non régies par une norme et non gérées en stock (prévisions quantitatives)

Prévisions de consommations de matières et fournitures pour fonctionnement non régies par une norme et non gérées en stock (prévisions quantitatives)

Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Nombre des missions par destinations

Dép. M Dép. M Dép. M Dép. F Dép. M

Pour compléter budget achat M (annexe) et valoriser les consommations Pour compléter budget achat Pour compléter budget achat Pour intégration dans le budget de trésorerie Annexe Etat des missions détaillé


134


11) Budget élaboré par le département Passation des Marchés :

Objectif : Le budget du département passation des marches a pour objectif d’élaborer, principalement, les prévisions en matières et fournitures et prestations de services induites par le processus de passation des marchés de l’Unité.

a) Budget et PMT de la fonction passation des marchés: - Acteurs impliqués : Département PM et toutes les structures de l’Unité - informations exploitées (input) :

plan de passation de marchés par Structure -Informations (output)

Prévisions de prestations de services : liées principalement à la publication des appels d’offres

b) Budget de fonctionnement et PMT de la structure PM : - Fournitures consommées (non régies par une normes) : Produits sociaux, -Prestations de services : Nombre des missions par destinations.

c) Prévisions de recettes liées aux retraits des cahiers de charges.

12) Budget élaboré par la Direction de l’Unité, D*E et D*S :

Objectif : budget exprimant les prévisions de consommations de fournitures et de services liées aux postes, pour un fonctionnement normal.

- Acteurs impliqués : Directeur, Sous directeur Exploitation et Sous directeur Personnel

Budget de fonctionnement et PMT : - Fournitures consommées (non régie par une norme) : Produits sociaux, consommation de

fournitures diverses et fournitures de bureaux, - Prestations de services : Nombre des missions par destinations.



Toutes les structures de l’Unité

Plan de passation de marchés Dép. PM

Dép. PM

Elaboration des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration des prévisions consolidées de recettes liées aux retraits des cahiers de charges. Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) de consommation de fournitures non régies par une norme, non gérées en stock (prévisions quantitatives) Elaboration et transmission des prévisions quantitatives de missions pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Dép. F Dép. F Dép. M Dép. M

Pour intégration dans le budget de trésorerie Annexe. Pour prise en compte dans les prévisions de produits d’exploitation. Pour compléter budget achat M (annexe 2) Etat des missions détaillé (annexe 3)



D/Unité D*E D*S

Elaboration et transmission des prévisions de consommations fournitures pour fonctionnement non régies par une norme et non gérées en stock (prévisions quantitatives) PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Nombre des missions par destinations

Dép. M Dép. M

Pour compléter budget achat (annexe) et valoriser les consommations Etat des missions détaillé (annexe)


135


13) Budget élaboré par l’Assistant Sûreté Interne ASI Objectif : budget exprimant les prévisions de consommations de fournitures et prestations de

services, dans le cadre de l’accomplissement des missions de cette Structure. a) Budget et PMT de la fonction

- Acteurs impliqués : toutes les structures - Informations exploitées (input) :

Nombre de personnel et sous-traitants ouvrant droit à l’accès aux différentes zones (port, zones industrielles, …)

- Prévisions de consommation des fournitures: Ports badges Badges

- Prévisions de prestations de services : Confection badges –impression- (interne et externe) Contrat gardiennage Escorte

b) Budget de fonctionnements et PMT:

- Fournitures consommées (non régie par une norme) : Produits sociaux, consommation de fournitures diverses et fournitures de bureaux.





Nombre de personnel et sous traitants ouvrant droit à l’accès aux différentes zones

ASI

ASI

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) de consommation de fournitures non gérées en stock (prévisions quantitatives Elaboration et transmission des prévisions de consommations fournitures pour fonctionnement non régies par une norme et non gérées en stock (prévisions quantitatives) PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration et transmission des prévisions valorisées de prestation de services pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Nombre des missions par destinations

Dép. M Dép. M Dép. F Dép. M

Pour compléter budget achat (annexe) et valoriser les consommations Pour compléter budget achat (annexe) et valoriser les consommations Pour intégration dans le budget de trésorerie Annexe Etat des missions détaillé (annexe)

14) Budget élaboré par le service relation de travail RT

Objectif : budget exprimant les prévisions de consommations de fournitures et prestations de services relatives au maintien du climat socioprofessionnel au sein de l’Unité.

a) Budget de fonctionnements PA et PMT:

- Fournitures consommées (non régies par une norme) : Produits sociaux, consommation de fournitures diverses et fournitures de bureaux.



136


Acteur /

Intervenant Action / Description Destinataire Observation / support

RT

Elaboration et transmission des prévisions de consommations en fournitures pour fonctionnement non régies par une norme et non gérées en stock (prévisions quantitatives) PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Nombre des missions par destinations

Dép. M Dép. M


15) Budget élaboré par le conseil syndical

Objectif : budget exprimant les prévisions de consommations de fournitures et prestations de services, dans le cadre de l’accomplissement des missions du conseil syndical.

a) Budget de fonctionnements PA et PMT:

- Fournitures consommées (non régies par une norme) : Produits sociaux, consommation de fournitures diverses.




Conseil syndical

Elaboration et transmission des prévisions de consommations en fournitures pour fonctionnement non régies par une norme gérées et non gérées en stock (prévisions quantitatives) PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Nombre des missions par destinations

Dép. M Dép. M


16) Budget élaboré par le Département Finances :

Objectif : Le budget élaboré par le département finances a pour objectif de déterminer pour l’ensemble de l’Unité, essentiellement, les prévisions des:

Impôts et taxes,

Assurances,

Dotations aux amortissements,

Frais bancaires

Prestations de services prévues par Finances.

a) Budget et PMT élaboré par finances:

- Acteurs impliqués : Toutes les structures de l’Unité et autres structures AVAL (DAG, FIN, DRIZ………….)

- Informations exploitées (input) : Fichier investissement et le plan d’investissement Unité (pour le calcul des

amortissements) Plan de production (taxe GN auto consommé, ..) Patrimoine à assurer (contrats d’assurances, plan d’investissement et valeurs des

stocks) Plan d’approvisionnement Le nombre de contrats et montants prévisionnels à régler aux fournisseurs de

biens et services locaux et étrangers pour déterminer les services bancaires en rapport avec les modes de paiements.

Listing des véhicules légers et utilitaires réel


137


Prestations inter unité (frais de siège DG et AVAL, participation financière, …….) Paiements pour compte (redevances téléphoniques, salaires des cadres

supérieurs, contrats groupés Aval,…) Plan des consommations valorisées (A et M) Prestations de services valorisées de toutes les structures Prix GN autoconsommé retenu comme norme Soldes des comptes comptables de dettes et créances par natures de dépenses.

- Informations (output) Prévisions d’impôt et taxes Prévisions d’assurances Prévisions dotations aux amortissements Prévisions des frais bancaires (commissions,…… Prévisions des prestations inter-unités Valorisations des prévisions de GN autoconsommé

- Prévisions de prestations de services : honoraires avocats, commissaires-priseurs, notaires.

b) Budget et PMT de fonctionnements de la structure F : - Fournitures consommées (non régie par une norme) : produits sociaux, fournitures

diverses et fournitures de bureaux, …………………….. - Prestations de services : Nombre des missions par destinations.

Acteur / Intervenant Action / Description Destinataire Observation / support

Toutes les structures de l’Unité et autres structures AVAL

Voir les informations exploitées (input)

Dép. F

Dép. F

Elaboration et transmission des prévisions PA (par mois pour N et N+1) et PMT (de N+2 à N+5) de consommation de fournitures non régies par une norme, non gérées en stock (prévisions quantitatives) Elaboration et transmission des prévisions quantitatives de missions

pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration des prévisions valorisées de prestations de services prévues par Dép. F pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration des prévisions valorisées PA (par mois pour N et N+1) et PMT (de N+2 à N+5) :

Dotation aux amortissements Prévisions prestation inter-unité Impôts et taxes Assurances Frais bancaires Valorisations des prévisions de GN autoconsommé

Consolidations des prévisions valorisées des charges (Unité) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Consolidations des prévisions valorisées des produits (Unité) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5) Elaboration des prévisions de trésorerie (Unité) pour PA (par mois pour N et N+1) et PMT (de N+2 à N+5)

Dép. M

Dép. M

Pour compléter budget achat M (annexe) Etat des missions

détaillé (annexe) Pour intégration dans le budget de trésorerie Annexe

BBiibblliiooggrraapphhiiee

Bibliographie

138


[01] J. Steffe. Cours UML. Ecole nationale des ingénieurs des travaux

agricoles de bordeaux, Mars 2005.

[02] S. Ghenima. Méthodes et outils pour la gestion des workflow-Modélisation ontologique des processus pour l’analyse. Thèse de

Doctorat, Université Mouloud Mammeri de Tizi Ouzou, 2013.

[03] C. Lemaigre. Développement d'un éditeur graphique de workflow

générant automatiquement ses spécifications fonctionnelles. Mémoire de licence. Université Catholique de Louvain. 2006-2007.

[04] N. Ramuz. Business Process Management, de la Théorie à la Modélisation. Cours de Systèmes d’information I et II. Université de

Fribourg –Suisse, 2008.

[05] L. AUDIBERT. UML 2.0 . Support de cours, Institut Universitaire de

Technologie de Villetaneuse.

[06] M. Latifa & G. Nadia. Livre de la Pratique des systèmes

d’information : UML outil du génie logiciel. Edition Pages Blues, 2007.

[07] S. Hamri. Interopérabilité des Modèles de Workflow. Thèse de

Doctorat, Université Mentouri de Constantine.

[08] G. Zacharewicz. Un Environnement G-DEVS/HLA - Application à la

Modélisation et Simulation Distribuée de WORKFLOW. Thèse de

Doctorat, Université Paul Cézanne Aix-Marseille-III, 2006

[09] B. Dalila & K. Zahra. Réalisation d’un outil de modélisation workflow

des processus coopératifs – utilisation des diagrammes d’activités

UML. Mémoire de licence. Université des Sciences et de la

Technologie, 2008.

[10] M. TISSOT. Environnements d’édition de workflow. Rapport de Stage effectué dans le cadre du projet Opéra – INRIA, Août 2000.

[11] H. Bersini. La programmation orientée objet, quatrième édition,

Eyrolles, Paris, 2009.

[12] J. Gabay, D. Gabay. UML 2 Analyse et conception, Dunod, Paris,

2008.

[13] Sylvain RAMPACEK. Sémantique, interactions et langages de

description des services web complexes. Thèse de Doctorat,

Université de Reims Champagne-Ardenne, 2006.

Bibliographie

139


[14] M.B. Juric, B. Mathew, P. Sarang. BPEL pour les services web,

deuxième édition, Packt Publishing Ltd, janvier 2006.

[15] I. Chebbi and S. Tata. CoopFlow : a framework for inter-

organizational workflow cooperation. In Proceedings of International

Conference on Cooperative Information Systems, Agia Napa, Cyprus, 31 Oct-4 Nov 2005.

[16] Z. Maamar. Aperçu général sur la technologie des Workflows. Revue -

centre de recherches pour la défense valcartier, Canada. RIST

Vol.8N°02-1998.

[17] M. Baker. Workflow Meets Business Objects. In Proceedings of OOPSLA'96 Workshop, Business Object Design and

ImplementationII: Business Objects as Distributed Application

Components - the enterprise solution, 1996.

[18] C.Mohan, G. Alonso, R. Günthör et M. Kamath. Exotica : A research

perspective on workflow management systems. Data Engineering, 18(1), Mars 1995.

[19] S. Paul, E. Park et J. Chair. Essential Requirements for a Workflow Standard. In Proceedings of OOPSLA'97 Workshop, Business Object

Design and Implementation III: Patterns, Workflow, Components,

and the Web. Octobre 1997.

[20] Object Management Group. http://www.omg.org

[21] M.C. Schmidt. Building Workflow Business Objects. In Proceedings

of OOPSLA'98 Workshop, Business Object Design and

Implementation IV: From Business Objects to Complex Adaptive System. Vancouver, Canada, Octobre 1998.

[22] H. Albrecht, M. Riebisch, T. Heverhagen et H. Liessmann. A Business Object Framework Architecture. In Proceedings of OOPSLA'98

Workshop, Business Object Design and Implementation IV: From

Business Objects to Complex Adaptive System. Vancouver, Canada, Octobre 1998.

[23] P. Hruby. Structuring Specification of Business Systems with UML

(with an Emphasis on Workflow Management Systems). In Proceedings of OOPSLA'98 Workshop, Business Object Design and

Implementation IV: From Business Objects to Complex Adaptive

System. Vancouver, Canada, Octobre 1998.

http://www.omg.org/


Résumé

Le budget est un processus lourd et complexe à mettre en œuvre. Le premier rôle dubudget est de donner un cadre pour l’exercice à venir. La gestion budgétaire est unmode de gestion qui englobe tous les aspects de l'activité de l'organisation quicomprend une période de budgétisation (construction de l'ensemble cohérents deprévisions chiffrées) puis une période de contrôle budgétaire. Les prévisionsbudgétaires et leur planification au cours de toute l’année est une des partiesessentielles dans la gestion d’une entreprise industrielle. Elle permet aussi de donnerdes délais courts aux demandes/commandes des clients et des agents de l’entreprise.La gestion et le contrôle budgétaire au niveau de l’activité Sonatrach/AVAL n’adoptepas de technique et de méthode automatique suffisante à la solution du processusbudgétaire. Les difficultés à ce niveau peuvent être vues classées en deux catégories :des problèmes de gestion et des problèmes de contrôle. Le projet de l’automatisation dela gestion et du contrôle budgétaire devient donc une nécessité prioritaire.Notre objectif dans ce projet est la mise en place d'une solution informatique auproblème de la gestion et de contrôle des budgets au niveau de l'activitéSonatrach/AVAL. Notre objectif final dans ce projet est l'adoption d'une approcheorganisationnelle et méthodologique qui vise une automatisation de la gestion et ducontrôle des processus budgétaires et la mise en œuvre d'une solution généralisée pourl'optimisation de la solution au niveau de l'activité AVAL. Une bonne prévisionbudgétaire annuelle permet d’honorer les meilleures dépenses des clients et agents del’entreprise Sonatrach/AVAL. Les méthodes de prise en charge des flux utilisées serontUML et Workflow, les outils de validation des modèles de conception serontl’utilisation du Logiciel MagicDraw pour la génération des fichiers BPEL.

Mots-clés :

Modèle; Système D’information; UML; Workflow; Processus Métier; BPEL; Modélisation; Validation;Représentation Relationnelle; Activité Budgétaire; Sonatrach/AVAL.

Documents

MÉMOIRE - theses.univ-oran1.dztheses.univ-oran1.dz/document/TH4211.pdf · essentielles dans la gestion dune entreprise industrielle. Elle permet aussi de donner ... Notre objectif